Hola Habr! Mi nombre es Andrey Gomenyuk, soy el líder del equipo de uno de los equipos de desarrollo de servidores Badoo .

En May Badoo Techleads Meetup , dedicado a la gestión del desarrollo, compartí la experiencia de integrar a los recién llegados al equipo. Y hoy estoy compartiendo un texto complementado y una versión mejorada de mi informe.

Imagina que hoy es tu primer día de trabajo en Badoo. ¿Qué tipo de conocimiento y habilidades espera el departamento de usted, y en particular yo, el líder? Al menos tal:



Tenga en cuenta que no hay nada como "escribir en PHP" y "saber MySQL". Preguntamos sobre esto en la entrevista. Y en esta lista están todas nuestras herramientas, tecnologías y términos, así como cosas generales que probablemente no nos gusten a los demás. Y cuanto antes sepas todo esto, mejor.

Embarque en Badoo

El término incorporación significa ingresar a una persona en un equipo, presentarle el proyecto y los procesos. Dado que nuestro departamento de desarrollo de servidores se ha duplicado en los últimos años (ahora somos más de cuarenta), nos convertimos en los primeros en Badoo en preocuparnos por la adaptación intensiva de los recién llegados y su integración en el trabajo.

Destaco dos objetivos principales de la incorporación.

El primero es a corto plazo. Nosotros, como la mayoría de las compañías de TI, realmente queremos poner a la persona en el código el primer día, poner sus boletos en producción en la primera semana, para que la persona se acostumbre lo más rápido posible. Sin embargo, esto no es lo principal para nosotros.

El segundo objetivo es a largo plazo. Queremos que una persona alcance un cierto nivel de independencia lo antes posible y comience a resolver las tareas de manera efectiva.

Para hacer esto, guiamos al principiante a través de cinco etapas no muy explícitas. Pero antes de hablar sobre ellos en orden, noto dos puntos igualmente importantes.

¿Quién conocerá al recién llegado?

El primer día hábil, estamos seguros de encontrarnos con un principiante. Esto debe hacerlo el líder, y nosotros en el departamento estamos tratando de cumplir con esta regla. Lead se encuentra con un hombre, le muestra la oficina y lo presenta al equipo. Luego se lleva a cabo una reunión programada con el departamento de personal, durante la cual se redactan los documentos.


Fuente

Parece que después de esto ya es posible poner a una persona en la mesa, pero hay otro detalle importante.

¿Quién "guiará" al principiante?

En algunas empresas, todo el proceso de incorporación está "vinculado" a los mentores. Estas son las personas que explican todo, muestran qué, dónde y cómo, responden las preguntas del principiante y lo reúnen con las personas adecuadas.

No usamos ese término, pero, como dice la famosa canción, hay un mentor, pero no hay palabras. Es solo que este rol está asignado al líder, que puede delegarlo a uno de los empleados. Como regla general, un líder (o una persona designada por él) es un punto de partida para un principiante en todos los temas. Durante una breve reunión, presenta al recién llegado al proyecto, habla sobre los procesos adoptados por la empresa. Este es el comienzo de la transferencia de nuestra cultura a una persona que anteriormente trabajó en otras compañías y está acostumbrada a hacer las cosas de manera diferente. Y es muy importante que el principiante entienda qué, cómo y por qué lo hacemos.

Etapas de la incorporación

Me permitiré dividir todo nuestro proceso en varias etapas, cada una de las cuales tiene algún tipo de resultado:

• hombre sentado en una computadora portátil
  
• con un ambiente de trabajo personalizado
  
• y hace boletos.
  
• Puede diseñar una nueva característica
  
• y trabajar de forma independiente.
  

Luego, considere lo que sucede en cada etapa.

1. Laptop

