Nopea prototypointi voi olla hyödyllinen työkalu meille digitaalisina projektipäälliköinä, kun autamme asiakkaita, jotka esittävät kysymykset: ”Mutta toimiiko tämä?” ja ”Miten tämä toimii?” Usein yksinkertainen mutta turhauttava vastaus on: ”Emme vielä tiedä – mutta autetaan teitä selvittämään se.” Loistava tapa selvittää asia, ja sellainen, joka on yhä suositumpi toimistojen ja asiakkaiden keskuudessa, on nopea prototypointi – investoidaan hieman, jotta voidaan tehdä tietoon perustuva päätös tuotteen elinkelpoisuudesta ennen suuria investointeja.
Toimialamme etenee salamannopeasti, ja digitaalisina projektipäälliköinä meidän on sopeuduttava nopeasti uusiin työskentelytapoihin. Yksi ajankohtainen esimerkki tästä on nopea prototypointi. Yhdeksän kuukautta sitten en ollut koskaan työskennellyt nopean prototypoinnin projektissa, ja nyt olen juuri saanut päätökseen neljännen nopean prototypoinnin projektini tuotteen elinkelpoisuuden nopeaa testaamista varten. Jos et siis ole vielä työskennellyt nopean prototypoinnin projektissa, olen varma, että sellainen on aivan nurkan takana.
Tässä kirjoituksessa esitellään erilaisia tapoja tutkia tuotteen elinkelpoisuutta ja annetaan ohjaavia periaatteita, joiden avulla voit hallita nopeasti eteneviä digitaalisia tai analogisia projekteja luottavaisin mielin.
Mutta ensin: mitä nopea prototypointi on?
Nopea prototypointi tarkoittaa prosessia, jota käytetään konseptin toimivuuden osoituksen tai nopeiden prototyyppien rakentamiseen. Prototyyppi sopii hyvin konseptin toimivuuden testaamiseen. Sen avulla voit kehittää enemmän ominaisuuksia nopeammin, mutta tämä tapahtuu yleensä laadun kustannuksella, minkä vuoksi tuote on pääosin kertakäyttöinen.
Prototyyppejä on monenlaisia ja -kokoisia
Vaikka tuotteen elinkelpoisuutta voi tutkia monin eri tavoin, tässä on kolme selkeästi erilaista lähestymistapaa:
- Konseptin toimivuuden osoitus – Konseptin toimivuuden osoitus on tuotteen hyvin kevyt ja poisheitettävä esittelyversio, jonka tarkoituksena on testata tuotteen taustalla oleva idea ennen sen rakentamista.
- Nopea prototyyppi – Nopea prototyyppi on tuotteen kevyt ensimmäinen versio, jota voidaan testata oikeilla käyttäjillä, jotta tuotteeseen saadaan enemmän luottamusta ennen täysimittaista toteutusta.
- Elinkelpoinen vähimmäistuote (MVP) – MVP on tuotteen ensimmäinen tuotantolaatuinen versio, jossa käyttäjille rakennetaan täysin toimivat ominaisuudet.
Luottamuksesi tuotteeseen tulisi olla tärkein tekijä, kun päätät, mitä lähestymistapaa käytät.
Mitä riskialttiimpi idea on, sitä nopeammin sinun pitäisi edetä.
Jotkut saattavat sanoa, että jos idea on riskialtis, sen pohtimiseen ennen rakentamista pitäisi käyttää enemmän aikaa. Tavallaan he ovat oikeassa. Tarpeen voi validoida lähes rakentamatta mitään. Validointitestauksesta on lukuisia esimerkkejä, joihin kannattaa tutustua.
Kun kuitenkin tiedät, että tarve on olemassa, ainoa tapa todistaa se on rakentaa jotain, julkaista se mahdollisimman nopeasti raakimmassa muodossaan, kerätä palautetta ja kehittää sitä iteratiivisesti. Olemme lukuisia kertoja havainneet, että ideaa tutkiessasi asiakas sanoo väistämättä: ”Ostaisin tuon”, mutta kun tuote julkaistaan, myynti ei lähdekään nousuun.
”Ostaisin tuon ehdottomasti” – 100 ihmistä
Sen todella ostavat = 10
Jeff Sheldon (@ugmonk) 1. syyskuuta 2016
Nopea prototypointi vähentää riskiä joka kerta lyhentämällä palautesykliä ja varmistamalla, että rakennat tuotetta, joka menee kaupaksi.
Miten tiedät, mikä vaihtoehto sopii sinulle?
| Prototypoinnin tyyli | Luottamus | Kuinka keinotekoinen | Kuinka kertakäyttöinen |
|---|---|---|---|
| Konseptin toimivuuden osoitus | Matala | Täysin | Täysin |
| Nopea prototyyppi | Keskitasoinen | Osittain | Osittain |
| Elinkelpoinen vähimmäistuote | Korkea | Hyvin vähän / ei lainkaan | Rakennettu kestämään |
Jotta voit rakentaa asioita nopeasti, sinun on oltava valmis kehittämään uusia prosesseja ja työskentelytapoja.
Ohjaavat periaatteet nopean prototypoinnin projektien hallintaan
Alla kuvattujen työskentelytapojen omaksuminen edellyttää uutta ajattelutapaa. Suosittelen aloittamaan projektin sisäisellä aloitustapaamisella, jossa käytte nämä periaatteet läpi ja selitätte, miksi ne ovat tärkeitä. Näin varmistetaan, että koko tiimi on alusta alkaen samalla sivulla, tietää, mitä siltä odotetaan, ja ymmärtää, missä ja miksi projekti saattaa poiketa totutuista toimintatavoista.
1. Varaudu tekemään vähemmän
Tämä tarkoittaa todennäköisesti tavallista vähäisempää ennakkosuunnittelua ja sitä, että sinun on oltava valmis seuraaviin asioihin:
- Ei lainkaan tai vain minimaaliset hyväksymiskriteerit
- Tarinoissa ei ole alitehtäviä
- Ei arvioita
Sen, minkä menetät jäykässä prosessissa, saat takaisin nopeutena, luottamuksena ja viestintänä. Hyväksy hallinnan puute.
Tämä periaate muistuttaa koko tiimiä siitä, että tunnettujen prosessien hylkääminen on hyväksyttävää, jos sen ansiosta toimiva ohjelmisto saadaan toimitettua nopeammin. On hyvä kysyä säännöllisesti itseltäsi ja tiimiltä: ”onko tämä nopein tapa tehdä x?”
2. Näytä, älä kerro
Kun suunnittelet vähemmän etukäteen, puhut ja piirrät enemmän kehityksen aikana. Saatat haluta pidentää päivittäisiä scrum-kokouksia, jotta voitte keskustella ominaisuudesta hieman yksityiskohtaisemmin ennen kuin tiimisi alkaa rakentaa sitä kyseisenä päivänä. Kuten sanonta kuuluu, kuva kertoo enemmän kuin tuhat sanaa. Joskus sivun luonnos, sisältömalli tai kaavio, joka havainnollistaa järjestelmän toteutustapaa, riittää rakentamisen aloittamiseen, minkä jälkeen voit iteroida sen pohjalta.
Tämä periaate vahvistaa sinun ja asiakkaan luottamusta. Kaikki nauttivat edistymisen näkemisestä, ja työn säännöllinen esittely mahdollistaa oikea-aikaisen palautteen, mikä vähentää hukkaa.
3. Pyydä anteeksiantoa, älä lupaa
Useimmissa perusteellisissa ohjelmistokehitysprosesseissa yhteisymmärrys on avainasemassa. Haluat, että tuotteen omistaja hyväksyy hyväksymiskriteerit, ja projektipäällikkönä haluat varmistaa, että tiimisi on ymmärtänyt vaatimukset ennen kuin yhtäkään koodiriviä kirjoitetaan.
Nopeiden prototyyppien yhteydessä on tärkeää, että tiimisi tuntee voivansa yksinkertaisesti rakentaa ratkaisun parhaan senhetkisen ymmärryksensä mukaan, näyttää työnsä mahdollisimman nopeasti, saada palautetta ja iteroida.
Yhteisymmärryksen tavoittelu heti alussa hidastaa toimintaa, ja työ menee harvoin hukkaan, jos tiimi näyttää työnsä varhaisessa vaiheessa ja usein.
Tämä periaate on erityisen hyödyllinen kehittäjille, sillä se antaa heille vastuun ominaisuuden alkuperäisestä suunnittelusta ja rakentamisesta vähäisellä ulkopuolisella vaikutuksella. Rakennamme usein liikaa ja teemme asioista liian monimutkaisia, koska emme aina näe pyyntöihimme liittyvää teknistä monimutkaisuutta. Siksi on hyvä luottaa tiimin kehittäjiin siinä, että he päättävät, mikä on yksinkertaisin toteutus, ja rakentavat ensin sen.
Jotta tämä toimisi, on tärkeää, että kehittäjilläsi on syvällinen ymmärrys projektista, jotta he pystyvät tekemään projektin kannalta oikeita päätöksiä ja rakentamaan aina vain juuri tarpeeksi.

