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

Codificación heroica

Codificar hasta altas horas de la noche, trabajar largas horas y cronometrar muchas horas extra son una señal segura de que algo salió mal. Además, mi experiencia es que si ves a alguien trabajando hasta tarde en cualquier punto del proyecto, solo empeorará. Puede que lo esté haciendo solo para que su única característica vuelva a estar programada, y podría tener éxito; sin embargo, la codificación de vaqueros como esa es casi siempre el resultado de un fallo de planificación que inevitablemente causará más de esto pronto. Por lo tanto, cuanto antes lo veas en el proyecto, peor se volverá.

Cuando los programadores comienzan a ganar el argumento "El código es horrible, debemos comenzar desde cero". en cualquier aplicación madura.

Puedes pensar que puedes construirlo mejor, o entender el problema más completamente, pero realmente no lo haces. 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 las personas comienzan a planear el uso de herramientas desconocidas, no me importa, pero estoy atento. Cuando comienzan a planificar todos los beneficios anunciados de esas herramientas en el calendario, me preocupo. Ejemplos divertidos:

• Podemos ahorrar un mes de la programación porque vamos a intentar usar un lenguaje orientado a objetos (aunque todos somos desarrolladores c).
• ¡Probaremos este nuevo scrum, que solucionará todos nuestros problemas de proceso!
• Sé que está a mitad del proyecto, pero ¿y si cambiamos los ORM a algo nuevo?

Las nuevas tecnologías y prácticas son excelentes, pero casi nunca se obtienen todos los beneficios.

Para mí, el mayor problema, y uno que puede detectar de inmediato, es cuando las empresas consideran 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 gestión

Cuando los responsables de plazos, características, personal, etc. se desconectan de las personas responsables de entregar el proyecto. Esto puede llevar a:

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

Entonces, cuando parece que la administración 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 por 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 (que es la "súper estrella 10x", quiénes son los programadores decentes, y cómo interactúan entre sí, etc.). p>

El número dos suele indicar una gran falta de interés por parte de los desarrolladores restantes.

La primera vez que alguien, generalmente la gerencia dice "no tenemos tiempo para ..."

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

Deje que el cliente, el marketing o la gerencia escojan una fecha y luego intenten trabajar hacia atrás para lograr un horario imaginario

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

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

La primera mala señal que se me ocurre es cuando la administración no está dispuesta a pasar las malas noticias a la cadena o al cliente con la esperanza de que desaparezca, es decir, la gestión por ilusiones. No puedo pensar en cuántas veces, los desarrolladores han demostrado que no pueden cumplir con el plazo de semanas o incluso meses antes, y sin embargo, nadie quiere decírselo al cliente. Rara vez he visto a un cliente que no exigiría una fecha límite cuando existe una razón genuina para explicar la necesidad con suficiente antelación; A menudo he visto a un cliente enojado cuando le informaron el día de la fecha límite que no se iba a cumplir y que tampoco se cumpliría al día siguiente sino a los dos meses en el futuro. En este punto, ellos, con razón, puedo agregar, cuestionan sus procesos, por qué no lo sabían antes. (Respuesta verdadera, pero la que nunca dimos. Lo sabíamos, pero teníamos miedo de decírtelo).

Otra señal segura de que se está produciendo un error es asignar a los nuevos desarrolladores la parte más crítica y complicada del proceso, en lugar de las personas que ya comprenden el sistema actual. Entonces no los mire con cuidado para ver si realmente están completando el trabajo correctamente o si tienen preguntas (BANDA GRANDE GRANDE ROJA si no hay preguntas). Los nuevos empleados deben ser monitoreados hasta que sepa que realmente tienen las habilidades que afirman tener. Todavía puedo recordar haber pasado un verano doloroso rehaciendo el trabajo (que ya había vencido la fecha límite cuando lo obtuve) de un nuevo empleado que recibió una parte crítica de un proyecto y le dijo a todos que todo estuvo bien durante meses y luego renunció una semana después de la fecha límite. y nada de lo que hizo fue utilizable.

Otra señal segura de fracaso es cuando los desarrolladores están trabajando en piezas que dependen de que otras cosas se hagan primero y esas cosas no se hayan hecho o ni siquiera se hayan iniciado. Si la administración no puede hacer que el trabajo se asigne en el orden correcto, se está yendo por los tubos.

