Idea ei ole pyyntö: viisi kysymystä ennen kuin automaatiota kannattaa rakentaa

Kun triagesin sidosryhmien AI-toivelistaa ensimmäistä kertaa, listalla oli reilut viisikymmentä riviä. Osa oli tyhjiä, otsikko ja ei muuta. Osassa oli kaksi lausetta jotka viittasivat johonkin edelliseen kokoukseen jota en ollut ollut mukana. Iso osa oli merkitty kategoriaan “muu”, mikä on aina merkki siitä ettei kukaan ole vielä oikeasti miettinyt mihin rivi kuuluu. Ja lähes joka riviltä puuttui yksi ja sama asia: määrittely siitä mitä rivi oikeasti tarkoittaa käytännössä.

Tämä on tuttu tilanne jokaiselle joka on koskaan pyytänyt organisaatiota listaamaan tekoälyideoita. Kokous tuottaa innostuneen post-it-seinän tai jaetun taulukon, jossa jokainen rivi kuulostaa lupaavalta ja yksikään ei ole vielä toteutuskelpoinen.

Idea ja pyyntö eivät ole sama asia

Tässä on täsmällinen ero jonka opin kantapään kautta: idea on toive lopputuloksesta, pyyntö on kuvaus siitä miten sinne päästään. “Haluaisin että asiakaspalvelu olisi nopeampaa tekoälyn avulla” on idea. Se on ihan validi ajatus, mutta sen kanssa ei voi mennä kehittäjän pöydälle, koska kukaan ei tiedä mistä data tulee, missä muodossa se on, mihin järjestelmään lopputulos pitäisi viedä tai miten kukaan tietäisi että homma onnistui. Pyyntö on sama ajatus, mutta niin auki kirjoitettuna että joku voi alkaa rakentaa sitä maanantaina.

Ero ei ole akateeminen. Korkealentoinen idea naamioituna pyynnöksi johtaa väärin scopattuun työhön, koska joku alkaa rakentaa jotain arvauksen varassa, ja arvaus osuu harvoin ensimmäisellä kerralla. Se johtaa myös hukattuihin kierroksiin: viikon työn jälkeen selviää että lopputulos ratkaisi väärän ongelman, koska kukaan ei kysynyt oikeaa kysymystä ajoissa.

Miten kriteeristö syntyi

Ensimmäinen intake-kierros paljasti systeemiset aukot, ei yksittäisiä huonoja rivejä. Kun kävin listaa läpi rivi kerrallaan ja yritin arvioida mikä erotti ne muutamat toteutuskelpoiset ideat lopusta joukosta, viisi kysymystä alkoi toistua käytännössä joka kerta kun jokin rivi eteni oikeasti eteenpäin.

Otetaan yksi rivi esimerkiksi, koska se havainnollistaa prosessia paremmin kuin lista abstraktioita. Kuvitellaan tyypillinen rivi tällaiselta listalta: “Automaattinen yhteenveto asiakaspalautteesta johdolle.” Kun tällaisen rivin vie viiden kysymyksen läpi, ensimmäinen kysymys on mistä palaute oikeasti tulee, eli mikä on syöte ja lähde. Vastaus on tyypillisesti epäselvä: osa palautteesta on sähköposteissa, osa CRM-järjestelmän vapaatekstikentässä, osa suullisena kuultuna käytävällä. Vasta kun pyytäjä joutuu vastaamaan tähän ääneen, hän yleensä huomaa ettei hän itsekään ole tiennyt mistä data pitäisi kerätä.

Toinen kysymys on, onko olemassa source of truth koneluettavana, eli onko jossain yksi paikka josta järjestelmä voisi hakea ajantasaisen tiedon ilman että ihminen syöttää sitä manuaalisesti joka kerta. Tällaisella rivillä vastaus on usein ei: CRM:n vapaatekstikenttä on olemassa, mutta sen sisältö on epäjohdonmukaista tekstiä jota kukaan ei ole koskaan jäsentänyt. Tämä yksi kysymys siirtää koko projektin painopisteen. Ennen kuin yhtään yhteenvetoa voidaan automatisoida, pitää ensin ratkaista paljon tylsempi ongelma: miten palaute kirjataan johdonmukaisesti ylipäätään.

Kolmas kysymys koskee output-muotoa, eli missä muodossa lopputuloksen pitää olla jotta joku oikeasti käyttää sitä. Tulisiko siitä Slack-viesti maanantaiaamuna vai PDF johtoryhmän kokoukseen? Kumpikin vaatii täysin erilaisen toteutuksen, ja tähän kulmaan pyytäjä ei ole yleensä ajatellut asiaa lainkaan ennen kuin kysymys esitetään suoraan.

