Epigraf:
Soțul, uitându-se la copiii murdari, îi spune soției: ei, pe aceștia îi spălăm sau îi naștem alții noi?
Mai jos se află a doua parte a unui articol al liderului nostru de echipă, precum și al directorului de dezvoltare a produselor RAS, Igor Marnat, despre particularitățile motivarii programatorilor. Prima parte a articolului poate fi găsită aici -
În prima parte a articolului, am atins cele două niveluri inferioare ale piramidei lui Maslow: nevoi fiziologice, nevoi de siguranță, confort și constanță și trec la următorul, al treilea nivel, și anume:
III - Nevoia de apartenență și iubire
Știam că mafia italiană se numește „Cosa Nostra”, dar am fost foarte impresionat când am aflat cum se traduce „Cosa Nostra”. „Cosa Nostra” tradus din italiană înseamnă „afacerea noastră”. Alegerea numelui este foarte reușită pentru motivație (să lăsăm deoparte ocupația, în acest caz ne interesează doar motivația). O persoană dorește de obicei să facă parte dintr-o echipă, să facă o afacere mare, comună, a noastră.
O mare importanță se acordă satisfacerii nevoii de apartenență și dragoste în armată, marina și orice formațiuni mari paramilitare. Și, după cum vedem, în mafie. Acest lucru este de înțeles, pentru că trebuie să forțați oameni care au puține în comun, care inițial nu formează o echipă de oameni cu gânduri similare, care sunt reuniți prin recrutare (nu voluntar), care au niveluri diferite de educație, valori personale diferite. , pentru a-și dedica literalmente viața, cu risc de moarte, unei cauze comune, încredințează-ți viața unui tovarăș de arme.
Aceasta este o motivație foarte puternică; pentru majoritatea oamenilor este extrem de important să simtă că aparțin unui lucru mai mare, să știe că faci parte dintr-o familie, o țară, o echipă. În armată, uniformele, diferitele ritualuri, paradele, marșurile, bannerele și așa mai departe servesc acestor scopuri. Aproximativ aceiași factori sunt importanți pentru orice echipă. Simbolurile, marca corporativă și culorile corporative, accesoriile și suvenirurile sunt importante.
Este important ca evenimentele semnificative să aibă propria lor întruchipare vizibilă cu care pot fi asociate. În zilele noastre, este mai degrabă norma ca o companie să aibă propria marfă, jachete, tricouri etc. Dar este important să evidențiem și echipa din cadrul companiei. Deseori lansăm tricouri pe baza rezultatelor unei lansări, care sunt oferite tuturor celor implicați în eliberare. Unele evenimente, sărbători comune sau activități cu întreaga echipă sunt un alt factor important de motivare.
Pe lângă atributele externe, mai mulți alți factori influențează sentimentul de apartenență la o echipă.
În primul rând, prezența unui obiectiv comun pe care toată lumea îl înțelege și împărtășește o evaluare a importanței acestuia. De obicei, programatorii vor să înțeleagă că fac un lucru grozav și fac acest lucru grozav împreună, ca o echipă.
În al doilea rând, echipa trebuie să aibă un spațiu de comunicare în care să fie prezentă întreaga echipă și care să aparțină doar acesteia (de exemplu, un chat în messenger, sincronizari periodice ale echipei). Pe lângă problemele de muncă, comunicarea informală, uneori discuții despre evenimente externe, lumina offtop - toate acestea creează un sentiment de comunitate și echipă.
În al treilea rând, aș evidenția introducerea de bune practici inginerești în cadrul echipei, dorința de a ridica standarde față de cele acceptate în companie. Implementarea celor mai bune abordări acceptate în industrie, mai întâi în echipă și apoi în companie în ansamblu, oferă echipei posibilitatea de a simți că este înaintea celorlalți într-un fel, deschizând calea, acest lucru creează un sentiment de apartenență unei echipe cool.
Sentimentul de apartenenta este influentat si de participarea echipei la planificare si management. Atunci când membrii echipei sunt implicați în discutarea obiectivelor proiectului, a planurilor de lucru, a standardelor echipei și a practicilor de inginerie și în intervievarea noilor angajați, ei dezvoltă un sentiment de participare, de proprietate comună și de influență asupra muncii. Oamenii sunt mult mai dispuși să ducă la îndeplinire deciziile luate și exprimate de ei înșiși decât cele propuse de alții, chiar dacă sunt practic în ton.
Zile de naștere, aniversari, evenimente semnificative din viața colegilor - o pizza comună, un mic cadou din partea echipei dau un sentiment cald de implicare și recunoștință. În unele companii, se obișnuiește să se acorde mici semne memoriale pentru 5, 10, 15 ani de muncă în companie. Pe de o parte, nu cred că acest lucru mă motivează atât de mult pentru noi realizări. Dar, evident, aproape oricine va fi mulțumit că nu a uitat de el. Acesta este unul dintre acele cazuri în care absența unui fapt demotivează mai degrabă decât motivează prezența acestuia. De acord, poate fi destul de păcat dacă LinkedIn ți-a amintit dimineața și te-a felicitat cu ocazia a 10-a aniversare la locul tău de muncă, dar nici un singur coleg din companie nu te-a felicitat sau și-a amintit de tine.
Desigur, un punct semnificativ este schimbarea în componența echipei. Este clar că, chiar dacă sosirea sau plecarea cuiva din echipă este anunțată din timp (de exemplu, într-un buletin informativ al companiei sau al echipei, sau la o întâlnire de echipă), acest lucru nu motivează în mod deosebit pe nimeni spre noi realizări. Dar dacă într-o bună zi vezi o persoană nouă lângă tine sau nu vezi una veche, poate fi o surpriză, iar dacă pleci, de-a dreptul neplăcut. Oamenii nu ar trebui să dispară în liniște. Mai ales într-o echipă distribuită. Mai ales dacă munca ta depinde de un coleg dintr-un alt birou care s-a ridicat brusc și a dispărut. Astfel de momente merită cu siguranță informați echipa separat în prealabil.
Un factor important, care în engleză se numește proprietate (traducerea literală a „posesiei” nu reflectă pe deplin sensul acesteia). Acesta nu este un sentiment de proprietate, ci mai degrabă un sentiment de responsabilitate pentru proiectul tău, acel sentiment atunci când te asociezi emoțional cu produsul și produsul cu tine însuți. Acest lucru corespunde aproximativ cu rugăciunea marinului din filmul „Full Metal Jacket”: „Aceasta este pușca mea. Există multe astfel de puști, dar aceasta este a mea. Pușca mea este cel mai bun prieten al meu. Ea este viața mea. Trebuie să învăț să-l dețin în același mod în care îmi dețin viața. Fără mine, pușca mea este inutilă. Sunt inutil fără pușca mea. Trebuie să-mi trag pușca drept. Trebuie să trag mai precis decât inamicul care încearcă să mă omoare. Trebuie să-l împușc înainte să mă împuște el. Aşa să fie…”.
Când o persoană lucrează la un produs pentru o perioadă lungă de timp, are posibilitatea de a-și asuma întreaga responsabilitate pentru crearea și dezvoltarea acestuia, pentru a vedea cum un lucru care funcționează iese din „nimic”, cum îl folosesc oamenii, apare acest sentiment puternic. Echipele de produse care lucrează împreună timp îndelungat la un singur proiect sunt de obicei mai motivate și mai coezive decât echipele care sunt asamblate pentru o perioadă scurtă de timp și lucrează în modul linie de asamblare, trecând de la un proiect la altul, fără a avea responsabilitatea deplină pentru întregul proiect. produs, de la început până la sfârșit.
IV. Nevoia de recunoaștere
Un cuvânt bun îi mulțumește și pisicii. Toată lumea este motivată de recunoașterea importanței muncii depuse și de evaluarea pozitivă a acesteia. Discutați cu programatorii, oferiți-le feedback periodic, sărbătoriți o treabă bine făcută. Dacă aveți o echipă mare și distribuită, întâlnirile periodice (ceea ce se numesc unu la unu) sunt perfecte pentru asta; dacă echipa este foarte mică și lucrează împreună la nivel local, această oportunitate este de obicei oferită fără întâlniri speciale în calendar (deși una periodică). la unul este tot ce mai este nevoie, pur și simplu o poți face mai rar). Acest subiect este bine acoperit în podcasturi pentru manageri de pe manager-tools.com.
Cu toate acestea, merită să țineți cont de diferențele culturale. Unele abordări familiare colegilor americani nu vor funcționa întotdeauna cu cele ruși. Nivelul de politețe acceptat în comunicarea zilnică în echipele din țările occidentale pare inițial excesiv programatorilor din Rusia. Unele caracteristici de simplitate ale colegilor ruși pot fi percepute ca nepoliticos de către colegii lor din alte țări. Acest lucru este foarte important în comunicarea într-o echipă interetnică; s-au scris multe despre acest subiect; managerul unei astfel de echipe trebuie să-și amintească acest lucru.
Demonstrațiile de caracteristici, în care programatorii arată caracteristicile dezvoltate în timpul unui sprint, sunt o practică bună pentru a realiza această nevoie. Pe lângă faptul că aceasta este o oportunitate excelentă de a clarifica canalele de comunicare între echipe, de a prezenta managerilor de produse și de testare noile funcții, este și o oportunitate bună pentru dezvoltatori de a arăta rezultatele muncii lor și de a-și indica autoritatea. Ei bine, și lustruiește-ți abilitățile de a vorbi în public, desigur, ceea ce nu este niciodată dăunător.
Ar fi o idee bună să sărbătorim contribuția semnificativă a colegilor deosebit de distinși cu certificate, semne memoriale (cel puțin un cuvânt bun) la întâlnirile comune ale echipelor. Oamenii apreciază de obicei foarte mult astfel de certificate și semne memoriale, le iau cu ei atunci când se mută și, în general, au grijă de ele în toate modurile posibile.
Pentru a marca o contribuție mai semnificativă, pe termen lung, la munca echipei, experiența acumulată și expertiza, este adesea folosit un sistem de grade (din nou, se poate face o analogie cu sistemul gradelor militare din armată, care, în plus pentru asigurarea subordonării, servește și acestui scop). Adesea, dezvoltatorii tineri muncesc de două ori mai mult pentru a obține noi vedete pe bretele lor (adică să treacă de la dezvoltator junior la dezvoltator full-time etc.).
Cunoașterea așteptărilor oamenilor dvs. este esențială. Unii sunt mai susceptibili de a fi motivați de o notă mare, posibilitatea de a fi numiți, să zicem, arhitect, în timp ce alții, dimpotrivă, sunt indiferenți față de note și titluri și vor considera creșterea salariului un semn de recunoaștere din partea companiei. . Comunicați cu oamenii pentru a înțelege ce își doresc și care sunt așteptările lor.
O demonstrație de recunoaștere, un nivel mai ridicat de încredere din partea echipei, poate fi oferită oferind mai multă libertate de acțiune sau implicare în noi domenii de activitate. De exemplu, după ce a dobândit o anumită experiență și a obținut anumite rezultate, un programator, pe lângă implementarea caracteristicilor sale în conformitate cu specificația, poate lucra la arhitectura lucrurilor noi. Sau implicați-vă în noi domenii care ar putea să nu fie direct legate de dezvoltare - automatizarea testelor, implementarea celor mai bune practici de inginerie, ajutor la gestionarea lansărilor, discursuri la conferințe etc.
V. Nevoia de cunoaștere și autoactualizare.
Mulți programatori sunt concentrați pe diferite tipuri de activități de programare în diferite etape ale vieții lor. Unora le place să facă învățare automată, să dezvolte noi modele de date, să citească multă literatură științifică pentru muncă și să creeze ceva nou de la zero. Un altul este mai aproape de depanarea și susținerea unei aplicații existente, în care trebuie să sapi adânc în codul existent, să studiezi jurnalele, să stivezi urme și captch-uri de rețea timp de zile și săptămâni și să nu scrii aproape niciun cod nou.
Ambele procese necesită un efort intelectual mare, dar rezultatul lor practic este diferit. Se crede că programatorii sunt reticenți în a sprijini soluțiile existente; ei sunt mai degrabă motivați să dezvolte altele noi. Există un sâmbure de înțelepciune în asta. Pe de altă parte, cea mai motivată și unită echipă cu care am lucrat vreodată a fost dedicată sprijinirii unui produs existent, găsirii și remedierii erorilor după ce echipa de asistență i-a contactat. Băieții trăiau literalmente pentru această muncă și erau gata să iasă sâmbăta și duminica. Odată ne-am ocupat cu nerăbdare de o altă problemă urgentă și complexă, fie în seara zilei de 31 decembrie, fie în după-amiaza zilei de 1 ianuarie.
Mai mulți factori au influențat această motivație ridicată. În primul rând, era o companie cu un nume mare în industrie, echipa sa asociat cu aceasta (vezi „Nevoia de afiliere”). În al doilea rând, ei erau ultima frontieră, nu era nimeni în spatele lor, nu era nicio echipă de produs la acea vreme. Între ei și clienți existau două niveluri de suport, dar dacă problema ajungea la ei, nu era unde să se retragă, nimeni nu era în spatele lor, toată corporația era pe ei (patru tineri programatori). În al treilea rând, această mare companie avea clienți foarte mari (guvernele țărilor, preocupări de automobile și aviație etc.) și instalații la scară foarte mare în mai multe țări. Ca urmare, problemele mereu complexe și interesante, problemele simple au fost rezolvate prin suportul nivelurilor anterioare. În al patrulea rând, motivația echipei a fost foarte influențată de nivelul profesional al echipei de suport cu care au interacționat (au fost ingineri foarte experimentați și capabili din punct de vedere tehnic), iar noi am fost mereu încrezători în calitatea datelor pe care le-au pregătit, în analiza pe care le-au efectuat. , etc. În al cincilea rând, și cred că acesta este cel mai important punct - echipa era foarte tânără, toți băieții erau la începutul carierei. Au fost interesați să studieze un produs mare și complex, să rezolve probleme serioase care erau noi pentru ei într-un mediu nou, au căutat să se potrivească profesional cu nivelul echipelor din jur, problemelor și clienților. Proiectul s-a dovedit a fi o școală excelentă, toți au făcut mai târziu o carieră bună în companie și au devenit lideri tehnici și manageri superiori, unul dintre băieți este acum manager tehnic la Amazon Web Services, celălalt s-a mutat în cele din urmă la Google și toți dintre ei îşi amintesc încă cu căldură acest proiect .
Dacă această echipă ar fi formată din programatori cu 15-20 de ani de experiență în spate, motivația ar fi alta. Vârsta și experiența nu sunt, desigur, factori 100% determinanți; totul depinde de structura motivației. În acest caz particular, dorința de cunoaștere și creștere a tinerilor programatori a dat rezultate excelente.
În general, așa cum am menționat deja de mai multe ori, trebuie să cunoașteți așteptările programatorilor dvs., să înțelegeți care dintre ei ar dori să-și extindă sau să-și schimbe domeniul de activitate și să țineți cont de aceste așteptări.
Dincolo de piramida lui Maslow: vizibilitatea rezultatelor, gamification și competiție, fără prostii
Mai sunt trei puncte importante cu privire la motivația programatorilor care trebuie menționate cu siguranță, dar atragerea lor în modelul nevoilor lui Maslow ar fi prea artificială.
Prima este vizibilitatea și proximitatea rezultatului.
Dezvoltarea de software este de obicei un maraton. Rezultatele eforturilor de cercetare și dezvoltare devin vizibile după luni, uneori ani. Este dificil să mergi la un obiectiv care este cu mult dincolo de orizont, cantitatea de muncă este înspăimântătoare, scopul este departe, nu este clar și nu este vizibil, „noaptea este întunecată și plină de orori”. Este mai bine să rupeți drumul către el în părți, să faceți o cale către cel mai apropiat copac care este vizibil, accesibil, contururile sunt clare și nu este departe de noi - și mergeți la acest obiectiv apropiat. Vrem să facem un efort de câteva zile sau săptămâni, să obținem și să evaluăm rezultatul, apoi să trecem mai departe. Prin urmare, merită să spargeți munca în părți mici (sprinturile în agile servesc bine acestui scop). Am terminat o parte din lucrare - am înregistrat-o, am expirat, am discutat, i-am pedepsit pe vinovați, i-am recompensat pe cei nevinovați - putem începe următorul ciclu.
Această motivație este într-o oarecare măsură similară cu ceea ce experimentează jucătorii când termină jocuri pe calculator: ei primesc periodic medalii, puncte, bonusuri pe măsură ce termină fiecare nivel; aceasta poate fi numită „motivație pentru dopamină”.
În același timp, vizibilitatea rezultatului este literalmente importantă. O caracteristică închisă din listă ar trebui să devină verde. Dacă codul este scris, testat, eliberat, dar nu există nicio schimbare în starea vizuală vizibilă pentru programator, acesta se va simți incomplet, nu va exista niciun sentiment de finalizare. Într-una dintre echipele din sistemul nostru de control al versiunilor, fiecare patch a trecut prin trei etape succesive - build-ul a fost asamblat și testele au trecut, patch-ul a trecut de revizuirea codului, patch-ul a fost fuzionat. Fiecare etapă a fost marcată vizual cu o căpușă verde sau cruce roșie. Odată ce unul dintre dezvoltatori s-a plâns că revizuirea codului a durat prea mult, colegii au trebuit să accelereze, patch-urile au rămas suspendate timp de câteva zile. Am întrebat, ce schimbă de fapt asta pentru el? La urma urmei, când codul este scris, construcția este asamblată și testele au trecut, nu trebuie să acorde atenție patch-ului trimis dacă nu există comentarii. Înșiși colegii îl vor revizui și aproba (dacă, din nou, nu există comentarii). El a răspuns: „Igor, vreau să-mi iau cele trei căpușe verzi cât mai curând posibil.”
Al doilea punct este gamificarea și competiția.
La dezvoltarea unuia dintre produse, echipa noastră de ingineri a avut scopul de a ocupa o poziție proeminentă în comunitatea unuia dintre produsele open source, pentru a intra în top-3. La acel moment, nu exista o modalitate obiectivă de a evalua vizibilitatea cuiva în comunitate; fiecare dintre marile companii participante putea pretinde (și susținea periodic) că este contribuitorul numărul unu, dar nu exista o modalitate reală de a compara contribuția participanților. între ele, pentru a-i evalua dinamica în timp. În consecință, nu a existat nicio modalitate de a stabili un obiectiv pentru echipă care să poată fi măsurat la unii papagali, de a evalua gradul de realizare etc. Pentru a rezolva această problemă, echipa noastră a dezvoltat un instrument de măsurare și vizualizare a contribuției companiilor și contribuabililor individuali . Din punct de vedere motivațional, s-a dovedit a fi doar o bombă. Nu doar inginerii și echipele au monitorizat constant progresul lor și progresul colegilor și concurenților lor. Conducerea de top a companiei noastre și toți concurenții importanți și-au început ziua cu stackalytics. Totul a devenit foarte transparent și vizual, toată lumea își putea monitoriza cu atenție progresul, se putea compara cu colegii etc. A devenit convenabil și ușor pentru ingineri, manageri și echipe să stabilească obiective.
Un punct important care apare la implementarea oricărui sistem de metrici cantitative este că de îndată ce le-ați implementat, sistemul se străduiește automat să prioritizeze realizarea acestor metrici cantitative, în detrimentul celor calitative. De exemplu, numărul de revizuiri de cod finalizate este utilizat ca una dintre valori. Evident, revizuirea codului poate fi făcută în moduri diferite, puteți petrece câteva ore pentru o revizuire amănunțită și verificarea unui patch complex cu teste de verificare, rulând-o pe bancul dvs., verificând cu documentație și obțineți plus o revizuire în karma dvs. sau faceți clic orbește pe câteva zeci de patch-uri în câteva minute, acordați fiecăruia +1 și obțineți plus douăzeci în karma. Au fost cazuri comice când inginerii au făcut clic pe patch-uri atât de repede încât au dat +1 patch-urilor automate din sistemul CI. După cum am glumit mai târziu, „du-te, du-te, Jenkins”. În cazul commit-urilor, au fost și mulți oameni care au trecut prin codul cu instrumente de formatare a codului, au editat comentarii, au schimbat punctele în virgule și astfel și-au pompat karma. A trata acest lucru este destul de simplu: folosim bunul simț și, pe lângă metricile cantitative, folosim și cele esențiale, calitative. Gradul de utilizare a rezultatelor muncii echipei, numărul de colaboratori externi, nivelul de acoperire a testelor, stabilitatea modulelor și a întregului produs, rezultatele testării la scară și a performanței, numărul de ingineri care au primit umărul recenzentului de bază bretele, faptul că proiectele au fost acceptate în comunitatea proiectelor de bază, respectarea criteriilor diferitelor etape ale procesului de inginerie - toți aceștia și mulți alți factori trebuie evaluați împreună cu metrici cantitative simple.
Și în sfârșit, al treilea punct - Fără prostii.
Dezvoltatorii sunt oameni foarte inteligenți și extrem de logici în domeniul lor de activitate. Ei petrec 8-10 ore pe zi construind lanțuri logice lungi și complexe, așa că văd vulnerabilități în ele din mers. Când fac ceva, ei, ca toți ceilalți, vor să înțeleagă de ce o fac, ce se va schimba în bine. Este extrem de important ca obiectivele pe care le-ați stabilit pentru echipa dumneavoastră să fie oneste și realiste. Încercarea de a vinde o idee proastă unei echipe de programare este o idee proastă. O idee este rea dacă tu nu crezi în ea sau, în cazuri extreme, nu ai starea internă de a nu fi de acord și a te angajezi (nu sunt de acord, dar o voi face). Am implementat odată un sistem de motivare într-o companie, unul dintre elementele căruia era un sistem electronic de furnizare de feedback. Au investit mulți bani, au dus oameni în America pentru antrenament, în general, au investit la maxim. Odată, într-o conversație de după antrenament, unul dintre manageri le-a spus subalternilor săi: „Ideea nu este rea, se pare că va funcționa. Nu-ți voi oferi eu însumi feedback electronic, dar tu le oferi oamenilor tăi și le ceri de la ei.” Gata, nimic nu s-a mai putut implementa. Ideea, desigur, s-a terminat în nimic.
Sursa: www.habr.com