Menaxhimi i një ekipi programuesish: si dhe si t'i motivoni ata siç duhet? Pjesa e pare

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ë diskutimi i drejtuesit të ekipit tonë, si dhe Drejtorit të Zhvillimit të Produkteve RAS, Igor Marnat, rreth veçorive të programuesve motivues.

Menaxhimi i një ekipi programuesish: si dhe si t'i motivoni ata siç duhet? Pjesa e pare
Sekreti i suksesit në krijimin e produkteve softuerike të lezetshme është i njohur mirë - merrni një ekip programuesish të lezetshëm, jepini ekipit një ide të lezetshme dhe mos ndërhyni në punën e ekipit. Zhvilluesit e lezetshëm janë të rrallë dhe në kërkesë. Madje, disa rekrutues thonë se kanë përshtypjen se është më e lehtë të prodhosh një programues të lezetshëm sesa të punësosh një nga tregu. Përveç vështirësive me punësimin si të tillë, përvoja e secilit zhvillues specifik, njohuritë e tij për produktin ekzistues dhe historinë e zhvillimit të tij, shpesh janë të pazëvendësueshme ose të vështira dhe kërkon kohë për t'u rimbushur. Prandaj, nëse jeni me fat dhe tashmë keni një ekip të mirë programuesish, është e rëndësishme të punoni për motivimin e tyre. Punësimi dhe trajnimi i zhvilluesve të rinj, krijimi i një ekipi prej tyre është pothuajse po aq i vështirë dhe kërkon kohë sa lindja dhe rritja e fëmijëve.

Le të shqyrtojmë faktorët kryesorë të motivimit për programuesit (ekipet e programuesve), duke përdorur piramidën e Maslow për qartësinë dhe strukturimin e prezantimit. Nëse nuk keni dëgjuar për piramidën e Maslow, kjo nuk është një teori e padiskutueshme, por shumë e njohur dhe ilustruese e psikologut amerikan Abraham Harold Maslow, i cili propozoi një teori të motivimit personal bazuar në hierarkinë e nevojave njerëzore (shih foton më poshtë).

Maslow i rregulloi nevojat e individit në një rend hierarkik, nga nevojat fiziologjike deri te nevoja për zhvillim të mundshëm dhe vetëaktualizim. Një supozim kryesor në teorinë e Maslow është se "një person nuk mund të përjetojë nevoja të nivelit më të lartë derisa të plotësohen nevojat e tij të nivelit më të ulët". Për shembull, një person nuk mund të nxitet nga nevoja për njohuri ose nevoja estetike nëse në të njëjtën kohë ky person nuk ka fjetur ose ngrënë për tre ditë.

Menaxhimi i një ekipi programuesish: si dhe si t'i motivoni ata siç duhet? Pjesa e pare

Para se të hyjmë në detaje, le të përqendrohemi në një fakt të dukshëm - një ekip përbëhet nga njerëz, të gjithë njerëzit janë të ndryshëm, secili ka strukturën e vet të motivimit. Përveç faktit që çdo person udhëhiqet nga interesa të ndryshme, çdo person është edhe në kushte të ndryshme jetese. Dikush është në fillim të një karriere dhe po mendon se si ta ndërtojë atë, dikush do të martohet dhe dikush dëshiron të zotërojë një fushë të re lëndore. Ajo që është e rëndësishme për një është krejtësisht e parëndësishme për një tjetër, dhe nesër gjithçka do të ndryshojë përsëri. Për të kuptuar saktë këtë kontekst, ekziston një ilaç i thjeshtë - duhet të mendoni për të dhe të punoni me të. Gjëja më e rëndësishme është komunikimi.
Sigurohuni që të flisni me ekipin tuaj për diçka tjetër përveç punës, ndërtoni marrëdhënie joformale.

Pra, tani le të kalojmë nëpër piramidën e Maslow dhe të konsiderojmë nivelet e saj si të zbatuara për menaxhimin e një ekipi programuesish.

I: Nevojat fiziologjike, biologjike:

