🥇Tööprotsessi korraldamine meeskonnas IT projektil

Tere, sõbrad. Üsna sageli, eriti allhanke puhul, näen sama pilti. Selge töövoo puudumine erinevate projektide meeskondades.

Kõige tähtsam on see, et programmeerijad ei mõista, kuidas kliendiga ja omavahel suhelda. Kuidas luua pidev protsess kvaliteetse toote arendamiseks. Kuidas planeerida oma tööpäeva ja sprinte.

Ja kõige selle tagajärjeks on lõpuks rikutud tähtajad, ületunnid, pidevad etteheited, kes on süüdi, ja klientide rahulolematus – kuhu ja kuidas kõik liigub. Üsna sageli viib see kõik programmeerijate ja isegi tervete meeskondade vahetumiseni. Kliendi kaotus, maine halvenemine ja nii edasi.

Omal ajal sattusin just sellisesse projekti, kus olid kõik need naudingud.

Keegi ei tahtnud projekti eest vastutada (suur teenindusturg), käive oli kohutav, klient muudkui rebis ja viskas. Tegevjuht pöördus kuidagi minu poole ja ütles, et teil on vajalik kogemus olemas, nii et teil on kaardid käes. Võtke projekt enda jaoks. Kui ajad sassi, paneme projekti kinni ja lööme kõik välja. See selgub, see on lahe, siis juhtige seda ja arendage seda oma äranägemise järgi. Selle tulemusena sai minust projekti meeskonnajuht ja kõik langes minu õlgadele.

Esimese asjana kavandasin nullist töövoo, mis ühtis minu tollase nägemusega ja kirjutasin meeskonnale ametijuhendi. Selle rakendamine ei olnud lihtne. Aga kuskil kuu ajaga kõik paika loksus, arendajad ja klient harjusid ära ning kõik läks vaikselt ja mugavalt. Näitamaks meeskonnale, et see pole lihtsalt torm klaasis, vaid reaalne väljapääs olukorrast, võtsin enda peale maksimaalselt kohustusi, eemaldades meeskonnalt ebameeldiva rutiini.

Poolteist aastat on juba möödas ja projekt areneb ilma ületundideta, ilma “rottide võidujooksude” ja igasuguste pingeteta. Keegi vanas meeskonnas ei tahtnud niimoodi töötada ja lahkus, vastupidi, keegi sattus tõesti sellesse, et ilmusid läbipaistvad reeglid. Kuid selle tulemusel on kõik meeskonnaliikmed väga motiveeritud ja tunnevad tohutut projekti täielikult nii esi- kui ka tagaosaga. Sealhulgas nii koodibaasi kui ka kogu äriloogika. On jõutud isegi selleni, et me pole lihtsalt “sõudjad”, vaid mõtleme ise välja palju äriprotsesse ja uusi funktsioone, mis ettevõttele meeldivad.

Tänu meiepoolsele lähenemisele otsustas klient tellida meie ettevõttelt teise turu, mis on hea uudis.

Kuna see töötab minu projektis, siis võib-olla on sellest ka kellelegi abi. Niisiis, protsess ise, mis aitas meil projekti salvestada:

Projekti "Minu lemmikprojekt" meeskonnatöö protsess

a) Meeskonnaprotsessis (arendajate vahel)