Primero, queremos que el principiante se concentre en el trabajo, en lugar de pensar en algo sin importancia, y estamos tratando de hacer mucho por adelantado. Por lo tanto, nos contactamos con él por adelantado y descubrimos los deseos del equipo: lo que quiere el monitor, la computadora portátil, el teclado y el mouse. Creamos todas las cuentas para principiantes y otorgamos privilegios, lo agregamos a grupos y chats. Muchos de estos procedimientos son automáticos, mientras que otros se ingresan en las listas de verificación para que la persona no corra por la oficina el primer día, descubriendo por qué no puede ingresar a Jira o por qué no ve el boleto que se le asignó.

2. Ambiente de trabajo

Luego, la persona se sienta en la computadora portátil para establecer un entorno de trabajo. Pero toda la configuración es que ingresa a una interfaz especial, selecciona un nombre de usuario y carga una clave SSH. Listo

El hecho es que tenemos una plataforma de desarrollo, un análogo de nuestra infraestructura de producción, planteada en la oficina. Además, para emular varios DC, tenemos una plataforma de desarrollo en ambas oficinas: en Londres y en Moscú. Este enfoque tiene muchas ventajas. El desarrollador siempre tiene la versión actual del código y el último software, absolutamente igual que en la producción. Incluso si algo no funciona, puede estar seguro de que alguien ya está resolviendo el problema. El novato, de hecho, solo clona el repositorio, abre el IDE y está listo para trabajar. Es suficiente que Lida se asegure de poder entrar en todos los chats y comenzar a recibir correo.

En esta etapa, estoy listo para darle al principiante el primer boleto.

3. Entradas

Digamos que el primer boleto vino así:



O así:



Probablemente, para usted, estos boletos tienen solo una cosa en común: nada está claro. Destaqué en naranja las palabras que probablemente te causen la mayoría de las preguntas, e incluso si no, te contaré sobre ellas de todos modos.

Como era antes

Cuando vine a Badoo hace siete años, era algo así. Lead se sienta con el recién llegado y comienza a decir: "Mira, tenemos colas, un marco de secuencias de comandos. Ellos trabajan así. Presta atención a eso. En este boleto deberás hacer esto ” .

El problema es que el líder pasa su tiempo de trabajo en estas historias. Cada vez que explica lo mismo a los principiantes, siempre se olvida de algo. Cada plomo cuenta su propio camino.

Naturalmente, el líder solo dará notas introductorias específicas sobre el boleto relacionadas con este boleto, omitiendo los puntos que el principiante puede no necesitar en este momento. Si tiene suerte, este último podrá encontrar un enlace a una descripción de una herramienta. Pero por lo general, toda esa documentación está escrita para uso interno, es decir, se entiende que el usuario ya está familiarizado con los detalles. La documentación tiene muchos detalles que el principiante definitivamente no necesita en las primeras etapas. Como resultado, se desarrolló una situación paradójica: una persona trabajó durante uno o dos años en la empresa, pero no hay garantía de que se haya familiarizado con todo y sepa cómo funciona toda la infraestructura.


Fotograma de la película Groundhog Day

Además de los colegas que respondieron varias preguntas, Aleksey Rybak, que en ese momento administraba la Plataforma, dio una conferencia sobre principios básicos, infraestructura y servicios básicos para todos los nuevos empleados. En algún momento, estaba cansado de eso, y lo grabó en video. Pero en una historia de dos horas no lo tendrás todo, hay muchos detalles. Y luego esta conferencia es muy difícil de actualizar. Por supuesto, es genial que en siete años haya quedado un poco desactualizado, pero algunas partes ya no son relevantes.

En algún momento, alguien creó una página de bienvenida para nuevos desarrolladores en la Wiki. Lanzaron un montón de enlaces allí que sería bueno leerle al desarrollador.

Probablemente no me equivoque mucho si digo que en cualquier empresa hay dos fuentes principales para obtener nueva información: esta es una especie de análogo Wiki (o Google Docs) y una sala de fumadores. Desafortunadamente, solo en uno de ellos la información estará actualizada, y esto no es un Wiki.

Que nuestra página no tenía una estructura común. Se reponía así. El líder de otro equipo se me acerca y dice: “Andryukha, a tus desarrolladores les está yendo mal. Para hacerlo bien, escribí un artículo en la Wiki. Lo agregó al "Bienvenido nuevo desarrollador" para que todos sus desarrolladores lo lean " .



