ProHoster > Blogs > Administrācija > IT projekta darbplÅ«smas organizÄ“Å”ana komandā

IT projekta darbplÅ«smas organizÄ“Å”ana komandā

Sveiki draugi. Diezgan bieži, īpaŔi ārpakalpojumos, redzu vienu un to paŔu ainu. Trūkst skaidras darbplūsmas dažādu projektu komandās.

Pats galvenais, ka programmētāji nesaprot, kā komunicēt ar klientu un savā starpā. Kā izveidot nepārtrauktu kvalitatīva produkta izstrādes procesu. Kā plānot savu darba dienu un sprintus.

Un tas viss galu galā rada nokavētus termiņus, virsstundas, pastāvÄ«gu kārÅ”u izrēķināŔanos par to, kurÅ” ir vainÄ«gs, un klientu neapmierinātÄ«bu ar to, kur un kā viss virzās. Diezgan bieži tas viss noved pie programmētāju vai pat veselu komandu maiņas. Klienta zaudÄ“Å”ana, reputācijas pasliktināŔanās utt.

Savulaik es vienkārŔi nonācu pie Ŕāda projekta, kur bija visi Ŕie prieki.

Neviens negribēja uzņemties atbildÄ«bu par projektu (liels pakalpojumu tirgus), apgrozÄ«jums bija drausmÄ«gs, klients vienkārÅ”i saplosÄ«ts un neapmierināts. Reiz pie manis pienāca izpilddirektors un teica, ka jums ir vajadzÄ«gā pieredze, tāpēc lÅ«k, kārtis jÅ«su rokās. Paņemiet projektu sev. Ja jÅ«s sabojāsit, mēs slēgsim projektu un izmetÄ«sim visus. Izdosies, bÅ«s forÅ”i, tad vadi un attÄ«sti pēc saviem ieskatiem. Rezultātā es kļuvu par projekta komandas vadÄ«tāju, un viss krita uz maniem pleciem.

Pirmā lieta, ko es izdarÄ«ju, bija no nulles izstrādāt darbplÅ«smu, kas atbilst manam toreizējam redzējumam, un uzrakstÄ«ju komandai darba aprakstu. To Ä«stenot nebija viegli. Bet apmēram mēneÅ”a laikā viss nokārtojās, izstrādātāji un klients pieraduÅ”i, un viss noritēja klusi un ērti. Lai parādÄ«tu komandai, ka Ŕī nav tikai ā€œvētra tējas krÅ«zēā€, bet gan reāla izeja no situācijas, uzņēmos maksimāli daudz pienākumu, noņemot no komandas nepatÄ«kamo rutÄ«nu.

Jau pagājis pusotrs gads, un projekts attÄ«stās bez virsstundām, bez ā€œÅ¾urku skrējieniemā€ un visāda stresa. Daži cilvēki vecajā komandā nevēlējās tā strādāt un aizgāja, citi, gluži pretēji, bija ļoti apmierināti, ka ir parādÄ«juÅ”ies pārredzami noteikumi. Bet galu galā visi komandā ir ļoti motivēti un pilnÄ«bā pārzina milzÄ«go projektu, tostarp gan priekÅ”galu, gan aizmuguri. Ietverot gan koda bāzi, gan visu biznesa loÄ£iku. Ir pat nonācis lÄ«dz tādam lÄ«menim, ka mēs neesam tikai ā€œairētājiā€, bet paÅ”i nākam klajā ar daudziem biznesa procesiem un jaunām funkcijām, kas izrādās biznesam patÄ«k.

Pateicoties Å”ai mÅ«su pieejai, klients nolēma pasÅ«tÄ«t citu tirgu no mÅ«su uzņēmuma, kas ir labas ziņas.

Tā kā tas darbojas manā projektā, varbūt tas kādam arī noderēs. Tātad, pats process, kas mums palīdzēja saglabāt projektu:

Komandas darba process projektā ā€œMans mīļākais projektsā€