Kõik ülesanded luuakse Jira süsteemis
Iga ülesannet tuleks võimalikult palju kirjeldada ja teha rangelt üks toiming.
Iga funktsioon, kui see on piisavalt keeruline, jagatakse paljudeks väikesteks ülesanneteks
Meeskond töötab funktsioonide kallal ühe ülesandena. Esiteks teeme koos ühe funktsiooni, anname selle testimiseks, seejärel võtame järgmise.
Iga ülesanne on märgistatud tausta- või esiprogrammi jaoks
On erinevaid ülesandeid ja vigu. Peate need õigesti täpsustama.
Pärast ülesande täitmist viiakse see üle koodi ülevaatuse olekusse (selle kolleegile luuakse tõmbetaotlus)
See, kes ülesande täitis, jälgib kohe selle ülesande täitmiseks kuluvat aega
Pärast koodi kontrollimist kinnitatakse PR ja pärast seda liidab selle ülesande iseseisvalt täitja selle põhiharusse, misjärel muudab selle oleku arendusserverisse juurutamiseks valmis.
Kõik arendusserverisse juurutamiseks valmis olevad ülesanded juurutab meeskonna juht (tema vastutusala), mõnikord meeskonnaliige, kui midagi on kiireloomuline. Pärast juurutamist viiakse kõik ülesanded juurutamiseks valmis kuni arendajani üle olekusse – valmis arenduses testimiseks
Kõik ülesanded on kliendi poolt testitud
Kui klient on ülesande arendajas testinud, edastab ta selle tootmisse juurutamiseks valmisolekusse.
Tootmisse juurutamiseks on meil eraldi filiaal, kus liidame masteri vahetult enne juurutamist
Kui klient leiab testimise käigus vigu, tagastab ta ülesande ülevaatamiseks, määrates selle oleku ülevaatamiseks tagastatud. Nii eraldame uued ülesanded nendest, mida pole testitud.
Selle tulemusel jõuavad kõik ülesanded loomisest lõpetamiseni: teha → Arenduses → Koodi ülevaatus → Valmis juurutamiseks arendajasse → Kvaliteet arendajasse → (Tagasi arendaja juurde) → Valmis juurutamiseks tootmisse → Kvaliteet tootmises → Valmis
Iga arendaja testib oma koodi iseseisvalt, sealhulgas saidi kasutajana. Filiaali liitmine põhiharuga ei ole lubatud, välja arvatud juhul, kui on kindlalt teada, et kood töötab.
Igal ülesandel on prioriteedid. Prioriteedid määrab kas klient või meeskonnajuht.
Arendajad teevad esmalt prioriteetsed ülesanded.
Arendajad saavad üksteisele ülesandeid määrata, kui süsteemis leiti erinevaid vigu või üks ülesanne koosneb mitme spetsialisti tööst.
Kõik kliendi loodud ülesanded saadetakse meeskonnajuhile, kes neid hindab ja kas palub kliendil need lõplikult vormistada või määrab need mõnele meeskonnaliikmele.
Kõik ülesanded, mis on valmis juurutamiseks arendajale või tootmisele, jõuavad ka meeskonna juhini, kes määrab iseseisvalt, millal ja kuidas juurutada. Pärast iga kasutuselevõttu peab meeskonnajuht (või meeskonnaliige) sellest klienti teavitama. Ja muutke ka ülesannete olekuid testimiseks valmis dev / prod.
Iga päev samal kellaajal (meil kell 12.00) teeme ralli kõigi meeskonnaliikmete vahel
Kõik rallil osalejad, sealhulgas meeskonna juht, arutavad, mida ta eile tegi, mida ta täna teha plaanib. Mis ei tööta ja miks. Seega on kogu meeskond kursis sellega, kes mida teeb ja mis etapis projekt on. See annab meile võimaluse prognoosida ja vajadusel korrigeerida oma hinnanguid ja tähtaegu.
Koosolekul annab meeskonnajuht teada ka kõikidest projekti muudatustest ja hetke vigade tasemest, mida klient ei leidnud. Kõik vead sorteeritakse ja määratakse igale meeskonnaliikmele nende lahendamiseks.
Miitingul jagab meeskonna juht igaühele ülesanded, võttes arvesse arendajate hetkekoormust, erialase ettevalmistuse taset ning arvestades ka konkreetse ülesande lähedust arendaja poolt hetkel tehtavale.
Koosolekul töötab meeskonnajuht välja üldise arhitektuuri ja äriloogika strateegia. Pärast seda arutab kogu meeskond seda ja otsustab, kas teha kohandusi või võtta see strateegia kasutusele.
Iga arendaja kirjutab koodi ja koostab algoritme iseseisvalt ühe arhitektuuri ja äriloogika raames. Igaüks võib väljendada oma nägemust rakendamisest, kuid keegi ei sunni kedagi tegema seda nii ja mitte teisiti. Iga otsus on õigustatud. Kui on olemas parem lahendus, aga praegu pole selleks aega, siis luuakse rasvas ülesanne, teatud koodiosa edaspidiseks ümbertöötamiseks.
Kui arendaja võtab ülesande enda peale, viib ta selle arendusolekusse. Kogu suhtlus kliendiga ülesande selgitamise osas langeb arendaja õlgadele. Tehnilisi küsimusi saab esitada meeskonna juhile või kolleegidele.
Kui arendaja ei saa ülesande olemusest aru ja klient ei osanud seda mõistlikult selgitada, jätkab ta järgmise ülesandega. Ja meeskonna juht võtab praeguse ja arutab seda kliendiga.
Iga päev peaks arendaja kirjutama kliendi vestlusse, milliste ülesannetega ta eile töötas ja milliste ülesannetega täna töötab
Töövoog põhineb Scrumil. Kõik on jagatud sprintideks. Iga sprint kestab kaks nädalat.
Sprintide loob, täidab ja sulgeb meeskonna juht.
Kui projektil on ranged tähtajad, siis püüame kõik ülesanded umbkaudselt hinnata. Ja me kogume neilt sprindi. Kui klient proovib sprindile rohkem ülesandeid lisada, siis paneme paika prioriteedid ja osad muud ülesanded kanname üle järgmisele sprindile.

