Kako v 30 dneh vključiti namensko razvojno ekipo

Uvod

Večina pogodb o zunanjem izvajanju storitev propade že v prvem mesecu, ne šele v prvem letu. Inženirji so usposobljeni in cena je poštena, vendar ekipa tedne preživi brez dostopa, konteksta ali jasnih prednostnih nalog. Ko se delo končno začne, je naročnik že izgubil zaupanje v ta model.

Posebna razvojna ekipa lahko doseže polno produktivnost v 30 dneh, če se naročnik na to ustrezno pripravi. Izvajalec poskrbi za zaposlovanje in zaposlitvene postopke, vendar le naročnik lahko pojasni izdelek, kodno bazo in poslovne cilje. Vključevanje novih sodelavcev je skupni projekt, pri čemer večino prenosa znanja opravlja naročnikova stran.

Pred prvim dnem: kaj je treba pripraviti

Teden pred začetkom določa, kako hitro bo ekipa delovala. Inženirji, ki tri dni čakajo na dostop do repozitorija, izgubijo zagon, zamuda pa določi ton celotnega sodelovanja.

Priprava od naročnika zahteva nekaj ur dela. Večina tega je administrativnega značaja, celoten seznam pa lahko obdela ena oseba.

• Dostop in računi. Ustvarite račune za repozitorij kode, sistem za sledenje nalog, konzolo v oblaku in komunikacijske kanale. Pred začetkom preizkusite vsak prijavni podatke.
• Tehnična dokumentacija. Zberite arhitekturne diagrame, opise API-jev in navodila za nastavitev na enem mestu. Zastareli dokumenti so sprejemljivi, če nekdo označi, kaj se je spremenilo.
• Kontaktna oseba. Na strani naročnika določite eno osebo, ki bo odgovarjala na vprašanja v enem delovnem dnevu. Ta oseba je običajno tehnični vodja ali lastnik izdelka.
• Začetni seznam nalog. Pripravite 10 do 15 nalog nizke in srednje zahtevnosti. Ekipa potrebuje delo, ki jo seznani z kodno bazo, ne da bi ogrožala produkcijo.

1. teden: Dostop, kontekst in prve naloge

Prvi teden je namenjen orientaciji. Ekipa spozna, kaj produkt počne, kdo ga uporablja in kako je organizirana koda.

Rezultati v tem tednu so namerno skromni. Cilj je delovno okolje in prva združena sprememba, ne pa izdaja nove funkcije.

1.–2. dan: Nastavitev okolja

Prvi dan naročnik organizira uvodni klic. Lastnik izdelka pojasni poslovni model, glavne skupine uporabnikov in trenutne prioritete. Tehnični vodja predstavi arhitekturo in proces uvajanja.

Po sestanku inženirji vzpostavijo lokalna okolja in zaženejo aplikacijo. Večina težav pri vzpostavitvi se pojavi prav tu, zato mora biti kontaktna oseba pri naročniku na voljo za hitre odgovore.

Dnevi 3–5: Prve manjše naloge

Vsak inženir prevzame eno ali dve nalogi iz začetnega seznama. V tej fazi so primerne popravke napak, majhne spremembe v uporabniškem vmesniku in testiranje pokritosti. Pri tem se dotikajo dejanske kode, tveganje pa je nizko.

Vsaka naloga preide skozi celoten cikel pregleda kode, testiranja in uvajanja. To ekipi pokaže, kako deluje naročnik, in zgodaj razkrije vrzeli v procesu.

2. teden: Procesi in ritem komunikacije

V drugem tednu ekipa preide od posameznih nalog k ekipnim rutinam. Stranka in izvajalec se dogovorita o načinu načrtovanja, obravnavanja in poročanja o delu.

Razpršene ekipe potrebujejo več strukture kot tiste, ki delajo na istem mestu. Časovni pasovi in kulturne razlike otežujejo neformalno komunikacijo, zato mora biti ritem jasno določen.

