recuperación de desastres de software cuando un ingeniero no está disponible de repente

8

Recientemente, en mi empresa, tuvimos un proyecto donde el plazo era muy ajustado y todo iba según lo planeado hasta que no estuve disponible debido a problemas personales extremos.

Eventualmente perdimos la fecha límite por 4 ~ 5 días.

¿Cuáles son los planes de recuperación habituales para estas condiciones? ¿Debería mi empresa intentar subcontratar a un desarrollador para que termine mi trabajo? incluso eso podría tomar unos días para encontrar uno?

project-management software deadlines

— Jerife
fuente

3

Si su parte del trabajo puede subcontratarse sin capacitación o transferencia de información de usted, es posible que no esté agregando mucho valor. Pero típicamente, en un proyecto bien administrado, uno debe permitir un tiempo de contingencia (basado en la duración del proyecto, pero nunca menos de una semana) para administrar riesgos como este.

— James McLeod

¿Por qué no había nadie para terminar el trabajo?

— Eufórico

77

"Recientemente en mi empresa tuvimos un proyecto en el que el plazo era muy ajustado", es decir, (a) el gerente del proyecto creó un plazo que no permitía que nada saliera mal, y (b) el gerente del proyecto estaba no pudo prever ningún riesgo (como un desarrollador que no estuvo disponible por un período de tiempo, no exactamente una circunstancia exótica) y, por lo tanto, no pudo planificarlos. Parece que necesita un nuevo gerente de proyecto, a menos que éste pueda aprender de sus errores.

— Kyralessa

44

@ Kyralessa: O (c) el gerente del proyecto se vio obligado a exprimir todos los buffers de la planificación porque alguien más hizo promesas poco realistas al cliente. "Construir esto no puede ser tan difícil, así que prometemos una fecha de entrega antes de pedirles a los desarrolladores sus estimaciones".

— Bart van Ingen Schenau

3

@BartvanIngenSchenau, en una situación como esa, su trabajo como gerente de proyectos es retroceder.

— Kyralessa

10

Depende de la duración previsible de la falta de disponibilidad, la duración restante del proyecto, la forma en que se distribuyen las tareas y las consecuencias de no cumplir con los plazos.

Los desarrolladores de software no son intercambiables a voluntad. Los desarrolladores crean conocimiento sobre el sistema a medida que el sistema crece, y agregar un nuevo recurso requiere hacer frente al conocimiento contextual que falta de los nuevos recursos.

Varias buenas prácticas reducen los riesgos asociados con la indisponibilidad repentina:

Las revisiones por pares aseguran que el conocimiento sobre el desarrollo se comparta entre varios desarrolladores. En caso de falta de disponibilidad, el resto del equipo podría reorganizarse para hacerse cargo o, en el peor de los casos, traer un nuevo codificador y organizar una transferencia de conocimiento.
Los equipos integrados ubicados que trabajan en estrecha colaboración para tomar decisiones de diseño pueden mitigar la indisponibilidad de la misma manera. El conocimiento compartido sobre el diseño general facilita la redistribución del trabajo y la información de los recién llegados.
la documentación formal eventualmente podría ayudar. Sin embargo, en la práctica, esto funciona bien solo si la documentación producida por un desarrollador es utilizada por otro desarrollador (o modelos utilizados en herramientas de generación de código). La documentación que solo lee uno mismo con frecuencia parece ser mucho más ambigua. Si un nuevo desarrollador tiene que hacerse cargo de dicho trabajo, la auto documentación podría generar tantas preguntas que responda.

Traer nuevos desarrolladores cuando hay plazos ajustados es muy difícil, porque informar a los recién llegados toma tiempo del equipo, en un período en el que no hay tiempo libre. Si estás enfermo durante 1 semana, no tiene sentido. Se debe prever si el costo de informar a los recién llegados se compensa con los beneficios del nuevo recurso, generalmente si hay altos costos por llegar tarde, o si no es posible posponer, o si la falta de disponibilidad es por un período de tiempo más largo.

— Christophe
fuente

1

Esto está bastante cerca. Lo más importante es asegurarse activamente de que alguien pueda cubrirlo en cualquier momento.