4. Kannusta aina tiimiä näyttämään, mitä se työstää (vaikka se olisi rumaa)
Tämä prosessi on saanut vaikutteita Government Digital Servicen prototyyppiperiaatteista.
Yleensä näytämme asiakkaille ominaisuudet vasta niiden valmistuttua. Nopeiden prototyyppien projekteissa on tärkeää näyttää ominaisuus heti, kun se toimii, jotta voit vähentää hukkaa, iteroida ja tarvittaessa muuttaa suuntaa.
Saa se toimimaan. Näytä asia.
Tee siitä kaunis. Näytä asia.
Tee siitä skaalautuva. Näytä asia.
Tämä periaate vapauttaa tiimin jäsenet tunteesta, että heidän pitäisi näyttää työnsä vasta, kun suunnittelija on tarkistanut sen tai se on testattu täysin. Juhlistakaa keskeneräistä työtä.
5. Valitse fyysiset prosessit verkkopohjaisten sijaan
Kuten Brett Harned sanoo, hallitsemme projekteja mielessämme, emme työkaluillamme. Älä pelkää hylätä projektinhallintatyökalujasi. Visualisoi työ, käytä fyysistä työjonoa, kiinnitä luonnokset, käyttäjäpolut ja käyttäjäpersoonat seinälle ja kokoontukaa niiden äärelle scrum-kokoukseen. Viittaa niihin usein ja kannusta ihmisiä ottamaan vastuuta korttien siirtämisestä sekä uusien ominaisuuksien käyttöönoton juhlistamisesta. Jos asiakkaasi ei työskentele samassa paikassa, valokuvaa kaikki ja jaa se Slackissa, jotta hän ei jää ulkopuolelle.
Uuden prosessin kokeileminen voi olla hankalaa. Työn visualisointi tuo todennäköisesti esiin keskusteluja, joita ei syntyisi, jos katselisit digitaalista taulua videokokouksessa. Pian käy ilmeiseksi, jos fyysistä korttia ei ole siirretty päivään tai jos keskeneräistä työtä on liikaa. Fyysisten prosessien käyttö lisää läpinäkyvyyttä, mistä olet kaiken tuntuessa epäselvältä ikuisesti kiitollinen.
6. Kohdelkaa toisianne erinomaisesti
On luonnollista tuntea olonsa kuormittuneeksi, kun yrität omaksua uuden prosessin ja työskentelytavan, etenkin jos ne ovat sinullekin uusia. Johda kuitenkin itsevarmasti ja kannusta tiimiä sen kohdatessa vaikeuksia. Kuuntele tarkasti heidän huoliaan ja ole valmis hienosäätämään prosessia matkan varrella. Varmista, ettei prosessi aiheuta tiimillesi lisäpaineita – nopeassa prototypoinnissa on kyse älykkäämmästä, ei raskaammasta työskentelystä.
Tiimisi jäsenten persoonallisuuksista riippuen jotkut heistä omaksuvat tämän uuden työskentelytavan innokkaasti, kun taas toiset saattavat vastustaa sitä. Opimme kaikki eri tahtiin, ja kukin osa-alue kohtaa erilaisia haasteita sopeutuessaan työskentelemään uudella tavalla. Projektipäällikkönä pidä tämä mielessä ja pyri luomaan tiimille kannustava ja turvallinen ympäristö – istukaa yhdessä, juokaa teetä ja kysykää säännöllisesti kaikilta, miten heillä menee.
7. Minimoi häiriötekijät
Projektipäällikkönä on joskus hankalaa tietää, missä kohdissa uuden prosessin suhteen voi tehdä kompromisseja ja milloin omasta kannastaan pitäisi pitää kiinni. Kun kyse on uusien muutosten hyväksymisestä kesken sprintin, jatka vastustamista ja kieltäytymistä. On tärkeää, että sprintin alkaessa tiimisi saa työskennellä keskeytyksettä; heidän aikansa suojaaminen on arvokkainta, mitä voit tehdä.
Tämä periaate antaa tiimille valmiudet torjua pyyntöjä. On todennäköistä, että työskentelette viikon mittaisissa sprinteissä, ja näin lyhyessä ajassa ei ole varaa menettää aikaa. Hanki tukea koko yritykseltä, jotta ihmiset voivat siirtää sisäisiä kokouksia tai muita velvollisuuksia ja keskittyä täysin työhön kyseisen ajanjakson aikana.
Näin nopea prototypointi toimii hyödyksesi
Olen kokenut tämän uuden työskentelytavan erittäin palkitsevaksi, vaikka se tuntui ajoittain kaoottiselta, sekavalta ja hallitsemattomalta. On vaikea tietää, mistä ja kuinka paljon nykyisestä prosessistasi pitäisi poiketa, mutta kannustan sinua kokeilemaan, epäonnistumaan nopeasti ja kertomaan tiimillesi avoimesti, mitä tarvitset heiltä.
Joskus poistimme prosessista keskeisen osan ja palautimme sen myöhemmin, koska kävi ilmi, että minun oli vaikea hallita projektia ilman sitä. Projektin näissä vaiheissa varmistin, että pystyin selittämään selkeästi muulle tiimille, mitä seurauksia tämän prosessin poistamisella oli. Keskustelimme tiiminä siitä, olisiko minulla jokin vaihtoehtoinen tapa saada kyseiset tiedot. Jos emme löytäneet parempaa ratkaisua, palautimme prosessin. Tällaisina hetkinä saat yhteisen luottamuksen ja kunnioituksen kannustavan ympäristön rakentamisen hyödyt. Jokaisessa vaiheessa opimme, kehitämme toimintaamme ja jatkamme eteenpäin yhtenä tiiminä.
Kiitos näistä periaatteista Chris Thorpeille, kaikki tietoni ovat peräisin häneltä.
