🥇Organizimi i procesit të punës në ekip për projektin IT

Përshëndetje miq. Veçanërisht në fushën e jashtme, shpesh shoh të njëjtën pamje. Mungesa e një procesi të qartë pune në ekipet e projekteve të ndryshme.

E rëndësishmja është se programuesit nuk kuptojnë se si duhet të komunikojnë me porositësin dhe njëri-tjetrin. Si të ndërtojnë një proces të pandërprerë zhvillimi të një produkti cilësor. Si të planifikojnë ditën e tyre të punës dhe sprintet.

Dhe të gjitha këto përfundimisht çojnë në shkelje të afateve, orë shtesë, përplasje të vazhdueshme rreth fajit, dhe pakënaqësi të porositësve — drejt dhe si po ecur gjitha. Shumë shpesh, kjo sjell ndërrimin e programuesve, madje të tërë ekipeve. Humbje të porositësve, përkeqësim të reputacionit dhe kështu me radhë.

Në një moment, unë pata rastin të punoja në një projekt të tillë, ku ishin të gjitha këto bukuri.

Asnjë nuk donte të merrte përsipër përgjegjësinë për projektin (një treg different, të madh të shërbimeve), rotacioni ishte i frikshëm, porositësi thjesht po shqyente dhe godiste. CEO më qas në një moment dhe më tha se kisha përvojën e nevojshme, kështu që këtu janë kartat, merr projektin për vete. Nëse dështon, do ta mbyllim projektin dhe do të largojmë të gjithë. Nëse ia del, do të jetë super, atëherë udhëheq dhe zhvilloje siç e sheh të nevojshme. Mënyra si përfundoi, kam filluar si lider ekipi në projekt dhe të gjithë pesha ra mbi shpatullat e mia.

E para gjë që bëra ishte të zhvilloja procesin e punës nga zero, i cili në atë moment përputhej me vizionin tim, dhe të shkruaja një udhëzim detyrash për ekipin. Ta implementosh atë nuk ishte e lehtë. Por diku gjatë një muaji çdo gjë u stabilizua, zhvilluesit dhe klienti u mësuan me të, dhe gjithçka filloi të shkonte qetë dhe komod. Për të treguar ekipit se kjo nuk ishte thjesht "një stuhi në një gotë", por një zgjidhje reale e situatës, mora përsipër një volum maksimal detyrash, duke hequr rutinën e pakëndshme nga ekipi.

Këtu ka kaluar një rreth një e gjysmë vit dhe projekti po zhvillohet pa orë shtesë, pa "garat e miut" dhe pa stres të ndryshëm. Disa nga anëtarët e vjetër të ekipit nuk dëshironin të punonin kështu dhe u larguan, ndërsa disa të tjerë e gjetën shumë të këndshme që ekzistonin rregulla të qarta. Por në përfundim, të gjithë ata që janë në ekip janë shumë të motivuar dhe e njohin projektin e madh plotësisht, përfshirë si frontendin ashtu edhe backendin. Duke filluar nga baza e kodit deri te e gjithë logjika e biznesit. Ka arritur deri në pikën që ne jo vetëm që jemi "peshkatarë", por edhe ne krijojmë shumë procese biznesi dhe karakteristika të reja që rezultuan të pëlqejnë biznesit.

Falë këtij подходi nga ana jonë, klienti vendosi të porosisë nga kompania jonë një tjetër treg online, që nuk mund të mos na gëzojë.

Për shkak se në projektin tim kjo funksionon, ndoshta ndonjëherë kjo mund t'i ndihmojë edhe dikujt tjetër. Pra, ja procesi që na ndihmoi të shpëtojmë projektin:

Procesi i punës së ekipit në projektin "Projekti im i preferuar"

a) Procesi brenda ekipit (midis zhvilluesve)