— candied_orange

En la gestión de proyectos hay un concepto para estos casos. La planificación debe tener en cuenta este tipo de situaciones. Ahora es demasiado tarde para que la empresa minimice el impacto. Sea honesto con las partes interesadas y hágales saber que la fecha límite debe ser movida. Cumplir con los plazos es casi nada comparado con cumplir con las expectativas. Intentando salvar esta falta de planificación a expensas de la "calidad", la solución podría ser más cara de lo que piensas ... Después del lanzamiento, solo hay una "primera impresión".

— Laiv

@Laiv Gracias por tus comentarios. No puedo juzgar si en este caso el plazo puede posponerse o no. En el pasado, administré varios proyectos críticos de introducción de Y2K y EURO para los cuales el aplazamiento no era una opción. Pero estoy de acuerdo con usted en el principio: es mejor discutir asuntos de plazos con el cliente cuando el riesgo es demasiado alto, en lugar de tratar de encontrar una alternativa imposible y fracasar. La planificación de la contingencia es, por supuesto, una necesidad; pero desafortunadamente no es suficiente lidiar con situaciones tan extremas (las reservas tienden a agotarse al final del proyecto).

— Christophe

Sí, eso es verdad. No he visto demasiados proyectos en ejecución a pesar del presupuesto para contingencias.

— Laiv

5

Los planes habituales para esto es incorporar la contingencia en la fecha límite. Las cosas suceden, a menudo nunca se cumplen los plazos. ¡Que no estuvieras disponible era solo otro inconveniente en los planes cuidadosamente diseñados que nunca salen según el plan!

— gbjbaanb
fuente

Tiene toda la razón: cada plan necesita algunas reservas de contingencia para hacer frente a los riesgos. Sin embargo, el problema con demasiada contingencia es el efecto de profecía autocumplida: al final, la contingencia se consume de todos modos. Y en las últimas semanas del plan, las personas podrían enfermarse aunque no quede margen. Entonces la contingencia por sí sola no es suficiente.

— Christophe

1

En realidad, la contingencia es una estrategia de mitigación de riesgos, pero son otras formas de lidiar con el riesgo, incluida la eliminación (asegúrese de que otros puedan hacerse cargo sin afectar el cronograma), aceptarlo (el valor predeterminado si no administra sus riesgos), o transfiéralo (en este caso, informe al cliente / cliente que no está pagando lo suficiente para garantizar la entrega a tiempo y que debe estar listo para manejar cualquier demora).

— James McLeod

5

Esto se llama el "factor de bus". Básicamente, el riesgo que representa el proyecto si un desarrollador golpea a un desarrollador. Tener un desarrollador no disponible durante una semana es un pequeño inconveniente en comparación con perder un desarrollador de forma permanente. Podría ser un accidente o una enfermedad repentina, pero de manera menos dramática podría ser un desarrollador principal que cambia de trabajo a corto plazo o es despedido. O un desarrollador principal que se transfiere a otra tarea de alta prioridad en un departamento diferente.

En resumen, debe planear la reducción del factor del bus, o debe estar preparado para mitigarlo, por ejemplo, tener amortiguadores en los plazos o simplemente ser lo suficientemente flexible como para poder cumplir con el plazo. Lo que generalmente no puede hacer es subcontratar una tarea compleja a corto plazo o contratar a un nuevo desarrollador; casi siempre llevaría más tiempo introducir un nuevo desarrollador en un sistema existente que esperar una semana para que regrese un desarrollador principal. Si un equipo pequeño pierde un miembro, por supuesto será más lento, pero si también tiene que presentar un nuevo miembro, será aún más lento .

Puede reducir el factor del bus al tener un equipo de intercambio continuo de conocimientos y revisiones por pares (o incluso programación de pares). Pero, por supuesto, esto es algo que tiene que suceder antes de que llegue el autobús.

— JacquesB
fuente

2

Cualquier empleado puede dejar de estar disponible durante una semana, un mes o para siempre, sin previo aviso, en cualquier momento. Accidente, enfermedad, haber tenido suficiente de este trabajo, muchas otras razones. Depende de la gerencia asegurarse de que tal ocasión sea molesta, quizás costosa, pero no un desastre.

