Kuinka ottaa käyttöön oma kehitystiimi 30 päivässä

Johdanto

Suurin osa ulkoistussopimuksista epäonnistuu jo ensimmäisen kuukauden aikana, ei ensimmäisen vuoden aikana. Insinöörit ovat päteviä ja hinta on kohtuullinen, mutta tiimi viettää viikkoja ilman pääsyä, taustatietoja tai selkeitä prioriteetteja. Kun työ vihdoin alkaa, asiakas on jo menettänyt luottamuksensa malliin.

Omistautunut kehitystiimi voi saavuttaa täyden tuottavuuden 30 päivän kuluessa, kun asiakas valmistautuu siihen. Palveluntarjoaja hoitaa rekrytoinnin ja työsuhteiden solmimisen, mutta vain asiakas voi selittää tuotteen, koodipohjan ja liiketoimintatavoitteet. Perehdytys on yhteinen projekti, ja suurin osa tiedon siirrosta tapahtuu asiakkaan puolelta.

Ennen ensimmäistä päivää: mitä valmistella

Aloituspäivää edeltävä viikko ratkaisee, kuinka nopeasti tiimi pääsee vauhtiin. Insinöörit, jotka joutuvat odottamaan kolme päivää pääsyä koodivarastoon, menettävät vauhtiaan, ja viivästys asettaa sävyn koko yhteistyölle.

Valmistelu vaatii asiakkaalta muutaman tunnin työtä. Suurin osa siitä on hallinnollista, ja yksi henkilö voi hoitaa koko tehtävälistan.

• Pääsy ja tilit. Luo tilit koodivarastolle, tehtävien seurantajärjestelmälle, pilvipalvelukonsolille ja viestintäkanaville. Testaa jokainen kirjautuminen ennen aloituspäivää.
• Tekninen dokumentaatio. Kerää arkkitehtuurikaaviot, API-kuvaukset ja asennusohjeet yhteen paikkaan. Vanhentuneet dokumentit kelpaavat, jos joku merkitsee niihin, mitä on muuttunut.
• Yhteyshenkilö. Nimeä asiakkaan puolelta yksi henkilö, joka vastaa kysymyksiin yhden työpäivän kuluessa. Tämä henkilö on yleensä tekninen johtaja tai tuoteomistaja.
• Alustava backlog. Valmistele 10–15 tehtävää, joiden monimutkaisuus on alhainen tai keskitasoinen. Tiimi tarvitsee tehtäviä, joiden avulla se oppii tuntemaan koodipohjaa ilman riskiä tuotantoympäristölle.

Viikko 1: Pääsy, tausta ja ensimmäiset tehtävät

Ensimmäinen viikko on perehdyttämistä. Tiimi oppii, mitä tuote tekee, kuka sitä käyttää ja miten koodi on järjestetty.

Tämän viikon tuotokset ovat tarkoituksella vähäisiä. Tavoitteena on toimiva ympäristö ja ensimmäinen yhdistetty muutos, ei uuden ominaisuuden julkaisu.

Päivät 1–2: Ympäristön asennus

Ensimmäisenä päivänä asiakas järjestää aloituskokouksen. Tuotevastaava selittää liiketoimintamallin, tärkeimmät käyttäjäryhmät ja nykyiset prioriteetit. Tekninen johtaja käy läpi arkkitehtuurin ja käyttöönottoprosessin.

Puhelun jälkeen insinöörit asettavat paikalliset ympäristöt ja ajavat sovellusta. Suurin osa asennusongelmista ilmenee tässä vaiheessa, joten asiakkaan yhteyshenkilön tulisi olla tavoitettavissa nopeiden vastausten antamiseksi.

Päivät 3–5: Ensimmäiset pienet tehtävät

Jokainen insinööri ottaa yhden tai kaksi tehtävää alkuperäisestä backlogista. Virhekorjaukset, pienet käyttöliittymän muutokset ja testauskattavuus sopivat hyvin tähän vaiheeseen. Niissä käsitellään todellista koodia, mutta riski on pieni.

Jokainen tehtävä käy läpi koko syklin, joka koostuu koodin tarkistuksesta, testauksesta ja käyttöönotosta. Tämä osoittaa tiimille, miten asiakas toimii, ja paljastaa prosessin puutteet varhaisessa vaiheessa.

Viikko 2: Prosessit ja viestinnän rytmi

Toisella viikolla tiimi siirtyy yksittäisistä tehtävistä tiimin rutiineihin. Asiakas ja toimittaja sopivat siitä, miten työ suunnitellaan, siitä keskustellaan ja siitä raportoidaan.

Hajautetut tiimit tarvitsevat enemmän rakennetta kuin samassa paikassa työskentelevät tiimit. Aikavyöhykkeet ja kulttuurierot vaikeuttavat epävirallista viestintää, joten viestinnän rytmin on oltava selkeästi määritelty.

