🥇Työnkulun organisointi tiimissä IT-projektissa

Hei ystävät. Varsinkin ulkoistamisessa näen melko usein saman kuvan. Selkeän työnkulun puute tiimeissä eri projekteissa.

Tärkeintä on, että ohjelmoijat eivät ymmärrä miten kommunikoida asiakkaan ja toistensa kanssa. Kuinka rakentaa jatkuva prosessi laadukkaan tuotteen kehittämiseksi. Kuinka suunnitella työpäiväsi ja sprintit.

Ja kaikki tämä johtaa lopulta määräaikojen rikkoutumiseen, ylityöhön, jatkuvaan syyllisen selvittelyyn ja asiakkaiden tyytymättömyyteen - missä ja miten kaikki liikkuu. Melko usein kaikki tämä johtaa ohjelmoijien ja jopa kokonaisten ryhmien vaihtamiseen. Asiakkaan menetys, maineen heikkeneminen ja niin edelleen.

Kerran pääsin juuri sellaiseen projektiin, jossa oli kaikkia näitä herkkuja.

Kukaan ei halunnut ottaa vastuuta projektista (iso palvelumarkkinapaikka), liikevaihto oli kauhea, asiakas vain repi ja heitti. Toimitusjohtaja jotenkin lähestyi minua ja sanoi, että sinulla on tarvittava kokemus, joten sinulla on kortit käsissäsi. Ota projekti itsellesi. Jos sotket, lopetamme projektin ja potkaisemme kaikki ulos. Se osoittautuu, se on siistiä, sitten johda sitä ja kehitä sitä parhaaksi katsomallasi tavalla. Tuloksena minusta tuli projektin tiiminvetäjä ja kaikki putosi harteilleni.

Ensimmäinen asia, jonka tein, oli suunnitella alusta alkaen työnkulku, joka vastasi silloista näkemystäni ja kirjoitin tehtävänkuvauksen tiimille. Sen toteuttaminen ei ollut helppoa. Mutta jossain kuukaudessa kaikki asettui, kehittäjät ja asiakas tottuivat siihen ja kaikki sujui hiljaa ja mukavasti. Osoittaakseni joukkueelle, että tämä ei ole vain myrsky lasissa, vaan todellinen ulospääsy tilanteesta, otin suurimman mahdollisen määrän vastuuta poistamalla joukkueelta epämiellyttävän rutiinin.

Puolitoista vuotta on jo kulunut, ja projekti kehittyy ilman ylitöitä, ilman "rottakilpailuja" ja kaikenlaista stressiä. Joku vanhassa tiimissä ei halunnut työskennellä niin ja lähti, päinvastoin, joku todella joutui siihen, että avoimet säännöt ilmestyivät. Mutta sen seurauksena kaikki tiimin jäsenet ovat erittäin motivoituneita ja tietävät valtavan projektin kokonaisuudessaan sekä etu- että takapään kanssa. Sisältää sekä koodipohjan että kaiken liiketoimintalogiikan. On jopa tullut siihen pisteeseen, että emme ole vain "soutujia", vaan keksimme itse monia liiketoimintaprosesseja ja uusia ominaisuuksia, joista yritys pitää.

Tämän lähestymistavan ansiosta asiakas päätti tilata yritykseltämme toisen markkinapaikan, mikä on hyvä uutinen.

Koska tämä toimii projektissani, ehkä se auttaa myös jotakuta. Joten itse prosessi, joka auttoi meitä pelastamaan projektin:

Ryhmätyöprosessi projektissa "Lempiprojektini"

a) Tiimiprosessissa (kehittäjien välillä)

