🥇 Skipulag vinnuflæðis í teymi í upplýsingatækniverkefni

Hæ vinir. Oft, sérstaklega í útvistun, sé ég sömu myndina. Skortur á skýru vinnuflæði í teymum við ýmis verkefni.

Það mikilvægasta er að forritarar skilja ekki hvernig á að eiga samskipti við viðskiptavininn og hver við annan. Hvernig á að byggja upp stöðugt ferli við að þróa gæðavöru. Hvernig á að skipuleggja vinnudaginn og spretti.

Og allt þetta leiðir að lokum til brotinna tímafresta, yfirvinnu, stöðugra uppgjörs um hverjum er um að kenna og óánægju viðskiptavina - hvert og hvernig allt er á hreyfingu. Oft leiðir þetta allt til þess að skipta um forritara og jafnvel heilu teymi. Tap á viðskiptavinum, rýrnun á orðspori og svo framvegis.

Einhvern tíma fór ég bara í svona verkefni, þar sem allt þetta unað var.

Enginn vildi taka ábyrgð á verkefninu (stór þjónustumarkaður), veltan var hræðileg, viðskiptavinurinn bara rifnaði og henti. Forstjórinn leitaði einhvern veginn til mín og sagði að þú hefðir nauðsynlega reynslu, svo þú ert með spilin í höndunum. Taktu verkefnið fyrir þig. Ef þú klúðrar, munum við loka verkefninu og reka alla út. Það kemur í ljós, það verður flott, leiddu það síðan og þróaðu það eins og þér sýnist. Í kjölfarið varð ég liðsstjóri í verkefninu og allt féll á mínar herðar.

Það fyrsta sem ég gerði var að hanna verkflæði frá grunni sem passaði við mína sýn á þeim tíma og skrifaði starfslýsingu fyrir teymið. Það var ekki auðvelt að koma því í framkvæmd. En einhvers staðar innan mánaðar lagaðist allt, verktaki og viðskiptavinur venjast þessu og allt fór rólega og þægilega fram. Til að sýna liðinu að þetta er ekki bara stormur í glasi, heldur raunveruleg leið út úr stöðunni, tók ég á mig hámarksábyrgð og fjarlægði óþægilegu rútínuna úr liðinu.

Eitt og hálft ár er þegar liðið og verkefnið þróast án yfirvinnu, án „rottukapphlaupa“ og alls kyns álags. Einhver í gamla liðinu vildi ekki vinna svona og fór, þvert á móti lenti einhver virkilega í því að gagnsæjar reglur birtust. En fyrir vikið eru allir í teyminu mjög áhugasamir og þekkja stóra verkefnið til fulls, bæði með framhlið og bakhlið. Þar með talið bæði kóðagrunninn og alla viðskiptarökfræði. Það er meira að segja komið að því að við erum ekki bara „róarar“ heldur komum við sjálf með marga viðskiptaferla og nýja eiginleika sem fyrirtækinu líkar við.

Þökk sé þessari nálgun af okkar hálfu ákvað viðskiptavinurinn að panta annan markaðstorg frá fyrirtækinu okkar, sem eru góðar fréttir.

Þar sem þetta virkar á verkefninu mínu, gæti það líka hjálpað einhverjum. Svo, ferlið sjálft, sem hjálpaði okkur að bjarga verkefninu:

Ferlið við teymisvinnu við verkefnið „Uppáhaldsverkefnið mitt“

a) Innan hópferlis (milli þróunaraðila)

