Cuánta información se retiene durante un volcado de cerebro [cerrado]

Cuánta información se puede transferir cuando un empleado está a punto de irse.

A un miembro de mi equipo, desde hace un mes, se le presentó un nuevo proyecto. Recibió un volcado de cerebro de los 2 desarrolladores originales. Me emocioné con este proyecto desde hace 2 semanas. Mi equipo recuerda que ha anunciado su renuncia y se irá en 2 semanas. ¿Cuánto del conocimiento original podré obtener? Cualquier fuente sería apreciada.

Esta pregunta en realidad puede ser más adecuada para Project Management SE.
Voto para cerrar esta pregunta como fuera de tema porque no se trata de navegar en el lugar de trabajo sino de la gestión de proyectos.
No creo que esto esté particularmente relacionado con la gestión de proyectos, pero sí creo que hay una amplia variedad de posibles respuestas a esto en función de diferentes circunstancias.
Voto para cerrar esta pregunta como fuera de tema porque lo mucho que alguien puede esperar recordar no se trata de navegar en el lugar de trabajo.

Respuestas (4)

Nadie puede decirte lo que puedes aprender. Eso está mucho más condicionado por tu estilo de aprendizaje y antecedentes que por las circunstancias.

Aprender haciendo es mucho más efectivo que aprender escuchando. Por lo tanto, lo mejor que puede hacer es hacer que las personas nuevas intenten trabajar en el asunto mientras la persona anterior todavía está allí para responder sus preguntas.

La segunda mejor cosa que puede hacer es tomar notas y grabar en video cualquier 'descarga' para que pueda volver a revisarlo más tarde.

Por supuesto, en retrospectiva, la empresa debería haber dedicado tiempo a tener suficiente documentación interna para evitar este problema en primer lugar.

Entonces, ¿está tratando de obtener una descarga de cerebro de alguien que hace un mes recibió una descarga de cerebro del equipo real?

He liderado equipos que se han hecho cargo de una serie de proyectos/sistemas a lo largo de los años. Por experiencia, sugeriría que la persona en el medio solo habrá retenido las cosas con las que ha tenido que lidiar directamente (por ejemplo, cualquier problema de producción, cambios/nuevo trabajo realizado, etc.). Para cualquier otra cosa, diría que si no fue documentado por los desarrolladores originales, es mejor contarlo como conocimiento perdido.

Le pediría a la persona intermedia que comenzara a delinear y documentar todo lo que pueda, y que buscara grandes lagunas lo antes posible antes de irse.

También me gustaría preguntarle al gerente si estaría dispuesto a contratar a uno de los miembros originales del equipo por uno o dos días como "consultor" para ayudarlo a ponerse al día.
@Voxwoman: estoy trabajando sobre la base de que los desarrolladores originales se fueron hace mucho tiempo, si todavía están en la empresa, solo haría que rehagan la entrega original (idealmente a más que solo el OP en caso de que el usuario 2097159 se vaya / también es atropellado por un autobús).
Lo entiendo. A veces, sin embargo, si los ex empleados se fueron en buenos términos (y no hace mucho tiempo), pueden estar dispuestos a ayudar a sus reemplazos, por una tarifa, por supuesto.
Absolutamente, pero creo que si ese fuera el caso, no sería necesario hacer una pregunta en stackexchange...
@TheWanderingDevManager Los desarrolladores originales se han ido.

Esta es una de las razones por las que es importante contar con una documentación completa y actualizada sobre todos los aspectos de un proyecto. Si el proceso de documentación se vuelve parte del ciclo de vida del proyecto en lugar de otra tarea, la cantidad de información que se pierde en una transición como esta se minimiza. Muchas empresas ven esta documentación como un sumidero de tiempo que cuesta dinero y los miembros del equipo la ven como una tarea adicional que muchas veces nunca se revisará. Por esta razón, la documentación de un proyecto a menudo se minimiza a lo que se requiere para completar el proyecto. Pero esto es un error.

El acto de documentar brinda tiempo para pensar y detectar fallas antes de que se haya realizado el trabajo y cueste más arreglarlo. Y con una buena documentación, es mucho más fácil traer un nuevo miembro del equipo para aumentar o reemplazar al personal existente. Cada vez que alguien se va hay una pérdida de conocimiento sobre el proyecto. Pero cuanto mejor se documentó el proyecto, menos de este conocimiento se pierde por completo, y más se puede comunicar fácilmente y es más probable que el nuevo personal lo retenga.

He hecho esto varias veces (entregar y recibir), puedo decir que hacerlo sin problemas requiere cierta planificación y tacto.

Como indicó ReallyTired, los procesos y sistemas completamente documentados son vitales, pero eso es algo que debe hacerse todo el tiempo durante la vida de los proyectos. Apresurarlo en la salida de 2 semanas es una pérdida de tiempo y demasiado poco y demasiado tarde. Además, las 2 semanas restantes se aprovechan mucho mejor interactuando con la persona que se va en lugar de tener que escribir documentos en su cubo sin parar.

He encontrado algunas cosas que son efectivas:

  • Asigne a alguien para que "siga" a la persona que se va. Pídales que enseñen sus tareas básicas del día a día a una persona capaz y motivada que hará buenas preguntas y no se resistirá a practicar incluso las cosas más simples solo para tener una idea.

  • Si el trabajo requiere algunas tareas repetitivas relativamente simples, haga que la persona que se va capture esas tareas en screencasts. Un screencast narrado puede comunicar muchos más matices para el esfuerzo que un documento de Word para cosas operativas básicas.

  • Reconoce que no todo se va a transferir. A menos que la salida y el traslado se planeen con meses de anticipación, simplemente no es posible. Tienes que hacer triaje. Concéntrese en una pequeña cantidad de habilidades clave para transferir realmente bien en lugar de presionar para cubrir todo lo humanamente posible.