Cómo lidiar con un caso de ‘depresión del desarrollador’

Answer 1

Parece que esta empresa en particular puede no estar bien estructurada. Si bien los requisitos de desarrollo cambian todo el tiempo, los cambios frecuentes y / o drásticos son una señal de una planificación deficiente y una ejecución peor. Eso habla más hacia la gestión de la empresa y podría ser una señal de alerta en lo que respecta al futuro de la empresa y / o el proyecto.

Le sugiero que hable con sus colegas ingenieros y vea si también encuentran alarmante la frecuencia. En caso de que todos estén de acuerdo, hable con los gerentes de proyecto sobre el tema. Los buenos gerentes de proyecto entenderán cómo los cambios frecuentes están afectando la moral (código no utilizado, cambios, pivotes, etc.) y cambiarán las cosas en consecuencia.

Si no están abiertos a sugerencias o el alcance del proyecto requiere los cambios frecuentes a los que no está acostumbrado, puede que sea el momento de elegir otra empresa para la cual trabajar. Su trabajo a lo largo del tiempo se convertirá en deficiente, y su salud mental probablemente se verá afectada, lo que afectará negativamente a usted y a su empresa.

Algunos le sugerirán que busque distracciones fuera del trabajo, que adquiera nuevos pasatiempos o “deje el trabajo en el trabajo” cuando regrese a casa. Si bien todas estas son soluciones excelentes para la “depresión del desarrollador” en general (como resultado de un exceso de trabajo / agotamiento / pocos resultados), harán poco para ayudar en una situación en la que el proyecto en sí mismo sea ​​la razón detrás de su angustia. Cuando regrese al trabajo, incluso después de desconectarse, se encontrará todavía evitado para el proyecto y, en última instancia, el problema no se solucionará.

¡La mejor de las suertes!

Answer 2

Estoy totalmente de acuerdo con lo que dijo Gary Barlich, pero en este caso creo que es su empresa la que debe tomar la iniciativa. Así que sin hablar con el gerente, nada va a cambiar demasiado rápido. Mejor que sea positivo, dígales cuánto pudo haber hecho y cuánto podría ganar más la compañía si se escribieran los requisitos, así …

Answer 3

Cambiar los requisitos es una fuente común de frustración para los programadores; Sin embargo, también es parte integral del proceso. ¿Por qué? La obtención de requisitos es difícil y, francamente, muchos clientes (incluida la gerencia) realmente no saben lo que quieren. Aquí estarás, “lo sabré cuando lo vea”. Entonces juegas el juego “tráeme una roca”, “no, no ésa, tráeme otra roca”. No lo tomes personalmente, es parte del proceso de requisitos. Mejorará en ayudar al cliente (o a la gerencia) a definir sus requisitos de software. Puede hacer esto con maquetas, casos de uso (o escenarios de usuario) y requisitos escritos (con buenas definiciones). Habiendo dicho todo esto, si todavía no está contento, conserve su trabajo actual mientras busca otro. Eso es un beneficio de la industria de la tecnología: hay muchos buenos trabajos. ¡Los mejores deseos!

Answer 4

Salir. Si no estás contento, te costará mucho cambiar las cosas para que seas más feliz y productivo.

Si los requisitos siempre cambian, parece que no se está produciendo una gestión formal del proyecto. Los cambios ocurren y afectan el proyecto, a veces poco y a veces mucho. Se necesita un PM para administrar ese proceso de cambio y para asegurar que todos los requisitos se reúnan antes de comenzar el trabajo.

¿Existe un plan de proyecto formal con los requisitos acordados y aprobados por el cliente? ¿Existe un proceso formal de gestión de cambios que maneje las solicitudes de cambio y la documentación asociada y pueda explicar a todos los involucrados las consecuencias del cambio, como la demora en el proyecto o los costos adicionales u otros riesgos, etc.

La otra opción es ingresar al rol de PM y comenzar a explicar los costos / riesgos de realizar muchos cambios. He hecho esto en mi pasado y he trabajado duro para mejorar las relaciones con los clientes y compañeros de trabajo cuando las cosas no se manejaron bien.

Answer 5

Estoy de acuerdo con Gary, y ahora veo dónde dijiste que eres un programador.

Mi recomendación es volver a encuadrar la situación. Considera esto como una oportunidad de aprendizaje. Aprenderás varias habilidades. La primera habilidad es convertirse en un maestro del cambio. Podrá implementar el cambio y recuperarse de un cambio en el tiempo récord, impresionando a todos. Y mientras aprende a convertirse en el maestro del cambio, también aprenderá los pasos necesarios que se deben seguir para evitar la necesidad del cambio. Documentar esos y aplicarlos a todas las tareas nuevas y presentes. Pronto, habrán encontrado soluciones que beneficiarán a toda la compañía.

Answer 6

Te escucho.

El mejor consejo que recibí sobre esto es que formen parte de tu equipo. No tienes que reorganizar ni nada. Simplemente involucrarlos de tantas maneras como sea posible en el trabajo diario. Por ejemplo:

• Prototipo temprano y con frecuencia. Permítales al menos ver la página web / formulario lo antes posible. De esa manera, los cambios tienden a ocurrir al principio del proceso y no más tarde.
• Haga que documenten los requisitos. Luego, cada vez que las cambien, deberán actualizar la documentación.
• Haga que desarrollen guiones de prueba. Saben mejor lo que quieren que haga el sistema. A medida que cambien los requisitos deberán actualizar los scripts de prueba.

Obviamente, es probable que tenga que hablar con su gerente o su primer ministro. Intenta ser lo más constructivo posible. La mayoría de la gente ama resolver problemas y odia escuchar quejas. Ponte en sus zapatos antes de hablar con ellos.

Finalmente, se da cuenta de que dos cosas cambian lentamente y cada grupo con el que trabaja es diferente. Probablemente en tu carrera tendrás muchas situaciones como las que tienes ahora mismo, algunas completamente opuestas, y todo lo que hay entre ellas.

Espero que ayude.