Para mí, hay dos aspectos de cualquier tarea asignada a un desarrollador en un proyecto de software. Estos no son excluyentes, por lo que una tarea puede ser (por ejemplo) 40% aspecto 1 y 60% aspecto 2:
No tengo problema en trabajar en tareas que son completamente de tipo 2, ya que son parte del trabajo, pero cuando hay otros miembros del equipo que ya han dedicado mucho tiempo a esas áreas específicas, me parece una tarea pérdida de tiempo y recursos para todos. Esto mata absolutamente mi motivación. Sobre todo en un proyecto próximo a terminar, cuando está claro que no habrá más tareas en esas áreas.
Esto puede ser útil para compartir conocimientos entre el equipo, por ejemplo, si alguien renuncia, otros podrían tomar el relevo, pero cualquiera puede dedicar unos días a descubrir un código. Hacerlo por adelantado es como pagar por un accidente que aún no ha ocurrido o que en realidad nunca ocurrirá.
Entiendo que no es agradable estar encasillado; Yo mismo estuve allí, trabajando en proyectos heredados que realmente no son relevantes para la tecnología, la arquitectura o las metodologías actuales. Si me hubiera dejado solo, probablemente habría terminado siendo el "chico del código heredado", así que hablé con mi gerente y le dije que quería hacer otras cosas además de trabajar en cosas heredadas. Entonces, creo que el paso 1 para usted es plantear algo similar a su gerente.
Siempre habrá tareas en el trabajo que no quieras hacer, pero no se resolverán solas y, eventualmente, alguien tiene que hacerlas. Sin embargo, no es justo que esto sea responsabilidad exclusiva de una persona, por lo que tiene perfecto derecho a pedir trabajar en otras cosas, siempre que acepte su parte de la responsabilidad general, tal como lo hace todo buen empleado cuando elige trabajar. para un empleador.
En términos de cómo motivarse durante esos momentos en los que está atascado haciendo cosas que no quiere, aquí hay algunos consejos que funcionan para mí:
Por último, su punto sobre compartir conocimientos es válido. Sin embargo, tu siguiente comentario sobre que es una pérdida de tiempo no es válido; como dijiste, es
pagar por algún accidente que aún no sucedió o que tal vez ni siquiera suceda nunca
Tú mismo lo dijiste; no está garantizado que estos desarrolladores experimentados siempre estarán disponibles, por lo que es mejor para la empresa asegurarse de que suficientes personas conozcan estos productos para poder mantenerlos en funcionamiento en caso de que la gente se vaya (o, como es cada vez más el caso con el código heredado , morir).
Probablemente comenzó por uno de esos "otros miembros, que pasaron mucho tiempo allí" diciendo que también deseaban trabajar en otras tareas, además de que el factor autobús también es un buen argumento.
He usado varias estrategias, según el tipo de tarea, la cantidad, el tiempo esperado, etc.:
Nota: Hay literalmente cientos de formas, según el tipo de tarea (error de código heredado, función de código heredado, clic manual, arreglos manuales de datos, creación de informes, aprendizaje de tecnología antigua/impopular), tiempo esperado de finalización (5 minutos de locura). haciendo clic, 1 hora de reflexión, 3 meses de investigación, ...) etc.
Cómo motivarse para trabajar en tareas que no te ayudan a mejorar
Incluso si tu tarea actual no tiene posibilidad de mejorar (lo dudo), al completar estas tareas liberas tiempo para trabajar en tareas que te ayudarán a mejorar.
Entonces, si su único propósito para trabajar en su empresa es mejorar, su motivación debe ser terminar la tarea A "que no mejora" para que pueda trabajar en la tarea B "que mejora".
Piense en formas de automatizar su trabajo de rutina. Utilice los sentimientos de frustración y aburrimiento como un sistema de encendido para su descubrimiento de métodos de automatización.
Marcos Rotteveel
uylmz
motosubatsu
gnasher729