Hoi allegearre! Myn namme is Lyudmila Makarova, ik bin in ûntwikkelingsmanager by UBRD en in tredde fan myn team binne "generalisten".
Jou it ta: elke Tech Lead dreamt fan cross-funksjonaliteit binnen har team. It is sa cool as ien persoan yn steat is om trije te ferfangen, en sels it effisjint te dwaan, sûnder deadlines te fertrage. En, wichtiger, it besparret boarnen!
It klinkt hiel ferleidend, mar is it echt sa? Litte wy besykje it út te finen.
Wa is hy, ús foarrinner fan ferwachtings?
De term "generalist" ferwiist meastentiids nei teamleden dy't mear as ien rol kombinearje, bygelyks ûntwikkelder-analist.
De ynteraksje fan it team en it resultaat fan har wurk hinget ôf fan 'e profesjonele en persoanlike kwaliteiten fan' e dielnimmers.
Alles is dúdlik oer hurde feardichheden, mar sêfte feardichheden fertsjinje spesjaal omtinken. Se helpe om in oanpak te finen foar in meiwurker en rjochtsje him op 'e taak wêr't hy it nuttichst sil wêze.
D'r binne in protte artikels oer alle soarten persoanlikheidstypen yn 'e IT-sektor. Op grûn fan myn ûnderfining soe ik IT-generalisten ferdielen yn fjouwer kategoryen:
1. "Universeel - Almachtich"
Dizze binne oeral. Se binne altyd tige aktyf, wolle it sintrum fan 'e oandacht wêze, freegje har kollega's konstant oft se har help nedich hawwe, en soms kinne se sels ferfelend wêze. Se binne allinnich ynteressearre yn betsjuttingsfolle taken, dielname oan dat sil jaan romte foar kreativiteit en kin amusearje harren grutskens.
Wat binne se sterk yn:
- kinne komplekse problemen oplosse;
- dûke djip yn it probleem, "grave" en berikke resultaten;
- hawwe in nijsgjirrige geast.
Mar:
- emosjoneel labiel;
- min beheard;
- hawwe in eigen unshakable eachpunt, dat is hiel dreech te feroarjen;
- It is dreech om ien te krijen om in ienfâldich ding te dwaan. Maklike taken dogge it ego fan 'e almachtige sear.
2. "Universeel - ik sil it útfine en doch it"
Sokke minsken hawwe gewoan in hantlieding en in bytsje tiid nedich - en se sille it probleem oplosse. Se hawwe normaal in sterke eftergrûn yn DevOps. Sokke generalisten dogge harsels net mei ûntwerp en brûke leaver in ûntwikkelingsmetoade dy't allinich basearre is op har ûnderfining. Se kinne maklik in diskusje hawwe mei de technyske lead oer de keazen opsje foar it útfieren fan de taak.
Wat binne se sterk yn:
- ûnôfhinklik;
- stress-resistant;
- kompetint yn in protte saken;
- erudite - der is altyd wat te praten mei harren.
Mar:
- faak skeine ferplichtings;
- tend to complicate alles: oplosse de multiplikaasjetabel troch yntegraasje troch dielen;
- de kwaliteit fan it wurk is leech, alles wurket 2-3 kear;
- Se feroarje konstant deadlines, om't yn werklikheid alles net sa ienfâldich blykt te wêzen.
3. "Universeel - okee, lit my it dwaan, om't d'r gjinien oars is"
De meiwurker is goed fertroud yn ferskate gebieten en hat relevante ûnderfining. Mar hy slagget net om in profesjoneel te wurden yn ien fan har, om't hy faak brûkt wurdt as in lifeline, dy't gatten yn aktuele taken stekt. Pliable, effisjint, beskôget himsels yn fraach, mar is net.
In praktyske ideale meiwurker. Meast wierskynlik hat hy in rjochting dy't hy it bêste fynt, mar troch it fervagen fan kompetinsjes komt ûntwikkeling net foar. As gefolch, in persoan it risiko te wurden unclaimed en emosjoneel útbaarnd.
Wat binne se sterk yn:
- binne ferantwurdlik;
- op resultaat rjochte;
- kalm;
- folslein kontrolearre.
Mar:
- gemiddelde resultaten sjen litte troch in leech nivo fan kompetinsjes;
- kin komplekse en abstrakte problemen net oplosse.
4. "In allrounder is in master fan syn ambacht"
In persoan mei in serieuze eftergrûn as ûntwikkelder hat systeem tinken. Pedantysk, easket fan himsels en syn team. Elke taak wêrby't him belutsen kin ûnbepaald groeie as grinzen net definieare binne.
Hy is goed bekend mei de arsjitektuer, selekteart in metoade fan technyske ymplemintaasje, analysearret de ynfloed fan 'e keazen oplossing op' e hjoeddeistige arsjitektuer soarchfâldich. Beskieden, net ambisjeus.
Wat binne se sterk yn:
- sjen litte hege kwaliteit fan wurk;
- yn steat om elk probleem op te lossen;
- hiel effisjint.
Mar:
- yntolerânsje foar de mieningen fan oaren;
- maksimalisten. Se besykje alles goed te dwaan, en dit fergruttet de ûntwikkelingstiid.
Wat hawwe wy yn 'e praktyk?
Litte wy sjen hoe't rollen en kompetinsjes meast wurde kombinearre. Litte wy in standert ûntwikkelingsteam as útgongspunt nimme: PO, ûntwikkelingsmanager (tech lead), analisten, programmeurs, testers. Wy sille de produkteigner en technyske lead net beskôgje. De earste komt troch in gebrek oan technyske kompetinsjes. De twadde, as der problemen binne yn it team, moat alles dwaan kinne.
De meast foarkommende opsje foar kombinearjen / gearfoegjen / kombinearjen fan kompetinsjes is ûntwikkelder-analist. Testanalist en "trije yn ien" binne ek heul gewoan.
Mei myn team as foarbyld, sil ik jo de foar- en neidielen fan myn kollega-generalisten sjen litte. Der binne in tredde fan harren op myn team, en ik hâld fan harren hiel folle.
PO krige in driuwende opdracht om nije tariven yn in besteand produkt yn te fieren. Myn team hat 4 analysts. Op dat stuit wie ien op fakânsje, de oare wie siik, en de rest wie dwaande mei de útfiering fan strategyske taken. As ik se útlûke, soe it ûnûntkomber de útfieringsterminen fersteure. D'r wie mar ien útwei: it "geheime wapen" te brûken - in alsidige ûntwikkelder-analist dy't it fereaske fakgebiet behearske. Litte wy him Anatoly neame.
Syn persoanlikheid type is "universeel - ik sil it útfine en doch it". Fansels besocht hy in lange tiid út te lizzen dat hy "in folsleine efterstân fan syn taken hat", mar troch myn sterke wilsbeslút waard hy stjoerd om in driuwend probleem op te lossen. En Anatoly die it! Hy hat de staging útfierd en de ymplemintaasje op tiid foltôge, en de klanten wiene tefreden.
Op it earste each slagge alles. Mar nei in pear wiken kamen wer easken foar ferbettering foar dit produkt. No de formulearring fan dit probleem waard útfierd troch in "suvere" analist. Op it poadium fan it testen fan 'e nije ûntwikkeling koenen wy in lange tiid net begripe wêrom't wy flaters hienen by it keppeljen fan nije tariven, en pas dan, nei't wy de hiele tangel ûntraffele, kamen wy nei de boaiem fan' e wierheid. Wy fergrieme in protte tiid en miste deadlines.
It probleem wie dat in protte ferburgen mominten en falkûlen allinich yn 'e kop fan ús stasjonswagon bleaunen en net op papier oerbrocht waarden. Lykas Anatoly letter útlein hie, hie er tefolle haast. Mar de meast wierskynlike opsje is dat hy al tidens de ûntwikkeling problemen tsjinkaam en se gewoan omseach sûnder dit oeral te reflektearjen.
Der wie in oare situaasje. No hawwe wy mar ien tester, dus guon taken moatte wurde hifke troch analisten, ynklusyf generalisten. Dêrom joech ik ien taak oan 'e betingst Fedor - "universeel - okee, lit my it dwaan, om't der gjinien oars is".
Fedor is in "trije yn ien", mar in ûntwikkelder is al tawiisd foar dizze taak. Dit betsjut dat Fedya allinich in analist en in tester moast kombinearje.
Easken binne sammele, de spesifikaasje is yntsjinne foar ûntwikkeling, it is tiid om te testen. Fedor wit dat it systeem wurdt wizige "lykas de rêch fan syn hân" en hat de hjoeddeistige easken yngeand útwurke. Dêrom hat er him net lestich falle mei it skriuwen fan testskripts, mar hat testen útfierd oer "hoe't it systeem moat wurkje", en joech it troch oan brûkers.
De test wie foltôge, de revyzje gie nei produksje. Letter die bliken dat it systeem net allinnich betellingen oan bepaalde saldo-akkounts ophâlde, mar ek betellingen blokkearre fan tige seldsume ynterne akkounts dy't hjir net oan meidwaan moasten.
Dit barde troch it feit dat Fedor net kontrolearre hoe't "it systeem moat net wurkje", gjin testplan of checklists opstelde. Hy besleat om te besparjen op timing en fertrouwe op syn eigen ynstinkten.
Hoe geane wy mei problemen om?
Situaasjes lykas dizze beynfloedzje teamprestaasjes, frijlittingskwaliteit en klanttefredenheid. Dêrom kinne se net ferlitten wurde sûnder oandacht en analyze fan 'e redenen.
1. Foar elke taak dy't swierrichheden feroarsake, freegje ik jo om in unifoarm formulier yn te foljen: in flaterkaart, wêrmei jo it poadium kinne identifisearje wêryn de "ôfdieling" barde:
2. Nei it identifisearjen fan knelpunten, wurdt in brainstorming sesje hâlden mei elke meiwurker dy't it probleem beynfloede: "Wat te feroarjen?" (wy beskôgje gjin spesjale gefallen efterôf), as gefolch fan hokker spesifike aksjes wurde berne (spesifyk foar elk persoanlikheidstype) mei deadlines.
3. Wy hawwe regels ynfierd foar ynteraksje binnen it team. Wy hawwe bygelyks ôfpraat om alle ynformaasje oer de fuortgong fan in taak needsaaklik op te nimmen yn it projektbehearsysteem. As artefakten wurde feroare / identifisearre tidens it ûntwikkelingsproses, moat dit reflektearre wurde yn 'e kennisbasis en de definitive ferzje fan' e technyske spesifikaasjes.
4. Kontrôle begon te wurde útfierd yn elke faze (spesjaal omtinken wurdt betelle oan problematyske stadia yn it ferline) en automatysk basearre op de resultaten fan 'e folgjende taak.
5. As it resultaat op de folgjende taak net feroare is, dan set ik de generalist yn kwestje net yn 'e rol wêryn't er min omgiet. Ik besykje syn fermogen en winsk te beoardieljen om kompetinsjes yn dizze rol te ûntwikkeljen. As ik gjin antwurd fyn, lit ik him yn 'e rol dy't him tichterby leit.
Wat barde der op it lêst?
It ûntwikkelingsproses is transparanter wurden. De BUS-faktor is ôfnommen. Teamleden, wurkje oan flaters, wurde mear motivearre en ferbetterje har karma. Wy ferbetterje de kwaliteit fan ús releases stadichoan.
befinings
Generalist meiwurkers hawwe har foar- en neidielen.
Pluses:
- jo kinne in sakke taak op elk momint slute of in driuwende bug yn koarte tiid oplosse;
- in yntegreare oanpak foar it oplossen fan in probleem: de útfierer sjocht it út it perspektyf fan alle rollen;
- generalisten kinne hast alles like goed.
Nedenberjochten:
- BUS faktor ferheget;
- de kearnkompetinsjes dy't ynherint binne oan 'e rol, wurde erodearre. Dêrtroch nimt de kwaliteit fan it wurk ôf;
- de kâns op in ferskowing yn deadlines nimt ta, omdat der is gjin kontrôle op elke poadium. D'r binne ek risiko's om in "stjer" te groeien: de meiwurker is der wis fan dat hy better wit dat hy in pro is;
- it risiko fan profesjonele burnout nimt ta;
- in soad wichtige ynformaasje oer it projekt kin bliuwe allinnich "yn 'e holle" fan de meiwurker.
Sa't jo sjen kinne, binne d'r mear tekoarten. Dêrom brûk ik generalisten allinich as d'r net genôch middels binne en de taak frijwat driuwend is. Of in persoan hat kompetinsjes dy't oaren misse, mar kwaliteit is op it spul.
As de regel fan ferdieling fan rollen wurdt waarnommen yn mienskiplik wurk oan in taak, dan nimt de kwaliteit fan it wurk ta. Wy sjogge problemen út ferskate hoeken, ús sicht is net wazig, frisse gedachten ferskine altyd. Tagelyk hat elk teamlid alle kânsen foar profesjonele groei en útwreiding fan har kompetinsjes.
Ik leau dat it wichtichste is om belutsen te fielen yn it proses, jo wurk te dwaan, stadichoan fergrutsjen fan de breedte fan jo kompetinsjes. Generalisten yn in team bringe lykwols foardielen: it wichtichste is om te soargjen dat se ferskate rollen effektyf kombinearje.
Ik winskje elkenien in selsorganisearjend team fan "universele masters fan har ambacht"!
Boarne: www.habr.com