Naturalmente, considera que su artículo es el más importante, lo coloca en el lugar más visible y lo resalta en negrita, rojo. Como resultado, una página grande con un montón de enlaces que pueda necesitar se volcará al principiante. Con una gran cantidad de frases en negrita , DEBE LEER y "¡Se requiere lectura!".

En algún momento, nos dimos cuenta de que las conferencias, videos y wikis ya no nos satisfacen. Decidimos tomar lo mejor de estas herramientas y hacer algo nuevo. Y nos lanzó la idea correcta ... El marco de Laravel. No cuente para publicidad. Es solo que en ese momento estábamos recogiendo el marco para un proyecto, en el motor de búsqueda del "mejor marco PHP" Laravel apareció en primer lugar, y lo obtuvimos. Y en él nos gustó mucho la sección de documentación de Inicio rápido, que habla sobre los principios básicos y las herramientas disponibles en un ejemplo real (y, habiendo entendido los conceptos básicos, puede comenzar a leer la descripción detallada).

Inicio rápido

Realmente nos gustó este formato, y decidimos escribir un artículo similar para nuestros principiantes. ¿Pero cómo hacerlo? Hay mucha información: ¿cómo mantener un equilibrio entre concisión e información, mientras se mantiene la posibilidad de una actualización oportuna para que los recién llegados no tengan que extraer conocimiento en la sala de fumadores? ¿Y cómo alentar la lectura de un documento de aquellos que han estado trabajando en la empresa durante algún tiempo, pero ciertamente tienen lagunas de conocimiento?


Fuente

Comenzamos reuniendo una lista de herramientas, tecnologías y enfoques que, en nuestra opinión, todos los desarrolladores del departamento deberían conocer. Luego estructuraron la información en forma de una tabla de contenido, de simple a complejo: desde bases de datos y servicios hasta desempeño y pruebas. Luego, una persona escribió los primeros capítulos para que otros pudieran entender cómo presentar el material. Después de eso, distribuimos voluntariamente los temas restantes a otros empleados, y cada uno escribió un capítulo. El resultado fue un documento enorme, semanas solo para dos lecturas.

No pudimos encontrar una tarea común para toda la sección de Inicio rápido. Sí, sería ineficaz. Imagine que le asigna una tarea a una persona; de hecho, una gran característica que cubre todas las secciones. Trabajará en él durante un mes o dos, y todo este tiempo no puede distraerlo con boletos, y esto contradice el primer propósito de la incorporación.

Luego, en cada sección colocamos una o dos tareas que son lo más similares posible a las reales. Un principiante lee una sección, trabaja en tareas, se familiariza con herramientas específicas. Recomendamos que nuestros líderes lleven a cabo algunas de las tareas de acuerdo con el proceso estándar: se emite un ticket, una persona empuja un código, se revisa un código, una persona recibe muchos comentarios. Después de eso, la rama se elimina y con ella un ticket.

Entonces surgió la pregunta de cómo mantener la relevancia de todo este cuerpo de información. Y aquí las mismas tareas nos ayudaron. Por ejemplo, tenemos spots (fragmentos virtuales) y un servicio que se encarga de comparar usuarios y spots. En la vida normal, los desarrolladores no necesitan saber sobre esto, porque usan una API de alto nivel. Pero les exigimos que comprendan cómo funciona esto internamente.

Damos la tarea: registrar al usuario en el desarrollador, obtener el identificador de spot en su dirección de correo, obtener la información de la base de datos en el spot, entrar allí, seleccionar y ver qué hay allí. Si algo cambia en este procedimiento, los desarrolladores comunes no lo sabrán. No sabrán que necesita entrar y corregir la descripción. Pero el desarrollador que actualmente está involucrado en esto entenderá: algo está mal. Subirá a la cabeza y dirá que algo no está funcionando. El líder se sentará con él, lo resolverá, y actualizaremos el documento. Intentamos no alentar a los desarrolladores a cambiar el Inicio rápido por su cuenta, para no violar la estructura y el estilo de presentación. En su lugar, creamos un documento de Google en el que pueden escribir sus deseos. Luego, esta lista es revisada por la persona responsable que realiza cambios en nuestro artículo.

