Soy desarrollador en un equipo de 5 miembros y creo que nuestro proyecto se dirige al desastre. Describiré por qué en un momento, pero mi pregunta es: ¿cómo debo comportarme?

La fecha límite es de 1,5 meses, y creo que no importa lo que hagamos, este proyecto fallará. Soy de la opinión de que deberíamos terminar el proyecto y dejar de perder el tiempo, pero políticamente creo que es imposible que nuestro gerente lo haga.

¿Qué debo hacer en este caso? ¿Debería poner un esfuerzo extra, o debería tomarlo con calma? ¿Y qué debo decirle al gerente?

Razones por las que este proyecto se dirige al fracaso:

• Cuando se acerca la fecha límite, muchas de las funciones imprescindibles no están terminadas
• La aplicación es inestable y muy difícil de usar.
• El sistema es muy complicado, el código es muy difícil de entender, muy difícil de cambiar: el modelo de datos está demasiado impulsado por una base de datos relacional compleja (más de 100 tablas)
• Liderazgo poco claro; el gerente responde a la nueva información con cambios importantes
• Casi no hay pruebas automatizadas o pruebas unitarias
• Depende en gran medida de otros sistemas, pero aún no hay pruebas de integración

De hecho, en realidad acabamos de heredar este proyecto (junto con el desorden) hace aproximadamente 1-2 meses de otro equipo de desarrollo bajo el mismo gerente, que ha trabajado en él durante unos meses.

Comunique sus inquietudes de la manera más concisa y sin confrontaciones posible en la escala administrativa. Resuma los riesgos, pero no imponga su conclusión sobre ellos.

La gerencia siempre debe tener la opción de qué hacer, pero es su trabajo evaluar y comunicar la situación. Use el correo electrónico para dejar un rastro de papel cuando las cosas se van al sur.

Una vez hecho esto, siga trabajando en el proyecto de buena fe.

Tenga en cuenta que es posible que no sepa todo lo que hay que saber sobre el proyecto, sus patrocinadores y las decisiones financieras que lo respaldan. Las decisiones de gestión que le parecen estúpidas en realidad podrían basarse en un razonamiento inteligente que no es visible para usted.

Mantenga un rastro de papel (por ejemplo, diario, correos electrónicos guardados, etc.). Solo incluya hechos y observaciones objetivas . Deje todas las conclusiones a quien (si alguien) lee lo que ha escrito.

Como desarrollador, si no se lo ve como un obstáculo para el proyecto, es probable que salga bien de señalar con el dedo que sin duda sucederá. Es posible que su gerente no tenga tanta suerte, pero eso no es relevante aquí.

Solo por principios generales, actualice su currículum y asegúrese de reunirse ocasionalmente con otros desarrolladores fuera de su empresa. Si no eres parte de ningún grupo de desarrolladores locales, únete a 2 o 3. Lleva años construir una red de amigos y conocidos, pero a la larga vale la pena. Asegúrese de verlo como una calle de doble sentido: si puede ayudar a llenar una vacante en su empresa con alguien capaz, eso es tan bueno como alguien que lo ayude a encontrar un trabajo.

Voy a recomendar que te tomes un poco de tiempo para leer 2 libros.

Death March es el libro canónico que describe un estilo de gestión de proyectos patológicos que está muy extendido en el desarrollo de software. Debido a la compresión del cronograma, la hinchazón de funciones o la mala administración, muchos proyectos terminan en mal estado; ayuda a entender que no estás solo y que tu proyecto no es la única marcha de la muerte. El autor Edward Yourdon clasifica los proyectos sin salida en 4 cuadrantes, cada uno de los cuales tiene diferentes estrategias de afrontamiento. A veces, la única estrategia de afrontamiento es alejarse. Creo que este libro te ayudará a descubrir cuál es tu rango de opciones y a reducir lo que puedes y no puedes hacer.

Desenredamiento de catástrofes se escribe más para los gerentes de proyecto. Su objetivo es descubrir cómo clasificar un proyecto roto: ¿Qué se debe cortar, qué se puede recortar y cómo presentarlo a los clientes? La gestión de proyectos de software "convencional" nos lleva a proyectos desordenados, y no escaparemos de nuestros problemas utilizando el mismo pensamiento que nos metió en ellos en primer lugar. Este libro es un poco más difícil de leer que Death March , pero es bueno tenerlo en su estantería.

3 estrategias simples y cínicas para mantener la carrera / cordura.

1. Vea cómo se produce un choque de trenes: baje del tren: los proyectos fallidos son terribles para la moral y, a menos que tenga habilidades de administración ascendente ninja, tendrá un impacto negativo en su carrera. Salta ahora si puedes ver algún aterrizaje suave.