a) iekŔējais komandas process (starp izstrādātājiem)

  • Visi jautājumi tiek izveidoti Jira sistēmā
  • Katrs uzdevums ir jāapraksta pēc iespējas vairāk un jāveic stingri viena darbÄ«ba
  • Jebkura funkcija, ja tā ir pietiekami sarežģīta, tiek sadalÄ«ta daudzos mazos uzdevumos
  • Komanda strādā ar funkcijām kā vienu uzdevumu. Pirmkārt, mēs visi kopā strādājam pie vienas funkcijas, nosÅ«tām to testÄ“Å”anai, pēc tam ņemam nākamo.
  • Katrs uzdevums ir atzÄ«mēts gan aizmugursistēmai, gan priekÅ”galam
  • Ir uzdevumu un kļūdu veidi. Jums tie ir pareizi jānorāda.
  • Pēc uzdevuma izpildes tas tiek pārsÅ«tÄ«ts uz koda pārskatÄ«Å”anas statusu (Å”ajā gadÄ«jumā kolēģim tiek izveidots izvilkÅ”anas pieprasÄ«jums)
  • Persona, kas paveica uzdevumu, nekavējoties izseko Å”im uzdevumam veltÄ«to laiku.
  • Pēc koda pārbaudes PR apstiprinās, un pēc tam tas, kurÅ” veica Å”o uzdevumu, patstāvÄ«gi apvieno to galvenajā filiālē, pēc tam maina tā statusu uz gatavs izvietoÅ”anai dev serverÄ«.
  • Visus uzdevumus, kas ir gatavi izvietoÅ”anai izstrādātāju serverÄ«, izvieto komandas vadÄ«tājs (viņa atbildÄ«bas joma), dažreiz komandas loceklis, ja kaut kas ir steidzams. Pēc izvietoÅ”anas visi uzdevumi no gatavi izvietoÅ”anai uz izstrādātāju tiek pārsÅ«tÄ«ti uz statusu ā€” gatavs testÄ“Å”anai izstrādātājā
  • Visus uzdevumus pārbauda klients
  • Kad klients ir pārbaudÄ«jis uzdevumu izstrādātājā, viņŔ to pārsÅ«ta uz statusu gatavs izvietoÅ”anai ražoÅ”anā
  • IzvērÅ”anai uz ražoÅ”anu mums ir atseviŔķa filiāle, kurā mēs sapludinām galveno tikai pirms izvietoÅ”anas
  • Ja testÄ“Å”anas laikā klients konstatē kļūdas, viņŔ atgriež uzdevumu pārskatÄ«Å”anai, iestatot tā statusu kā atgriezts pārskatÄ«Å”anai. Tādā veidā mēs atdalām jaunus uzdevumus no tiem, kas nav izturējuÅ”i pārbaudi.
  • Rezultātā visi uzdevumi sākas no izveides lÄ«dz pabeigÅ”anai: Izdarāms ā†’ Izstrādē ā†’ Koda pārskatÄ«Å”ana ā†’ Gatavs izvietoÅ”anai izstrādātājā ā†’ Kvalitāte izstrādātājā ā†’ (Atgriezties uz izstrādātāju) ā†’ Gatavs izvietoÅ”anai ražoÅ”anā ā†’ QA ražoÅ”anas procesā ā†’ Gatavs
  • Katrs izstrādātājs pārbauda savu kodu neatkarÄ«gi, tostarp kā vietnes lietotājs. Nav atļauts apvienot filiāli galvenajā, ja vien nav droÅ”i zināms, ka kods darbojas.
  • Katram uzdevumam ir prioritātes. Prioritātes nosaka klients vai komandas vadÄ«tājs.
  • Izstrādātāji vispirms pabeidz prioritāros uzdevumus.
  • Izstrādātāji var pieŔķirt uzdevumus viens otram, ja sistēmā tika atrastas dažādas kļūdas vai viens uzdevums sastāv no vairāku speciālistu darba.
  • Visi klienta izveidotie uzdevumi nonāk komandas vadÄ«tājam, kurÅ” tos novērtē un vai nu lÅ«dz klientam tos mainÄ«t, vai arÄ« pieŔķir kādam no komandas locekļiem.
  • Visi uzdevumi, kas ir gatavi izvietoÅ”anai izstrādātājā vai produkcijā, tiek nodoti arÄ« komandas vadÄ«tājam, kas neatkarÄ«gi nosaka, kad un kā veikt izvietoÅ”anu. Pēc katras izvietoÅ”anas komandas vadÄ«tājam (vai komandas loceklim) par to ir jāinformē klients. Un arÄ« mainiet uzdevumu statusus, lai tie bÅ«tu gatavi testÄ“Å”anai dev/cont.
  • Katru dienu vienā un tajā paŔā laikā (mums tas ir plkst. 12.00) rÄ«kojam visu komandas dalÄ«bnieku tikÅ”anos
  • Visi sapulces dalÄ«bnieki, arÄ« komandas vadÄ«tājs, ziņo par vakar paveikto un Å”odien plānotajiem. Kas nedarbojas un kāpēc. Tādā veidā visa komanda apzinās, kas ko dara un kurā stadijā atrodas projekts. Tas dod mums iespēju prognozēt un vajadzÄ«bas gadÄ«jumā koriģēt mÅ«su tāmes un termiņus.
  • Sanāksmē komandas vadÄ«tājs runā arÄ« par visām izmaiņām projektā un paÅ”reizējo kļūdu lÄ«meni, ko klients nav atradis. Visas kļūdas tiek sakārtotas un pieŔķirtas katram komandas dalÄ«bniekam, lai tās novērstu.
  • Sanāksmē komandas vadÄ«tājs katram cilvēkam pieŔķir uzdevumus, ņemot vērā izstrādātāju paÅ”reizējo darba slodzi, viņu profesionālās sagatavotÄ«bas lÄ«meni, kā arÄ« ņemot vērā konkrētā uzdevuma tuvumu tam, ko izstrādātājs Å”obrÄ«d dara.
  • Sanāksmē komandas vadÄ«tājs izstrādā vispārÄ«gu arhitektÅ«ras un biznesa loÄ£ikas stratēģiju. Pēc tam visa komanda to apspriež un nolemj veikt korekcijas vai pieņemt Å”o stratēģiju.
  • Katrs izstrādātājs raksta kodu un veido algoritmus neatkarÄ«gi vienas arhitektÅ«ras un biznesa loÄ£ikas ietvaros. Katrs var izteikt savu redzējumu par ievieÅ”anu, taču neviens nevienam neliek darÄ«t tā un ne citādi. Katrs lēmums ir pamatots. Ja ir labāks risinājums, bet Å”obrÄ«d tam nav laika, tad taukos tiek izveidots uzdevums noteiktas koda daļas turpmākai pārstrukturÄ“Å”anai.
  • Kad izstrādātājs uzņemas uzdevumu, viņŔ to nodod izstrādes statusā. Visa komunikācija par uzdevuma noskaidroÅ”anu ar klientu gulstas uz izstrādātāja pleciem. Tehniskus jautājumus var uzdot komandas vadÄ«tājam vai kolēģiem.
  • Ja izstrādātājs nesaprot uzdevuma bÅ«tÄ«bu un klients nevarēja to skaidri izskaidrot, viņŔ pāriet pie nākamā uzdevuma. Un komandas vadÄ«tājs ņem paÅ”reizējo un apspriež to ar klientu.
  • Katru dienu izstrādātājam klienta tērzÄ“Å”anā jāieraksta par to, pie kādiem uzdevumiem viņŔ strādāja vakar un pie kādiem uzdevumiem strādās Å”odien
  • Darba process notiek saskaņā ar Scrum. Viss ir sadalÄ«ts sprintos. Katrs sprints ilgst divas nedēļas.
  • Sprintus veido, aizpilda un noslēdz komandas vadÄ«tājs.
  • Ja projektā ir stingri noteikti termiņi, tad cenÅ”amies aptuveni aplēst visus uzdevumus. Un mēs tos salikām sprintā. Ja klients mēģina sprintam pievienot vairāk uzdevumu, tad mēs nosakām prioritātes un dažus citus uzdevumus pārvedam uz nākamo sprintu.

