¿Cómo gestionas los proyectos que dejan otros empleados? [cerrado]

Sucede que alguien deja la compañía de repente. Ahora su trabajo necesita ser completado y se le está asignando. Sin tener idea de lo que estaba haciendo (¿estaba hecho al 90% o al 9%?), ¿Cómo manejas las sobras?

1. ¿Debo comenzar desde cero? ¿Qué pasa si se hizo el 90%?
2. ¿Debo intentar entender lo que haya hecho? ¿Qué pasa si era solo una tontería?

Para saber qué hacer, necesita saber qué tiene y qué tan bien está en forma.

Entonces, comience por echar un vistazo rápido a toda la fuente y vea lo que tiene. Si está vívidamente claro, entonces es más fácil terminar lo que falta. Haz pruebas unitarias para descubrir qué funciona y qué no.

Si no está vívidamente claro, entonces comienza a descubrir qué funciona con las nuevas pruebas unitarias. Si esto es imposible, comunique al líder de su equipo que tiene un problema y que es posible que no pueda resolverlo. Luego puede decidir si el trabajo restante se debe recuperar de todos modos o si es demasiado malo y necesita volver a hacerlo.

Además de lo que otros escribieron, te sugiero que hables con cualquiera que haya tenido contacto directo con el chico. Entiendo por su descripción que él estaba trabajando solo, ¿aún así debe haber estado informando a alguien? Y puede haber personal de control de calidad que haya probado lo que había producido ... Estas personas deberían (normalmente) tener al menos una idea aproximada de cuán lejos llegó el chico con su proyecto antes de irse. A menos que, por supuesto, la información / producto suministrado por él resulte ser completamente poco confiable, contribuyendo a su despido.

Discuta esto con su gerente y asigne un marco de tiempo para la exploración / prueba inicial del código sobrante, y comprenda la especificación y los requisitos. Esto podría ser aproximadamente un día para un proyecto en la escala de tiempo de unas pocas personas meses, como máximo una semana para un proyecto de trabajo de una o más personas por año, etc.

Después de esta exploración inicial, debe tener una estimación aproximada de

• lo que se supone que debe hacer el producto,
• qué puede hacer actualmente y qué tan bien
• cuánto tiempo y riesgo tomaría reescribir desde cero,
• cuánto tiempo y riesgo tomaría terminar lo que ya está hecho.

Luego puede volver a sentarse con su gerente para tomar una decisión.

En mi experiencia, esta no es una situación poco común. Desafortunadamente, realmente tienes dos problemas aquí :

1) Las sobras de este proyecto 2) Las razones por las que te metiste en este lío en primer lugar

Para (1) debe tener en cuenta el tamaño / complejidad del proyecto. Si es una semana de trabajo, probablemente deba comenzar de nuevo. Si es un año de trabajo, es posible que necesite ver qué puede salvar del código existente.

De cualquier manera, debe seguir estos pasos de inmediato:

a) Informe a sus gerentes que tiene un gran problema

b) Obtenga las especificaciones del proyecto y obtenga una comprensión profunda de lo que necesita lograr, o hable con los patrocinadores del proyecto si no hay especificaciones.

c) Hable con los gerentes / clientes, etc. y averigüe si alguien tiene / piensa que tiene alguna idea del estado del proyecto.

Una vez que haya hecho eso, podrá comenzar a examinar el código / elaborar una estrategia.

(No creo que las pruebas unitarias lo ayuden mucho; podrían decirle si las funciones que se han escrito realmente funcionan, pero no le dicen qué funciones deberían estar allí).

Lo que no quiero a continuación es obtener una visión general de la arquitectura del código que existe y cómo esto se asigna al problema definido en la especificación. Luego trabaje cuáles son los subcomponentes de cada uno de estos componentes principales y vea cómo encajan en el panorama general. Hacer esto le dirá (aproximadamente) qué componentes faltan.

Una vez que sepa lo que existe, debe comenzar a examinar el código existente para ver si hace lo que se supone que debe hacer.

Una vez que hayas hecho todo esto, podrás estimar cuánto trabajo queda por hacer.

En cuanto a la parte (2), su empresa puede necesitar analizar las políticas de contratación / políticas de retención de personal, encontrar formas de hacer que los programadores sean responsables del progreso.

Finalmente, también debe considerar cómo podría evitar que esto le suceda a la empresa en caso de que se vaya rápidamente.

Definitivamente necesita probar y ejecutar el software para ver qué funciona y qué no.