2. Si eso no funciona, mantén la cabeza baja: las personas comenzarán a buscar personas a las que culpar, ¡no lo hagas fácil! Si bien las crecientes preocupaciones en la cadena de administración podrían ser lo correcto, son ineficaces y riesgosas. Es poco probable que su propio gerente transmita sus preocupaciones y eludirlo no solo hará que ambos se vean mal, sino que podría calificarlo como un 'alborotador', es decir, el tipo de persona a la que se puede culpar por socavar el proyecto en primer lugar, etc. Esto, por supuesto, también significa ser profesional, dedicar tus horas pero no heroicidades.

3. Planifique una salida de emergencia en T + 1: tenga algunas opciones y haga las bases para una posible transferencia interna o externa ahora. Hablar con las personas; no hay razón para esperar a que otros decidan qué hacer con usted cuando los fondos del proyecto se reducen o se ven envueltos en la inevitable "estampida" de las personas que emigran en un par de meses.

Disculpas si suena demasiado cínico, pero si lo has llamado correctamente, entonces no hay ninguna ventaja en sufrir las molestias que se te presenten. Sea profesional, sea optimista pero siempre sea realista.

¿Qué impacto tendrá este proyecto que pronto fracasará en su carrera en la empresa y más allá? En mi experiencia, el simple hecho de estar asociado con proyectos exitosos no es un indicador de su propia excelencia personal.

Las cualidades que exhibes frente a la adversidad y, a veces, lo que parece ser un cierto fracaso, a menudo son notadas por los superiores, más de lo que piensas. Y estoy hablando más allá de su gerente inmediato.

Personalmente, he experimentado que mi gerente inmediato fue despedido por incompetencia, y luego me encontré ascendido a su puesto el mismo día. No es agradable, pero mostró que la gente me estaba mirando y me gustó lo que hice.

A menudo, el mismo caos y desorganización que viene con un proyecto fallido, le brinda la oportunidad de brillar.

Así que mire el proyecto de esta manera: ¿qué oportunidad ofrece este proyecto fallido para que la luz brille en todas mis fortalezas y mejores cualidades? ¿Qué lecciones estoy aprendiendo de esta experiencia, que me harán un mejor profesional y una mejor persona?

Esencialmente, la suma de experiencias extraídas de los fracasos es lo que alimenta el verdadero éxito.

Nota: Thomas Owens preguntó qué cosas específicas puede hacer una persona en un proyecto como este. Tengo algunas sugerencias generales, que he utilizado como pautas personales en estas situaciones. ¿Ayudará a un proyecto de socorro a tener éxito milagrosamente? No, pero he descubierto que me ha ayudado a mantener una perspectiva adecuada de las cosas y a encontrar el éxito personal a pesar de la mala situación.

1) Centrarse en la excelencia personal: esforzarse por escribir un código cada vez mejor, cumplir con estándares cada vez más altos de calidad y funcionalidad.

2) Céntrate en las métricas personales: ¿cuánto código escribes para generar errores posteriores? Reduce esa proporción lo más bajo que puedas. Cuando se le pide que proporcione una estimación de una tarea que se le asignó, ¿es generalmente exacto o considera que ha sobrecargado / insuficiente la línea de tiempo? Cuando realmente se le asigna una tarea, ¿proporciona un buen nivel de retroalimentación sobre la progresión del trabajo, incluida la notificación anticipada de los problemas de la línea de tiempo?

3) Concéntrese en las métricas del equipo: estas son solo algunas cosas fuera de mi alcance: ¿Están otros miembros del equipo rezagados debido a la dependencia de una tarea en la que está trabajando? ¿Eres bueno para delegar o dividir tu tarea / subtareas a otros en el equipo? ¿Le resulta difícil comunicarse con uno o más miembros del equipo? Todas las áreas en las que trabajo para mejorar regularmente.

En una situación como esta, como el peldaño más bajo de la escalera, solo hay mucho que puede hacer para ayudar al proyecto.

• Asegúrate de que tu trabajo esté impecable
• ayudar a identificar las áreas problemáticas más grandes
• Intenta proporcionar respuestas, no solo problemas. Parece que estás tratando de arreglarlos.

Aparte de eso, realmente tienes que cuidar el número 1.

• Documenta todo
• mantener todos los correos electrónicos, conversaciones de mensajería instantánea
• Intenta encontrar una salida al proyecto si es posible

Los proyectos fallidos pueden ser tóxicos para el alma, causar depresión, exceso de trabajo y baja autoestima.

Todo es relativo a la perspectiva.

He trabajado en proyectos horribles mientras estaba sentado frente a otro chico que tenía una sonrisa en su rostro todos los días. Oh, cómo quería quitar esa sonrisa de su rostro.

