Ola a todos! Chámome Lyudmila Makarova, son xestor de desenvolvemento da UBRD e un terzo do meu equipo son "xeralistas".
Admíteo: cada Tech Lead soña con funcionalidades cruzadas dentro do seu equipo. É tan xenial cando unha persoa pode substituír tres, e incluso facelo de forma eficiente, sen atrasar os prazos. E, sobre todo, aforra recursos!
Parece moi tentador, pero é realmente así? Imos tentar descifralo.
Quen é el, o noso precursor de expectativas?
O termo "xeralista" refírese xeralmente aos membros do equipo que combinan máis dunha función, por exemplo, analista-desenvolvedor.
A interacción do equipo e o resultado do seu traballo dependen das calidades profesionais e persoais dos participantes.
Todo está claro sobre as habilidades duras, pero as habilidades blandas merecen unha atención especial. Eles axudan a atopar un enfoque para un empregado e dirixilo para a tarefa onde lle será máis útil.
Hai moitos artigos sobre todo tipo de personalidades na industria das TIC. Segundo a miña experiencia, dividiría os xeneralistas de TI en catro categorías:
1. "Universal - Todopoderoso"
Estes están en todas partes. Son sempre moi activos, queren ser o centro de atención, preguntan constantemente aos seus compañeiros se precisan da súa axuda, e ás veces mesmo poden resultar molestos. Só lles interesan tarefas significativas, participando nas que darán espazo á creatividade e poden divertir o seu orgullo.
En que son fortes:
- son capaces de resolver problemas complexos;
- mergullarse profundamente no problema, "cavar" e conseguir resultados;
- ter unha mente inquisitiva.
Pero:
- emocionalmente lábil;
- mal xestionado;
- teñen o seu propio punto de vista inquebrantable, que é moi difícil de cambiar;
- É difícil conseguir que alguén faga unha cousa sinxela. As tarefas fáciles feren o ego do todopoderoso.
2. "Universal: descubrirei e facelo"
Estas persoas só necesitan un manual e un pouco de tempo, e resolverán o problema. Normalmente teñen unha sólida formación en DevOps. Estes xeneralistas non se preocupan co deseño e prefiren utilizar un método de desenvolvemento baseado unicamente na súa experiencia. Poden discutir facilmente co responsable técnico sobre a opción elixida para implementar a tarefa.
En que son fortes:
- independente;
- resistente ao estrés;
- competente en moitas cuestións;
- erudito - sempre hai algo que falar con eles.
Pero:
- moitas veces viola as obrigas;
- tenden a complicalo todo: resolver a táboa de multiplicar integrando por partes;
- a calidade do traballo é baixa, todo funciona 2-3 veces;
- Cambian constantemente os prazos, porque en realidade todo non é tan sinxelo.
3. "Universal - vale, déixame facelo, xa que non hai ninguén máis"
O empregado está ben versado en varias áreas e ten experiencia relevante. Pero non consegue converterse en profesional en ningún deles, porque adoita utilizarse como salvavidas, taponando buratos nas tarefas actuais. Flexible, eficiente, considérase demandado, pero non o é.
Un empregado ideal práctico. O máis probable é que teña unha dirección que máis lle gusta, pero debido á difuminación das competencias, o desenvolvemento non se produce. Como resultado, unha persoa corre o risco de ser non reclamada e emocionalmente queimada.
En que son fortes:
- son responsables;
- orientado a resultados;
- calma;
- totalmente controlado.
Pero:
- mostrar resultados medios debido a un baixo nivel de competencias;
- non pode resolver problemas complexos e abstractos.
4. "Un todoterreo é un mestre do seu oficio"
Unha persoa cunha experiencia seria como programador ten pensamento de sistemas. Pedante, esixente consigo mesmo e co seu equipo. Calquera tarefa que o implique pode crecer indefinidamente se non se definen os límites.
Coñece ben a arquitectura, selecciona un método de implementación técnica, analizando coidadosamente o impacto da solución elixida na arquitectura actual. Modesto, non ambicioso.
En que son fortes:
- mostrar alta calidade do traballo;
- capaz de resolver calquera problema;
- moi eficiente.
Pero:
- intolerante coas opinións dos demais;
- maximalistas. Intentan facer todo ben, e isto aumenta o tempo de desenvolvemento.
Que temos na práctica?
Vexamos como se combinan con máis frecuencia roles e competencias. Tomemos un equipo de desenvolvemento estándar como punto de partida: PO, xestor de desenvolvemento (responsable técnico), analistas, programadores, probadores. Non consideraremos o propietario do produto e o responsable técnico. O primeiro é debido á falta de competencias técnicas. O segundo, se hai problemas no equipo, debería poder facelo todo.
A opción máis común para combinar/fusionar/combinar competencias é analista-desenvolvedor. Analista de probas e "tres nun" tamén son moi comúns.
Usando o meu equipo como exemplo, mostrareivos os pros e os contras dos meus compañeiros xeneralistas. Hai un terzo deles no meu equipo, e quéroos moito.
PO recibiu unha tarefa urxente para introducir novas tarifas nun produto existente. O meu equipo ten 4 analistas. Daquela, un estaba de vacacións, o outro enfermo e o resto dedicábanse á execución de tarefas estratéxicas. Se os retirase, inevitablemente interrompería os prazos de implementación. Só había unha saída: usar a "arma secreta": un programador-analista versátil que dominaba a área temática requirida. Chamémoslle Anatoly.
O seu tipo de personalidade é "universal: descubrireino e facelo". Por suposto, intentou durante moito tempo explicar que "ten unha chea de tarefas atrasadas", pero pola miña decidida decisión enviárono para resolver un problema urxente. E Anatoly fíxoo! Realizou a posta en escena e completou a implantación a tempo, e os clientes quedaron satisfeitos.
A primeira vista, todo funcionou. Pero despois dunhas semanas, os requisitos de mellora xurdiron de novo para este produto. Agora a formulación deste problema foi realizada por un analista "puro". Na fase de proba do novo desenvolvemento, durante moito tempo non puidemos entender por que estabamos tendo erros ao vincular novas tarifas, e só entón, despois de desentrañar toda a maraña, chegamos ao fondo da verdade. Perdemos moito tempo e perdemos os prazos.
O problema era que moitos momentos e trampas ocultos quedaron só na cabeza da nosa camioneta e non foron trasladados ao papel. Como Anatoly explicou máis tarde, tiña demasiada présa. Pero a opción máis probable é que xa se atopou con problemas durante o desenvolvemento e simplemente os ignorou sen reflectir isto en ningún lado.
Houbo outra situación. Agora só temos un probador, polo que algunhas tarefas teñen que ser probadas por analistas, incluídos xeneralistas. Polo tanto, dei unha tarefa ao Fedor condicional: "universal - vale, déixame facelo, xa que non hai ninguén máis".
Fedor é un "tres nun", pero xa se asignou un desenvolvedor para esta tarefa. Isto significa que Fedya tivo que combinar só un analista e un probador.
Recopiláronse os requisitos, a especificación foi sometida a desenvolvemento, é hora de probar. Fedor sabe que o sistema se está modificando "como a palma da súa man" e traballou a fondo os requisitos actuais. Polo tanto, non se molestou en escribir guións de proba, senón que realizou probas sobre "como debería funcionar o sistema", para despois transmitirllo aos usuarios.
A proba completouse, a revisión pasou a produción. Máis tarde descubriuse que o sistema non só suspendeu os pagos a determinadas contas de saldo, senón que tamén bloqueou os pagos de contas internas moi raras que non debían participar nesta.
Isto ocorreu debido ao feito de que Fedor non comprobou como "o sistema non debería funcionar", non elaborou un plan de proba ou listas de verificación. Decidiu aforrar tempo e confiar nos seus propios instintos.
Como tratamos os problemas?
Situacións como estas afectan o rendemento do equipo, a calidade do lanzamento e a satisfacción do cliente. Polo tanto, non poden quedar sen atención e análise dos motivos.
1. Para cada tarefa que causou dificultades, pídoche que enche un formulario unificado: un mapa de erros, que permite identificar a fase na que se produciu a "destracción":
2. Despois de identificar os pescozos de botella, realízase unha sesión de reflexión con cada empregado que influíu no problema: "Que cambiar?" (non consideramos casos especiais retrospectivamente), como consecuencia dos cales nacen accións concretas (específicas para cada tipo de personalidade) con prazos.
3. Introducimos normas para a interacción dentro do equipo. Por exemplo, acordamos rexistrar necesariamente toda a información sobre o progreso dunha tarefa no sistema de xestión de proxectos. Cando se modifiquen/identifiquen artefactos durante o proceso de desenvolvemento, isto debe reflectirse na base de coñecemento e na versión final das especificacións técnicas.
4. O control comezou a levarse a cabo en cada etapa (préstase especial atención ás etapas problemáticas no pasado) e automaticamente en función dos resultados da seguinte tarefa.
5. Se o resultado na seguinte tarefa non cambiou, entón non poño ao xeneralista en cuestión no papel no que afronta mal. Intento valorar a súa capacidade e ganas de desenvolver competencias neste rol. Se non atopo resposta, déixoo no papel que está máis preto del.
Que pasou ao final?
O proceso de desenvolvemento fíxose máis transparente. O factor BUS diminuíu. Os membros do equipo, traballando nos erros, vólvense máis motivados e melloran o seu karma. Imos mellorando gradualmente a calidade dos nosos lanzamentos.
Descubrimentos
Os empregados xeralistas teñen os seus pros e contras.
Pluses:
- podes pechar unha tarefa caida en calquera momento ou resolver un erro urxente en pouco tempo;
- un enfoque integrado para resolver un problema: o intérprete mírao dende a perspectiva de todos os roles;
- os xeneralistas poden facer case todo igual de ben.
Desvantaxes:
- O factor BUS aumenta;
- as competencias básicas inherentes ao rol están erosionadas. Por iso, a calidade do traballo diminúe;
- aumenta a probabilidade dun cambio de prazos, porque non hai control en cada etapa. Tamén hai riscos de facer crecer unha "estrela": o empregado confía en saber mellor que é un profesional;
- aumenta o risco de esgotamento profesional;
- moita información importante sobre o proxecto pode permanecer só "na cabeza" do empregado.
Como podes ver, hai máis carencias. Polo tanto, só uso xeralistas se non hai recursos suficientes e a tarefa é bastante urxente. Ou unha persoa ten competencias das que carecen outros, pero a calidade está en xogo.
Se se observa a regra de distribución de roles no traballo conxunto nunha tarefa, a calidade do traballo aumenta. Miramos os problemas desde diferentes ángulos, a nosa visión non está borrosa, sempre aparecen pensamentos frescos. Ao mesmo tempo, cada membro do equipo ten todas as oportunidades de crecemento profesional e de ampliación das súas competencias.
Creo que o máis importante é sentirse implicado no proceso, facer o seu traballo, aumentando pouco a pouco a amplitude das súas competencias. Non obstante, os xeneralistas nun equipo aportan beneficios: o principal é asegurarse de que combinen de forma efectiva os diferentes roles.
Deséxolles a todos un equipo autoorganizado de "mestres universais do seu oficio"!
Fonte: www.habr.com