Kur flasim për motivimin, shumë njerëz shpesh mendojnë për pagën para së gjithash. Në këtë rast, me pagë nënkuptoj një pjesë të përhershme të paketës së kompensimit, e cila nuk varet në asnjë mënyrë nga rezultatet. Kjo nuk vlen për bonuset, shpërblimet dhe promovimet e kompanive. Është paga që do t'i atribuoja nivelit të “nevojave fiziologjike” në rastin tonë. Bonuset, shpërblimet në bazë të performancës, opsioneve dhe aksioneve të kompanisë - të gjitha këto do t'i klasifikoja në nivele të tjera.

Sipas mendimit tim, sado e çuditshme të tingëllojë, paga mund të jetë më mirë demotivuese faktor dhe jo faktor motivues. E veçanta e punës me programuesit është se ata janë të gjithë njerëz, së pari, shumë të zgjuar (një tipar i profesionit), dhe së dyti, të arsimuar thellësisht dhe/ose gjerësisht. Në mënyrë tipike, programuesit, përveç profesionit të tyre, kanë një kuptim të thellë të një ose më shumë fushave lëndore për të cilat ata krijojnë produkte. Përveç kësaj, programuesit e mirë janë të interesuar dhe e njohin mirë historinë e zhvillimit të programimit, algoritmet, standardet, etj. E njëjta gjë vlen edhe për fushën e tyre lëndore. Për njerëzit në këtë nivel, paga zakonisht nuk është faktori kryesor motivues.

Në të njëjtën kohë, mungesa e një rroge të drejtë për programuesit, në kuptimin e tyre, demotivon dhe demotivon shumë. Të kesh një pagë të drejtë është normë. Paga është shumë më e lartë se norma (tregu) - gjithashtu, çuditërisht, një faktor mjaft demotivues. Një koleg më tregoi një herë për një ekip programuesish në një nga kompanitë e mëdha amerikane të animacionit, të cilët, për një sërë rrethanash, merrnin paga në një nivel dy deri në tre herë më të lartë se tregu. Siç tha ai, nuk kishte parë kurrë në jetën e tij programues më të mërzitur, dembelë dhe të demotivuar. Fakti i rritjes së pagës mund të motivojë në afat të shkurtër, por pas disa muajsh paga e re bëhet normë dhe pushon së motivuari. Në përgjithësi, do të thosha se për programuesit në fillim të karrierës së tyre, faktori paga është më i rëndësishëm, pasi rriten dhe zhvillohen profesionalisht, rëndësia e tij ulet dhe faktorë të tjerë fillojnë të mbizotërojnë.

Pika e dytë e rëndësishme është prania e një ekuilibri të drejtë në nivelin e pagave në ekip. Nëse një ekip mendon se kontributi i një anëtari është dukshëm më i ulët, por niveli i kompensimit është i njëjtë, kjo do të demotivojë të gjithë ekipin. Ndonjëherë menaxherët tundohen të ushqejnë zjarrin me para - të mbajnë një person të djegur ose të demotivuar duke rritur pagën e tij mbi normalen. Kjo zakonisht krijon probleme vetëm në planin afatgjatë - motivimi i vetë personit nuk do të rritet shumë, ose do të rritet për disa muaj, por motivimi i pjesës tjetër të ekipit do të bjerë. Në situata të tilla, ia vlen të kërkoni qasje të tjera, përveç nëse, natyrisht, ky është një specialist unik që duhet të mbahet me çdo kusht, qoftë edhe për një kohë të shkurtër.

II. Nevoja për siguri, rehati, konsistencë të kushteve të jetesës:

70 vjet më parë, prania e një sobë në një makinë mund të ishte një faktor motivues kur zgjidhni një makinë, atëherë ishte mbi normën dhe ishte një shenjë luksi. Tani edhe mungesa e ajrit të kondicionuar është e pakuptimtë, dhe prania e tij, natyrisht, nuk do të jetë një faktor motivues kur zgjedh një makinë. Pra, 10-15 vjet më parë, një zyrë e përshtatshme, pajisje të mira, kafe të shijshme, palestër, orë fleksibël etj. mund të jenë faktorë të mirë motivues, por tani kjo është më tepër norma për punën e një programuesi të mirë. Në të njëjtën kohë, mungesa e tyre do të jetë sërish demotivuese.

