Contratar y poner al día a la gente en una organización de alto crecimiento puede ser una experiencia intimidante. Puede ser fácil centrar todos nuestros esfuerzos en encontrar a las personas adecuadas, sólo para pasar por alto las actividades necesarias para ayudar a los compañeros de equipo a ponerse al día una vez que se han unido.
Cuando un cliente saca el tema de la contratación con nosotros, es típicamente porque está enfrentando su próxima ola de contratación y quiere usar los datos para ayudar a acomodar ese crecimiento. Específicamente, normalmente hay dos objetivos generales que quieren alcanzar:
- Utilizar los datos para proporcionar expectativas claras en torno a los hitos de embarque (estableciendo un ritmo para cuando esperan que las personas se encuentren completamente en su equipo), y
- Utilizar los datos para proporcionar objetivos procesables y alcanzables para que los nuevos empleados los alcancen.
En la práctica, la mayoría de los gerentes tienden a crear un plan de 30/60/90 días o algo similar. Es útil pensar en lo que significa ser un miembro del equipo que contribuya plenamente y trabajar a partir de eso – donde cada hito ha articulado claramente las expectativas en torno a las actividades y comportamientos que un miembro del equipo debe exhibir en ese momento.
El tiempo de incorporación, las distintas fases y la forma en que se llevan a cabo las comprobaciones con los nuevos contratados variarán en función de los valores de la empresa y de lo que hayan experimentado históricamente con su proceso de incorporación. Pero a pesar de la variación, hay dos resultados previstos del proceso de incorporación que la mayoría de las organizaciones comparten:
- Queremos que el nuevo miembro del equipo cree soluciones y contribuya a la base de código, y
- Queremos que colaboren con sus colegas y que juntos produzcan un trabajo aún mayor.
Ambos conceptos son simples, son fáciles de entender para los nuevos empleados que se encuentran en un entorno desconocido, y son fáciles de rastrear. Hoy nos centraremos en tres métricas que proporcionan visibilidad en el proceso de incorporación: Días de actividad por semana, participación en la solicitud de extracción y relaciones públicas sin revisar.
Días activos por semana
Días activos por semana es cualquier día en el que un desarrollador contribuyó con código a un proyecto.
Hay muchas formas diferentes de trabajo de ingeniería: explorar soluciones, escribir código, revisar el trabajo de otros, discutir especificaciones y arquitectura – y para los nuevos contratados, que esencialmente empiezan con una pizarra en blanco, hay mucho que aprender sobre el código, el equipo y la organización para tener éxito en lo que fueron contratados para hacer.
Así que la intuición detrás de Días activos por semana es simple: ¿los nuevos contratados están obteniendo los recursos que necesitan para empezar a contribuir a los proyectos? Y luego, con el tiempo, ¿se sienten cómodos para asumir tareas más significativas?
Dentro de GitPrime, puedes usar el informe de la Tarjeta de Jugador para visualizar los Días Activos por Semana de un ingeniero durante el período de tiempo especificado. Dentro de ese mismo informe, también podrás ver el alcance más amplio del día de alguien y cómo está participando en el proceso de revisión del código.
Lo importante es que para el día 90, su nueva contratación está integrada en el código y aunque no lo saben todo, saben dónde buscar. Esto debería permitirles asumir la mayoría de las tareas que le pedirías a alguien con su nivel de experiencia.»
Participación en el proceso de revisión del código
La participación es el porcentaje de solicitudes de extracción en las que participó el o los examinadores. Es una medida muy dependiente del contexto; si estás viendo la participación dentro de un equipo pequeño, un individuo puede mostrar un 60% de participación, indicando que proporcionó un comentario o aprobación en tres de las 5 RP abiertas en ese equipo. Pero si se aleja el zoom para ver toda la organización, el nivel de participación de ese mismo individuo será mucho más bajo ya que no está participando en muchas de las relaciones públicas fuera de su equipo.
Queremos asegurarnos de que los nuevos empleados participen en la revisión del código como revisores y como presentadores. Queremos ver a los miembros del equipo dando y recibiendo retroalimentación, compartiendo información y aprendiendo sobre el código base, y comenzando a desarrollar un área de experiencia sobre el producto».
Queremos tomar la participación con el contexto del promedio del equipo u organización. Si el equipo al que se une este nuevo empleado tiene un promedio del 20% de participación, puede que quieras ver al individuo subir hasta el 10% en los seis meses siguientes al comienzo. Podrías entonces retroceder y establecer metas incrementales: para el día 14, te gustaría ver un 1% de participación. Para el día 30, el 2%. En los primeros 60 días quieres verlo en el 5%, y más cerca del 10% en la marca de los 90 días.
Relaciones públicas no revisadas
Las relaciones públicas sin revisar son un porcentaje de las solicitudes de extracción que no obtuvieron ninguna revisión antes de ser fusionadas. Los equipos generalmente quieren asegurarse de que los nuevos contratados reciben muchas críticas de sus relaciones públicas. Quieren asegurarse de que el código que los nuevos contratados están escribiendo es seguro y cumple con sus estándares – pero también quieren asegurarse de que los nuevos empleados están recibiendo comentarios de sus compañeros y aprendiendo sobre el código.
En un mundo ideal, las relaciones públicas nunca se fusionan sin ser revisadas, incluso cuando son relativamente pequeñas o hechas por desarrolladores más antiguos. Muchas organizaciones establecen una política y configuran su sistema para rechazar programáticamente los RP no revisados. En la práctica, el objetivo es reducir el porcentaje de RP no revisadas a cero o casi.
Queremos asegurarnos de que los nuevos ingenieros están presentando solicitudes de extracción y participando en el proceso de revisión, porque una de las mejores maneras de poner a la gente al día con una nueva base de código es mirar lo que otras personas están haciendo, y que personas más experimentadas te den su opinión».
Aaron SilvermanLíder de ingeniería en Storyblocks
Medición del proceso de embarque
Para entender cuánto tiempo le toma normalmente a alguien ponerse al día en su organización, mire los datos históricos del equipo (específicamente los días activos por semana, participación en relaciones públicas y relaciones públicas no revisadas) y vea cuánto tiempo le tomó a los miembros actuales de su equipo ponerse al día. Consiga un rango de plazos y construya sus expectativas alrededor de esos promedios históricos.
Entonces, sea flexible e itere en el proceso. Cuando las expectativas no se cumplan, manténgase curioso y trate de entender por qué – tal vez hubo un bloqueo o confusión en torno a un proyecto o forma de trabajo específico. Tengan en cuenta esas experiencias y mejoren el proceso para futuras contrataciones.
Aprovechando estos informes dentro de GitPrime, puede establecer hitos objetivos o vías de progresión que ayuden a sus directivos a comprender si están proporcionando a sus nuevos empleados los recursos que necesitan para ponerse al día con éxito.