Öll verkefni eru búin til í Jira kerfinu
Lýsa skal hverju verkefni eins mikið og mögulegt er og framkvæma nákvæmlega eina aðgerð.
Sérhver eiginleiki, ef hann er nógu flókinn, er skipt í mörg lítil verkefni
Teymið vinnur að eiginleikum sem eitt verkefni. Fyrst gerum við einn eiginleika saman, gefum hann til prófunar og tökum síðan þann næsta.
Hvert verkefni er merkt fyrir bakenda eða framenda
Það eru tegundir af verkefnum og villur. Þú þarft að tilgreina þær rétt.
Eftir að verkefninu er lokið er það flutt yfir í kóða endurskoðunarstöðu (uppdráttarbeiðni er búin til fyrir samstarfsmann þess)
Sá sem kláraði verkefnið rekur strax tíma sinn fyrir þetta verkefni
Eftir að hafa athugað kóðann er PR samþykktur og eftir það sameinar sá sem framkvæmdi þetta verkefni það sjálfstætt í aðalútibúið, eftir það breytir það stöðu sinni í tilbúið til dreifingar á þróunarþjóninn.
Öll verkefni tilbúin til að dreifa á þróunarþjóninn eru sett af liðsstjóranum (ábyrgðarsviði hans), stundum liðsmanni, ef eitthvað er brýnt. Eftir dreifingu eru öll verkefni frá tilbúin til dreifingar yfir í dev flutt yfir í stöðuna - tilbúin til prófunar á dev
Öll verkefni eru prófuð af viðskiptavini
Þegar viðskiptavinurinn hefur prófað verkefnið á dev, flytur hann það í stöðuna tilbúið til dreifingar í framleiðslu.
Fyrir dreifingu í framleiðslu höfum við sérstaka útibú þar sem við sameinum meistarann rétt fyrir dreifinguna
Ef viðskiptavinurinn finnur villur meðan á prófun stendur, þá skilar hann verkefninu til endurskoðunar og setur stöðu þess aftur til endurskoðunar. Þannig aðskiljum við ný verkefni frá þeim sem ekki hafa verið prófuð.
Þar af leiðandi fara öll verkefni frá sköpun til að ljúka: Að gera → Í þróun → Kóðaskoðun → Tilbúinn dreifing á þróunaraðila → QA á þróun → (Aftur í þróun) → Tilbúinn dreifing í framleiðslu → QA á framleiðslu → Lokið
Hver verktaki prófar kóðann sinn sjálfstætt, þar á meðal sem notandi síðunnar. Ekki er leyfilegt að sameina útibú við aðalgreinina nema vitað sé með vissu að kóðinn virki.
Hvert verkefni hefur forgangsröðun. Forgangsröðun er annaðhvort sett af viðskiptavininum eða liðsstjóranum.
Hönnuðir sinna forgangsverkefnum fyrst.
Hönnuðir geta úthlutað verkefnum hver á annan ef mismunandi villur fundust í kerfinu eða eitt verkefni samanstendur af vinnu nokkurra sérfræðinga.
Öll verkefni sem viðskiptavinurinn býr til eru send til teymisstjórans sem metur þau og biður viðskiptavininn annaðhvort um að ganga frá þeim eða úthlutar þeim til eins liðsmanna.
Öll verkefni sem eru tilbúin til að dreifa til þróunar eða framkalla koma einnig til liðsstjórans, sem ákveður sjálfstætt hvenær og hvernig á að dreifa. Eftir hverja dreifingu verður liðsstjóri (eða liðsmaður) að tilkynna viðskiptavininum um þetta. Og breyttu líka stöðunum fyrir verkefni í tilbúið til prófunar á dev / prod.
Alla daga á sama tíma (við höfum það kl. 12.00) höldum við rall á milli allra liðsmanna
Allir á rallinu segja frá, líka liðsstjórinn, hvað hann gerði í gær, hvað hann ætlar að gera í dag. Hvað virkar ekki og hvers vegna. Þannig er allt teymið meðvitað um hver er að gera hvað og á hvaða stigi verkefnið er. Þetta gefur okkur tækifæri til að spá fyrir um og aðlaga, ef nauðsyn krefur, áætlanir okkar og tímafresti.
Á fundinum tilkynnir teymisstjórinn einnig allar breytingar á verkefninu og magn núverandi galla sem ekki fundust af viðskiptavininum. Allar villur eru flokkaðar og úthlutað til hvers liðsmanns til að leysa þær.
Á fundinum úthlutar teymisstjóri verkefnum fyrir hvern og einn, að teknu tilliti til núverandi vinnuálags þróunaraðila, fagmenntunarstigs þeirra og einnig með hliðsjón af nálægð tiltekins verkefnis við það sem verktaki er að gera núna.
Á fundinum mótar teymisstjóri almenna stefnu fyrir arkitektúr og viðskiptarökfræði. Að því loknu ræðir allt teymið þetta og ákveður hvort gera eigi lagfæringar eða taka upp þessa stefnu.
Hver þróunaraðili skrifar kóða og byggir sjálfstætt reiknirit innan einnar byggingarlistar og viðskiptarökfræði. Það geta allir tjáð sína sýn á framkvæmdina en það er enginn að neyða neinn til að gera þetta með þessum hætti og ekki öðruvísi. Sérhver ákvörðun er réttmæt. Ef það er betri lausn, en núna er enginn tími fyrir hana, þá er verkefni búið til í fitu, til framtíðar endurþáttunar á ákveðnum hluta kóðans.
Þegar verktaki tekur að sér verkefni færir hann það í þróunarstöðu. Öll samskipti varðandi skýringu á verkefninu við viðskiptavininn falla á herðar framkvæmdaraðila. Hægt er að spyrja tæknilegra spurninga til liðsstjóra eða samstarfsmanna.
Ef verktaki skilur ekki kjarna verkefnisins og viðskiptavinurinn gat ekki útskýrt það á skynsamlegan hátt, þá heldur hann áfram í næsta verkefni. Og liðsstjórinn tekur núverandi og ræðir það við viðskiptavininn.
Á hverjum degi ætti verktaki að skrifa í spjall viðskiptavinarins um hvaða verkefni hann vann í gær og hvaða verkefni hann mun vinna í dag
Verkflæðið er byggt á Scrum. Öllu er skipt í spretti. Hver sprettur tekur tvær vikur.
Sprettir eru búnir til, fylltir og lokaðir af liðstjóra.
Ef verkefnið hefur stranga tímafresti þá reynum við að áætla öll verkefni gróflega. Og við söfnum frá þeim spretti. Ef viðskiptavinurinn reynir að bæta við fleiri verkefnum á sprettinn þá setjum við forgangsröðun og flytjum önnur verkefni yfir á næsta sprett.