Algunas personas no se molestan por el estado actual de las cosas en un proyecto. Disfrutan de su contribución, sus tareas y están trabajando en el dominio de sus intereses. Mientras que otros, tienen una fuerte reacción negativa al estado actual de las cosas. Se trata de nuestras expectativas percibidas para nuestros trabajos diarios.

Si bien es posible que estés haciendo parte del trabajo que disfrutas. Hay claramente elementos en el proyecto actual que no le gustan.

Debe identificar cuáles son esos elementos problemáticos y abordarlos.

• presión de plazo
• control de calidad
• profesionalismo
• orientación por parte de la gerencia

Hay muchos equipos y empresas que no consideran importantes los aspectos anteriores del desarrollo. Lo que he encontrado es que a menudo piensan lo siguiente.

• La presión del plazo se percibe como una forma de motivar a las personas.
• La calidad cuesta más y el límite de devoluciones.
• La profesionalidad se aplica a otras áreas del negocio.
• Un gerente es un cronometrador y no una persona que contribuye al desarrollo.

Estos problemas no son tuyos. Es de ellos, y no debes desperdiciar energía sobre su comportamiento. Si no eres uno de los tipos que sonríe y disfruta de su trabajo incluso cuando se dirige a un acantilado, entonces debes pensar en encontrar un lugar para like mindeddesarrolladores.

Estarás mucho más feliz.

Trate de ser proactivo para encontrar una nueva forma de lograr el éxito del proyecto. Piensa en cómo puedes proponer algunas alternativas. En este momento, su jefe probablemente está siendo golpeado por el fracaso del proyecto, ¿no le gustaría que alguien viniera con soluciones en lugar de problemas?

¿Quizás haya una manera de dividir las características en entregas escalonadas? A menudo hay grados de "must have", así que vea si puede obtener esos priorizados y agrúpelos en hitos. Es mejor tener algún producto al final de la línea de tiempo que nada. O considere dividir el equipo entre personas que trabajan en una nueva funcionalidad y otras que trabajan en la estabilidad, de esta manera puede mostrar cierto progreso en ambos frentes.

Si estos esfuerzos tienen éxito, habrás demostrado que eres un miembro del equipo que puede encontrar una manera de tener éxito; de lo contrario, habrás demostrado que no te rindes y trabajarás para encontrar una solución.

Suena como la mayoría de los proyectos en los que he estado. Sin embargo, probablemente no terminará tan mal como crees:

1) Haz tu trabajo. No se preocupe tanto por el proyecto en general siempre que complete sus responsabilidades.

2) CYA. Si el proyecto falla y sospecha que el gerente comenzará a culpar a todos menos a sí mismo, asegúrese de tener pruebas suficientes de que hizo todo lo que se le exigió (consulte el elemento 1).

3) Haga algunas sugerencias educadas para mejorar. No hagas sonar las campanas de advertencia, no seas pesimista, solo sé cortés y sutil.

Por ejemplo, si el equipo no está escribiendo pruebas unitarias efectivas (o cualquier prueba), escriba algunas pruebas unitarias más cercanas a lo que le gustaría ver y mencione causalmente cómo hacerlo lo ayudó a resolver un problema en particular o le ahorró tiempo.

Sea lo que sea, si quieres afectar el cambio, enfócate en los pasos positivos que tienen resultados concretos. Es posible que este proyecto nunca resulte ganador, pero tal vez el equipo pueda aprender para el próximo.

También:

4) La refactorización oportunista es tu amiga.

1. Trabaja duro; pero no a expensas de su familia o su salud.
2. Mantenga un registro de todas las decisiones críticas de diseño; especialmente en lo que respecta a su trabajo.
3. Mantenga las redes y mantenga abiertas sus opciones si la situación se vuelve demasiado difícil o si se convierte en víctima de un despido masivo.
4. Trate de no pensar en su proyecto como un "proyecto fallido". A todos les gustan las personas que se mantienen positivas y luchan duro ante la adversidad. Así que por el mayor tiempo posible, trata de ser esa persona. Una perspectiva positiva, determinación y determinación son siempre buenas para el lugar de trabajo.
5. Si está anticipando un proyecto fallido, está anticipando una reunión post mortem. En la reunión post-mortem, todos tendrán que rendir cuentas. Prepárate para defender todo tu código. [Nota: Como regla general, siempre debe escribir código limpio para que sea fácil defenderlo más tarde.] Si tiene un correo electrónico o un documento de diseño que inspiró sus decisiones, entonces eso es aún mejor.
6. En esa reunión post mortem, trate de mantenerse positivo; y solo presente su correo electrónico y evidencia de documento de diseño si su juicio, esfuerzo o mano de obra es cuestionado.

Lo que he encontrado más efectivo es la recomendación de Robert L. Read sobre cómo combatir la presión del horario . Esto es lo que lee escribe:

La clave para luchar contra la presión del cronograma es simplemente convertirlo en presión de tiempo de comercialización. La forma de hacerlo es dar visibilidad a la relación entre la mano de obra disponible y el producto. Producir una estimación honesta, detallada y, sobre todo, comprensible de todo el trabajo involucrado es la mejor manera de hacerlo. Tiene la ventaja adicional de permitir que se tomen buenas decisiones de gestión sobre posibles compensaciones de funcionalidad.

La idea clave que la estimación debe dejar en claro es que el trabajo es un fluido casi incompresible. No puede empacar más en un lapso de tiempo más de lo que puede empacar más agua en un recipiente por encima del volumen de ese recipiente. En cierto sentido, un programador nunca debe decir 'no', sino más bien decir '¿Qué renunciarás para conseguir lo que quieres?' El efecto de producir estimaciones claras será aumentar el respeto por los programadores. Así se comportan otros profesionales. El trabajo duro de los programadores será visible. Establecer un horario poco realista también será dolorosamente obvio para todos. Los programadores no pueden ser engañados. Es irrespetuoso y desmoralizador pedirles que hagan algo poco realista.

Cuando dice que el proyecto "se dirige al fracaso", eso se basa en su evaluación de las tareas que deben realizarse y cuánto esfuerzo requerirá cada una de ellas. Haga que la evaluación sea explícita , comprensible y detallada . Separe las tareas en sus componentes; explique con el mayor detalle posible cómo se empleará el tiempo de desarrollo.

Una vez que haga eso, tendrá una base sólida para discutir las inquietudes con la gerencia. Con toda probabilidad, una vez que haya desglosado su evaluación en todas las tareas específicas que deben completarse, podrá demostrar que el trabajo lleva más tiempo del que tiene, posiblemente mucho, mucho más.

Una vez que esté discutiendo este cronograma detallado con su gerente, prepárese para ser flexible. Su gerente podría decir "La Tarea X no tomará un mes; tomará una semana como máximo" o "La Tarea Y es completamente innecesaria, elimine eso del cronograma". Ciertamente puede discutir estos puntos, pero lo que es mucho más importante es llegar a un entendimiento entre usted y su gerente sobre alguna versión realista de un cronograma. De esa manera, si no se le asigna tiempo para, por ejemplo, realizar pruebas, entonces tiene una directiva explícita de no realizar pruebas, en lugar de quedarse sin tiempo "inesperadamente". Y definitivamente es posible que su gerente esté legítimamente dispuesto a cortar explícitamente ciertas esquinas para enviar a tiempo: hay muchos casos en los que eso '

La estimación le da sustancia concreta para debatir y debatir. Te pone en la misma página; Le ayuda a sentirse seguro de que su gerente ha tenido en cuenta sus preocupaciones. Y lo lleva al punto en que si su gerente le pregunta claramente lo imposible, será perfectamente evidente para ambos. Si el proyecto está bien y realmente condenado, lo habrá dejado en claro, y le corresponderá a su gerente decidir con precisión cómo quiere que pase su tiempo.

Como su gerente sabe que probablemente fallará, está mejor que la mayoría. Consideraría trabajar con el administrador y ver si hay partes / características de la aplicación que puedan excluirse.

Con demasiada frecuencia pensamos que cada solicitud de un cliente es un "asesino de ofertas" y hacemos todo lo posible para prometer la entrega. Hasta que alguien trabaje con el cliente y pruebe más profundamente, es posible que no pueda tomar estas decisiones. Si no puede hacer esto, intente entregar lo que cree que es más importante. A veces es más fácil pedir perdón que permiso.

Participé en tres proyectos que fueron un claro fracaso. Estos fueron bastante dolorosos, pero mirando hacia atrás, dos de tres no tuvieron consecuencias negativas en mi carrera, e incluso el tercero no fue el fin del mundo.

Aquí hay algunas observaciones que recuerdo.

Los desarrolladores en posiciones junior ("código por especificación", "arreglar el error", cosas así) no se ven afectados mucho, a menos que se relajen debido a la baja moral del equipo. En posiciones como estas, una estrategia de supervivencia sensata e incluso a veces exitosa podría estar haciendo lo mejor que pueda.

• ^{Por ejemplo, una de las fallas que experimenté fue superada por la solución simple y metódica de más de cien errores conocidos que (junto con un enfoque particularmente inteligente de promover este progreso por parte del líder tecnológico) eventualmente llevaron a la alta gerencia a la decisión de recuperar el proyecto y dar Es otra oportunidad con un nuevo lanzamiento, que a su vez tuvo un éxito razonable.}