• Dnevna srečanja. Organizirajte kratek klic v času, ki pokriva oba časovna pasova. Petnajst minut je dovolj za poročanje o stanju in ovirah.
• Načrtovanje sprintov. Načrtujte delo v eno- ali dvotedenskih sprintih. Lastnik izdelka na strani naročnika določi prioritete, ekipa pa oceni obseg dela.
• Pravila za pregled kode. Dogovorite se, kdo kaj pregleduje in kako hitro. Zamuda pri pregledu, daljša od enega dneva, upočasni celotno ekipo.
• Pisna poročila. Zahtevajte kratek tedenski povzetek v skupnem kanalu. To zainteresiranim stranem omogoča vpogled brez dodatnih sestankov.
• Postopek eskalacije. Določite, kdo na vsaki strani rešuje ovire. Vodja odnosov s strankami pri ponudniku obravnava težave ekipe, kontaktna oseba stranke pa vprašanja v zvezi s produktom.

3.–4. teden: Odgovornost in merjenje

V zadnjih dveh tednih se preveri, ali je vključevanje novih članov uspelo. Ekipa prevzame dejansko odgovornost, obe strani pa pregledata rezultate glede na jasna merila.

Ta faza tudi pokaže, kje je proces še treba prilagoditi. Majhne težave je lažje odpraviti na 25. dan kot na 90. dan.

Predaja dejanske funkcije

V tretjem tednu ekipi dodelite eno celovito funkcionalnost iz načrta razvoja izdelka. Ta naj zahteva odločitve glede zasnove, delo na več delih kodne baze in izdajo v produkcijo.

Tehnični vodja stranke pregleda tehnični pristop, preden se začne razvoj. Po tem je ekipa odgovorna za delo od ocene do uvedbe. Tesno nadzorovanje v tej fazi ni v skladu s ciljem.

Kazalniki, ki jih je treba spremljati na 30. dan

Ob koncu meseca organizirajte pregledni klic z izvajalcem. Primerjajte rezultate z pričakovanji, določenimi v prvem tednu, in kjer je mogoče, uporabite številke.

• Tempo izvedbe. Primerjajte načrtovane in izvedene točke zgodb v zadnjih dveh sprintih. Stabilen tempo je pomembnejši od visokega.
• Kakovost kode. Preverite delež zahtevkov za prevzem (pull requests), ki uspešno prestanejo pregled v prvem ali drugem krogu. Pogosto ponovno delo kaže na vrzeli v kontekstu.
• Število vprašanj. Sledite, kako pogosto inženirji prosijo stranko za pomoč. Število naj bi se vsak teden zmanjševalo.
• Povratne informacije deležnikov. Prosite lastnika izdelka in tehničnega vodjo za kratko oceno. Njihovo mnenje pogosto razkrije težave, ki jih kazalniki spregledajo.

Pogoste napake pri uvajanju

Večina zamud pri uvajanju ima iste vzroke. Podjetja jih ponavljajo, ker se vsak od njih na začetku zdi nepomemben.

• Pozni dostop. Računi, ki prispejo tretji dan, ekipo stanejo tri dni. Varnostna odobritve pogosto trajajo dlje, kot se pričakuje, zato jih začnite pravočasno.
• Pomanjkanje konteksta izdelka. Inženirji, ki ne razumejo uporabnikov, sprejemajo tehnično pravilne, a neuporabne odločitve. Ena ura razlage o izdelku prihrani tedne ponovnega dela.
• Preveč kontaktnih oseb. Ko navodila daje pet ljudi, pride do navzkrižja prioritet. En odločevalec ohranja jasno usmeritev.
• Obravnavanje ekipe kot zunanje. Ločeni kanali in omejena srečanja ustvarjajo dvostopenjsko strukturo. Ekipe, ki se vključijo v rutino naročnika, se hitreje integrirajo.

Zaključne misli

Trideset dni je dovolj, da posvečena ekipa doseže polno produktivnost. Rezultat je manj odvisen od ponudnika in bolj od tega, kako dobro stranka pripravi dostop, kontekst in jasne prioritete.

Vključevanje obravnavajte kot projekt z odgovornimi osebami, roki in končnim pregledom. Strukturiran prvi mesec gradi zaupanje, ki je potrebno za dolgoročno sodelovanje.