¿Cómo haces para entrenar a un reemplazo? [cerrado]

Recientemente pregunté sobre dejar un puesto y obtuve muchas respuestas excelentes. Uno de los hilos comunes era que estar cerca para entrenar a la nueva persona sería de esperar y podría recorrer un largo camino.

Ahora que considero que (creo) la mayoría de las personas no se quedan en una empresa por mucho tiempo después de haber avisado, y tomará tiempo para que la empresa entreviste / contrate a uno, lo que deja un corto período de tiempo para poner a alguien al día.

Tampoco he entrenado a nadie antes. Hice un montón de tutorías en la Universidad y la Universidad, pero enseñar un idioma / tecnología es muy diferente de entrenar a alguien para reemplazarlo en su trabajo.

Entonces, la pregunta es: ¿cómo se capacita a alguien para que lo reemplace en un tiempo potencialmente corto?

Simplemente hablando, es imposible entrenar completamente a una nueva persona. El conocimiento de 2-3 años no se puede transmitir a una nueva persona en 1-2 semanas. Es responsabilidad de la nueva persona interesarse y aprender por sí mismo la mayoría de las cosas.
Según yo, debe distribuir el tiempo de esta manera: -
Compartir los documentos y explicarlos - 30%
Esto incluirá explicar los diseños y clases de alto nivel, bajo nivel, etc.

Compartir el código y explicarlo: 70%
Esto significa revisar la parte importante del código.

En el medio tendrá que dar tiempo a la nueva persona, para aprender las cosas y plantear las dudas. Su objetivo principal debe ser hacer que la persona sea independiente, para que él / ella entienda qué parte del código hace qué. No puede explicar todos y cada uno, e incluso si lo explica, no será muy útil. La nueva persona tendrá una capacidad limitada para comprender el nuevo sistema. Así que no bombardees con muchas cosas. Solo explica cosas importantes.

Señalarlos en la wiki

Tienes uno, ¿no? Y estoy seguro de que tiene algunos miembros del equipo que actúan como bibliotecarios de código durante las revisiones de código para que se pueda introducir un código común (ya sea en la biblioteca de códigos de la compañía o para reemplazar el código personalizado que el desarrollador acaba de reunir).

¿No? Ah Bueno, entonces tienes un problema.

Dependiendo de cuánto tiempo tenga, deberá seguir uno de estos planes, en orden de nivel de crisis:

1. Aargh! Me voy esta tarde

Si el chico nuevo tiene mucha experiencia en el dominio de su problema, simplemente apúntelo a la wiki y muéstrele cómo llegar al código relevante en su SCM. Cómprele una cerveza, ofrezca su número de teléfono si se siente generoso y vaya a su fiesta de despedida.

Si no tiene tanta experiencia, preséntele a otros miembros del equipo que deberían ser sus puntos de contacto principales para tener una idea de cómo encaja todo. Eso es todo lo que tienes tiempo para.

2. Obtuve toda la semana, pero hay mucha limpieza

Haga que su reemplazo lo proteja durante el primer día para que pueda evaluar sus habilidades y tratar de hacer que hagan su trabajo lo más rápido posible. Déjelos ver cómo aborda un problema, y ​​luego entregue gradualmente para que lo resuelvan y usted actúe como consultor. Desarrolle desde las operaciones principales que realiza todos los días hasta las menos frecuentes. Componga problemas si puede. Empareje el programa si puede. Pídales que hagan un seguimiento de lo que les ha dicho en una wiki o en algún otro recurso basado en texto en red para que puedan consultarlo más tarde y, finalmente, convertirlo en la documentación adecuada.

3. Es el desarrollador junior quien se hace cargo

Ya tendrán el conocimiento del dominio y sabrán cómo funciona el equipo. Comience a asignarles sus tareas y a trabajar para desarrollar su conocimiento sobre sistemas y procesos desconocidos. Concéntrese en ayudarlos a entender lo básico, y las cosas más avanzadas llegarán más tarde a medida que tenga tiempo.

Proporcionar soporte telefónico básico

Suponiendo que se va en buenos términos con la empresa, ofrézcales asistencia telefónica para que sepan que no los dejará en la estacada. Si comienzan a sonar a cada hora haciendo preguntas descabelladas que se pueden encontrar en la wiki, mencione sus tarifas competitivas de consultoría. De lo contrario, la extraña llamada aquí y allá les permite elegir sus cerebros y que usted se mantenga en contacto con ellos, lo que podría ser útil cuando surja la próxima ronda de trabajos.

Deja de codificar de inmediato. Deje que el chico nuevo haga su trabajo diario y esté allí para responder sus preguntas.

No hay mejor manera de aprender que hacerlo.

Dependiendo de la complejidad de lo que esté haciendo, entrenar a alguien después de que usted notifique puede ser una causa perdida, e incluso sin complejidad, hay un número creciente de lugares que simplemente lo dejan tan pronto como lo notifica (asegúrese de tener lo que el suyo antes de dar aviso), por lo que a menudo es mejor capacitar a su reemplazo antes de dar aviso. Las próximas vacaciones o cirugía inventadas son una buena excusa si la necesita, pero suponiendo que esté trabajando en un equipo, debería poder trabajar ese tipo de cosas en un momento a medida que avanza y pasarlas por mantenerlas en el lazo.

Si ya ha apretado el gatillo y tiene una fecha final, entonces hacerles saber dónde buscar varias cosas es probablemente la cosa # 1 que los ayudará a trabajar. Cuando les está mostrando los proyectos y qué hace lo que necesita para asegurarse de que tengan una idea del flujo de trabajo a través de los sistemas y de dónde están los bits importantes en los proyectos más grandes. No tendrá tiempo para darles muchos detalles, pero probablemente pueda llevarlos a un punto en que sepan qué código deben extraer cuando necesiten comenzar a resolver un problema.

Tiende a terminar rápidamente lo que está haciendo o al menos llegar a un punto de parada. Entonces comienza la descarga de documentación / cerebro. He estado en lugares donde el nuevo empleado no estaba familiarizado con parte de la tecnología (tenía que mantener un sitio ASP). Tuve el tiempo suficiente para explicar dónde estaba todo el código y cómo actualizar el sitio (Encontrar el servidor de producción en sí no fue difícil porque estaba debajo de mi escritorio; si eso da una pequeña indicación de por qué me fui).

Suponiendo que su empresa no contrata un fracaso absoluto como su reemplazo, entonces una de las cosas clave es el dominio de las aplicaciones que se están entregando. Puede ser una gran suposición, pero no puedes enseñarle a alguien cómo codificar bien en un par de semanas, ya sea que lo tengan inactivo o no, por lo que la clave es el dominio imo.