it-swarm-es.com

¿Cuáles son las señales de advertencia de Doom inminente a tener en cuenta en un proyecto?

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 grandes 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í, un gran letrero es tener una fecha límite externa dura y rápida combinada con el desplazamiento de características . He visto que los proyectos que estaban bien planeados y que se desarrollaban según lo programado se salían horriblemente del Rails una vez que las solicitudes de funciones tardías comenzaron a llegar y se agregaron al "entregable" final. de estas solicitudes obtuvo el apodo de Columbo , debido a que rara vez sale de la habitación sin pedir "solo una cosa más".

¿Cuáles son las señales de advertencia que buscas que activan las alarmas de Doom inminente en tu cabeza?

66
ConroyP

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, una 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.

70
Fishtoaster

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ó.

44
JohnFx

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; Sin requisitos escritos

Es el beso de la muerte.

41
John MacIntyre

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.

41
Fishtoaster

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 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 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 hacia las colinas.

33
Fishtoaster
  1. Cuando los desarrolladores clave se van y 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.

25
MrDatabase

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)

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 administración 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 exija un plazo 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? (Respuesta verdadera pero la que nunca damos; lo sabíamos pero teníamos miedo de decírtelo).

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 previo 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 deslizamiento de la función sin retrasar el plazo 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.

21
HLGEM

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 ...

21
adolf garlic

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

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

18
Walter

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!

17
GrandmasterB

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.

16
user281377

Miembros aburridos del equipo.

13
Ashalynd

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

12
Scott Whitlock

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

  • 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 Dinámica del desarrollo de software ).

10
Jon Hopkins

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 requisitos cambiantes cuando sucede lo inevitable.

9
ChrisF

Desarrolladores corriendo salvajes en el rango

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 modificaciones significativas. 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.
9
MagicAndi

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

Era un trabajo de contratación y el desarrollador más senior y PM 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 incompetente PM (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 PM dejó el proyecto, y la calidad del proyecto sufrió por todas partes debido a él.

El PM incluso tuvo el descaro de volar para CDR (Critical Design Review) solo para deshacerse de la reunión con el cliente y provocar un ataque de disgusto. Cuando exigió que sus gastos de viaje se pagaran por debajo de Al 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.

8
Evan Plaice

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 una bonificación 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 debo 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 comienza a recibir correos electrónicos que tienen un sello 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.

8
HLGEM

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 Doom" 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 al fracaso de la OMI.

6
Jaco Pretorius

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

  • La compañía decide que los desarrolladores junior diseñen y desarrollen nuevas características, 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 píldoras 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 varios años de trabajo en unas pocas semanas, pero la gerencia se niega a congelar las funciones.
  • Claramente, sus proveedores de hardware 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 corregir errores". Semana dos: "Oh, mierda, no vamos a cumplir con el cronograma 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.
6
Bob Murphy

Paul Vick escribió un excelente post hace varios años sobre ¡proyectos de agujeros negros. Creo que todos los consejos son relevantes. (He editado los elementos y resúmenes por longitud).

  • Objetivos absurdamente grandiosos . Como "fundamentalmente reinventar la forma en que las personas trabajan con 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.
5
Chris Smith

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.

Un poco más tarde, el proyecto fue cancelado y todo el hermoso código que había escrito fue descartado.

5
Vaccano

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.
4
OKAN

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, y 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 ser una mentira.

4
Jason Baker

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".

3
therobyouknow

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 entre sí 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.

3
user8685

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 ...

3
Nitsan Wakart

El último proyecto profesional en el que trabajé fracasó. Una de las razones por las que creo que falló es una combinación de todas las otras respuestas (especialmente ninguna especificación escrita). Pero creo que la causa principal es la falta de toma de decisiones.

Yo era un desarrollador principal y le preguntaba a mi gerente cómo quería que funcionara alguna característica. Su respuesta es "necesitamos recopilar más información de clientes potenciales". Así que trabajé en un área diferente del proyecto. Eventualmente llegó a donde estaba reescribiendo los componentes para estar más limpio porque cada otra área del proyecto dependía de decisiones no tomadas. Cerca del final comencé a tomar decisiones por mí mismo. Me despidieron debido a que el proyecto fue destruido aproximadamente un mes después de que comencé a tomar decisiones.

Resumiré algunas cosas a tener en cuenta:

  1. Sin especificación escrita
  2. No se tomaron decisiones, o si se tomaron, solo se expresaron como "lo haremos de esta manera y lo volveremos a implementar más tarde de la manera correcta"
  3. Varios plazos vencidos
  4. Equipo sin experiencia o con poco personal (¡Este proyecto fue la primera vez que usé .Net, y sin embargo, fui un desarrollador principal!)
  5. Tener que trabajar en áreas ya completas porque otras áreas necesitan tomar decisiones antes de que el trabajo pueda comenzar. (por supuesto, estoy hablando de refactorización durante semanas solo para mantenerme ocupado)
  6. La idea de que alguna herramienta nueva ahorrará meses de tiempo de desarrollo
2
Earlz

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.

Bien, eso es un alivio!

Creo que no tener diariamente, útil supervisión administrativa es clave para detectar el deslizamiento. Creo que si tiene la información correcta, si logra que sus desarrolladores ingresen la información correcta, puede detectar el deslizamiento con bastante rapidez. Lo que hagas con eso después de eso, bueno, eso es más política y menos desarrollo ...

2
Tom Morgan

Hay muchos síntomas (agotamiento, horas extra, frustración, silencio ...) pero en última instancia, sabe que esto sucede cuando las fechas de lanzamiento comienzan a escasear y ya no puede entregar el producto tan a menudo como se supone que debe hacerlo.

1
Martin Wickman

Bueno, la mejor manera de responder esto es con un ejemplo:

Bob comienza un proyecto con una idea genial. Comienza creando un plan para el proyecto de software que comienza con pasos específicos que deben completarse. Sin embargo, los pasos no conducen al resultado final, sino que solo llegan a una parte del camino.

Al final, el proyecto falla porque los planes estaban incompletos. No es tanto falta de planificación como es planificación insuficiente.

0
Nathan Osman

Proyectos que están listos para la producción, pero se siguen agregando características.

Largo tiempo de desarrollo sin un claro compromiso de lanzamiento.

0
dukeofgaming

Un proyecto y proyectos futuros están condenados cuando la empresa decide escribir un "marco" interno porque todos los marcos disponibles no se ajustan perfectamente a sus necesidades.

0
Jeremy Heiler

Cuando la gerencia ha decidido, y no proporciona espacio para ajustes, en todo lo siguiente:

  • Fecha límite
  • Alcance
  • Recursos asignados
0
Pete