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

66

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?

ConroyP
fuente
Robert Glass escribió "Elixir universal y otros proyectos informáticos que fallaron". Publicado en 1977, el libro era una colección de columnas que había escrito anteriormente, cada una mirando un proyecto que falló, buscando las razones detrás del fracaso. El libro hace una EXCELENTE lista de señales de advertencia.
John R. Strohm
Dos artículos: Patología del proyecto y (el sobrevalorado) Informe del caos . Dale una buena lectura a Death March si buscas un libro.

Respuestas:

70

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.

Fishtoaster
fuente
12
La única excusa para tirar una noche entera es abordar un problema ESPECÍFICO para un plazo inflexible ESPECÍFICO. Tal vez soy solo yo, pero el código que escribo a las tres de la mañana cuando estoy gruñón y con falta de sueño tiende a parecer sangriento y horrible visto a la cruel luz del día.
BlairHippo
55
Bueno, la otra excusa es ser estudiante. La mala planificación del proyecto es normal para el curso entonces. :)
Fishtoaster
20
Oh cristo. Universidad. Recuerdo estar sentado frente a mi terminal cuando salió el sol, empujando *'s y &' más o menos al azar frente a las variables en mi código C ++ con la esperanza de que la maldita cosa comenzara a funcionar. No soy parte de la universidad que extraño.
BlairHippo
2
A principios de este año tuvimos un proyecto como ese: un tipo trabajaba regularmente hasta las 2 a.m. y yo comenzaba a las 4 a.m. Sin embargo, hicimos el trabajo, a pesar de las escalas de tiempo ridículas que se nos impusieron (nos habíamos comprometido a completarnos en un plazo legislativo). ¡Todavía estamos ordenando y refactorizando ahora!
Chris Buckett
3
Voy a poner mi karma en peligro aquí y señalar que la "codificación heroica" es un indicador tardío. Los proyectos se meten en problemas mucho antes de llegar a la fase en que comienza a producirse la "codificación heroica". Por lo general, hay muchos indicadores de problemas tempranos, que aparecen mucho antes de que la codificación comience en serio. Desafortunadamente, son ignorados con demasiada frecuencia. Robert Glass ha escrito extensamente sobre este tema, en "The Universal Elixir" y en otros libros. Ignóralo a tu propio riesgo.
John R. Strohm
44

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

revs JohnFx
fuente
9
¿No es esto solo un resumen de la infame reescritura de Netscape?
Jasarien
44
Estoy en desacuerdo. Hay ciertos peligros para las reescrituras (por ejemplo, el síndrome del segundo sistema), pero si sabe sobre esto, una reescritura no es más peligrosa que cualquier otro proyecto de campo verde.
nikie
44
A veces necesitas amputar y reemplazar con algo que hará que la aplicación sea más fuerte, mejor e inteligente. Pero la palabra clave allí es amputar, no matar y resucitar.
Erik Reppen
2
Esto puede ser en gran parte cierto, pero no estrictamente cierto. Me sometí a un proyecto de este tipo hace unos 9 meses, y fue un éxito. Pasé más de la mitad del tiempo diseñando pruebas para demostrar que era correcto y que los errores viejos / nuevos no se presentaron a la nueva versión, y mientras tanto encontraron un montón de errores nuevos en el existente. (Aunque, supongo, esto hace que esta respuesta sea verdadera como una señal de advertencia )
Izkata
41

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.

Fishtoaster
fuente
3
Una vez estuve en un proyecto que tenía dos bifurcaciones debido a dos interfaces: dispositivo de escritorio y dispositivo portátil. Las estimaciones de tiempo se basaron en la noción de que podríamos usar estas nuevas cosas brillantes "EJB" para reutilizar el código de capa de modelo entre los dos. Desafortunadamente, la base de datos era un nido de ratas tan horrible que todos los datos extraídos de ella tenían que proceder de consultas SQL específicas cuidadosamente construidas; poblar completamente los granos habría sido un golpe de rendimiento demasiado brutal. Cuando resultó que (¡sorpresa!) La versión de escritorio necesitaba más datos que la versión de mano, la línea de tiempo se fue directamente al infierno.
BlairHippo
2
"¡Maravilloso! ¡Ahora que hemos rescatado el marco de prueba de la unidad, podemos comenzar a reducir el tiempo de esa fase de control de calidad demasiado larga!"
Arkaaito
jajaja. Excelente. +1 para la nueva herramienta resolverá todos mis problemas.
rápidamente_ahora
40

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.

