Nuevo empleado: vivo o muerto

Hola a todos! Sigo hablando de la experiencia de gestión en TI. Hoy hablaremos sobre presentar un nuevo empleado al equipo. Has contratado a un ingeniero. ¿Cuándo se convertirá en una unidad de combate completa? ¿Qué hacer para acelerar su adaptación? ¿Cómo optimizar este proceso? Después de todo, ¿vale la pena prestarle atención y pasar tiempo?


Comenzaré con la respuesta a la última pregunta: definitivamente sí. No importa cuán experimentado sea el especialista, necesita tiempo para profundizar en los detalles técnicos de un proyecto en particular, familiarizarse con el proceso de desarrollo y finalmente conocer nuevos colegas. Esto es realmente importante para la empresa: cuanto más rápido comience a resolver los problemas, más rápido comenzará a beneficiar a la empresa.

Creo que ingresar a un nuevo empleado en el equipo es un proceso extremadamente importante, y cuanto más depurado sea, más rápido se convertirá en un empleado de pleno derecho y menos tiempo pasará en él.

Principiante a la transformación del colega

Cuando trabajé en un agregador de servicio de repuestos usados, me llevó 3 días presentar nuevas personas al equipo. Después de eso, ellos y los demás resolvieron las tareas actuales en igualdad de condiciones, participaron en discusiones y bromearon con sus colegas en la máquina de café. Pero no llegué a esto, por supuesto, de inmediato, al principio tuve que llenar los baches y ganar experiencia. Solo entonces formé los principios básicos para mí y construí el proceso.

Estos son los principales matices que aprendí por mí mismo de la práctica de la gestión de equipos.

1. Ingresar a una persona en un equipo debe comenzar con una introducción al proyecto. Y esto ya lo hice en la entrevista. Siempre tuve una historia de 10 minutos sobre la compañía en su conjunto, de qué se gana, cómo funciona el servicio, la estructura de los departamentos y más.
2. Preparación del lugar de trabajo y creación de condiciones de trabajo cómodas. El primer día, una persona debe sentarse en su escritorio con una cómoda silla o sillón y encender una computadora ya configurada. ¿No tienes tiempo para preparar todo esto? No puedo, esto realmente necesita atención.
3. Enfoque individual. Por ejemplo, para crear comodidad (y es necesario, especialmente en condiciones de estrés al mudarse a un nuevo trabajo). Es bueno preguntar acerca de las preferencias en términos del sistema operativo y el teclado / mouse. Quizás sea el primer empleador en ofrecer esto. Y esto elevará su empresa a los ojos del empleado.
4. Correcto conocimiento del equipo. No es suficiente imaginar los nombres de todos los empleados e ir a los lugares de trabajo. Puede hacer esto: este es Misha, él es responsable del backend, esta es Petya, él es DevOps, y Vasya y Kolya son responsables de la parte del cliente, se les puede hacer preguntas sobre tales y otros aspectos. Y todo esto debe reflejarse en la documentación oficial para los empleados, pero más sobre eso a continuación.
5. Conocimiento de la empresa. Creo que lo mejor es llevarlo a cabo en departamentos y contar cómo se organiza la empresa por dentro, cómo se establece la interacción entre los empleados. Será útil en el futuro.
6. Gen. Un nuevo ingeniero debe saber cosas tan triviales, dónde está el baño, cómo usar una máquina de café y dónde puede calentar los alimentos. Un gran paso hacia relaciones más cercanas con colegas es invitarlo a cenar con el equipo.
7. Los principios del equipo. En todas partes sus propios términos y condiciones. Por ejemplo, era habitual que nuestro equipo trabajara de acuerdo con un horario flexible, cualquiera podía venir a una hora conveniente para él o tomarse un día libre por negocios o trabajar desde casa. Pero en el caso de una liberación o situaciones de emergencia, nos demoramos y resolvimos el problema juntos. El equipo también tenía una atmósfera amigable, nos tratamos con respeto y esperábamos esto de los recién llegados.

En general, no he descubierto ningún secreto, pero estos aspectos son realmente de gran importancia. La primera impresión es muy importante, es de él que la persona formará una opinión sobre la empresa y su lugar en ella.

