¿Cuáles son las señales de advertencia de una muerte inminente a tener en cuenta en un proyecto? [cerrado]

Haber trabajado en un proyecto fallido es una de las pocas cosas que la mayoría de los programadores tienen en común, independientemente del idioma utilizado, la industria o la experiencia.

Estos proyectos pueden ser excelentes experiencias de aprendizaje, desastres devastadores (¡o ambos!), Y pueden ocurrir por una multitud de razones:

• cambio de gestión superior del corazón
• equipo poco calificado / con pocos recursos
• aparición de un competidor superior durante el ciclo de desarrollo
• sobre / bajo gestión

Una vez que haya trabajado en un par de proyectos de este tipo, ¿es posible reconocer en una etapa temprana exactamente cuándo un proyecto está condenado al fracaso?

Para mí, una gran señal es tener una fecha límite externa dura y rápida combinada con un deslizamiento de funciones . He visto que los proyectos que estaban bien planificados y que avanzaban según lo programado se salían horriblemente del camino una vez que las solicitudes de funciones tardías comenzaron a llegar y se agregaron al "entregable" final. Los proponentes de estas solicitudes ganaron el apodo de Columbo , debido a que rara vez salían de la sala sin pedir "solo una cosa más".

¿Cuáles son las señales de advertencia que buscas que activan las campanas de alarma de muerte inminente en tu cabeza?

Codificación heroica

Codificar hasta altas horas de la noche, trabajar largas horas y registrar muchas horas extras son una señal segura de que algo salió mal. Además, mi experiencia es que si ves a alguien trabajando tarde en algún momento del proyecto, solo empeora. Podría estar haciéndolo solo para que su única característica vuelva a estar programada, y podría tener éxito; sin embargo, la codificación de vaquero como esa es casi siempre el resultado de una falla de planificación que inevitablemente causará más de ella pronto. Entonces, cuanto antes lo veas en el proyecto, peor será eventualmente.

Cuando los programadores comienzan a ganar el argumento "El código es horrible, tenemos que empezar de cero". en cualquier aplicación madura.

Puede pensar que puede construirlo mejor o comprender el problema más completamente, pero realmente no lo hace. Ah, y todos esos parches feos? Son soluciones a problemas del mundo real que probablemente volverás a introducir en la reescritura.

Además, un día tendrá que explicarle al gerente del proyecto por qué después de 6 meses de trabajo tiene casi el 85% de la capacidad y el 150% de los errores que tenía la aplicación cuando comenzó.

Una nueva herramienta como solucionador de problemas.

Cuando la gente comienza a planear el uso de herramientas desconocidas, no me importa, pero lo vigilo. Cuando comienzan a planificar todos los beneficios anunciados de esas herramientas en el cronograma, me preocupa. Ejemplos divertidos:

• Podemos recortar un mes de la programación porque vamos a intentar usar un lenguaje orientado a objetos (a pesar de que todo lo que tenemos son desarrolladores c).
• Probaremos esta nueva cosa de scrum, ¡eso solucionará todos nuestros problemas de proceso!
• Sé que está a la mitad del proyecto, pero ¿qué pasa si cambiamos los ORM a algo nuevo?

Las nuevas tecnologías y prácticas son excelentes, pero casi nunca obtienes todos los beneficios de la puerta.

Para mí, el mayor problema, y ​​uno que puede detectar de inmediato, es cuando la empresa considera los requisitos escritos como una pérdida de tiempo.

Así que básicamente; No hay requisitos escritos

Es el beso de la muerte.

Desconexión de la gerencia

Cuando los responsables de plazos, características, personal, etc. se desconectan de las personas responsables de la ejecución del proyecto. Esto puede llevar a:

• Arrastre de características cuando el cliente está hablando con alguien que no entiende el costo de las características
• Síndrome de hombre-mes, donde los nuevos desarrolladores se lanzan a un proyecto lo suficientemente tarde como para ser más un obstáculo que una ayuda
• Plazos poco realistas, creados por personas que tienen que lidiar con las consecuencias comerciales de las decisiones de plazos, pero no con las consecuencias de la implementación.
• Productos que no resuelven el problema, cuando la comunicación entre el cliente y el desarrollador se ve obstaculizada por la administración en el medio.
• Mala gestión de riesgos, donde los problemas potenciales no se comunican con suficiente antelación entre los desarrolladores y la administración.