Një faktor i rëndësishëm demotivues është mungesa e aftësisë për t'u përqëndruar dhe një mjedis pune i zhurmshëm. Puna e një programuesi kërkon heshtje dhe përqendrim. Nëse hapësira e zyrës nuk ofron mundësinë për t'u siguruar zhvilluesve një hapësirë ​​pune të izoluar, është e nevojshme të paktën të sigurohet një bashkëpunim i rehatshëm midis kolegëve që nuk ndërhyjnë me njëri-tjetrin. Është më mirë të bashkoni shokët energjikë dhe me zë të lartë me njëri-tjetrin, duke u dhënë mundësinë për t'u përqendruar tek ata që kanë nevojë.

Kostoja e kohës së një programuesi tani është dukshëm më e lartë se kostoja e harduerit në të cilin ai punon. Dy ose tre monitorë, kompjuterë të fuqishëm, një vend pune i rehatshëm për çdo zhvillues - duhet të jenë norma në çdo kompani. Kjo temë është mbuluar mirë në një nga artikujt e Joel Spolsky "Testi Joel: 12 hapa për një kod më të mirë.”

Komponenti fizik i rehatisë është më themelorja dhe më e thjeshta; tani le të flasim për pjesën tjetër.

Në shumë kompani, norma për programuesit është një orar fleksibël i punës dhe pa kod veshjeje. Kjo është e mirë dhe e saktë nëse e lejojnë specifikat e punës së ekipit (për shembull, nuk ka takime me klientë, politikanë apo bankierë).

Gjëja e rëndësishme është që të kemi një dritare specifike kohore ku i gjithë ekipi punon së bashku në nivel lokal, në mënyrë që njerëzit të komunikojnë dhe të zgjidhin çështjet ballë për ballë. Një programues, në thelb, nuk e lë punën edhe pas punës. Në mënyrë tipike, çështjet e punës përsëriten në mendjen e tij, pavarësisht nga prania e tij në zyrë, dhe vendimet e mira shpesh vijnë nga jashtë zyrës. Duke pasur parasysh nevojën për të qenë të mirë (për të cilën do të diskutojmë më poshtë), kontrolli i imët është i dëmshëm. Jo vetëm që është demotivues, por edhe redukton produktivitetin. Siç tregon praktika, në mungesë të kontrollit, një ekip i motivuar ka më shumë gjasa të punojë më gjatë sesa duhet. Nëse ka kontroll, zhvilluesit mund të ulen në tastierë nga nëntë në gjashtë, por rezultati, mendoj, do të jetë më i keq. Siç thonë ata, një person mund ta çojë një kalë në ujë, por edhe njëqind nuk do ta detyrojnë atë të pijë nëse ai nuk dëshiron.

Përshkrimi i këtij niveli të nevojave përmend gjithashtu lirinë nga ankthi dhe frika, mungesa e kaosit dhe nevojën për strukturë dhe rregull. Këto janë gjithashtu pika jashtëzakonisht të rëndësishme që ndikojnë shumë në atmosferën në ekip.

Së pari, mungesa e kaosit, strukturës dhe rendit - ekipi duhet të kuptojë se kush është përgjegjës për çfarë, si shpërndahen rolet, çfarë duhet bërë, kujt, kur, cilat kërkesa bazohen në produktin, cilat janë pritshmëritë e menaxhmentit dhe klienti... Pjesa më e madhe e kësaj duhet të përshkruhet zyrtarisht, gjithçka duhet diskutuar periodikisht. Pa diskutim dhe përdorim periodik, përshkrimet nuk funksionojnë. Është praktikë e mirë që t'i diskutoni periodikisht dhe t'i përditësoni ato bazuar në rezultatet e analizës postmortem pas lirimit.

