motto:
Mies, katsoessaan likaisia lapsia, sanoo vaimolleen: no, pestäänkö nämä vai synnytetäänkö uusia?
Leikkauksen alapuolella on tiimimme johtajan sekä RAS:n tuotekehitysjohtajan Igor Marnatin keskustelu ohjelmoijien motivoinnin erityispiirteistä.
Menestyksen salaisuus upeiden ohjelmistotuotteiden luomisessa on hyvin tiedossa – ota joukko hienoja ohjelmoijia, anna tiimille hieno idea äläkä häiritse tiimin työtä. Hienot kehittäjät ovat harvinaisia ja kysyttyjä. Jotkut rekrytoijat jopa sanovat, että heillä on sellainen vaikutelma, että on helpompi tuottaa hieno ohjelmoija kuin palkata sellainen markkinoilta. Varsinaisen rekrytoinnin vaikeuksien lisäksi jokaisen tietyn kehittäjän kokemus, hänen tietämys olemassa olevasta tuotteesta ja sen kehityshistoriasta on usein korvaamatonta tai vaikeaa ja aikaa vievää täydentää. Siksi, jos olet onnekas ja sinulla on jo viileä ohjelmoijatiimi, on tärkeää työstää heidän motivaatiotaan. Uusien kehittäjien palkkaaminen ja kouluttaminen, heistä tiimin muodostaminen on lähes yhtä vaikeaa ja aikaa vievää kuin synnytys ja lasten kasvattaminen.
Tarkastellaanpa ohjelmoijien (ohjelmoijatiimien) päämotivaatiotekijöitä käyttäen Maslow'n pyramidia esityksen selkeyden ja jäsentämisen vuoksi. Jos et ole kuullut Maslowin pyramidista, se ei ole kiistaton, mutta erittäin suosittu ja havainnollistava teoria amerikkalaispsykologilta Abraham Harold Maslowilta, joka ehdotti teoriaa henkilökohtaisesta motivaatiosta, joka perustuu ihmisten tarpeiden hierarkiaan (katso kuva alla).
Maslow asetti yksilön tarpeet hierarkkiseen järjestykseen fysiologisista tarpeista potentiaalisen kehityksen ja itsensä toteuttamisen tarpeeseen. Maslowin teorian keskeinen oletus on, että "ihminen ei voi kokea korkeamman tason tarpeita ennen kuin hänen alemman tason tarpeensa on tyydytetty." Esimerkiksi tiedon tarve tai esteettiset tarpeet eivät voi ohjata ihmistä, jos samaan aikaan hän ei ole nukkunut tai syönyt kolmeen päivään.
Ennen kuin mennään yksityiskohtiin, keskitytään ilmeiseen tosiasiaan - tiimi koostuu ihmisistä, kaikki ihmiset ovat erilaisia, jokaisella on oma motivaatiorakenne. Sen lisäksi, että jokaista ihmistä ohjaavat erilaiset kiinnostuksen kohteet, jokainen ihminen on myös erilaisissa elinoloissa. Joku on uransa alussa ja miettii sen rakentamista, joku aikoo mennä naimisiin ja joku haluaa hallita uuden aihealueen. Se, mikä on yhdelle tärkeää, on toiselle täysin merkityksetöntä, ja huomenna kaikki muuttuu taas. Tämän kontekstin ymmärtämiseksi oikein on olemassa yksinkertainen ratkaisu - sinun on mietittävä sitä ja työskenneltävä sen kanssa. Tärkeintä on viestintä.
Muista puhua tiimisi kanssa jostain muusta kuin työstä, rakentaa epävirallisia suhteita.
Joten, käydään nyt läpi Maslow'n pyramidin ja pohditaan sen tasoja ohjelmoijatiimin hallinnassa.
I: Fysiologiset, biologiset tarpeet:
Motivaatiosta puhuttaessa monet ajattelevat usein ennen kaikkea palkkaa. Tässä tapauksessa tarkoitan palkalla pysyvää osaa palkkiopaketista, joka ei ole millään tavalla riippuvainen tuloksista. Tämä ei koske bonuksia, bonuksia ja yrityskampanjoita. Se on palkka, jonka katsoisin meidän tapauksessamme "fysiologisten tarpeiden" tasolle. Bonukset, suoritukseen perustuvat bonukset, optiot ja yhtiön osakkeet - luokittelisin tämän kaiken muille tasoille.
Minusta, vaikka se kuulostaa kuinka oudolta, palkka voisi mieluummin olla demotivoivaa pikemminkin kuin motivoiva tekijä. Ohjelmoijien kanssa työskentelyn erikoisuus on, että he ovat kaikki ihmisiä, ensinnäkin erittäin älykkäitä (ammatin ominaisuus) ja toiseksi syvästi ja/tai laajasti koulutettuja. Tyypillisesti ohjelmoijalla on ammattinsa lisäksi syvä ymmärrys yhdestä tai useammasta aihealueesta, jolle he luovat tuotteita. Lisäksi hyvät ohjelmoijat ovat kiinnostuneita ja tuntevat hyvin ohjelmoinnin kehityshistorian, algoritmit, standardit jne. Sama pätee heidän aihealueeseensa. Tämän tason ihmisille palkka ei yleensä ole tärkein motivoiva tekijä.
Samaan aikaan ohjelmoijien oikeudenmukaisen palkan puute heidän ymmärryksensä mukaan demotivoi ja demotivoi suuresti. Kohtuullinen palkka on normi. Palkka on paljon korkeampi kuin normi (markkinat) - myös, kummallista kyllä, melko demotivoiva tekijä. Eräs kollega kertoi minulle kerran erään suuren amerikkalaisen animaatioyhtiön ohjelmoijatiimistä, joka useista olosuhteista johtuen sai XNUMX-XNUMX kertaa markkinoita korkeampaa palkkaa. Kuten hän sanoi, hän ei ollut koskaan nähnyt tylsempiä, laiskoja ja motivoituneempia ohjelmoijia elämässään. Palkankorotuksen tosiasia voi motivoida lyhyellä aikavälillä, mutta muutaman kuukauden kuluttua uudesta palkasta tulee normi ja se lakkaa motivoimasta. Yleisesti ottaen sanoisin, että uransa alussa oleville ohjelmoijille palkkatekijä on tärkeämpi, kun he kasvavat ammatillisesti ja kehittyvät, sen merkitys vähenee ja muut tekijät alkavat voittaa.
Toinen tärkeä kohta on oikeudenmukainen tasapaino joukkueen palkkatasossa. Jos tiimin mielestä yhden jäsenen panos on huomattavasti pienempi, mutta korvaustaso on sama, demotivoi se koko tiimiä. Joskus esimiehillä on kiusaus sytyttää tulta rahalla - pitääkseen loppuun palaneen tai motivoituneen henkilön liikkeessä nostamalla hänen palkkaansa normaalia korkeammalle. Tämä aiheuttaa yleensä ongelmia vain pitkällä tähtäimellä - henkilön itsensä motivaatio ei juurikaan nouse, tai se nousee pariksi kuukaudeksi, mutta muun tiimin motivaatio putoaa. Tällaisissa tilanteissa kannattaa etsiä muita lähestymistapoja, ellei tämä tietenkään ole ainutlaatuinen asiantuntija, joka on pidettävä hinnalla millä hyvänsä, jopa lyhyen aikaa.
II. Turvallisuuden, mukavuuden ja elinolojen johdonmukaisuuden tarve:
70 vuotta sitten liesi autossa saattoi olla motivoiva tekijä autoa valittaessa, silloin se oli normin yläpuolella ja ylellisyyden merkki. Nyt jopa ilmastoinnin puuttuminen on hölynpölyä, ja sen läsnäolo ei tietenkään ole motivoiva tekijä auton valinnassa. Joten 10-15 vuotta sitten kätevä toimisto, hyvä laitteisto, herkullinen kahvi, kunto, joustavat työajat jne. voisi olla hyviä motivoivia tekijöitä, mutta nyt tämä on pikemminkin normi hyvän ohjelmoijan työssä. Samalla heidän poissaolonsa on taas demotivoivaa.
Tärkeä demotivoiva tekijä on keskittymiskyvyn puute ja meluisa työympäristö. Ohjelmoijan työ vaatii hiljaisuutta ja keskittymistä. Jos toimistotila ei tarjoa mahdollisuutta tarjota kehittäjille eristäytynyttä työtilaa, on ainakin varmistettava mukava yhteistyö kollegoiden välillä, jotka eivät häiritse toisiaan. On parempi yhdistää energiset ja äänekkäät toverit keskenään, jolloin annetaan mahdollisuus keskittyä sitä tarvitseville.
Ohjelmoijan ajan hinta on nyt huomattavasti korkeampi kuin sen laitteiston hinta, jolla hän työskentelee. Kaksi tai kolme näyttöä, tehokkaat tietokoneet, mukava työpaikka jokaiselle kehittäjälle - pitäisi olla normi kaikissa yrityksissä. Tätä aihetta käsitellään hyvin yhdessä Joel Spolskyn artikkeleista "Joelin testi: 12 askelta parempaan koodiin.
Mukavuuden fyysinen osa on alkeellisin ja yksinkertaisin; nyt puhutaan muusta.
Monissa yrityksissä ohjelmoijien normi on joustava työaikataulu eikä pukeutumiskoodi. Tämä on hyvä ja oikein, jos tiimin työn erityispiirteet sen sallivat (esim. ei tapaamisia asiakkaiden, poliitikkojen tai pankkiirien kanssa).
Tärkeää on, että meillä on tietty aikaikkuna, jossa koko tiimi työskentelee yhdessä paikallisesti, jotta ihmiset voivat kommunikoida ja ratkaista ongelmia kasvokkain. Ohjelmoija ei periaatteessa lähde töistä edes töiden jälkeen. Tyypillisesti työasiat toistuvat hänen mielessään riippumatta hänen läsnäolostaan toimistossa, ja hyvät päätökset tulevat usein toimiston ulkopuolelta. Kun otetaan huomioon tarve olla hyvä (josta keskustelemme alla), vähäpätöinen valvonta on haitallista. Se ei ainoastaan demotivoi, vaan myös vähentää tuottavuutta. Kuten käytäntö osoittaa, kontrollin puuttuessa motivoitunut tiimi työskentelee todennäköisemmin pidempään kuin on tarpeen. Jos ohjaus on olemassa, kehittäjät voivat istua näppäimistön ääressä yhdeksästä kuuteen, mutta mielestäni tulos on huonompi. Kuten sanotaan, yksi ihminen voi viedä hevosen veteen, mutta satakaan ei pakota häntä juomaan, jos hän ei halua.
Tämän tarpeiden tason kuvauksessa mainitaan myös vapaus ahdistuksesta ja pelosta, kaaoksen puuttuminen sekä rakenteen ja järjestyksen tarve. Nämä ovat myös erittäin tärkeitä kohtia, jotka vaikuttavat suuresti joukkueen ilmapiiriin.
Ensinnäkin kaaoksen, rakenteen ja järjestyksen puuttuminen - tiimin tulee ymmärtää kuka on vastuussa mistäkin, miten roolit jakautuvat, mitä pitää tehdä, kenelle, milloin, mitkä vaatimukset ovat tuotteen taustalla, mitkä ovat johdon odotukset ja Asiakas... Suurin osa tästä pitäisi kuvata muodollisesti, kaikesta tulisi keskustella säännöllisesti. Ilman keskustelua ja säännöllistä käyttöä kuvaukset eivät toimi. On hyvä käytäntö keskustella niistä säännöllisesti ja päivittää niitä post mortem -analyysin tulosten perusteella vapautumisen jälkeen.
Toiseksi rauhallinen ja ystävällinen ilmapiiri. Me kaikki vietämme suurimman osan ajastamme töissä, ja haluamme tehdä sen ilman stressiä, konflikteja tai pelkoa. Kehitystiimi työskentelee yleensä aikataulujen ja asiakkaiden aiheuttaman paineen alla. Kukaan ei tarvitse lisästressiä kollegoilta ja esimiehiltä. Tiimin ilmapiiri, yleensä se tosiasia, että kehittäjäryhmää voidaan kutsua ja olla "tiimi", on johtajan suora ja tärkeä vastuu, yksi tärkeimmistä keskipitkän ja pitkän aikavälin tehtävistä. Siksi on tärkeää, että johtaja työskentelee erityisesti tiimin ristiriitojen kanssa, eikä anna niiden kehittymisen kulkea omaa kulkuaan. Konfliktinhallinta on erillinen aihe, joka ansaitsee erillisen tutkimuksen.
On kaksi päätapaa vaikuttaa tiimin tunnetilaan ja kollegoiden käyttäytymiseen (jos joku lisää kommentteihin, se olisi hienoa). Ensimmäinen on oma käytöksesi. Henkilökohtainen esimerkki on erittäin tärkeä esimiehelle ja tiimille. Kuten sanotaan, niin kuin on pappi, niin on saapuminen. Käyttäydy niin kuin odotat kollegojesi käyttäytyvän. Toinen on kannustaa oikeaan käyttäytymiseen ja niin sanotusti estää väärää käytöstä. Kommunikoi ihmisten kanssa, anna heille palautetta, tähän on monia tapoja. Yleisesti ottaen palaute on erillisen keskustelun aihe, se on suuri ja tärkeä osa motivaatiotyötä.
Toinen huomautus ilmapiiristä, joka saattaa tuntua epätavalliselta, mutta käytännössä se on tärkeä. Useimmiten kehitystiimissä on vähemmän tyttöjä kuin miehiä. Usein ryhmät ovat kokonaan miehiä. Tällaisissa olosuhteissa, myös kuormituksen alaisena, ryhmässä aletaan joskus käyttää säädytöntä kieltä. Käytäntö osoittaa, että tällä on kielteinen vaikutus ilmapiiriin; viestinnästä tulee vähitellen töykeää. Sinun tulee välttää sen käyttöä itse ja estää sen käyttöä tiimissäsi.
Kehitystiimiä kutsutaan usein T&K:ksi (tutkimus ja kehitys), jossa tutkimus muodostaa merkittävän osan työstä. Tämä on se osa, jota on yleensä vaikea ohjelmoida ja suunnitella, muuten se ei olisi tutkimusta. On tärkeää, että tiimillä on oikeus tehdä virheitä, olla oma-aloitteinen, kokeilla erilaisia vaihtoehtoja, jotka voivat päättyä menestykseen tai eivät. Virheet ovat normaali osa työtä, niiltä ei voi välttyä, mutta niistä voi opiskella, analysoida, ottaa opiksi tulevaisuutta varten ja jatkaa eteenpäin. Toyotalta peräisin oleva 5 Miksi -periaate on hyvä tapa löytää ongelman perimmäinen syy. Virheistä rankaiseminen on loistava tapa luoda pelon ja epävarmuuden ilmapiiri. Ainoa poikkeus on tilanne, jossa analyysin tulosten perusteella käy ilmi, että virhe johtuu epäammattimaisesta asenteesta työhön, jolloin voidaan joutua tekemään henkilöstöpäätöksiä.
Ryhmän ilmapiiriin vaikuttavat suuresti odotuksesi ja tunnetila ennen keskustelun alkamista. Ennen kuin aloitat vaikean keskustelun, jonkinlaisen debriefingin tai vain tunteellisen keskustelun, mielialasi ja asenteesi henkilöön, jonka kanssa aiot puhua, on tärkeitä. Uskon ja toimin aina oletuksena sen mukaan, mitä henkilö vilpittömästi yritti tehdä parhaansa. Jos sinun asemasi perusteella näyttää siltä, että näin ei ole, sinun on rauhallisesti ja yksityiskohtaisesti selvitettävä konteksti ja ymmärrettävä, mitä hän teki oikein, miksi hänen mielestään se oli oikein ja missä odotuksemme eroavat. Yleensä käy ilmi, etteivät ne oikeastaan eroa toisistaan, vaan hänen näkemyksensä kontekstista on täydellisempi tai tuoreempi, ja on jotain, jota et tiennyt. Tai päinvastoin, hän ei tiennyt jotain. Tämä on erityisen tärkeää hajautetussa tiimissä, kun ihmiset kommunikoivat harvemmin henkilökohtaisesti ja käyttävät sähköpostia ja pikaviestimiä. Tämä on vielä tärkeämpää ryhmässä, joka koostuu ohjelmoijista eri maista ja jakautuu eri aikavyöhykkeille. Tässä kulttuurieroilla alkaa olla suuri rooli.
Vaikeassa tilanteessa liikkeellä ajaminen on helppoa, erittäin helppoa, mutta sitten takaisin ajaminen on vaikeaa ja sedimentti pysyy pitkään. Annan sinulle yksinkertaisen esimerkin viimeaikaisista kokemuksista. Eräs tiimin johtajista tarvitsi kipeästi kommentteja jostakin asiakkaaseen liittyvästä ongelmasta toisesta maasta vastaavan tiimin johtajalta. Hän pingasi kollegaansa messengerissä, odotti 15 minuuttia, pingoitti uudelleen, sitten 15 minuuttia myöhemmin hän meni suureen chattiin, jossa myös muut johtajat olivat mukana, ja hyökkäsi hieman kollegaa vastaan seuraavasti: "koska sinä et. ansaitsetko ehkä vastata minulle, eikä kysymys ole niin kiireellinen?" Lopulta kävi ilmi, että yritysviestintämme oli hieman tylsä ja kollega ei nähnyt kysymystä ollenkaan. Minun piti pyytää anteeksi. Yleensä on parempi aloittaa hyvästä. Aina on mahdollista tehdä paha virhe ja joutua ongelmiin myöhemmin; siinä ei ole mitään ongelmaa (vaikka sinun ei pitäisi tehdä niin). Yleensä yli 20 vuoden aikana toimialallamme olen tavannut todella pahantahtoisen kollegan vain kerran (!). Onneksi erosimme melko nopeasti. Suurimmassa osassa tapauksia on oikein olettaa, että kollegat haluavat parasta, kontekstin parhaan ymmärryksensä mukaan.
Tehtäväsi esimiehenä on varmistaa kontekstien synkronointi, yhteinen käsitys odotuksista, vaatimuksista, määräajoista ja tiimissä hyväksytyistä standardeista. Nämä voivat tuntua pieniltä asioilta, mutta ilmapiiri joukkueessa rakentuu juuri sellaisista pienistä asioista. Hajautetun tiimin näkökulmasta yksi tärkeimmistä tehtävistä on varmistaa, että tiimin jäsenet kommunikoivat säännöllisesti kasvokkain. Olen useammin kuin kerran kuullut ohjelmoijilta, että kun esimerkiksi tukitiimin insinöörit tulivat heidän luokseen ja työskentelivät yhdessä henkilökohtaisesti, he mielellään jäivät töihin auttamaan vaikeassa tapauksessa henkilökohtaisesti heidän luokseen äskettäin tullutta Pashaa, vaikka aiemmin Pasha oli vain ikoni sanansaattajassa, eikä kukaan olisi pysähtynyt ikonin vuoksi.
Muuten, aloin puhua tukitiimistä ja muistin kanonisen esimerkin minulle. Kerran yhdellä asiakkaalla Amerikassa oli ongelma tuotteen kanssa, yksi sen toteutuksen parissa työskennellyistä tukitiimin insinööreistä (lähetetty Venäjältä) jäi töiden jälkeen auttamaan, mutta ongelmaa ei ratkaistu eikä ratkaistu. Yleensä hän viipyi ja istui siellä melkein aamuun asti. Tässä vaiheessa asiakkaan esimiehet eskaloivat ongelmaa, tunnistivat sen kriittisyyden heille ja lähtivät töistä illalla. Eskalaatioprosessi kiihtyi jo eri aikavyöhykkeellä, tukipäälliköt Venäjällä alkoivat yrittää auttaa, johtuen tietyistä vaikeuksista kommunikaatiossa asiakkaan toimiston kanssa (VPN, yhteysongelmat, puhelujen vaikeudet maiden välillä, ...) ei tiennyt, että kaveri oli jo vankilassa toimistossa ja ratkaisee ongelman, ja yritti löytää hänet. He löysivät sen vasta aamulla (amerikkalainen), kun ongelma oli jo käytännössä ratkaistu ja tuote toimi. Heti heti alkuun alettiin sanoa, että mitä helvettiä, asiakkaalla on sellainen eskalaatio, mikään ei toimi, missä olet, emme löydä sinua jne. Tarpeetonta sanoa, että tällaisen käytöksen seurauksena kaveri oli suuresti demotivoitunut. Hajautetun tiimin työn organisointi on erillinen iso aihe, mutta on tärkeää muistaa kaksi asiaa. Ensinnäkin viestintä ja ilmapiiri ovat erittäin tärkeitä, työn onnistuminen riippuu siitä. Toiseksi tämä ei toimi itsestään, vaan sitä on käsiteltävä erikseen ja perusteellisesti.
Toinen tärkeä tähän tarpeeseen liittyvä seikka on jälleen palkka. Ei palkan koko sellaisenaan, vaan tietyn menettelyn olemassaolo sen muuttamiseksi. Yrityksellä tulee olla lähestymistapa eri tasojen tehtävien vaatimusten määrittämiseen. Jokaisen kehittäjän tulee pystyä keskustelemaan yrityksen kanssa työskentelynsä odotuksista, ymmärtämään, miten ja milloin hänen ponnistelunsa voivat vaikuttaa hänen palkkaansa. Säännölliset tapaamiset johtajan kanssa, puolivuosittaiset tai vuosittaiset suoritusarvioinnit palvelevat tätä tarkoitusta. Tämä taas on yksi niistä hetkistä, joiden läsnäolo ei nimenomaisesti motivoi, mutta niiden poissaolo on erittäin demotivoivaa.
Järjestyksen tarpeesta ja sääntöjen olemassaolosta seuraa tarve noudattaa näitä sääntöjä, noudattaa tiimissä hyväksyttyjä normeja, niin virallisia kuin epävirallisiakin. Yleisesti ottaen kutsuisin sitä tarpeeksi olla hyvä. Tämän tarpeen olemassaolo vahvistaa, että mikrohallinta ei ole välttämätöntä, vaan pikemminkin haitallista. Riittää, kun tarjotaan ihmiselle kaikki työhön tarvittava, annetaan hänelle tietoa kontekstista, prioriteeteista ja annetaan toiminta- ja päätöksentekovapaus hänen tasollaan. Tällaisissa olosuhteissa hän tuntee luottamusta, mahdollisuuden tehdä omat päätöksensä, ottaa niistä vastuuta ja pystyy paljastamaan potentiaalinsa.
Toinen tärkeä seikka, jonka pitäisi katsoa järjestyksen tarpeeseen ja kaaoksen puuttumiseen, on kyky keskittyä tehtävään, toistuvien kontekstin vaihtojen puuttuminen. Ohjelmoijana oleminen vaatii aikaa ja keskittymistä. Ohjelmoijat eivät todellakaan halua luopua kiireesti yhdestä tehtävästä ja vaihtaa toiseen. Tarpeellinen osa ohjelmoijan työtä ei yleensä ole vain koodin varsinainen kehittäminen, vaan myös virheenkorjaus ja avustaminen asiakkaiden pyyntöjen käsittelyssä. Tällaisia asioita kannattaa suunnitella etukäteen siten, että ohjelmoija voi rauhallisesti ja täysin suorittaa yhden tehtävän työskentelyn ennen siirtymistä toiseen. Paras vaihtoehto on antaa itsellesi mahdollisuus suunnitella työsi itse, tunnistamalla prioriteetit ja tulevat tehtävät etukäteen ja varaamalla pitkiä, pitkiä aikoja yhden tyyppisen tehtävän tekemiseen. Tämä aihe on kuvattu hyvin kirjassa "Google – Sivuston luotettavuussuunnittelu”, joka kuvaa hyvin lähestymistapoja työskentelyn suunnitteluun ryhmien, jotka varmistavat suurten, erittäin kuormitettujen, vikasietoisten järjestelmien toiminnan ja kehittämisen, sekä insinöörien, joiden ammatissa yhdistyvät ohjelmistokehitys ja sen tuki.
Jatkuu ...
Lähde: will.com