b) Ferlið við að vinna með viðskiptavininum

Hver verktaki getur og ætti að hafa samskipti við viðskiptavininn
Þú getur ekki leyft viðskiptavinum að setja sínar eigin leikreglur. Nauðsynlegt er á kurteislegan og vinsamlegan hátt að gera viðskiptavinum ljóst að við erum sérfræðingar á okkar sviði og við eigum einungis að byggja upp verkferla og taka viðskiptavininn inn í þá.
Það er nauðsynlegt, helst, áður en haldið er áfram með innleiðingu einhverrar virkni, að búa til flæðirit yfir allt rökrétt ferli fyrir eiginleika (verkflæði). Og sendu það til viðskiptavinarins til staðfestingar. Þetta á aðeins við um flókna og ekki augljósa virkni, til dæmis greiðslukerfi, tilkynningakerfi o.s.frv. Þetta gerir þér kleift að skilja nákvæmlega hvað viðskiptavinurinn þarfnast, vista skjölin fyrir eiginleikann og einnig tryggja þig gegn því að viðskiptavinurinn gæti sagt í framtíðinni að við gerðum ekki það sem hann bað um.
Allar skýringarmyndir/flæðirit/rökfræði o.s.frv. við vistum í Confluence/Fat þar sem við biðjum viðskiptavininn í athugasemdum að staðfesta réttmæti framtíðarútfærslunnar.
Við reynum að íþyngja viðskiptavininum ekki með tæknilegum upplýsingum. Ef við þurfum skilning á því hvernig viðskiptavinurinn vill, þá teiknum við frumstæð reiknirit í formi flæðirits sem viðskiptavinurinn getur skilið og lagað / breytt öllu sjálfur.
Ef viðskiptavinurinn finnur galla í verkefninu, þá biðjum við þig um að lýsa því í smáatriðum í Fat. Við hvaða aðstæður gerðist það, hvenær, hvaða röð aðgerða var framkvæmt af viðskiptavinum við prófun. Vinsamlegast hengdu skjámyndir við.
Við reynum á hverjum degi, hámark annan hvern dag, að dreifa á þróunarþjóninn. Viðskiptavinurinn byrjar þá að prófa virknina og verkefnið er ekki aðgerðalaust. Um leið er þetta merki fyrir viðskiptavininn um að verkefnið sé í fullri þróun og enginn sé að segja honum ævintýri.
Það kemur oft fyrir að viðskiptavinurinn skilur ekki alveg hvað hann þarfnast. Þar sem hann býr til nýtt fyrirtæki fyrir sjálfan sig, með ferlum sem hafa ekki enn verið kembiforrit. Þess vegna er mjög algengt tilfelli þegar við hendum heilum kóðabútum í ruslið og endurmótum rökfræði forritsins. Af þessu leiðir að það er ekki nauðsynlegt að ná nákvæmlega öllu með prófum. Það er skynsamlegt að ná aðeins yfir mikilvæga virkni með prófunum og síðan með fyrirvara.
Það eru aðstæður þar sem liðið áttar sig á því að við göngum ekki inn í tímamörk. Síðan gerum við hraða úttekt á verkefnunum og upplýsum viðskiptavininn strax um það. Sem leið út úr stöðunni mælum við með því að ræsa mikilvæga og mikilvæga virkni á réttum tíma og láta afganginn eftir til útgáfu.
Ef viðskiptavinurinn byrjar að koma með önnur verkefni frá höfðinu á sér, byrjar að fantasera og útskýra á fingrum sínum, þá biðjum við hann um að útvega okkur síðuuppsetningu og flæði með rökfræði sem ætti að lýsa hegðun alls skipulagsins og þess að fullu. þættir.
Áður en við tökumst á við verkefni verðum við að ganga úr skugga um að þessi eiginleiki hafi verið innifalinn í skilmálum samningsins / samningsins. Ef þetta er nýr eiginleiki sem fer út fyrir upphaflega samninga okkar, þá verðum við örugglega að áætla þennan eiginleika ((áætlaður leiðtími + 30%) x 2) og gefa viðskiptavinum til kynna að það muni taka okkur svo mikinn tíma að klára hann, auk frestur er færður fyrir áætlunartíma margfaldað með tveimur. Gerum verkefnið hraðari - frábært, allir munu bara græða á þessu. Ef ekki, þá erum við tryggð.