Së dyti, një atmosferë e qetë dhe miqësore. Ne të gjithë e kalojmë pjesën më të madhe të kohës në punë dhe duam ta bëjmë atë pa stres, konflikt apo frikë. Ekipi i zhvillimit zakonisht punon nën presionin e orareve dhe klientëve. Askush nuk ka nevojë për stres shtesë nga kolegët dhe eprorët. Atmosfera në ekip, në përgjithësi vetë fakti që një grup zhvilluesish mund të thirret dhe të jetë një "ekip" është përgjegjësi e drejtpërdrejtë dhe e rëndësishme e menaxherit, një nga detyrat më të rëndësishme afatmesme dhe afatgjatë. Prandaj, është e rëndësishme që një menaxher të punojë, veçanërisht, me konfliktet në ekip dhe të mos lejojë që zhvillimi i tyre të marrë rrjedhën e tij. Menaxhimi i konfliktit është një temë më vete që meriton studim të veçantë.

Ka dy mënyra kryesore për të ndikuar në gjendjen emocionale të ekipit dhe sjelljen e kolegëve (nëse dikush shton në komente, do të ishte mirë). E para është sjellja juaj. Shembulli personal është shumë i rëndësishëm për një menaxher dhe ekip. Siç thonë ata, siç është prifti, ashtu është ardhja. Silluni ashtu siç prisni të sillen kolegët tuaj. E dyta është inkurajimi i sjelljes korrekte dhe, si të thuash, deinkurajimi i sjelljes së gabuar. Komunikoni me njerëzit, jepini atyre reagime, ka shumë mënyra për ta bërë këtë. Në përgjithësi, feedback-u është një temë për një diskutim më vete; është një pjesë e madhe dhe e rëndësishme e punës me motivim.

Një tjetër shënim për atmosferën, që mund të duket e pazakontë, por në praktikë është e rëndësishme. Më shpesh sesa jo, ka më pak vajza në ekipin e zhvillimit sesa burra. Shpesh grupet janë tërësisht meshkuj. Në kushte të tilla, edhe nën ngarkesë, ndonjëherë fillon të përdoret gjuhë e turpshme në ekip. Praktika tregon se kjo ka një ndikim negativ në atmosferë; komunikimi gradualisht bëhet i pasjellshëm. Ju duhet të shmangni përdorimin e tij vetë dhe të dekurajoni përdorimin e tij në ekipin tuaj.

Ekipet e zhvillimit shpesh quhen R&D (kërkim dhe zhvillim), ku kërkimi përbën një pjesë të rëndësishme të punës. Kjo është pjesa që zakonisht është e vështirë për t'u programuar dhe planifikuar, përndryshe nuk do të ishte kërkim. Është e rëndësishme që skuadra të ketë të drejtën të gabojë, të marrë iniciativën, të provojë opsione të ndryshme që mund të përfundojnë ose jo me sukses. Gabimet janë një pjesë normale e punës, ato nuk mund të shmangen, por ju mund të studioni, analizoni, të mësoni prej tyre për të ardhmen dhe të vazhdoni përpara. Parimi 5 Pse, i cili e ka origjinën në Toyota, është një mënyrë e mirë për të gjetur shkakun rrënjësor të një problemi. Ndëshkimi i gabimeve është një mënyrë e shkëlqyer për të krijuar një atmosferë frike dhe pasigurie. Përjashtimi i vetëm është kur, bazuar në rezultatet e analizës, rezulton se gabimi është shkaktuar nga një qëndrim joprofesional ndaj punës, në këtë rast, mund të duhet të merren vendime të personelit.

Atmosfera në ekip ndikohet shumë nga pritshmëritë tuaja dhe gjendja emocionale para fillimit të bisedës. Përpara se të filloni një diskutim të vështirë, një lloj përmbledhjeje ose thjesht një bisedë emocionale, disponimi dhe qëndrimi juaj ndaj personit me të cilin do të flisni është i rëndësishëm. Unë gjithmonë besoj dhe veproj sipas parazgjedhjes bazuar në atë që personi sinqerisht u përpoq të bënte më të mirën. Nëse nga pozicioni juaj duket se nuk është kështu, duhet të zbuloni me qetësi dhe në detaje kontekstin dhe të kuptoni se çfarë bëri mirë, pse mendoi se ishte e drejtë dhe ku ndryshojnë pritshmëritë tona. Zakonisht rezulton se ato nuk ndryshojnë vërtet, thjesht se vizioni i tij për kontekstin është më i plotë ose më i freskët, dhe ka diçka që nuk e dinit. Ose, anasjelltas, ai nuk dinte diçka. Kjo është veçanërisht e rëndësishme në një ekip të shpërndarë, kur njerëzit komunikojnë më rrallë personalisht dhe përdorin email dhe mesazhe të çastit. Kjo është edhe më kritike në një ekip të përbërë nga programues nga vende të ndryshme dhe të shpërndarë nëpër zona të ndryshme kohore. Këtu dallimet kulturore fillojnë të luajnë një rol të madh.