Los programadores en puestos más importantes e influyentes estarían mejor preparados para compartir las consecuencias negativas del fracaso del proyecto. Por lo general, se espera que un arquitecto, líder tecnológico, desarrollador senior tenga un impacto lo suficientemente grande como para ser considerado responsable del éxito o el fracaso del proyecto.

En el puesto superior, uno estaría mejor preparado para ganar "indirectamente", analizando qué salió mal y qué podría haberse hecho mejor.

Estos fragmentos de conocimiento, las lecciones post-mortem pueden ser invaluables si se aprenden bien, la carrera exitosa en puestos de alto nivel puede depender de qué tan bien se aprendan, como se explica en esta brillante respuesta en WP :

El juicio no proviene del éxito, sino de los fracasos. La mayoría de las empresas quieren contratar personas que hayan tenido sus fallas pagadas por compañías anteriores ...

En una nota más práctica, uno puede considerar el enfoque de "próximo / lanzamiento de actualización" como una posible forma de salir de la falla. Casualmente o no (creo que no ), pero las dos fallas que no dañaron mi carrera pasaron por escenarios muy similares: la liberación Nfue un desastre total, la liberación N+1fue tolerable, las liberaciones N+2y más tarde fueron un éxito total.

Caminando en sus zapatos, probablemente pondría algo de esfuerzo en preparar / promover la idea del "próximo lanzamiento". Haga (¡y comuníquese !) Algo así como una lista tentativa de problemas conocidos que desearía solucionar después del lanzamiento planificado. Redacte una hoja de ruta informal y aproximada para la próxima versión.

Piense en cómo podría comunicar estas ideas a las personas que lo rodean, cómo podría influir en la administración para considerar este plan. Si el proyecto tiene a alguien con buenas habilidades de mercadotecnia, intente involucrarlo en la amortización del daño por falla al concluir la próxima versión en términos más suaves, como "acceso temprano", "beta", "vista previa del cliente", "versión introductoria", cosas como ese.

Piense en un plan de respaldo en caso de que los superiores parezcan sordos a esta idea. ¿Recuerdas la historia anterior sobre "la corrección de más de cien errores conocidos"? existe la posibilidad de que las cosas cambien, de verdad.

La administración puede parecer sorda a las ideas del próximo lanzamiento ahora, pero hay una buena oportunidad para que reconsideren ante una fuerte evidencia convincente de progreso en la calidad del proyecto.

• ^{Es bastante probable que haya transcurrido bastante tiempo entre el congelamiento del código para la publicación planificada y la decisión de la administración de abandonarlo por completo. Ese momento es su oportunidad: si enfoca el esfuerzo en solucionar problemas conocidos y "evangelizar" adecuadamente el progreso, esto podría marcar la diferencia (como alguna vez lo hizo para mí).}

Aquí hay montones de consejos prácticos (y de otro tipo), pero para mí las claves de este misterio son los siguientes dos elementos (énfasis mío):

La fecha límite es en 1,5 meses.

y

... en realidad acabamos de heredar este proyecto (junto con el desorden) hace aproximadamente 1-2 meses de otro equipo de desarrollo bajo el mismo administrador ...

Entonces....

Bienvenido al equipo Patsy The Avengers

El equipo anterior tenía mejores cosas que hacer ... que fallar. Y de alguna manera el gerente estuvo de acuerdo con eso. Cambiar de equipo tan cerca de la fecha límite no es el mejor movimiento de gestión de proyectos, así que ... ¿qué pasa con eso?

Corrección: El equipo anterior fue reemplazado, ~ 3 meses antes de la fecha límite.

-> Descubre cómo el equipo de desarrollo anterior logró escapar, y hazlo. <-

3 meses es apenas tiempo suficiente para acelerar un sistema de este tamaño aparente, mucho menos corregir su arquitectura, agregar pruebas y finalizarlo. Necesitas mas tiempo

Y si no puede hacer eso, a menos que esté absolutamente seguro de que el proyecto se extenderá indefinidamente, o con la ayuda de elfos mágicos o algo así, no querrá ser el último hombre que quede de pie sosteniendo la bolsa.

¿Duro? Si. Pero si bien la mala planificación (¡al menos!) Por parte de los equipos / gerentes anteriores no es su culpa, la 'falla en la entrega' sí lo será .

El equipo anterior abandonó . El equipo anterior fue pateado a la acera. ¿Qué te dice eso? Me dice que usted es el equipo de recuperación ... y su gerente cuenta con sus heroicidades para salvar el día.

Un equipo de 5 personas y 1.5 meses para el final. El nuevo equipo solo ha tenido el proyecto durante 1-2 meses, por lo que el nuevo equipo ni siquiera ha superado la curva de aprendizaje . Adivinando el tamaño de este proyecto, me parece que no hay forma de que el nuevo equipo haya superado la curva de aprendizaje, incluso si el proyecto no tuviera ningún problema.

