Epígraf:
El marit, mirant els fills bruts, diu a la seva dona: bé, els rentarem o en donarem a llum de nous?
A sota del tall hi ha la segona part d'un article del nostre líder d'equip, així com del director de desenvolupament de productes de RAS, Igor Marnat, sobre les peculiaritats de motivar programadors. La primera part de l'article es pot trobar aquí -
A la primera part de l'article vaig tocar els dos nivells inferiors de la piràmide de Maslow: necessitats fisiològiques, necessitats de seguretat, comoditat i constància i vaig passar al següent, tercer nivell, és a dir:
III - Necessitat de pertinença i amor
Sabia que la màfia italiana es deia “Cosa Nostra”, però em va impressionar molt quan vaig saber com es tradueix “Cosa Nostra”. "Cosa Nostra" traduït de l'italià significa "el nostre negoci". L'elecció del nom és molt encertada per motivació (deixem de banda l'ocupació, en aquest cas només ens interessa la motivació). Normalment, una persona vol formar part d'un equip, fer alguna cosa gran i comuna, la nostra empresa.
Es dóna molta importància a la satisfacció de la necessitat de pertinença i amor a l'exèrcit, la marina i qualsevol formació paramilitar de grans dimensions. I, com veiem, a la màfia. Això és comprensible, perquè cal forçar persones que tenen poc en comú, que inicialment no formen un equip de persones afins, que s'ajunten per reclutament (no voluntàriament), que tenen diferents nivells d'estudis, diferents valors personals. , per dedicar literalment la seva vida, en risc mortal, a alguna causa comuna, confia la teva vida a un company d'armes.
Aquesta és una motivació molt forta; per a la majoria de la gent és extremadament important sentir que pertanyen a alguna cosa més gran, saber que formeu part d'una família, d'un país, d'un equip. A l'exèrcit, els uniformes, els rituals diversos, les desfilades, les marxes, les pancartes, etc. serveixen per a aquests propòsits. Aproximadament els mateixos factors són importants per a qualsevol equip. Els símbols, la marca corporativa i els colors corporatius, la parafernàlia i els records són importants.
És important que els esdeveniments significatius tinguin la seva pròpia encarnació visible amb la qual es puguin associar. Actualment, és més aviat la norma que una empresa tingui la seva pròpia mercaderia, jaquetes, samarretes, etc. Però també és important destacar l'equip dins de l'empresa. Sovint lliberem samarretes basades en els resultats d'un llançament, que es donen a tots els implicats en el llançament. Alguns esdeveniments, celebracions conjuntes o activitats amb tot l'equip són un altre factor important de motivació.
A més dels atributs externs, diversos altres factors influeixen en el sentiment de pertinença a un equip.
En primer lloc, la presència d'un objectiu comú que tothom entén i comparteix una valoració de la seva importància. Els programadors solen entendre que estan fent una cosa genial i que ho fan junts, com a equip.
En segon lloc, l'equip ha de disposar d'un espai de comunicació en el qual estigui present tot l'equip i que només li pertanyi (per exemple, un xat al messenger, sincronitzacions periòdiques de l'equip). A més dels problemes laborals, la comunicació informal, de vegades la discussió d'esdeveniments externs, la llum a la part superior, tot això crea una sensació de comunitat i equip.
En tercer lloc, destacaria la introducció de bones pràctiques d'enginyeria dins de l'equip, la voluntat d'elevar estàndards respecte als acceptats a l'empresa. Implementar els millors enfocaments acceptats en el sector, primer en l'equip i després en el conjunt de l'empresa, dóna a l'equip l'oportunitat de sentir que d'alguna manera està per davant dels altres, liderant el camí, això crea un sentiment de pertinença. a un equip genial.
El sentiment de pertinença també està influenciat per la participació de l'equip en la planificació i gestió. Quan els membres de l'equip participen en la discussió dels objectius del projecte, els plans de treball, els estàndards de l'equip i les pràctiques d'enginyeria, i entrevisten nous empleats, desenvolupen un sentit de participació, propietat compartida i influència en el treball. La gent està molt més disposada a dur a terme les decisions preses i expressades per elles mateixes que les proposades pels altres, encara que estiguin pràcticament en sintonia.
Aniversaris, aniversaris, esdeveniments significatius en la vida dels companys: una pizza conjunta, un petit regal de l'equip donen una càlida sensació d'implicació i gratitud. En algunes empreses, s'acostuma a donar petits signes commemoratius de 5, 10, 15 anys de treball a l'empresa. D'una banda, no crec que això em motivi tant per a nous èxits. Però, òbviament, gairebé tothom estarà content de no haver-se oblidat d'ell. Aquest és un d'aquells casos en què l'absència d'un fet desmotiva més que la seva presència. D'acord, pot ser una vergonya que LinkedIn t'ho recordi al matí i et feliciti pel teu 10è aniversari al teu lloc de treball, però ni un sol company de l'empresa t'ha felicitat ni se n'ha recordat.
Per descomptat, un punt important és el canvi en la composició de l'equip. És evident que encara que l'arribada o la sortida d'algú de l'equip s'anunciï amb antelació (per exemple, en un butlletí d'empresa o d'equip, o en una reunió d'equip), això no motiva especialment ningú cap a nous èxits. Però si un bon dia veus una persona nova al teu costat, o no veus una de vella, pot ser una sorpresa, i si te'n vas, francament desagradable. La gent no hauria de desaparèixer en silenci. Sobretot en un equip distribuït. Sobretot si la teva feina depèn d'un company d'una altra oficina que de sobte va aixecar i va desaparèixer. Aquests moments, sens dubte, val la pena informar l'equip per separat amb antelació.
Un factor important, que en anglès es diu propietat (la traducció literal de "possessió" no reflecteix completament el seu significat). Això no és un sentiment de propietat, sinó més aviat un sentiment de responsabilitat pel teu projecte, aquella sensació quan t'associes emocionalment amb el producte i el producte amb tu mateix. Això correspon aproximadament a la pregària del marine a la pel·lícula "Full Metal Jacket": "Aquest és el meu rifle. N'hi ha molts, però aquest és el meu. El meu rifle és el meu millor amic. Ella és la meva vida. He d'aprendre a posseir-ho de la mateixa manera que tinc la meva vida. Sense mi, el meu rifle és inútil. Soc inútil sense el meu rifle. He de disparar el meu rifle recte. He de disparar amb més precisió que l'enemic que intenta matar-me. He de disparar-li abans que ell em dispari a mi. Que sigui així..."
Quan una persona treballa en un producte durant molt de temps, té l'oportunitat d'assumir la total responsabilitat de la seva creació i desenvolupament, de veure com sorgeix una cosa que funciona del "res", com la gent l'utilitza, sorgeix aquest sentiment poderós. Els equips de producte que treballen junts durant molt de temps en un projecte solen estar més motivats i cohesionats que els equips que es formen durant un període curt de temps i treballen en línia de muntatge, passant d'un projecte a un altre, sense responsabilitat total de tot el producte. , de principi a fi.
IV. Necessitat de reconeixement
Una paraula amable també agrada al gat. Tothom està motivat pel reconeixement de la importància de la feina feta i la seva valoració positiva. Parleu amb els programadors, doneu-los comentaris periòdics, celebreu la feina ben feta. Si tens un equip gran i distribuït, les reunions periòdiques (el que s'anomenen un a un) són perfectes per a això; si l'equip és molt petit i treballa conjuntament a nivell local, aquesta oportunitat se sol oferir sense reunions especials al calendari (encara que una periòdica). a un és tot. Encara cal, només ho pots fer amb menys freqüència). Aquest tema està ben tractat als podcasts per a gestors a manager-tools.com.
No obstant això, val la pena tenir en compte les diferències culturals. Alguns enfocaments coneguts pels col·legues nord-americans no sempre funcionen amb els russos. El nivell de cortesia acceptat en la comunicació diària en equips dels països occidentals sembla inicialment excessiu als programadors de Rússia. Algunes característiques de franquesa dels col·legues russos poden ser percebudes com a grolleres pels seus col·legues d'altres països. Això és molt important en la comunicació en un equip interètnic; s'ha escrit molt sobre aquest tema; el responsable d'aquest equip ho ha de recordar.
Les demostracions de funcions, on els programadors mostren les funcions desenvolupades durant un sprint, són una bona pràctica per adonar-se d'aquesta necessitat. A més del fet que es tracta d'una excel·lent oportunitat per aclarir els canals de comunicació entre equips, donar a conèixer noves funcions als gestors de producte i als provadors, també és una bona oportunitat perquè els desenvolupadors mostrin els resultats del seu treball i indiquin la seva autoria. Bé, i poliu les vostres habilitats per parlar en públic, és clar, cosa que mai és perjudicial.
Seria una bona idea celebrar la contribució significativa de col·legues especialment distingits amb certificats, rètols commemoratius (almenys una paraula amable) a les reunions d'equip conjunt. Les persones solen valorar molt aquests certificats i rètols commemoratius, els porten amb ells quan es mouen i, en general, els cuiden de totes les maneres possibles.
Per marcar una contribució més significativa i a llarg termini al treball de l'equip, l'experiència acumulada i l'experiència, sovint s'utilitza un sistema de graus (de nou, es pot fer una analogia amb el sistema de rangs militars de l'exèrcit, que, a més per garantir la subordinació, també serveix per a aquest propòsit). Sovint, els desenvolupadors joves treballen el doble per aconseguir noves estrelles a les espatlles (és a dir, passar de desenvolupador júnior a desenvolupador a temps complet, etc.).
Conèixer les expectatives de la teva gent és fonamental. Alguns tenen més probabilitats d'estar motivats per una nota alta, l'oportunitat de ser anomenats, per exemple, arquitectes, mentre que d'altres, per contra, són indiferents a les qualificacions i títols i consideraran un augment del sou com a senyal de reconeixement per part de l'empresa. . Comunicar-se amb la gent per entendre què volen i quines són les seves expectatives.
Una demostració de reconeixement, un major nivell de confiança per part de l'equip, es pot donar donant més llibertat d'actuació o implicació en noves àrees de treball. Per exemple, després d'haver adquirit certa experiència i d'aconseguir determinats resultats, un programador, a més d'implementar les seves característiques d'acord amb l'especificació, pot treballar en l'arquitectura de coses noves. O involucrar-se en àrees noves que potser no estan directament relacionades amb el desenvolupament: automatització de proves, implementació de les millors pràctiques d'enginyeria, ajuda amb la gestió de llançaments, xerrada en conferències, etc.
V. La necessitat de cognició i autorealització.
Molts programadors se centren en diferents tipus d'activitats de programació en diferents etapes de la seva vida. A algunes persones els agrada fer aprenentatge automàtic, desenvolupar nous models de dades, llegir molta literatura científica per treballar i crear alguna cosa nova des de zero. Un altre està més a prop de la depuració i el suport d'una aplicació existent, en la qual cal aprofundir en el codi existent, estudiar registres, apilar traces i captchas de xarxa durant dies i setmanes i escriure gairebé cap codi nou.
Tots dos processos requereixen un gran esforç intel·lectual, però la seva producció pràctica és diferent. Es creu que els programadors són reticents a donar suport a les solucions existents; estan més aviat motivats per desenvolupar-ne de noves. Hi ha un gra de saviesa en això. D'altra banda, l'equip més motivat i unit amb el qual he treballat mai es va dedicar a donar suport a un producte existent, a trobar i corregir errors després que l'equip d'assistència es va posar en contacte amb ells. Els nois, literalment, vivien per aquesta feina i estaven preparats per sortir dissabtes i diumenges. Una vegada vam tractar amb ànsia un altre problema urgent i complex, ja sigui el 31 de desembre al vespre o l'1 de gener a la tarda.
Diversos factors van influir en aquesta alta motivació. En primer lloc, era una empresa amb un gran nom en el sector, l'equip s'hi va associar (vegeu "La necessitat d'afiliació"). En segon lloc, eren l'última frontera, no hi havia ningú al darrere, no hi havia cap equip de producte en aquell moment. Entre ells i els clients hi havia dos nivells de suport, però si el problema els arribava, no hi havia on retirar-se, ningú hi havia al darrere, tota la corporació hi anava (quatre joves programadors). En tercer lloc, aquesta gran empresa tenia clients molt grans (governs dels països, empreses d'automòbils i aviació, etc.) i instal·lacions molt grans a diversos països. Com a resultat, problemes sempre complexos i interessants, problemes senzills es resolen amb el suport de nivells anteriors. En quart lloc, la motivació de l'equip va estar molt influenciada pel nivell professional de l'equip de suport amb el qual van interactuar (hi havia enginyers amb molta experiència i capacitat tècnica), i sempre vam tenir confiança en la qualitat de les dades que preparaven, l'anàlisi que feien. , etc. En cinquè lloc, i crec que aquest és el punt més important: l'equip era molt jove, tots els nois estaven al començament de la seva carrera. Estaven interessats en estudiar un producte gran i complex, resoldre problemes greus que eren nous per a ells en un entorn nou, buscaven igualar professionalment el nivell dels equips, problemes i clients dels voltants. El projecte va resultar ser una escola excel·lent, després tothom va fer una bona carrera a l'empresa i es va convertir en líders tècnics i alts directius, un dels nois ara és director tècnic d'Amazon Web Services, l'altre finalment es va traslladar a Google i tots d'ells encara recorden aquest projecte amb calidesa.
Si aquest equip estigués format per programadors amb 15-20 anys d'experiència al darrere, la motivació seria diferent. L'edat i l'experiència no són, per descomptat, factors 100% determinants; tot depèn de l'estructura de la motivació. En aquest cas concret, el desig de coneixement i creixement dels joves programadors va donar excel·lents resultats.
En general, com ja hem comentat diverses vegades, has de conèixer les expectatives dels teus programadors, entendre quin d'ells voldria ampliar o canviar el seu camp d'activitat i tenir en compte aquestes expectatives.
Més enllà de la piràmide de Maslow: visibilitat dels resultats, gamificació i competència, cap merda
Hi ha tres punts més importants sobre la motivació dels programadors que definitivament cal esmentar, però incorporar-los al model de necessitats de Maslow seria massa artificial.
El primer és la visibilitat i la proximitat del resultat.
El desenvolupament de programari sol ser una marató. Els resultats dels esforços d'R+D es fan visibles després de mesos, de vegades anys. És difícil anar a un objectiu que està molt més enllà de l'horitzó, la quantitat de treball és aterridora, l'objectiu és llunyà, poc clar i no visible, "la nit és fosca i plena d'horrors". És millor trencar el camí en parts, fer un camí fins a l'arbre més proper que sigui visible, accessible, els contorns són clars i no està lluny de nosaltres, i anar a aquest objectiu proper. Volem fer un esforç de diversos dies o setmanes, obtenir i avaluar el resultat i després seguir endavant. Per tant, val la pena dividir el treball en petites parts (els sprints en àgil serveixen bé per a aquest propòsit). Hem acabat una part del treball -l'hem gravat, l'hem exhalat, l'hem comentat, hem castigat els culpables, hem premiat els innocents- podem començar el següent cicle.
Aquesta motivació és fins a cert punt semblant a la que experimenten els jugadors en completar jocs d'ordinador: reben periòdicament medalles, punts, bonificacions a mesura que completen cada nivell; això es pot anomenar "motivació de la dopamina".
Al mateix temps, la visibilitat del resultat és literalment important. Una funció tancada de la llista hauria de tornar-se verda. Si el codi s'escriu, es prova, s'allibera, però no hi ha cap canvi en l'estat visual visible per al programador, se sentirà incomplet, no hi haurà sensació de finalització. En un dels equips del nostre sistema de control de versions, cada pegat va passar per tres etapes successives: es va muntar la construcció i es van aprovar les proves, el pegat va passar la revisió del codi i el pegat es va fusionar. Cada etapa estava marcada visualment amb una paparra verda o una creu vermella. Una vegada que un dels desenvolupadors es va queixar que la revisió del codi va trigar massa, els companys havien d'accelerar-se, els pegats van estar penjats durant diversos dies. Vaig preguntar, què canvia això realment per a ell? Al cap i a la fi, quan s'escriu el codi, es munta la compilació i les proves han passat, no cal que presti atenció al pegat enviat si no hi ha comentaris. Els mateixos companys el revisaran i aprovaran (si, de nou, no hi ha comentaris). Ell va respondre: "Igor, vull aconseguir les meves tres paparres verdes el més aviat possible".
El segon punt és la gamificació i la competència.
En desenvolupar un dels productes, el nostre equip d'enginyeria tenia com a objectiu ocupar una posició destacada a la comunitat d'un dels productes de codi obert, per entrar al top-3. En aquell moment, no hi havia cap manera objectiva d'avaluar la visibilitat d'algú a la comunitat; cadascuna de les grans empreses participants podia afirmar (i afirmar periòdicament) que era el col·laborador número u, però no hi havia cap manera real de comparar les contribucions dels participants. entre ells, per avaluar la seva dinàmica en el temps. En conseqüència, no hi havia manera de fixar un objectiu per a l'equip que es pogués mesurar en alguns lloros, avaluar el grau d'assoliment, etc. Per solucionar aquest problema, el nostre equip ha desenvolupat una eina per mesurar i visualitzar la contribució de les empreses i els col·laboradors individuals . Des del punt de vista motivacional, va resultar ser només una bomba. No només els enginyers i els equips van controlar constantment el seu progrés i el progrés dels seus companys i competidors. La direcció de la nostra empresa i tots els principals competidors també van començar el seu dia amb stackalytics. Tot es va fer molt transparent i visual, tothom podia controlar acuradament el seu progrés, comparar amb els companys, etc. S'ha tornat còmode i fàcil per als enginyers, directius i equips establir objectius.
Un punt important que sorgeix a l'hora d'implementar qualsevol sistema de mètriques quantitatives és que tan bon punt les s'ha implantat, el sistema s'esforça automàticament per prioritzar l'assoliment d'aquestes mètriques quantitatives, en detriment de les qualitatives. Per exemple, el nombre de revisions de codi completades s'utilitza com una de les mètriques. Òbviament, la revisió del codi es pot fer de diferents maneres, podeu dedicar diverses hores a una revisió exhaustiva i a la comprovació d'un pegat complex amb proves de comprovació, executant-lo al vostre banc, comprovant amb documentació i obtenir més una revisió al vostre karma, o Feu clic cegament a un parell de dotzenes de pedaços en un parell de minuts, doneu +1 a cadascun i obteniu més vint de karma. Hi va haver casos còmics en què els enginyers feien clic als pedaços tan ràpidament que van donar +1 als pedaços automàtics del sistema CI. Com més tard vam fer broma, "va, va, jenkins". En el cas dels commits, també hi va haver moltes persones que van revisar el codi amb eines de format de codi, van editar comentaris, van canviar els punts per comes i així van augmentar el seu karma. Tractar-ho és ben senzill: fem servir el sentit comú i, a més de mètriques quantitatives, també fem servir les essencials, qualitatives. El grau d'ús dels resultats del treball de l'equip, el nombre de col·laboradors externs, el nivell de cobertura de la prova, l'estabilitat dels mòduls i del producte sencer, els resultats de les proves d'escala i rendiment, el nombre d'enginyers que van rebre l'espatlla del revisor bàsic. corretges, el fet que els projectes hagin estat acceptats a la comunitat de projectes bàsics, el compliment dels criteris de les diferents etapes del procés d'enginyeria, tots aquests i molts altres factors s'han d'avaluar juntament amb mètriques quantitatives senzilles.
I, finalment, el tercer punt: cap merda.
Els desenvolupadors són persones molt intel·ligents i extremadament lògiques en la seva línia de treball. Passen entre 8 i 10 hores al dia construint cadenes lògiques llargues i complexes, de manera que hi veuen vulnerabilitats sobre la marxa. Quan fan alguna cosa, ells, com tothom, volen entendre per què ho fan, què canviarà per a millor. És molt important que els objectius que us plantegeu per al vostre equip siguin honestos i realistes. Intentar vendre una mala idea a un equip de programació és una mala idea. Una idea és dolenta si no hi creus tu mateix, o, en casos extrems, no tens l'estat intern de no estar d'acord i comprometre't (no estic d'acord, però ho faré). Una vegada vam implantar un sistema de motivació en una empresa, un dels elements del qual era un sistema electrònic de retroalimentació. Van invertir molts diners, van portar gent a Amèrica per formar-se, en general, van invertir al màxim. Una vegada, en una conversa després de l'entrenament, un dels directius va dir als seus subordinats: “La idea no està malament, sembla que funcionarà. Jo mateix no us faré comentaris electrònics, però vosaltres els doneu a la vostra gent i els exigireu". Això és tot, no es podria implementar res més. La idea, és clar, no va acabar en res.
Font: www.habr.com