Otro factor crucial es la reducción del estrés. Es inevitable, ya que la transición a un nuevo trabajo es una forma de salir de la zona de confort, todas las personas son diferentes, no todos saben cómo lidiar bien con esto. Su tarea es suavizar el proceso de unir a una persona al equipo. Y aquí la atención a los detalles es importante. Por ejemplo, una persona puede ser tímida al pedir reemplazar un teclado incómodo. O si ves que es introvertido, sé más delicado y no lo lleves bajo los reflectores al centro de la arena de espacios abiertos cuando te reúnas con un equipo.

Cómo cargar rápidamente un novato en un proyecto y no matarlo

Un hombre vino a trabajar con usted, lo presentó a sus colegas y a la empresa en general, creó condiciones cómodas. Es hora de ponerse a trabajar. Después de todo, su tarea es involucrarlo en el proceso de desarrollo y comenzar a beneficiar a la empresa lo más rápido posible. Y en esta situación, lo principal es no resolver con rapidez. Sumerja al colega recién acuñado en el trabajo sin problemas.

Por lo tanto, a continuación se detallan los pasos principales que me permiten convertir rápida y sin dolor a un principiante en un miembro completo del equipo.

1. Historia sobre el proyecto. Creo que primero debe hablar sobre el proyecto desde el punto de vista de los clientes. ¿Por qué es necesario, cómo funciona, qué problemas resuelve? Y solo entonces podemos pasar a lo que está "debajo del capó" y mostrar cómo está organizado dentro. Para ahorrar tiempo, puede grabar un video una vez. Solo es necesario controlar su relevancia. Si no puede hacerlo usted mismo, dele la tarea a sus colegas.
2. Estructura del proyecto. Es importante mostrar en qué consiste su servicio, qué módulos incluyen, cómo interactúan entre sí.
3. Base de conocimiento Asegúrese de escribir documentación técnica. Ella será un rayo de luz y una guía para la naturaleza de su proyecto para un principiante. Debería ser todo: desde los principios de denominación de ramas y las reglas para crear solicitudes de extracción en Git hasta la descripción de la infraestructura del servidor y un conjunto de herramientas técnicas.
4. Levantando el proyecto. Ayude al recién llegado a implementar el proyecto, no lo deje caer en esta etapa. Incluso un programador experimentado puede guardar antes de tal tarea cuando todo está confundido allí. Para acelerar este proceso, escriba las instrucciones. Pero puede ahorrar aún más tiempo si hace esto por adelantado y configura el proceso de ensamblaje del proyecto en sí.
5. De simple a complejo. En dos días, cuéntele todo y luego arroje al recién llegado a la tronera y ¿lo obligará a cortar nuevas características complejas? Gran plan para fallar. Los recursos del cerebro humano no son ilimitados; preséntelo gradualmente. Dedique un poco de tiempo y elija tareas con una complejidad creciente, gradualmente llévelo al nivel deseado de dificultad.

Nuevamente, no dije nada nuevo, pero por alguna razón, muchas compañías continúan cometiendo tales errores. Y luego se sorprenden de que una persona con gran experiencia cometa errores molestos. Es lógico establecer mi analogía favorita con los deportes: un jugador profesional sabe cómo patear la pelota y dar un pase con destreza, pero sin conocer las tácticas y la estrategia del equipo no habrá sentido ni resultados. Es por eso que se necesita un entrenador para ayudar al jugador a formar parte del equipo. Si usted es un líder de equipo, la presentación de nuevas personas al equipo debe recaer en usted. Falta de tiempo y otras razones, estas son solo excusas. Este es un proceso realmente importante que nadie arreglará para usted.

Historias de vida

A continuación compartiré casos instructivos de mi propia práctica. Tampoco tuve éxito inmediatamente en la depuración del proceso, fui a esto por errores.

Sobre plantear un proyecto

Cuando mi equipo era muy pequeño, para los nuevos empleados, levantamos todos los servicios desde cero en cada máquina. Por supuesto, pasé mucho tiempo o se lo quité a mis colegas cuando les pedí ayuda. Con el crecimiento de la empresa y el departamento de TI, esto se convirtió en un dolor de cabeza.