Kaikki tehtävät luodaan Jira-järjestelmässä
Jokainen tehtävä tulee kuvata mahdollisimman tarkasti ja suorittaa tiukasti yksi toiminto.
Mikä tahansa ominaisuus, jos se on tarpeeksi monimutkainen, jaetaan moniin pieniin tehtäviin
Tiimi käsittelee ominaisuuksia yhtenä tehtävänä. Ensin teemme yhdessä yhden ominaisuuden, annamme sen testattavaksi ja sitten otamme seuraavan.
Jokainen tehtävä on nimetty tausta- tai käyttöliittymäksi
On erilaisia tehtäviä ja bugeja. Sinun on määritettävä ne oikein.
Kun tehtävä on suoritettu, se siirretään koodintarkistustilaan (kollegalle luodaan vetopyyntö)
Tehtävän suorittanut seuraa välittömästi tähän tehtävään kuluvaa aikaa
Koodin tarkistuksen jälkeen PR hyväksytään ja sen jälkeen tämän tehtävän suorittanut yhdistää sen itsenäisesti päähaaraan, minkä jälkeen se muuttaa tilansa valmiiksi käyttöönotettavaksi dev-palvelimelle.
Tiimin johtaja (hänen vastuualueensa), joskus tiimin jäsen ottaa käyttöön kaikki kehityspalvelimelle asennettavat tehtävät, jos jokin on kiireellistä. Käyttöönoton jälkeen kaikki tehtävät valmiista käyttöönottoon kehittäjäksi siirretään tilaan – valmis testattavaksi kehittäjällä
Kaikki tehtävät ovat asiakkaan testaamia
Kun asiakas on testannut tehtävän kehittäjällä, hän siirtää sen tilaan valmis käyttöön otettavaksi tuotantoon.
Tuotantokäyttöä varten meillä on erillinen haara, jossa yhdistämme masterin juuri ennen käyttöönottoa
Jos asiakas havaitsee testauksen aikana vikoja, hän palauttaa tehtävän tarkistettavaksi asettamalla sen tilan tarkistettavaksi. Näin erotamme uudet tehtävät niistä, joita ei ole testattu.
Seurauksena on, että kaikki tehtävät etenevät luomisesta loppuun: Tehtävä → Kehityksessä → Kooditarkistus → Valmis käyttöönotto kehittäjälle → Laadunvarmistus kehittäjässä → (Palaa kehittäjälle) → Käyttövalmis tuotantoon → Laadunvarmistus tuotannossa → Valmis
Jokainen kehittäjä testaa koodiaan itsenäisesti, myös sivuston käyttäjänä. Haaraa ei saa yhdistää päähaaraan, ellei ole varmuudella tiedossa, että koodi toimii.
Jokaisella tehtävällä on prioriteetit. Prioriteetit asettaa joko asiakas tai tiiminvetäjä.
Kehittäjät tekevät ensisijaiset tehtävät ensin.
Kehittäjät voivat jakaa tehtäviä toisilleen, jos järjestelmästä löytyy erilaisia vikoja tai yksi tehtävä koostuu useiden asiantuntijoiden työstä.
Kaikki asiakkaan luomat tehtävät lähetetään tiiminvetäjälle, joka arvioi ne ja joko pyytää asiakasta viimeistelemään ne tai antaa ne jollekin tiimin jäsenelle.
Kaikki tehtävät, jotka ovat valmiita käyttöönotettavaksi kehittäjälle tai tuotteelle, saapuvat myös tiiminvetäjälle, joka päättää itsenäisesti, milloin ja miten otetaan käyttöön. Jokaisen käyttöönoton jälkeen ryhmänjohtajan (tai tiimin jäsenen) on ilmoitettava tästä asiakkaalle. Muuta myös tehtävien tilat valmiiksi testattavaksi dev/prod-versiossa.
Joka päivä samaan aikaan (meillä on klo 12.00) pidämme rallin kaikkien joukkueen jäsenten välillä
Kaikki rallissa, mukaan lukien joukkueenjohtaja, raportoivat, mitä hän teki eilen, mitä hän aikoo tehdä tänään. Mikä ei toimi ja miksi. Näin ollen koko tiimi on tietoinen siitä, kuka tekee mitä ja missä vaiheessa projekti on. Tämä antaa meille mahdollisuuden ennakoida ja tarvittaessa muuttaa arvioimme ja määräaikojamme.
Kokouksessa tiiminvetäjä kertoo myös kaikista projektin muutoksista ja nykyisten bugien tason, joita asiakas ei löytänyt. Kaikki virheet selvitetään ja osoitetaan jokaiselle tiimin jäsenelle ratkaisemaan ne.
Rallissa tiiminvetäjä jakaa kullekin tehtävät ottaen huomioon kehittäjien nykyisen työmäärän, ammatillisen koulutuksen tason ja myös tietyn tehtävän läheisyyden kehittäjän parhaillaan tekemiseen.
Kokouksessa tiiminvetäjä kehittää yleistä strategiaa arkkitehtuurille ja liiketoimintalogiikalle. Sen jälkeen koko tiimi keskustelee tästä ja päättää, tehdäänkö muutoksia vai omaksutaanko tämä strategia.
Jokainen kehittäjä kirjoittaa koodia ja rakentaa algoritmeja itsenäisesti yhden arkkitehtuurin ja liiketoimintalogiikan sisällä. Jokainen voi ilmaista näkemyksensä toteutuksesta, mutta kukaan ei pakota ketään tekemään näin eikä toisin. Jokainen päätös on perusteltu. Jos on olemassa parempi ratkaisu, mutta nyt siihen ei ole aikaa, niin rasvaan luodaan tehtävä tietyn koodin osan tulevaa refaktorointia varten.
Kun kehittäjä ottaa tehtävän, hän siirtää sen kehitystilaan. Kaikki viestintä tehtävän selventämisestä asiakkaan kanssa on kehittäjän harteilla. Teknisiä kysymyksiä voi esittää ryhmänjohtajalle tai kollegoille.
Jos kehittäjä ei ymmärrä tehtävän olemusta, eikä asiakas pystynyt selittämään sitä järkevästi, hän siirtyy seuraavaan tehtävään. Ja tiiminvetäjä ottaa nykyisen ja keskustelee siitä asiakkaan kanssa.
Joka päivä kehittäjän tulee kirjoittaa asiakkaan chatiin, mitä tehtäviä hän työskenteli eilen ja mitä tehtäviä hän työskentelee tänään
Työnkulku perustuu Scrum-järjestelmään. Kaikki on jaettu sprinteihin. Jokainen sprintti kestää kaksi viikkoa.
Sprintit luo, täyttää ja sulkee joukkueen johtaja.
Jos projektissa on tiukat määräajat, yritämme arvioida karkeasti kaikki tehtävät. Ja keräämme heiltä sprintin. Jos asiakas yrittää lisätä sprinttiin tehtäviä, asetamme prioriteetit ja siirrämme joitain muita tehtäviä seuraavaan sprinttiin.

