Përshëndetje miq. Shumë shpesh, veçanërisht në outsourcing, po shoh të njëjtin pamje. Mungesën e një procesi të qartë të punës në ekipet e projekteve të ndryshme.
E rëndësishmja është që programuesit nuk kuptojnë si duhet të komunikojnë me klientin dhe njëri-tjetrin. Si të ndërtohet një proces i vazhdueshëm i zhvillimit të një produkti cilësor. Si të planifikohet dita e punës dhe sprintet.
Dhe e gjithë kjo rezulton në afatet e fundit të prishura, orë shtesë, përplasje të përhershme për atë kush është fajtor, dhe pakënaqësi të klientëve — ku dhe si po shkon gjithçka. Shpesh kjo çon në ndërrimin e programuesve, madje edhe të ekipeve të tëra. Humbje të klientëve, përkeqësim të reputacionit dhe kështu me radhë.
Në një moment, unë isha pikërisht në një projekt të tillë, ku kishte të gjitha këto kënaqësi.
Askush nuk donte të merrte përgjegjësinë për projektin (një treg me shërbime të mëdha), rotacioni ishte i frikshëm, klienët ishin të pakënaqur. CEO më afroi dhe më tha se kisha përvojën e nevojshme, kështu që po të japin ty. Merr projektin për vete. Nëse dështon, do ta mbyllim projektin dhe do të largojmë të gjithë. Nëse del mirë, është super, atëherë fitoj tregun dhe e zhvilloj si të dëshirosh. Në përfundim, u bëra lider ekipi në projekt dhe gjithë barra ra mbi supet e mia.
E para gjë që bëra ishte të zhvilloja një proces pune nga e para, që përkohej me vizionin tim në atë moment dhe të shkruaja një përshkrim pune për ekipin. Zbatimi i tij nuk ishte i lehtë. Por, diku brenda një muaji, gjithçka u stabilizua, zhvilluesit dhe klienti u mësuan, dhe gjithçka filloi të funksiononte qetë dhe rehatshëm. Për të treguar ekipit se kjo nuk ishte thjesht 'një furtunë në një gotë', por një zgjidhje reale e situatës, mora mbi vete sa më shumë detyra që të mundesha, duke i hequr ekipit barrën e pakëndshme.
Kalu ka kaluar një deri në një vit, projekti po zhvillohet pa orë shtesë, pa «garë miqësish» dhe pa stres të ndryshëm. Disa nga ekipi i vjetër nuk deshën të punojnë kështu dhe ikën, dikush tjetër tërhoqi shumë nga vendosja e rregullave të qarta. Por rezultatet tregojnë se të gjithë ata që janë në ekip janë shumë të motivuar dhe e njohin projektin e madh për nga thellësia, si për frontend-in dhe backend-in. Duke përfshirë bazën e kodit dhe të gjithë logjikën e biznesit. Madje kemi arritur deri në atë pikë sa nuk jemi thjesht «kanotierë», por ne vetë imagjinojmë shumë nga proceset e biznesit dhe karakteristikat e reja që i pëlqejnë biznesit.
Falë një qasje të tillë nga ana jonë, klienti vendosi të porosisë një tjetër treg për kompaninë tonë, gjë që nuk mund të na gëzojë.
Ngase në projektin tim kjo punon, ndoshta dikujt tjetër mund t'i ndihmojë gjithashtu. Kështu që, procesi që na ndihmoi të shpëtojmë projektin:
Procesi i punës së ekipit në projektin «Projekti im i preferuar»
a) Procesi brenda ekipit (ndërmjet zhvilluesve)
- Të gjitha detyrat krijohen në sistemin Jira
- Çdo detyrë duhet të jetë maksimalisht e përshkruar dhe të kryejë vetëm një veprim
- Çdo karakteristikë, nëse është mjaft e komplikuar, ndahen në shumë detyra të vogla
- Ekipi punon mbi karakteristikat si një detyrë e vetme. Fillimisht bëjmë së bashku një karakteristikë, e dorëzojmë për testim dhe pastaj marrim të radhën tjetër.
- Çdo detyrë etiketohen, për backend-in ose frontend-in
- Ka tipe detyrash dhe gabimesh. Është e nevojshme t’i shënojmë ato saktësisht.
- Pas përfundimit të detyrës, ajo kalon në statusin e rishikimit të kodit (në këtë rast krijohet një kërkesë për lidhje me kolegun tuaj)
- Ai që e ka përfunduar detyrën menjëherë e ndjek kohën e tij për këtë detyrë
- Pas rishikimit të kodit, PR miratohet dhe pas kësaj, ai që e ka kryer këtë detyrë, e bashkon atë në degën master, dhe më pas ndrroi statusin e saj në gatshme për implementim në dev server.
- Të gjitha detyrat, që janë gati për implementim në serverin dev, implementohen nga lideri i ekipit (zona e tij e përgjegjësisë), ndonjëherë nga një anëtar i ekipit, nëse diçka është urgjente. Pas implementimit, të gjitha detyrat të gatshme për implementim në dev kalojnë në statusin - gati për testim në dev
- Të gjitha detyrat testohen nga klienti
- Kur klienti ka testuar detyrën në dev, ai e kalon në statusin gati për implementim në prodhim
- Për implementimin në prodhim ne kemi një degë të veçantë, ku bashkojmë masterin vetëm para implementimit
- Nëse gjatë testimit klienti gjen gabime, atëherë ai e kthen detyrën për korrigjim, duke i vendosur atij statusin "e kthyer për riparim". Kështu ne ndjejmë detyrat e reja nga ato që nuk e kaluan testimin.
- Si rezultat, të gjitha detyrat kalojnë rrugën nga krijimi në përfundim: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Kthehu në dev) → Ready deploy to prod → QA on prod → Done.
- Çdo zhvillues teston kodin e tij vetë, duke përfshirë dhe si përdorues i sitit. Nuk lejohet që dega të bashkohet me kryesoren, nëse nuk është vërtetuar që kodi funksionon.
- Çdo detyrë ka prioritete. Prioritetet vendosen ose nga klienti, ose nga tim lideri.
- Zhvilluesit përparësisht realizojnë detyrat me prioritet.
- Zhvilluesit mund të caktojnë detyra njëri-tjetrit, nëse janë gjetur gabime të ndryshme në sistem ose një detyrë përbëhet nga puna e disa specialistëve.
- Të gjitha detyrat që krijon klienti shkojnë te tim lideri, i cili i vlerëson ato, dhe ose i kërkon klientit të korrigjojë, ose i cakton një nga anëtarët e ekipit.
- Të gjitha detyrat që janë të gatshme për depozitimin në dev ose prod, gjithashtu shkojnë te tim lideri, i cili e përcakton vetë se kur dhe si të kryejë depozitimin. Pas çdo depozitimi, tim lideri (ose një anëtar i ekipit) duhet ta njoftojë klientin për këtë. Po ashtu, të ndryshojë statuset për detyrat në "të gatshme për testim" në dev/prod.
- Çdo ditë në të njëjtën orë (për ne është në 12.00) ne zhvillojmë një miting midis të gjithë anëtarëve të ekipit.
- Çdo kush në miting raporton, duke përfshirë tim liderin, se çfarë bëri dje, çfarë planifikon të bëjë sot, çfarë nuk shkon dhe arsyet pse. Kështu, e gjithë ekipi është në dijeni se kush merret me çfarë dhe në cilin stad ndodhet projekti. Kjo na jep mundësinë të parashikojmë dhe të rregullojmë, nëse është e nevojshme, estimatet dhe afatet e fundit.
- Në miting, tim lideri gjithashtu njofton për të gjitha ndryshimet në projekt dhe për nivelin e gabimeve aktuale, të cilat nuk janë gjetur nga klienti. Të gjitha gabimet shqyrtohen dhe caktohen për çdo anëtar të ekipit për t'i zgjidhur ato.
- Në miting, tim lideri cakton detyra për secilin, duke marrë parasysh ngarkesën aktuale të zhvilluesve, nivelin e përgatitjes së tyre profesionale, si dhe duke marrë parasysh afërsinë e detyrës ndaj asaj që zhvilluesi merret aktualisht.
- Në takim, lideri i ekipit zhvillon strategjinë e përgjithshme për arkitekturën dhe logjikën e biznesit. Pas kësaj, i gjithë ekipi e diskuton këtë dhe merr një vendim për të bërë ndryshime ose për të pranuar këtë strategji.
- Çdo zhvillues shkruan kod dhe zhvillon algoritme në mënyrë të pavarur brenda arkitekturës dhe logjikës së biznesit të njëjtë. Çdo njëri mund të shprehë vizionin e tij për implementim, por askush nuk detyrohet të veprojë në një mënyrë të caktuar. Çdo vendim argumentohet. Nëse ka një zgjidhje më të mirë, por tani nuk ka kohë për të, krijohet një detyrë në JIRA për refaktorizimin e një pjese të caktuar të kodit në të ardhmen.
- Kur një zhvillues merr një detyrë, ai e kalon atë në statusin e zhvillimit. Të gjitha komunikimet për sqarimin e detyrës me klientin përcillen te zhvilluesi. Pyetjet teknike mund t'i drejtohen liderit të ekipit ose kolegëve.
- Nëse zhvilluesi nuk e kupton thelbin e detyrës dhe klienti nuk ka arritur ta sqarojë atë qartë, ai kalon në detyrën tjetër. Ndërsa lideri i ekipit e merr aktualen dhe e diskuton vetë me klientin.
- Çdo ditë, zhvilluesi duhet të shkruajë në bisedën me klientin për detyrat mbi të cilat ka punuar dje dhe për ato që do të punojë sot.
- Procesi i punës ndodh sipas metodologjisë Scrum. Gjithçka është e ndarë në sprint-e. Çdo sprint zgjat dy javë.
- Sprint-et krijohen, mbushen dhe mbyllen nga lideri i ekipit.
- Nëse projekti ka afatet strikte, ne mundohemi të estimojmë përafërsisht të gjitha detyrat. Dhe krijojmë një sprint nga ato. Nëse klienti përpiqet të shtojë më shumë detyra në sprint, atëherë ne vendosim prioritete dhe disa detyra të tjera i kalojmë në sprint-in e ardhshëm.
b) Procesi i punës me klientin
- Çdo zhvillues mund dhe duhet të komunika me klientin.
- Nuk duhet t'i lejojmë klientit të imponojë rregullat e tij të lojës. Duhet t'i japim të kuptojë në një mënyrë të sjellshme dhe miqësore që ne jemi specialistë në fushën tonë, dhe vetëm ne duhet të organizojmë proceset e punës dhe të angazhojmë klientin në to.
- Është e nevojshme, idealisht, para se të filloni implementimin e ndonjë funksionaliteti, të krijoni një bllok-diagram të gjithë procesit logjik për veçorinë (workflow). Dhe t'ia dërgoni për miratim klientit. Kjo i përket vetëm funksionaliteteve të ndërlikuarat dhe jo të dukshme, si p.sh. sistemi i pagesave, sistemi i njoftimeve, etj. Kjo do të ndihmojë për të kuptuar më saktë se çfarë ka nevojë klienti, për të ruajtur dokumentacionin për veçorinë, si dhe për të siguruar veten ndaj asaj që klienti mund të thotë më vonë se ne bëmë ndryshe nga ajo që ai kërkoi.
- Të gjitha diagramet/bllok-diagramet/logjika etj. i ruajmë në Confluence/Jira, ku kërkojmë nga klienti në komentet për të konfirmuar saktësinë e implementimit të ardhshëm.
- Ne përpiqemi t'i shmangim klientit detajet teknike. Nëse na nevojitet një kuptim se si dëshiron klienti, çizojmë algoritme primitive në formën e një bllok-diagrami, të cilat klienti mund t'i kuptojë dhe të bëjë vetë të gjitha korrigjimet/përmirësimet.
- Nëse klienti gjen një bug në projekt, ne kërkojmë që ai ta përshkruajë atë shumë në detaje në Jira. Nga cilat rrethana ka ndodhur, kur, çfarë renditje veprimesh ka kryer klienti gjatë testimit. Kërkojmë që të bashkëngjitë screenshot-e.
- Ne përpiqemi që çdo ditë, maksimumi çdo dy ditë të bëjmë implementimin në serverin zhvillimor. Kështu, klienti fillon të testojë funksionalitetin dhe projekti nuk qëndron inaktiv. Kjo gjithashtu shërben si një shenjë për klientin se projekti është në zhvillim të plotë dhe askush nuk i thotë atij përralla.
- Shumë shpesh ndodh që klienti nuk e kupton plotësisht se çfarë i nevojitet atij në të vërtetë. Sepse krijon një biznes të ri për vete, me procese që ende nuk janë të stabilizuara. Prandaj, një situatë shumë e zakonshme është ajo kur ne hedhim në plehra pjesë të tëra të kodit dhe riorganizojmë logjikën e aplikacionit. Nga kjo del se nuk është e nevojshme të mbuloni absolutisht çdo gjë me teste. Ka kuptim të mbuloni me teste vetëm funksionalitetin kritikisht të rëndësishëm dhe atë me rezervime.
- Ka situata kur ekipi kupton se ne nuk po përputhemi me afatet e përcaktuara. Atëherë ne kryejmë një audit të shpejtë për detyrat, dhe menjëherë i komunikojmë kësaj klientit. Si një zgjidhje nga kjo situatë, ne propozojmë të lançojmë në afat funksionalitetin e rëndësishëm dhe kritik, ndërsa të tjerat të lihen për pas-lançim.
- Nëse klienti fillon të shpikë detyra të ndryshme nga koka, fillon të fantazojë dhe shpjegon në gisht, atëherë ne e kërkojmë që të na japë një skicë të faqes dhe një rrjedhë me logjikën që duhet të përshkruajë plotësisht sjelljen e gjithë skicës dhe elementeve të saj.
- Para se të marrim në punë çdo detyrë, ne duhet të sigurohemi që kjo veçori ishte përfshirë në kushtet e marrëveshjes tonë. Nëse është një veçori e re që del përtej marrëveshjeve tona fillestare, atëherë ne patjetër duhet ta vlerësojmë këtë veçori ((koha e përafërt e përfundimit + 30%) x 2) dhe të informojmë klientin se na nevojitet kaq shumë kohë për të, plus afati i fundit zgjatet me kohën e vlerësimit e shumëzuar me dy. Nëse e përfundojmë detyrën më shpejt — është shkëlqyer, të gjithë do të përfitojnë nga kjo. Nëse jo, atëherë kemi mbrojtur veten.
c) Çfarë nuk pranojmë në ekip:
- Mospranueshmërinë, çrregullimin, harrimin.
- „Të ushqehesh me pengesa“. Nëse nuk mund të përfundosh një detyrë, nuk di si, atëherë je i detyruar të informosh menjëherë liderin e ekipit, e jo të presësh deri në fund.
- Rrëfimet dhe krenaritë nga një person që nuk e ka provuar akoma aftësinë dhe profesionalizmin e tij me vepra. Nëse ka provuar, atëherë lejohet, brenda normave të etikes 🙂
- Mashtrimi në çdo shprehje të tij. Nëse detyra nuk është përfunduar, atëherë nuk duhet të ndryshohet statusi i saj në të përfunduar dhe të shkruhet në bisedën me klientin se është gati. Kompjuter i prishur, sistemi ka rënë, qeni e ka dëmtuar laptopin — këto janë të papranueshme. Nëse ndodh një forcuar real, lideri i ekipit duhet të informohet menjëherë.
- Kur specialisti është gjithmonë offline dhe është e vështirë të arrish te ai gjatë orarit të punës.
- Toksiciteti në ekip nuk pranohet! Nëse dikush nuk është dakord me diçka, atëherë të gjithë së bashku mblidhen në një mbledhje dhe e diskutojnë dhe e zgjidhin.
Dhe një sërë pyetjesh/thesish, që unë ndonjëherë i bëj klientit tim, për të bërë që të gjithë moskuptimet të zhduken:
- Cilat janë kriteret e tua të cilësisë?
- Si e përcaktoni nëse ka probleme në projekt apo jo?
- Duke shkelur të gjithë rekomandimet dhe këshillat tona për ndryshim/përmirësim të sistemit, të gjithë rreziqet i merrni vetëm ju.
- Çdo ndryshim të madh në projekt (p.sh., çdo lloj rrjedhësh ekstreme) do të çojë në mundësinë e shfaqjes së gabimeve (të cilat ne do t'i rregullojmë, natyrisht).
- Është e pamundur të kuptohet brenda pak minutash se çfarë problemi ka ndodhur në projekt, e aq më pak ta rregullosh menjëherë.
- Ne punojmë me një fluks të caktuar produktesh (Detyrat në Jira — Zhvillimi — Testimi — Depoja). Kështu që ne nuk mund të reagojmë ndaj gjithë kërkesave dhe ankesave në chat.
- Programuesit janë pikërisht programues, dhe jo profesionistë të testimit, dhe nuk mund të garantojnë cilësinë e duhur të testimit të projektit.
- Përgjegjësia për testimin e fundit dhe miratimin e detyrave në prodhim është plotësisht në duar tuaja.
- Nëse ne tashmë kemi marrë një detyrë për punë, nuk mund të kalojmë menjëherë në të tjera, derisa të përfundojmë aktualen (ndryshe kjo çon në më shumë bugs dhe rritjen e kohës së zhvillimit).
- Numri i njerëzve në ekip ka rënë (për shkak të pushimeve ose sëmundjeve), ndërsa puna është e gjithmbarshme dhe ne fizikisht nuk do të arrijmë të reagojmë ndaj gjithçkaje që dëshironi.
- Kërkesa nga ana juaj për të bërë depon në prodhim pa detyra të testuara në zhvillim — kjo është vetëm rreziku juaj, jo i zhvilluesve.
- Kur vendosni detyra të paqarta, pa fluks të saktë, pa skica dizajni, kjo kërkon nga ne shumë më shumë përpjekje dhe kohë realizimi, pasi ne në vendin tuaj duhet të bëjmë një volum shtesë pune.
- Cilatdo detyra për bugs, pa përshkrim të detajuar të ndodhisë së tyre dhe fotografi ekrani, nuk na japin mundësinë të kuptojmë se çfarë ka ndodhur dhe si ta simulojmë atë bug.
- Projekti kërkon punë të vazhdueshme dhe përmirësime për të rritur performancën dhe sigurinë. Prandaj ekipi shpenzon një pjesë të kohës së tij për këto përmirësime.
- Për shkak se kemi ndonjëherë orë të tejkalimeve (rregullime urgjente), ne duhet t'i kompensojmë ato në ditë të tjera.
Si rregull, klienti menjëherë kupton se nuk është aq e lehtë në zhvillimin e softuerit dhe dëshira e vetme këtu është qartësisht e pamjaftueshme.
Në përgjithësi, kjo është gjithçka. Pas skenave kam lënë një mori negociatash dhe rregullimin e parë të të gjitha proceseve, por si rezultat, gjithçka është rregulluar. Mund të them se ky proces është bërë për ne një "Plumb Argjendi". Njerëzit e rinj që erdhën në projekt mund të fillonin punën që në ditën e parë, sepse të gjitha proceset janë përshkruar, dhe dokumentacioni dhe arhitektura në formë diagrami jepnin menjëherë një ide për atë çfarë po bëjmë këtu.
P. S. Dua të saktësoj se nuk kemi menaxher projekti në anën tonë. Ai ndodhet te klienti. Aspak teknik. Projekti është evropian. Të gjitha komunikimet janë vetëm në anglisht.
Të gjithë fat të mirë në projekte. Mos u djegni dhe përpiquni të përmirësoni proceset tuaja.
Burimi në të mijat .
Burimi: habr.com
