Mejor forma de entrenar a nuevos empleados [cerrado]

El equipo en el que formo parte actualmente experimenta una rotación bastante alta, con miembros que generalmente se mudan a diferentes proyectos dentro de la misma compañía. Actualmente, nuestra "capacitación" para los nuevos miembros es vincularlos con un contacto principal (generalmente la persona más reciente para completar su capacitación) que les brindará experiencia práctica y les preguntará a los desarrolladores de mayor antigüedad si el nuevo empleado pregunta algo al mentor no sabe Proporciona una oportunidad para que el nuevo empleado se involucre rápidamente y desafía al mentor a mejorar su comprensión del sistema también.

Sin embargo, como puede imaginar, este estilo de capacitación lleva mucho tiempo y no proporciona una muy buena transferencia de conocimiento (se propagan conceptos erróneos, las brechas se expanden).

Me encargaron generar documentación y materiales de capacitación para nuestros futuros nuevos empleados. Ya hago redacción técnica ocasionalmente, pero es para el usuario final y es muy específico con muchas capturas de pantalla y consume una gran cantidad de tiempo para completar.

La creación de la nueva documentación para nuevos empleados se considera de baja prioridad y actualmente solo tengo ~ 40 horas para trabajar en ella. Documentar el sistema de la forma actual en que escribo la documentación técnica apenas arañaría la superficie en 40 horas. Especialmente teniendo en cuenta que tengo que documentar no solo sobre la base del código, sino también sobre las implementaciones y el soporte.

¿Cómo puedo escribir rápidamente la documentación para actualizar a los nuevos empleados lo más rápido posible sin invertir mucho tiempo en escribir la documentación?

Información adicional:
Actualmente tenemos un wiki y algunos documentos de capacitación, sin embargo, ambos son escasos.

Buena pregunta. La capacitación de programadores en el trabajo rara vez se toma en serio, ni se habla con frecuencia.

Algunas ideas que he visto funcionan bien:

• En su wiki, tenga un nuevo documento de contratación (el que está escribiendo). En ese documento, describa las tareas que realizará el nuevo empleado durante las primeras 1-2 semanas. Donde trabajo, hay mucho que saber desde el primer momento, desde software / herramientas internas, hasta procesos y ubicaciones de tipos específicos de información. edit> tenemos instrucciones como "instalar x, y, z en orden" con capturas de pantalla para la configuración, etc. Por lo tanto, configurar un sistema o granja (VM) con Win Server, SQL Server, SharePoint, BizTalk, nuestro software no es tan simple como sonidos Esto se aplica a las otras versiones de esas aplicaciones que admitimos.
• Practica problemas. Donde estoy, tenemos un producto que expone una API de gran tamaño. Por lo tanto, siempre es beneficioso para nosotros revisar nuestra propia documentación de productos para escribir extensiones (predeterminadas) tal como lo harían nuestros clientes / clientes. Entonces, si tenía una biblioteca matemática como parte de la API de su producto, tenga un problema de práctica que es "escribir una calculadora usando nuestra API" o algo así.
• Los mentores son buenos. Guárdalos. Hacemos eso también aquí, y no solo es una buena manera de conocer gente / hacer amigos, sino que son invaluables como fuente de aprendizaje. Yo recomiendo no teniendo que ser la persona más reciente para terminar la formación, ya que no tienen la historia del conocimiento corporativo que alguien más fuerza. Haga que todos lo hagan en una rotación.
• Hacemos (aproximadamente) presentaciones semanales / charlas tecnológicas. Haga que los nuevos empleados escojan algo de su producto (o lo asignen) y hagan una presentación después de su tercera semana. Asegúrese de que sepan que hay espacio para que se equivoquen, y que el equipo pueda corregirlos si molestan algo en la presentación.
• Haga que los nuevos empleados trabajen en la documentación cuando comiencen. Los obliga a leerlo.

Como señala Dan McGrath, es una buena idea alentar a los nuevos empleados a mejorar la wiki para ellos también.

Primero, sugeriría que no tenga que hacer que su nuevo documento de capacitación de contratación sea tan exhaustivo como algo que escribiría para un cliente. Debe ser lo suficientemente técnico como para que un nuevo desarrollador pueda usarlo como guía, pero no tan detallado como para describir cada pequeña cosa. Podrán hablar con el equipo si tienen preguntas después de todo.

¿Cuáles son las 10 cosas principales que un nuevo empleado necesita saber para ser útil para su equipo? Concéntrate en estas cosas. Conviértalos en su lista de elementos de éxito para que un nuevo desarrollador tenga suficiente para hacer y suficiente información para que continúen. Si tiene demasiadas cosas en la lista, pregúntese si lo harán en las primeras dos o tres semanas. Si no van a hacer algo en este momento, tal vez no debería estar en la guía de embarque.