b) Kliendiga töötamise protsess

Iga arendaja saab ja peabki kliendiga suhtlema
Te ei saa lubada kliendil oma mängureegleid kehtestada. Kliendile on vaja viisakalt ja sõbralikult selgeks teha, et oleme oma ala spetsialistid ning ainult meie peaksime üles ehitama tööprotsesse ja kaasama neisse klienti
Ideaalis on vaja enne mis tahes funktsionaalsuse juurutamist luua funktsiooni (töövoo) kogu loogilise protsessi vooskeem. Ja saatke see kliendile kinnituseks. See kehtib ainult keerukate ja mitte ilmsete funktsioonide kohta, näiteks maksesüsteem, teavitussüsteem jne. See võimaldab teil täpsemalt aru saada, mida klient täpselt vajab, salvestada funktsiooni dokumentatsiooni ning kindlustada end ka selle vastu, et klient võib tulevikus öelda, et me ei teinud seda, mida ta palus.
Kõik diagrammid/vooskeemid/loogika jne. salvestame Confluence/Fati, kus palume kliendil kommentaarides kinnitada tulevase teostuse õigsust.
Püüame mitte koormata klienti tehniliste detailidega. Kui vajame arusaama sellest, kuidas klient soovib, siis koostame primitiivsed algoritmid vooskeemi kujul, millest klient saab aru ja kõike ise parandada/muuta.
Kui klient leiab projektis vea, siis palume seda Fatis väga detailselt kirjeldada. Mis asjaoludel see tekkis, millal, millise toimingute jada klient testimise käigus läbi viis. Palun lisage ekraanipildid.
Püüame iga päev, maksimaalselt ülepäeviti, juurutada arendusserverisse. Seejärel hakkab klient funktsionaalsust testima ja projekt ei seisa jõude. Samas on see tellija jaoks marker, et projekt on täies mahus arendusjärgus ja keegi ei räägi talle muinasjutte.
Tihti juhtub, et klient ei saa täielikult aru, mida ta üldse vajab. Kuna ta loob enda jaoks uue ettevõtte protsessidega, mida pole veel silutud. Seetõttu on väga levinud olukord, kus me viskame terved koodijupid prügikasti ja kujundame ümber rakenduse loogika. Sellest järeldub, et absoluutselt kõike ei ole vaja testidega katta. Testidega on mõttekas katta ainult kriitilised funktsionaalsused ja seejärel broneeringud.
On olukordi, kus meeskond mõistab, et me ei mahu tähtaegadesse. Seejärel viime läbi ülesannete kiire auditi ja teavitame sellest koheselt klienti. Olukorrast väljapääsuna soovitame olulised ja kriitilised funktsioonid õigeaegselt käivitada ning jätta ülejäänu väljalaskejärgseks ajaks.
Kui klient hakkab peast erinevaid ülesandeid välja mõtlema, hakkab fantaseerima ja näpuga seletama, siis palume tal esitada meile lehepaigutus ja loogikaga voog, mis peaks täielikult kirjeldama kogu küljenduse ja selle käitumist. elemendid.
Enne mis tahes ülesande täitmist peame veenduma, et see funktsioon sisaldub meie lepingu/lepingu tingimustes. Kui see on uus funktsioon, mis ületab meie esialgseid kokkuleppeid, siis peame kindlasti seda funktsiooni hindama ((ligikaudne teostusaeg + 30%) x 2) ja andma kliendile teada, et selle valmimine võtab meil nii palju aega, lisaks tähtaega nihutatakse arvestusliku aja võrra, mis on korrutatud kahega. Teeme ülesande kiiremaks – suurepärane, kõik saavad sellest ainult kasu. Kui ei, siis oleme kindlustatud.

c) Mida me meeskonnas ei aktsepteeri:

