Hola a tots! Em dic Lyudmila Makarova, sóc gerent de desenvolupament a UBRD i un terç del meu equip són "generalistes".
Admet-ho: tots els responsables tècnics somien amb una funcionalitat transversal dins del seu equip. És genial quan una persona pot substituir-ne tres, i fins i tot fer-ho de manera eficient, sense retardar els terminis. I, sobretot, estalvia recursos!
Sembla molt temptador, però és així? Intentem esbrinar-ho.
Qui és ell, el nostre precursor d'expectatives?
El terme "generalista" sol referir-se als membres de l'equip que combinen més d'una funció, per exemple, desenvolupador-analista.
La interacció de l'equip i el resultat del seu treball depenen de les qualitats professionals i personals dels participants.
Tot és clar sobre les habilitats dures, però les habilitats blanes mereixen una atenció especial. Ajuden a trobar una aproximació a un empleat i el dirigeixen a la tasca on li serà més útil.
Hi ha molts articles sobre tot tipus de personalitats a la indústria de les TI. D'acord amb la meva experiència, dividiria els generalistes informàtics en quatre categories:
1. "Universal - Totpoderós"
Aquests estan a tot arreu. Sempre són molt actius, volen ser el centre d'atenció, demanen constantment als seus companys si necessiten la seva ajuda i, de vegades, fins i tot poden ser molestos. Només els interessen tasques significatives, la participació en les quals donarà lloc a la creativitat i pot divertir el seu orgull.
En què són forts:
- són capaços de resoldre problemes complexos;
- aprofundir en el problema, "excavar" i aconseguir resultats;
- tenir una ment inquisitiva.
Però:
- emocionalment labil;
- mal gestionat;
- tenen el seu propi punt de vista inamovible, que és molt difícil de canviar;
- És difícil aconseguir que algú faci una cosa senzilla. Les tasques fàcils fan mal a l'ego del totpoderós.
2. "Universal: ho descobriré i ho faré"
Aquestes persones només necessiten un manual i una mica de temps, i solucionaran el problema. Normalment tenen una formació sòlida en DevOps. Aquests generalistes no es molesten amb el disseny i prefereixen utilitzar un mètode de desenvolupament basat únicament en la seva experiència. Poden discutir fàcilment amb el responsable tècnic sobre l'opció escollida per implementar la tasca.
En què són forts:
- independent;
- resistent a l'estrès;
- competent en moltes qüestions;
- erudit: sempre hi ha alguna cosa de què parlar amb ells.
Però:
- sovint incompleix les obligacions;
- tendeixen a complicar-ho tot: resoldre la taula de multiplicar integrant per parts;
- la qualitat del treball és baixa, tot funciona 2-3 vegades;
- Canvien constantment els terminis, perquè en realitat tot resulta que no és tan senzill.
3. "Universal: d'acord, deixa'm fer-ho, ja que no hi ha ningú més"
L'empleat està ben versat en diverses àrees i té experiència rellevant. Però no aconsegueix convertir-se en un professional en cap d'ells, perquè sovint s'utilitza com a salvavides, tapant forats en les tasques actuals. Flexible, eficient, es considera demandat, però no ho és.
Un empleat ideal pràctic. El més probable és que tingui una direcció que més li agrada, però a causa de la difuminació de les competències, el desenvolupament no es produeix. Com a resultat, una persona corre el risc de no ser reclamada i esgotada emocionalment.
En què són forts:
- responsable;
- orientat a resultats;
- calma;
- completament controlat.
Però:
- mostrar resultats mitjans a causa d'un baix nivell de competències;
- no poden resoldre problemes complexos i abstractes.
4. "Un polivalent és un mestre del seu ofici"
Una persona amb una formació seriosa com a desenvolupador té pensament de sistemes. Pedant, exigent amb ell mateix i amb el seu equip. Qualsevol tasca que l'impliqui pot créixer indefinidament si no es defineixen els límits.
Coneix bé l'arquitectura, selecciona un mètode d'implementació tècnica, analitza acuradament l'impacte de la solució escollida en l'arquitectura actual. Modesta, no ambiciós.
En què són forts:
- mostrar una alta qualitat del treball;
- capaç de resoldre qualsevol problema;
- molt eficient.
Però:
- intolerant amb les opinions dels altres;
- maximalistes. Intenten fer-ho tot bé, i això augmenta el temps de desenvolupament.
Què tenim a la pràctica?
Vegem com es combinen més sovint rols i competències. Prenem com a punt de partida un equip de desenvolupament estàndard: PO, director de desenvolupament (director tecnològic), analistes, programadors, provadors. No tindrem en compte el propietari del producte i el responsable tècnic. El primer es deu a la manca de competències tècniques. El segon, si hi ha problemes a l'equip, hauria de poder fer-ho tot.
L'opció més habitual per combinar/fusionar/combinar competències és desenvolupador-analista. Analista de proves i "tres en un" també són molt comuns.
Utilitzant el meu equip com a exemple, us mostraré els pros i els contres dels meus companys generalistes. Hi ha un terç d'ells al meu equip i els estimo molt.
PO va rebre una tasca urgent per introduir noves tarifes en un producte existent. El meu equip té 4 analistes. En aquell moment, un estava de vacances, l'altre malalt i la resta es dedicaven a la realització de tasques estratègiques. Si els retirés, inevitablement alteraria els terminis d'implementació. Només hi havia una sortida: utilitzar l'"arma secreta": un desenvolupador-analista versàtil que dominava l'àrea temàtica requerida. Diguem-lo Anatoly.
El seu tipus de personalitat és "universal: ho descobriré i ho faré". Per descomptat, durant molt de temps va intentar explicar que "té un endarreri total de les seves tasques", però per la meva decidida decisió el van enviar per resoldre un problema urgent. I Anatoly ho va fer! Va portar a terme la posada en escena i va completar la implementació a temps, i els clients van quedar satisfets.
A primera vista, tot va sortir bé. Però després d'unes setmanes, els requisits de millora van tornar a sorgir per a aquest producte. Ara la formulació d'aquest problema va ser realitzada per un analista "pur". En l'etapa de prova del nou desenvolupament, durant molt de temps no vam poder entendre per què teníem errors a l'hora d'enllaçar les noves tarifes, i només aleshores, després d'haver resolt tot l'embolic, vam arribar al fons de la veritat. Hem perdut molt de temps i hem perdut terminis.
El problema va ser que molts moments ocults i esculls només quedaven al capdavant de la nostra camioneta i no es van traslladar al paper. Com Anatoly va explicar més tard, tenia massa pressa. Però l'opció més probable és que ja es va trobar amb problemes durant el desenvolupament i simplement els va passar per alt sense reflectir-ho enlloc.
Hi havia una altra situació. Ara només tenim un verificador, de manera que algunes tasques han de ser provades per analistes, inclosos els generalistes. Per tant, vaig donar una tasca al Fedor condicional: "universal, d'acord, deixa'm fer-ho, ja que no hi ha ningú més".
Fedor és un "tres en un", però ja s'ha assignat un desenvolupador per a aquesta tasca. Això vol dir que Fedya havia de combinar només un analista i un verificador.
S'han recollit els requisits, l'especificació s'ha sotmès a desenvolupament, és hora de provar. Fedor sap que el sistema es modifica "com el dors de la mà" i ha treballat a fons els requisits actuals. Per tant, no es va preocupar d'escriure scripts de prova, sinó que va realitzar proves sobre "com hauria de funcionar el sistema", i després ho va transmetre als usuaris.
La prova es va completar, la revisió va passar a producció. Més tard va resultar que el sistema no només va suspendre els pagaments a determinats comptes de saldo, sinó que també va bloquejar els pagaments de comptes interns molt rars que no havien de participar en això.
Això va passar pel fet que Fedor no va comprovar com "el sistema no hauria de funcionar", no va elaborar un pla de proves ni llistes de verificació. Va decidir estalviar temps i confiar en els seus propis instints.
Com tractem els problemes?
Situacions com aquestes afecten el rendiment de l'equip, la qualitat del llançament i la satisfacció del client. Per tant, no es poden deixar sense atenció i anàlisi dels motius.
1. Per a cada tasca que ha causat dificultats, us demano que ompliu un formulari unificat: un mapa d'errors, que us permet identificar l'etapa en què es va produir la "reducció":
2. Després d'identificar els colls d'ampolla, es fa una pluja d'idees amb cada empleat que va influir en el problema: "Què canviar?" (no considerem casos especials en retrospectiva), com a conseqüència de les quals neixen accions concretes (específiques per a cada tipus de personalitat) amb terminis.
3. Hem introduït normes per a la interacció dins de l'equip. Per exemple, vam acordar registrar necessàriament tota la informació sobre el progrés d'una tasca al sistema de gestió de projectes. Quan es modifiquen/identifiquen artefactes durant el procés de desenvolupament, això s'ha de reflectir a la base de coneixements i a la versió final de les especificacions tècniques.
4. El control es va començar a dur a terme a cada etapa (es presta especial atenció a les etapes problemàtiques en el passat) i automàticament en funció dels resultats de la següent tasca.
5. Si el resultat de la següent tasca no ha canviat, no poso el generalista en qüestió en el paper en què s'enfronta malament. Intento valorar la seva capacitat i ganes de desenvolupar competències en aquesta funció. Si no trobo resposta, el deixo en el paper més proper a ell.
Què va passar al final?
El procés de desenvolupament s'ha tornat més transparent. El factor BUS ha disminuït. Els membres de l'equip, treballant en els errors, es motiven més i milloren el seu karma. Anem millorant gradualment la qualitat dels nostres llançaments.
Troballes
Els empleats generalistes tenen els seus pros i contres.
Plomes:
- podeu tancar una tasca enfonsada en qualsevol moment o resoldre un error urgent en poc temps;
- un enfocament integrat per resoldre un problema: l'intèrpret el mira des de la perspectiva de tots els rols;
- els generalistes poden fer gairebé tot igual de bé.
Desavantatges:
- El factor BUS augmenta;
- les competències bàsiques inherents al rol s'estan erosionant. Per això, la qualitat del treball disminueix;
- augmenta la probabilitat d'un canvi de terminis, perquè no hi ha control a cada etapa. També hi ha riscos de fer créixer una “estrella”: l'empleat confia que sap millor que és un professional;
- augmenta el risc d'esgotament professional;
- molta informació important sobre el projecte només pot romandre "al cap" de l'empleat.
Com podeu veure, hi ha més mancances. Per tant, faig servir generalistes només si no hi ha prou recursos i la tasca és força urgent. O una persona té competències que els altres manquen, però la qualitat està en joc.
Si s'observa la regla de distribució de rols en el treball conjunt en una tasca, la qualitat del treball augmenta. Mirem els problemes des de diferents angles, la nostra visió no és borrosa, sempre apareixen pensaments nous. Al mateix temps, cada membre de l'equip té totes les oportunitats de creixement professional i d'ampliació de les seves competències.
Crec que el més important és sentir-te implicat en el procés, fer la teva feina, augmentant progressivament l'amplitud de les teves competències. Tanmateix, els generalistes en equip aporten avantatges: el més important és assegurar-se que combinen de manera eficaç els diferents rols.
Desitjo a tothom un equip autoorganitzat de "mestres universals del seu ofici"!
Font: www.habr.com