John MacIntyre
fuente
3
O peor, requisitos escritos que nadie lee. De hecho, he estado en proyectos donde se escribieron requisitos extensos y nunca se mostraron a los programadores.
JohnFx
1
@Adolf Garlic: los requisitos escritos no garantizarán su puntualidad o presupuesto, pero nunca cumplirá con las expectativas si las expectativas no se comunican, no tienen todas las áreas grises definidas y cambian constantemente (sus ideas mentales cambiarán )
John MacIntyre
55
Una vez tuve un analista de negocios que me dijo que no se necesitaban requisitos. ¿Cuál es el trabajo de un analista de negocios nuevamente? ¡Oh sí, para escribir requisitos! Obtendríamos requisitos como hacer que esto funcione como lo hace hkjk.com.
HLGEM
1
Si está desarrollando un producto personalizado para un solo cliente, seguro. Pero si está escribiendo la próxima versión de Powerpoint o la próxima versión de un sistema de software interno, no entiendo el punto. Siempre aprenderá más sobre los requisitos durante el desarrollo (por ejemplo, algunos requisitos no son útiles y otros no son viables). Prefiero usar ese conocimiento y cambiar los requisitos durante el desarrollo que lanzar un producto inferior.
nikie
1
@nikie: no digo que los requisitos sean estáticos y nunca cambien. Estoy diciendo que debe escribirlo para evitar la falta de comunicación y evitar que las ideas cambien en la cabeza de las personas con el tiempo. Si los requisitos cambian, cámbielos, pero mantenga los requisitos actuales por escrito. ¿Tiene sentido?
John MacIntyre
33

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.

Fishtoaster
fuente
+1 para tu primer artículo. He sido un cliente en el escenario que mencionas y es malo para todos (nadie quiere una factura inesperada y nadie quiere discutir sobre pagarla).
fearoffours
+1 amen. He estado allí, hecho eso, no me importa estar en esa posición nuevamente.
Evan Plaice
+1 por el hecho de que estoy viviendo con todas estas balas (excepto quizás la cuarta).
AShelly
Gran respuesta. Incluso si no se molestó en elaborar, y simplemente puso 'Desconexión de la administración', su respuesta hubiera valido un +10.
Jim G.
25
  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.

MrDatabase
fuente
24

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)

Mawg
fuente
8
¿Tienes una referencia para eso? sería una gran munición usar ...
Alex Feinman
1
Llámelo "La primera ley de gestión de software de
Mawg
1
@Alex Feinman: IIRC Code Complete contiene muchas referencias a estadísticas como estas.
nikie
21

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

Mawg
fuente
Gracias. Alwasy recuerda, puedes hacerlo rápido, barato o trabajando ... elige cualquiera de los dos
Mawg
21

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

adolf ajo
fuente
Nada hace que el alcance se desplace peor que las "características de concesión" porque el primer ministro se equivocó cuando configuró las fechas clave.
Evan Plaice
21

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.

HLGEM
fuente
Sí, las noticias mejoran a medida que avanza :)
Hans Westerbeek
18

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.

Walter
fuente
66
Una vez tuve un gerente que quería traer un codificador web front-end a un proyecto (la decisión correcta) pero debido a que alguien más en el proyecto se había enfermado a largo plazo quería recibir un golpe escrito en el contrato del nuevo tipo que no se le permitía enfermarse.
Jon Hopkins
1
@ Jon - Eso es triste ... divertido, pero muy triste!
Walter
16

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!