Entonces, cuando parece que la gerencia no está interesada en el proyecto, se está comunicando mal, no está escuchando a los clientes, o no está escuchando al equipo de desarrollo, corre hacia las colinas.

1. Cuando los desarrolladores clave se van y a la administración no le importa

2. Cuando los desarrolladores clave se van y ninguno de los otros desarrolladores se preocupa

El número uno suele ser indicativo de gerentes que están muy fuera de contacto con la dinámica del equipo (quién es la "súper estrella 10x", quiénes son los programadores decentes y cómo interactúan entre sí, etc.).

El número dos generalmente indica una grave falta de interés por parte de los desarrolladores restantes.

La primera vez que alguien, por lo general, la gerencia dice "no tenemos tiempo para ..."

Por lo general, precede a algo que no tenemos tiempo para no hacer, como documentación o revisiones de código (que estadísticamente encuentra y corrige más errores que cualquier otra cosa, incluidas todas las formas de prueba)

Deje que el cliente, el departamento de marketing o la gerencia elijan una fecha y luego intente retroceder a un horario imaginario

Cuando la administración es demasiado débil para decir "No" a la empresa.

Conduce a plazos que nunca se cumplirán, lo que lleva a una falta de confianza en el departamento de TI, lo que lleva a los desarrolladores a crear hacks (es decir, acceso a la base de datos que se ejecuta en la máquina de alguien ... en algún lugar), lo que lleva a una pesadilla para TI cuando el ' sistema crítico 'tiene que migrarse, lo que conduce a ...

La primera mala señal en la que puedo pensar es cuando la gerencia no está dispuesta a transmitir malas noticias a la cadena o al cliente con la esperanza de que desaparezcan, es decir, la gerencia por ilusiones. No puedo pensar cuántas veces, los desarrolladores han demostrado que no pueden cumplir el plazo semanas o incluso meses antes y, sin embargo, nadie quiere decirle al cliente. Raramente he visto a un cliente que no presionara una fecha límite cuando hay una razón genuina para explicar la necesidad con suficiente antelación; A menudo he visto a un cliente enojado cuando me dijeron el día de la fecha límite que no se cumpliría y que tampoco se cumpliría al día siguiente, sino dentro de dos meses. En este punto, con razón podría agregar, cuestionan sus procesos: ¿cómo es que no sabían esto antes?

Otra señal segura de que se avecina una falla es asignar nuevos desarrolladores a la parte más difícil y crítica del proceso en lugar de las personas que ya entienden el sistema actual. Luego, no los observe cuidadosamente para ver si realmente están completando el trabajo correctamente o si tiene preguntas (BANDERA GRANDE, GRANDE Y ROJA si no hay preguntas). Los nuevos empleados deben ser monitoreados hasta que sepa que realmente tienen las habilidades que afirman tener. Todavía recuerdo haber pasado un verano doloroso rehaciendo el trabajo (ya vencido el plazo cuando lo obtuve) de un nuevo empleado que obtuvo una pieza crítica de un proyecto y les dijo a todos que todo estuvo bien durante meses y luego renunció sin aviso una semana después de la fecha límite y nada de lo que hizo fue utilizable.

Otra señal segura de falla es cuando los desarrolladores están trabajando en piezas que dependen de otras cosas que se hacen primero y esas cosas no se hacen o incluso no se inician. Si la gerencia no puede asignar el trabajo en el orden correcto, se está yendo por los tubos.

Por supuesto, el arrastre de características sin retrasar la fecha límite cada vez es una de las señales más comunes de que las cosas van a ir mal. Agregas 20 horas de trabajo a mi plato, la fecha límite se mueve por 20 horas. Si no es así, el proyecto fallará, garantizado.

Una señal segura que he visto en mi carrera es cuando la gerencia comienza a hablar de traer más cuerpos para recuperar el tiempo en el cronograma. Nunca he visto más cuerpos en un proyecto de ayuda.