Se agrega nueva información a Inicio rápido de la misma manera: alguien encuentra una nueva herramienta que no se describe en el documento y escribe sobre ella en Google Doc. Y las personas responsables luego deciden si este es un caso especial que no es interesante para la mayoría de los desarrolladores, o si vale la pena escribir al respecto en Quick Start.

Los propios desarrolladores a veces agregan "pequeñas cosas" geniales al documento. Por ejemplo, se agregó un contador para la duración de la lectura y el número de páginas a cada capítulo. También en algunas secciones se agregaron enlaces que abren inmediatamente la clase deseada en PhpStorm.

Entonces comenzamos a pensar, ¿cómo hacer que las personas mayores estudien el documento? Después de todo, Quick Start resultó ser enorme, y nadie quería pasar dos semanas leyéndolo. Luego se nos ocurrió una prueba: sobre la base del documento, hicimos unas 100 preguntas sobre diferentes temas y a todos se les ofreció aprobarlo de forma anónima. A cada desarrollador se le dio la opción de unas 40 preguntas. El objetivo no era probar el conocimiento, sino ayudar a las personas a comprender lo que no sabían. Es decir, la prueba fue una herramienta de aprendizaje, no una prueba, y si la pregunta no fue respondida correctamente, se le ofrecieron indicaciones y enlaces de inmediato donde puede leer sobre ella en Inicio rápido.


Un ejemplo de una pregunta de una prueba.

No controlamos el paso de la prueba por parte de principiantes. Se cree que para ellos esta será la conclusión lógica para aprender Quick Start. Al mismo tiempo, mantenemos estadísticas sobre todas las respuestas. Cuando los "viejos" pasaron la prueba, seleccionamos varias preguntas que no respondieron de la manera que quisiéramos y les pedimos a los muchachos con experiencia que escribieran artículos sobre estos temas.

Inicio rápido y prueba es la parte más impresionante de nuestro proceso de incorporación.

Más entradas

Por lo general, junto con Quick Start, una persona recibe inmediatamente uno o dos boletos simples. Poco a poco, su número aumenta, y el líder asegura que los nuevos tickets correspondan a lo que el desarrollador logró familiarizarse. Por lo tanto, el proceso de lectura se diluye con un trabajo real y, en conjunto, lleva unos dos meses. Idealmente, al final del período de prueba, la persona debe conocer bien nuestra infraestructura, herramientas y enfoques.

Después de leer Quick Start, el significado de los tickets anteriores será mucho más claro para usted:



Como guía, solo necesito dar una pequeña introducción aquí: hay un campo en el lugar y un campo en el servicio, no están sincronizados para el usuario; Necesita corregir el error y sincronizar. Y el principiante ya sabe qué script ejecutar y cómo hacerlo.

O un segundo ejemplo:



Aquí lo mismo: la foto terminó en el álbum equivocado; lo más probable es que el cliente simplemente envió el álbum equivocado; debe comprender si todavía hay tales casos y solucionarlo.

Los boletos, de hecho, son simples, por una hora de trabajo.

4. Diseñando una nueva característica

Por "diseño" no me refiero a la organización de clases y código, sino a cómo el principiante trabajará con datos, dónde creará tablas, qué eventos agregará, dónde se transmitirán, a qué servicios accederá una persona. En esta etapa, el principiante está listo para tomar decisiones técnicas sobre cómo se hacen las funciones. Esto generalmente se logra mediante la práctica. Cuantas más tareas, más conocimiento y experiencia.

Es cierto que esto no siempre es posible, porque no es posible encontrar un número suficiente de tareas interesantes para cada principiante. En la prueba, estos temas son a menudo difíciles de cubrir, porque las situaciones son diferentes. En diferentes casos, necesita acceder a diferentes servicios y en todas partes sus propias características.