b) Asiakkaan kanssa työskentelyprosessi

Jokainen kehittäjä voi ja sen tulee kommunikoida asiakkaan kanssa
Et voi antaa asiakkaan määrätä omia pelisääntöjään. Asiakkaalle on kohteliaasti ja ystävällisesti tehtävä selväksi, että olemme alamme asiantuntijoita ja vain meidän tulee rakentaa työprosesseja ja ottaa asiakas mukaan niihin.
Ihannetapauksessa on tarpeen luoda vuokaavio koko ominaisuuden (työnkulun) loogisesta prosessista ennen minkään toiminnon toteuttamista. Ja lähetä se asiakkaalle vahvistusta varten. Tämä koskee vain monimutkaisia ja ei ilmeisiä toimintoja, esimerkiksi maksujärjestelmää, ilmoitusjärjestelmää jne. Näin voit ymmärtää tarkemmin mitä asiakas tarkalleen tarvitsee, tallentaa ominaisuuden dokumentaation ja myös vakuuttaa itsesi siltä varalta, että asiakas saattaa tulevaisuudessa sanoa, että emme tehneet sitä, mitä hän pyysi.
Kaikki kaaviot/vuokaaviot/logiikka jne. säästämme Confluence/Fatissa, jossa pyydämme asiakasta kommenteissa vahvistamaan tulevan toteutuksen oikeellisuuden.
Pyrimme olemaan rasittamatta asiakasta teknisillä yksityiskohdilla. Jos tarvitsemme ymmärrystä siitä, miten asiakas haluaa, piirrämme alkukantaisia algoritmeja vuokaavion muodossa, joita asiakas voi ymmärtää ja korjata/muokata kaikkea itse.
Jos asiakas löytää projektista vian, pyydämme sinua kuvailemaan sitä erittäin yksityiskohtaisesti Fatissa. Missä olosuhteissa se tapahtui, milloin, minkä toimintosarjan asiakas suoritti testauksen aikana. Liitä kuvakaappaukset.
Yritämme ottaa käyttöön kehityspalvelimelle joka päivä, korkeintaan joka toinen päivä. Asiakas alkaa sitten testata toimivuutta, eikä projekti ole lepotilassa. Samalla tämä on asiakkaalle merkki siitä, että projekti on täydessä kehityksessä eikä kukaan kerro hänelle satuja.
Usein käy niin, että asiakas ei täysin ymmärrä, mitä hän tarvitsee. Koska hän luo itselleen uuden yrityksen prosesseilla, joita ei ole vielä korjattu. Siksi hyvin yleinen tapaus on, kun heitämme kokonaisia koodinpätkiä roskakoriin ja muokkaamme sovelluslogiikkaa. Tästä seuraa, että kaikkea ei tarvitse kattaa testeillä. On järkevää kattaa vain kriittiset toiminnot testeillä ja sitten varauksilla.
On tilanteita, jolloin tiimi tajuaa, ettemme mahdu määräaikaan. Sitten teemme tehtävien nopean auditoinnin ja ilmoitamme siitä välittömästi asiakkaalle. Pääsynä tilanteesta suosittelemme tärkeiden ja kriittisten toimintojen käynnistämistä ajoissa ja loput jättämistä julkaisun jälkeen.
Jos asiakas alkaa keksiä erilaisia tehtäviä omasta päästään, alkaa haaveilla ja selittää sormillaan, niin pyydämme häntä toimittamaan meille sivuasettelun ja logiikan, jonka pitäisi kuvata täydellisesti koko asettelun ja sen käyttäytymistä. elementtejä.
Ennen kuin ryhdymme mihinkään tehtäviin, meidän on varmistettava, että tämä ominaisuus on sisällytetty sopimukseemme. Jos tämä on uusi ominaisuus, joka ylittää alkuperäiset sopimuksemme, meidän on ehdottomasti arvioitava tämä ominaisuus ((likimääräinen läpimenoaika + 30 %) x 2) ja ilmoitettava asiakkaalle, että sen toteuttaminen vie meiltä niin paljon aikaa. määräaikaa siirretään arvioitulle ajalle kerrottuna kahdella. Tehdään tehtävästä nopeampi - hienoa, kaikki vain hyötyvät tästä. Jos ei, olemme vakuutettuja.

