Epigrafi:
Burri, duke parë fëmijët e ndyrë, i thotë gruas: mirë, t'i lajmë këto apo të lindim të rinj?
Më poshtë është pjesa e dytë e një artikulli nga drejtuesi i ekipit tonë, si dhe Drejtori i Zhvillimit të Produkteve RAS, Igor Marnat, në lidhje me veçoritë e motivimit të programuesve. Pjesën e parë të artikullit mund ta gjeni këtu -
Në pjesën e parë të artikullit, unë preka dy nivelet më të ulëta të piramidës së Maslow: nevojat fiziologjike, nevojat për siguri, rehati dhe qëndrueshmëri dhe kalova në nivelin tjetër, të tretë, përkatësisht:
III - Nevoja për përkatësi dhe dashuri
E dija që mafia italiane quhej “Cosa Nostra”, por më bëri shumë përshtypje kur mora vesh se si përkthehet “Cosa Nostra”. “Cosa Nostra” e përkthyer nga italishtja do të thotë “Biznesi ynë”. Zgjedhja e emrit është shumë e suksesshme për motivim (le të lëmë mënjanë profesionin, në këtë rast na intereson vetëm motivimi). Një person zakonisht dëshiron të jetë pjesë e një ekipi, të bëjë biznesin tonë të madh e të përbashkët.
Rëndësi e madhe i kushtohet plotësimit të nevojës për përkatësi dhe dashuri në ushtri, marinë dhe çdo formacion të madh paraushtarak. Dhe, siç e shohim, në mafia. Kjo është e kuptueshme, sepse ju duhet të detyroni njerëz që kanë pak të përbashkëta, të cilët fillimisht nuk formojnë një ekip njerëzish me mendje të njëjtë, të cilët mblidhen me rekrutim (jo vullnetarisht), që kanë nivele të ndryshme arsimore, vlera të ndryshme personale. , për t'ia kushtuar fjalë për fjalë jetën e tyre, në rrezik vdekjeprurës, për një kauzë të përbashkët, besojini jetën tuaj një shokut të armëve.
Ky është një motivim shumë i fortë; për shumicën e njerëzve është jashtëzakonisht e rëndësishme të ndihen sikur i përkasin diçkaje më të madhe, të dinë se jeni pjesë e një familjeje, një vendi, një ekipi. Në ushtri, uniformat, rituale të ndryshme, parada, marshime, pankarta e kështu me radhë i shërbejnë këtyre qëllimeve. Përafërsisht të njëjtët faktorë janë të rëndësishëm për çdo ekip. Simbolet, markat e korporatës dhe ngjyrat e korporatës, veglat dhe suveniret janë të rëndësishme.
Është e rëndësishme që ngjarjet e rëndësishme të kenë mishërimin e tyre të dukshëm me të cilin mund të lidhen. Në ditët e sotme, është më tepër normë që një kompani të ketë mallrat e saj, xhaketa, bluza, etj. Por është gjithashtu e rëndësishme të theksohet ekipi brenda kompanisë. Shpesh lëshojmë bluza bazuar në rezultatet e një lëshimi, të cilat u jepen të gjithë atyre që janë përfshirë në lëshim. Disa ngjarje, festime të përbashkëta apo aktivitete me të gjithë ekipin janë një tjetër faktor i rëndësishëm motivimi.
Përveç atributeve të jashtme, disa faktorë të tjerë ndikojnë në ndjenjën e përkatësisë në një ekip.
Së pari, prania e një qëllimi të përbashkët që të gjithë e kuptojnë dhe ndajnë një vlerësim të rëndësisë së tij. Programuesit zakonisht duan të kuptojnë se ata po bëjnë një gjë të lezetshme, dhe ata po e bëjnë këtë gjë të lezetshme së bashku, si një ekip.
Së dyti, skuadra duhet të ketë një hapësirë komunikimi në të cilën është i pranishëm i gjithë ekipi dhe që i përket vetëm atij (për shembull, një bisedë në mesazher, sinkronizime periodike të ekipit). Përveç çështjeve të punës, komunikimit joformal, ndonjëherë diskutimi i ngjarjeve të jashtme, dritë offtop - e gjithë kjo krijon një ndjenjë të komunitetit dhe ekipit.
Së treti, do të veçoja futjen e praktikave të mira inxhinierike brenda ekipit, dëshirën për të rritur standardet në krahasim me ato të pranuara në kompani. Zbatimi i qasjeve më të mira të pranuara në industri, së pari në ekip, dhe më pas në kompani në tërësi, i jep ekipit mundësinë të ndiejë se është përpara të tjerëve në një farë mënyre, duke udhëhequr rrugën, kjo krijon një ndjenjë përkatësie. për një ekip të lezetshëm.
Ndjenja e përkatësisë ndikohet gjithashtu nga pjesëmarrja e ekipit në planifikim dhe menaxhim. Kur anëtarët e ekipit përfshihen në diskutimin e qëllimeve të projektit, planet e punës, standardet e ekipit dhe praktikat inxhinierike, dhe intervistimin e punonjësve të rinj, ata zhvillojnë një ndjenjë pjesëmarrjeje, pronësi të përbashkët dhe ndikim në punë. Njerëzit janë shumë më të gatshëm të zbatojnë vendimet e marra dhe të shprehura nga vetë ata sesa ato të propozuara nga të tjerët, edhe nëse ato janë praktikisht në harmoni.
Ditëlindjet, përvjetorët, ngjarjet e rëndësishme në jetën e kolegëve - një picë e përbashkët, një dhuratë e vogël nga ekipi japin një ndjenjë të ngrohtë përfshirjeje dhe mirënjohjeje. Në disa kompani, është zakon të jepen shenja të vogla përkujtimore për 5, 10, 15 vjet punë në kompani. Nga njëra anë, nuk mendoj se kjo më motivon aq shumë për arritje të reja. Por, padyshim, pothuajse kushdo do të jetë i kënaqur që nuk e ka harruar atë. Ky është një nga ato raste kur mungesa e një fakti demotivon më shumë sesa prania e tij. Dakord, mund të jetë shumë turp nëse LinkedIn ju kujtoi në mëngjes dhe ju uroi për 10 vjetorin tuaj në vendin tuaj të punës, por asnjë koleg i vetëm nga kompania nuk ju përgëzoi apo ju kujtoi.
Sigurisht, një pikë domethënëse është ndryshimi në përbërjen e ekipit. Është e qartë se edhe nëse ardhja ose largimi i dikujt nga ekipi njoftohet paraprakisht (për shembull, në një gazetë të një kompanie ose ekipi, ose në një takim ekipi), kjo nuk motivon veçanërisht askënd për arritje të reja. Por nëse një ditë të bukur shihni një person të ri pranë jush, ose nuk shihni një të vjetër, mund të jetë një surprizë, dhe nëse largoheni, krejtësisht e pakëndshme. Njerëzit nuk duhet të zhduken në heshtje. Sidomos në një ekip të shpërndarë. Sidomos nëse puna juaj varet nga një koleg nga një zyrë tjetër, i cili papritmas u ngrit dhe u zhduk. Momente të tilla padyshim që ia vlen të informoni paraprakisht ekipin veç e veç.
Një faktor i rëndësishëm, që në anglisht quhet pronë (përkthimi fjalë për fjalë i "posedimit" nuk pasqyron plotësisht kuptimin e tij). Kjo nuk është një ndjenjë pronësie, por më tepër një ndjenjë përgjegjësie për projektin tuaj, ajo ndjenjë kur ju e lidhni emocionalisht veten me produktin dhe produktin me veten tuaj. Kjo përafërsisht korrespondon me lutjen e marinës në filmin "Xhaketa e plotë metalike": "Kjo është pushka ime. Pushkë të tilla ka shumë, por kjo është e imja. Pushka ime është shoku im më i mirë. Ajo është jeta ime. Unë duhet të mësoj ta zotëroj atë në të njëjtën mënyrë që zotëroj jetën time. Pa mua, pushka ime është e kotë. Unë jam i kotë pa pushkën time. Unë duhet të gjuaj pushkën time drejt. Më duhet të qëlloj më saktë se armiku që po përpiqet të më vrasë. Duhet ta qëlloj para se ai të më qëllojë mua. Le të jetë kështu…”.
Kur një person punon në një produkt për një kohë të gjatë, ka mundësinë të mbajë përgjegjësinë e plotë për krijimin dhe zhvillimin e tij, të shohë se si një gjë funksionale lind nga "asgjëja", si e përdorin njerëzit, lind kjo ndjenjë e fuqishme. Ekipet e produkteve që punojnë së bashku për një kohë të gjatë në një projekt janë zakonisht më të motivuar dhe më kohezivë sesa ekipet që mblidhen për një periudhë të shkurtër kohore dhe punojnë në modalitetin e linjës së montimit, duke kaluar nga një projekt në tjetrin, pa përgjegjësi të plotë për të gjithë produktin. , nga fillimi në fund.
IV. Nevoja për njohje
Një fjalë e mirë i pëlqen edhe maces. Të gjithë motivohen nga njohja e rëndësisë së punës që kanë bërë dhe vlerësimi pozitiv i saj. Bisedoni me programuesit, jepuni atyre reagime periodike, festoni një punë të kryer mirë. Nëse keni një ekip të madh dhe të shpërndarë, takimet periodike (që quhen një me një) janë perfekte për këtë; nëse ekipi është shumë i vogël dhe punon së bashku në nivel lokal, kjo mundësi zakonisht ofrohet pa takime të veçanta në kalendar (edhe pse periodike për një është gjithçka Është ende e nevojshme, thjesht mund ta bëni më rrallë). Kjo temë është e mbuluar mirë në podkastet për menaxherët në manager-tools.com.
Megjithatë, ia vlen të mbash parasysh dallimet kulturore. Disa qasje të njohura për kolegët amerikanë nuk do të funksionojnë gjithmonë me ato ruse. Niveli i mirësjelljes së pranuar në komunikimin e përditshëm në ekipet në vendet perëndimore fillimisht duket i tepruar për programuesit nga Rusia. Njëfarë drejtësie karakteristike e kolegëve rusë mund të perceptohet si vrazhdësi nga kolegët e tyre nga vende të tjera. Kjo është shumë e rëndësishme në komunikimin në një ekip ndëretnik, është shkruar shumë për këtë temë, menaxheri i një ekipi të tillë duhet ta mbajë mend këtë.
Demonstrimet e veçorive, ku programuesit tregojnë veçori të zhvilluara gjatë një sprinti, janë një praktikë e mirë për realizimin e kësaj nevoje. Përveç faktit se kjo është një mundësi e shkëlqyer për të pastruar kanalet e komunikimit midis ekipeve, për të prezantuar menaxherët e produkteve dhe testuesit me veçori të reja, është gjithashtu një mundësi e mirë për zhvilluesit që të tregojnë rezultatet e punës së tyre dhe të tregojnë autorësinë e tyre. Epo, dhe lëmoni aftësitë tuaja të të folurit në publik, natyrisht, gjë që nuk është kurrë e dëmshme.
Do të ishte një ide e mirë për të festuar kontributin e rëndësishëm të kolegëve veçanërisht të dalluar me certifikata, shenja përkujtimore (të paktën një fjalë e mirë) në mbledhjet e përbashkëta të ekipit. Njerëzit zakonisht i vlerësojnë shumë certifikatat dhe shenjat përkujtimore, i marrin me vete kur lëvizin dhe përgjithësisht kujdesen për to në çdo mënyrë të mundshme.
Për të shënuar një kontribut më domethënës, afatgjatë në punën e ekipit, përvojën dhe ekspertizën e akumuluar, shpesh përdoret një sistem notash (përsëri, mund të bëhet një analogji me sistemin e gradave ushtarake në ushtri, i cili, përveç kësaj për sigurimin e nënshtrimit, i shërben edhe këtij qëllimi). Shpesh zhvilluesit e rinj punojnë dy herë më shumë për të marrë yje të rinj në rripat e shpatullave të tyre (dmth. kalojnë nga zhvilluesi i ri në zhvillues me kohë të plotë, etj.).
Njohja e pritshmërive të njerëzve tuaj është kritike. Disa kanë më shumë gjasa të motivohen nga një notë e lartë, mundësia për t'u quajtur, të themi, arkitekt, ndërsa të tjerët, përkundrazi, janë indiferentë ndaj notave dhe titujve dhe do ta konsiderojnë rritjen e pagës një shenjë njohjeje nga kompania. . Komunikoni me njerëzit për të kuptuar se çfarë duan dhe cilat janë pritshmëritë e tyre.
Një demonstrim i njohjes, një nivel më i lartë besimi nga ana e ekipit, mund të jepet duke dhënë më shumë liri veprimi ose përfshirje në fusha të reja pune. Për shembull, pasi të ketë fituar një përvojë të caktuar dhe të arrijë rezultate të caktuara, një programues, përveç zbatimit të veçorive të tij në përputhje me specifikimet, mund të punojë në arkitekturën e gjërave të reja. Ose përfshihuni në fusha të reja që mund të mos lidhen drejtpërdrejt me zhvillimin - automatizimi i testimit, zbatimi i praktikave më të mira inxhinierike, ndihma në menaxhimin e lëshimit, të folurit në konferenca, etj.
V. Nevoja për njohje dhe vetëaktualizim.
Shumë programues janë të fokusuar në lloje të ndryshme të aktiviteteve programore në faza të ndryshme të jetës së tyre. Disa njerëzve u pëlqen të bëjnë mësimin e makinerive, të zhvillojnë modele të reja të dhënash, të lexojnë shumë literaturë shkencore për punë dhe të krijojnë diçka të re nga e para. Një tjetër është më afër korrigjimit dhe mbështetjes së një aplikacioni ekzistues, në të cilin ju duhet të gërmoni thellë në kodin ekzistues, të studioni regjistrat, të grumbulloni gjurmët dhe kapçat e rrjetit për ditë dhe javë dhe të mos shkruani pothuajse asnjë kod të ri.
Të dy proceset kërkojnë përpjekje të mëdha intelektuale, por rezultati i tyre praktik është i ndryshëm. Besohet se programuesit hezitojnë të mbështesin zgjidhjet ekzistuese; ata janë më tepër të motivuar për të zhvilluar zgjidhje të reja. Ka një kokërr urtësie në këtë. Nga ana tjetër, ekipi më i motivuar dhe më i bashkuar me të cilin kam punuar ndonjëherë ishte i përkushtuar për të mbështetur një produkt ekzistues, për të gjetur dhe rregulluar gabimet pasi ekipi mbështetës i kontaktoi. Djemtë jetuan fjalë për fjalë për këtë punë dhe ishin gati të dilnin të shtunave dhe të dielave. Dikur u morëm me padurim një problem tjetër urgjent dhe kompleks, qoftë në mbrëmjen e 31 dhjetorit, qoftë në pasditen e 1 janarit.
Në këtë motivim të lartë ndikuan disa faktorë. Së pari, ishte një kompani me një emër të madh në industri, ekipi u lidh me të (shih "Nevoja për anëtarësim"). Së dyti, ata ishin kufiri i fundit, nuk kishte njeri pas tyre, nuk kishte asnjë ekip produkti në atë kohë. Midis tyre dhe klientëve kishte dy nivele mbështetjeje, por nëse problemi i arrinte, nuk kishte ku të tërhiqej, askush nuk ishte pas tyre, e gjithë korporata ishte mbi ta (katër programues të rinj). Së treti, kjo kompani e madhe kishte klientë shumë të mëdhenj (qeveri të vendeve, koncerte të automobilave dhe aviacionit, etj.) dhe instalime shumë të mëdha në disa vende. Si rezultat, probleme gjithmonë komplekse dhe interesante, probleme të thjeshta u zgjidhën me mbështetjen e niveleve të mëparshme. Së katërti, motivimi i ekipit u ndikua shumë nga niveli profesional i ekipit mbështetës me të cilin ata ndërvepruan (kishte inxhinierë shumë me përvojë dhe teknikisht të aftë), dhe ne ishim gjithmonë të sigurt në cilësinë e të dhënave që përgatitnin, analizën që ata kryenin. , etj. Së pesti, dhe unë mendoj se kjo është pika më e rëndësishme - ekipi ishte shumë i ri, të gjithë djemtë ishin në fillimet e karrierës së tyre. Ata ishin të interesuar të studionin një produkt të madh dhe kompleks, të zgjidhnin probleme serioze që ishin të reja për ta në një mjedis të ri, ata kërkuan të përputheshin profesionalisht me nivelin e ekipeve, problemeve dhe klientëve përreth. Projekti doli të ishte një shkollë e shkëlqyeshme, të gjithë më vonë bënë një karrierë të mirë në kompani dhe u bënë drejtues teknikë dhe menaxherë të lartë, njëri nga djemtë tani është një menaxher teknik në Amazon Web Services, tjetri përfundimisht u transferua në Google, dhe të gjitha prej tyre ende e kujtojnë me ngrohtësi këtë projekt.
Nëse ky ekip do të përbëhej nga programues me përvojë 15-20 vjeçare pas tyre, motivimi do të ishte ndryshe. Mosha dhe përvoja nuk janë, sigurisht, 100% faktorë përcaktues; gjithçka varet nga struktura e motivimit. Në këtë rast të veçantë, dëshira për njohuri dhe rritje e programuesve të rinj dha rezultate të shkëlqyera.
Në përgjithësi, siç e kemi përmendur tashmë disa herë, duhet të njihni pritshmëritë e programuesve tuaj, të kuptoni se cili prej tyre do të dëshironte të zgjeronte ose ndryshonte fushën e tyre të veprimtarisë dhe të merrni parasysh këto pritshmëri.
Përtej piramidës së Maslow: dukshmëria e rezultateve, gamifikimi dhe konkurrenca, pa marrëzi
Ka edhe tre pika më të rëndësishme në lidhje me motivimin e programuesve që duhet përmendur patjetër, por tërheqja e tyre në modelin e nevojave të Maslow do të ishte shumë artificiale.
E para është dukshmëria dhe afërsia e rezultatit.
Zhvillimi i softuerit është zakonisht një maratonë. Rezultatet e përpjekjeve për R&D bëhen të dukshme pas muajsh, ndonjëherë edhe vitesh. Është e vështirë të shkosh në një qëllim që është shumë përtej horizontit, sasia e punës është e tmerrshme, qëllimi është i largët, i paqartë dhe i padukshëm, "nata është e errët dhe plot tmerre". Është më mirë të thyeni rrugën drejt saj në pjesë, të bëni një shteg drejt pemës më të afërt që është e dukshme, e arritshme, skicat janë të qarta dhe nuk është larg nesh - dhe shkoni te ky qëllim i ngushtë. Ne duam të bëjmë një përpjekje prej disa ditësh ose javësh, të marrim dhe vlerësojmë rezultatin, pastaj të vazhdojmë. Prandaj, ia vlen të ndash punën në pjesë të vogla (sprintet në shkathtësi i shërbejnë mirë këtij qëllimi). Kemi përfunduar një pjesë të punës - e kemi regjistruar, e kemi nxjerrë, e kemi diskutuar, kemi dënuar fajtorët, kemi shpërblyer të pafajshmit - mund të fillojmë ciklin tjetër.
Ky motivim është deri diku i ngjashëm me atë që lojtarët përjetojnë kur plotësojnë lojërat kompjuterike: ata marrin periodikisht medalje, pikë, shpërblime ndërsa përfundojnë çdo nivel; kjo mund të quhet "motivim dopamine".
Në të njëjtën kohë, dukshmëria e rezultatit është fjalë për fjalë e rëndësishme. Një veçori e mbyllur në listë duhet të bëhet e gjelbër. Nëse kodi është shkruar, testuar, lëshuar, por nuk ka ndryshim në statusin vizual të dukshëm për programuesin, ai do të ndihet i paplotë, nuk do të ketë ndjenjën e përfundimit. Në një nga ekipet në sistemin tonë të kontrollit të versionit, çdo patch kaloi nëpër tre faza të njëpasnjëshme - ndërtimi u montua dhe testet kaluan, patch-i kaloi rishikimin e kodit, patch u shkri. Çdo fazë u shënua vizualisht me një tik-tak të gjelbër ose me kryq të kuq. Pasi një nga zhvilluesit u ankua se rishikimi i kodit zgjati shumë, kolegët duhej të shpejtonin, arnimet ishin varur për disa ditë. E pyeta, çfarë ndryshon në të vërtetë kjo për të? Në fund të fundit, kur shkruhet kodi, ndërtimi është mbledhur dhe testet kanë kaluar, ai nuk ka nevojë t'i kushtojë vëmendje patch-it të dërguar nëse nuk ka komente. Vetë kolegët do ta shqyrtojnë dhe miratojnë atë (nëse, përsëri, nuk ka komente). Ai u përgjigj: "Igor, dua të marr tre rriqrat e mia jeshile sa më shpejt të jetë e mundur."
Pika e dytë është gamifikimi dhe konkurrenca.
Gjatë zhvillimit të një prej produkteve, ekipi ynë inxhinierik kishte një qëllim për të marrë një pozicion të spikatur në komunitetin e një prej produkteve me burim të hapur, për të hyrë në top-3. Në atë kohë, nuk kishte asnjë mënyrë objektive për të vlerësuar dukshmërinë e dikujt në komunitet; secila prej kompanive të mëdha pjesëmarrëse mund të pretendonte (dhe të pretendonte periodikisht) se ishte kontribuesi numër një, por nuk kishte asnjë mënyrë reale për të krahasuar kontributet e pjesëmarrësve. mes tyre, për të vlerësuar në kohë dinamikën e saj. Prandaj, nuk kishte asnjë mënyrë për të vendosur një objektiv për ekipin që mund të matej në disa papagaj, të vlerësohej shkalla e arritjes së tij, etj. Për të zgjidhur këtë problem, ekipi ynë ka zhvilluar një mjet për matjen dhe vizualizimin e kontributit të kompanive dhe kontribuesve individualë . Nga pikëpamja motivuese, rezultoi të ishte thjesht një bombë. Nuk ishin vetëm inxhinierët dhe ekipet që monitoronin vazhdimisht progresin e tyre dhe përparimin e kolegëve dhe konkurrentëve të tyre. Menaxhmenti i lartë i kompanisë sonë dhe të gjithë konkurrentët kryesorë gjithashtu e nisën ditën e tyre me stackalytics. Gjithçka u bë shumë transparente dhe vizuale, të gjithë mund të monitoronin me kujdes përparimin e tyre, të krahasoheshin me kolegët, etj. Është bërë i përshtatshëm dhe i lehtë për inxhinierët, menaxherët dhe ekipet për të vendosur qëllime.
Një pikë e rëndësishme që lind gjatë zbatimit të çdo sistemi të metrikës sasiore është se sapo t'i keni zbatuar ato, sistemi përpiqet automatikisht të japë prioritet arritjen e këtyre metrikave sasiore, në dëm të atyre cilësore. Për shembull, numri i rishikimeve të kodit të përfunduar përdoret si një nga metrikat. Natyrisht, rishikimi i kodit mund të bëhet në mënyra të ndryshme, ju mund të kaloni disa orë në një rishikim dhe kontroll të plotë të një patch kompleks me teste kontrolli, duke e ekzekutuar atë në stolin tuaj, duke kontrolluar me dokumentacion dhe për të marrë plus një rishikim në karmën tuaj, ose kliko verbërisht disa dhjetëra arna në disa minuta, jepni secilit +1 dhe merrni plus njëzet në karma. Kishte raste komike kur inxhinierët klikonin në arna aq shpejt sa u jepnin +1 arnimeve automatike nga sistemi CI. Siç bëmë më vonë shaka, "shko, shko, jenkins". Në rastin e kryerjeve, kishte gjithashtu shumë njerëz që kaluan kodin me mjete të formatimit të kodit, redaktonin komentet, ndryshuan periudha në presje dhe kështu ngritën karmën e tyre. Përballja me këtë është mjaft e thjeshtë: ne përdorim sens të përbashkët dhe, përveç metrikës sasiore, përdorim edhe ato thelbësore, cilësore. Shkalla e përdorimit të rezultateve të punës së ekipit, numri i kontribuesve të jashtëm, niveli i mbulimit të provës, stabiliteti i moduleve dhe i gjithë produktit, rezultatet e testimit të shkallës dhe performancës, numri i inxhinierëve që morën krahun kryesor të rishikuesit shiritat, fakti që projektet u pranuan në komunitetin e projekteve thelbësore, përputhshmëria me kriteret e fazave të ndryshme të procesit inxhinierik - të gjithë këta dhe shumë faktorë të tjerë duhet të vlerësohen së bashku me metrika të thjeshta sasiore.
Dhe së fundi, pika e tretë - Nuk ka marrëzi.
Zhvilluesit janë njerëz shumë të zgjuar dhe jashtëzakonisht logjikë në fushën e tyre të punës. Ata shpenzojnë 8-10 orë në ditë duke ndërtuar zinxhirë logjikë të gjatë dhe të ndërlikuar, kështu që shohin dobësi në to menjëherë. Kur bëjnë diçka, ata, si gjithë të tjerët, duan të kuptojnë pse po e bëjnë atë, çfarë do të ndryshojë për mirë. Është jashtëzakonisht e rëndësishme që qëllimet që vendosni për ekipin tuaj të jenë të sinqerta dhe realiste. Përpjekja për t'i shitur një ide të keqe një ekipi programimi është një ide e keqe. Një ide është e keqe nëse nuk e beson vetë, ose, në raste ekstreme, nuk ke gjendjen e brendshme të mosmarrëveshjes dhe angazhimit (nuk jam dakord, por do ta bëj). Dikur kemi zbatuar një sistem motivimi në një kompani, një nga elementët e të cilit ishte një sistem elektronik për të dhënë feedback. Ata investuan shumë para, çuan njerëz në Amerikë për stërvitje, në përgjithësi investuan në maksimum. Një herë, në një bisedë pas stërvitjes, një nga drejtuesit u tha vartësve të tij: “Ideja nuk është e keqe, duket se do të funksionojë. Unë nuk do t'ju jap vetë reagime elektronike, por ju ua jepni njerëzve tuaj dhe kërkoni prej tyre." Kjo është ajo, asgjë nuk mund të zbatohej më tej. Ideja, natyrisht, përfundoi në asgjë.
Burimi: www.habr.com