b) Darba process ar klientu

  • Katrs izstrādātājs var sazināties ar klientu un tam vajadzētu sazināties
  • Klientam nevar ļaut uzspiest savus spēles noteikumus. Klientam pieklājÄ«gi un draudzÄ«gi jāpaskaidro, ka esam savas jomas speciālisti, un tikai mums paÅ”iem jāveido darba procesi un jāiesaista tajos klients.
  • Ideālā gadÄ«jumā pirms jebkuras funkcionalitātes ievieÅ”anas ir jāizveido visas funkcijas (darbplÅ«smas) loÄ£iskā procesa blokshēma. Un nosÅ«tiet to klientam apstiprināŔanai. Tas attiecas tikai uz sarežģītu un nepārprotamu funkcionalitāti, piemēram, maksājumu sistēmu, paziņojumu sistēmu utt. Tas ļaus precÄ«zāk saprast, kas tieÅ”i klientam ir nepiecieÅ”ams, saglabāt dokumentāciju funkcijai, kā arÄ« apdroÅ”ināties pret to, ka klients nākotnē var teikt, ka mēs neizdarÄ«jām to, ko viņŔ lÅ«dza.
  • Visas diagrammas/blokshēmas/loÄ£ika utt. Saglabājam Confluence/Fat, kur lÅ«dzam klientu komentāros apstiprināt turpmākās ievieÅ”anas pareizÄ«bu.
  • Mēs cenÅ”amies neapgrÅ«tināt klientu ar tehniskām detaļām. Ja mums ir vajadzÄ«ga izpratne par to, kā klients to vēlas, tad mēs zÄ«mējam primitÄ«vus algoritmus blokshēmas veidā, ko klients var saprast un pats visu labot/pārveidot.
  • Ja klients projektā konstatē kļūdu, tad lÅ«dzam to ļoti detalizēti aprakstÄ«t Fat. Kādos apstākļos tas notika, kad, kādu darbÄ«bu secÄ«bu testÄ“Å”anas laikā veica klients. LÅ«dzu, pievienojiet ekrānuzņēmumus.
  • Mēs cenÅ”amies katru dienu, ne vairāk kā katru otro dienu, izvietot izstrādātāja serverÄ«. Pēc tam klients sāk pārbaudÄ«t funkcionalitāti, un projekts nestāv dÄ«kstāvē. Tajā paŔā laikā tas ir marÄ·ieris klientam, ka projekts ir pilnā attÄ«stÄ«bas stadijā un neviens viņam nestāsta pasakas.
  • Bieži gadās, ka klients lÄ«dz galam nesaprot, kas viņam vajadzÄ«gs. Jo viņŔ veido sev jaunu biznesu, ar procesiem, kas vēl nav izveidoti. Tāpēc ļoti izplatÄ«ta ir situācija, kad mēs izmetam veselas koda daļas miskastē un pārveidojam lietojumprogrammas loÄ£iku. No tā izriet, ka jums nevajadzētu pilnÄ«bā visu aptvert ar testiem. Ir jēga ar testiem aptvert tikai kritisko funkcionalitāti un pēc tam tikai ar atrunām.
  • Ir situācijas, kad komanda saprot, ka neievērojam termiņus. Pēc tam veicam ātru uzdevumu auditu un nekavējoties par to informējam klientu. Kā izeju no situācijas, iesakām laicÄ«gi palaist svarÄ«gu un kritisku funkcionalitāti, bet pārējo atstāt pēc izlaiÅ”anas.
  • Ja klients sāk izdomāt dažādus uzdevumus no savas galvas, sāk fantazēt un skaidrot ar pirkstiem, tad mēs lÅ«dzam viņu nodroÅ”ināt mums lapas izkārtojumu un plÅ«smu ar loÄ£iku, kas pilnÄ«bā apraksta visa izkārtojuma uzvedÄ«bu un tās elementi.
  • Pirms jebkura uzdevuma veikÅ”anas mums ir jāpārliecinās, vai Ŕī funkcija ir iekļauta mÅ«su lÄ«guma/lÄ«guma noteikumos. Ja Ŕī ir jauna funkcija, kas pārsniedz mÅ«su sākotnējos lÄ«gumus, mums ir jānosaka Ŕīs funkcijas cena ((paredzamais pabeigÅ”anas laiks + 30%) x 2) un jānorāda klientam, ka mums bÅ«s nepiecieÅ”ams tik daudz laika, lai to pabeigtu, kā arÄ« termiņŔ tiek pārcelts ar paredzamo laiku, kas reizināts ar divi. Uzdevumu veiksim ātrāk ā€“ lieliski, no tā ieguvēji bÅ«s visi. Ja nē, tad mēs jÅ«s nodroÅ”inām.

