opschrift:
De man kijkt naar de vuile kinderen en zegt tegen zijn vrouw: zullen we deze wassen of nieuwe baren?
Onder de afbeelding staat het tweede deel van een artikel van onze teamleider en RAS Product Development Director Igor Marnat, over de eigenaardigheden van het motiveren van programmeurs. Het eerste deel van het artikel vindt u hier -
In het eerste deel van het artikel heb ik de twee lagere niveaus van de piramide van Maslow aangeraakt: fysiologische behoeften, behoeften aan veiligheid, comfort en standvastigheid, en ga verder naar het volgende, derde niveau, namelijk:
III - Behoefte aan verbondenheid en liefde
Ik wist dat de Italiaanse maffia “Cosa Nostra” heette, maar ik was erg onder de indruk toen ik ontdekte hoe “Cosa Nostra” vertaald wordt. “Cosa Nostra” vertaald uit het Italiaans betekent “Ons bedrijf”. De naamkeuze is zeer succesvol voor de motivatie (laten we het beroep buiten beschouwing laten, in dit geval zijn we alleen geïnteresseerd in motivatie). Normaal gesproken wil iemand deel uitmaken van een team en iets groots, gemeenschappelijks, doen.
Er wordt groot belang gehecht aan het bevredigen van de behoefte aan verbondenheid en liefde in het leger, de marine en alle grote paramilitaire formaties. En, zoals we zien, in de maffia. Dit is begrijpelijk, omdat je mensen moet dwingen die weinig gemeen hebben, die in eerste instantie geen team van gelijkgestemden vormen, die door de dienstplicht (niet vrijwillig) bij elkaar zijn gebracht, die verschillende opleidingsniveaus hebben, verschillende persoonlijke waarden , om letterlijk hun leven, met levensgevaar, te wijden aan een gemeenschappelijk doel, en je leven toe te vertrouwen aan een wapenbroeder.
Dit is een zeer sterke motivatie; voor de meeste mensen is het uiterst belangrijk om het gevoel te hebben dat ze tot iets groters behoren, om te weten dat je deel uitmaakt van een familie, een land, een team. In het leger dienen uniformen, verschillende rituelen, parades, marsen, spandoeken, enzovoort deze doeleinden. Voor elk team zijn ongeveer dezelfde factoren van belang. Symbolen, bedrijfsmerken en bedrijfskleuren, parafernalia en souvenirs zijn belangrijk.
Het is belangrijk dat belangrijke gebeurtenissen hun eigen zichtbare belichaming hebben waarmee ze geassocieerd kunnen worden. Tegenwoordig is het eerder de norm dat een bedrijf zijn eigen merchandise, jassen, T-shirts, enz. heeft. Maar het is ook belangrijk om het team binnen het bedrijf in de kijker te zetten. Vaak geven we op basis van de resultaten van een release T-shirts uit, die worden uitgedeeld aan alle betrokkenen bij de release. Sommige evenementen, gezamenlijke vieringen of activiteiten met het hele team zijn een andere belangrijke motivatiefactor.
Naast externe kenmerken beïnvloeden verschillende andere factoren het gevoel deel uit te maken van een team.
Ten eerste de aanwezigheid van een gemeenschappelijk doel dat iedereen begrijpt en waarvan iedereen het belang ervan deelt. Programmeurs willen meestal begrijpen dat ze iets cools doen, en dat ze dit coole ding samen doen, als team.
Ten tweede moet het team een communicatieruimte hebben waarin het hele team aanwezig is en die alleen tot hem behoort (bijvoorbeeld een chat in de messenger, periodieke teamsyncaps). Naast werkkwesties, informele communicatie, soms discussie over externe gebeurtenissen, licht offtop - dit alles creëert een gevoel van gemeenschap en team.
Ten derde zou ik de introductie van goede technische praktijken binnen het team willen benadrukken, de wens om de normen te verhogen in vergelijking met de normen die binnen het bedrijf worden geaccepteerd. Het implementeren van de beste benaderingen die in de branche worden geaccepteerd, eerst in het team en vervolgens in het bedrijf als geheel, geeft het team de kans om het gevoel te hebben dat het op de een of andere manier voorloopt op anderen en voorop loopt, dit creëert een gevoel van verbondenheid naar een tof team.
Het gevoel ergens bij te horen wordt ook beïnvloed door de deelname van het team aan planning en management. Wanneer teamleden betrokken zijn bij het bespreken van projectdoelen, werkplannen, teamnormen en technische praktijken, en het interviewen van nieuwe werknemers, ontwikkelen ze een gevoel van participatie, gedeeld eigenaarschap en invloed op het werk. Mensen zijn veel meer bereid beslissingen uit te voeren die zij zelf hebben genomen en geuit dan die welke door anderen zijn voorgesteld, ook al zijn ze praktisch op elkaar afgestemd.
Verjaardagen, jubilea, belangrijke gebeurtenissen in het leven van collega's - een gezamenlijke pizza, een klein cadeautje van het team geven een warm gevoel van betrokkenheid en dankbaarheid. In sommige bedrijven is het gebruikelijk om kleine herdenkingsborden te geven voor 5, 10, 15 jaar werk in het bedrijf. Aan de ene kant denk ik niet dat dit mij zo motiveert voor nieuwe prestaties. Maar het is duidelijk dat bijna iedereen blij zal zijn dat ze hem niet zijn vergeten. Dit is een van die gevallen waarin de afwezigheid van een feit eerder demotiveert dan de aanwezigheid ervan. Mee eens, het kan best jammer zijn als LinkedIn je er 's ochtends aan herinnerde en je feliciteerde met je 10-jarig jubileum op je werkplek, maar geen enkele collega van het bedrijf feliciteerde of herinnerde je.
Een belangrijk punt is natuurlijk de verandering in de samenstelling van het team. Het is duidelijk dat zelfs als de aankomst of het vertrek van iemand uit het team vooraf wordt aangekondigd (bijvoorbeeld in een bedrijfs- of teamnieuwsbrief, of tijdens een teamvergadering), dit niemand bijzonder motiveert tot nieuwe prestaties. Maar als je op een mooie dag een nieuwe persoon naast je ziet, of de oude niet ziet, kan dat een verrassing zijn, en als je weggaat, ronduit onaangenaam. Mensen mogen niet stilletjes verdwijnen. Vooral in een gedistribueerd team. Vooral als je werk afhankelijk is van een collega van een ander kantoor die plotseling opstond en verdween. Dergelijke momenten zijn zeker de moeite waard om het team vooraf apart te informeren.
Een belangrijke factor, die in het Engels wordt genoemd ownership (de letterlijke vertaling van ‘bezit’ geeft de betekenis ervan niet volledig weer). Dit is geen gevoel van eigenaarschap, maar eerder een gevoel van verantwoordelijkheid voor je project, dat gevoel wanneer je jezelf emotioneel associeert met het product en het product met jezelf. Dit komt grofweg overeen met het gebed van de marinier in de film ‘Full Metal Jacket’: “Dit is mijn geweer. Er zijn veel van dergelijke geweren, maar deze is van mij. Mijn geweer is mijn beste vriend. Zij is mijn leven. Ik moet leren er eigenaar van te worden, op dezelfde manier waarop ik mijn leven bezit. Zonder mij is mijn geweer nutteloos. Ik ben nutteloos zonder mijn geweer. Ik moet mijn geweer recht schieten. Ik moet nauwkeuriger schieten dan de vijand die mij probeert te vermoorden. Ik moet hem neerschieten voordat hij mij neerschiet. Laat het zo zijn
Wanneer een persoon lange tijd aan een product werkt, de mogelijkheid heeft om de volledige verantwoordelijkheid te dragen voor de creatie en ontwikkeling ervan, om te zien hoe een werkend ding voortkomt uit “niets”, hoe mensen het gebruiken, ontstaat dit krachtige gevoel. Productteams die lange tijd samenwerken aan één project zijn doorgaans gemotiveerder en hechter dan teams die voor een korte periode worden samengesteld en aan de lopende band werken, waarbij ze van het ene project naar het andere overschakelen, zonder de volledige verantwoordelijkheid voor het geheel te dragen. product, van begin tot eind.
IV. Behoefte aan erkenning
Een vriendelijk woord bevalt de kat ook. Iedereen wordt gemotiveerd door de erkenning van het belang van het werk dat ze hebben gedaan en de positieve beoordeling ervan. Praat met programmeurs, geef ze periodiek feedback, vier goed uitgevoerd werk. Als je een groot en verspreid team hebt, zijn periodieke bijeenkomsten (die één op één worden genoemd) hier perfect voor; als het team erg klein is en lokaal samenwerkt, wordt deze mogelijkheid meestal geboden zonder speciale bijeenkomsten op de kalender (hoewel periodieke bijeenkomsten één is alles. Het is nog steeds nodig, je kunt het alleen minder vaak doen). Dit onderwerp wordt goed behandeld in podcasts voor managers op manager-tools.com.
Het is echter de moeite waard om culturele verschillen in gedachten te houden. Sommige benaderingen die Amerikaanse collega's kennen, zullen niet altijd werken met Russische benaderingen. Het niveau van beleefdheid dat wordt geaccepteerd in de dagelijkse communicatie in teams in westerse landen lijkt aanvankelijk buitensporig voor programmeurs uit Rusland. Een zekere rechtlijnigheid die kenmerkend is voor Russische collega's kan door hun collega's uit andere landen als grofheid worden ervaren. Dit is erg belangrijk bij de communicatie in een interetnisch team; er is veel over dit onderwerp geschreven; de manager van zo'n team moet dit onthouden.
Functiedemonstraties, waarbij programmeurs functies tonen die tijdens een sprint zijn ontwikkeld, zijn een goede gewoonte om aan deze behoefte te voldoen. Naast het feit dat dit een uitstekende gelegenheid is om de communicatiekanalen tussen teams vrij te maken, productmanagers en testers kennis te laten maken met nieuwe features, is het ook een goede gelegenheid voor ontwikkelaars om de resultaten van hun werk te laten zien en hun auteurschap aan te geven. Nou, en verbeter natuurlijk je spreekvaardigheid in het openbaar, wat nooit schadelijk is.
Het zou een goed idee zijn om de belangrijke bijdrage van bijzonder vooraanstaande collega's te vieren met certificaten, herdenkingsborden (tenminste een vriendelijk woord) tijdens gezamenlijke teambijeenkomsten. Mensen hechten doorgaans veel waarde aan dergelijke certificaten en herdenkingsborden, nemen ze mee bij een verhuizing en zorgen er doorgaans op alle mogelijke manieren voor.
Om een belangrijkere bijdrage op lange termijn aan het werk van het team, de opgebouwde ervaring en expertise te markeren, wordt vaak een cijfersysteem gebruikt (opnieuw kan er een analogie worden getrokken met het systeem van militaire rangen in het leger, dat bovendien om ondergeschiktheid te garanderen, dient ook dit doel). Vaak werken jonge ontwikkelaars twee keer zo hard om nieuwe sterren op hun schouders te krijgen (dwz van junior ontwikkelaar naar fulltime ontwikkelaar, enz.).
Het is van cruciaal belang dat u de verwachtingen van uw mensen kent. Sommigen worden eerder gemotiveerd door een hoge rang, de mogelijkheid om bijvoorbeeld architect te worden genoemd, terwijl anderen juist onverschillig staan tegenover cijfers en titels en een salarisverhoging zullen beschouwen als een teken van erkenning door het bedrijf. . Communiceer met mensen om te begrijpen wat ze willen en wat hun verwachtingen zijn.
Een blijk van erkenning, een hoger niveau van vertrouwen van de kant van het team, kan worden gegeven door meer vrijheid van handelen of betrokkenheid bij nieuwe werkgebieden te geven. Nadat hij bijvoorbeeld bepaalde ervaring heeft opgedaan en bepaalde resultaten heeft bereikt, kan een programmeur, naast het implementeren van zijn functies in overeenstemming met de specificatie, werken aan de architectuur van nieuwe dingen. Of raak betrokken bij nieuwe gebieden die misschien niet direct verband houden met ontwikkeling: testautomatisering, het implementeren van de beste technische praktijken, helpen met releasebeheer, spreken op conferenties, enz.
V. De behoefte aan cognitie en zelfactualisatie.
Veel programmeurs zijn in verschillende fasen van hun leven gefocust op verschillende soorten programmeeractiviteiten. Sommige mensen houden ervan om aan machine learning te doen, nieuwe datamodellen te ontwikkelen, veel wetenschappelijke literatuur te lezen voor hun werk en vanaf het begin iets nieuws te creëren. Een andere is dichter bij het debuggen en ondersteunen van een bestaande applicatie, waarbij je diep in de bestaande code moet graven, logs moet bestuderen, traces en netwerkcaptcha's moet stapelen gedurende dagen en weken, en bijna geen nieuwe code moet schrijven.
Beide processen vergen grote intellectuele inspanningen, maar hun praktische resultaten zijn verschillend. Er wordt aangenomen dat programmeurs terughoudend zijn in het ondersteunen van bestaande oplossingen; ze zijn eerder gemotiveerd om nieuwe oplossingen te ontwikkelen. Hier zit een stukje wijsheid in. Aan de andere kant was het meest gemotiveerde en verenigde team waarmee ik ooit heb gewerkt toegewijd aan het ondersteunen van een bestaand product, het vinden en oplossen van bugs nadat het ondersteuningsteam contact met hen had opgenomen. De jongens leefden letterlijk voor dit werk en waren klaar om op zaterdag en zondag uit te gaan. Ooit hebben we gretig een ander urgent en complex probleem aangepakt, hetzij op de avond van 31 december, hetzij op de middag van 1 januari.
Verschillende factoren beïnvloedden deze hoge motivatie. Ten eerste was het een bedrijf met een grote naam in de branche, het team associeerde zich ermee (zie “De behoefte aan aansluiting”). Ten tweede vormden ze de laatste grens, er stond niemand achter hen, er was op dat moment geen productteam. Tussen hen en de klanten waren er twee ondersteuningsniveaus, maar als het probleem hen bereikte, was er geen plek om zich terug te trekken, niemand stond achter hen, het hele bedrijf stond achter hen (vier jonge programmeurs). Ten derde had dit grote bedrijf zeer grote klanten (overheden van landen, auto- en luchtvaartconcerns, enz.) en zeer grootschalige installaties in verschillende landen. Als gevolg hiervan werden altijd complexe en interessante problemen en eenvoudige problemen opgelost door de ondersteuning van eerdere niveaus. Ten vierde werd de motivatie van het team sterk beïnvloed door het professionele niveau van het ondersteuningsteam met wie ze omgingen (er waren zeer ervaren en technisch bekwame ingenieurs), en we hadden altijd vertrouwen in de kwaliteit van de gegevens die ze hadden voorbereid en de analyses die ze hadden uitgevoerd. , enz. Ten vijfde, en ik denk dat dit het belangrijkste punt is: het team was erg jong, alle jongens stonden aan het begin van hun carrière. Ze waren geïnteresseerd in het bestuderen van een groot en complex product en het oplossen van serieuze problemen die nieuw voor hen waren in een nieuwe omgeving. Ze probeerden professioneel te matchen met het niveau van de omringende teams, problemen en klanten. Het project bleek een uitstekende leerschool, iedereen maakte later een goede carrière in het bedrijf en werd technische leiders en senior managers, een van de jongens is nu technisch manager bij Amazon Web Services, de ander stapte uiteindelijk over naar Google, en allemaal van hen herinnert zich dit project nog steeds met warmte.
Als dit team zou bestaan uit programmeurs met 15-20 jaar ervaring, zou de motivatie anders zijn. Leeftijd en ervaring zijn uiteraard niet 100% bepalende factoren; het hangt allemaal af van de structuur van de motivatie. In dit specifieke geval leverde het verlangen naar kennis en groei van jonge programmeurs uitstekende resultaten op.
Over het algemeen moet u, zoals we al verschillende keren hebben vermeld, de verwachtingen van uw programmeurs kennen, begrijpen wie van hen hun werkterrein wil uitbreiden of veranderen, en rekening houden met deze verwachtingen.
Voorbij de piramide van Maslow: zichtbaarheid van resultaten, gamificatie en concurrentie, geen bullshit
Er zijn nog drie belangrijke punten met betrekking tot de motivatie van programmeurs die zeker moeten worden vermeld, maar het zou te kunstmatig zijn om ze in het behoeftenmodel van Maslow te betrekken.
De eerste is de zichtbaarheid en nabijheid van het resultaat.
Softwareontwikkeling is doorgaans een marathon. De resultaten van R&D-inspanningen worden na maanden, soms jaren, zichtbaar. Het is moeilijk om naar een doel te gaan dat ver voorbij de horizon ligt, de hoeveelheid werk is angstaanjagend, het doel is ver weg, niet helder en niet zichtbaar, “de nacht is donker en vol verschrikkingen.” Het is beter om de weg ernaartoe in delen te verdelen, een pad te maken naar de dichtstbijzijnde boom die zichtbaar en bereikbaar is, de contouren duidelijk zijn en het niet ver van ons verwijderd is - en naar dit nabije doel te gaan. We willen een inspanning van enkele dagen of weken leveren, het resultaat verkrijgen en evalueren en dan verder gaan. Daarom is het de moeite waard om het werk in kleine delen op te delen (sprints in agile dienen dit doel goed). We hebben een deel van het werk voltooid – het opgenomen, uitgeademd, besproken, de schuldigen gestraft, de onschuldigen beloond – we kunnen aan de volgende cyclus beginnen.
Deze motivatie is tot op zekere hoogte vergelijkbaar met wat spelers ervaren bij het voltooien van computerspellen: ze ontvangen periodiek medailles, punten en bonussen als ze elk niveau voltooien; dit kan ‘dopamine-motivatie’ worden genoemd.
Tegelijkertijd is de zichtbaarheid van het resultaat letterlijk belangrijk. Een gesloten object in de lijst moet groen worden. Als de code is geschreven, getest, vrijgegeven, maar er is geen verandering in de visuele status zichtbaar voor de programmeur, zal hij zich onvolledig voelen, er zal geen gevoel van voltooiing zijn. In een van de teams in ons versiebeheersysteem doorliep elke patch drie opeenvolgende fasen: de build werd samengesteld en de tests slaagden, de patch slaagde voor de codebeoordeling, de patch werd samengevoegd. Elke etappe werd visueel gemarkeerd met een groen vinkje of een rood kruis. Toen een van de ontwikkelaars klaagde dat de codebeoordeling te lang duurde, moesten de collega's versnellen, patches bleven enkele dagen hangen. Ik vroeg: wat verandert dit eigenlijk voor hem? Wanneer de code is geschreven, de build is samengesteld en de tests zijn geslaagd, hoeft hij immers geen aandacht te besteden aan de verzonden patch als er geen opmerkingen zijn. Collega's zullen het zelf beoordelen en goedkeuren (als er wederom geen opmerkingen zijn). Hij antwoordde: “Igor, ik wil zo snel mogelijk mijn drie groene vinkjes krijgen.”
Het tweede punt is gamificatie en concurrentie.
Bij het ontwikkelen van een van de producten had ons engineeringteam als doel een prominente positie in te nemen in de gemeenschap van een van de open source producten, om zo in de top-3 terecht te komen. Destijds was er geen objectieve manier om iemands zichtbaarheid in de gemeenschap te beoordelen; elk van de grote deelnemende bedrijven kon beweren (en beweerde periodiek) dat zij de grootste bijdrager waren, maar er was geen echte manier om de bijdragen van de deelnemers te vergelijken. onderling, om de dynamiek ervan op tijd te evalueren. Dienovereenkomstig was er geen manier om een doel voor het team te stellen dat bij sommige papegaaien kon worden gemeten, de mate van prestatie ervan kon worden beoordeeld, enz. Om dit probleem op te lossen heeft ons team een tool ontwikkeld waarmee de bijdrage van bedrijven en individuele bijdragers kan worden gemeten en gevisualiseerd . Vanuit motiverend oogpunt bleek het gewoon een bom te zijn. Het waren niet alleen ingenieurs en teams die voortdurend hun voortgang en die van hun collega's en concurrenten in de gaten hielden. Ook het topmanagement van ons bedrijf en alle grote concurrenten begonnen hun dag met stackalytics. Alles werd heel transparant en visueel, iedereen kon zijn voortgang nauwlettend volgen, vergelijken met collega’s, enz. Het is voor ingenieurs, managers en teams handig en gemakkelijk geworden om doelen te stellen.
Een belangrijk punt dat naar voren komt bij het implementeren van een systeem van kwantitatieve metrieken is dat zodra je ze hebt geïmplementeerd, het systeem er automatisch naar streeft om prioriteit te geven aan het behalen van deze kwantitatieve metrieken, ten koste van kwalitatieve. Het aantal voltooide codebeoordelingen wordt bijvoorbeeld als een van de statistieken gebruikt. Het is duidelijk dat codebeoordeling op verschillende manieren kan worden gedaan: u kunt enkele uren besteden aan een grondige beoordeling en controle van een complexe patch met controletests, deze op uw bank uitvoeren, controleren met documentatie, en plus één beoordeling in uw karma krijgen, of klik blindelings op een paar dozijn patches in een paar minuten, geef ze allemaal +1 en ontvang plus twintig aan karma. Er waren komische gevallen waarin ingenieurs zo snel op patches klikten dat ze +1 gaven aan automatische patches uit het CI-systeem. Zoals we later grapten: ‘Ga, ga, Jenkins.’ In het geval van commits waren er ook veel mensen die de code doornamen met codeopmaaktools, commentaren bewerkten, punten veranderden in komma's en zo hun karma opvoerden. Hiermee omgaan is vrij eenvoudig: we gebruiken ons gezond verstand en gebruiken naast kwantitatieve maatstaven ook essentiële, kwalitatieve maatstaven. De mate waarin de resultaten van het werk van het team worden gebruikt, het aantal externe bijdragers, het niveau van de testdekking, de stabiliteit van de modules en het gehele product, de resultaten van schaal- en prestatietests, het aantal ingenieurs dat de schouder van de kernrecensent heeft ontvangen beperkingen, het feit dat projecten werden geaccepteerd in de kernprojectengemeenschap, het voldoen aan de criteria van verschillende stadia van het engineeringproces - al deze en vele andere factoren moeten worden beoordeeld samen met eenvoudige kwantitatieve maatstaven.
En tot slot het derde punt: geen onzin.
Ontwikkelaars zijn zeer slimme mensen en uiterst logisch in hun vakgebied. Ze besteden 8 tot 10 uur per dag aan het bouwen van lange en complexe logische ketens, waardoor ze meteen kwetsbaarheden ontdekken. Als ze iets doen, willen ze, net als iedereen, begrijpen waarom ze het doen, wat er ten goede zal veranderen. Het is uiterst belangrijk dat de doelen die u voor uw team stelt eerlijk en realistisch zijn. Proberen een slecht idee aan een programmeerteam te verkopen is een slecht idee. Een idee is slecht als je er zelf niet in gelooft, of als je, in extreme gevallen, niet de interne staat hebt van het er niet mee eens zijn en je ertoe verbinden (ik ben het er niet mee eens, maar ik zal het wel doen). We hebben ooit een motivatiesysteem in een bedrijf geïmplementeerd, waarvan een van de elementen een elektronisch systeem voor het geven van feedback was. Ze investeerden veel geld, namen mensen mee naar Amerika voor training, en investeerden over het algemeen ten volle. Eens, in een gesprek na de training, zei een van de managers tegen zijn ondergeschikten: “Het idee is niet slecht, het lijkt erop dat het zal werken. Ik geef je zelf geen elektronische feedback, maar jij geeft het aan je mensen en eist het van hen.” Dat is alles, er kon niets meer worden geïmplementeerd. Het idee eindigde natuurlijk op niets.
Bron: www.habr.com