c) Það sem við samþykkjum ekki í liðinu:

Ósamræmi, ósamræmi, gleymska
"Morgunmatur". Ef þú getur ekki klárað verkefnið, þú veist ekki hvernig, þá þarftu að tilkynna liðsstjóranum strax um þetta og ekki bíða þangað til það síðasta.
Brovada og hrósa sér af manni sem hefur ekki enn sannað hæfileika sína og fagmennsku með verki. Ef það er sannað, þá er það mögulegt, innan marka velsæmis 🙂
Svik í öllum sínum birtingarmyndum. Ef verkefninu er ekki lokið, þá ættir þú ekki að breyta stöðu þess í lokið og skrifa í spjall viðskiptavinarins að það sé tilbúið. Tölvan hrundi, kerfið hrundi, hundurinn tuggði fartölvuna - allt er þetta óviðunandi. Ef raunverulegt óviðráðanlegt óviðráðanlegt ástand á sér stað skal strax tilkynna liðsstjóranum.
Þegar sérfræðingur er ótengdur allan tímann og erfitt er að ná í hann á vinnutíma.
Eiturhrif í liðinu eru ekki leyfð! Ef einhver er ósammála einhverju, þá koma allir saman til samkomu og ræða og ákveða.

Og fjöldi spurninga / ritgerða sem ég bið viðskiptavin minn stundum að eyða öllum misskilningi:

