Lo describiré usando el ejemplo del desarrollador abstracto Tom. Tom consiguió un trabajo en Internetmagazinzaden como desarrollador de PHP intermedio. La compañía hace tiendas en línea desde plantillas hasta complejas con un montón de integraciones. La empresa cuenta con todo lo mejor Agile, SCRUM, stand-ups y retro. Tom ha trabajado durante 3 meses y todo le va bien, lanzó un par de IM, incluso funcionan y los clientes están contentos.
Aquí llega una nueva tarea para el desarrollo de IM, pero con integración con CRM. Tom empieza con la tarea de integración y en algún momento no lo consigue y el plazo se alarga durante una semana. Al mismo tiempo, en el mitin general, Tom dice que "comprende el problema", esperando que ya esté cerca de una solución. Tom se vuelve hacia el desarrollador senior Mike (que no es su mentor y simplemente se sienta no muy lejos de Tom), lo dirige a los manuales y explica brevemente lo que debe hacerse.
Tom se va a leer los tutoriales y resolver el problema. Después de un par de días más, regresa con Mike con preguntas sobre la integración y las resuelven juntos.
Tom se va para solucionarlo durante un par de días, después de lo cual regresa con Mike nuevamente y le da la solución final. Mike revisa la tarea y señala algunos errores menores que Tom pronto corregirá.
Parece ser una imagen funcional, pero hay varios puntos que nos muestran que Tom ya no es un desarrollador intermedio como pensábamos antes, sino June.
- Tom pasó mucho tiempo (en este caso, una semana) lidiando con el problema y no señaló el problema a tiempo.
- No pude entender el tutorial yo mismo y en lugar de buscar en Google algunos momentos incomprensibles, fui a Mike.
- Tom pasó el tiempo de otro desarrollador en lugar de usar stand-ups y discutir sus problemas allí.
A veces, en las entrevistas para el puesto de líder de equipo, hacen la pregunta "¿Cómo se divide a los desarrolladores en junio, intermedio, senior?" Y mi respuesta es algo como esto:
- , ;
- , ;
- - .
En el caso de Tom, acaba de recibir el tutorial y la descripción de la implementación de Mike, pero no pudo resolverlo y volvió a Mike. Esta para mí fue la primera "llamada" importante que no estamos en el medio. La segunda llamada importante fue que la habilidad de "señalar un problema" es muy importante para el intermedio, y si no la posee, entonces en términos de habilidades blandas esto lo lleva de regreso a los juniors. La tercera "campana" es la actitud descuidada hacia el tiempo de otro desarrollador inherente a Juniors, que a veces no comprende la importancia de seguir el proceso y recurre al desarrollador más "amable" en lugar de ir al líder y conseguir un mentor a través de él. Esto es importante, porque quizás el desarrollador Mike está ocupado en un proyecto súper responsable o su tarea requiere una gran concentración, pero el programador John está literalmente sentado en la mesa de al lado.que acaba de terminar un proyecto y aún no ha tenido tiempo de comenzar a sumergirse en uno nuevo.
Consideremos otro caso. Vasya, desarrollador senior, ha estado trabajando en la empresa durante mucho tiempo. Vasya tiene un líder de equipo, Petya. Y dio la casualidad de que Petya es un líder muy reflexivo y no solo establece una tarea, sino que trabaja junto con un analista de sistemas en cada aspecto de la misma y solo entonces la pone a trabajar. Vasya y Petya han estado trabajando en la empresa durante 4 años y este esquema ya está en el orden de las cosas. Al mismo tiempo, Vasya implementa perfectamente las tareas de acuerdo con la especificación técnica escrita, documenta el código y se complace de que todo esté tan "bien y bien" con él.
Pero mala suerte, después de un tiempo la empresa cierra y Vasya tiene que buscar trabajo y por alguna razón comienzan a calificar a Vasya durante las entrevistas no como senior, sino como intermedio. "¿Cómo pasó esto? ¿Dónde caí? " Se pregunta a sí mismo.
Todo es simple nuevamente, Vasya perdió la habilidad de encontrar la solución óptima al problema, en 4 años el analista de sistemas y el líder del equipo solidario relajaron a Vasily tanto que esta habilidad ya no era necesaria.
¿Qué hacer en este caso? La mayoría de las veces, después de haber encontrado esto en una empresa, no debe quitarle rublos a los desarrolladores y reducir sus salarios (aunque sea indirectamente), sino que le desconcierte la pregunta "¿se puede solucionar esto?" Y si la respuesta es “no”, entonces es mejor despedirse del empleado “amablemente”, porque en algún momento estará insatisfecho con el hecho de que su salario no está creciendo, y el resto del equipo puede tener problemas con esto. Si la respuesta es sí, entonces necesitará un trabajo muy atento tanto del departamento de capacitación de personal como del líder del equipo. De hecho, en este caso, tendrá que aumentar la habilidad del empleado y hacerlo lo más suavemente posible para no herir su orgullo y darle la motivación para desarrollarse.