Të gjitha detyrat krijohen në sistemin Jira
Çdo detyrë duhet të jetë sa më e detajuar dhe të realizojë një veprim të vetëm
Çdo karakteristikë, nëse është mjaft e ndërlikuar, ndahet në shumë detyra më të vogla
Ekipi punon mbi funksionalitetet si një detyrë e vetme. Fillimisht bëjmë së bashku një funksionalitet, e dorëzojmë për testim, pastaj morrim funksionalitetin tjetër.
Çdo detyrë markohet, për backend apo frontend ajo
Ka lloje detyrash dhe gabimesh. Duhet t'i tregojmë ato saktësisht.
Pas përfundimit të detyrës, ajo kalon në statusin e riview-it të kodit (në të njëjtën kohë krijohet një pull request për kolegun e tij)
Ai që kreu detyrën menaxhon menjëherë kohën e tij për këtë detyrë
Pas kontrollit të kodit, PR miratohet dhe pas kësaj, ai që ka bërë këtë detyrë, e mërgon atë në degën master, pas së cilës ndryshon statusin në gati për deploy në dev server.
Të gjitha detyrat që janë gati për deploy në serverin dev, deploy-ohen nga lideri i ekipit (zona e tij e përgjegjësisë), ndonjëherë nga ndonjë anëtar i ekipit, nëse ka diçka urgjente. Pas deploy-it, të gjitha detyrat me statusin gati për deploy në dev kalojnë në statusin - gati për testim në dev
Të gjitha detyrat i teston klienti
Kur klienti e teste detyrën në dev, e kalon atë në statusin gati për deploy në prodhim
Për deploy në prodhim kemi një degë të veçantë, ku mërgojmë master-in vetëm para deploy-it
Nëse gjatë testimit klienti gjen defekte, ai e kthen detyrën për përmirësim, duke i vendosur asaj statusin 'kthyer për përmirësim'. Në këtë mënyrë, ne ndajmë detyrat e reja nga ato që nuk kanë kaluar testimin.
Si rezultat, të gjitha detyrat kalojnë rrugën nga krijimi deri në përfundim: To Do → Në Zhvillim → Rishikimi i Kodit → Gati për t'u vendosur në dev → QA në dev → (Kthehu në dev) → Gati për t'u vendosur në prodhimi → QA në prodhimi → E Kryer.
Çdo zhvillues teste kodin e tij/pas saj, duke përfshirë si përdorues i faqes. Nuk lejohet të bashkohen degët me kryesoren, nëse nuk është me siguri se kodi funksionon.
Çdo detyrë ka prioritete. Prioritetet vendosen ose nga klienti, ose nga lideri i skuadrës.
Zhvilluesit kryesisht realizojnë detyrat me prioritet të lartë.
Zhvilluesit mund të caktojnë detyrat njëri-tjetrit, nëse janë gjetur defekte të ndryshme në sistem ose një detyrë përbëhet nga puna e specialistëve të shumtë.
Të gjitha detyrat që krijon klienti i kalojnë liderit të skuadrës, i cili i vlerëson ato dhe ose kërkon nga klienti të bëjë përmirësime, ose i cakton njërës nga anëtarët e ekipit.
Të gjitha detyrat që janë gati për të u depozituar në dev ose prodhim, gjithashtu i dërgohen ekipit të liderëve, të cilët vendosin vetë kur dhe si të realizojnë depozitimin. Pas çdo depozite, lideri i ekipit (ose ndonjë anëtar i ekipit) duhet të njoftojë klientin për këtë. Po ashtu, duhet të ndryshojë statuset për detyrat në "të gatshme për testim" në dev/prod.
Çdo ditë në të njëjtën orë (ne e bëjmë këtë në 12:00) organizojmë një takim mes të gjithë anëtarëve të ekipit.
Çdo anëtar në takim raporton, përfshirë liderin e ekipit, se çfarë ka bërë dje, çfarë planifikon të bëjë sot. Cila është e pamundur dhe pse. Kështu, e gjithë skuadra është në dijeni se kush po merret me çfarë dhe në çfarë faze ndodhet projekti. Kjo na jep mundësinë të parashikojmë dhe të rregullojmë, nëse është e nevojshme, vlerësimet dhe afatet tona.
Gjatë takimit, lideri i ekipit gjithashtu njofton për të gjitha ndryshimet në projekt dhe për nivelin e të metave aktuale që janë gjetur nga klienti. Të gjitha defektet shqyrtohen dhe u caktohen secilit anëtar të ekipit për t'u zgjidhur.
Në takim, lideri i ekipit cakton detyra për secilin, duke marrë parasysh ngarkesën aktuale të zhvilluesve, niveli i pregatitjes së tyre profesionale, si dhe afërsinë e secilës detyre me atë që zhvilluesi po bën në atë moment.
Në takim, lideri i ekipit zhvillon strategjinë e përgjithshme për arkitekturën dhe logjikën e biznesit. Pas kësaj, e gjithë ekipi e diskuton dhe merr vendim për të bërë ndryshime ose për të pranuar këtë strategji.
Çdo zhvillues shkruan kodin dhe ndalon algoritmet vetë brenda një arkitekture dhe logjike biznesi të përbashkët. Çdo njëri mund të shprehë vizionin e tij për realizimin, por askush nuk detyrohet të bëjë vetëm kështu. Çdo vendim argumentohet. Nëse ka një zgjidhje më të mirë, por nuk ka kohë tani, krijohet një detyrë në Jira për një refaktorim të ardhshëm të një pjese të caktuar të kodit.
Kur një zhvillues merr një detyrë për të punuar, ai e kalon atë në statusin e zhvillimit. Të gjithë komunikimi për sqarimin e detyrës me porositësin bie në kurriz të zhvilluesit. 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ë ndjeshëm, ai kalon në detyrën tjetër. Dhe aktualen e merr timu lideri dhe vetë e diskuton atë me klientin.
Çdo ditë zhvilluesi duhet të shkruajë në bisedën me klientin se mbi cilat detyra ka punuar dje dhe mbi cilat detyra do të punojë sot.
Procesi i punës zhvillohet sipas metodologjisë Scrum. Çdo gjë është e ndarë në sprint-e. Çdo sprint zgjat dy javë.
Sprintet krijohen, popullohen dhe mbyllen nga timu lideri.
Nëse projekti ka afate strikte, ne përpiqemi t'ia vlerësojmë përafersisht të gjitha detyrat. Dhe i mbledhim ato në një sprint. Nëse klienti përpiqet të shtojë detyra të tjera në sprint, atëherë ne vendosim prioritetet dhe disa detyra të tjera i kalojmë në sprintin e ardhshëm.