Hver eru gæðaviðmiðin þín?
Hvernig ákveður þú hvort verkefni hafi vandamál eða ekki?
Ef þú brýtur í bága við allar ráðleggingar okkar og ráðleggingar um að breyta/bæta kerfið, eru allar áhættur eingöngu á þér
Allar meiriháttar verkefnisbreytingar (til dæmis alls kyns aukaflæði) munu leiða til hugsanlegrar útlits galla (sem við munum að sjálfsögðu laga)
Það er ómögulegt að skilja innan nokkurra mínútna hvers konar vandamál kom upp í verkefninu, og enn frekar að laga það þar
Við vinnum að ákveðnu vöruflæði (Tasks in Zhira - Development - Testing - Deploy). Þetta þýðir að við getum ekki svarað öllu flæði beiðna og kvartana í spjallinu.
Forritarar eru bara forritarar, ekki faglegir prófarar, og geta ekki tryggt rétt gæði verkefnaprófa
Ábyrgð á lokaprófun og viðtöku verkefna við sölu er alfarið hjá þér
Ef við höfum þegar tekið að okkur verkefni, þá getum við ekki skipt strax yfir í aðra fyrr en við lýkur núverandi verkefni (annars leiðir þetta til enn fleiri villu og aukins þróunartíma)
Það eru færri í teyminu (vegna fría eða veikinda) og það er meiri vinna og við munum ekki hafa líkamlega tíma til að bregðast við öllu sem þú vilt
Að biðja þig um að dreifa til framleiðslu án prófaðra verkefna á dev er aðeins þín áhætta, ekki þróunaraðilans
Þegar þú setur upp óljós verkefni, án rétts flæðis, án hönnunaruppsetninga, þá krefst þetta miklu meiri fyrirhafnar og framkvæmdatíma frá okkur, þar sem við þurfum að vinna aukavinnu í stað þín
Öll verkefni á villum, án nákvæmrar lýsingar á tilviki þeirra og skjámynda, gefa okkur ekki tækifæri til að skilja hvað fór úrskeiðis og hvernig við getum sent frá okkur þessa villu
Verkefnið krefst stöðugrar betrumbóta og endurbóta til að bæta frammistöðu og öryggi. Því eyðir liðið hluta af tíma sínum í þessar endurbætur.
Vegna þess að við höfum yfirvinnutíma (brýnar lagfæringar) verðum við að bæta fyrir þá aðra daga

Að jafnaði skilur viðskiptavinurinn strax að allt er ekki svo einfalt í hugbúnaðarþróun og löngunin ein er greinilega ekki nóg.

Almennt séð er þetta allt. Á bak við tjöldin skil ég eftir miklar samningaviðræður og fyrstu kembiforrit allra ferla, en þar af leiðandi gekk allt upp. Ég get sagt að þetta ferli hafi orðið eins konar „Silver Bullet“ fyrir okkur. Nýtt fólk sem kom að verkefninu gátu þegar í stað virkjuð til starfa frá fyrsta degi, þar sem öllum ferlum er lýst og skjöl og arkitektúr í formi skýringarmynda gaf strax hugmynd um hvað við erum öll að gera hér.

PS Ég vil taka það fram að það er enginn verkefnastjóri á okkar hlið. Það er á hlið viðskiptavinarins. Alls ekki tæknimaður. Evrópuverkefni. Öll samskipti eru eingöngu á ensku.

Gangi ykkur öllum vel í verkefnum ykkar. Ekki brenna út og reyna að bæta ferla þína.

heimild í mínum bloggfærsla.

Heimild: www.habr.com