opschrift:
De man kijkt naar de vuile kinderen en zegt tegen zijn vrouw: zullen we deze wassen of nieuwe baren?
Onder de tekst vindt u de discussie van onze teamleider en RAS Product Development Director, Igor Marnat, over de eigenaardigheden van het motiveren van programmeurs.
Het geheim van succes bij het maken van coole softwareproducten is bekend: neem een team van coole programmeurs, geef het team een cool idee en bemoei je niet met het werk van het team. Coole ontwikkelaars zijn zeldzaam en er is veel vraag naar. Sommige recruiters zeggen zelfs dat ze de indruk hebben dat het makkelijker is om een coole programmeur te produceren dan er één uit de markt te huren. Naast de problemen bij het aannemen van personeel als zodanig, is de ervaring van elke specifieke ontwikkelaar, zijn kennis van het bestaande product en de geschiedenis van de ontwikkeling ervan, vaak onvervangbaar of moeilijk en tijdrovend om aan te vullen. Als je geluk hebt en al een cool team programmeurs hebt, is het daarom belangrijk om aan hun motivatie te werken. Het inhuren en trainen van nieuwe ontwikkelaars en het samenstellen van een team is bijna net zo moeilijk en tijdrovend als het baren en opvoeden van kinderen.
Laten we eens kijken naar de belangrijkste motivatiefactoren voor programmeurs (teams van programmeurs), waarbij we de piramide van Maslow gebruiken voor duidelijkheid en structurering van de presentatie. Als je nog nooit van de piramide van Maslow hebt gehoord: het is geen onbetwiste, maar zeer populaire en illustratieve theorie van de Amerikaanse psycholoog Abraham Harold Maslow, die een theorie van persoonlijke motivatie voorstelde, gebaseerd op de hiërarchie van menselijke behoeften (zie onderstaande afbeelding).
Maslow rangschikte de behoeften van het individu in een hiërarchische volgorde, van fysiologische behoeften tot de behoefte aan potentiële ontwikkeling en zelfactualisatie. Een belangrijke veronderstelling in de theorie van Maslow is dat 'een persoon geen behoeften op een hoger niveau kan ervaren totdat zijn behoeften op een lager niveau zijn bevredigd'. Een persoon kan bijvoorbeeld niet gedreven worden door de behoefte aan kennis of esthetische behoeften als deze persoon tegelijkertijd drie dagen niet heeft geslapen of gegeten.
Voordat we in details treden, laten we ons concentreren op een voor de hand liggend feit: een team bestaat uit mensen, alle mensen zijn verschillend, elk heeft zijn eigen motivatiestructuur. Naast het feit dat ieder mens wordt gedreven door verschillende belangen, bevindt ieder mens zich ook in andere leefomstandigheden. Iemand staat aan het begin van een carrière en denkt na over hoe hij die wil opbouwen, iemand gaat trouwen en iemand wil zich een nieuw vakgebied eigen maken. Wat voor de één belangrijk is, is voor de ander volkomen onbelangrijk, en morgen zal alles weer veranderen. Om deze context correct te begrijpen, is er een eenvoudige oplossing: je moet erover nadenken en ermee werken. Het allerbelangrijkste is communicatie.
Zorg ervoor dat je met je team over iets anders dan werk praat, en bouw informele relaties op.
Laten we nu de piramide van Maslow eens doornemen en de niveaus ervan beschouwen als toegepast op het managen van een team programmeurs.
I: Fysiologische, biologische behoeften:
Als het over motivatie gaat, denken veel mensen vaak in de eerste plaats aan het salaris. Met salaris bedoel ik in dit geval een vast onderdeel van het verloningspakket, dat op geen enkele wijze afhankelijk is van de resultaten. Dit geldt niet voor bonussen, bonussen en bedrijfspromoties. Het is het salaris dat ik in ons geval zou toeschrijven aan het niveau van de ‘fysiologische behoeften’. Bonussen, bonussen op basis van prestaties, opties en bedrijfsaandelen - ik zou dit allemaal op andere niveaus classificeren.
Naar mijn mening zou het salaris, hoe vreemd het ook mag klinken, best wel zo kunnen zijn demotiverend factor in plaats van een motiverende factor. Het bijzondere van het werken met programmeurs is dat het allemaal mensen zijn, ten eerste heel slim (een kenmerk van het vak), en ten tweede diep en/of breed opgeleid. Doorgaans hebben programmeurs, naast hun beroep, een diepgaand inzicht in een of meer vakgebieden waarvoor ze producten maken. Bovendien zijn goede programmeurs geïnteresseerd in en kennen ze de geschiedenis van programmeerontwikkeling, algoritmen, standaarden, enz. goed. Hetzelfde geldt voor hun vakgebied. Voor mensen op dit niveau is salaris meestal niet de belangrijkste motiverende factor.
Tegelijkertijd demotiveert en demotiveert het gebrek aan een eerlijk salaris voor programmeurs, naar hun mening, enorm. Een eerlijk salaris is de norm. Het salaris is veel hoger dan de norm (markt) - ook, vreemd genoeg, een nogal demotiverende factor. Een collega vertelde me ooit over een team programmeurs bij een van de grote Amerikaanse animatiebedrijven, die door een aantal omstandigheden salarissen ontvingen die twee tot drie keer hoger lagen dan de markt. Zoals hij zei, hij had nog nooit in zijn leven meer verveelde, luie en gedemotiveerde programmeurs gezien. Het feit van een salarisverhoging kan op korte termijn motiveren, maar na een paar maanden wordt het nieuwe salaris de norm en houdt het op te motiveren. Over het algemeen zou ik zeggen dat voor programmeurs aan het begin van hun carrière de salarisfactor belangrijker is, naarmate ze professioneel groeien en zich ontwikkelen, het belang ervan afneemt en andere factoren de overhand beginnen te krijgen.
Het tweede belangrijke punt is de aanwezigheid van een eerlijk evenwicht in het niveau van de salarissen in het team. Als een team het gevoel heeft dat de bijdrage van één lid merkbaar lager is, maar het beloningsniveau hetzelfde is, zal dit het hele team demotiveren. Soms komen managers in de verleiding om het vuur met geld aan te wakkeren – om een opgebrand of gedemotiveerd persoon te behouden door zijn salaris boven normaal te verhogen. Dit levert meestal pas op de lange termijn problemen op - de motivatie van de persoon zelf zal niet veel toenemen, of gedurende een paar maanden, maar de motivatie van de rest van het team zal afnemen. In dergelijke situaties is het de moeite waard om naar andere benaderingen te zoeken, tenzij dit natuurlijk een unieke specialist is die koste wat het kost moet worden behouden, zelfs voor een korte tijd.
II. Behoefte aan veiligheid, comfort en consistentie van levensomstandigheden:
70 jaar geleden kon de aanwezigheid van een kachel in een auto een motiverende factor zijn bij het kiezen van een auto; toen was het boven de norm en een teken van luxe. Nu is zelfs de afwezigheid van airconditioning onzin, en de aanwezigheid ervan zal uiteraard geen motiverende factor zijn bij het kiezen van een auto. Dus 10-15 jaar geleden een handig kantoor, goede hardware, heerlijke koffie, fitness, flexibele uren, etc. zouden goede motiverende factoren kunnen zijn, maar nu is dit eerder de norm voor het werk van een goede programmeur. Tegelijkertijd zal hun afwezigheid opnieuw demotiverend zijn.
Een belangrijke demotiverende factor is het gebrek aan concentratievermogen en een luidruchtige werkomgeving. Het werk van een programmeur vereist stilte en concentratie. Als de kantoorruimte niet de mogelijkheid biedt om ontwikkelaars een afgezonderde werkruimte te bieden, is het noodzakelijk om op zijn minst te zorgen voor een comfortabele samenwerking tussen collega's die elkaar niet hinderen. Het is beter om energieke en luide kameraden met elkaar te verenigen, waardoor je de kans krijgt om je te concentreren op degenen die het nodig hebben.
De kosten van de tijd van een programmeur zijn nu aanzienlijk hoger dan de kosten van de hardware waarop hij werkt. Twee of drie monitoren, krachtige computers, een comfortabele werkplek voor elke ontwikkelaar - zou in elk bedrijf de norm moeten zijn. Dit onderwerp wordt goed behandeld in een van de artikelen van Joel Spolsky “De Joel Test: 12 stappen om beter te coderen.”
De fysieke component van comfort is de meest fundamentele en eenvoudige; laten we het nu over de rest hebben.
In veel bedrijven is de norm voor programmeurs een flexibel werkschema en geen dresscode. Dit is goed en correct als de specifieke kenmerken van het werk van het team dit toelaten (er zijn bijvoorbeeld geen ontmoetingen met klanten, politici of bankiers).
Het belangrijkste is om een specifiek tijdsbestek te hebben waarin het hele team lokaal samenwerkt, zodat mensen face-to-face kunnen communiceren en problemen kunnen oplossen. Een programmeur verlaat in wezen zijn werk niet, zelfs niet na het werk. Meestal spelen werkkwesties opnieuw door zijn hoofd, ongeacht of hij op kantoor aanwezig is, en goede beslissingen komen vaak van buiten het kantoor. Gegeven de noodzaak om goed te zijn (wat we hieronder zullen bespreken), is kleine controle schadelijk. Het is niet alleen demotiverend, het vermindert ook de productiviteit. Zoals de praktijk laat zien, is het bij gebrek aan controle waarschijnlijker dat een gemotiveerd team langer doorwerkt dan nodig is. Als er controle is, kunnen ontwikkelaars van negen tot zes aan het toetsenbord zitten, maar het resultaat zal, denk ik, slechter zijn. Zoals ze zeggen, kan één persoon een paard naar het water leiden, maar zelfs honderd zullen hem niet dwingen te drinken als hij dat niet wil.
De beschrijving van dit niveau van behoeften vermeldt ook de vrijheid van angst en angst, de afwezigheid van chaos en de behoefte aan structuur en orde. Ook dit zijn uiterst belangrijke punten die grote invloed hebben op de sfeer in het team.
Ten eerste de afwezigheid van chaos, structuur en orde: het team moet begrijpen wie waarvoor verantwoordelijk is, hoe de rollen zijn verdeeld, wat er moet gebeuren, aan wie, wanneer, welke eisen ten grondslag liggen aan het product, wat de verwachtingen zijn van het management en de klant... Het meeste hiervan moet formeel worden beschreven, alles moet periodiek worden besproken. Zonder discussie en periodiek gebruik werken beschrijvingen niet. Het is een goede gewoonte om deze periodiek te bespreken en bij te werken op basis van de resultaten van de postmortale analyse na vrijlating.
Ten tweede een rustige en vriendelijke sfeer. We brengen allemaal het grootste deel van onze tijd door op het werk, en we willen dit doen zonder stress, conflicten of angst. Het ontwikkelteam werkt meestal onder druk van planningen en klanten. Niemand heeft behoefte aan extra stress van collega’s en leidinggevenden. De sfeer in het team, in het algemeen het feit dat een groep ontwikkelaars kan worden genoemd en een “team” kan zijn, is de directe en belangrijke verantwoordelijkheid van de manager, een van de belangrijkste taken op de middellange en lange termijn. Daarom is het belangrijk dat een manager vooral met conflicten in het team werkt en de ontwikkeling ervan niet op zijn beloop laat. Conflictbeheersing is een apart onderwerp dat een aparte studie verdient.
Er zijn twee belangrijke manieren om de emotionele toestand van het team en het gedrag van collega’s te beïnvloeden (als iemand iets toevoegt in de reacties, zou dat geweldig zijn). De eerste is je eigen gedrag. Persoonlijk voorbeeld is super belangrijk voor een manager en team. Zoals ze zeggen, zoals de priester is, zo is de aankomst. Gedraag je zoals je verwacht dat je collega’s zich gedragen. De tweede is het aanmoedigen van correct gedrag en, om zo te zeggen, het ontmoedigen van verkeerd gedrag. Communiceer met mensen, geef ze feedback, er zijn veel manieren om dit te doen. Over het algemeen is feedback een onderwerp voor een aparte discussie; het is een groot en belangrijk onderdeel van het werken met motivatie.
Nog een opmerking over de sfeer, die misschien ongebruikelijk lijkt, maar in de praktijk belangrijk is. Vaak zitten er minder meisjes in het ontwikkelingsteam dan mannen. Vaak zijn de groepen geheel mannelijk. In dergelijke omstandigheden, ook onder belasting, wordt er in het team soms obscene taal gebruikt. De praktijk leert dat dit negatieve gevolgen heeft voor de sfeer; de communicatie wordt langzamerhand onbeleefd. U moet voorkomen dat u het zelf gebruikt en het gebruik ervan in uw team ontmoedigen.
Ontwikkelingsteams worden vaak R&D (onderzoek en ontwikkeling) genoemd, waarbij onderzoek een aanzienlijk deel van het werk uitmaakt. Dit is het deel dat meestal moeilijk te programmeren en te plannen is, anders zou het geen onderzoek zijn. Het is belangrijk dat het team het recht heeft om fouten te maken, initiatief te nemen, verschillende opties uit te proberen die wel of niet op succes kunnen uitlopen. Fouten zijn een normaal onderdeel van het werk, ze kunnen niet worden vermeden, maar je kunt ze bestuderen, analyseren, ervan leren voor de toekomst en verder gaan. Het 5 Why’s-principe, afkomstig van Toyota, is een goede manier om de oorzaak van een probleem te achterhalen. Het bestraffen van fouten is een geweldige manier om een sfeer van angst en onzekerheid te creëren. De enige uitzondering is wanneer op basis van de resultaten van de analyse blijkt dat de fout werd veroorzaakt door een onprofessionele werkhouding. In dit geval moeten mogelijk personeelsbeslissingen worden genomen.
De sfeer in het team wordt sterk beïnvloed door uw verwachtingen en emotionele toestand voordat het gesprek begint. Voordat u een moeilijke discussie, een soort debriefing of gewoon een emotioneel gesprek begint, is uw stemming en houding ten opzichte van de persoon met wie u gaat praten belangrijk. Standaard geloof en handel ik altijd op basis van wat de persoon oprecht het beste probeerde te doen. Als het vanuit uw standpunt lijkt dat dit niet zo is, moet u rustig en gedetailleerd de context achterhalen en begrijpen wat hij goed heeft gedaan, waarom hij dacht dat het goed was, en waar onze verwachtingen uiteenlopen. Meestal blijkt dat ze niet echt van elkaar verschillen, maar dat zijn visie op de context completer of frisser is, en dat er iets is dat je niet wist. Of omgekeerd: hij wist iets niet. Dit is vooral belangrijk in een gedistribueerd team, wanneer mensen minder vaak persoonlijk communiceren en e-mail en instant messengers gebruiken. Dit is zelfs nog belangrijker in een team dat bestaat uit programmeurs uit verschillende landen en verspreid over verschillende tijdzones. Dit is waar culturele verschillen een grote rol beginnen te spelen.
In een moeilijke situatie is het onderweg gemakkelijk, heel gemakkelijk, maar dan is het moeilijk om terug te rijden en blijft het sediment lange tijd achter. Ik zal u een eenvoudig voorbeeld geven uit recente ervaringen. Een van de teammanagers had dringend behoefte aan commentaar over een probleem met een klant van een manager van een gerelateerd team in een ander land. Hij pingde een collega in de messenger, wachtte 15 minuten, pingde opnieuw, en 15 minuten later ging hij naar een grote chat waarin ook de andere managers zaten, en viel de collega lichtjes aan met een bewoording als: “aangezien je dat niet doet verwaardigen mij misschien te antwoorden, en de vraag is niet zo dringend? Uiteindelijk bleek dat onze bedrijfsboodschapper een beetje saai was en dat de collega de vraag helemaal niet zag. Ik moest me verontschuldigen. Over het algemeen is het beter om met het goede te beginnen. Het is altijd mogelijk om een grote fout te maken en later in de problemen te komen; daar is geen probleem mee (hoewel je dat niet zou moeten doen). Over het algemeen heb ik in de ruim twintig jaar dat ik in onze branche werk, slechts één keer een echt kwaadwillende collega ontmoet (!). Gelukkig zijn we vrij snel uit elkaar gegaan. Het blijkt in de overgrote meerderheid van de gevallen juist te zijn om aan te nemen dat collega’s het beste willen, naar hun beste begrip van de context.
Jouw taak als manager is om te zorgen voor synchronisatie van contexten, een gemeenschappelijk begrip van verwachtingen, vereisten, deadlines en normen die in het team worden geaccepteerd. Het lijken misschien kleine dingen, maar de sfeer in het team is juist uit zulke kleine dingen opgebouwd. Vanuit het perspectief van een gedistribueerd team is een van de belangrijke taken ervoor te zorgen dat teamleden periodiek face-to-face communicatie hebben. Ik heb meer dan eens van programmeurs gehoord dat nadat bijvoorbeeld ingenieurs van het ondersteuningsteam naar hen toe waren gekomen en persoonlijk hadden samengewerkt, ze graag op het werk bleven om in een moeilijk geval persoonlijk te helpen aan Pasha, die onlangs naar hen toe was gekomen. hoewel Pasha eerder slechts een icoon in de messenger was, en niemand zou zijn gestopt omwille van het icoon.
Ik begon trouwens over het ondersteuningsteam te praten en herinnerde me een canoniek voorbeeld. Eens had een van de klanten in Amerika een probleem met het product, een van de engineers van het supportteam die aan zijn implementatie werkte (gedetacheerd vanuit Rusland) bleef na het werk om te helpen, maar het probleem werd niet opgelost en werd niet opgelost. Over het algemeen bleef hij hangen en bleef daar bijna tot de ochtend zitten. Op dat moment escaleerden de managers van de klant het probleem, identificeerden de ernst ervan voor hen en verlieten 's avonds het werk. Het escalatieproces kwam al in een andere tijdzone in een stroomversnelling, ondersteuningsmanagers in Rusland begonnen te proberen te helpen, vanwege bepaalde problemen in de communicatie met het kantoor van de klant (VPN, verbindingsproblemen, problemen met bellen tussen landen, ...). wist niet dat de man al in de gevangenis op kantoor zat en het probleem oplost, en probeerde hem te vinden. Ze vonden het pas in de ochtend (Amerikaans), toen het probleem al praktisch was opgelost en het product werkte. Ze begonnen meteen te zeggen: wat maakt het uit, de klant heeft zo'n escalatie, niets werkt, waar ben je, we kunnen je niet vinden, enz. Het is onnodig om te zeggen dat de man als gevolg van dergelijk gedrag enorm gedemotiveerd was. Het organiseren van het werk van een gedistribueerd team is een apart groot onderwerp, maar het is belangrijk om twee dingen te onthouden. Ten eerste zijn communicatie en sfeer erg belangrijk, het succes van het werk hangt ervan af. Ten tweede werkt dit niet op zichzelf; het moet apart en diepgaand worden aangepakt.
Een ander belangrijk punt met betrekking tot dit niveau van behoeften is opnieuw het salaris. Niet de hoogte van het salaris als zodanig, maar de aanwezigheid van een bepaalde procedure om dit te wijzigen. Het bedrijf moet een aanpak hebben om de vereisten voor functies op verschillende niveaus te bepalen. Elke ontwikkelaar moet de verwachtingen voor zijn werk met het bedrijf kunnen bespreken en begrijpen hoe en wanneer zijn inspanningen van invloed kunnen zijn op zijn salaris. Periodieke bijeenkomsten met de manager, halfjaarlijkse of jaarlijkse prestatiebeoordelingen dienen dit doel. Dit is wederom een van die momenten waarvan de aanwezigheid niet expliciet motiveert, maar hun afwezigheid is zeer demotiverend.
Uit de behoefte aan orde en de aanwezigheid van regels volgt de noodzaak om aan deze regels te voldoen, om de normen te volgen die in het team zijn aanvaard, zowel formeel als informeel. Over het algemeen zou ik het de behoefte noemen om ‘goed te zijn’. De aanwezigheid van deze behoefte bevestigt dat micromanagement niet noodzakelijk is, maar eerder schadelijk. Het is voldoende om iemand alles te bieden wat nodig is voor zijn werk, hem kennis te geven van de context en prioriteiten, en vrijheid van handelen en besluitvorming op zijn niveau te bieden. In dergelijke omstandigheden zal hij vertrouwen voelen, de mogelijkheid om zijn eigen beslissingen te nemen, de verantwoordelijkheid ervoor te nemen en zijn potentieel te onthullen.
Een ander belangrijk punt dat moet worden toegeschreven aan de behoefte aan orde en de afwezigheid van chaos is het vermogen om zich op een taak te concentreren, de afwezigheid van frequente contextwisselingen. Programmeur zijn vereist tijd en focus. Programmeurs houden er echt niet van om de ene taak dringend op te geven en naar een andere over te stappen. Een noodzakelijk onderdeel van het werk van een programmeur is meestal niet alleen de daadwerkelijke ontwikkeling van de code, maar ook het oplossen van bugs en hulp bij het verwerken van verzoeken van klanten. Het is de moeite waard om dergelijke dingen van tevoren te plannen, zodat de programmeur rustig en volledig aan de ene taak kan werken voordat hij naar de andere overschakelt. De beste optie is om uzelf de kans te geven uw werk zelf te plannen, prioriteiten en komende taken van tevoren te identificeren, en lange, langere perioden toe te wijzen aan het werken aan één type taak. Dit onderwerp wordt goed beschreven in het boek “Google - Sitebetrouwbaarheidstechniek”, waarin goed de benaderingen worden beschreven voor het plannen van het werk van teams die zorgen voor de werking en ontwikkeling van grote, zwaarbelaste, fouttolerante systemen, evenals van ingenieurs wier beroep softwareontwikkeling en de ondersteuning ervan combineert.
Wordt vervolgd ...
Bron: www.habr.com