b) Procesi i punës me klientin

Çdo zhvillues mund dhe duhet të komunikojë me klientin.
Nuk duhet t'i lejojmë klientit të imponojë rregullat e tij të lojës. Duhet në një mënyrë të sjellshme dhe miqësore të bëjmë të qartë për klientin se ne jemi specialistë në fushën tonë, dhe vetëm ne duhet të organizojmë proceset e punës dhe të përfshijmë klientin në to.
Idealisht, përpara se të fillojmë realizimin e ndonjë funksionaliteti, duhet të krijojmë një diagram të procesit logjik për veçorinë (workfllow) dhe ta dërgojmë për miratim te klienti. Kjo vlen vetëm për funksionalitetet e nd complicated dhe jo të dukshme, siç janë sistemi i pagesave, sistemi i njoftimeve etj. Kjo do të ndihmojë për të kuptuar më saktësisht se çfarë i nevojitet klientit, për të ruajtur dokumentacionin e veçorisë, si dhe për t'u siguruar që klienti nuk do të thotë në të ardhmen se ne bëmë diçka që ai nuk kërkoi.
Të gjitha diagramet/diagramet e bllokut/logjika etj. i ruajmë në Confluence/Jira, ku kërkojmë që klienti të konfirmojë në komentet e tij saktësinë e realizimit të ardhshëm.
Ne përpiqemi të mos ngarkojmë klientin me detaje teknike. Nëse na nevojitet të kuptojmë se si e dëshiron klienti, vizatojmë algoritme primitive në formën e diagramëve, të cilat klienti mund t'i kuptojë dhe vetë të bëjë ndryshime/përmirësime.
Nëse klienti gjen një gabim në projekt, ne kërkojmë që ai ta përshkruajë shumë hollësisht atë në Jira. Nën cilat rrethana ndodhi, kur, cilin renditje veprimesh e bëri klienti gjatë testimit. Kërkojmë të bashkangjiten foto të ekranit.
Ne përpiqemi të bëjmë deploy çdo ditë, maksimumi çdo dy ditë në serverin e zhvillimit. Kështu klienti fillon të testojë funksionalitetin dhe projekti nuk mbetet i papunë. Kjo gjithashtu shërben si një markë për klientin se projekti është në zhvillim të plotë dhe askush nuk i tregon atij përralla.
Shumë shpesh ndodh që klienti nuk e kupton plotësisht se çfarë i nevojitet. Ndërsa krijon një biznes të ri për vete, me procese ende të paqarta. Prandaj, një situatë e zakonshme është që ne hedhim në plehra të tëra copa kodi dhe ribëjmë logjikën e aplikacionit. Nga kjo del se nuk është e nevojshme të mbulojmë gjithçka me teste. Ka kuptim të mbulojmë vetëm funksionalitetet kritikisht të rëndësishme dhe atë me rezervat përkatëse.
Ka ndodhin situata kur ekipi kupton se nuk po i përfundojmë afatet. Atëherë ne kryejmë një auditim të shpejtë për detyrat dhe menjëherë e njoftojmë klientin. Si një zgjidhje, ne propozojmë të lançojmë brenda afatit funksionalin e rëndësishëm dhe kritik, duke lënë të tjerat për pas lansimit.
Nëse klienti fillon të imagjinon detyra të ndryshme nga mendja, fillon të fantazojë dhe të shpjegojë me gishta, atëherë ne e lutemi atë të na ofrojë një skicë të faqes dhe një fluks 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ë ndonjë detyrë, ne duhet të sigurohemi se ky funksion ishte pjesë e kushteve të kontratës tonë. Nëse është një funksion i ri që kalon kufijtë e marrëveshjeve tona fillestare, ne patjetër duhet ta vlerësojmë këtë funksion ((kohëzgjatja e përafërt e përshtatjes + 30%) x 2) dhe të informojmë klientin se do të na duhen aq dhe aq kohë për të, plus afati do të zhvendoset për kohën e vlerësimit të dyfishuar. Nëse e kryejmë detyrën më shpejt — është fantastike, të gjithë do të fitojnë nga kjo. Nëse jo, atëherë ne kemi marrë masat e nevojshme.