• Päivittäiset standup-kokoukset. Järjestä lyhyt puhelinkokous ajankohtana, joka kattaa molemmat aikavyöhykkeet. Viisitoista minuuttia riittää tilannekatsaukseen ja esteiden käsittelyyn.
• Sprintin suunnittelu. Suunnittele työ yhden tai kahden viikon sprinteiksi. Asiakkaan tuoteomistaja asettaa prioriteetit, ja tiimi arvioi työmäärän.
• Koodin tarkistussäännöt. Sovitaan siitä, kuka tarkistaa mitä ja kuinka nopeasti. Yli yhden päivän viive tarkistuksessa hidastaa koko tiimiä.
• Kirjalliset päivitykset. Pyydä lyhyt viikoittainen yhteenveto jaettuun kanavaan. Se antaa sidosryhmille näkyvyyttä ilman ylimääräisiä kokouksia.
• Eskalointipolku. Määritelkää, kuka ratkaisee esteet kummallakin puolella. Toimittajan asiakkuuspäällikkö hoitaa tiimiin liittyvät ongelmat, ja asiakkaan yhteyshenkilö hoitaa tuotteeseen liittyvät kysymykset.

Viikot 3–4: Vastuu ja mittaaminen

Kahden viimeisen viikon aikana testataan, onko perehdytys onnistunut. Tiimi ottaa todellisen vastuun, ja molemmat osapuolet arvioivat tuloksia selkeiden kriteerien perusteella.

Tässä vaiheessa käy myös ilmi, missä prosessia on vielä muokattava. Pienet ongelmat on helpompi korjata 25. päivänä kuin 90. päivänä.

Oikean ominaisuuden luovuttaminen

Kolmannella viikolla tiimille annetaan yksi valmis ominaisuus tuotesuunnitelmasta. Sen tulisi vaatia suunnittelupäätöksiä, työtä useissa koodipohjan osissa sekä tuotantoversion julkaisua.

Asiakkaan tekninen johtaja tarkistaa teknisen lähestymistavan ennen kehitystyön aloittamista. Sen jälkeen tiimi vastaa työstä arvioinnista käyttöönottoon asti. Tiivis valvonta tässä vaiheessa on tarkoituksen vastaista.

Seurattavat mittarit 30. päivänä

Kuukauden lopussa pidä arviointikokous toimittajan kanssa. Vertaa tuloksia ensimmäisellä viikolla asetettuihin odotuksiin ja käytä mahdollisuuksien mukaan lukuja.

• Toimitusvauhti. Vertaa kahden viimeisen sprintin suunniteltuja ja toteutuneita tarinapisteitä. Vakaa vauhti on tärkeämpää kuin nopea vauhti.
• Koodin laatu. Tarkista, kuinka suuri osuus pull-pyynnöistä läpäisee tarkastuksen ensimmäisellä tai toisella kierroksella. Toistuva uudelleen työstäminen viittaa puutteisiin kontekstissa.
• Kysymysten määrä. Seuraa, kuinka usein insinöörit pyytävät apua asiakkaalta. Määrän tulisi laskea viikoittain.
• Sidosryhmien palaute. Pyydä tuoteomistajalta ja tekniseltä johtajalta lyhyt arvio. Heidän näkemyksensä paljastaa usein ongelmia, joita mittarit eivät huomaa.

Yleisiä virheitä käyttöönotossa

Useimmilla käyttöönoton viivästyksillä on samat muutamat syyt. Yritykset toistavat niitä, koska kukin niistä näyttää aluksi vähäiseltä.

• Myöhäinen pääsy. Kolmantena päivänä saapuvat tilit maksavat tiimille kolme päivää. Turvallisuushyväksynnät kestävät usein odotettua kauemmin, joten aloita ne ajoissa.
• Tuotteen kontekstin puuttuminen. Insinöörit, jotka eivät ymmärrä käyttäjiä, tekevät teknisesti oikeita mutta hyödyttömiä päätöksiä. Yhden tunnin tuotetiedotus säästää viikkoja uusintatyötä.
• Liian monta yhteyshenkilöä. Kun viisi ihmistä antaa ohjeita, prioriteetit ovat ristiriidassa. Yksi päätöksentekijä pitää suunnan selkeänä.
• Tiimin kohteleminen ulkoisena osapuolena. Erilliset viestintäkanavat ja rajoitetut kokoukset luovat kaksitasoisen rakenteen. Tiimit, jotka integroituvat asiakkaan rutiineihin, sopeutuvat nopeammin.

Lopuksi

30 päivää riittää saamaan omistautuneen tiimin täyteen tuottavuuteen. Tulos riippuu vähemmän toimittajasta kuin siitä, kuinka hyvin asiakas valmistelee pääsyn, kontekstin ja selkeät prioriteetit.

Käsittele perehdyttämistä projektina, jossa on vastuuhenkilöt, määräajat ja loppuarviointi. Järjestelmällinen ensimmäinen kuukausi rakentaa luottamusta, jota pitkäaikainen yhteistyö vaatii.