Si tiene un equipo de diez, puede perder el 10% de su equipo. La empresa debería ser capaz de manejar eso si el resto del equipo está motivado (pagar horas extras es muy motivador). Si eres un equipo de uno, entonces el trabajo no se hará. Si tiene otros empleados que pueden intervenir, la demora puede reducirse al mínimo. Contratar a alguien desde el exterior sería difícil, aunque probablemente encuentre un contratista que pueda comenzar con un aviso de días durante algunas semanas a una tarifa por hora muy alta.

Lo mejor que puede hacer es tener contratos, etc. para que un retraso en la finalización de un producto no sea un desastre financiero. Y tener una fecha de finalización planificada y alcanzable mucho antes de la fecha límite. Tener empleados que puedan intervenir entre sí ayuda (pero puede ser problemático de lograr).

Y si tiene un plazo que debe cumplirse, entonces quizás el alcance del trabajo sea más flexible. En otras palabras, suelte funciones para cumplir con su fecha límite.

— gnasher729
fuente

1

Una forma clave de reducir el "Factor de Bus" que @JacquesB menciona arriba es la programación de pares como una técnica central. (Mi propia práctica es usar el término "Factor de Lotería" ya que es menos mórbido pero el efecto es el mismo).

Muchos desarrolladores odian la programación de pares; muchos gerentes también lo odian, por razones completamente diferentes (algunos desarrolladores odian verse obligados a comunicarse con otros humanos por períodos prolongados; algunos gerentes a menudo sienten incorrectamente como si estuvieran pagando el doble de dinero por una sola salida).

Pero la programación de pares elimina el riesgo de un solo punto humano de falla, al garantizar que cualquier tarea de desarrollo sea realizada y comprendida por al menos dos desarrolladores.

— Jim Kiley
fuente

0

Hay varias formas en que he visto este tipo de cosas manejadas:

Comparte el trabajo

Lo más obvio es compartir el trabajo entre los recursos existentes (suponiendo que esto sea posible). Cómo garantizar que los desarrolladores se pongan en marcha es casi una respuesta en sí misma, pero en última instancia, se reduce a registrar adecuadamente los requisitos, los diseños y el progreso. Cosas como la programación de pares también pueden ser de gran ayuda aquí.

Retrasar la fecha límite o intentar recuperar el tiempo

Consulte con el cliente para ver si se puede extender el plazo. Alternativamente, podría ser posible ganar tiempo de desarrollo adicional trabajando por las tardes, fines de semana y días festivos.

Descartar otras tareas

¿Hay alguna otra tarea no crítica que pueda descartarse temporalmente para hacer espacio?

Salir adelante

¿Hay trabajo planificado después del desarrollo que pueda adelantarse, como documentación, scripts de prueba y configuración?

Admite que podría ser tarde

Habla con el cliente temprano. Podría ser posible cumplir en parte, o al menos, podría obtener una dirección decente sobre las prioridades relativas de otras cosas.

Recurso adicional

Una posibilidad, pero esto en sí mismo conlleva riesgos. Tomará tiempo ponerlos al día y, como son temporales, podrían irse y dejarlo aún peor.

Comprueba la ruta crítica

Si hay otras partes involucradas, verifique que todavía estén en el objetivo. No tiene mucho sentido mover el cielo y la tierra para terminar algo si, por ejemplo, el equipo de prueba lleva un mes de retraso en probar cosas.

Aceptar las realidades del riesgo.

Hay una frase común en la profesión legal que establece que los problemas difíciles crean soluciones deficientes. Puede ser tentador intentar que todos comprendan todo para cubrir todas las eventualidades. Sin embargo, esto es un mandado tonto.

Los desarrolladores deberían dedicar tiempo de calidad a sus propios desarrollos. Consumir una cantidad cada vez mayor de tiempo para convertirse en au fait con otros desarrollos es una actividad altamente cuestionable. Un término medio razonable podría ser tener un experto en la materia y un suplente.

— Robbie Dee
fuente