Gran maestro B
fuente
16

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.

usuario281377
fuente
1
Las tasas de rotación más altas que vi fueron en dos proyectos. Uno era un proyecto estable que continuaba y otro era un proyecto condenado conocido en un banco. Nunca he estado tan feliz de estar desempleado como esos dos.
David Thornley
13

Miembros aburridos del equipo.

Ashalynd
fuente
11

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

Scott Whitlock
fuente
2
Parece muy divertido ahora que lo dices. Sin embargo, me pasó a mí. No fue divertido en ese momento.
+1000 sucede donde trabajo todo el tiempo T_T
Songo
1
Es curioso cómo cada programa tiene pruebas como último paso, como si las pruebas no encontraran ningún error. Si no, ¿por qué molestarse con las pruebas?
JohnFx
No se preocupe, "el cliente lo probará por nosotros" :-(
Mawg
10
  • 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 ).

Jon Hopkins
fuente
+1 para "Su orgullo sigue siendo el acto de enviar en lugar de lo que está enviando". Eso es tan cierto (aunque solo vi eso en mis gerentes. Los desarrolladores sabíamos qué salió por la puerta ... pies primero)
10

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

rev. Mawg
fuente
¿Qué es un codificador de vaquero?
Creative Magic
Wikipedia es tu amigo es.wikipedia.org/wiki/Cowboy_coding
Mawg
No sabía que era un término, ¡gracias! Bien, me dirijo a mi rancho ...
Creative Magic
9

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.

revs ChrisF
fuente
66
No hay nada de malo con la cascada cuando se usa correctamente. Desafortunadamente, nunca se usa correctamente :)
Adolf ajo
@adolf - Estaba pensando en un solo paso a través de la cascada. Múltiples mini cascadas probablemente estén bien.
ChrisF
OMI, Agile es solo una serie de cascadas. Muy pocos pueden hacer la cascada correctamente, ergo ..
Mawg
@mawg: mi punto era que una única iteración larga era mala, mientras que una serie de iteraciones cortas (sin embargo, se manejan) es mejor.
ChrisF
1
Me recuerda a un proyecto que desarrolla cosas electrónicas donde no hay prototipos programados en ... Una señal segura de un desastre inminente.
rápidamente_ahora
9

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.
MagicAndi
fuente
8

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.

Evan Plaice
fuente
8

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.

HLGEM
fuente
2
La patada en su primer párrafo es que, si la gerencia está haciendo eso, los plazos probablemente ya estén condenados y las bonificaciones inalcanzables.
David Thornley
1
@David Thornley, sí, eso es exactamente.
HLGEM
6

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.

Jaco Pretorius
fuente
1
también conocido como "definición de hecho", según lo acordado tanto por TI como por el negocio
adolf ajo
6

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.
Bob Murphy
fuente
Te daría un millón por ese último punto.
HLGEM
5

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.

Vaccano
fuente
5

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.
Chris Smith
fuente
4

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.

Jason Baker
fuente
Lolx! Tan verdadero; la reunión "puede que hayas escuchado rumo (u) rs ...".
Mawg
4

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.
OKAN
fuente
3

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.


fuente
LOL, trabajé en un estudio de mano de obra así, aunque aún peor, ya que los dos protagonistas estaban tratando de tener una aventura con la misma mujer. Si Bill dijo que sí, entonces Bob dijo que no y viceversa, el peor proyecto en el que he trabajado. Rogué que me reasignaran.
HLGEM
3

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

therobyouknow
fuente
¡Buen artículo! Me gusta el enfoque "cuando las cosas van bien".
user8865
3

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

Nitsan Wakart
fuente
1
Creo que es una estadística de inicio, no necesariamente una estadística general de proyecto de software.
Erik Reppen
2
Aquí hay una referencia buscada en Google al azar que parece sugerir que no se limita a las nuevas empresas. Vea también el excelente desarrollo rápido del Sr. McConnel para obtener más gemas sobre el tema.
Nitsan Wakart