Como resultado, simplemente recopilamos una docena de características realmente grandes que involucraban varios servicios, colas, spots, y los desarrolladores prepararon breves descripciones para ellos (un análogo de la tarea técnica). Cuando el recién llegado está listo, el líder le da la opción de elegir una tarea. Lo reflexiona durante un tiempo e informa que está listo para discutir la solución. Se programa una reunión con el autor de la función, en la cual el desarrollador explica su esquema: lo haría, solicitaría dicho servicio, almacenaría los datos aquí, se suscribiría a tales eventos. En respuesta, el autor cuenta cómo lo hizo y a qué llamó la atención. Como resultado, el desarrollador aprende muchas cosas nuevas, comienza a asumir la imagen general. Él entiende cómo funciona este o aquel proceso, cómo tomamos decisiones. Está bien si se metió en el código por adelantado y espió cómo se implementa la característica, esto es aún más probable que sea una ventaja.

Al final de la reunión, el líder recopila comentarios y puede ofrecer al desarrollador que estudie cuidadosamente una sección y piense en lo que aprendió.

5. Trabajo independiente

La quinta etapa, de hecho, no se expresa de ninguna manera. Estas son las cosas que hacemos a lo largo de nuestro trabajo en la empresa. Realmente apreciamos el deseo del desarrollador de comunicarse con otros equipos, para descubrir cómo funciona. Si algo no funciona, debe saber a quién recurrir para obtener ayuda. La tarea del líder es presentar al recién llegado a todos, mostrar quién se sienta dónde, decir a quién y en qué caso puede contactar.


Fuente

Una persona debe ser guiada en nuestros procesos. Aunque no tenemos Scrum y Agile, el flujo de trabajo es bastante flexible. Realmente apreciamos que un desarrollador no solo siga nuestros procesos sin pensar, sino que comprenda por qué son y qué tareas resuelven. Esto le permite en algunas situaciones encontrar soluciones. Por ejemplo, para comprender que un boleto en particular se puede enviar sin realizar pruebas completas, y que el otro debe hacerse más rápido. Le decimos a quién contactar y cómo priorizar para que el boleto funcione hoy.

Esperamos del nuevo desarrollador que durante el período de prueba se familiarice con el conjunto máximo de nuestras características y componentes. Idealmente, si para cuando finaliza el período de prueba, conocerá algún componente o característica lo suficientemente profundo como para poder acompañarlo.

También agregamos de inmediato a una persona a la evaluación del desempeño , para que pueda recibir comentarios no solo de su líder, sino también de todas las personas con las que interactúa: del producto, el control de calidad y los equipos de los clientes.

Resumen

Estos son quizás los cinco componentes principales de nuestro proceso de puesta en marcha para novatos:

• Atención mínima a lo sin importancia. Hacemos todo lo posible para que una persona se concentre en el trabajo y no se distraiga con cosas pequeñas (incluidas) las del hogar.
  
• Inicio rápidoNo nos atrevimos a proceder durante mucho tiempo y pensamos que era imposible hacerlo. Pero resultó ser más fácil de lo que pensábamos, pero ya ha valido la pena muchas veces.
  
• Prueba. En términos de la relación entre los beneficios recibidos y el tiempo empleado, pierde un poco en el inicio rápido, pero también es un elemento importante del proceso de aprendizaje.
  
• Tareas prácticas.
  
• Comentarios del equipo y liderazgo. Cuanto más, mejor.
  

Resultados

, . , , , «» .

. . - . , , — .


Fuente

Que sigue

— Quick Start , , . Quick Start.

, . Quick Start , , , , , , . , - . , . , .

Finalmente, ¿recuerdas la primera imagen con un montón de términos? Probablemente pensaste: "¿Por qué tanto?" Parece que todo es demasiado complicado para nosotros y el desarrollador probablemente no necesita saber sobre todo esto. Al leer Inicio rápido, es muy fácil ver cosas que se pueden simplificar, y estamos trabajando en esta dirección.