Por supuesto, la característica de arrastrarse 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 en 20 horas. Si no lo hace, entonces el proyecto fallará, garantizado.

Una señal segura que he visto en mi carrera es cuando la administración comienza a hablar sobre traer más cuerpos para compensar el tiempo en el calendario. Nunca he visto más cuerpos en la ayuda de un proyecto.

Cuando los gerentes no técnicos comienzan a insistir en tomar decisiones técnicas para las cuales no están calificados. ¡Grande, grande bandera roja!

El signo más obvio es una alta rotación de personal. Cuando todo el mundo está buscando un nuevo trabajo, probablemente debería hacerlo también.

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 del equipo aburrido.

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 las escalas de tiempo o con lo que están viendo
• El diseño originalmente hermoso ahora se siente comprometido
• Estás resignado a enviar algunos errores relativamente importantes que realmente prefieres solucionar, pero que no vas a poder
• El orgullo que te queda es el hecho de enviar en lugar de lo que estás enviando, más cercano a la mentalidad de sobreviviente que al 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 podría 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 from Dinámicas del desarrollo de software de Jim McCarthy).

Codificadores de vaqueros, grandes egos y aceptación por parte de la administración

Si el plan del proyecto requiere una iteración única 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, administradores y desarrolladores) y hacer frente a los cambios en los requisitos cuando suceda lo inevitable.

Desarrolladores que ejecutan Wild en el rango

Esto sucedió cuando te das cuenta de que otros desarrolladores (o, desafortunadamente, tú) han desarrollado un componente que varía significativamente con respecto al diseño, y que esto no se detecta hasta bien en las pruebas de sistema / UAT. No estoy hablando de bichos; Me refiero a que los componentes importantes del sistema carecen de características o carecen de una funcionalidad no solicitada y nunca pasarán la UAT sin una reelaboració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 detectaron esto? Si no tiene algún tipo de prueba de unidad / integración consistente, está jodido.
• Su jefe de proyecto / jefe 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 avecina un hito importante.

Era un trabajo de contratación y el desarrollador y PM más avanzado en el trabajo decidieron que querían formar un equipo para tratar de obtener un recorte mayor, por lo que el otro desarrollador tuvo 3 semanas de secuestro de código crítico. Al final, despedimos al incompetente PM (que había estado gastando 6 meses poniendo el proyecto en un curso para arruinar) y hablamos con el desarrollador.

Basta con decir que el resto del proyecto fue una marcha de muerte masoquista, la congelación de especificaciones se retrasó, el cliente recibió un montón de características de concesión para compensar la terrible programación en la que el primer ministro abandonó el proyecto y la calidad de el proyecto sufrió a causa de ello.

El PM incluso tuvo el descaro de volar hacia abajo para CDR (Critical Design Review) solo para deshacerse de la reunión con el cliente y lanzar un ataque sibilante. Cuando exigió que sus gastos de viaje se pagaran en el marco del proyecto, se le pidió cortésmente que se fornicara consigo mismo.

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

Mi primer signo en uno fue cuando preguntaron a cuántas horas extraordinarias nos comprometemos cada uno durante las próximas diez semanas y les ofrecieron a los trabajadores asalariados un bono por trabajar, dijo que las horas extraordinarias se basaron en el éxito del proyecto y en las fechas límite. p>

Otros signos importantes que he visto: La definición de los requisitos va más allá de lo programado y la fecha de finalización no se mueve. Estábamos atrasados antes de que podamos siquiera comenzar. Se tomaron el tiempo de diseño, por lo que comenzamos sin diseño de base de datos ni diseño de sitio, pero se espera que entreguen a tiempo, entre otras cosas, realizando importaciones a tablas que aún no están diseñadas ni 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 está empezando a construirla, se retrasará mi tarea).

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

Cuando comienza a recibir correos electrónicos que tienen una marca de fecha y hora posterior a las 11 pm y antes de las 6 am.

Cuando todas las preguntas sobre cómo manejar algo de complejidad se encuentran 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 al control de calidad o ir a vivir.

Cuando comienza a tener reuniones diarias que toman varias horas para discutir su falta de progreso. Oh, eso sería porque estoy en reuniones todo el día. Buena reunión diaria de 5 minutos, 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 la aplicación no se hablan entre sí.

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

