Përshëndetje miq. Shumë shpesh, veçanërisht në outsourcing, shoh të njëjtën pamje. Mungesa e një fluksi të qartë pune në ekipe për projekte të ndryshme.
Gjëja më e rëndësishme është që programuesit nuk kuptojnë se si të komunikojnë me klientin dhe me njëri-tjetrin. Si të ndërtoni një proces të vazhdueshëm të zhvillimit të një produkti cilësor. Si të planifikoni ditën tuaj të punës dhe sprintet.
Dhe e gjithë kjo përfundimisht rezulton në afate të humbura, jashtë orarit, përballje të vazhdueshme se kush duhet të fajësohet dhe pakënaqësi të klientëve se ku dhe si po lëviz gjithçka. Shumë shpesh, e gjithë kjo çon në një ndryshim të programuesve, apo edhe ekipeve të tëra. Humbja e një klienti, përkeqësimi i reputacionit, etj.
Në një kohë, sapo përfundova në një projekt të tillë, ku kishte gjithë këto kënaqësi.
Askush nuk donte të merrte përgjegjësinë për projektin (një treg i madh shërbimesh), qarkullimi ishte i tmerrshëm, klienti ishte thjesht i shqyer dhe i frustruar. Një herë CEO erdhi tek unë dhe më tha që ju keni përvojën e nevojshme, kështu që këtu janë kartat në duart tuaja. Merrni projektin për veten tuaj. Nëse e prishni, ne do ta mbyllim projektin dhe do t'i dëbojmë të gjithë. Do të funksionojë, do të jetë e lezetshme, pastaj drejtojeni dhe zhvilloni atë siç e shihni të arsyeshme. Si rezultat, u bëra drejtuesi i ekipit për projektin dhe gjithçka ra mbi supet e mia.
Gjëja e parë që bëra ishte të zhvillova një rrjedhë pune nga e para që përputhej me vizionin tim në atë kohë dhe shkrova një përshkrim pune për ekipin. Zbatimi i tij nuk ishte i lehtë. Por brenda një muaji ose më shumë gjithçka u rregullua, zhvilluesit dhe klienti u mësuan me të, dhe gjithçka shkoi në heshtje dhe të qetë. Për t'i treguar ekipit se kjo nuk ishte thjesht një "stuhi në filxhan çaji", por një rrugëdalje reale nga situata, mora përgjegjësitë maksimale, duke hequr rutinën e pakëndshme nga ekipi.
Tashmë ka kaluar një vit e gjysmë, dhe projekti po zhvillohet pa punë jashtë orarit, pa "gara miu" dhe të gjitha llojet e stresit. Disa njerëz në ekipin e vjetër nuk donin të punonin kështu dhe u larguan; të tjerë, përkundrazi, ishin shumë të kënaqur që ishin shfaqur rregulla transparente. Por në fund të fundit, të gjithë në ekip janë shumë të motivuar dhe e njohin plotësisht projektin e madh, duke përfshirë edhe pjesën e përparme dhe atë të pasme. Përfshirë si bazën e kodit ashtu edhe të gjithë logjikën e biznesit. Madje ka arritur deri në pikën ku ne nuk jemi thjesht “vaktarë”, por ne vetë dalim me shumë procese biznesi dhe veçori të reja që i pëlqejnë biznesit.
Falë kësaj qasjeje nga ana jonë, klienti vendosi të porosiste një treg tjetër nga kompania jonë, që është një lajm i mirë.
Meqenëse kjo funksionon në projektin tim, ndoshta do të ndihmojë edhe dikë. Pra, vetë procesi që na ndihmoi të shpëtojmë projektin:
Procesi i punës ekipore në projektin "Projekti im i preferuar"
a) Procesi i brendshëm i ekipit (midis zhvilluesve)
- Të gjitha çështjet krijohen në sistemin Jira
- Çdo detyrë duhet të përshkruhet sa më shumë që të jetë e mundur dhe të kryejë rreptësisht një veprim
- Çdo veçori, nëse është mjaft komplekse, ndahet në shumë detyra të vogla
- Ekipi punon në veçoritë si një detyrë e vetme. Së pari, ne të gjithë punojmë së bashku në një veçori, e dërgojmë për testim dhe më pas marrim një tjetër.
- Çdo detyrë është e shënuar, për pjesën e pasme ose frontin e saj
- Ka lloje detyrash dhe gabimesh. Ju duhet t'i tregoni ato saktë.
- Pas përfundimit të një detyre, ajo transferohet në statusin e rishikimit të kodit (në këtë rast, krijohet një kërkesë tërheqjeje për një koleg)
- Personi që përfundoi detyrën gjurmon menjëherë kohën e tij për këtë detyrë.
- Pas kontrollit të kodit, PR do të miratojë dhe pas kësaj, ai që e ka kryer këtë detyrë në mënyrë të pavarur e bashkon atë në degën kryesore, pas së cilës ai e ndryshon statusin e tij në gati për vendosje në serverin dev.
- Të gjitha detyrat e gatshme për vendosje në serverin dev vendosen nga drejtuesi i ekipit (fusha e tij e përgjegjësisë), ndonjëherë nga një anëtar i ekipit, nëse diçka është urgjente. Pas vendosjes, të gjitha detyrat nga gati për vendosje në dev transferohen në status - gati për testim në dev
- Të gjitha detyrat testohen nga klienti
- Kur klienti ka testuar detyrën në dev, ai e transferon atë në statusin e gatshëm për vendosje në prodhim
- Për vendosjen në prodhim, ne kemi një degë të veçantë, ku bashkojmë masterin vetëm përpara vendosjes
- Nëse gjatë testimit klienti gjen gabime, ai e kthen detyrën për rishikim, duke vendosur statusin e saj si të kthyer për rishikim. Në këtë mënyrë ne ndajmë detyrat e reja nga ato që nuk e kanë kaluar testimin.
- Si rezultat, të gjitha detyrat kalojnë nga krijimi deri në përfundim: Për të bërë → Në zhvillim → Rishikim i kodit → Vendosja e gatshme në dev → QA në dev → (Kthehu te dev) → Vendosja e gatshme në prod → QA në prod → U krye
- Secili zhvillues teston kodin e tij në mënyrë të pavarur, duke përfshirë si përdorues të faqes. Nuk lejohet bashkimi i një dege në atë kryesore, përveç nëse dihet me siguri se kodi funksionon.
- Çdo detyrë ka përparësi. Prioritetet vendosen ose nga klienti ose nga drejtuesi i ekipit.
- Zhvilluesit kryejnë së pari detyrat prioritare.
- Zhvilluesit mund t'i 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ë klienti krijon i shkojnë drejtuesit të ekipit, i cili i vlerëson ato dhe ose i kërkon klientit t'i modifikojë ose ia cakton njërit prej anëtarëve të ekipit.
- Të gjitha detyrat që janë gati për t'u vendosur në zhvillues ose prod i shkojnë gjithashtu drejtuesit të ekipit, i cili përcakton në mënyrë të pavarur se kur dhe si të kryhet vendosja. Pas çdo vendosjeje, drejtuesi i ekipit (ose anëtari i ekipit) duhet të njoftojë klientin për këtë. Dhe gjithashtu ndryshoni statuset për detyrat në gati për testim për dev/vazhdim.
- Çdo ditë në të njëjtën orë (për ne është ora 12.00) zhvillojmë një takim mes të gjithë anëtarëve të ekipit
- Të gjithë në takim raportojnë, duke përfshirë udhëheqësin e ekipit, për atë që kanë bërë dje dhe çfarë planifikojnë të bëjnë sot. Çfarë nuk funksionon dhe pse. Në këtë mënyrë i gjithë ekipi është i vetëdijshëm se kush po bën çfarë dhe në çfarë faze është projekti. Kjo na jep mundësinë të parashikojmë dhe rregullojmë, nëse është e nevojshme, vlerësimet dhe afatet tona.
- Në takim, drejtuesi i ekipit flet gjithashtu për të gjitha ndryshimet në projekt dhe nivelin e gabimeve aktuale që nuk u gjetën nga klienti. Të gjitha gabimet zgjidhen dhe i caktohen secilit anëtar të ekipit për t'i zgjidhur ato.
- Në takim, drejtuesi i ekipit cakton detyra për secilin person, duke marrë parasysh ngarkesën aktuale të zhvilluesve, nivelin e trajnimit të tyre profesional, dhe gjithashtu duke marrë parasysh afërsinë e një detyre të veçantë me atë që zhvilluesi po bën aktualisht.
- Në takim, drejtuesi i ekipit zhvillon një strategji të përgjithshme për arkitekturën dhe logjikën e biznesit. Pas së cilës i gjithë ekipi diskuton këtë dhe vendos të bëjë rregullime ose të miratojë këtë strategji.
- Çdo zhvillues shkruan kodin dhe ndërton algoritme në mënyrë të pavarur brenda kornizës së një arkitekture të vetme dhe logjike biznesi. Të gjithë mund të shprehin vizionin e tyre të zbatimit, por askush nuk e detyron askënd ta bëjë këtë në këtë mënyrë dhe jo ndryshe. Çdo vendim është i justifikuar. Nëse ka një zgjidhje më të mirë, por nuk ka kohë për të tani, atëherë krijohet një detyrë në yndyrë për rifaktorimin e ardhshëm të një pjese të caktuar të kodit.
- Kur një zhvillues merr përsipër një detyrë, ai e transferon atë në statusin e zhvillimit. I gjithë komunikimi në lidhje me sqarimin e detyrës me klientin bie mbi supet e zhvilluesit. Pyetjet teknike mund t'i bëhen drejtuesit të ekipit ose kolegëve.
- Nëse zhvilluesi nuk e kupton thelbin e detyrës dhe klienti nuk ishte në gjendje ta shpjegonte qartë atë, atëherë ai vazhdon në detyrën tjetër. Dhe drejtuesi i ekipit merr atë aktual dhe e diskuton atë me klientin.
- Çdo ditë, zhvilluesi duhet të shkruajë në bisedën e klientit se cilat detyra ka punuar dje dhe cilat detyra do të punojë sot
- Procesi i punës zhvillohet sipas Scrum. Gjithçka është e ndarë në sprinte. Çdo sprint zgjat dy javë.
- Sprintet krijohen, plotësohen dhe mbyllen nga drejtuesi i ekipit.
- Nëse projekti ka afate strikte, atëherë ne përpiqemi të vlerësojmë afërsisht të gjitha detyrat. Dhe ne i bashkuam ato në një sprint. Nëse klienti përpiqet të shtojë më shumë detyra në sprint, atëherë ne vendosim prioritete dhe transferojmë disa detyra të tjera në sprintin tjetër.
b) Procesi i punës me klientin
- Çdo zhvillues mund dhe duhet të komunikojë me klientin
- Klienti nuk mund të lejohet të vendosë rregullat e tij të lojës. Është e nevojshme t'i bëjmë të qartë klientit në mënyrë të sjellshme dhe miqësore se ne jemi specialistë në fushën tonë dhe vetëm ne duhet të ndërtojmë procese pune dhe të përfshijmë klientin në to.
- Është e nevojshme, në mënyrë ideale, përpara se të filloni të zbatoni ndonjë funksionalitet, të krijoni një diagram të rrjedhës së të gjithë procesit logjik për veçorinë (fluksin e punës). Dhe dërgojini klientit për konfirmim. Kjo vlen vetëm për funksionet komplekse dhe jo të dukshme, për shembull, një sistem pagese, një sistem njoftimi, etj. Kjo do të na lejojë të kuptojmë më saktë se çfarë saktësisht ka nevojë klienti, të ruajmë dokumentacionin për veçorinë dhe gjithashtu të sigurojmë veten kundër faktit që klienti mund të thotë në të ardhmen se ne nuk bëmë atë që ai kërkoi.
- Të gjitha diagramet / diagramet e rrjedhës / logjika etj. E ruajmë në Confluence/Fat, ku i kërkojmë klientit të konfirmojë korrektësinë e zbatimit të ardhshëm në komente.
- Ne përpiqemi të mos e ngarkojmë klientin me detaje teknike. Nëse ne kemi nevojë për të kuptuar se si e dëshiron klienti, atëherë ne vizatojmë algoritme primitive në formën e një grafiku rrjedhash që klienti mund të kuptojë dhe të korrigjojë/modifikojë gjithçka vetë.
- Nëse klienti gjen një gabim në projekt, atëherë ju kërkojmë ta përshkruani atë në detaje në Zhira. Në çfarë rrethanash ka ndodhur, kur, çfarë sekuence veprimesh janë kryer nga klienti gjatë testimit. Ju lutemi bashkëngjitni pamjet e ekranit.
- Ne përpiqemi çdo ditë, maksimumi çdo ditë tjetër, të vendosemi në serverin e dev. Më pas klienti fillon të testojë funksionalitetin dhe projekti nuk qëndron boshe. Në të njëjtën kohë, ky është një shënues për klientin që projekti është në zhvillim të plotë dhe askush nuk po i tregon atij përralla.
- Shpesh ndodh që klienti të mos e kuptojë plotësisht atë që i nevojitet. Sepse ai po krijon një biznes të ri për vete, me procese që ende nuk janë ngritur. Prandaj, një situatë shumë e zakonshme është kur hedhim pjesë të tëra kodi në koshin e plehrave dhe ridizajnojmë logjikën e aplikacionit. Nga kjo rrjedh se nuk duhet të mbuloni absolutisht gjithçka me teste. Ka kuptim të mbulohet vetëm funksionaliteti kritik me teste, dhe pastaj vetëm me rezervime.
- Ka situata kur skuadra e kupton që nuk po respektojmë afatet. Pastaj ne kryejmë një auditim të shpejtë të detyrave dhe menjëherë informojmë klientin për këtë. Si një rrugëdalje nga situata, ne sugjerojmë që funksionaliteti i rëndësishëm dhe kritik të lansohet në kohë dhe pjesa tjetër të lihet pas publikimit.
- Nëse klienti fillon të dalë me detyra të ndryshme nga koka e tij, fillon të fantazojë dhe të shpjegojë me gishta, atëherë i kërkojmë atij të na ofrojë një paraqitje faqeje dhe të rrjedhë me logjikë që duhet të përshkruajë plotësisht sjelljen e të gjithë paraqitjes dhe elementet e saj.
- Përpara se të marrim përsipër ndonjë detyrë, duhet të sigurohemi që kjo veçori të jetë përfshirë në kushtet e marrëveshjes/kontratës sonë. Nëse kjo është një veçori e re që shkon përtej marrëveshjeve tona fillestare, atëherë duhet ta çmojmë këtë veçori ((koha e parashikuar e përfundimit + 30%) x 2) dhe t'i tregojmë klientit se do të na duhet kaq shumë kohë për ta përfunduar atë, plus afati zhvendoset me kohën e vlerësimit shumëzuar me dy. Le ta bëjmë detyrën më shpejt - shkëlqyeshëm, të gjithë do të përfitojnë prej saj. Nëse jo, atëherë ne ju kemi mbuluar.
c) Çfarë nuk pranojmë në një ekip:
- Mosangazhimi, mungesa e qetësisë, harresa
- "Ushqyerja e mëngjesit." Nëse nuk mund ta përfundoni një detyrë dhe nuk dini si, atëherë duhet të njoftoni menjëherë drejtuesin e ekipit për të dhe të mos prisni deri në minutën e fundit.
- Vetullat dhe mburret nga një person që nuk i ka vërtetuar ende aftësitë dhe profesionalizmin e tij. Nëse vërtetohet, atëherë është e mundur, brenda kufijve të mirësjelljes :)
- Mashtrimi në të gjitha format e tij. Nëse një detyrë nuk është përfunduar, atëherë nuk duhet ta ndryshoni statusin e saj në të përfunduar dhe të shkruani në bisedën e klientit se është gati. Kompjuteri u prish, sistemi u rrëzua, qeni përtypi laptopin - e gjithë kjo është e papranueshme. Nëse ndodh një ngjarje e vërtetë e forcës madhore, drejtuesi i ekipit duhet të njoftohet menjëherë.
- Kur një specialist është jashtë linje gjatë gjithë kohës dhe është e vështirë ta kontaktosh gjatë orarit të punës.
- Nuk lejohet toksiciteti në ekip! Nëse dikush nuk pajtohet me diçka, atëherë të gjithë mblidhen në një tubim dhe diskutojnë dhe vendosin për të.
Dhe një numër pyetjesh/tezash që ndonjëherë i bëj klientit tim për të pastruar të gjitha keqkuptimet:
- Cilat janë kriteret tuaja të cilësisë?
- Si të përcaktoni nëse një projekt ka probleme apo jo?
- Duke shkelur të gjitha rekomandimet dhe këshillat tona për ndryshimin/përmirësimin e sistemit, të gjitha rreziqet përballohen vetëm nga ju
- Çdo ndryshim i madh në projekt (për shembull, të gjitha llojet e rrjedhave shtesë) do të çojë në shfaqjen e mundshme të gabimeve (të cilat, natyrisht, do t'i rregullojmë)
- Është e pamundur të kuptosh brenda dy minutash se çfarë lloj problemi ka ndodhur në projekt, aq më pak ta rregullosh atë menjëherë
- Ne punojmë në një fluks specifik produkti (Detyrat në Zhira - Zhvillimi - Testimi - Vendosja). Kjo do të thotë që ne nuk mund t'i përgjigjemi të gjithë rrjedhës së kërkesave dhe ankesave në chat.
- Programuesit janë programues, jo testues profesionistë dhe nuk mund të sigurojnë cilësinë e duhur të testimit të projektit
- Përgjegjësia për testimin përfundimtar dhe pranimin e detyrave të prodhimit bie tërësisht mbi ju
- Nëse tashmë kemi marrë përsipër një detyrë, nuk mund të kalojmë menjëherë te të tjerat derisa të përfundojmë atë aktuale (përndryshe kjo çon në më shumë gabime dhe rritje të kohës së zhvillimit)
- Ka më pak njerëz në ekip (për shkak të pushimeve ose sëmundjeve), por ka më shumë punë dhe fizikisht nuk do të kemi kohë për t'iu përgjigjur gjithçkaje që dëshironi
- Ne ju kërkojmë të bëni një vendosje në prodhim pa detyra të testuara në dev - ky është vetëm rreziku juaj, jo zhvilluesit
- Kur vendosni detyra të paqarta, pa një rrjedhë të saktë, pa paraqitje të projektimit, kjo kërkon shumë më tepër përpjekje dhe kohë zbatimi nga ne, pasi ne duhet të bëjmë një punë shtesë në vend të jush.
- Çdo detyrë mbi defektet, pa një përshkrim të detajuar të shfaqjes së tyre dhe pamjet e ekranit, nuk na jep mundësinë të kuptojmë se çfarë shkoi keq dhe si mund ta rregullojmë këtë defekt
- Projekti kërkon përpunim dhe përmirësime të vazhdueshme për të përmirësuar performancën dhe sigurinë. Prandaj, ekipi shpenzon një pjesë të kohës së tij në këto përmirësime
- Për faktin se kemi jashtë orarit me orë (rregullime urgjente), duhet t'i kompensojmë ato në ditët e tjera.
Si rregull, klienti e kupton menjëherë se gjithçka nuk është aq e thjeshtë në zhvillimin e softuerit dhe vetëm dëshira nuk është e mjaftueshme.
Në përgjithësi, kjo është e gjitha. Unë lë pas skenës shumë negociata dhe korrigjimin fillestar të të gjitha proceseve, por si rezultat, gjithçka funksionoi. Mund të them se ky proces u bë një lloj “plumbi i argjendtë” për ne. Njerëzit e rinj që erdhën në projekt mund të përfshiheshin menjëherë në punë që nga dita e parë, pasi të gjitha proceset u përshkruan, dhe dokumentacioni dhe arkitektura në formën e diagrameve dhanë menjëherë një ide se çfarë po bënim të gjithë këtu.
PS Do të doja të sqaroja se nuk ka asnjë menaxher projekti nga ana jonë. Është në anën e klientit. Aspak teknik. projekt evropian. I gjithë komunikimi është vetëm në anglisht.
Ju uroj fat të gjithëve në projektet tuaja. Mos u digjni dhe përpiquni të përmirësoni proceset tuaja.
Burimi në timin .
Burimi: www.habr.com