Ebajärjekindlus, ebajärjekindlus, unustamine
"Hommikusöötmine". Kui te ei saa ülesannet täita, te ei tea, kuidas, peate sellest kohe meeskonnajuhile teatama ja mitte ootama viimaseni.
Brovadas ja hoopleb mehelt, kes pole veel oma võimeid ja professionaalsust teoga tõestanud. Kui see tõestatakse, siis on see sündsuse piirides võimalik 🙂
Pettus kõigis selle ilmingutes. Kui ülesanne ei ole lõpetatud, siis ärge muutke selle olekut lõpetatuks ja kirjutage kliendi vestlusesse, et see on valmis. Arvuti jooksis kokku, süsteem jooksis kokku, koer näris sülearvutit – kõik see on vastuvõetamatu. Tõelise vääramatu jõu ilmnemisel tuleb sellest koheselt teavitada meeskonna juhti.
Kui spetsialist on kogu aeg võrgust väljas ja teda on tööajal raske kätte saada.
Toksilisus meeskonnas ei ole lubatud! Kui keegi millegagi ei nõustu, siis kogunevad kõik koos miitingule ja arutavad ning otsustavad.

Ja mitmed küsimused / teesid, mida ma mõnikord oma kliendilt küsin, et kõik arusaamatused kõrvaldada:

Millised on teie kvaliteedikriteeriumid?
Kuidas teha kindlaks, kas projektil on probleeme või mitte?
Kui rikute kõiki meie soovitusi ja nõuandeid süsteemi muutmise/parandamise kohta, kannate kõik riskid ainult teie
Kõik suuremad projektimuudatused (näiteks igasugused lisavood) võivad põhjustada vigu (mille me loomulikult parandame)
Mõne minutiga on võimatu aru saada, milline probleem projektis ilmnes, ja veelgi enam, et seda kohe seal parandada
Töötame konkreetse tootevoo kallal (Tasks in Zhira – Arendamine – Testing – Deploy). See tähendab, et me ei saa vastata kogu vestluse taotluste ja kaebuste voogudele.
Programmeerijad on lihtsalt programmeerijad, mitte professionaalsed testijad ega suuda tagada projekti testimise nõuetekohast kvaliteeti
Vastutus lõpliku testimise ja müügiülesannete vastuvõtmise eest lasub täielikult teil
Kui oleme ülesande juba võtnud, siis ei saa me kohe teistele üle minna enne, kui oleme praeguse ülesande täitnud (muidu põhjustab see veelgi rohkem vigu ja arendusaja pikenemist)
Meeskonnas on vähem inimesi (puhkuse või haiguste tõttu) ja tööd on rohkem ning meil pole füüsiliselt aega kõigele, mida soovid, vastata
Tootmisprotsessi juurutamine ilma arendaja testitud ülesanneteta on ainult teie, mitte arendaja risk
Kui seate hägused ülesanded, ilma õige voo, ilma kujunduspaigutusteta, nõuab see meilt palju rohkem pingutust ja juurutusaega, kuna peame teie asemel tegema lisatööd.
Kõik vigadega seotud ülesanded, ilma nende esinemise üksikasjaliku kirjelduseta ja ekraanipiltideta, ei anna meile võimalust aru saada, mis valesti läks ja kuidas seda viga väljastada
Projekt nõuab jõudluse ja ohutuse parandamiseks pidevat viimistlemist ja täiustamist. Seetõttu kulutab meeskond osa oma ajast nendele täiustustele.
Seoses sellega, et meil on ületunde (kiireparandused), peame need kompenseerima teistel päevadel

Reeglina saab klient kohe aru, et tarkvaraarenduses pole kõik nii lihtne ja soovist üksi selgelt ei piisa.

Üldiselt on see kõik. Kulisside taha jätan palju läbirääkimisi ja kõigi protsesside esialgset silumist, kuid selle tulemusena sai kõik korda. Võin öelda, et sellest protsessist on saanud meie jaoks omamoodi “Hõbekuul”. Uued inimesed, kes projekti tulid, said end kohe esimesest päevast peale tööle panna, sest kõik protsessid on kirjeldatud ning dokumentatsioon ja arhitektuur diagrammidena andis kohe aimu, millega me kõik tegeleme. siin.

PS Tahan selgitada, et meie poolel ei ole projektijuhti. See on kliendi poolel. Pole üldse tehnikamees. Euroopa projekt. Kogu suhtlus toimub ainult inglise keeles.

Edu kõigile teie projektides. Ärge põlege läbi ja proovige oma protsesse parandada.

allikas minu ajaveeb.

Allikas: www.habr.com

IT-projekti töövoo korraldamine meeskonnas