c) Ko mēs nepieņemam komandā:

  • NeapņemÅ”anās, nesavaldÄ«bas trÅ«kums, aizmārŔība
  • ā€œBrokastu baroÅ”ana.ā€ Ja nevarat izpildÄ«t uzdevumu un nezināt, kā, tad nekavējoties par to jāpaziņo komandas vadÄ«tājam, nevis jāgaida lÄ«dz pēdējai minÅ«tei.
  • Uzacis un lepojas no cilvēka, kurÅ” vēl nav pierādÄ«jis savas spējas un profesionalitāti. Ja tas ir pierādÄ«ts, tad tas ir iespējams, pieklājÄ«bas robežās :)
  • MaldināŔana visās tās izpausmēs. Ja uzdevums nav pabeigts, tad nevajadzētu mainÄ«t tā statusu uz pabeigts un klienta tērzÄ“Å”anā rakstÄ«t, ka tas ir gatavs. Dators sabojājās, sistēma avarēja, suns koŔļāja klēpjdatoru - tas viss ir nepieņemami. Ja notiek reāls nepārvaramas varas notikums, nekavējoties jāinformē komandas vadÄ«tājs.
  • Kad speciālists visu laiku ir bezsaistē un darba laikā viņu ir grÅ«ti sasniegt.
  • Toksicitāte komandā nav pieļaujama! Ja kāds kaut kam nepiekrÄ«t, tad visi sanāk kopā uz mÄ«tiņu un apspriež un lemj par to.

