¡Hola a todos! Mi nombre es Lyudmila Makarova, soy directora de desarrollo en la UBRD y un tercio de mi equipo son "generalistas".
Admítelo: todo líder tecnológico sueña con la funcionalidad cruzada dentro de su equipo. Es genial cuando una persona puede reemplazar a tres, e incluso hacerlo de manera eficiente, sin retrasar los plazos. Y, lo más importante, ¡ahorra recursos!
Suena muy tentador, pero ¿realmente es así? Intentemos resolverlo.
¿Quién es él, nuestro precursor de las expectativas?
El término "generalista" 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.
Todo está claro sobre las habilidades duras, pero las habilidades blandas merecen una atención especial. Ayudan a encontrar un enfoque para un empleado y lo dirigen a la tarea en la que será más útil.
Hay muchos artículos sobre todo tipo de personalidades en la industria de TI. Según mi experiencia, dividiría a los generalistas de TI en cuatro categorías:
1. “Universal – Todopoderoso”
Estos están por todas partes. Siempre son muy activos, quieren ser el centro de atención, preguntan constantemente a sus compañeros si necesitan su ayuda y, en ocasiones, incluso pueden resultar molestos. Sólo les interesan las tareas significativas, cuya participación dará lugar a la creatividad y podrá divertir su orgullo.
¿En qué son fuertes?
- son capaces de resolver problemas complejos;
- sumergirse profundamente en el problema, “excavar” y lograr resultados;
- tener una mente inquisitiva.
Pero:
- emocionalmente lábil;
- mal gestionado;
- tener su propio punto de vista inquebrantable, que es muy difícil de cambiar;
- Es difícil conseguir que alguien haga algo sencillo. Las tareas fáciles dañan el ego del todopoderoso.
2. “Universal: lo resolveré y lo haré”
Estas personas sólo necesitan un manual y un poco de tiempo y solucionarán el problema. Por lo general, tienen una sólida experiencia en DevOps. Estos generalistas no se preocupan por el diseño y prefieren utilizar un método de desarrollo basado únicamente en su experiencia. Pueden conversar fácilmente con el líder técnico sobre la opción elegida para implementar la tarea.
¿En qué son fuertes?
- independiente;
- resistente al estrés;
- competente en muchos temas;
- eruditos: siempre hay algo de qué hablar con ellos.
Pero:
- a menudo violan obligaciones;
- tienden a complicarlo todo: resuelven la tabla de multiplicar integrando por partes;
- la calidad del trabajo es baja, todo funciona 2-3 veces;
- Cambian constantemente los plazos, porque en realidad todo resulta no tan sencillo.
3. “Universal – está bien, déjame hacerlo, ya que no hay nadie más”
El empleado conoce bien varias áreas y tiene experiencia relevante. Pero no logra convertirse en un profesional en ninguno de ellos, porque a menudo se le utiliza como salvavidas, tapando agujeros en las tareas actuales. Flexible, eficiente, se considera solicitado, pero no lo es.
Un empleado práctico ideal. Lo más probable es que tenga la dirección que más le gusta, pero debido a la confusión de competencias, el desarrollo no se produce. Como resultado, una persona corre el riesgo de no ser reclamada y de agotarse emocionalmente.
¿En qué son fuertes?
- son responsables;
- orientado a los resultados;
- calma;
- completamente controlado.
Pero:
- mostrar resultados promedio debido a un bajo nivel de competencias;
- No puede resolver problemas complejos y abstractos.
4. “Un todoterreno es un maestro en su oficio”
Una persona con experiencia seria como desarrollador tiene pensamiento sistémico. Pedante, exigente consigo mismo y con su equipo. Cualquier tarea que lo involucre puede crecer indefinidamente si no se definen límites.
Conoce bien la arquitectura, selecciona un método de implementación técnica y analiza cuidadosamente el impacto de la solución elegida en la arquitectura actual. Modesto, no ambicioso.
¿En qué son fuertes?
- mostrar alta calidad de trabajo;
- capaz de resolver cualquier problema;
- muy eficiente.
Pero:
- intolerante con 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 se combinan con mayor frecuencia roles y competencias. Tomemos como punto de partida un equipo de desarrollo estándar: PO, gerente de desarrollo (líder tecnológico), analistas, programadores, evaluadores. No consideraremos al propietario del producto ni al líder técnico. El primero se debe a la falta de competencias técnicas. El segundo, si hay problemas en el equipo, debería poder hacerlo todo.
La opción más común para combinar/fusionar/combinar competencias es desarrollador-analista. También son muy habituales los tests de analista y “tres en uno”.
Usando a mi equipo como ejemplo, les mostraré los pros y los contras de mis compañeros generalistas. Hay un tercio de ellos en mi equipo y los quiero mucho.
PO recibió la tarea urgente de introducir nuevos aranceles a un producto existente. Mi equipo tiene 4 analistas. En ese momento uno estaba de vacaciones, el otro estaba enfermo y el resto se dedicaba a la ejecución de tareas estratégicas. Si los retirara, inevitablemente alteraría los plazos de implementación. Sólo había una salida: utilizar el "arma secreta": un desarrollador-analista versátil que dominara el área temática requerida. Llamémoslo Anatoly.
Su tipo de personalidad es “universal – lo resolveré y lo haré”. Por supuesto, intentó durante mucho tiempo explicar que "tiene un montón de tareas pendientes", pero por mi decisión decidida lo enviaron a resolver un problema urgente. ¡Y Anatoly lo hizo! Realizó la puesta en escena y completó la implementación a tiempo y los clientes quedaron satisfechos.
A primera vista, todo salió bien. Pero al cabo de unas semanas volvieron a surgir necesidades de mejora para este producto. Ahora bien, la formulación de este problema la llevó a cabo un analista “puro”. En la etapa de prueba del nuevo desarrollo, durante mucho tiempo no pudimos entender por qué cometíamos errores al vincular las nuevas tarifas, y solo entonces, después de desenmarañar todo el enredo, llegamos al fondo de la verdad. Perdimos mucho tiempo y no cumplimos con los plazos.
El problema fue que muchos momentos ocultos y trampas quedaron sólo en la cabeza de nuestra camioneta y no se plasmaron en el papel. Como explicó Anatoly más tarde, tenía demasiada prisa. Pero la opción más probable es que ya haya encontrado problemas durante el desarrollo y simplemente los haya ignorado sin reflejarlos en ninguna parte.
Hubo otra situación. Ahora solo tenemos un evaluador, por lo que algunas tareas deben ser probadas por analistas, incluidos los generalistas. Por lo tanto, le di una tarea al condicional Fedor: “universal – está bien, déjame hacerlo, ya que no hay nadie más”.
Fedor es un “tres en uno”, pero ya se ha asignado un desarrollador para esta tarea. Esto significa que Fedya tuvo que combinar solo un analista y un evaluador.
Se han recopilado los requisitos, la especificación se ha enviado a desarrollo, es hora de realizar pruebas. Fedor conoce el sistema que se está modificando "como la palma de su mano" y ha elaborado a fondo los requisitos actuales. Por lo tanto, no se molestó en escribir scripts de prueba, sino que realizó pruebas sobre "cómo debería funcionar el sistema" y luego las transmitió a los usuarios.
Se completó la prueba, la revisión pasó a producción. Más tarde resultó que el sistema no solo suspendió los pagos a ciertas cuentas de saldo, sino que también bloqueó los pagos de cuentas internas muy raras que se suponía que no debían participar en esto.
Esto sucedió debido al hecho de que Fedor no comprobó cómo "el sistema no debería funcionar", no elaboró un plan de prueba ni listas de verificación. Decidió ahorrar tiempo y confiar en su propio instinto.
¿Cómo afrontamos los problemas?
Situaciones como estas afectan el rendimiento del equipo, la calidad de los lanzamientos y la satisfacción del cliente. Por tanto, no se pueden dejar sin atención y análisis de los motivos.
1. Para cada tarea que causó dificultades, les pido que completen un formulario unificado: un mapa de error, que permite identificar la etapa en la que se produjo la “reducción”:
2. Después de identificar los cuellos de botella, se lleva a cabo una sesión de lluvia de ideas con cada empleado que influyó en el problema: "¿Qué cambiar?" (no consideramos casos especiales en retrospectiva), como resultado de lo cual nacen acciones específicas (específicas para cada tipo de personalidad) con plazos.
3. Hemos introducido reglas para la interacción dentro del equipo. Por ejemplo, acordamos registrar necesariamente toda la información sobre el progreso de una tarea en el sistema de gestión de proyectos. Cuando se cambian/identifican artefactos durante el proceso de desarrollo, esto debe reflejarse en la base de conocimientos y en la versión final de las especificaciones técnicas.
4. El control comenzó a realizarse en cada etapa (se presta especial atención a las etapas problemáticas en el pasado) y de forma automática en función de los resultados de la siguiente tarea.
5. Si el resultado de la siguiente tarea no ha cambiado, entonces no pongo al generalista en cuestión en el papel que se las arregla mal. Intento valorar su capacidad y deseo de desarrollar competencias en este rol. Si no encuentro respuesta, lo dejo en el rol que le resulta más cercano.
¿Que pasó al final?
El proceso de desarrollo se ha vuelto más transparente. El factor BUS ha disminuido. Los miembros del equipo, al trabajar en los errores, se motivan más y mejoran su karma. Poco a poco vamos mejorando la calidad de nuestros lanzamientos.
Hallazgos
Los empleados generalistas tienen sus pros y sus contras.
ventajas:
- puedes cerrar una tarea caída en cualquier momento o resolver un error urgente en poco tiempo;
- un enfoque integrado para resolver un problema: el intérprete lo mira desde la perspectiva de todos los roles;
- los generalistas pueden hacer casi todo igualmente bien.
desventajas:
- El factor BUS aumenta;
- las competencias básicas inherentes al puesto se erosionan. Debido a esto, la calidad del trabajo disminuye;
- la probabilidad de un cambio en los plazos aumenta, porque no hay control en cada etapa. También existen riesgos de convertirse en una “estrella”: el empleado confía en saber mejor que es un profesional;
- aumenta el riesgo de agotamiento profesional;
- Mucha información importante sobre el proyecto sólo puede permanecer "en la cabeza" del empleado.
Como puede ver, hay más deficiencias. Por lo tanto, utilizo generalistas sólo si no hay suficientes recursos y la tarea es bastante urgente. O una persona tiene competencias de las que otros carecen, pero la calidad está en juego.
Si se observa la regla de distribución de roles en el trabajo conjunto en una tarea, entonces la calidad del trabajo aumenta. Miramos los problemas desde diferentes ángulos, nuestra visión no está borrosa, siempre aparecen pensamientos nuevos. Al mismo tiempo, cada miembro del equipo tiene todas las oportunidades de crecimiento profesional y ampliación de sus competencias.
Creo que lo más importante es sentirte implicado en el proceso, hacer tu trabajo, aumentando poco a poco la amplitud de tus competencias. Sin embargo, los generalistas en un equipo aportan beneficios: lo principal es garantizar que combinen eficazmente diferentes roles.
¡Les deseo a todos un equipo autoorganizado de “maestros universales en su oficio”!
Fuente: habr.com