Para cada sección de su guía, asegúrese de que haya una persona destacada en la parte superior. De esta manera, si el nuevo empleado tiene alguna pregunta, saben a quién acudir para obtener ayuda. Además, asegúrese de que un miembro del equipo no sea el indicado para demasiadas secciones. No desea tomarse el tiempo de una persona con nuevas preguntas de contratación si no son el mentor.

No gastes toda tu semana en este documento. Tómese un tiempo para ajustarlo después de dejar pasar al menos un nuevo empleado. Vea lo que funciona bien, lo que no funciona y corríjalo.

Recientemente comencé con un documento similar en mi lugar de trabajo, con limitaciones de tiempo similares. Comparto que es fácil querer escribirlo a un nivel muy detallado, como hice al principio también, pero eso podría ser contraproducente.

Si alguien nuevo está comenzando un papel, es probable que esté inundado de información durante las primeras semanas. Tener su capacitación inicial como un tugurio mental de un desarrollador que ha estado en una empresa durante varios años, en mi opinión, complicará mucho lo que alguien necesita saber durante sus primeros meses o incluso un año en esa posición. Manténgalo en un nivel alto, intente utilizar jerga y conceptos estándar, y luego amplíelos con los detalles de los procesos de la compañía.

Para mí, la primera iteración de este documento es simplemente un resumen del SDLC que utilizamos en mi lugar de trabajo, con una lista de roles asociados en cada paso, algunos ejemplos de personas que cumplen esos roles y listas de verificación específicas asociadas con cada paso del ciclo de vida también. Personalmente, considero que las listas de verificación son indispensables para fines de capacitación, pero también sobre cualquier otra cosa que hago en el trabajo. Por ejemplo:

• Project Manager (Joe) te asigna una tarea en Jira.
• Establezca un tiempo estimado de finalización de la tarea basado en la fórmula x.
• Establezca el ticket como 'en progreso' cuando comience a trabajar en él.
• Cree una rama desde git, haga clic en el enlace para ver un video de 30 segundos sobre este progreso.
• Escriba pruebas unitarias basadas en restricciones en el documento de diseño, consulte la página y para conocer las convenciones de nomenclatura de pruebas unitarias.
• Configure el ticket para su revisión y envíe el código para revisar el sistema ... 'etc.

Es de esperar que su nuevo empleado esté familiarizado con la mayoría de los conceptos y ahora tenga una guía paso a paso de cómo se aplican los procesos en la empresa. También hago una demostración rápida del proceso de principio a fin utilizando documentos reales de proyectos que siento que se ejecutaron bien.

Como se mencionó, también es un documento vivo, por lo que las secciones se pueden ampliar a medida que se identifica que necesitan más información. Todo el equipo debe participar para mantenerlo actualizado. Puede ser un wiki, un documento de OneNote, lo que sea, pero algo que todas las personas puedan editar y revisar, y luego comenzar a involucrar a otras personas para mejorarlo cuando tengan una hora libre aquí y allá. De esa manera, una persona no lo está haciendo y propagando su propio giro en el proceso a todos los nuevos empleados.

Una vez que hayan revisado el proceso, pídales que sigan una pequeña función / corrección de errores en un proyecto que no sea de misión crítica y pídales que hagan preguntas que el documento no cubre. Registre cuáles son estas preguntas, porque probablemente deberían ser las primeras cosas que agregue al documento la próxima vez que trabaje en él.

No puedes combinar hacer algo así de bueno sin perder tiempo. Al menos, si quieres hacerlo tú mismo. Debería preguntarse si es realmente necesario documentarlo con la precisión que está intentando.

La única alternativa sería dejar que los nuevos empleados hagan el trabajo principal. Deja que escriban algunas partes. El tiempo que dedica a corregir estos (en forma de comentarios) será menor que en sus situaciones actuales. Proporcione algunas buenas plantillas y no tendrá que preocuparse por el diseño.

Creo que ya sabes que te han encomendado una misión imposible. Como escritor, probablemente ya esté familiarizado con la cita de Mark Twain:

Si tuviera más tiempo, habría escrito menos.

Dado que prácticamente no tiene recursos, probablemente lo mejor que puede hacer es obtener un archivador y pedir a todos que hagan una copia de lo que ya tienen y que guarden la copia en el archivador. De esa manera, al menos puede decirle al nuevo empleado: "Si desea buscar algo sobre el sistema, el lugar para comenzar es en el archivador".

La buena escritura lleva tiempo, punto. Además, debe adaptarse al público objetivo. Lo que funciona para los usuarios finales no será lo que un programador necesita.

Sin mencionar que una buena capacitación no se limita a materiales escritos, sino que incluiría una gran variedad de recursos educativos, incluidos en línea, en el aula, multimedia, etc.

Como dicen: "Si crees que la educación es cara, prueba el costo de la ignorancia".

Además, no hace falta decir que ver la documentación como algo que se debe hacer después del hecho en lugar de convertirla en una parte integral del proceso desde el primer día es indicativo de un problema organizacional sistémico.