Hei kaikki! Nimeni on Ljudmila Makarova, olen kehityspäällikkö UBRD:ssä ja kolmasosa tiimistäni on "generalisteja".
Myönnä se: jokainen tekninen johtaja haaveilee tiiminsä monipuolisesta toimivuudesta. On niin siistiä, kun yksi henkilö pystyy korvaamaan kolme ja jopa tekemään sen tehokkaasti viivyttelemättä määräaikoja. Ja mikä tärkeintä, se säästää resursseja!
Se kuulostaa erittäin houkuttelevalta, mutta onko se todella sitä? Yritetään selvittää se.
Kuka hän on, meidän odotusten edelläkävijä?
Termi "yleinen" viittaa yleensä tiimin jäseniin, jotka yhdistävät useamman kuin yhden roolin, esimerkiksi kehittäjä-analyytikko.
Ryhmän vuorovaikutus ja sen työn tulos riippuvat osallistujien ammatillisista ja henkilökohtaisista ominaisuuksista.
Kovissa taidoissa kaikki on selvää, mutta pehmeät taidot ansaitsevat erityistä huomiota. Ne auttavat löytämään lähestymistavan työntekijään ja ohjaavat hänet siihen tehtävään, jossa hänestä on eniten hyötyä.
IT-alalla on monia artikkeleita kaikenlaisista persoonallisuustyypeistä. Kokemukseni perusteella jakaisin IT-yleiset neljään kategoriaan:
1. "Universaali – Kaikkivaltias"
Näitä on kaikkialla. He ovat aina erittäin aktiivisia, haluavat olla huomion keskipisteenä, kysyvät jatkuvasti kollegoiltaan, tarvitsevatko he heidän apuaan, ja joskus he voivat jopa ärsyttää. Heitä kiinnostavat vain merkitykselliset tehtävät, joihin osallistuminen antaa tilaa luovuudelle ja voi huvittaa heidän ylpeytensä.
Missä he ovat vahvoja:
- pystyvät ratkaisemaan monimutkaisia ongelmia;
- sukeltaa syvälle ongelmaan, "kaivaa" ja saavuttaa tuloksia;
- on utelias mieli.
mutta:
- emotionaalisesti labiili;
- huonosti hoidettu;
- heillä on oma horjumaton näkökulmansa, jota on erittäin vaikea muuttaa;
- On vaikea saada joku tekemään yksinkertaisia asioita. Helpot tehtävät vahingoittavat kaikkivaltiaan egoa.
2. "Universaali – keksin sen ja teen sen"
Tällaiset ihmiset tarvitsevat vain käsikirjan ja vähän aikaa - ja he ratkaisevat ongelman. Heillä on yleensä vahva DevOps-tausta. Tällaiset generalistit eivät vaivaudu suunnitteluun ja käyttävät mieluummin vain kokemukseensa perustuvaa kehitysmenetelmää. He voivat helposti keskustella teknisen johdon kanssa valitusta vaihtoehdosta tehtävän toteuttamiseksi.
Missä he ovat vahvoja:
- riippumaton;
- stressiä kestävä;
- pätevä monissa asioissa;
- oppinut - heidän kanssaan on aina jotain puhuttavaa.
mutta:
- rikkovat usein velvoitteitaan;
- yleensä monimutkaistaa kaikkea: ratkaise kertotaulukko integroimalla osien mukaan;
- työn laatu on alhainen, kaikki toimii 2-3 kertaa;
- He muuttavat jatkuvasti määräaikoja, koska todellisuudessa kaikki ei ole niin yksinkertaista.
3. "Universaali – okei, anna minun tehdä se, koska ei ole ketään muuta"
Työntekijä on perehtynyt useisiin alueisiin ja hänellä on asiaankuuluvaa kokemusta. Hänestä ei kuitenkaan tule ammattia missään niistä, koska häntä käytetään usein pelastusköynnöksenä, joka tukkii aukkoja nykyisiin tehtäviin. Taipuisa, tehokas, pitää itseään kysyttynä, mutta ei sitä ole.
Käytännöllinen ihanteellinen työntekijä. Todennäköisesti hänellä on suunta, josta hän pitää eniten, mutta kompetenssien hämärtymisen vuoksi kehitystä ei tapahdu. Tämän seurauksena henkilö on vaarassa tulla vaatimattomaksi ja emotionaalisesti loppuun palaneeksi.
Missä he ovat vahvoja:
- vastuullinen;
- tulosorientoitunut;
- rauhoittaa;
- täysin hallinnassa.
mutta:
- näyttää keskimääräisiä tuloksia alhaisen pätevyyden vuoksi;
- ei pysty ratkaisemaan monimutkaisia ja abstrakteja ongelmia.
4. "Yleinen pelaaja on taitonsa mestari"
Henkilöllä, jolla on vakava tausta kehittäjänä, on järjestelmäajattelu. Pedanttinen, vaativa itselleen ja joukkueelleen. Mikä tahansa häntä koskeva tehtävä voi kasvaa loputtomiin, jos rajoja ei määritellä.
Hän tuntee arkkitehtuurin hyvin, valitsee teknisen toteutustavan ja analysoi huolellisesti valitun ratkaisun vaikutusta nykyiseen arkkitehtuuriin. Vaatimaton, ei kunnianhimoinen.
Missä he ovat vahvoja:
- näyttää korkeaa työn laatua;
- pystyy ratkaisemaan minkä tahansa ongelman;
- erittäin tehokas.
mutta:
- suvaitsematon muiden mielipiteitä kohtaan;
- maksimalistit. He yrittävät tehdä kaiken oikein, ja tämä lisää kehitysaikaa.
Mitä meillä käytännössä on?
Katsotaanpa, kuinka roolit ja kompetenssit useimmiten yhdistetään. Otetaan lähtökohtana standardikehitystiimi: PO, kehityspäällikkö (tekninen johto), analyytikot, ohjelmoijat, testaajat. Emme ota huomioon tuotteen omistajaa ja teknistä johtoa. Ensimmäinen johtuu teknisen osaamisen puutteesta. Toinen, jos joukkueessa on ongelmia, pitäisi pystyä tekemään kaikkea.
Yleisin vaihtoehto osaamisen yhdistämiseen/yhdistämiseen/yhdistämiseen on kehittäjä-analyytikko. Testausanalyytikko ja "kolme yhdessä" ovat myös hyvin yleisiä.
Käytän tiimiäni esimerkkinä, ja näytän sinulle generalistikollegoideni hyvät ja huonot puolet. Heitä on tiimissäni kolmannes, ja rakastan heitä erittäin paljon.
PO sai kiireellisen tehtävän ottaa käyttöön uusia tariffeja olemassa olevaan tuotteeseen. Ryhmässäni on 4 analyytikkoa. Tuolloin yksi oli lomalla, toinen sairas ja loput olivat mukana strategisten tehtävien toteuttamisessa. Jos vetäisin ne pois, se häiritsisi väistämättä täytäntöönpanon määräaikoja. Oli vain yksi ulospääsy: käyttää "salaista asetta" - monipuolista kehittäjä-analyytikkoa, joka hallitsi vaaditun aihealueen. Kutsutaan häntä Anatoliksi.
Hänen persoonallisuustyyppinsä on "yleinen – keksin sen ja teen sen". Tietenkin hän yritti pitkään selittää, että hänellä on "täysi ruuhka tehtävistään", mutta vahvan tahdon päätökselläni hänet lähetettiin ratkaisemaan kiireellinen ongelma. Ja Anatoli teki sen! Hän suoritti lavastuksen ja toteutuksen ajoissa, ja asiakkaat olivat tyytyväisiä.
Ensi silmäyksellä kaikki sujui. Mutta muutaman viikon kuluttua tälle tuotteelle nousi jälleen parannusvaatimuksia. Nyt tämän ongelman muotoilun suoritti "puhdas" analyytikko. Uuden kehityksen testausvaiheessa emme pitkään aikaan kyenneet ymmärtämään, miksi uusien tariffien yhdistämisessä tapahtui virheitä, ja vasta sitten, kun koko sotku oli selvitetty, pääsimme totuuden ytimeen. Me hukkasimme paljon aikaa ja missatimme määräaikoja.
Ongelmana oli, että monet piilotetut hetket ja sudenkuopat jäivät vain farmarivaunumme päähän, eivätkä ne siirretty paperille. Kuten Anatoli myöhemmin selitti, hänellä oli liian kiire. Mutta todennäköisin vaihtoehto on, että hän törmäsi ongelmiin jo kehityksen aikana ja ohitti ne heijastamatta tätä missään.
Oli toinenkin tilanne. Nyt meillä on vain yksi testaaja, joten jotkin tehtävät joutuvat testaamaan analyytikoiden, myös yleisten asiantuntijoiden, toimesta. Siksi annoin ehdolliselle Fedorille yhden tehtävän - "yleinen - okei, anna minun tehdä se, koska ei ole ketään muuta".
Fedor on "kolme yhdessä", mutta kehittäjä on jo varattu tähän tehtävään. Tämä tarkoittaa, että Fedyan täytyi yhdistää vain analyytikko ja testaaja.
Vaatimukset on koottu, spesifikaatio on lähetetty kehittelyyn, on aika testata. Fedor tuntee muutettavan järjestelmän "kuin taskunsa" ja on käsitellyt perusteellisesti nykyiset vaatimukset. Siksi hän ei vaivautunut kirjoittamaan testiskriptejä, vaan suoritti testauksen "kuinka järjestelmän pitäisi toimia" ja välitti sen sitten käyttäjille.
Testi valmistui, versio meni tuotantoon. Myöhemmin kävi ilmi, että järjestelmä ei ainoastaan keskeyttänyt maksuja tietyille saldotileille, vaan myös esti maksut hyvin harvinaisilta sisäisiltä tileiltä, joiden ei pitänyt osallistua tähän.
Tämä johtui siitä, että Fedor ei tarkistanut, kuinka "järjestelmän ei pitäisi toimia", ei laatinut testisuunnitelmaa tai tarkistuslistoja. Hän päätti säästää ajoituksessa ja luottaa omiin vaistoihinsa.
Miten käsittelemme ongelmia?
Tällaiset tilanteet vaikuttavat tiimin suorituskykyyn, julkaisujen laatuun ja asiakastyytyväisyyteen. Siksi niitä ei voida jättää ilman huomiota ja syiden analysointia.
1. Pyydän jokaista vaikeuksia aiheuttanutta tehtävää varten täyttämään yhtenäisen lomakkeen: virhekartan, jonka avulla voit tunnistaa vaiheen, jossa "poisto" tapahtui:
2. Pullonkaulojen tunnistamisen jälkeen jokaisen ongelmaan vaikuttaneen työntekijän kanssa järjestetään aivoriihi: "Mitä muuttaa?" (erikoistapauksia emme tarkastele jälkikäteen), joiden seurauksena syntyy konkreettisia tekoja (persoonallisuustyypille omat) määräajoin.
3. Olemme ottaneet käyttöön säännöt vuorovaikutukseen tiimin sisällä. Sovimme esimerkiksi, että kaikki tiedot tehtävän etenemisestä kirjataan välttämättä projektinhallintajärjestelmään. Kun artefakteja muutetaan/tunnistetaan kehitysprosessin aikana, tämän tulee näkyä tietokannassa ja teknisten eritelmien lopullisessa versiossa.
4. Valvontaa alettiin toteuttaa jokaisessa vaiheessa (erityisesti kiinnitetään huomiota aiemmin ongelmallisiin vaiheisiin) ja automaattisesti seuraavan tehtävän tulosten perusteella.
5. Jos seuraavan tehtävän tulos ei ole muuttunut, en aseta kyseistä generalistia siihen rooliin, jossa hän pärjää huonosti. Yritän arvioida hänen kykyään ja halua kehittää osaamistaan tässä roolissa. Jos en löydä vastausta, jätän hänet rooliin, joka on häntä lähempänä.
Mitä lopussa tapahtui?
Kehitysprosessista on tullut läpinäkyvämpi. BUS-tekijä on laskenut. Virheiden parissa työskentelevät tiimin jäsenet motivoituvat ja parantavat karmaaan. Parannamme julkaisujemme laatua vähitellen.
Tulokset
Yleisillä työntekijöillä on hyvät ja huonot puolensa.
edut:
- voit sulkea painuvan tehtävän milloin tahansa tai ratkaista kiireellisen virheen lyhyessä ajassa;
- integroitu lähestymistapa ongelman ratkaisemiseen: esiintyjä tarkastelee sitä kaikkien roolien näkökulmasta;
- generalistit voivat tehdä melkein kaiken yhtä hyvin.
Haitat:
- BUS-tekijä kasvaa;
- rooliin luontaiset ydinkompetenssit murenevat. Tästä johtuen työn laatu heikkenee;
- määräaikojen siirtymisen todennäköisyys kasvaa, koska jokaisessa vaiheessa ei ole valvontaa. "Tähdeksi" kasvamiseen liittyy myös riskejä: työntekijä on varma, että hän tietää paremmin olevansa ammattilainen;
- ammatillisen loppuunpalamisen riski kasvaa;
- paljon tärkeää tietoa projektista voi jäädä vain työntekijän "päähän".
Kuten näet, puutteita on enemmän. Siksi käytän generalisteja vain, jos resurssit eivät riitä ja tehtävä on melko kiireellinen. Tai ihmisellä on osaamista, joita muilta puuttuu, mutta laatu on vaakalaudalla.
Jos tehtävän yhteisessä työssä noudatetaan roolijaon sääntöä, työn laatu paranee. Katsomme ongelmia eri näkökulmista, näkemyksemme ei ole hämärtynyt, tuoreita ajatuksia tulee aina esiin. Samalla jokaisella tiimin jäsenellä on kaikki mahdollisuudet ammatilliseen kasvuun ja osaamisen laajentamiseen.
Uskon, että tärkeintä on tuntea olevansa mukana prosessissa, tehdä työtäsi, asteittain laajentaen osaamistasi. Generalistit tiimissä tuovat kuitenkin etuja: tärkeintä on varmistaa, että he yhdistävät tehokkaasti eri rooleja.
Toivotan kaikille itseorganisoituvaa tiimiä ”alansa yleismestareista”!
Lähde: will.com