v) Çfarë nuk pranojmë në ekip:

Mungesa e përkushtimit, mosorganizohet, harresa
„Të ushqyerit me mëngjes“. Nëse nuk mund të kryesh një detyrë, ose nuk e di se si, duhet të informosh menjëherë ekipin, jo të presësh deri në fund.
Krenaria dhe lavdërimet nga dikush që ende nuk ka dëshmuar aftësitë dhe profesionalizmin e tij me vepra. Nëse e ka bërë, atëherë është e pranueshme, brenda limitesh 🙂
Mashtrimi në çdo manifestim të tij. Nëse detyra nuk është kryer, nuk duhet të ndryshosh statusin në të kryer dhe të shkruash në bisedën me klientin se ajo është gati. Kompjuteri dështoi, sistemi ra,j qëni e grisi laptopin — të gjitha këto janë të papranueshme. Nëse ndodh një rast i vërtetë forca majeure, ekipi menjëherë duhet të informohet.
Kur specialisti është vazhdimisht offline dhe është e vështirë të kontaktosh gjatë orarit të punës.
Toksicitete në ekip nuk përshtaten! Nëse dikush nuk është dakord me diçka, të gjithë duhet të mblidhen në një takim dhe ta diskutojnë dhe ta zgjidhin atë.

Dhe një sërë pyetjesh / tezash që ndonjëherë i bëj klientit tim, për të sqaruar çdo keqkuptim:

Cilat janë kriteret tuaja për cilësinë?
Si e përcaktoni nëse ka probleme në projekt apo jo?
Duke të gjitha rekomandimet dhe këshillat tona për modifikimin/përmirësimin e sistemit, të gjithë rreziku i përket vetëm juve.
Çdo ndryshim më i madh në projekt (për shembull, ndryshime të shumta fluksi) do të çojë në mundësinë e shfaqjes së defekteve (të cilat ne do t'i rregullojmë natyrisht).
Nuk është e mundur të kuptohet brenda disa minutash se çfarë problemi ka ndodhur në projekt, e aq më pak ta rregullojmë menjëherë.
Ne punojmë sipas një fluksi të caktuar produkti (Detyrat në Jira — Zhvillimi — Testimi — Shpërndarja). Kështu, nuk mund të reagojmë ndaj gjithë kërkesave dhe ankesave në bisedë.
Programuesit janë saktësisht programues, dhe jo testues profesionistë, dhe nuk mund të sigurojnë cilësi të duhur të testimit të projektit.
Përgjegjësia për testimin përfundimtar dhe pranimin e detyrave në prodhim është plotësisht mbi ju.
Nëse ne tashmë kemi marrë një detyrë në punë, nuk mund të kalojmë menjëherë në të tjera, derisa të përfundojmë atë të tanishmen (ndryshe kjo çon në më shumë defekte dhe rritje të kohës së zhvillimit).
Numri i njerëzve në ekip është ulur (për shkak të pushimeve ose sëmundjeve), ndërsa puna është shtuar dhe ne fizikisht nuk do të arrijmë të reagojmë ndaj të gjithave që dëshironi.
Kërkesa nga ana juaj për të bërë deploy në prod pa teste të kryera në dev – kjo është vetëm rreziku juaj, jo i zhvilluesve.
Kur vendosni detyra të paqarta, pa një rrjedhë korrekte, pa dizajnin e skicës, kjo kërkon nga ne shumë më shumë përpjekje dhe kohë realizimi, pasi na duhet të bëjmë punë shtesë në vendin tuaj.
Çdo detyrë për defekte, pa përshkrim të detajuar të shfaqjes së tyre dhe screenshots, nuk na jep mundësinë të kuptojmë se çfarë ka shkuar keq dhe si të simullojmë këtë defekt.
Projekti kërkon vazhdimësi në përmirësim dhe përmirësime për të rritur produktivitetin dhe sigurinë. Prandaj ekipi shpenzon një pjesë të kohës së tij për këto përmirësime.
Për shkak se kemi orë të tepruara (riparime urgjente), ne duhet t'i kompensohem këto në ditë të tjera.

Zakonisht, klienti e kupton menjëherë se zhvillimi i software-it nuk është i thjeshtë dhe dëshira e vetme këtu nuk është padyshim e mjaftueshme.

Në përgjithësi, kjo është gjithçka. Pas skenave, unë kam lënë një sërë negociatash dhe përgatitjesh fillestare të të gjitha proceseve, por si rezultat, gjithçka u stabilizua. Mund të them se ky proces u bë një 'Pule Argjendi' për ne. Njerëzit e rinj që vinin në projekt, mund të angazhoheshin në punë që nga dita e parë, pasi të gjitha proceset janë të përshkruara, dhe dokumentacioni dhe struktura në formën e diagramëve e jepnin menjëherë një ide se çfarë po bëjmë këtu të gjithë ne.

P. S. Dua të sqaroj se nga ana jonë nuk ka një menaxher projekti. Ai është nga ana e klientit. Aspak teknik. Projekti është evropian. Të gjitha komunikimet bëhen vetëm në anglisht.

Të gjithë fat të mbarë në projekte. Mos u djegni dhe përpiquni të përmirësoni proceset tuaja.

Burimi në blogun e tij.

Burimi: habr.com

Organizimi i procesit të punës në ekip në projektin IT