Neljäs kysymys on integraatiopiste työnkulussa: mihin kohtaan olemassa olevaa prosessia automaatio liittyy. Onko se erillinen työkalu jota kukaan ei avaa, vai upotettu siihen kohtaan jossa johto jo muutenkin lukee tietoa? Viides kysymys on onnistumismittari: mistä tiedetään kolmen kuukauden päästä että tämä oli hyvä idea eikä vain kiva demo. Kun tällainen rivi läpäisee kaikki viisi kysymystä, siitä syntyy oikea, hyvin rajattu pyyntö. Moni rivi ei koskaan pääse tähän pisteeseen, koska vastaukset eivät löydy, ja sekin on hyödyllinen tulos: se säästää rakentamasta jotain mikä olisi joka tapauksessa jäänyt käyttämättä.

Analogia: remonttitilaus

Tämä muistuttaa tilannetta jossa joku soittaa remonttiyritykselle ja sanoo haluavansa kodin kauniimmaksi. Rakentaja ei voi aloittaa mistään tuolla lauseella. Hän kysyy ensin mistä materiaalit tulevat ja missä kunnossa nykyiset rakenteet ovat, eli syöte ja lähde. Sitten hän pyytää piirustuksen josta näkyy tarkasti mitat ja rakenteet, ei suullista kuvausta muistin varassa, eli koneluettavan source of truthin. Keittiö vai kylpyhuone vai molemmat, eli tarkka output-muoto, ratkaisee minkälaisen tarjouksen hän ylipäätään voi laskea. Jos remontti koskee sähköjä tai putkistoa jotka vaikuttavat muuhun taloon, se on integraatiopiste jonka pitää olla tiedossa ennen ensimmäistä lyöntiä. Ja lopuksi molempien pitää sopia etukäteen mistä tiedetään että remontti on valmis ja hyväksytty, se on onnistumismittari. Ilman näitä viittä asiaa rakentaja voi tarjota vain arvauksen, ja lasku sen arvauksen mukaan tulee joka tapauksessa.

Viisi kysymystä, käytä sellaisenaan

Kriteeristö kääntyy suoraan kysymyslistaksi jonka voi esittää kenelle tahansa joka tuo AI-idean pöydälle. Jos vastaus johonkin näistä on epäselvä, se ei tarkoita että idea on huono, se tarkoittaa että idea ei ole vielä pyyntö.

1. Syöte ja lähde. Mistä data tai tieto oikeasti tulee, ja missä muodossa se tällä hetkellä on?
2. Source of truth koneluettavana. Onko olemassa yksi paikka josta ajantasainen tieto saadaan ilman manuaalista syöttöä, vai pitääkö tämä rakentaa ensin?
3. Output-muoto. Missä konkreettisessa muodossa lopputulos pitää olla, jotta joku oikeasti käyttää sitä osana omaa työtään?
4. Integraatiopiste työnkulussa. Mihin kohtaan olemassa olevaa prosessia tämä liittyy, ja kuka sen näkee ensimmäisenä?
5. Onnistumismittari. Mistä tiedämme kolmen kuukauden päästä että tämä oli oikea päätös, eikä vain kiva demo?

Vain ne rivit jotka läpäisevät kaikki viisi etenevät buildiin. Käytännössä huomasin myös, että kun spec on kerran kirjoitettu näin auki, sama työkalu kattaa usein useamman rivin listalta kerralla. Kaksi eri sanoin kirjoitettua toivetta osoittautuu samaksi pyynnöksi heti kun molemmat pakotetaan vastaamaan samoihin viiteen kysymykseen.

Mitä tämä tarkoittaa sinun organisaatiollesi

Jos oma listasi näyttää samalta kuin minun ensimmäinen kierrokseni, eli täynnä innostuneita mutta tyhjiä rivejä, kannattaa katsoa suhdetta eikä yksittäisiä rivejä. “Meillä on viisikymmentä AI-ideaa” tarkoittaa käytännössä yleensä: “meillä on kolme oikeaa pyyntöä ja neljäkymmentäseitsemän toivetta.” Se on ihan normaali suhde, kunhan sen tunnistaa ajoissa eikä yritä rakentaa kaikkia neljäkymmentäseitsemän kerralla.

Organisaatioiden AI-jono on tyypillisesti määrittelyongelma, ei teknologiaongelma, ja määrittelyongelma ratkeaa kysymyksillä. Konsultin arvokkain työkalu tässä vaiheessa on kysymyslista jonka voi antaa pyytäjälle takaisin ja pyytää häntä vastaamaan itse. Se toimii paremmin kuin mikään malliarkkitehtuuri tai valmis prompti, koska se pakottaa pyytäjän tekemään ison osan ajattelutyöstä ennen kuin kukaan koskettaa koodia. Jos sinulla on oma toivelista pöydällä, kokeile ajaa yksi rivi näiden viiden kysymyksen läpi tänään. Se kertoo nopeammin kuin mikään muu, onko kyseessä idea vai pyyntö.