Un vairāki jautājumi/tēzes, ko es dažreiz uzdodu savam klientam, lai novērstu visus pārpratumus:

  1. Kādi ir jūsu kvalitātes kritēriji?
  2. Kā noteikt, vai projektam ir problēmas vai nav?
  3. Pārkāpjot visus mÅ«su ieteikumus un ieteikumus par sistēmas maiņu/uzlaboÅ”anu, visus riskus uzņematies tikai jÅ«s
  4. Jebkuras bÅ«tiskas izmaiņas projektā (piemēram, visa veida papildu plÅ«sma) izraisÄ«s iespējamu kļūdu parādÄ«Å”anos (kuras mēs, protams, izlabosim)
  5. Dažu minÅ«Å”u laikā nav iespējams saprast, kāda veida problēma radusies projektā, un vēl jo mazāk to nekavējoties novērst
  6. Mēs strādājam pie konkrētas produktu plÅ«smas (Uzdevumi Žirā - Izstrāde - TestÄ“Å”ana - IzvietoÅ”ana). Tas nozÄ«mē, ka mēs nevaram atbildēt uz visu pieprasÄ«jumu un sÅ«dzÄ«bu plÅ«smu tērzÄ“Å”anā.
  7. Programmētāji ir programmētāji, nevis profesionāli testētāji, un viņi nevar nodroÅ”ināt atbilstoÅ”u projektu testÄ“Å”anas kvalitāti
  8. JÅ«s esat pilnÄ«bā atbildÄ«gs par galÄ«go testÄ“Å”anu un ražoÅ”anas uzdevumu pieņemÅ”anu
  9. Ja mēs jau esam uzņēmuÅ”ies uzdevumu, mēs nevaram nekavējoties pārslēgties uz citiem, kamēr nepabeidzam paÅ”reizējo (pretējā gadÄ«jumā tas rada vēl vairāk kļūdu un palielina izstrādes laiku)
  10. Komandā ir mazāk cilvēku (atvaļinājumu vai slimību dēļ), bet darba ir vairāk un mums fiziski nebūs laika atbildēt uz visu, ko vēlaties
  11. Mēs lÅ«dzam jÅ«s veikt izvietoÅ”anu ražoÅ”anas versijā bez pārbaudÄ«tiem uzdevumiem izstrādātājā ā€” tas ir tikai jÅ«su risks, nevis izstrādātāji.
  12. Ja iestatāt neskaidrus uzdevumus, bez pareizas plūsmas, bez dizaina izkārtojumiem, tas no mums prasa daudz vairāk pūļu un ievieŔanas laika, jo mums jūsu vietā ir jāveic papildu darba apjoms.
  13. Jebkuri uzdevumi saistÄ«bā ar kļūdām bez detalizēta to raÅ”anās apraksta un ekrānuzņēmumiem nedod mums iespēju saprast, kas nogāja greizi un kā mēs varam Å”o kļūdu novērst.
  14. Projektam ir nepiecieÅ”ama pastāvÄ«ga pilnveidoÅ”ana un uzlabojumi, lai uzlabotu veiktspēju un droŔību. Tāpēc komanda daļu sava laika velta Å”iem uzlabojumiem
  15. Tā kā mums ir stundu virsstundas (steidzami labojumi), pārējās dienās tie ir jākompensē

Parasti klients uzreiz saprot, ka programmatÅ«ras izstrādē viss nav tik vienkārÅ”i, un ar vēlmi vien nepietiek.

Kopumā tas arÄ« viss. Aizkulisēs atstāju daudz sarunu un visu procesu sākotnējo atkļūdoÅ”anu, bet rezultātā viss izdevās. Varu teikt, ka Å”is process mums kļuva par sava veida ā€œSudraba lodiā€. Jauni cilvēki, kas ieradās projektā, jau no pirmās dienas varēja nekavējoties iesaistÄ«ties darbā, jo visi procesi bija aprakstÄ«ti, un dokumentācija un arhitektÅ«ra diagrammu veidā uzreiz sniedza priekÅ”statu par to, ko mēs visi Å”eit darām.

P.S. Vēlos precizēt, ka mūsu pusē projektu vadītāja nav. Tas ir klienta pusē. Nav nekāds tehniķis. Eiropas projekts. Visa saziņa notiek tikai angļu valodā.

Veiksmi visiem jūsu projektos. Neizdegies un centies uzlabot savus procesus.

Avots manējā emuāra ziņa.

Avots: www.habr.com