Cuando considere instalar un semáforo afuera de la oficina de algún gerente para informarle si es seguro acercarse a él ese día.

Creo que generalmente es fácil detectar un proyecto fallido cuando se acerca la fecha límite. Como ha dicho, la función de arrastre de funciones combinada con una fecha límite establecida en piedra es una forma segura de matar un proyecto.

Sin embargo, la clave es detectar un proyecto fallido de antemano. Creo que el único "signo de la fatalidad" real en este caso sería la falta completa de la definición de "cuándo hemos terminado". A menos que sepamos esto en la compensación, estamos condenados por un fallo de IMO.

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

• La compañía decide que los desarrolladores junior diseñen y desarrollen nuevas funciones, y asigna a los desarrolladores senior más costosos para corregir sus errores.
• La compañía subcontrata componentes de software críticos a compañías del tercer mundo que no tienen la experiencia de dominio requerida.
• Los ciclos de tiempo de crisis se acercan tanto que la salud de las personas se está deteriorando.
• Las píldoras que su equipo lleva para drogarse y dormir cada noche dejan de funcionar.
• El cliente envía órdenes de cambio más rápido de lo que puede analizarlas.
• Se supone que debes realizar varios años de trabajo en unas pocas semanas, pero la administración se niega a congelar las funciones.
• Sus proveedores de hardware claramente están teniendo problemas para entregar un producto viable a tiempo, y los tomadores de decisiones en su empresa no considerarán ninguna alternativa.
• Los prototipos de dispositivos que los desarrolladores necesitan para que tengan la posibilidad de cumplir el calendario probablemente poco realista se les quita y se les entrega a los principales ejecutivos para que se sientan bien.
• Semana uno: "Oh, mierda, el código está defectuoso. Todos dejen de hacer nuevas funciones y corrigen errores". Segunda semana: "Oh, mierda, no vamos a cumplir con el calendario de funciones. Todos dejen de corregir errores y escriben nuevas funciones". Repita indefinidamente.
• El desarrollo se realiza en un país, y el control de calidad se realiza en otro país del 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 son competentes.

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

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

Poco después, se canceló el proyecto y se eliminó todo el hermoso código que había escrito.

Paul Vick escribió un excelente publicación hace varios años sobre agujero negro proyectos . Creo que todos los consejos son relevantes. (He editado los elementos y los resúmenes para su longitud).

• Objetivos absurdamente grandiosos . Me gusta "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 volver a escribir el código base original en mucho, mucho menos tiempo del que se tomó originalmente.
• Creencias poco realistas sobre compatibilidad . Al igual que creer, puedes reescribir y conservar todas las pequeñas peculiaridades sin ningún esfuerzo adicional.
• Siempre "seis meses" a partir de la fecha límite principal que nunca parece llegar . O, si llega, se agrega otro hito al final del proyecto para compensar.
• Debe consumir enormes cantidades de recursos . Por lo general, chupando la sangre vital de uno o más productos establecidos.
• Implique el uso de una tecnología completamente nueva que aún no se haya probado . Como tales, 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 lo escucho, la gerencia lo dice. Por lo general, los gerentes lo lanzan incidentalmente en reuniones no relacionadas ("Ah, por cierto, todo va bien. ¡No hay razón para preocuparse!"), Pero es una bandera roja aún más grande tener una reunión específicamente convocada para decir eso.

Todavía no he escuchado a un gerente decir algo en este sentido y que no resulte ser una mentira.

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

• La administración duplica al equipo para terminar más rápido.
• los desarrolladores comienzan a "enterrar" 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 inmóvil.

Una vez estuve involucrado en un proyecto gestionado por dos chicos. O bien no se hablaron entre sí o cada uno tiene un ego que resolver, pero estaban encomendando nuestro trabajo en dirección opuesta cada semana aproximadamente. No tardó mucho en darse cuenta de que nunca habrá ningún resultado. Con mucho gusto mi participación solo duró unos meses.

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

La ausencia de cualquiera de los elementos enunciados en el artículo debe hacer que suenen las campanas de alarma:

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 va a lograr".

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

3. "El tercero es una comprensión de los problemas que deben abordarse".

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

El inicio estadístico de un proyecto de software es una señal justa de que fallará, como lo hace la gran mayoría de ellos ...