Kirjoita agentille selkeä tehtävänanto

Kuvaa muutos, jonka tarkastaja voi arvioida

”Lisää asiakkaiden vienti” jättää useita päätöksiä auki. Kuka saa viedä tietoja? Mitkä tietueet ja kentät tulevat mukaan? Mitä tapahtuu pyynnön epäonnistuessa? Agentti voi täydentää aukot uskottavilla ratkaisuilla, jotka ovat silti liiketoiminnalle vääriä.

Aloita käyttäjästä ja ongelmasta. Kuvaa sitten vaadittu toiminta ja näyttö, jonka perusteella tulos voidaan hyväksyä.

Tehtävänanto vähentää epävarmuutta. Sen ei tarvitse lukita kaikkia sisäisiä ratkaisuja. Määrittele esimerkiksi pakollinen tietoraja. Anna toteutuksen käyttää repositorion nykyisiä käytäntöjä, ellei niiden muuttamiseen ole syytä.

Käytä konkreettista esimerkkiä

Seuraava tehtävänanto koskee kuvitteellista tukisovellusta. Se on opetusesimerkki, ei valmis tuotantomäärittely.

Tavoite: Tukitiimin manager voi ladata asiakaslistan.
Käyttäjä: Nykyisen organisaation manager.
Tiedot: Vain kyseisen organisaation aktiiviset asiakkaat.
Kentät: Asiakastunniste, yrityksen nimi ja asiakkuuden tila.
Muoto: UTF-8 CSV ja otsikkorivi.
Kielletty pyyntö: Nykyinen authorization-virhe.
Tyhjä tulos: Kelvollinen CSV, jossa on vain otsikkorivi.
Rajaus: Nykyinen export-route ja audit-käytäntö.
Pois rajattu: Ei uusia rooleja, riippuvuuksia tai deploymentia.
Näyttö: Sallitut, kielletyt, tyhjät ja organisaatiorajan ylittävät pyynnöt.

Tehtävänanto kertoo hyödyllisen toiminnan ja rajat. Se paljastaa myös lisäkysymyksiä. Pitääkö viennin kokoa rajoittaa? Voiko kentässä olla taulukkolaskennan kaava? Kuka pääsee audit-tietoon? Ratkaise olennaiset kysymykset ennen toteutusta. Esimerkki ei ole yleispätevä tarkistuslista.

Erota vaatimukset oletuksista

Vaatimus kertoo, mitä muutoksen pitää tehdä. Oletus on tieto, jota ei ole vielä tarkistettu. Pidä ne erillään.

”Käytä nykyistä audit-käytäntöä” olettaa sopivan toteutustavan olevan olemassa. Pyydä agenttia etsimään se. Jos sellaista ei ole, agentin pitää nostaa puute esiin ennen uuden audit-järjestelmän keksimistä.

Reunaehto voi myös olla ristiriidassa tavoitteen kanssa. Nykyinen route saattaa tarkoituksella palauttaa kaikkien organisaatioiden tiedot. Agentin tulee näyttää ristiriita ja ehdottaa rajattua korjausta. Se ei saa hiljaisesti poistaa tietorajaa tai laajentaa tehtävää arkkitehtuurin uusimiseksi.

Sisällytä näyttö valmistumisen ehtoihin

Pyydä loppukuvaus toteutetusta toiminnasta, rajauksen muutoksista ja tehdyistä tarkistuksista. Edellytä täsmällisiä komentoja ja tuloksia silloin, kun niillä on merkitystä. Onnistunut tarkistus ja ajamatta jäänyt tarkistus ovat eri asioita.

Pull requestin tulee säilyttää muutoksen syy. Myöhempi ylläpitäjä näkee koodin, mutta ei välttämättä alkuperäistä keskustelua. Kerro, miksi tietyt kentät on jätetty viennistä pois ja miten käyttöoikeus valvotaan.

Googlen muutoskuvausten ohje antaa tähän hyödyllisen lähtökohdan: kuvaa muutos ja sen tarkoitus. Päivitä kuvaus vastaamaan lopullista toteutusta myös review-muutosten jälkeen.

Mitoita tehtävänanto seurauksiin

Pieni tekstikorjaus tarvitsee lyhyen tehtävänannon. Tietojen vienti vaatii enemmän, koska virhe voi paljastaa tietoa. Uusi maksuprosessi tarvitsee vielä perusteellisemman arvioinnin.

Älä mittaa tehtävänannon laatua pituudella. Pystyisikö osaava tarkastaja erottamaan oikean tuloksen väärästä? Jos kaksi järkevää toteutusta eroaisi olennaisessa toiminnassa, täsmennä se ensin.