c) Mitä emme hyväksy joukkueessa:

Epäjohdonmukaisuus, epäjohdonmukaisuus, unohtaminen
"Aamiainen syöminen". Jos et voi suorittaa tehtävää, et tiedä miten, sinun on ilmoitettava tästä välittömästi ryhmänjohtajalle, eikä odota viimeiseen asti.
Brovada ja kehuminen henkilöltä, joka ei ole vielä todistanut kykyjään ja ammattitaitoaan teolla. Jos todistetaan, niin se on mahdollista säädyllisyyden rajoissa 🙂
Petos kaikissa ilmenemismuodoissaan. Jos tehtävää ei ole suoritettu loppuun, älä muuta sen tilaa valmiiksi ja kirjoita asiakkaan chattiin, että se on valmis. Tietokone kaatui, järjestelmä kaatui, koira pureskeli kannettavaa tietokonetta - kaikkea tätä ei voida hyväksyä. Jos tapahtuu todellinen ylivoimainen este, ryhmänjohtajalle on ilmoitettava välittömästi.
Kun asiantuntija on koko ajan offline-tilassa ja häntä on vaikea tavoittaa työaikana.
Myrkyllisyys joukkueessa ei ole sallittua! Jos joku on jostain eri mieltä, niin kaikki kokoontuvat mielenosoitukseen keskustelemaan ja päättämään.