Entonces, (todavía) creo que has sido engañado.

Si ese es el caso, y solo usted puede decidir qué es verdad o qué quiere creer, no le debe a nadie una explicación o una disculpa por salirse del camino de este choque de trenes. Sin embargo, debes ser discreto al respecto.

Dudo seriamente que el gerente no sepa que el proyecto está en peligro, lo que significa que las explicaciones suaves no le darán más que atención negativa. A menos que su gerente sea el Sr. Rogers , su futuro está en peligro.

Pero recuerde siempre : no tome consejos profesionales de extraños en Internet.

¡Esta es una oportunidad increíble para ti! Tomemos un punto de vista empresarial sobre esto.

Asumiendo que la gerencia quiere que este proyecto tenga éxito, usted está en una excelente posición para ayudarlos a hacerlo. La razón por la que esta comprensión es tan importante es porque debe desarrollar la convicción y la confianza de que las señales de advertencia que está viendo realmente conducirán al fracaso de este proyecto [1].

Esta es tu oportunidad de practicar habilidades importantes en el pensamiento sistemático y la comunicación interpersonal. Comprenda y visualice los problemas y las oportunidades potenciales que se están perdiendo para que pueda desarrollar una estrategia para comunicarlos de la manera más clara y simple posible.

Reconoce tu oportunidad aquí para mejorar tus habilidades.

[1] Cancelar el proyecto en realidad sería un éxito. El fracaso sería gastar dinero bueno después del malo.

Qué puedes hacer

• Trate esto en sus propios términos de excelencia, es "su" proyecto, pero también el suyo, tome posesión aunque sepa que fracasará. ¿Por qué? porque a) puede ayudarlo a fallar un poco menos, b) en el momento del desafío, aquí es donde aprende más c) debe medirse a través de sus propias métricas de excelencia, hacer lo mejor que pueda no salvará el proyecto, pero usted podría terminar todavía orgulloso de ti mismo

• Hable con otros desarrolladores y vea lo que piensan, probablemente descubrirá que muchos comparten la misma frustración, si se hace con cuidado (no haga que la gente piense que quiere comenzar un motín o algo así), esto puede ayudarlo no solo a usted, sino a usted. otros también

• Ignorar el problema no va a hacer que desaparezca, hablar sobre formas de superarlo, contra todo pronóstico, por ejemplo, al menos conseguir algunos elementos imprescindibles decentes, o el caso de uso principal del "factor sorpresa" bien hecho, podría hacer esto proyecto fallar menos miserablemente. ¿Cómo hacerlo? bueno, pocas ideas de "cuando ponerse duro se pone difícil" o "los tiempos desesperados justifican medidas desesperadas" y otros clichés, por ejemplo: uso masivo de OSS, programación extrema / metodologías ágiles, hackatones de fin de semana (solo voluntarios, sin obligar a las personas a fines de semana de trabajo). Este es el momento en el que puedes mostrar liderazgo (con cuidado si no estás en una posición de liderazgo / alto nivel de equipo) pero puedes aprovechar esta ventaja y convertirte en su sinsajo, solo haz que la gente sienta que podría obtener este proyecto un poco menos que Todos lo saben.

• Asegúrese de que su gerencia lo sepa, pero muy, muy cuidadosamente, si lo saben, apreciarán que les diga esto de una manera tranquila y sin confrontaciones, si no lo hacen, lo apreciarán aún más, y se preguntarán por qué nadie lo dijo ellos al respecto antes. Debe decirles esto como un servicio, sin ningún lado emocional, solo hechos claros y sin una agenda. Si le preguntan qué cree que deberían hacer (lo cual es una gran señal, pero rara), consulte la siguiente sección

Lo que no puede hacer, pero su gerencia probablemente debería

• No deberían agregar más personas al proyecto "para ayudar" a ver esto

• Llame al cliente de inmediato y cuéntele las malas noticias. ¿Por qué es una buena idea? bueno, me iré citando el manifiesto para el desarrollo ágil de software, pero incluso sin él, incluso los amantes de las caídas de agua odian las malas sorpresas. Si el cliente sabe de antemano que este proyecto está condenado al fracaso, será infeliz, pero será mucho más feliz que les diga que hay problemas antes de que se les ocurra, y que está en ello y haciendo todo lo posible para adaptarse eso. El cliente puede hacer muchas cosas, pero la mayoría de ellas no son peores que descubrir en el último minuto que no tienen una entrega (o lo hacen pero es de una calidad no utilizable). El cliente lo apreciará, ya que podrá retrasar la contratación de personal de pruebas, personal de TI en alta mar, cambiar sus planes de capacitación internos y todo solo porque fue honesto con ellos.