Në një situatë të vështirë, ngasja në lëvizje është e lehtë, shumë e lehtë, por më pas kthimi është i vështirë dhe sedimenti mbetet për një kohë të gjatë. Më lejoni t'ju jap një shembull të thjeshtë nga përvoja e fundit. Një nga menaxherët e ekipit kishte nevojë urgjente për komente për ndonjë problem me një klient nga një menaxher nga një ekip i lidhur në një vend tjetër. Ai pingoi një koleg në mesazher, priti 15 minuta, përsëri ping, pastaj 15 minuta më vonë ai shkoi në një bisedë të madhe në të cilën ishin edhe menaxherët e tjerë, dhe e sulmoi pak kolegun, me një formulim si: “meqë nuk e bën mund të më përgjigjesh, ndoshta, dhe pyetja nuk është aq urgjente? Në fund, doli që lajmëtari ynë i korporatës ishte pak i mërzitshëm dhe kolegu nuk e pa fare pyetjen. Më duhej të kërkoja falje. Në përgjithësi, është më mirë të filloni me të mirën. Është gjithmonë e mundur të bësh një gabim të keq dhe të hasësh në telashe më vonë; nuk ka asnjë problem me këtë (edhe pse nuk duhet ta bësh këtë). Në përgjithësi, në më shumë se 20 vjet punë në industrinë tonë, kam takuar një koleg vërtet keqdashës vetëm një herë (!). Për fat të mirë, ne u ndamë shumë shpejt. Rezulton e saktë në shumicën dërrmuese të rasteve të supozohet se kolegët duan më të mirën, në kuptimin më të mirë të kontekstit.

Detyra juaj si menaxher është të siguroni sinkronizimin e konteksteve, një kuptim të përbashkët të pritjeve, kërkesave, afateve dhe standardeve të pranuara në ekip. Këto mund të duken si gjëra të vogla, por atmosfera në ekip është ndërtuar pikërisht nga këto gjëra të vogla. Nga këndvështrimi i ekipit të shpërndarë, një nga detyrat e rëndësishme është të sigurohet që anëtarët e ekipit të kenë komunikim periodik ballë për ballë. Kam dëgjuar më shumë se një herë nga programuesit që pasi, për shembull, inxhinierë nga ekipi mbështetës erdhën tek ata dhe punuan personalisht së bashku, ata me kënaqësi qëndruan në punë për të ndihmuar në një rast të vështirë personalisht pashait, i cili kishte ardhur së fundmi tek ata, edhe pse më parë Pasha ishte vetëm një ikonë në mesazher dhe askush nuk do të ndalej për hir të ikonës.

Nga rruga, fillova të flisja për ekipin mbështetës dhe kujtova një shembull kanonik për mua. Një herë, një nga klientët në Amerikë kishte një problem me produktin, një nga inxhinierët nga ekipi mbështetës që punonte për zbatimin e tij (i dërguar nga Rusia) qëndroi pas punës për të ndihmuar, por problemi nuk u zgjidh dhe nuk u zgjidh. Në përgjithësi, ai zgjati dhe u ul pothuajse deri në mëngjes. Në këtë kohë, menaxherët e klientit e përshkallëzuan problemin, identifikuan kritikën e tij për ta dhe u larguan nga puna në mbrëmje. Procesi i përshkallëzimit tashmë po fitonte vrull në një zonë tjetër kohore, menaxherët e mbështetjes në Rusi filluan të përpiqen të ndihmojnë, për shkak të disa vështirësive në komunikimin me zyrën e klientit (VPN, problemet e lidhjes, vështirësitë me thirrjet midis vendeve, ...) ata nuk e dinte që djali ishte tashmë në burg në zyrë dhe e zgjidh çështjen, dhe u përpoq ta gjente. Ata e gjetën atë vetëm në mëngjes (amerikane), kur çështja tashmë ishte zgjidhur praktikisht dhe produkti po funksiononte. Menjëherë filluan të thonë se çfarë dreqin, klienti ka një përshkallëzim të tillë, asgjë nuk funksionon, ku jeni, nuk ju gjejmë, etj. Eshtë e panevojshme të thuhet, si rezultat i një sjelljeje të tillë, djali u demotivua shumë. Organizimi i punës së një ekipi të shpërndarë është një temë më vete e madhe, por është e rëndësishme të mbani mend dy gjëra. Së pari, komunikimi dhe atmosfera janë shumë të rëndësishme, suksesi i punës varet nga kjo. Së dyti, kjo nuk funksionon më vete, duhet trajtuar veçmas dhe në thellësi.