Ja joukko kysymyksiä / teesejä, joita joskus pyydän asiakkaaltani poistamaan kaikki väärinkäsitykset:

Mitkä ovat laatukriteerisi?
Kuinka selvittää, onko projektissa ongelmia vai ei?
Jos rikot kaikkia suosituksiamme ja neuvojamme järjestelmän muuttamisesta/parannuksesta, kaikki riskit ovat vain sinun vastuullasi
Kaikki suuret projektimuutokset (esimerkiksi kaikenlaiset ylimääräiset virtaukset) johtavat mahdollisiin virheiden ilmaantumiseen (jotka tietysti korjaamme)
On mahdotonta ymmärtää muutamassa minuutissa, minkälainen ongelma projektissa tapahtui, ja vielä enemmän korjata se siellä
Työskentelemme tietyn tuotevirran parissa (Tasks in Zhira - Development - Testing - Deploy). Tämä tarkoittaa, että emme voi vastata koko chatissa oleviin pyyntöihin ja valituksiin.
Ohjelmoijat ovat vain ohjelmoijia, eivät ammattitestaajia, eivätkä voi taata projektitestauksen asianmukaista laatua
Vastuu lopputestauksesta ja myyntitehtävien hyväksymisestä on täysin sinulla
Jos olemme jo ottaneet tehtävän, emme voi heti siirtyä muihin, ennen kuin saamme nykyisen valmiiksi (muuten tämä johtaa vielä enemmän virheisiin ja pidentyy kehitysaikaan)
Ryhmässä on vähemmän ihmisiä (lomien tai sairauksien vuoksi), ja työtä on enemmän, eikä meillä ole fyysisesti aikaa vastata kaikkeen mitä haluat
Se, että pyydät sinua ottamaan käyttöön tuotantoon ilman testattuja tehtäviä kehittäjällä, on vain sinun riskisi, ei kehittäjän
Kun asetat sumeita tehtäviä, ilman oikeaa kulkua, ilman suunnittelun asetteluja, tämä vaatii meiltä paljon enemmän vaivaa ja toteutusaikaa, koska meidän on tehtävä enemmän työtä sinun sijaan
Kaikki bugeihin liittyvät tehtävät, ilman niiden esiintymisen yksityiskohtaista kuvausta ja kuvakaappauksia, eivät anna meille mahdollisuutta ymmärtää, mikä meni pieleen ja kuinka voimme lähettää tämän virheen
Projekti vaatii jatkuvaa jalostusta ja parannuksia suorituskyvyn ja turvallisuuden parantamiseksi. Siksi tiimi käyttää osan ajastaan näihin parannuksiin.
Koska meillä on ylitöitä (kiireet korjaukset), meidän on korvattava ne muina päivinä

Yleensä asiakas ymmärtää heti, että ohjelmistokehityksessä kaikki ei ole niin yksinkertaista, eikä pelkkä halu selvästikään riitä.

Yleisesti ottaen tässä on kaikki. Kulissien taakse jätän paljon neuvotteluja ja kaikkien prosessien alkuperäisen virheenkorjauksen, mutta tuloksena kaikki sujui. Voin sanoa, että tästä prosessista on tullut meille eräänlainen "Silver Bullet". Projektiin tulleet uudet ihmiset pystyivät jo heti ensimmäisestä päivästä lähtien valjastamaan itsensä töihin, sillä kaikki prosessit on kuvattu ja dokumentaatio ja arkkitehtuuri kaavioiden muodossa antoivat heti käsityksen siitä, mitä me kaikki teemme. tässä.

PS Haluan selventää, ettei puolellamme ole projektipäällikköä. Se on asiakkaan puolella. Ei ollenkaan teknikko. eurooppalainen hanke. Kaikki viestintä on vain englanniksi.

Onnea kaikille projekteihinne. Älä pala loppuun ja yritä parantaa prosessejasi.

lähde minun blogin viesti.

Lähde: will.com