Lo admito, me perdí este momento. Además, esto causó problemas no solo con los principiantes. Cuando uno de los empleados necesitaba aumentar el servicio que otro equipo estaba escribiendo, estaban listos para dispararse. ¿Y si de inmediato era necesario reunir una docena? Decidí la situación radicalmente: transfirí toda la infraestructura a Docker. Sí, no fue fácil, dedicamos mucho tiempo y esfuerzo, pero gran parte se ahorró en el futuro. Seleccionamos las configuraciones óptimas del proyecto y cada una proporcionó instrucciones detalladas sobre cómo implementar y aumentar.

Como resultado, nuestros 15 servicios internos se implementaron en 20-30 minutos. Es decir, los recién llegados saltaron sin dolor una de las etapas de adaptación en un nuevo lugar. Muchos incluso se sorprendieron al recordar su experiencia pasada. Ese fue el mejor elogio para mí. Por cierto, conozco muchas compañías en las que los recién llegados se lanzaron solos con el proyecto, ¡y tuvieron que pasar una semana entera criándolos!

Acerca de la documentación

Probablemente, como todos los demás, al comienzo del proyecto no teníamos ninguna documentación. Y aunque el equipo era pequeño y el servicio tenía una funcionalidad modesta, no hubo problemas. Pero después de dos años, cuando se cambiaron a otras partes del proyecto, los propios desarrolladores no entendieron cómo funcionaban esas partes del servicio que no habían tocado durante mucho tiempo. Fue aún más difícil contarles a los nuevos empleados sobre el proyecto. Especialmente cuando consta de 15 servicios que funcionan de diferentes maneras y en diferentes tecnologías.

En la primera etapa de resolución del problema, se grabaron videos de capacitación para todos los empleados de todos los departamentos. Se permitió a los programadores ver todo para que entendieran cómo se organizaba el trabajo de los servicios desde el punto de vista del usuario. Esto ahorró mucho tiempo, no fue necesario hablar durante mucho tiempo, 10 minutos fueron suficientes para responder preguntas después de ver.

Luego preparamos la documentación en dos versiones: para principiantes y extendida para todos los demás. El primero era esencialmente una hoja de trucos simple para la etapa inicial de introducir a una persona en el equipo, donde los recién llegados podían encontrar todas las cosas más importantes. Y la segunda versión extendida, todos ya la han usado. Todo se describió allí: desde la arquitectura y las instrucciones para implementar proyectos hasta los sutiles matices técnicos del uso de ciertas tecnologías. Más tarde, crearon otro documento grande que describía la interacción de todos los componentes de nuestro sistema común.

Podemos decir que al principio no hubo búsqueda en el muelle grande, fue extremadamente incómodo de usar, por lo que todo se transfirió al motor Wiki. Con una organización adecuada, y esto tampoco fue posible en el primer intento, todo resultó ser muy conveniente y asequible. Más tarde agregamos documentos adicionales para diferentes departamentos. Y luego nuestra documentación se convirtió en una base de conocimiento completa. Por ejemplo, si necesita configurar la replicación en algunos de los servicios, encontrará el artículo necesario con instrucciones y ejemplos.

Cada empleado podía agregar y editar documentos, había personas responsables que controlaban la relevancia de la información, pero casi todos estaban involucrados en el proceso de una forma u otra. Es importante tener en cuenta un punto clave aquí: el conocimiento no debe estar bloqueado en una sola persona, esta es la forma de llegar a ninguna parte. Puede enfermarse o renunciar, luego, en su ausencia, puede ocurrir un colapso de la información.

Ya dejé esa compañía hace mucho tiempo, pero la base está viva, los empleados la usan constantemente.

Sobre la comodidad

Una vez que llegué a un nuevo trabajo como programador ordinario, me complació cuando intentaron crear condiciones cómodas y me explicaron todo. Pero fue cuando los plantaron en el lugar de trabajo y los dejaron solos con el proyecto. Se enfureció terriblemente. Pero la gerencia no vio esto como un problema.