Një tjetër pikë e rëndësishme lidhur me këtë nivel nevojash është sërish paga. Jo madhësia e pagës, si e tillë, por prania e një procedure të caktuar për ndryshimin e saj. Kompania duhet të ketë një qasje në përcaktimin e kërkesave për pozicione në nivele të ndryshme. Çdo zhvillues duhet të jetë në gjendje të diskutojë pritshmëritë për punën e tij me kompaninë, të kuptojë se si dhe kur përpjekjet e tyre mund të ndikojnë në pagën e tyre. Takimet periodike me menaxherin, rishikimet gjashtëmujore ose vjetore të performancës i shërbejnë këtij qëllimi. Ky, sërish është një nga ato momente, prania e të cilit nuk e motivon shprehimisht, por mungesa e tyre është shumë demotivuese.

Nga nevoja për rregull dhe prania e rregullave rrjedh edhe nevoja për të respektuar këto rregulla, për të ndjekur normat e pranuara në ekip, si ato formale ashtu edhe ato informale. Në përgjithësi, unë do ta quaja nevojën për të "të qenë i mirë". Prania e kësaj nevoje konfirmon se mikromenaxhimi nuk është i nevojshëm, por më tepër i dëmshëm. Mjafton t'i siguroni një personi gjithçka të nevojshme për punë, t'i jepni njohuri për kontekstin, përparësitë dhe t'i siguroni lirinë e veprimit dhe vendimmarrjes në nivelin e tij. Në kushte të tilla, ai do të ndjejë besim, mundësinë për të marrë vendimet e tij, për të marrë përgjegjësinë për to dhe do të jetë në gjendje të zbulojë potencialin e tij.

Një pikë tjetër e rëndësishme që duhet t'i atribuohet nevojës për rregull dhe mungesës së kaosit është aftësia për t'u përqëndruar në një detyrë, mungesa e ndërrimeve të shpeshta të kontekstit. Të jesh programues kërkon kohë dhe fokus. Programuesit me të vërtetë nuk u pëlqen të heqin dorë urgjentisht nga një detyrë dhe të kalojnë në një tjetër. Një pjesë e domosdoshme e punës së një programuesi zakonisht nuk është vetëm zhvillimi aktual i kodit, por edhe rregullimi i gabimeve dhe ndihma me përpunimin e kërkesave nga klientët. Vlen të planifikoni gjëra të tilla paraprakisht, në mënyrë që të lejojë programuesin të përfundojë me qetësi dhe plotësisht punën në një detyrë përpara se të kalojë në një tjetër. Opsioni më i mirë është t'i jepni vetes mundësinë për të planifikuar vetë punën tuaj, duke identifikuar prioritetet dhe detyrat e ardhshme paraprakisht, duke ndarë periudha të gjata dhe të gjata kohore për të punuar në një lloj detyre. Kjo temë është përshkruar mirë në librin "Google - Inxhinieri e besueshmërisë së sitit”, i cili përshkruan mirë qasjet për planifikimin e punës së ekipeve që sigurojnë funksionimin dhe zhvillimin e sistemeve të mëdha, shumë të ngarkuara, tolerante ndaj gabimeve, si dhe inxhinierëve, profesioni i të cilëve kombinon zhvillimin e softuerit dhe mbështetjen e tij.

Vazhdon…

Burimi: www.habr.com

Shto një koment