Cuando los gerentes no técnicos comienzan a insistir en tomar decisiones técnicas que de ninguna manera están calificados para tomar. ¡Grande, gran bandera roja!

La señal más obvia es una alta rotación de personal. Cuando todo el mundo está buscando un nuevo trabajo, probablemente también debería hacerlo.

El otro signo muy obvio es la falta de progreso. Si ha pasado un año y no parece que estés más cerca del objetivo, estás condenado. Esto sucede especialmente cuando los requisitos cambian más rápido de lo que puede implementarlos.

Miembros aburridos del equipo.

Estás "90% listo", la entrega es la próxima semana, pero está bien porque todo lo que te queda es "probar".

• Todos están agotados física y mentalmente
• Los clientes / usuarios están claramente descontentos con los plazos o con lo que ven.
• El diseño originalmente hermoso ahora se siente comprometido
• Está resignado a enviar con algunos errores relativamente importantes que realmente preferiría solucionar, pero que no podrá
• Su orgullo restante está en el acto de enviar en lugar de lo que envía, más cerca de la mentalidad de sobreviviente que del orgullo profesional
• El equipo tiene miedo de que haya ciertas cosas que no funcionan y están ignorando esas secciones y esperando lo mejor porque tienen miedo de lo que pueda haber allí.
• Todos están convencidos de que han ido más allá (y tienen razón)
• Las personas muestran signos de agotamiento (pesimismo general, desinterés, ira)