Luego deberá considerar qué documentación le queda. ¿Hay requisitos escritos? ¿Hay tareas específicas? ¿Se realiza un seguimiento de las tareas de alguna manera? ¿Alguien lo ha estado probando? De ser así, sabrán qué se hizo y qué no.

Creo que un plan de acción sería:

1. Marque qué requisitos se han completado (mediante una ejecución rápida del sistema como lo haría un probador)

2. Mire el código, ¿puede darle sentido? ¿Está bien escrito?

Claramente, si está hecho al 90% y el código está bien escrito, simplemente lo terminaría.

No mencionado aún.

Intenta contactar al chico que se fue. No es posible en todos los casos. Pero si está sano y al menos le gustó un poco su trabajo, lo ayudará y le dará una respuesta honesta sobre el progreso y las partes faltantes. Y él podría explicarte el panorama general.

Felicidades, esta es tu oportunidad de brillar y causar una impresión realmente positiva en tus jefes. Lo que tienes aquí es una oportunidad invaluable. Entonces, ¿qué necesitas hacer y cómo?

Primero, obtenga el código. Es posible que no haya verificado todo (el tipo que nos hizo esto no lo hizo) y que alguien con derechos de administrador lo quite de su computadora y lo registre por usted.

Siguiente triaje del problema. Tome los requisitos y observe qué partes parecen tener código escrito y cuáles no. Esta es la lista aproximada de lo que no está terminado. Crecerá a medida que avanza el siguiente paso. Luego revise el código y evalúelo, ejecútelo y vea qué está funcionando actualmente y qué parece no funcionar aunque haya un código escrito. Agregue las partes que no funcionan a la lista. Busque pruebas unitarias (me sorprendería si las encuentra, las personas que rescatan justo antes de la fecha límite porque saben que están fallando tienden a no escribirlas). Ahora al menos tienes una buena idea de lo malo que es. También revise los requisitos y vea qué preguntas necesita responder. Muchas veces, las fallas del proyecto se producen como resultado de requisitos deficientes y un desarrollador que no quiere (por una miríada de razones) hacer más preguntas.

Ahora haces tu plan de proyecto. Comience con una lista de las preguntas que tiene de los requisitos (escríbala formalmente en un documento) y luego enumere las cosas que debe hacer para completar el trabajo. Haga una estimación de cuánto tiempo tomará cada uno. Determine si lo que existe actualmente es recuperable (y si no, prepárese para justificar por qué no).

Ahora tenga una reunión con el gerente del proyecto (y su jefe si son dos personas diferentes) y cuéntele las malas noticias. (Casi siempre son malas noticias cuando alguien se va de repente y hay que retomar donde lo dejaron, los buenos desarrolladores no dejan a la gente en la estacada; al menos se van con una lista de lo que han hecho y lo que queda por hacer La excepción puede ser si alguien se fue debido a problemas de salud.) En su discusión, puede obtener algunas de las respuestas que necesita y usted y el primer ministro pueden modificar un poco el plan del proyecto.

Haga un seguimiento de la reunión enviando al primer ministro y otras partes interesadas críticas (el primer ministro identificará a quién), una copia de sus preguntas que deben responderse y el plan del proyecto que elaboró.

Ahora tiene lo que necesita para comenzar con la codificación real, así que manos a la obra.

Mientras tanto, es probable que te hayan quitado algo más para salvar este proyecto. Asegúrese de que su trabajo esté en forma para que otra persona lo recoja o para que usted lo recoja después de que termine el proyecto. Eso significa el mismo tipo de cosas, un documento donde dices lo que está hecho y lo que no está y un registro de todo el código fuente (no necesariamente al tronco si no está hecho, pero en algún lugar donde alguien más puede acceder a él) .

Si no ha sido retirado de su trabajo existente, entonces necesita calcular con su jefe cuánto tiempo en el día laboral dedicará a cada uno. Este es uno de esos momentos en que se pueden necesitar horas extras y serán apreciadas. Cuanto más cerca esté de la fecha límite real, más desesperada es la administración, es posible que pueda calcular el pago de horas extras o una gran bonificación si la fecha límite está cerca. Si este trabajo va a retrasar significativamente el otro trabajo, entonces debe asegurarse de que las partes interesadas en ese proyecto lo sepan.

Una vez que tenga éxito en la recuperación del proyecto, asegúrese de presumir de eso en su próxima revisión de desempeño.