Sveiki, draugai. Gana dažnai, ypač perkant užsakomąsias paslaugas, matau tą patį vaizdą. Aiškios darbo eigos trūkumas komandose vykdant įvairius projektus.
Svarbiausia, kad programuotojai nesupranta, kaip bendrauti su klientu ir tarpusavyje. Kaip sukurti nuolatinį kokybiško produkto kūrimo procesą. Kaip planuoti savo darbo dieną ir sprintus.
Ir visa tai galiausiai lemia praleistus terminus, viršvalandžius, nuolatinius susirėmimus, kas kaltas, ir klientų nepasitenkinimą, kur ir kaip viskas juda. Gana dažnai visa tai lemia programuotojų ar net ištisų komandų kaitą. Kliento praradimas, reputacijos pablogėjimas ir pan.
Vienu metu aš tiesiog atsidūriau tokiame projekte, kuriame buvo visi šie malonumai.
Niekas nenorėjo prisiimti atsakomybės už projektą (didelė paslaugų prekyvietė), apyvarta buvo baisi, klientas tiesiog suplyšęs ir nusivylęs. Kartą prie manęs priėjo generalinis direktorius ir pasakė, kad turite reikiamos patirties, tai štai kortos jūsų rankose. Pasiimk projektą sau. Jei suklysi, uždarysime projektą ir visus išvarysime. Tai pasiteisins, bus šaunu, tada vadovauk ir vystyk, kaip tau atrodo tinkama. Dėl to tapau projekto komandos vadovu ir viskas krito ant mano pečių.
Pirmas dalykas, kurį padariau, buvo nuo nulio sukurti darbo eigą, kuri atitiko mano tuometinę viziją, ir parašiau komandos darbo aprašymą. Jį įgyvendinti nebuvo lengva. Tačiau per mėnesį ar daugiau viskas susitvarkė, kūrėjai ir klientas priprato, viskas vyko tyliai ir patogiai. Norėdamas parodyti komandai, kad tai ne tik „audra arbatos puodelyje“, o tikra išeitis iš situacijos, prisiėmiau maksimalią atsakomybę, pašalindama iš komandos nemalonią rutiną.
Jau praėjo pusantrų metų, o projektas vystosi be viršvalandžių, be „žiurkių lenktynių“ ir visokio streso. Vieni senajame kolektyve nenorėjo taip dirbti ir išėjo, kiti, atvirkščiai, labai apsidžiaugė, kad atsirado skaidrios taisyklės. Bet galiausiai visi komandos nariai yra labai motyvuoti ir puikiai žino didžiulį projektą, įskaitant ir priekinę, ir užpakalinę dalį. Įskaitant kodo bazę ir visą verslo logiką. Netgi pasiekėme, kad nesame tik „irkluotojai“, o patys sugalvojame daug verslo procesų ir naujų funkcijų, kurios, pasirodo, patinka verslui.
Dėl tokio mūsų požiūrio klientas nusprendė užsisakyti kitą prekyvietę iš mūsų įmonės, o tai yra gera žinia.
Kadangi tai veikia mano projekte, galbūt tai taip pat kam nors padės. Taigi, pats procesas, kuris padėjo mums išsaugoti projektą:
Komandinio darbo procesas projekte „Mano mėgstamiausias projektas“
a) Vidinis komandos procesas (tarp kūrėjų)
- Visi klausimai kuriami Jira sistemoje
- Kiekviena užduotis turi būti aprašyta kiek įmanoma išsamiau ir atlikti griežtai vieną veiksmą
- Bet kuri funkcija, jei ji pakankamai sudėtinga, yra suskirstyta į daug smulkių užduočių
- Komanda dirba su funkcijomis kaip viena užduotimi. Pirmiausia visi kartu dirbame ties viena funkcija, siunčiame ją išbandyti, tada imamės kitos.
- Kiekviena užduotis yra pažymėta užpakalinei arba priekinei sistemai
- Yra užduočių ir klaidų tipų. Turite juos teisingai nurodyti.
- Atlikus užduotį, ji perkeliama į kodo peržiūros būseną (šiuo atveju kolegai sukuriama ištraukimo užklausa)
- Užduotį atlikęs asmuo iš karto seka šiai užduočiai skirtą laiką.
- Patikrinęs kodą, PR patvirtins, o po to tas, kuris atliko šią užduotį, savarankiškai sujungia jį į pagrindinį filialą, o po to pakeičia jo būseną į paruoštą diegti dev serveryje.
- Visas užduotis, paruoštas diegti dev serveryje, diegia komandos vadovas (jo atsakomybės sritis), kartais komandos narys, jei kas nors yra skubu. Po įdiegimo visos užduotys nuo paruoštos diegti iki kūrėjo perkeliamos į būseną – paruoštos testavimui dev.
- Visas užduotis išbando klientas
- Kai klientas išbando užduotį programuotoje, jis perkelia ją į būseną, parengtą diegti gamyboje
- Diegimui į gamybą turime atskirą filialą, kuriame pagrindinį sujungiame tik prieš dislokavimą
- Jei testavimo metu klientas randa klaidų, jis grąžina užduotį taisyti, nustatydamas jos būseną kaip grąžintą taisyti. Taip atskiriame naujas užduotis nuo tų, kurios neišlaikė testavimo.
- Dėl to visos užduotys nuo sukūrimo iki užbaigimo: Užduotis → Kuriama → Kodo peržiūra → Paruoštas diegti į dev → QA dev → (Grįžti į kūrėją) → Paruoštas diegti gamyboje → QA gaminant → Atlikta
- Kiekvienas kūrėjas savo kodą išbando savarankiškai, taip pat ir kaip svetainės vartotojas. Neleidžiama sujungti šakos su pagrindine, nebent tiksliai žinoma, kad kodas veikia.
- Kiekviena užduotis turi prioritetus. Prioritetus nustato klientas arba komandos vadovas.
- Kūrėjai pirmiausia atlieka prioritetines užduotis.
- Kūrėjai gali priskirti užduotis vieni kitiems, jei sistemoje buvo aptiktos skirtingos klaidos arba viena užduotis susideda iš kelių specialistų darbo.
- Visos užduotys, kurias sukuria klientas, atitenka komandos vadovui, kuris jas įvertina ir paprašo kliento jas pakeisti arba priskiria vienam iš komandos narių.
- Visos užduotys, kurios yra paruoštos diegti kūrėjams arba gamintojams, taip pat perduodamos komandos vadovui, kuris savarankiškai nustato, kada ir kaip atlikti diegimą. Po kiekvieno diegimo komandos vadovas (arba komandos narys) turi apie tai pranešti klientui. Taip pat pakeiskite užduočių būsenas į paruoštas testavimui dev/cont.
- Kiekvieną dieną tuo pačiu laiku (mums tai 12.00 val.) rengiame visų komandos narių susirinkimą
- Visi susirinkimo dalyviai, įskaitant komandos vadovą, praneša apie tai, ką veikė vakar ir ką planuoja daryti šiandien. Kas neveikia ir kodėl. Taip visa komanda žino, kas ką daro ir kokioje stadijoje yra projektas. Tai suteikia mums galimybę numatyti ir prireikus koreguoti savo sąmatas ir terminus.
- Susitikime komandos vadovas taip pat kalba apie visus projekto pokyčius ir esamų klaidų, kurių klientas nerado, lygį. Visos klaidos yra išrūšiuojamos ir priskiriamos kiekvienam komandos nariui, kad jas išspręstų.
- Susitikimo metu komandos vadovas kiekvienam žmogui paskirsto užduotis, atsižvelgdamas į esamą kūrėjų darbo krūvį, jų profesinio pasirengimo lygį, taip pat atsižvelgdamas į konkrečios užduoties artumą tam, ką šiuo metu daro kūrėjas.
- Susitikime komandos vadovas parengia bendrą architektūros ir verslo logikos strategiją. Po to visa komanda tai aptaria ir nusprendžia pakoreguoti arba priimti šią strategiją.
- Kiekvienas kūrėjas savarankiškai rašo kodą ir kuria algoritmus pagal vieną architektūrą ir verslo logiką. Kiekvienas gali išsakyti savo įgyvendinimo viziją, bet niekas nieko neverčia daryti taip ir ne kitaip. Kiekvienas sprendimas yra pagrįstas. Jei yra geresnis sprendimas, bet dabar tam nėra laiko, tada riebaluose sukuriama užduotis būsimam tam tikros kodo dalies pertvarkymui.
- Kai kūrėjas imasi užduoties, jis perkelia ją į kūrimo būseną. Visas bendravimas dėl užduoties išaiškinimo su klientu tenka kūrėjo pečiams. Techninius klausimus galima užduoti komandos vadovui arba kolegoms.
- Jei kūrėjas nesupranta užduoties esmės, o klientas negalėjo jos aiškiai paaiškinti, jis pereina prie kitos užduoties. O komandos vadovas paima dabartinį ir aptaria jį su klientu.
- Kiekvieną dieną kūrėjas turėtų rašyti kliento pokalbyje apie tai, kokias užduotis jis dirbo vakar ir kokias užduotis dirbs šiandien
- Darbo procesas vyksta pagal Scrum. Viskas suskirstyta į sprintus. Kiekvienas sprintas trunka dvi savaites.
- Sprintus kuria, užpildo ir uždaro komandos vadovas.
- Jeigu projektas turi griežtus terminus, tuomet stengiamės apytiksliai įvertinti visas užduotis. Ir mes juos sujungėme į sprintą. Jei klientas bando į sprintą įtraukti daugiau užduočių, mes nustatome prioritetus ir kai kurias kitas užduotis perkeliame į kitą sprintą.
b) Darbo su klientu procesas
- Kiekvienas kūrėjas gali ir turi bendrauti su klientu
- Klientui negalima leisti primesti savo žaidimo taisyklių. Klientui reikia mandagiai ir draugiškai suprasti, kad esame savo srities specialistai ir tik mes privalome kurti darbo procesus ir įtraukti į juos klientą
- Idealiu atveju, prieš pradedant diegti bet kokią funkciją, būtina sukurti viso funkcijos (darbo eigos) loginio proceso schemą. Ir nusiųskite jį klientui patvirtinti. Tai taikoma tik sudėtingoms ir neaiškioms funkcijoms, pavyzdžiui, mokėjimo sistemai, pranešimų sistemai ir kt. Tai leis mums tiksliau suprasti, ko tiksliai klientui reikia, išsaugoti dokumentaciją funkcijai, o taip pat apsidrausti nuo to, kad klientas ateityje gali pasakyti, kad mes nepadarėme to, ko jis prašė.
- Visos diagramos / schemos / logika ir kt. Jį išsaugome Confluence/Fat, kur prašome kliento komentaruose patvirtinti būsimo diegimo teisingumą.
- Stengiamės neapkrauti kliento techninėmis detalėmis. Jeigu mums reikia supratimo, kaip to nori klientas, tai struktūrinės schemos pavidalu braižome primityvius algoritmus, kuriuos klientas gali suprasti ir pats viską pataisyti/pakeisti.
- Jei klientas projekte aptinka klaidą, prašome ją labai išsamiai aprašyti „Žira“. Kokiomis aplinkybėmis tai įvyko, kada, kokią veiksmų seką atliko užsakovas testavimo metu. Pridėkite ekrano kopijas.
- Stengiamės kiekvieną dieną, daugiausiai kas antrą dieną, diegti kūrėjo serveryje. Tada klientas pradeda testuoti funkcionalumą ir projektas nestovi be darbo. Kartu tai užsakovui yra ženklas, kad projektas yra visiškai kuriamas ir niekas jam nepasakoja pasakų.
- Dažnai atsitinka taip, kad klientas iki galo nesuvokia, ko jam reikia. Nes kuria sau naują verslą, su procesais, kurie dar nėra nusistovėję. Todėl labai dažna situacija, kai ištisas kodo dalis išmetame į šiukšliadėžę ir perkuriame programos logiką. Iš to išplaukia, kad neturėtumėte absoliučiai visko atlikti testais. Tikslinga testais aprėpti tik esmines funkcijas, o tada tik išlygas.
- Būna situacijų, kai komanda supranta, kad nesilaikome terminų. Tada atliekame greitą užduočių auditą ir nedelsiant apie tai informuojame klientą. Kaip išeitį iš situacijos siūlome laiku paleisti svarbias ir svarbias funkcijas, o likusias palikti po išleidimo.
- Jei klientas pradeda sugalvoti įvairias užduotis iš galvos, pradeda fantazuoti ir aiškinti pirštais, tada mes prašome jo pateikti mums puslapio išdėstymą ir logikos srautą, kuris turėtų visiškai apibūdinti viso maketo elgesį ir jos elementai.
- Prieš imdamiesi bet kokios užduoties, turime įsitikinti, kad ši funkcija buvo įtraukta į mūsų sutarties/sutarties sąlygas. Jei tai nauja funkcija, kuri neapsiriboja mūsų pradiniais susitarimais, turime nustatyti šios funkcijos kainą ((numatomas užbaigimo laikas + 30%) x 2) ir nurodyti klientui, kad mums prireiks tiek laiko, kol ją užbaigsime, ir terminas perkeliamas iš numatomo laiko, padauginto iš dviejų. Užduotį atlikime greičiau – puiku, iš to naudos bus visi. Jei ne, tada mes jus pasirūpinome.
c) Ko mes nepriimame komandoje:
- Neįsipareigojimas, ramybės stoka, užmaršumas
- „Šerti pusryčius“. Jei negalite atlikti užduoties ir nežinote, kaip tai padaryti, turite nedelsiant apie tai pranešti komandos vadovui, o ne laukti paskutinės minutės.
- Žmogaus, kuris dar neįrodė savo galimybių ir profesionalumo, antakiai ir pasigyrimai. Jeigu pasitvirtina, vadinasi, padorumo ribose įmanoma :)
- Apgaulė visomis jos formomis. Jei užduotis nebaigta, neturėtumėte pakeisti jos būsenos į baigtą ir kliento pokalbyje rašykite, kad ji paruošta. Sugedo kompiuteris, sugedo sistema, šuo kramtė nešiojamąjį kompiuterį – visa tai nepriimtina. Jeigu įvyksta tikras force majeure įvykis, apie tai reikia nedelsiant pranešti komandos vadovui.
- Kai specialistas visą laiką neprisijungęs ir darbo valandomis jį sunku pasiekti.
- Toksiškumas komandoje neleidžiamas! Jei kas nors su kuo nors nesutinka, tada visi susirenka į mitingą ir diskutuoja bei sprendžia.
Ir keletas klausimų/tezių, kurių kartais užduodu savo klientui, kad išsiaiškintų visus nesusipratimus:
- Kokie yra jūsų kokybės kriterijai?
- Kaip nustatyti, ar projektas turi problemų, ar ne?
- Pažeidus visas mūsų rekomendacijas ir patarimus dėl sistemos keitimo/tobulinimo, visą riziką prisiimate tik jūs
- Bet kokie dideli projekto pakeitimai (pavyzdžiui, visi papildomi srautai) gali sukelti klaidų (kurias mes, žinoma, ištaisysime)
- Neįmanoma per porą minučių suprasti, kokia problema iškilo projekte, o tuo labiau - nedelsiant ją išspręsti
- Dirbame ties konkretaus produkto srautu (Tasks in Zhira – Kūrimas – Testavimas – Diegimas). Tai reiškia, kad negalime atsakyti į visą užklausų ir skundų srautą pokalbyje.
- Programuotojai yra programuotojai, o ne profesionalūs testuotojai ir negali užtikrinti tinkamos projekto testavimo kokybės
- Atsakomybė už galutinį bandymą ir gamybos užduočių priėmimą tenka tik jums
- Jei jau ėmėmės užduoties, negalime iš karto pereiti prie kitų, kol nebaigsime esamos (kitaip atsiranda dar daugiau klaidų ir pailgėja kūrimo laikas)
- Komandoje mažiau žmonių (dėl atostogų ar ligų), bet darbo daugiau ir fiziškai nespėsime atsakyti į viską, ko norite
- Mes prašome jūsų įdiegti gamybinę versiją be išbandytų užduočių kūrimo priemonėje – tai tik jūsų rizika, o ne kūrėjai
- Kai nustatote neaiškias užduotis, be teisingo srauto, be dizaino išdėstymo, tai reikalauja iš mūsų daug daugiau pastangų ir įgyvendinimo laiko, nes mes turime atlikti papildomą darbą vietoj jūsų
- Bet kokios užduotys, susijusios su klaidomis, be išsamaus jų atsiradimo aprašymo ir ekrano kopijų, nesuteikia mums galimybės suprasti, kas nutiko ir kaip galime ištaisyti šią klaidą
- Siekiant pagerinti našumą ir saugą, projektą reikia nuolat tobulinti ir tobulinti. Todėl komanda dalį savo laiko skiria šiems patobulinimams
- Dėl to, kad turime viršvalandžių pagal valandas (skubūs pataisymai), kitomis dienomis juos privalome kompensuoti
Paprastai klientas iš karto supranta, kad programinės įrangos kūrime viskas nėra taip paprasta, o vien noro aiškiai neužtenka.
Apskritai, tai viskas. Daug derybų ir pirminio visų procesų derinimo palieku užkulisiuose, bet dėl to viskas pavyko. Galiu pasakyti, kad šis procesas mums tapo savotiška „Sidabrine kulka“. Nauji žmonės, atėję į projektą, galėjo iš karto įsitraukti į darbą nuo pat pirmos dienos, nes buvo aprašyti visi procesai, o dokumentacija ir architektūra schemų pavidalu iš karto leido suprasti, ką mes visi čia veikiame.
PS Norėčiau patikslinti, kad mūsų pusėje projektų vadovo nėra. Tai yra kliento pusėje. Visai ne technikas. Europos projektas. Visas bendravimas vyksta tik anglų kalba.
Sėkmės visiems jūsų projektuose. Nepersistenkite ir stenkitės pagerinti savo procesus.
Šaltinis mano .
Šaltinis: www.habr.com