Hola a todos! Mi nombre es Lyudmila Makarova, soy gerente de desarrollo en la UBRD y un tercio de mi equipo es universal.
Reconozca: cada líder tecnológico sueña con la funcionalidad cruzada dentro de su equipo. Después de todo, es genial cuando una persona puede reemplazar a tres, e incluso hacerlo cualitativamente, sin cambiar el marco de tiempo. Y, lo que es más importante, ¡ahorra recursos!
Suena muy tentador, pero ¿es realmente así? Tratemos de resolverlo.
¿Quién es él, nuestro anticipador de expectativas?
El término "generalista" generalmente se entiende como miembros del equipo que combinan más de un rol, por ejemplo, un analista de desarrollo.
La interacción del equipo y el resultado de su trabajo dependen de las cualidades profesionales y personales de los participantes.
Por habilidades duras, todo está claro, pero las habilidades blandas merecen una atención especial. Ayudan a encontrar un enfoque para un empleado y lo dirigen precisamente a la tarea en la que será más útil.
Hay muchos artículos sobre todo tipo de personalidad de representantes de la industria de TI. Según mi experiencia, dividiría los universales de TI en cuatro categorías:
1. "Universal - Todopoderoso"
Hay tales en todas partes. Siempre muestran una gran actividad, quieren estar en el centro de atención, constantemente preguntan a sus colegas si se necesita su ayuda, a veces incluso molesta. Solo están interesados en tareas importantes, cuya participación dará lugar a la creatividad y puede divertir el orgullo.
¿Qué son fuertes?
- capaz de resolver problemas complejos;
- profundamente inmerso en el problema, "cavando" y logrando el resultado;
- Poseer una mente inquisitiva.
Pero:
- emocionalmente lábil;
- mal manejado;
- tienen su propio punto de vista inquebrantable, que es muy difícil de cambiar;
- difícil hacer una cosa simple. Las tareas fáciles hieren la omnipotencia del orgullo.
2. "Station wagon - Lo resolveré y lo haré"
Estas personas tienen suficiente manual y poco tiempo, y resolverán el problema. Por lo general, tienen un gran fondo detrás de ellos como DevOps. Tales generalistas no se molestan con el diseño y prefieren usar el método de desarrollo solo en base a su propia experiencia. Pueden tomar un refrigerio fácilmente con techlide sobre la opción elegida para implementar la tarea.
¿Qué son fuertes?
- independiente
- resistente al estrés;
- competente en muchos asuntos;
- erudito: siempre hay algo de qué hablar con ellos.
Pero:
- a menudo violan obligaciones;
- tienden a complicar las cosas: resuelven la tabla de multiplicar al integrarse en partes;
- la calidad del trabajo es baja, todo resulta 2-3 veces;
- están cambiando constantemente los plazos, porque en realidad todo no resulta ser tan simple.
3. "Universal - está bien, déjame, ya que no hay nadie más”
El empleado está bien versado en varias áreas y tiene experiencia relevante. Pero no logra convertirse en profesional en ninguno de ellos, porque a menudo se lo utiliza como salvavidas, tapando agujeros para las tareas actuales. Maleable, eficiente, se considera en demanda, pero no lo es.
Práctico empleado ideal. Lo más probable es que tenga una dirección que le guste más, pero debido al desenfoque de las competencias, el desarrollo no ocurre. Como resultado, una persona corre el riesgo de no ser reclamada y agotada emocionalmente.
¿Qué son fuertes?
- son responsables
- centrado en el resultado;
- calma
- Totalmente controlado.
Pero:
- mostrar un resultado promedio debido a un bajo nivel de competencias;
- no puede resolver problemas complejos y abstractos.
4. "Universal es un maestro de su oficio"
Una persona con antecedentes serios de desarrollador tiene un pensamiento sistémico. Pedantic, exigente consigo mismo y con el equipo. Cualquier tarea con su participación puede crecer hasta el infinito, si no define límites.
Conoce bien la arquitectura, elige el método de implementación técnica y analiza cuidadosamente la influencia de la solución elegida en la arquitectura actual. Modesto, no ambicioso.
¿Qué son fuertes?
- mostrar trabajo de alta calidad;
- capaz de resolver cualquier problema;
- Muy eficiente.
Pero:
- intolerante a las opiniones de los demás;
- maximalistas Intentan hacer todo bien, y esto aumenta el tiempo de desarrollo.
¿Qué tenemos en la práctica?
Veamos cómo los roles y las competencias se combinan con mayor frecuencia. Como punto de partida, tomemos el equipo de desarrollo estándar: PO, gerente de desarrollo (experto técnico), analistas, programadores, probadores. No consideraremos al propietario del producto ni al líder técnico. El primero, debido a la falta de competencias técnicas. En segundo lugar, si hay problemas en el equipo, debería poder hacer todo.
La opción más común para combinar / fusionar / combinar competencias es un desarrollador analítico. Además, un analista probador y un tres en uno son muy comunes.
Con el ejemplo de mi equipo, les mostraré los pros y los contras de los compañeros universalistas. Hay un tercio de ellos en mi equipo, y los quiero mucho.
PO recibió una tarea urgente de introducir nuevas tarifas en un producto existente. Mi equipo tiene 4 analistas. En ese momento, uno estaba de vacaciones, el otro se enfermó y el resto estaba involucrado en la implementación de tareas estratégicas. Si los retirara, inevitablemente interrumpiría los plazos de implementación. Solo había una salida: usar el "arma secreta", el universal del analista desarrollador, que poseía el área temática necesaria. Llamémosle Anatoly.
Su tipo de personalidad es
"vagón, lo resolveré
y lo haré" . Por supuesto, trató durante mucho tiempo de explicar que tenía "un atraso completo de sus tareas", pero por decisión deliberada fue enviado a resolver una tarea urgente. ¡Y Anatoly lo hizo! Organizó y completó la implementación a tiempo, y los clientes quedaron satisfechos.
A primera vista, todo salió bien. Pero después de algunas semanas, los requisitos de revisión surgieron nuevamente en este producto. Ahora la configuración de esta tarea fue tratada por un analista "puro". En la etapa de prueba del nuevo desarrollo, durante mucho tiempo no pudimos entender por qué tuvimos errores al vincular las nuevas tarifas y solo entonces, después de desenredar todo el enredo, llegamos al fondo de la verdad. Pasamos mucho tiempo y no cumplimos con los plazos.
El problema era que muchos momentos ocultos y dificultades permanecían solo en la cabeza de nuestra camioneta y no se transferían al papel. Como Anatoly explicó más tarde, tenía prisa. Pero la opción más probable es que ya se topó con problemas durante el desarrollo y simplemente los evitó, sin reflejarlo en ningún lado.
Hubo otra situación. Ahora solo tenemos un probador, por lo que algunas tareas que los analistas deben probar, incluidos los generalistas. Por lo tanto, le di una tarea al Fedor condicional -
"universal - está bien, déjame, ya que no hay nadie más" .
Fedor: "tres en uno", pero el desarrollador ya ha sido seleccionado para esta tarea. Entonces, Feda necesitaba combinar solo un analista y un probador.
Se recopilan los requisitos, la especificación se entrega al desarrollo, es hora de probar. Fedor conoce el sistema en desarrollo "como el dorso de su mano" y resolvió minuciosamente los requisitos actuales. Por lo tanto, no se molestó en escribir scripts de prueba, sino que probó "cómo debería funcionar el sistema" y luego lo transmitió a los usuarios.
La prueba se completó, la revisión fue al baile de graduación. Más tarde resultó que el sistema no solo suspende los pagos a ciertas cuentas de saldo, sino que también bloquea los pagos de cuentas internas muy raras que no deberían haber estado involucradas en esto.
Esto sucedió debido al hecho de que Fedor no realizó una verificación de cómo "el sistema no debería funcionar", no elaboró un plan de prueba ni revisó las listas. Decidió ahorrar tiempo y confió en su propio instinto.
¿Cómo trabajamos con problemas?
Tales situaciones afectan la efectividad del equipo, la calidad de los lanzamientos y la satisfacción del cliente. Por lo tanto, no pueden ser ignorados y el análisis de las razones.
1. Para cada problema que causó dificultades, le pido que complete un formulario unificado: un mapa de errores que le permite identificar la etapa en la que ocurrió la "reducción":
2. Después de identificar los cuellos de botella, con cada empleado que influyó en el problema, una sesión de lluvia de ideas "¿Qué cambiar?" (no consideramos casos especiales en retro), como resultado de lo cual las acciones específicas (para cada tipo de personalidad) nacen con líneas de tiempo.
3. Introdujimos las reglas de interacción dentro del equipo. Por ejemplo, acordamos registrar necesariamente toda la información sobre el progreso de la tarea en el sistema de gestión del proyecto. Al cambiar / identificar artefactos durante el proceso de desarrollo, debe mostrar esto en la base de conocimientos y en la versión final de los TOR.
4. El control comenzó a llevarse a cabo en cada etapa (se presta especial atención a las etapas problemáticas en el pasado) y automáticamente en función de los resultados de la siguiente tarea.
5. Si el resultado de la siguiente tarea no ha cambiado, entonces no pongo en cuestión el vagón en el papel que desempeña mal. Trato de evaluar su habilidad y deseo de desarrollar competencias en este rol. Si no encuentro una respuesta, lo dejo en el papel más cercano a él.
Cual es el resultado?
El proceso de desarrollo se ha vuelto más transparente. Factor BUS disminuido. Los miembros del equipo, trabajando en los errores, se motivan más, mejoran su karma. Estamos mejorando gradualmente la calidad de nuestros lanzamientos.
Conclusiones
Los empleados universales tienen sus pros y sus contras.
Ventajas:- Puede cerrar la tarea de hundimiento en cualquier momento o resolver un error urgente en poco tiempo;
- un enfoque integrado para resolver el problema: el intérprete lo mira desde el lado de todos los roles;
- los generalistas pueden hacer casi todo igual de bien.
Desventajas- El factor BUS está creciendo;
- Las competencias centrales inherentes al rol se erosionan. Debido a esto, la calidad del trabajo se reduce;
- la probabilidad de un cambio en el tiempo aumenta, No hay control en cada etapa. También hay riesgos de hacer crecer una "estrella": el empleado está seguro de que sabe mejor que es un profesional;
- aumenta el riesgo de agotamiento profesional;
- Una gran cantidad de información importante sobre el proyecto solo puede permanecer "en la cabeza" del empleado.
Como puede ver, hay más defectos. Por lo tanto, uso universales solo si no hay suficientes recursos y la tarea es lo suficientemente urgente. O una persona tiene competencias que otros no tienen, y la calidad está en juego.
Si en el trabajo conjunto en una tarea se observa la regla de distribución de roles, entonces la calidad del trabajo aumenta. Observamos los problemas desde diferentes ángulos, nuestros ojos no están borrosos, siempre aparecen nuevos pensamientos. Además, 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 sentirse involucrado en el proceso, participar en su trabajo y aumentar gradualmente la amplitud de sus competencias. Sin embargo, los vagones en un equipo son beneficiosos: lo principal es asegurarse de que combinen efectivamente diferentes roles.
¡Les deseo a todos un equipo autoorganizado de "maestros universales de su oficio"!