(Cribbed de Jim McCarthy's Dynamics of Software Development ).

Codificadores de vaqueros, grandes egos y aceptación de la gestión de los mismos.

Si el plan del proyecto requiere una sola iteración de diseño, desarrollo, prueba e implementación, la cascada clásica, para un proyecto de más de 1 mes, correría una milla.

No necesita ser completamente ágil, pero tener ciclos de desarrollo cortos le permite demostrar el progreso a todos (clientes, gerentes y desarrolladores) y hacer frente a los requisitos cambiados cuando sucede lo inevitable.

Desarrolladores Running Wild on the Range

Esto ha sucedido cuando te das cuenta de que otros desarrolladores (o, desafortunadamente, tú) han desarrollado un componente que varía significativamente del diseño, y que esto no se retoma hasta bien entrado en las pruebas del sistema / UAT. No estoy hablando de bichos; Estoy hablando de componentes importantes del sistema que faltan características o no han solicitado funcionalidad y nunca van a pasar UAT sin una revisión significativa. Este problema indica que:

• Su sistema de calidad está roto; ¿Por qué el desarrollador en cuestión no se dio cuenta del problema en la fase de diseño / implementación? ¿No se revisó / inspeccionó el código? ¿Por qué las pruebas de unidad e integración no se dieron cuenta de esto? Si no tiene algún tipo de prueba consistente de unidad / integración, está jodido.
• Su jefe de proyecto / líder técnico no tiene el control de su equipo de desarrollo. Si no pueden lograr que los desarrolladores entreguen lo que se requiere, nunca podrán entregar una solución completa.

Cuando un desarrollador clave en un proyecto no ha registrado ningún código durante semanas y se acerca un hito importante.

Fue un trabajo de contratación y el desarrollador más veterano y el primer ministro en el trabajo decidieron que querían formar un equipo para tratar de obtener un corte mayor, por lo que el otro desarrollador mantuvo 3 semanas de código crítico como rehén. Al final, despedimos al PM incompetente (que había pasado 6 meses poniendo el proyecto en un curso por ruina) y hablamos con el desarrollador.

Basta decir que el resto del proyecto fue una marcha masoquista de la muerte, la congelación de las especificaciones se retrasó, el cliente recibió un montón de características de concesión para compensar la terrible programación que el primer ministro dejó el proyecto, y la calidad del proyecto sufrió todo por eso.

El primer ministro incluso tuvo el descaro de volar para CDR (Revisión de diseño crítico) solo para deshacerse de la reunión con el cliente y lanzar un ataque de silbido. Cuando exigió que sus gastos de viaje se pagaran en virtud del proyecto, se le dijo cortésmente que fornicara consigo mismo.

Puedo identificarme fácilmente con al menos 5 de las otras respuestas encontradas aquí que afectaron ese proyecto. En resumen, aprendí muchas lecciones difíciles en mi primer proyecto serio de codificación.

Mi primer signo en uno fue cuando preguntaron a cuántas horas de tiempo extra nos comprometeríamos cada una durante las próximas diez semanas y les ofrecimos a los trabajadores asalariados un bono por trabajar dicho tiempo extra basado en el éxito del proyecto y el cumplimiento de los plazos.

Otros signos importantes que he visto: la definición de requisitos supera el cronograma y la fecha de finalización no se mueve. Estábamos atrás incluso antes de que podamos comenzar. Se tomaron el tiempo del diseño, por lo que comenzamos sin un diseño de base de datos y un diseño de sitio, pero esperamos entregar a tiempo, entre otras cosas, haciendo importaciones a tablas que aún no están diseñadas y creadas.

Cuando los elementos en la ruta crítica se realizan simultáneamente en lugar de en orden. (Si tengo que usar la herramienta X y el programador A apenas comienza a compilarla, retrasará mi tarea).

Cuando los gerentes están confirmando el código en Acción de Gracias.

Cuando comience a recibir correos electrónicos que tengan una marca de fecha y hora posterior a las 11 p.m. y antes de las 6 a.m.

Cuando cada pregunta sobre cómo manejar cierta complejidad se encuentra con la misma respuesta, "No te preocupes por eso todavía".

Cuando todavía están haciendo cambios en los requisitos, el día antes de ir a control de calidad o en vivo.

Cuando comienzas a tener reuniones diarias que toman varias horas para discutir tu falta de progreso. Oh, eso sería porque estoy en reuniones todo el día. Reunión diaria de 5 minutos bien, reunión diaria que dura más de una hora, no está bien.

Cuando el equipo de la base de datos y el equipo de aplicación no hablan entre sí.

Cuando el cliente no puede proporcionar la información prometida a tiempo. Especialmente cuando se trata de archivos de importación de datos y necesita esos datos en la base de datos para verificar cómo funciona el código.

Cuando considere instalar una luz de freno fuera de la oficina de algún gerente para informarle si es seguro acercarse a él ese día.

Creo que en general es fácil detectar un proyecto fallido cuando se acerca la fecha límite. Como dijiste, el arrastre de características combinado con una fecha límite establecida es una forma segura de matar un proyecto.

Sin embargo, la clave es detectar un proyecto que falla con mucha antelación. Creo que el único "signo de fatalidad" real en este caso sería una falta total de la definición de "cuando hayamos terminado". A menos que sepamos esto en la compensación, estamos condenados a fallar en la OMI.

He estado en tres marchas de la muerte en los últimos cinco años. Aquí hay algunas cosas que contribuyeron a mi instinto de fatalidad inminente.

• La compañía decide que los desarrolladores junior diseñen y desarrollen nuevas funciones, y asigna desarrolladores senior más caros para corregir sus errores.
• La compañía externaliza componentes críticos de software a compañías del tercer mundo que no tienen la experiencia requerida en el dominio.
• Los ciclos de tiempo de crisis se acercan tanto que la salud de las personas se está deteriorando.
• Las pastillas que su equipo toma para drogarse cada noche dejan de funcionar.
• El cliente envía órdenes de cambio más rápido de lo que puede analizarlas.
• Se supone que debe entregar el trabajo de varios años en unas pocas semanas, pero la gerencia se niega a congelar las funciones.
• Sus proveedores de hardware claramente tienen problemas para entregar un producto viable a tiempo, y los tomadores de decisiones en su empresa no considerarán ninguna alternativa.
• Los desarrolladores de dispositivos prototipo que necesitan para tener la posibilidad de cumplir con el programa probablemente poco realista se les quita y se les da a los principales ejecutivos para que se sientan bien.
• Semana uno: "Oh, mierda, el código tiene errores. Todos dejaron de hacer nuevas funciones y corrigieron errores". Semana dos: "Oh, mierda, no vamos a cumplir con el calendario de funciones. Todo el mundo deja de corregir errores y escribe nuevas funciones". Repite indefinidamente.
• El desarrollo se realiza en un país, y el control de calidad se realiza en otro país al otro lado del mundo, por lo que una comunicación de ida y vuelta sobre un error siempre requiere 24 horas, y al menos una de las personas involucradas está discutiendo problemas técnicos complicados. en un idioma en el que no dominan.

Para mí, es cuando aquellos que son responsables del conjunto de características (también conocidos como gerentes, propietarios de productos, clientes ...) dejan de preocuparse o parecen tener un aire desesperado sobre sus respuestas. Las preguntas sobre las características se encuentran con apatía y desánimo. Está claro que han perdido inversión o confianza en el proyecto.

Esto me sucedió cuando un proyecto en el que estaba tuvo el "cambio de corazón de la alta dirección". Estaba haciendo preguntas sobre cómo debería funcionar y, de repente, nadie tenía una opinión real.

Poco tiempo después, el proyecto fue cancelado y todo el hermoso código que había escrito fue descartado.

Paul Vick escribió una excelente publicación hace varios años sobre proyectos de agujeros negros . Creo que todos los consejos son relevantes. (He editado los ítems y resúmenes por longitud).

• Metas absurdamente grandiosas . Como "fundamentalmente reinventar la forma en que las personas trabajan con las computadoras".
• Plazos completamente poco realistas . Por lo general, esto se debe a que creen que pueden reescribir la base de código original en mucho, mucho menos tiempo del que originalmente tomó.
• Creencias poco realistas sobre la compatibilidad . Como creer, puedes reescribir y preservar todas las pequeñas peculiaridades sin ningún esfuerzo adicional.
• Siempre "seis meses" desde la fecha límite principal que nunca parece llegar . O, si llega, se agrega otro hito al final del proyecto para compensar.
• Debe consumir grandes cantidades de recursos . Por lo general, al extraer la sangre de uno o más productos establecidos.
• Involucre el uso de tecnología completamente nueva que aún no ha sido probada . Como tal, pueden eliminar todos los problemas de escalabilidad con la nueva tecnología.

Traduzco mentalmente "Todo está bien. No tenemos nada de qué preocuparnos". a "Todos estamos jodidos" cada vez que escucho que la gerencia lo dice. Por lo general, se escucha a los gerentes lanzarlo de manera incidental en reuniones no relacionadas ("Ah, por cierto, todo va bien. ¡No hay razón para preocuparse!"), Pero es una señal de alerta aún más grande tener una reunión específicamente convocada para decir eso.

Todavía tengo que escuchar a un gerente decir algo en este sentido y que no resulte mentira.

Un par de puntos de un proyecto muerto del que formé parte:

• La gerencia duplica al equipo para terminar más rápido.
• los desarrolladores comienzan a "enterrar" los errores para cumplir con los plazos, y aunque es obvio, se ignoran durante la revisión del código.

Cuando la gerencia lleva el proyecto a diferentes direcciones simultáneamente y el carro permanece quieto.

Una vez estuve involucrado en un proyecto administrado por dos chicos. O no se hablaban o cada uno tenía algo de ego que resolver, pero estaban dirigiendo nuestro trabajo en dirección opuesta aproximadamente cada semana más o menos. No tardé en darme cuenta de que nunca habrá ningún resultado. Con mucho gusto mi participación solo duró unos pocos meses.

Vea este breve artículo: Cuando los proyectos de TI van bien .

La ausencia de cualquiera de los elementos establecidos en el artículo debería hacer sonar las alarmas:

Así que asegúrese de que su proyecto tenga todo lo siguiente, si no, entonces debería preocuparse:

(para citar el artículo anterior :)

1. "La primera es que se basan en una visión clara de lo que se debe lograr".

2. "La segunda característica se refiere al apoyo y compromiso de las diferentes partes involucradas en todo el negocio, especialmente la alta gerencia".

3. "Tercero es comprender los problemas que deben abordarse".

4. "La característica común final es que se han puesto a disposición suficientes recursos y habilidades".

Estadísticamente, el inicio de un proyecto de software es una buena señal de que fracasará, como lo hace una abrumadora mayoría de ellos ...