• con el cliente, piense en maneras de hacer algo del proyecto, la más común es descorazonar cosas. por ejemplo, puede haber algunas características que son demasiado difíciles de desarrollar de la forma en que fueron diseñadas, y si el cliente acepta algunas pequeñas modificaciones y simplificaciones, algunas características se volverán más simples.

• Actualice su propia alta gerencia, también les ayudará a mantener su trabajo ...

Lo que NO debes hacer

• Solicite agregar más personas al proyecto (vea esto )

• Salga / busque otro trabajo (al menos todavía no), esto es algo de lo que puede aprender y lo que algún día lo convertirá en un mejor desarrollador o mejor administrador. Aprenderá a apreciar mejor muchas cosas, a administrar mejor el tiempo, a diseñar mejor, a escribir mejor el código y a trabajar mejor con sus pares y la administración. Busque un trabajo después de que hayan terminado estos 2 meses si no le gusta trabajar allí, no por ningún otro motivo.

• Quejarse, quejarse o ser negativo sobre el proyecto, la administración, el mal diseño que heredó, los desarrolladores novatos a los que debe orientar que le lleva 3 horas explicarles que hagan algo que le lleva 1 hora, sea tan positivo como usted puede.

• Critique a la gerencia y conviértase en un objetivo como creador de problemas, están en el mismo barco y pueden saber cosas que usted no sabe, todo lo que puede hacer es actualizarlas (siempre actualice su propio gerente directo, nunca lo omita)

• Culpa a la gente (o a ti mismo), no ayuda, nunca

• Tómelo demasiado en serio, a menos que sea un equipo médico, es probable que nadie muera si no cumple con los plazos, es un software, no cumplimos con los plazos para vivir, relájese.

Eso es solo mis dos centavos, YMMV

Encuentre los problemas con los que se enfrenta su proyecto e intente cuantificarlos de la manera más objetiva posible. Con cada "métrica" ​​que cuantifique, asegúrese de definir por qué cree que esta métrica es importante. Desea darle a su gerente una idea de cuáles serían las consecuencias si una determinada métrica no estuviera dentro del "rango aceptable". Deberá proporcionar algunas pautas para cada métrica para indicar qué valores son "Bueno", "Aceptable", "Problemático" o "Malo". Defina cada criterio por adelantado. Si es posible, podría describir lo que se necesitaría mínimamente para que un proyecto tenga éxito y contrastar esto con el proyecto actual.

• La calidad del código estático se puede cuantificar mediante muchas herramientas de análisis estático. Puede mantener esto tan simple o detallado como mejor le parezca. Las métricas que sugiero que comience con:
  • Complejidad Ciclomática
  • Tamaño de su código (por ejemplo, número de líneas por función / clase, número de archivos, número de tablas ...)
  • Identificar qué módulos son demasiado grandes.
  • Duplicación.
  • Adherencia al estilo de código
• Tasa de defectos
  • por KLOC por módulo y / o subsistema (identifique partes problemáticas de su sistema)
  • podrías calcular cuánto por miembro del equipo, pero creo que deberías guardarlo para ti
  • resuelto vs encontrado
  • tiempo necesario para resolver un error (tal vez si esto es inclinable haga un gráfico de esto)
  • quizás haga una estimación de cuánto tiempo se necesita si esto continúa al ritmo actual
• Planificación
  • Tiempo extrapolado utilizado para las características integradas. Tener en cuenta la complejidad de la función. Esto no tiene que ser muy preciso. Lo que desea transmitir con esto sería lo siguiente: "Las características A, B y C tienen la misma complejidad que D, E y F. Con las características ABC se utiliza el 170% si el tiempo planificado. Si nada cambia, esperamos lo mismo se necesita tiempo para DEF "o en la línea de" La función promedio tarda X% más de lo calculado. No tenemos ninguna razón para suponer que el resto de la funcionalidad es más fácil de construir, por lo que debemos compensar esto en la planificación futura No sirve de nada tener una planificación si no es realista.
  • Trate de tener un calendario de lanzamiento mensual o preferiblemente incluso más corto. Si solo interno. Esto podría ayudarlo a extrapolar el tiempo que necesita para el proyecto. Esto también podría salvarlo de hacer compromisos poco realistas (si no se compromete a un nuevo trabajo antes de que se realice un lanzamiento). Haga una planificación para cada ciclo y asegúrese de que las nuevas características solo entren en el siguiente ciclo (es decir, nunca se pueden agregar al ciclo actual).
• Cobertura de prueba: explique los valores de cobertura de prueba "normales" y muestre cómo es su cobertura actual
• Documentación: ¿Cuánto% está realmente documentado? ¿Que bien?
• Modularidad:
  • Basado en clase (acoplamiento y cohesión)
  • Paquete basado
  • Basado en subsistema (¿cuántas rutas de comunicación hay?)