Recordando mi experiencia, siempre trato de escuchar a las personas y crear condiciones cómodas. Por ejemplo, era tal que una persona carecía de buenos auriculares con cancelación de ruido o una silla con respaldo. En mi práctica, incluso había una historia cuando un programador llegó a PHP, pero en el fondo quería hacer JS. Estaba reformando el departamento, y la persona tenía una excelente motivación y ojos ardientes. Como resultado, lo transferí a una posición diferente, todos estaban satisfechos.

Los muchachos que vinieron a mi departamento realmente apreciaron esta actitud. Dijeron que todo era muy complicado para nosotros, pero gracias a una introducción tan suave al curso del trabajo y la ayuda de otros empleados, rápidamente dominaron el equipo.

Creo que mucha comunicación buena y una atmósfera amigable en el equipo ayuda mucho. El Líder del equipo debe vivir con el equipo, CTO con TL y procesos, probablemente solo entonces habrá un idilio.

Proyecto de prueba de manejo

Hay casos tan desafortunados cuando se ingresa a una nueva persona en la empresa, pero ya en el proceso de trabajo resulta que o no es adecuado para el proyecto, o el proyecto no le conviene por alguna razón. Por supuesto, la situación no es ordinaria, pero a veces sucede.

Para minimizar los riesgos para ambas partes, introduje una práctica como un día de prueba. Utilizamos este enfoque cuando había dudas. Es decir, un especialista podría trabajar un día para probar un nuevo proyecto para él, para ver cómo funciona todo. A su vez, incluso en tan poco tiempo, podríamos evaluarlo exhaustivamente.

Un ingeniero puede tener muchas razones por las que no le gusta el proyecto. Por ejemplo, puede que no quiera trabajar con Legacy, puede que no le gusten los enfoques de desarrollo y, finalmente, la atmósfera en el equipo puede no ser adecuada para él. Y sucede que una persona no tiene suficientes razones para irse después de un período de prueba. Él permanece, pero siente incomodidad o descontento.

Para excluir tales situaciones, pasamos días de prueba. La gente simplemente se tomó un descanso y vino a nosotros para tratar de trabajar. En este caso, hubo incluso menos tiempo para familiarizarse con el proyecto, por lo que les presentamos el curso de las cosas en un programa acelerado. Esto valió la pena: en caso de duda después de la entrevista, nosotros, junto con el candidato, tomamos la decisión correcta. Por lo tanto, no corría el riesgo de perder su trabajo existente y entrar en un proyecto que no le gustaba, y ahorramos muchos recursos si la persona eventualmente no se convirtió en miembro del equipo. Por cierto, otras empresas utilizan un enfoque similar.

Conclusiones

En diferentes compañías, los flujos de trabajo son muy diferentes, también en todas partes tiene su propia especificidad y arquitectura. Por lo tanto, incluso los profesionales más duros necesitan tiempo para adaptarse. Su tarea es hacerla lo más efectiva posible y reducirla a tiempo tanto como sea posible. Por lo tanto, vale la pena dedicar tiempo a depurar un proceso como ingresar a un nuevo empleado en un equipo. Si no ha tomado medidas en esta dirección, intente hacerlo lo antes posible. Esto le ahorrará mucho tiempo en el futuro. Y no importa cuántas personas trabajen en la empresa, 10 o 1000. También es importante comprender que si no hay nadie para hacer esto, la responsabilidad aún recae en el líder del equipo.

¡Mi equipo logró reducir el tiempo de entrada a tres días! Después de tan poco tiempo, una persona se unió al equipo y asumió las tareas actuales. No existe una receta universal, en cada situación su plan funcionará. Pero en mi opinión, los aspectos clave son la preparación cuidadosa para el reclutamiento de nuevos empleados (documentación, configuración del entorno, hardware), la creación de condiciones cómodas, el conocimiento competente del proyecto y el apoyo de colegas y, por supuesto, el líder del equipo.

PD ¿Qué sucede si tienes historias interesantes, divertidas o instructivas sobre cómo te presentaron al equipo? Grabar en los comentarios! :)

Mis otros artículos de gestión de TI:

¿Qué es ser un líder de equipo?
Equipo de ensueño desde cero: contratar profesionales de TI
Cómo crear y administrar equipos exitosos
Grow, Team Leader, grande y pequeño