¡Hola a todos! Me llamo Liudmila Makarova, soy gerente de desarrollo en UBRiR y un tercio de mi equipo son «universales».
Reconozcámoslo: cada Tech Lead sueña con la multifuncionalidad dentro de su equipo. Es genial cuando una persona puede reemplazar a tres, y además hacerlo bien sin alterar los plazos. Y, lo que es más importante, ¡eso genera un ahorro de recursos!
Suena muy atractivo, pero ¿realmente es así? Tratemos de averiguarlo.
¿Quién es nuestro anticipador de expectativas?
El término «universal» generalmente se refiere a miembros del equipo que combinan más de un rol, por ejemplo, desarrollador-analista.
La interacción del equipo y el resultado de su trabajo dependen de las cualidades profesionales y personales de los participantes.
Los hard skills son claros, pero los soft skills merecen una atención especial. Ayudan a encontrar el enfoque adecuado para cada empleado y dirigirlo hacia la tarea en la que será más útil.
Hay muchos artículos sobre los diversos tipos de personalidades de los representantes de la industria tecnológica. Basándome en mi experiencia, dividiría a los universales de IT en cuatro categorías:
1. «Universal – todopoderoso»
Estos están en todas partes. Siempre muestran una gran actividad, quieren estar en el centro de atención, constantemente preguntan a sus colegas si necesitan su ayuda, a veces incluso pueden ser molestos. Solo les interesan las tareas significativas, cuya participación les dará espacio para la creatividad y alimentará su ego.
En lo que destacan:
- capaces de resolver problemas complejos;
- se sumergen profundamente en el problema, «cavan» y logran resultados;
- tienen una mente inquisitiva.
Pero:
- son emocionalmente inestables;
- son poco controlables;
- tienen un punto de vista inquebrantable que es muy difícil de cambiar;
- es complicado hacerles realizar tareas simples. Las tareas fáciles tocan el ego de los todopoderosos.
2. «Universal – me las arreglo y lo hago»
A estas personas les basta con un manual y un poco de tiempo – y resolverán el problema. Normalmente, tienen una gran experiencia como DevOps. Estos universales no se complican la vida con la planificación y prefieren utilizar un método de desarrollo basado únicamente en su experiencia. Pueden discutir con el tech lead sobre la opción elegida para implementar la tarea.
En lo que destacan:
- son independientes;
- son resistentes al estrés;
- son competentes en muchos temas;
- son eruditos; siempre hay algo de qué hablar con ellos.
Pero:
- a menudo incumplen sus compromisos;
- tienden a complicarlo todo: resuelven la tabla de multiplicar integrando por partes;
- la calidad del trabajo es baja, todo se logra a la segunda o tercera vez;
- siempre aplazan los plazos porque, en realidad, resulta que no es tan simple.
3. "Universal – está bien, déjame a mí, ya que no hay más quien lo haga"
El empleado tiene un buen conocimiento en varias áreas y la experiencia correspondiente. Pero no logra convertirse en un profesional en ninguna de ellas, ya que a menudo lo utilizan como un salvavidas, tapando huecos en tareas actuales. Es adaptable, obediente, y se considera demandado, aunque en realidad no lo es.
El empleado ideal práctico. Es probable que tenga una dirección que le gusta más, pero debido a la difuminación de las competencias, no se produce desarrollo. Como resultado, corre el riesgo de volverse obsoleto y emocionalmente agotado.
En lo que destacan:
- son responsables;
- están orientados a resultados;
- son tranquilos;
- completamente controlables.
Pero:
- muestran un resultado medio debido a su bajo nivel de competencias;
- no pueden resolver tareas complejas y abstractas.
4. "Universal – maestro de su oficio"
Persona con un sólido trasfondo en desarrollo, con pensamiento sistémico. Es meticuloso, exigente consigo mismo y con el equipo. Cualquier tarea en la que participe puede expandirse indefinidamente si no se establecen límites.
Conoce bien la arquitectura, elige el método de implementación técnica, analizando cuidadosamente el impacto de la solución elegida en la arquitectura actual. Es modesto, no ambicioso.
En lo que destacan:
- muestran una alta calidad de trabajo;
- capaces de resolver cualquier tarea;
- son muy trabajadores.
Pero:
- intolerantes a la opinión de otros;
- son maximalistas. Intentan hacerlo todo bien, lo que incrementa los plazos de desarrollo.
¿Qué tenemos en la práctica?
Veamos cómo se suelen combinar roles y competencias. Tomemos como punto de partida un equipo de desarrollo estándar: PO, gerente de desarrollo (líder técnico), analistas, programadores, probadores. No consideraremos al propietario del producto ni al líder técnico. Al primero, por la falta de competencias técnicas. El segundo, si hay problemas en el equipo, debe saber hacer todo.
La forma más común de combinar habilidades es el desarrollador-analista. También son muy frecuentes el analista-testador y el 'tres en uno'.
Usando mi equipo como ejemplo, mostraré las ventajas y desventajas de los colegas multifuncionales. En mi equipo, un tercio son así, y los aprecio mucho.
El PO dio una tarea urgente para implementar nuevas tarifas en el producto existente. En mi equipo hay 4 analistas. En ese momento, uno estaba de vacaciones, otro estaba enfermo y los demás estaban ocupados con la realización de tareas estratégicas. Si los hubiera sacado de su trabajo, inevitablemente habríamos retrasado la implementación. Solo quedaba una opción: utilizar el 'arma secreta', un desarrollador-analista multifuncional que conocía el área temática necesaria. Llamémoslo Anatoly.
Su tipo de personalidad es “multifuncional – me encargaré y lo haré”. Por supuesto, intentó explicar durante mucho tiempo que tenía 'un backlog completo de sus tareas', pero por decisión firme lo envié a resolver la tarea urgente. ¡Y Anatoly lo logró! Realizó la planificación y completó la implementación a tiempo, y los clientes quedaron satisfechos.
A primera vista, todo salió bien. Pero después de algunas semanas, surgieron nuevos requisitos para mejorar este producto. Ahora un 'analista puro' se encargaba de la planificación de esta tarea. En la etapa de prueba del nuevo desarrollo, no podíamos entender por qué teníamos errores al vincular las nuevas tarifas y solo luego, desenredando toda la madeja, llegamos a la verdad. Perdimos mucho tiempo y retrasamos los plazos.
El problema era que muchos aspectos ocultos y obstáculos solo estaban en la mente de nuestro multifuncional y no se habían trasladado a papel. Como explicó más tarde Anatoly, tenía prisa. Pero es más probable que se haya encontrado con problemas durante el desarrollo y simplemente los evitó sin documentarlos.
También hubo otra situación. Ahora solo tenemos un testador, por lo que algunos trabajos tienen que ser probados por analistas, incluidos los multifuncionales. Así que entregué una tarea al hipotético Fedor – “multifuncional – bueno, déjenme a mí, ya que no hay más quien lo haga”.
Fedor es un 'tres en uno', pero ya se había asignado un desarrollador para esta tarea. Por lo tanto, Fedor solo tenía que combinar en sí mismo el rol de analista y testador.
Los requisitos se han recopilado, la especificación ha sido enviada al desarrollo, y ha llegado el momento de probar. Fedor conoce el sistema en desarrollo «como la palma de su mano» y ha trabajado exhaustivamente en los requisitos actuales. Por lo tanto, no se molestó en escribir guiones de prueba y realizó pruebas sobre «cómo debería funcionar el sistema», y luego – se lo transmitió a los usuarios.
La prueba ha finalizado, y el desarrollo se ha enviado a producción. Más tarde se descubrió que el sistema no solo suspende los pagos en ciertos balances, sino que también bloquea los pagos de cuentas internas muy raras que no deberían estar involucradas en esto.
Esto sucedió porque Fedor no realizó la verificación de cómo «no debería funcionar el sistema», no elaboró un plan de pruebas ni listas de verificación. Decidió ahorrar tiempo y se confió en su propio instinto.
¿Cómo lidiamos con los problemas?
Estas situaciones afectan la eficiencia del trabajo en equipo, la calidad de las versiones liberadas y la satisfacción de los clientes. Por lo tanto, no se pueden dejar sin atención y análisis de las causas.
1. Para cada tarea que ha presentado dificultades, solicito que se complete un formulario unificado: una hoja de errores, que permite identificar la etapa en la que ocurrió la «caída»:
2. Después de identificar los cuellos de botella, se lleva a cabo una lluvia de ideas con cada empleado que impactó el problema, sobre «¿Qué cambiar?», (no consideramos casos particulares en la retroalimentación), de la cual surgen acciones concretas (para cada tipo de personalidad, las suyas) con plazos.
3. Hemos implementado reglas de interacción dentro del equipo. Por ejemplo, hemos acordado registrar toda la información sobre el progreso de la tarea en el sistema de gestión de proyectos. Cualquier cambio o identificación de artefactos en el proceso de desarrollo debe reflejarse en la base de conocimientos y en la versión final del documento de requisitos.
4. El control se lleva a cabo en cada etapa (se presta especial atención a las etapas problemáticas del pasado) y automáticamente según los resultados de la siguiente tarea.
5. Si el resultado de la siguiente tarea no ha cambiado, no coloco al universal en el rol en el que tiene un mal desempeño. Intento evaluar su capacidad y deseo de desarrollar competencias en ese rol. Si no encuentro respuesta, lo dejo en el rol que le queda más cercano.
¿Qué resultado se obtuvo en última instancia?
El proceso de desarrollo se ha vuelto más transparente. Ha disminuido el factor BUS. Los miembros del equipo, al trabajar en los errores, se sienten más motivados y mejoran su karma. Gradualmente estamos aumentando la calidad de nuestros lanzamientos.
Conclusiones
Los empleados polivalentes tienen sus pros y contras.
Ventajas:
- se puede cerrar una tarea pendiente en cualquier momento o resolver un error urgente en poco tiempo;
- enfoque integral para resolver la tarea: el ejecutor la aborda desde todos los roles;
- los polivalentes pueden hacer prácticamente todo de manera igualmente buena.
Desventajas:
- aumenta el factor BUS;
- se desdibujan las competencias principales inherentes al rol. Esto reduce la calidad del trabajo;
- aumenta la probabilidad de retrasos, ya que no hay control en cada etapa. También surgen riesgos de crear una 'estrella': el empleado está convencido de que sabe mejor, que es un profesional;
- aumenta el riesgo de agotamiento profesional;
- mucha información importante sobre el proyecto puede quedarse solo 'en la cabeza' del empleado.
Como ven, hay más desventajas. Por eso solo utilizo polivalentes en caso de que falten recursos y la tarea sea lo suficientemente urgente. O si la persona tiene competencias que no tienen los demás y lo que está en juego es la calidad.
Si se respeta la regla de distribución de roles en el trabajo conjunto sobre la tarea, la calidad del trabajo mejora. Miramos los problemas desde diferentes perspectivas, no nos aburrimos y siempre surgen ideas frescas. Al mismo tiempo, cada miembro del equipo tiene todas las oportunidades para el crecimiento profesional y la expansión de sus competencias.
Creo que lo más importante es sentir que uno pertenece al proceso, dedicarse a su trabajo, aumentando gradualmente la amplitud de sus competencias. Sin embargo, los polivalentes en el equipo aportan beneficios: lo principal es asegurarse de que combinen eficazmente diferentes roles.
¡Les deseo a todos un equipo autoorganizado de 'polivalentes maestros en lo que hacen'!
Fuente: habr.com
