mottó:
A férj a koszos gyerekekre nézve azt mondja a feleségének: na, ezeket mossuk ki, vagy szüljünk újakat?
A vágás alatt csoportvezetőnk, valamint a RAS termékfejlesztési igazgatója, Igor Marnat cikkének második része a programozók motiválásának sajátosságairól szól. A cikk első része itt olvasható -
A cikk első részében a Maslow-piramis két alsó szintjét érintettem: a fiziológiai szükségleteket, a biztonság, a kényelem és az állandóság szükségleteit, majd továbbléptem a következő, harmadik szintre, nevezetesen:
III - Az összetartozás és a szeretet igénye
Tudtam, hogy az olasz maffiát „Cosa Nostra”-nak hívják, de nagyon lenyűgözött, amikor megtudtam, hogyan fordítják a „Cosa Nostra”-t. A „Cosa Nostra” olasz fordításban azt jelenti: „Vállalkozásunk”. Motiváció szempontjából nagyon jól sikerült a névválasztás (a foglalkozást hagyjuk, ebben az esetben csak a motiváció érdekel). Az ember általában egy csapat tagja akar lenni, valami nagy, közös üzletet csinálni.
Nagy jelentőséget tulajdonítanak az összetartozás és a szeretet igényének kielégítésének a hadseregben, a haditengerészetben és bármely nagy félkatonai alakulatban. És mint látjuk, a maffiában. Ez érthető, mert erőltetni kell azokat az embereket, akikben kevés a közös, akik kezdetben nem alkotnak egy csapatot hasonló gondolkodású emberekből, akiket a sorkatonaság (nem önként) fog össze, akiknek különböző iskolai végzettsége, eltérő személyes értékrendje van. , hogy a szó szoros értelmében életüket, halálos kockázatot kockáztatva, valamilyen közös ügynek szenteljék, bízza életét egy harcostársra.
Ez egy nagyon erős motiváció, a legtöbb ember számára rendkívül fontos, hogy valami nagyobbhoz tartozónak érezze magát, hogy egy család, egy ország, egy csapat tagja vagy. A hadseregben egyenruhák, különféle rituálék, felvonulások, felvonulások, transzparensek stb. szolgálják ezeket a célokat. Nagyjából ugyanazok a tényezők fontosak minden csapat számára. Fontosak a szimbólumok, a vállalati márka és a vállalati színek, a kellékek és az ajándéktárgyak.
Fontos, hogy a jelentős eseményeknek saját látható megtestesülésük legyen, amelyhez társíthatók. Manapság inkább az a jellemző, hogy egy cégnek van saját áruja, kabátja, pólója stb. De fontos kiemelni a cégen belüli csapatot is. Gyakran egy kiadás eredménye alapján adunk ki pólókat, amelyeket a kiadásban résztvevők megkapnak. Egyes események, közös ünnepségek vagy tevékenységek az egész csapattal egy másik fontos motivációs tényező.
A külső adottságokon kívül számos egyéb tényező is befolyásolja a csapathoz tartozás érzését.
Először is, egy közös cél megléte, amelyet mindenki megért, és a fontosságát osztja. A programozók általában meg akarják érteni, hogy nagyszerű dolgot csinálnak, és ezt együtt, csapatként csinálják.
Másodszor, a csapatnak rendelkeznie kell egy kommunikációs térrel, amelyben az egész csapat jelen van, és amely csak hozzá tartozik (például chat a messengerben, időszakos csapatszinkronok). A munkahelyi kérdések mellett a kötetlen kommunikáció, esetenként a külső események megbeszélése, a fény offtop – mindez közösségi és csapat érzést teremt.
Harmadikként kiemelném a jó mérnöki gyakorlatok csapaton belüli bevezetését, a színvonal emelésének vágyát a cégnél elfogadottakhoz képest. Az iparágban elfogadott legjobb megközelítések megvalósítása először a csapatban, majd a vállalat egészében lehetőséget ad a csapatnak arra, hogy úgy érezze, hogy valamilyen szempontból megelőzi a többieket, utat mutat, ez az összetartozás érzését kelti. egy menő csapatnak.
Az összetartozás érzését az is befolyásolja, hogy a csapat részt vesz a tervezésben és az irányításban. Amikor a csapat tagjai részt vesznek a projektcélok, munkatervek, csapatszabványok és mérnöki gyakorlatok megvitatásában, valamint az új alkalmazottak interjúiban, kialakul bennük a részvétel érzése, a közös tulajdon és a munkára gyakorolt befolyás. Az emberek sokkal szívesebben hajtják végre a saját maguk által hozott és hangoztatott döntéseket, mint a mások által javasoltakat, még akkor is, ha gyakorlatilag összhangban vannak.
Születésnapok, évfordulók, jelentős események a kollégák életében - egy közös pizza, egy kis ajándék a csapattól az érintettség és a hála meleg érzését adják. Egyes cégeknél bevett szokás, hogy a cégnél eltöltött 5, 10, 15 évnyi munkáért apró emléktáblákat adnak. Egyrészt nem hiszem, hogy ez annyira motiválna az új eredményekre. De nyilván szinte mindenki örül annak, hogy nem feledkezett meg róla. Ez azon esetek egyike, amikor egy tény hiánya inkább demotivál, mint jelenléte motivál. Egyetértek, elég szégyen lehet, ha a LinkedIn reggel emlékeztette, és gratulált a munkahelyén a 10. évforduló alkalmából, de a cégtől egyetlen kolléga sem gratulált, vagy nem emlékezett rád.
Természetesen lényeges pont a csapat összetételének változása. Nyilvánvaló, hogy még ha valakinek a csapatból való érkezését vagy távozását előre bejelentik (például cég- vagy csapathírlevélben, vagy csapattalálkozón), ez senkit nem motivál különösebben új eredményekre. De ha egy szép napon új embert lát maga mellett, vagy nem lát egy régit, az meglepetés lehet, ha pedig távozik, kifejezetten kellemetlen. Az embereknek nem szabad csendben eltűnniük. Főleg egy megosztott csapatban. Főleg, ha a munkája egy másik irodából származó kollégán múlik, aki hirtelen felkelt és eltűnt. Az ilyen pillanatokról mindenképpen érdemes előre külön értesíteni a csapatot.
Egy fontos tényező, amelyet angolul úgy hívnak tulajdon (a „birtoklás” szó szerinti fordítása nem tükrözi teljes mértékben a jelentését). Ez nem a tulajdonos érzése, hanem inkább a projektje iránti felelősség érzése, az az érzés, amikor érzelmileg összekapcsolja magát a termékkel, a terméket pedig önmagával. Ez nagyjából megfelel a tengerészgyalogos imájának a „Full Metal Jacket” filmben: „Ez az én puskám. Sok ilyen puska van, de ez az enyém. A puskám a legjobb barátom. Ő az életem. Meg kell tanulnom birtokolni, ugyanúgy, ahogy az életemet. Nélkülem használhatatlan a puskám. A puskám nélkül használhatatlan vagyok. Egyenesen kell lőnöm a puskámat. Pontosabban kell lőnöm, mint annak az ellenségnek, aki meg akar ölni. Le kell lőnöm, mielőtt ő lő rám. Legyen úgy…”.
Amikor az ember hosszú ideig dolgozik egy terméken, lehetősége van teljes felelősséget vállalni annak létrehozásáért és fejlesztéséért, hogy lássa, hogyan keletkezik a „semmiből” működő dolog, hogyan használják az emberek, akkor ez az erőteljes érzés jön létre. Azok a termékcsapatok, amelyek hosszú ideig dolgoznak együtt egy projekten, általában motiváltabbak és összetartóbbak, mint azok a csapatok, amelyek rövid ideig állnak össze, és futószalag üzemmódban dolgoznak, egyik projektről a másikra váltva anélkül, hogy a teljes termékért teljes felelősséget vállalnának. , elejétől a végéig.
IV. Az elismerés szükségessége
Egy kedves szó is örömet okoz a macskának. Mindenkit motivál az elvégzett munka fontosságának elismerése és pozitív értékelése. Beszéljen programozókkal, adjon nekik rendszeres visszajelzést, ünnepelje a jól végzett munkát. Ha nagy és szétosztott csapatunk van, akkor erre tökéletesek az időszakos értekezletek (amit egytől egyig hívnak), ha nagyon kicsi a csapat és helyben dolgozik együtt, akkor ez a lehetőség általában külön megbeszélések nélkül biztosított a naptárban (bár időszakos). csak egyre van. Még mindig szükség van rá, csak ritkábban teheti meg). Ezzel a témával jól foglalkoznak a menedzser-tools.com webhely vezetői podcastjai.
Érdemes azonban szem előtt tartani a kulturális különbségeket. Néhány, az amerikai kollégák által ismert megközelítés nem mindig működik az oroszokkal. A nyugati országok csapataiban a napi kommunikáció során elfogadott udvariasság kezdetben túlzónak tűnik az orosz programozók számára. Az orosz kollégákra jellemző bizonyos egyenességet más országokból származó kollégáik durvaságként érzékelhetik. Ez nagyon fontos a kommunikációban egy interetnikus csapatban, sokat írtak már erről a témáról, ezt egy ilyen csapat vezetőjének emlékeznie kell.
A funkcióbemutatók, ahol a programozók a sprint során kifejlesztett funkciókat mutatják be, jó gyakorlat ennek az igénynek a megvalósításához. Amellett, hogy ez kiváló lehetőség a csapatok közötti kommunikációs csatornák megtisztítására, a termékmenedzserek, tesztelők újdonságok megismertetésére, jó alkalom arra is, hogy a fejlesztők bemutassák munkájuk eredményét, és jelezzék szerzőségüket. Nos, és persze csiszold a nyilvános beszédkészségedet, ami sosem árt.
A különösen jeles kollégák jelentős közreműködését érdemes oklevéllel, emléktáblával (legalább kedves szóval) megünnepelni a közös csapattalálkozókon. Az ilyen okleveleket, emléktáblákat az emberek általában nagyon értékelik, költözéskor magukkal viszik, és általában minden lehetséges módon vigyáznak rájuk.
A csapat munkájához való jelentősebb, hosszú távú hozzájárulás, a felhalmozott tapasztalat és szakértelem jelzésére gyakran alkalmaznak osztályzati rendszert (ismét analógia vonható a hadsereg katonai rendfokozatának rendszerével, amely ráadásul alárendeltség biztosítására is ezt a célt szolgálja). A fiatal fejlesztők gyakran kétszer annyit dolgoznak, hogy új sztárokat szerezzenek a vállpántjaikra (azaz junior fejlesztőből főállású fejlesztővé váljanak stb.).
Az emberek elvárásainak ismerete kritikus. Egyeseket nagyobb valószínűséggel motivál a magas besorolás, az a lehetőség, hogy mondjuk építésznek nevezzék őket, míg mások éppen ellenkezőleg, közömbösek a fokozatok és címek iránt, és a fizetésemelést a cég elismerésének jelének tekintik. . Kommunikáljon az emberekkel, hogy megértse, mit akarnak és mik az elvárásaik.
Az elismerés, a magasabb szintű bizalom a csapat részéről az lehet, ha nagyobb cselekvési szabadságot adunk, vagy új munkaterületeken veszünk részt. Például egy programozó bizonyos tapasztalatok megszerzése és bizonyos eredmények elérése után amellett, hogy sajátosságait a specifikációnak megfelelően implementálja, új dolgok architektúráján dolgozhat. Vagy vegyen részt olyan új területeken, amelyek nem feltétlenül kapcsolódnak közvetlenül a fejlesztéshez - tesztautomatizálás, legjobb mérnöki gyakorlatok bevezetése, kiadáskezelési segítség, konferenciákon való felszólalások stb.
V. A megismerés és az önmegvalósítás igénye.
Sok programozó különböző típusú programozási tevékenységekre összpontosít élete különböző szakaszaiban. Vannak, akik szeretnek gépi tanulást végezni, új adatmodelleket fejleszteni, sok tudományos irodalmat olvasni munkájukhoz, és a semmiből újat alkotni. Egy másik közelebb áll a hibakereséshez és egy meglévő alkalmazás támogatásához, amelyben mélyre kell ásni a meglévő kódot, tanulmányozni kell a naplókat, a nyomkövetéseket és a hálózati captchákat napokon és heteken keresztül kell rögzíteni, és szinte semmilyen új kódot nem kell írni.
Mindkét folyamat nagy intellektuális erőfeszítést igényel, de gyakorlati eredménye más. Úgy gondolják, hogy a programozók vonakodnak a meglévő megoldások támogatásától, inkább motiváltak új megoldások fejlesztésére. Ebben van egy kis bölcsesség. Másrészt a legmotiváltabb és legegységesebb csapat, amellyel valaha is dolgoztam, egy meglévő termék támogatására, a hibák felkutatására és kijavítására törekedett, miután a támogatási csapat felvette velük a kapcsolatot. A srácok szó szerint ennek a munkának éltek, és készen álltak arra, hogy szombaton és vasárnap kimenjenek. Egyszer lelkesen foglalkoztunk egy újabb sürgető és összetett problémával, akár december 31-én este, akár január 1-jén délután.
Számos tényező befolyásolta ezt a magas motivációt. Először is, ez egy nagy hírnévvel rendelkező cég volt az iparágban, a csapat összekötötte magát vele (lásd: „A társulás szükségessége”). Másodszor, ők voltak az utolsó határ, nem volt mögöttük senki, akkor még nem volt termékcsapat. Köztük és az ügyfelek között két szintű támogatás volt, de ha elérte őket a probléma, akkor nem volt hova visszavonulni, senki nem állt mögöttük, az egész cég rajtuk volt (négy fiatal programozó). Harmadszor, ennek a nagyvállalatnak nagyon nagy ügyfelei (országok kormányai, autó- és légiközlekedési konszernek stb.) és nagyon nagy méretű létesítményei voltak több országban. Ennek eredményeként a mindig összetett és érdekes problémákat, egyszerű problémákat a korábbi szintek támogatásával oldották meg. Negyedszer, a csapat motivációját nagyban befolyásolta a támogató csapat szakmai szintje, akivel kapcsolatba kerültek (nagyon tapasztalt és műszakilag jól képzett mérnökök voltak), és mindig bíztunk az általuk készített adatok minőségében, az elvégzett elemzésekben. stb. Ötödször, és azt hiszem, ez a legfontosabb pont - a csapat nagyon fiatal volt, minden srác pályafutása elején járt. Érdekelték őket egy nagy és összetett termék tanulmányozása, a számukra újszerű, komoly problémák új környezetben való megoldása, igyekeztek szakmailag megfelelni a környező csapatok, problémák, ügyfelek színvonalának. A projekt kiváló iskolának bizonyult, később mindenki jó karriert futott be a cégben, és műszaki vezetők és felsővezetők lettek, az egyik srác jelenleg az Amazon Web Services műszaki vezetője, a másik végül a Google-hoz költözött, és minden közülük még mindig melegséggel emlékeznek erre a projektre.
Ha ez a csapat olyan programozókból állna, akik 15-20 éves tapasztalattal a hátuk mögött állnak, akkor más lenne a motiváció. Az életkor és a tapasztalat természetesen nem 100%-ban meghatározó tényező, minden a motiváció szerkezetétől függ. Ebben az esetben a fiatal programozók tudásvágya és fejlődése kiváló eredményeket hozott.
Általánosságban, ahogy azt már többször említettük, ismernie kell programozói elvárásait, meg kell értenie, hogy melyikük szeretné bővíteni vagy megváltoztatni tevékenységi körét, és figyelembe kell vennie ezeket az elvárásokat.
Maslow piramisán túl: az eredmények láthatósága, gamification és verseny, semmi baromság
A programozók motivációjával kapcsolatban van még három fontos szempont, amelyeket mindenképpen meg kell említeni, de ezek bevonása Maslow szükségleti modelljébe túlságosan mesterséges lenne.
Az első az eredmény láthatósága és közelsége.
A szoftverfejlesztés általában egy maraton. A K+F erőfeszítések eredménye hónapok, néha évek múlva válik láthatóvá. Nehéz eljutni a horizonton túli célhoz, a munka mennyisége ijesztő, a cél messze van, nem világos és nem látható, „sötét az éjszaka és tele van borzalmakkal”. Jobb, ha a hozzá vezető utat részekre bontjuk, utat csinálunk a legközelebbi fához, amely jól látható, elérhető, a körvonalai tiszták, és nincs messze tőlünk - és menjünk el ehhez a közeli célhoz. Több napot vagy hetet akarunk erőfeszítéseket tenni, megkapni és értékelni az eredményt, majd továbblépni. Ezért érdemes apró részekre bontani a munkát (a sprintek agilisban jól szolgálják ezt a célt). A munka egy részét befejeztük - rögzítettük, kilélegztük, megbeszéltük, megbüntették a vétkeseket, megjutalmaztuk az ártatlanokat - kezdhetjük a következő ciklust.
Ez a motiváció bizonyos mértékig hasonló ahhoz, amit a játékosok a számítógépes játékok teljesítése során tapasztalnak: időszakonként érmeket, pontokat, bónuszokat kapnak az egyes szintek teljesítésekor; ezt nevezhetjük „dopaminmotivációnak”.
Ugyanakkor az eredmény láthatósága szó szerint fontos. A listában egy zárt funkciónak zöldre kell váltania. Ha a kódot megírják, tesztelik, kiadják, de a programozó számára nem látható változás a vizuális státuszban, hiányosnak érzi magát, nem lesz befejezettség érzése. A verziókezelő rendszerünk egyik csapatában minden javítás három egymást követő szakaszon ment keresztül – a build összeállításra került, és a tesztek sikeresek voltak, a javítás átment a kódellenőrzésen, a javítás összevonásra került. Minden szakaszt vizuálisan zöld pipával vagy piros kereszttel jelöltek. Egyszer az egyik fejlesztő panaszkodott, hogy a kód áttekintése túl sokáig tartott, a kollégáknak gyorsítaniuk kellett, a javítások több napig lógtak. Megkérdeztem, mit változtat ez valójában nála? Végül is, amikor a kód meg van írva, a build össze van állítva és a tesztek sikeresek, akkor nem kell figyelnie a küldött javításra, ha nincsenek megjegyzések. A kollégák maguk fogják felülvizsgálni és jóváhagyni (ha ismételten nincs megjegyzés). Azt válaszolta: "Igor, a lehető leghamarabb meg akarom szerezni a három zöld kullancsomat."
A második pont a gamification és a verseny.
Az egyik termék fejlesztése során mérnökcsapatunknak az volt a célja, hogy az egyik nyílt forráskódú termék közösségében előkelő helyet foglaljon el, bekerüljön a legjobb 3 közé. Abban az időben nem volt objektív mód valakinek a közösségben való láthatóságának felmérésére, a résztvevő nagyvállalatok mindegyike állíthatta (és időnként állította), hogy ő volt az első számú közreműködő, de a résztvevők hozzájárulását nem igazán lehetett összehasonlítani. egymás között, hogy időben értékeljék annak dinamikáját. Ennek megfelelően nem lehetett néhány papagájban mérhető célt kitűzni a csapat elé, felmérni a teljesítésének mértékét stb. A probléma megoldására csapatunk kifejlesztett egy eszközt a vállalatok és egyéni közreműködők hozzájárulásának mérésére és megjelenítésére . Motivációs szempontból kiderült, hogy ez csak egy bomba. Nem csak a mérnökök és a csapatok figyelték folyamatosan saját, valamint kollégáik és versenytársaik fejlődését. Cégünk felső vezetése és minden jelentősebb versenytárs is stackalytics-el kezdte a napját. Minden nagyon átlátható és vizuális lett, mindenki gondosan figyelemmel kísérhette a fejlődését, összehasonlíthatta a kollégákkal stb. A mérnökök, menedzserek és csapatok számára kényelmes és egyszerűvé vált a célok kitűzése.
A mennyiségi mérőszámok bármely rendszerének megvalósítása során felmerülő fontos szempont, hogy amint bevezette azokat, a rendszer automatikusan igyekszik előtérbe helyezni ezeknek a mennyiségi mérőszámoknak az elérését, a minőségi mérőszámok rovására. Például az elvégzett kód-ellenőrzések számát a rendszer az egyik mérőszámként használja. Nyilvánvalóan a kódellenőrzés többféleképpen is elvégezhető, több órát tölthet egy komplex javítás alapos áttekintésével és ellenőrzésével, ellenőrzési tesztekkel, lefuttatásával, dokumentációval való ellenőrzésével, és plusz egy felülvizsgálatot kaphat a karmájában, ill. vakon kattints pár perc alatt pár tucat foltot, adj mindegyiknek +1-et és kapsz plusz húsz karmát. Voltak komikus esetek, amikor a mérnökök olyan gyorsan kattintottak a javításokra, hogy +1-et adtak a CI rendszer automatikus javításaira. Ahogy később tréfálkoztunk: „menj, menj, jenkinek”. A commitok esetében is sokan voltak, akik kódformázó eszközökkel végigmentek a kódon, megjegyzéseket szerkesztettek, pontokat vesszőre cseréltek, és ezzel felpumpálták a karmáját. Ennek kezelése meglehetősen egyszerű: használjuk a józan észt, és a mennyiségi mérőszámok mellett a lényeges, minőségi mérőszámokat is alkalmazzuk. A csapat munkájának eredményeinek felhasználási foka, a külső közreműködők száma, a tesztlefedettség szintje, a modulok és a teljes termék stabilitása, a méret- és teljesítménytesztek eredményei, az alapbírálói vállát kapott mérnökök száma hevederek, az a tény, hogy a projekteket elfogadták az alapprojektek közösségébe, a tervezési folyamat különböző szakaszaiban meghatározott kritériumoknak való megfelelés - mindezeket és sok más tényezőt egyszerű mennyiségi mérőszámok mellett kell értékelni.
És végül a harmadik pont - Nem baromság.
A fejlesztők nagyon okos emberek és rendkívül logikusak a munkájuk során. Napi 8-10 órát töltenek hosszú és összetett logikai láncok építésével, így menet közben látják bennük a sebezhetőséget. Amikor csinálnak valamit, ők is, mint mindenki más, meg akarják érteni, hogy miért csinálják, mi fog változni jó irányba. Rendkívül fontos, hogy a csapata számára kitűzött célok őszinték és reálisak legyenek. Rossz ötlet eladni egy programozó csapatnak. Egy ötlet akkor rossz, ha te magad nem hiszel benne, vagy extrém esetben nincs benned az egyet nem értés és az elköteleződés belső állapota (nem értek egyet, de megteszem). Valamikor egy cégnél bevezettünk egy motivációs rendszert, melynek egyik eleme egy elektronikus visszacsatolási rendszer volt. Rengeteg pénzt fektettek be, Amerikába vittek embereket képzésre, általában maximálisan befektettek. Egyszer a tréning utáni beszélgetés során az egyik vezető azt mondta a beosztottainak: „Nem rossz az ötlet, úgy néz ki, hogy működni fog. Én magam nem adok elektronikus visszajelzést, de te megadod az embereidnek, és követeled tőlük." Ennyi, nem lehetett tovább megvalósítani semmit. Az ötletnek persze semmi lett a vége.
Forrás: will.com