Casi todo el equipo de desarrollo de Skyeng, compuesto por más de 100 personas, trabaja de forma remota y los requisitos para los especialistas siempre han sido altos: buscábamos seniors, desarrolladores fullstack y mid-level. Pero a principios de 2019, por primera vez contratamos a tres juniors. Esto se hizo por varias razones: contratar solo a superespecialistas no resuelve todos los problemas, y para crear una atmósfera saludable en el desarrollo se necesitan personas de diferentes niveles de profesionalismo.
Cuando trabajas de forma remota, es crucial que una persona llegue al proyecto y comience a aportar valor de inmediato, sin largos procesos de capacitación y adaptación. Con los juniors esto no es así, además, aparte de la capacitación, también se requiere una correcta integración del novato en el equipo, ya que todo le resulta nuevo. Y eso es una tarea aparte para el líder del equipo. Por lo tanto, nos centramos en la búsqueda y contratación de desarrolladores más experimentados y ya establecidos. Pero con el tiempo nos dimos cuenta de que en equipos compuestos solo por seniors y desarrolladores fullstack también hay sus problemas. Por ejemplo, ¿quién se encargará de las tareas rutinarias pero obligatorias que no requieren una supercalificación ni conocimientos especiales?
Antes, en lugar de contratar juniors, lidiábamos con freelancers.
Mientras había pocas tareas, nuestros seniors se apretaban los dientes y asumían esas tareas que no les interesaban, ya que el desarrollo debe avanzar. Pero eso no podía continuar por mucho tiempo: los proyectos crecían y aumentaba el número de tareas rutinarias y simples. La situación empezó a parecerse cada vez más a un chiste, cuando los clavos se clavan con un microscopio en vez de un martillo. Para ilustrarlo, tomemos la aritmética: si contratas a una persona cuyo tarifario es de 50$/hora para trabajos que podría realizar un empleado con una tarifa de 10$/hora, entonces tienes un problema.
Lo más importante que hemos aprendido de esta situación es que la actual paradigma de contratar solo a los mejores especialistas no resuelve nuestros problemas con las tareas rutinarias. Necesitamos a alguien que esté dispuesto a realizar el trabajo que los experimentados séniores consideran una carga y que en verdad no les resulta eficiente delegar. Por ejemplo, escribir bots para los Slack de nuestros profesores y creadores de cursos o encargarse de pequeños proyectos de mejoras para necesidades internas, que los desarrolladores siempre están demasiado ocupados para atender, pero cuya vida sería mucho más agradable.
En ese momento se desarrolló una solución intermedia. Comenzamos a involucrar freelancers en nuestros proyectos. Precisamente esas tareas simples y no urgentes estaban siendo externalizadas: arreglar algo aquí, verificar allá, reescribir algo. Nuestro departamento de freelancing creció de manera bastante activa. Uno de nuestros project managers recopilaba tareas de diferentes proyectos y las asignaba a los freelancers, basándose en la base de datos de ejecutores disponible. Entonces, nos parecía una buena solución: aliviamos la carga de los séniores y pudieron volver a ser creativos, en lugar de estar lidiando con asuntos elementales. Por supuesto, había tareas que no podían ser delegadas a ejecutores externos debido a la confidencialidad comercial, pero esas cuestiones eran mucho menos en comparación con la cantidad de tareas que se estaban yendo a freelancing.
Pero esto no podía continuar para siempre. La empresa se enfrentó al hecho de que el departamento de freelancers se había convertido en un monstruo torpe. La cantidad de tareas rutinarias simples creció junto con los proyectos y en algún momento se volvió demasiado para distribuirlas de manera eficiente entre ejecutores externos. Además, los freelancers no están inmersos en la especificidad de los proyectos, lo que conlleva un gasto constante de tiempo en la incorporación. Es evidente que cuando en su equipo hay más de 100 desarrolladores profesionales, no puede contratar ni a medio centenar de freelancers y gestionar su actividad de manera efectiva. Además, la interacción con freelancers siempre conlleva ciertos riesgos de incumplimiento de plazos y otros problemas organizativos.
Es importante señalar que un empleado a distancia y un freelancer son dos entidades diferentes. Un trabajador remoto está completamente integrado en la empresa, tiene un horario de trabajo definido, un equipo, un superior, etc. Un freelancer, en cambio, trabaja por proyecto, regido principalmente por plazos. A diferencia del empleado remoto, el freelancer generalmente está más solo y tiene poca interacción con el equipo. De ahí surgen los riesgos potenciales al interactuar con estos profesionales.
Cómo llegamos a crear el 'departamento de tareas simples' y qué hemos logrado
Al analizar la situación actual, llegamos a la conclusión de que necesitamos empleados de menor calificación. No tenemos ilusiones de que de todos los juniors lleguemos a formar futuras superestrellas, o que contratar a una decena de juniors nos costará solo unos pocos centavos. En realidad, la situación con los juniors es la siguiente:
- A corto plazo, contratarlos no es rentable. En lugar de cinco o diez juniors 'justo ahora', es mejor contratar a un senior y pagarle millones por un trabajo de calidad, que gastar presupuestos en principiantes.
- Los juniors tienen un largo periodo de adaptación al proyecto y de formación.
- En el momento en que un junior aprende algo y supuestamente debe comenzar a 'recuperar' la inversión en él durante los primeros seis meses de trabajo, debe ser ascendido a mid, o se va a esa posición en otra empresa. Así que la contratación de juniors solo es adecuada para organizaciones maduras que estén dispuestas a invertir en ellos sin garantías de obtener beneficios a corto plazo.
Pero hemos crecido hasta el punto en que no podemos prescindir de los juniors en el equipo: la cantidad de tareas rutinarias aumenta, y gastar horas-hombre de profesionales consumados en ellas es simplemente un delito. Por eso creamos un departamento específicamente para desarrolladores junior.
El período de trabajo en el departamento de tareas simples está limitado a tres meses, es decir, es el período de prueba estándar. Después de tres meses de trabajo remunerado, el nuevo empleado es enviado al equipo que desea contar con él como desarrollador junior, o nos separamos.
A la cabeza del departamento que hemos creado se encuentra un experimentado PM, que es responsable de la distribución de las tareas a los juniors y de su interacción con otros equipos. El junior recibe una tarea, la ejecuta y recibe retroalimentación tanto del equipo como de su gerente. En la etapa de trabajo en el departamento, no asignamos tareas sencillas a los novatos en equipos y proyectos específicos; tienen acceso a todo el conjunto de tareas según sus habilidades (actualmente estamos contratando front-enders en AngularJS, back-enders en PHP o buscando candidatos para el puesto de desarrollador web con ambos lenguajes) y pueden trabajar en varios proyectos a la vez.
Pero la contratación de juniors no es lo único que nos importa: también hay que crear condiciones de trabajo adecuadas, y eso ya es una tarea de otra magnitud.
Lo primero con lo que nos definimos fue el mentorazgo voluntario en cantidades razonables. Es decir, además de que no obligamos a nadie de los especialistas existentes a ser mentores, se dejó claro que la formación de un novato no debería sustituir el trabajo principal. Nada de ‘50% del tiempo trabajando, 50% enseñando al junior’. Para tener una idea clara del tiempo que se dedicará al mentorazgo, se elaboró un pequeño ‘plan de estudios’: una lista de tareas que cada mentor debía completar con su aprendiz. Lo mismo se hizo para el project manager de los juniors, y al final obtuvimos un escenario bastante fluido y comprensible para la preparación de novatos y su integración en el trabajo.
Hemos considerado los siguientes aspectos: verificación de conocimientos teóricos, preparación de un conjunto de materiales, en caso de que el junior necesite aprender algo más, y aprobación de un principio único para realizar revisiones de código para los mentores. En cada etapa, los líderes brindan retroalimentación al novato, lo cual es extremadamente importante para el mismo. El joven empleado entiende en qué aspectos es fuerte y en cuáles debe prestar más atención. Para facilitar el proceso de aprendizaje para juniors y desarrolladores experimentados, se creó un chat común en Slack, de modo que otros miembros del equipo pueden unirse al proceso de aprendizaje y responder alguna pregunta en lugar del mentor. Todo esto hace que trabajar con juniors sea un proceso perfectamente predecible y, lo que es igualmente importante, controlable.
Al finalizar el período de prueba de tres meses, el mentor lleva a cabo una última entrevista técnica con el junior, donde se decide si puede pasar a un trabajo permanente en uno de los equipos o no.
Total
A primera vista, nuestro departamento para juniors se asemeja a un incubadora o a un parque de arena creado especialmente. Pero en realidad, es un departamento real con todos los atributos de un equipo de combate completo, que aborda tareas reales y no de entrenamiento.
Pero lo más importante es que damos a las personas un horizonte concreto. El departamento de tareas simples no es un limbo infinito en el que uno pueda quedarse atrapado para siempre. Hay un plazo claro de tres meses, durante el cual el junior resuelve tareas simples en proyectos, pero al mismo tiempo puede destacarse y unirse a algún equipo. Los nuevos empleados que contratamos saben que tendrán su propio gerente de proyecto, un mentor senior (o incluso varios) y la oportunidad de integrarse completamente en un colectivo donde serán bienvenidos y esperados.
Desde principios de año, se han contratado 12 juniors en el departamento de tareas simples, solo dos no superaron el período de prueba. Otro chico no se adaptó al equipo, pero dado que es muy capaz en cuanto a trabajo, lo reincorporamos al departamento de tareas simples por un nuevo período, durante el cual, esperamos, encontrará un nuevo equipo. El trabajo con juniors también ha tenido un impacto positivo en nuestros desarrolladores experimentados. Algunos de ellos, después de un período de mentoría, descubrieron en sí mismos fuerzas y deseos de probarse en roles de liderazgo, y otros, al observar a los juniors, mejoraron sus propios conocimientos y pasaron de ser intermedios a seniors.
Solo vamos a expandir nuestra práctica de contratación de jóvenes desarrolladores, ya que esto brinda numerosas ventajas al equipo. Los juniors tienen la oportunidad de un empleo remoto completo sin importar su región de residencia: los miembros de nuestros equipos de desarrollo viven desde Riga hasta Vladivostok y manejan muy bien la diferencia horaria gracias a los procesos bien establecidos dentro de la empresa. Todo esto abre la puerta a personas talentosas que residen en ciudades y pueblos lejanos. Además, no se trata solo de graduados recientes o estudiantes, sino también de personas que han decidido cambiar de profesión por alguna razón. Nuestro junior puede tener tanto 18 como 35 años, ya que ser junior se relaciona con la experiencia y las habilidades, no con la edad.
Estamos convencidos de que nuestro enfoque se puede replicar de manera segura en otras empresas que utilizan el modelo de desarrollo remoto. Permite, al mismo tiempo, contratar de manera selectiva a jóvenes talentos desde cualquier parte de Rusia o la CEI, mientras se desarrollan las habilidades de mentoría de los desarrolladores experimentados. Desde un punto de vista financiero, esta historia es extremadamente económica, por lo que todos salen beneficiados: la empresa, nuestros desarrolladores y, por supuesto, los juniors que no tienen que mudarse a grandes ciudades o capitales para formar parte de un equipo experimentado y trabajar en proyectos interesantes.
Fuente: habr.com
