Epigraaf:
De man sjocht nei de grimmitige bern en seit tsjin syn frou: no, sille wy dizze waskje of nije bern jaan?
Under de besuniging is de diskusje fan ús teamlieder, lykas RAS Product Development Director, Igor Marnat, oer de eigenaardichheden fan motivearjende programmeurs.
It geheim foar sukses by it meitsjen fan koele softwareprodukten is goed bekend - nim in team fan koele programmeurs, jou it team in koel idee en bemuoie it wurk fan it team net. Coole ûntwikkelders binne seldsum en yn fraach. Guon recruiters sizze sels dat se de yndruk hawwe dat it makliker is om in koele programmeur te produsearjen dan ien fan 'e merk te hieren. Neist de swierrichheden mei it ynhieren as sadanich, is de ûnderfining fan elke spesifike ûntwikkelder, syn kennis fan it besteande produkt en de skiednis fan syn ûntwikkeling, faaks net te ferfangen as lestich en tiidslinend om oan te foljen. Dêrom, as jo gelok binne en al in koel team fan programmeurs hawwe, is it wichtich om te wurkjen oan har motivaasje. It ynhieren en oplieden fan nije ûntwikkelders, it meitsjen fan in team fan har is hast like lestich en tiidslinend as it berte jaan en bern grutbringe.
Lit ús beskôgje de wichtichste faktoaren fan motivaasje foar programmeurs (teams fan programmeurs), mei help fan Maslow syn piramide foar dúdlikens en strukturearjen fan presintaasje. As jo net heard hawwe fan Maslow syn piramide, it is net in ûnbestriden, mar tige populêre en yllustrative teory fan 'e Amerikaanske psycholooch Abraham Harold Maslow, dy't foarstelde in teory fan persoanlike motivaasje basearre op' e hiërargy fan minsklike behoeften (sjoch foto hjirûnder).
Maslow regele de behoeften fan it yndividu yn in hiërargyske folchoarder, fan fysiologyske behoeften oant de needsaak foar potensjele ûntwikkeling en selsaktualisaasje. In wichtige oanname yn Maslow syn teory is dat "in persoan kin net ûnderfine heger nivo behoeften oant syn legere nivo behoeften binne tefreden." In persoan kin bygelyks net dreaun wurde troch de needsaak foar kennis of estetyske behoeften as dizze persoan tagelyk trije dagen net sliept of iten hat.
Foardat wy yn details geane, litte wy rjochtsje op in fanselssprekkend feit - in team bestiet út minsken, alle minsken binne oars, elk hat har eigen motivaasjestruktuer. Neist it feit dat elke persoan wurdt dreaun troch ferskillende belangen, elke persoan is ek yn ferskillende libbensomstannichheden. Immen stiet oan it begjin fan in karriêre en tinkt oer hoe't se it bouwe, immen sil trouwe, en immen wol in nij fakgebiet behearskje. Wat foar de iene wichtich is, is foar in oar folslein ûnbelangryk, en moarn feroaret alles wer. Om dizze kontekst goed te begripen, is d'r in ienfâldige remedie - jo moatte der oer tinke en dermei wurkje. It wichtichste is kommunikaasje.
Wês wis dat jo mei jo team prate oer wat oars as wurk, bouwe ynformele relaasjes.
Dat, lit ús no troch Maslow's piramide gean en har nivo's beskôgje as tapast op it behearen fan in team fan programmeurs.
I: Fysiologyske, biologyske behoeften:
As it oer motivaasje praat wurdt, tinke in protte minsken faaks earst oer salaris. Yn dit gefal bedoel ik mei salaris in permanint diel fan it kompensaasjepakket, dat op gjin inkelde manier ôfhinget fan de resultaten. Dit jildt net foar bonussen, bonussen en bedriuwspromoasjes. It is it salaris dat ik soe tawize oan it nivo fan "fysiologyske behoeften" yn ús gefal. Bonussen, bonussen basearre op prestaasjes, opsjes en bedriuwsoandielen - ik soe dit alles op oare nivo's klassifisearje.
Neffens my kin, hoe nuver it ek klinke, it salaris leaver wêze kin demotivating faktor ynstee fan in motivearjende faktor. De eigenaardichheid fan wurkjen mei programmeurs is dat se allegear minsken binne, yn it foarste plak, tige tûk (in skaaimerk fan it berop), en twadde, djip en / of breed oplaat. Typysk hawwe programmeurs, neist har berop, in djip begryp fan ien of mear fakgebieten wêrfoar se produkten meitsje. Derneist binne goede programmeurs ynteressearre yn en kenne de skiednis fan programmearringûntwikkeling, algoritmen, noarmen, ensfh. Itselde jildt foar harren fakgebiet. Foar minsken op dit nivo is salaris meastentiids net de wichtichste motivearjende faktor.
Tagelyk demotivearret en demotivearret it gebrek oan in earlik salaris foar programmeurs, yn har begryp, sterk. In earlik salaris hawwe is de noarm. It salaris is folle heger as de noarm (merk) - ek, frjemd genôch, in nochal demotivearjende faktor. In kollega fertelde my ris oer in team fan programmeurs yn ien fan 'e grutte Amerikaanske animaasjebedriuwen, dy't troch in oantal omstannichheden salarissen krigen op in nivo twa oant trije kear heger as de merk. Lykas hy sei, hie hy yn syn libben noch noait mear ferfelende, luie en demotivearre programmeurs sjoen. It feit fan in salarisferheging kin op koarte termyn motivearje, mar nei in pear moannen wurdt it nije salaris de noarm en hâldt it op te motivearjen. Yn 't algemien soe ik sizze dat foar programmeurs oan it begjin fan har karriêre de salarisfaktor wichtiger is, om't se profesjoneel groeie en ûntwikkelje, it belang nimt ôf en oare faktoaren begjinne te hearskjen.
It twadde wichtige punt is de oanwêzigens fan in earlike balâns yn it nivo fan salarissen yn it team. As in team fynt dat de bydrage fan ien lid merkber leger is, mar it nivo fan de kompensaasje is itselde, dan sil dit it hiele team demotivearje. Soms wurde managers oanstriid om it fjoer mei jild te brânen - om in útbaarnd of demotivearre persoan te behâlden troch syn salaris boppe normaal te ferheegjen. Dit makket normaal allinich problemen op 'e lange termyn - de motivaasje fan' e persoan sels sil net folle tanimme, of it sil in pear moannen tanimme, mar de motivaasje fan 'e rest fan it team sil sakje. Yn sokke situaasjes is it de muoite wurdich om te sykjen nei oare oanpak, útsein as, fansels, dit is in unike spesjalist dy't moat wurde behâlden op elke priis, sels foar in koarte tiid.
II. Ferlet fan feiligens, komfort, konsistinsje fan libbensomstannichheden:
70 jier lyn koe de oanwêzigens fan in kachel yn in auto in motivearjende faktor wêze by it kiezen fan in auto; doe wie it boppe de noarm en wie in teken fan lúkse. No sels it ûntbrekken fan airconditioning is ûnsin, en syn oanwêzigens, fansels, sil gjin motivearjende faktor by it kiezen fan in auto. Dus 10-15 jier lyn, in handich kantoar, goede hardware, lekkere kofje, fitness, fleksibele oeren, ensfh. koe wêze goede motivearjende faktoaren, mar no dit is earder de noarm foar it wurk fan in goede programmeur. Tagelyk sil har ôfwêzigens wer demotivearjend wêze.
In wichtige demotivearjende faktor is it gebrek oan konsintraasjefermogen en in lawaaierige wurkomjouwing. It wurk fan in programmeur freget stilte en konsintraasje. As de kantoarromte gjin kâns biedt om ûntwikkelders in ôfsletten wurkromte te jaan, is it needsaaklik om op syn minst noflike gearwurking te garandearjen tusken kollega's dy't inoar net bemuoie. It is better om enerzjike en lûde kameraden mei elkoar te ferienigjen, de kâns te jaan om te konsintrearjen oan dyjingen dy't it nedich binne.
De kosten fan 'e tiid fan in programmeur binne no signifikant heger as de kosten fan' e hardware wêrop hy wurket. Twa of trije monitors, krêftige kompjûters, in noflike wurkplak foar elke ûntwikkelder - moat de noarm wêze yn elk bedriuw. Dit ûnderwerp wurdt goed behannele yn ien fan Joel Spolsky's artikels "De Joel Test: 12 stappen nei bettere koade.
De fysike komponint fan komfort is de meast basale en ienfâldige; litte wy no oer de rest prate.
Yn in protte bedriuwen is de noarm foar programmeurs in fleksibel wurkskema en gjin jurkkoade. Dit is goed en korrekt as de spesifiken fan it wurk fan it team it tastean (d'r binne bygelyks gjin gearkomsten mei klanten, politisy of bankiers).
It wichtichste is om in spesifyk finster fan tiid te hawwen wêr't it heule team lokaal gearwurket, sadat minsken kinne kommunisearje en problemen face-to-face kinne oplosse. In programmeur, yn essinsje, ferlit it wurk net sels nei it wurk. Typysk, wurkproblemen replay yn syn geast nettsjinsteande syn oanwêzigens yn it kantoar, en goede besluten komme faak fan bûten it kantoar. Sjoen de needsaak om goed te wêzen (wat wy hjirûnder sille beprate), is lytse kontrôle skealik. It is net allinich demotivearjend, it ferminderet ek de produktiviteit. As de praktyk docht bliken, is in motivearre team by it ûntbrekken fan kontrôle mear kâns om langer te wurkjen dan nedich. As der kontrôle is, kinne ûntwikkelders fan njoggen oant seis op it toetseboerd sitte, mar it resultaat, tink ik, sil slimmer wêze. Sa't se sizze, ien persoan kin liede in hynder nei it wetter, mar sels hûndert sil net twinge him te drinken as er net wol.
De beskriuwing fan dit nivo fan behoeften neamt ek frijheid fan eangst en eangst, it ûntbrekken fan gaos, en it ferlet fan struktuer en oarder. Dit binne ek tige wichtige punten dy't de sfear yn it team in protte ynfloed hawwe.
As earste, it ûntbrekken fan gaos, struktuer en oarder - it team moat begripe wa't ferantwurdlik is foar wat, hoe rollen wurde ferdield, wat moat dien wurde, oan wa, wannear, hokker easken lizze oan it produkt, wat binne de ferwachtings fan behear en de klant... It measte dêrfan moat formeel beskreaun wurde, alles moat periodyk besprutsen wurde. Sûnder diskusje en periodyk gebrûk wurkje beskriuwings net. It is in goede praktyk om se periodyk te besprekken en te aktualisearjen op basis fan de resultaten fan postmortem-analyse nei frijlitting.
Twad, in kalme en freonlike sfear. Wy besteegje allegear de measte fan ús tiid oan it wurk, en wy wolle it dwaan sûnder stress, konflikt of eangst. It ûntwikkelingsteam wurket normaal ûnder druk fan skema's en klanten. Nimmen hat ekstra stress nedich fan kollega's en superieuren. De sfear yn it team, yn 't algemien it feit dat in groep ûntwikkelders kin wurde neamd en in "team" is de direkte en wichtige ferantwurdlikens fan' e manager, ien fan 'e wichtichste taken op middellange en lange termyn. Dêrom is it wichtich foar in manager om yn it bysûnder te wurkjen mei konflikten yn it team, en har ûntwikkeling net syn beurt te litten. Konfliktbehear is in apart ûnderwerp dat aparte stúdzje fertsjinnet.
D'r binne twa wichtige manieren om de emosjonele steat fan it team en it gedrach fan kollega's te beynfloedzjen (as immen tafoeget yn 'e opmerkingen, soe dat geweldich wêze). De earste is dyn eigen gedrach. Persoanlik foarbyld is super wichtich foar in manager en team. Sa't se sizze, lykas de pryster, sa is de komst. Gedrach sa't jo ferwachtsje dat jo kollega's har gedrage. De twadde is om korrekt gedrach te stimulearjen en, om sa te sizzen, ferkeard gedrach te ûntmoedigjen. Kommunisearje mei minsken, jou har feedback, d'r binne in protte manieren om dit te dwaan. Yn 't algemien is feedback in ûnderwerp foar in aparte diskusje; it is in grut en wichtich ûnderdiel fan wurkjen mei motivaasje.
In oare notysje oer de sfear, dy't miskien lykje ûngewoan, mar yn 'e praktyk is it wichtich. Faker as net sitte der minder famkes yn it ûntwikkelingsteam as manlju. Faak binne de groepen folslein manlik. Yn sokke omstannichheden, ek ûnder lêst, begjint soms obsene taal yn it team te brûken. De praktyk lit sjen dat dit in negative ynfloed hat op 'e sfear; kommunikaasje wurdt stadichoan rude. Jo moatte foarkomme om it sels te brûken en it gebrûk yn jo team te ûntmoedigjen.
Untwikkelingsteams wurde faak R&D (ûndersyk en ûntwikkeling) neamd, mei ûndersyk in wichtich part fan it wurk. Dit is it diel dat meastal lestich te programmearjen en te planjen is, oars soe it gjin ûndersyk wêze. It is wichtich dat it team it rjocht hat om flaters te meitsjen, inisjatyf te nimmen, ferskate opsjes te besykjen dy't al of net op sukses einigje. Flaters binne in normaal diel fan wurk, se kinne net foarkommen wurde, mar jo kinne studearje, analysearje, leare fan har foar de takomst en trochgean. It 5 Why's-prinsipe, dat ûntstien is by Toyota, is in goede manier om nei de oarsaak fan in probleem te kommen. It straffen fan flaters is in geweldige manier om in sfear fan eangst en ûnwissichheid te meitsjen. De ienige útsûndering is wannear't, basearre op de resultaten fan 'e analyze, docht bliken dat de flater waard feroarsake troch in unprofesjonele hâlding oan it wurk, yn dit gefal, personiel besluten moatte wurde makke.
De sfear yn it team wurdt sterk beynfloede troch jo ferwachtings en emosjonele steat foardat it petear begjint. Foardat jo in drege diskusje begjinne, in soarte fan debriefing, of gewoan in emosjoneel petear, is jo stimming en hâlding foar de persoan mei wa't jo prate sille wichtich. Ik leau en hannelje altyd standert op basis fan wat de persoan oprjocht besocht it bêste te dwaan. As it út jo posysje liket dat dit net sa is, moatte jo rêstich en yn detail de kontekst fine en begripe wat hy goed die, wêrom't hy tocht dat it goed wie en wêr't ús ferwachtingen divergje. It meastal docht bliken dat se net echt diverge, it is gewoan dat syn fyzje fan 'e kontekst is folsleiner of farske, en der is wat jo net wisten. Of oarsom, hy wist neat. Dit is benammen wichtich yn in ferspraat team, as minsken minder faak persoanlik kommunisearje en e-post en instant messengers brûke. Dit is noch kritysker yn in team dat bestiet út programmeurs út ferskate lannen en ferdield oer ferskate tiidsônes. Hjir begjinne kulturele ferskillen in grutte rol te spyljen.
Yn in drege situaasje is it riden op 'e beweging maklik, heul maklik, mar dan is it weromriden lestich, en it sedimint bliuwt foar in lange tiid. Lit my jo in ienfâldich foarbyld jaan út resinte ûnderfining. Ien fan 'e teammanagers hie driuwend opmerkingen nedich oer wat probleem mei in klant fan in manager fan in besibbe team yn in oar lân. Hy pingte in kollega yn 'e boadskipper, wachte 15 minuten, pingte nochris, doe gie er 15 minuten letter nei in grut petear dêr't ek de oare managers yn wiene, en foel de kollega in bytsje oan, mei in wurden as: "omdat jo net dogge weardich my te beantwurdzjen, miskien, en de fraach is net sa driuwend? Uteinlik die bliken dat ús bedriuwsboadskipper wat dof wie, en de kollega seach de fraach hielendal net. Ik moast my ferûntskuldigje. Yn 't algemien is it better om te begjinnen mei it goede. It is altyd mooglik om in minne flater te meitsjen en letter yn problemen te kommen; dêr is gjin probleem mei (hoewol jo dat net moatte dwaan). Yn 't algemien, yn mear as 20 jier fan wurkjen yn ús yndustry, haw ik mar ien kear (!) in wirklik kweade kollega moete. Gelokkich binne wy frij gau útinoar brutsen. It blykt yn 'e grutte mearderheid fan 'e gefallen krekt te wêzen om oan te nimmen dat kollega's it bêste wolle, nei it bêste fan har begryp fan 'e kontekst.
Jo taak as manager is om te soargjen foar syngronisaasje fan konteksten, in mienskiplik begryp fan ferwachtings, easken, deadlines en noarmen akseptearre yn it team. Dit kinne lytse dingen lykje, mar de sfear yn it team is krekt út sokke lytse dingen opboud. Fanút in ferdield teamperspektyf is ien fan 'e wichtige taken om te soargjen dat teamleden periodike face-to-face kommunikaasje hawwe. Ik haw mear as ien kear heard fan programmeurs dat, nei't bygelyks yngenieurs fan it stipeteam nei har kamen en persoanlik gearwurke, se graach oan it wurk bleaunen om yn in lestige saak persoanlik te helpen oan Pasha, dy't koartlyn by har kaam, hoewol't earder Pasha wie gewoan in ikoan yn 'e boadskipper, en gjinien soe hawwe stoppe om 'e wille fan it ikoan.
Trouwens, ik begon te praten oer it stipeteam en herinnerde my in kanonike foarbyld foar my. Eartiids hie ien fan 'e klanten yn Amearika in probleem mei it produkt, ien fan' e yngenieurs fan 'e stipeteam dy't wurke oan syn ymplemintaasje (sekundearre út Ruslân) bleau nei it wurk om te helpen, mar it probleem waard net oplost en waard net oplost. Yn 't algemien bleau er en siet der hast oant de moarn. Op dit stuit eskalearren de managers fan 'e klant it probleem, identifisearren har krityk foar har, en ferlieten it wurk jûns. It eskalaasjeproses krige al in momentum yn in oare tiidsône, stipemanagers yn Ruslân begûnen te besykjen om te helpen, fanwege bepaalde swierrichheden yn kommunikaasje mei it kantoar fan 'e klant (VPN, ferbiningsproblemen, swierrichheden mei petearen tusken lannen, ...) wist net dat de keardel wie al yn 'e finzenis yn it kantoar en lost it probleem, en besocht te finen him. Se fûnen it allinich yn 'e moarn (Amerikaansk), doe't it probleem al praktysk oplost wie en it produkt wurke. Krekt út 'e bat begûnen se te sizzen dat wat de hel, de klant hat sa'n eskalaasje, neat wurket, wêr bisto, wy kinne jo net fine, ensfh. It is ûnmooglik om te sizzen, as gefolch fan sa'n gedrach de man wie tige demotivearre. It organisearjen fan it wurk fan in ferdield team is in apart grut ûnderwerp, mar it is wichtich om twa dingen te ûnthâlden. As earste binne kommunikaasje en sfear tige wichtich, it sukses fan it wurk hinget derfan ôf. Yn it twadde plak wurket dat net op himsels, it moat apart en yngeand behannele wurde.
In oar wichtich punt yn ferbân mei dit nivo fan behoeften is wer salaris. Net de grutte fan it salaris, as sadanich, mar de oanwêzigens fan in bepaalde proseduere foar it feroarjen. It bedriuw moat in oanpak hawwe om de easken foar posysjes op ferskate nivo's te bepalen. Elke ûntwikkelder moat yn steat wêze om ferwachtingen foar har wurk mei it bedriuw te besprekken, te begripen hoe en wannear har ynspanningen har salaris kinne beynfloedzje. Periodyske gearkomsten mei de manager, healjierlikse of jierlikse prestaasjesbeoardielingen tsjinje dit doel. Dit is wer ien fan dy mominten wêrfan de oanwêzigens net eksplisyt motivearret, mar har ôfwêzigens is tige demotivearjend.
Ut it ferlet fan oarder en de oanwêzigens fan regels folget de needsaak om te foldwaan oan dizze regels, te folgjen de noarmen akseptearre yn it team, sawol formeel en ynformeel. Yn 't algemien soe ik it de needsaak neame om "goed te wêzen." De oanwêzigens fan dizze need befêstiget dat mikromanagement net nedich is, mar earder skealik. It is genôch om te foarsjen in persoan mei alles nedich foar wurk, jou him kennis fan de kontekst, prioriteiten, en jouwe frijheid fan hanneljen en beslútfoarming op syn nivo. Yn sokke betingsten sil hy fertrouwen fiele, de kâns om syn eigen besluten te nimmen, ferantwurdlikens foar har nimme en syn potensjeel kinne iepenbierje.
In oar wichtich punt dat moat wurde taskreaun oan de needsaak foar oarder en it ûntbrekken fan gaos is de mooglikheid om te konsintrearjen op in taak, it ûntbrekken fan faak kontekst skeakels. In programmeur wêze fereasket tiid en fokus. Programmeurs wolle wirklik net ien taak opjaan en oerstappe nei in oare. In needsaaklik diel fan it wurk fan in programmeur is meastentiids net allinich de eigentlike ûntwikkeling fan 'e koade, mar ek bugfixing en help by it ferwurkjen fan oanfragen fan klanten. It is de muoite wurdich om soksoarte dingen yn 't foar te planjen, op sa'n manier dat de programmeur rêstich en folslein it wurk oan ien taak kin foltôgje foardat jo oerstapje nei in oare. De bêste opsje is om josels de kâns te jaan om jo wurk sels te planjen, prioriteiten en oankommende taken foarôf te identifisearjen, lange, útwreide perioaden te tawizen om oan ien soart taak te wurkjen. Dit ûnderwerp is goed beskreaun yn it boek "Google - Site Reliability Engineering”, dy't goed beskriuwt oanpakken foar it plannen fan it wurk fan teams dy't soargje foar de eksploitaasje en ûntwikkeling fan grutte, tige laden, fault-tolerante systemen, lykas yngenieurs waans berop kombinearret softwareûntwikkeling en har stipe.
Oanhâlde wurde ...
Boarne: www.habr.com