it-swarm-es.com

¿Cómo lidiar con proyectos de programación que fracasan?

No es raro que los proyectos fracasen.

Como programador, ¿cómo maneja los proyectos que fracasan?

Algunas definiciones de fracaso:

  • No cumple con la fecha límite.
  • El código y la funcionalidad no hacen lo que se supone que deben hacer.
  • El software se convierte en vapor-ware o en un sinfín de fases, esencialmente imposible de entregar.

O tal vez tenga su propia definición de fracaso.

¿Empiezas a señalar con el dedo? ¿Te culpas a ti mismo, a los requisitos, a la tecnología, a la gestión, al cliente, etc? ¿Hacéis una sesión de lecciones aprendidas en equipo?

12
spong

Debe hacer lecciones aprendidas para todos los proyectos, fallidos o exitosos. Hay mucho que aprender de un buen proyecto.

Los verdaderos proyectos fallidos han sido muy raros para mí. Además de comprender lo que sucedió, hago lo de "preguntar por qué cinco veces" para tratar de llegar a las causas subyacentes. También está la cuestión de por qué no me di cuenta de lo que estaba sucediendo y hice algo al respecto o al menos salí.

Creo que la primera posición de todos es culpar de todo: el cliente, la tecnología, el problema comercial que se aborda, la metodología, los miembros del equipo, el idioma, la plataforma, incluso la forma en que tomamos nuestro café por la mañana. Lo bueno de una retrospectiva (incluso si ocurre solo en su propia cabeza) es la oportunidad de reconciliarse con algunos o todos esos factores y darse cuenta de que no eran el problema.

En mi único fracaso real de los últimos 30 años, el proyecto había estado en requisitos durante literalmente años cuando llegamos. Tenemos los requisitos establecidos. Uno provino de la administración y cientos de los usuarios finales. Escribimos código, mucho código, algunos de ellos brillantes. Hubo pruebas y pruebas de aceptación y cambios y argumentos y solicitudes de cambio y trabajo no remunerado y trabajo remunerado y pernos de última hora y humor surrealista y escaladas a vicepresidentes y todo eso. Eventualmente, todo se detuvo. La razón del error fue que el requisito de gestión única era inaceptable para los usuarios finales. Y no importa cuántas cosas se salieran con la suya, no podrían superar esa y nunca aceptarían el sistema. Pero la gerencia no lo haría de otra manera. Así que eso fue todo y aunque obtuvimos mucho dinero, al final, todo fue horrible.

Todavía trabajo en esa tecnología, sigo usando esos procesos y sigo trabajando con las mismas personas. Incluso haría otro proyecto para ese cliente. Pero cuando los usuarios finales dicen que no les gusta algo que su propia administración ha inyectado en los requisitos, recordaré que escribir un buen código que funcione no lo protege de un proyecto fallido. Y haré algo al respecto entonces, no uno o dos años después.

8
Kate Gregory

Aléjate, perra, durante unos días o una semana mientras evito hacer cosas importantes, luego trato de averiguar qué salió mal y cómo no dejar que vuelva a suceder.

3
David Thornley

Hay un gran libro sobre el tema llamado Marcha de la Muerte: http://www.Amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X

Le sugiero que lo lea. Puede reconocer su (s) proyecto (s) en muchas descripciones.

No hay una respuesta única, ya que depende en gran medida de muchos componentes complejos de su organización, incluida la política ...

3
user2567

Culpé a todos menos a mí ... jaja, es broma. Lo que hago es escribir un documento de "Mea Culpa", con todas las cosas que "hice" mal. tal vez no ayude a ese proyecto, pero es una buena forma de no repetir los mismos errores

1
Nisanio