Debe ir a trabajar y hacer lo que haría en cualquier proyecto, ya sea que tenga éxito o no. Le pagan para realizar su trabajo. Hazlo lo mejor que puedas. Asumiendo que usted no es el gerente / líder del proyecto, no es su responsabilidad decidir si un programa debe ser cancelado o no. Decidir aflojar es lo mismo que tomar la decisión de cancelar el proyecto. Eso no es parte de la descripción de tu trabajo.

Sin embargo, en el panorama general, eso no significa que deba trabajar 50, 60 o más horas por semana para tratar de cumplir con el cronograma. Una vez más, ese es el trabajo de la gerencia para descubrir cómo lograr los objetivos del proyecto. Más de 50 horas semanales de trabajo no es una opción razonable a menos que estén dispuestos a pagar horas extras y usted esté dispuesto a poner su vida familiar en espera. Una vez más, era el trabajo de la gerencia elaborar un cronograma alcanzable. No pueden asumir que pueden obligar a los empleados a ignorar su vida familiar para cumplir con horarios poco realistas.

Además, aunque el horario puede decir 1 1/2 meses restantes. Esa probablemente no sea la fecha de "caída". Algunos clientes pueden tomar lo que tienes para esa fecha, incluso si no es todo. Algunos clientes pueden aportar fondos adicionales, ya que ya han invertido mucho dinero en el proyecto. A veces, la propia empresa puede asumir los costos adicionales para garantizar un cliente satisfecho. Todo eso está fuera de tu control. Haz tu trabajo lo mejor que puedas. Eso le dará opciones de gestión para trabajar que podrían convertir un proyecto de desastre en una gran historia de éxito. Lo he visto suceder muchas veces.

Solo puedo reiterar lo que otros han dicho, pero enfatizo enfáticamente: siempre luche por su mejor trabajo y mantenga un rastro de papel. tanto por CYA como por razones técnicas.

Cualquier caída que se presente en su camino depende del carácter personal de la gerencia; pero déjame decirte que es un infierno estar en el lado receptor de una gestión incompetente y mentirosa. Pero lo peor que dejará con su respeto a sí mismo (y a sus compañeros) intacto.

Mantenga buenas notas de los aspectos técnicos de su Marcha de la Muerte. Cuando recibes la inevitable pregunta de la entrevista, ¿ has estado en un proyecto fallido? ¿Por qué falló y qué hiciste para evitarlo? La administración de Bonehead no es una respuesta, incluso si es la razón.

Puede ser una forma fácil de asumir que es un fracaso inevitable y absoluto y simplemente renunciar al proyecto. Como consultor, a menudo me invitan a ayudar con los proyectos que se encuentran en varias etapas de degeneración, fallidos o fallidos, y parte de lo que me pagan es revivir y completar dichos proyectos.

Lo que ves como un fracaso completo, puede no ser percibido como tal por todos, dependiendo de la perspectiva. En un mundo ideal, todas las funciones se completarían, codificadas de forma elegante e independiente de otros sistemas y de cada línea de código probada. No he visto un solo proyecto que se viera así en la rev. 1. En el mundo real, enviar un proyecto significa asumir algunos compromisos, tal vez incluso faltar algunas características clave, pero el producto puede enviarse y aunque será de calidad beta en el mejor de los casos , al menos obtendrá los comentarios sobre qué cosas solucionar primero. La ventaja de esto es que puede informar a la administración que el software nunca se hace y, en lugar de tratar de desarrollar un cierto v 1.0 en vacío, es mejor iterar y responder a los cambios de una manera ágil. Finalmente para usted como desarrollador en esta posición, Creo que la clave es desarrollar el mejor código posible en estas condiciones: documentarlo, escribir pruebas usted mismo, si es necesario (especialmente para dependencias externas) y usar su conocimiento del sistema para comunicar qué características son realmente cruciales y deben -tienen y cuáles pueden esperar una semana o un mes. Exprese sus inquietudes y justifíquelas como lo hizo con nosotros. En lugar de prepararse para el plan B, prepárese para el hecho de que usted y otras almas pobres probablemente arreglarán todo ese código defectuoso y aún no realizado DESPUÉS de que se haya enviado el producto, como se indicó anteriormente, esto significa escribir su código de manera modular desacoplada, si cree que el código de la capa de persistencia es malo, es de esperar que pueda reemplazarlo por completo en la próxima revisión. Finalmente, no se desespere: lidiar con tal situación es parte de lo que usted ' me pagan y es un proceso de aprendizaje. Independientemente del resultado en este proyecto en particular, esto contará como una experiencia valiosa en el futuro.