Impact mapping

See postitus on ühest küljest kokkuvõte 23. novembril Londonis toimunud konverentsi Agile Testing and BDD eXchange 2012 keynotest, kus Gojko Adzic ning Dan North rääkisid metoodikast nimega impact mapping, teisalt on tegu ülevaatega raamatust Impact Mapping: Making a Big Impact with Software Products and Projects, illustreerivad joonised on laenatud siit.

 

Mis on impact mapping?

Impact mapping ehk mõjude kaardistamine on strateegiline planeerimismeetod, mis annab meeskonnale vahendid nõuete selgeks kommunikeerimiseks, aitab neil oma tegevusi ärieesmärkidega ühildada ja teha paremaid otsuseid. Selle meetodi kasutusala ei ole piiratud tarkvaraarendusega, samamoodi saab seda rakendada ka näiteks protsesside jms planeerimisel.

Tarkvara, mida me toodame, ei teki ega toimi vaakumis, see on ümbritseva maailmaga – kasutajad, teised tarkvaratooted jne – üsna tihedalt seotud. Samas paljud levinud planeerimismeetodid kas eeldavad, et kuni me oma toodet arendame, seisab ülejäänud maailm paigal, või siis ei loo nad üldse mingit pikemas perspektiivis “suurt pilti”. Mida siis mõjude kaardistamine paremini teeb:

  • esitab meie plaanide ja ümbritseva maailma vahelised seosed ning aitavad meil oma plaane kohandada muutunud oludega
  • annab arendusmeeskonnale endiselt hea roadmapi ja äripoolele ülevaate suurest pildist
  • väldib skoobi hajumist (scope creep) ja liiga keeruliste lahenduste loomist (over-engineering), vähendades sellega tühja töö tegemist
  • kindlustab, et arendustöö tulemusena valmib õige asi, mis vastab ärieesmärkidele ning võimaldab ebarealistlikud projektid peatada enne, kui need üle pea kasvavad

Ehk siis miks on impact mapping oluline? See aitab meil luua tooteid, mis täidavad neile pandud eesmärke, mitte lihtsalt tarkvara valmis kirjutada.

 

Kuidas mõjusid kaardistada?

Mõjude kaart on tarkvara skoobi ja selle aluseks olevate eelduste ning nõuete visualiseering. Selline kaart on sisuliselt mindmap, mis valmib arendusmeeskondade ning ärihuvide esindajate koostöös vastates järgmistele küsimustele:

  • Miks? – mõjude kaardi keskpunkis on meie jaoks kõige olulisem küsimus: Miks me seda teeme? See on eesmärk (goal), mille poole me püüdleme.
  • Kes? – esimene kaardi tase vastab sellistele küsimustele nagu Kes saab meid soovitud tulemuse saavutamisel aidata? Kes võib seda takistada? Kes on meie toote kasutajad? Kellele meie toode mõju avaldab? Isikud või üksused, keda need küsimused puudutavad, on tegutsejad (actors); nendeks võivad olla näiteks meie tarkvara kasutajad.
  • Kuidas? – järgmine kaardi tase asetab kasutajad meie eesmärgi konteksti. Kuidas peaks kasutajate käitumine muutuma? Kuidas nad saavad meil aidata oma eesmärke saavutada? Kuidas nad saavad seda takistada? Vastused nendele küsimustele ongi mõjud (impact), mida me soovime luua.
  • Mida? – alles siin tasemel saame rääkida skoobist, vastates küsimusele Mida meie kui ettevõte või arendusmeeskond saame teha oodatud mõjude teostumiseks? See on meie tarkvara funktsionaalsus ja tegevused ettevõtte tasemel – projekti väljundid (deliverables).

Mõjukaardi struktuur

 

Tavaliselt on tarkvara loomisel koostatavad plaanid ja nõuded lihtsalt nimekirjad asjadest, mida toode võiks teha. Suuremate projektide puhul, kus huvitatud osapooli on palju, hajub skoop kiiresti, sest igaüks tahab, et just temale meeldiv funktsionaalsus oleks tootesse sisse kirjutatud. Projekti väljundite ja ärieesmärkide vastavuse kaardistamise eeliseks on võimalus kergema vaevaga põhjendada, miks üks või teine asi on oluline või mitteoluline.

Mõjude kaart paneb projekti väljundid nende poolt loodavate või toetatavate mõjude konteksti, võimaldades meil neid võrrelda ja vältida vähemolulistesse projekti osadesse liigsete ressursside paigutamist. Samuti saame lihtsamini teha otsuseid ühe või teise funktsionaalsuse väljajätmise kohta, kui see meie üldise eesmärgi saavutamisele olulist mõju ei avalda. Viimaks, ühendades omavahel projekti väljundid, nende poolt avaldatavad mõjud ning projekti eesmärgid, saab selliselt kaardilt tuletada mõttekäigud, mis ühe või teise funktsionaalsuseni viisid – lisaks saame tehtud otsuseid kergemini ümber hinnata, kui olukord muutub.

 

Miks on mõjude kaardistamine oluline

Tarkvaraprojektid püsivad paremini fookuses ja ressursse raisatakse vähem, kui kõik osapooled mõistavad eesmärke, oodatavaid mõjusid ja olulisi eeldusi ühtmoodi. Traditsioonilised nõuete kirjeldamise meetodid küll annavad ülevaate suurest pildist, kuid ei ole piisavalt efektiivsed.

Iteratiivsed arendusmeetodid panevad rohkem rõhku sellele, kuidas tarkvaraversiooni reliisimisest saadud kogemust kasutada skoobi, spetsifikatsioonide ja nõuete lihvimisel. Ette valmis mõeldud plaanid ei toimi, kuna olukord muutub liiga tihti.

Mõjukaardid moodustavad silla kahe maailma vahel – nad võimaldavad teostada strateegilist planeerimist ja mõelda suure pildi loomisele olulisemaid ärieesmärke silmas pidades, kuid samas võimaldavad ka reliisikogemustest õppida ja projekti roadmap’i paremini hallata. Mõjukaart esitab projekti skoobi kergesti kohandataval, ümber prioritiseeritaval kujul, nad kasvavad või kahanevad vastavalt sellele, kuidas muutub ärimaastik või milliseid uusi teadmisi me oleme omandanud.

 

Strateegiline planeerimine

Mõjude kaardistamine võimaldab nii juhtivatel äripoole esindajatel kui tehnilistel spetsialistidel olla toote või projekti arendusse kaasatud algusest peale. See loob ühised teadmised ja arusaamise projekti skoobist – mitte niivõrd tehnilisest küljest kui just äripoole perspektiivist vaadatuna.

Kergesti visualiseeritavad vahendid tagavad selle, et projekti võtmeisikutel on ühine arusaam projekti aluseks olevatest ärilistest eeldustest, seega saavad kõik üldisest visioonist ühtmoodi aru ning juba varakult on olemas piisavalt informatsiooni projekti kaugemates faasides õigete otsuste tegemiseks.

 

Kvaliteedi defineerimine

Mõjukaart näitab, milliseid mõjusid projekti tehnilised väljundid peaksid avaldama äripoole vaatenurgast. Selline esitus määratleb tarkvara oodatava kvaliteedi üldisemal tasemel ja kindlustab osapoolte ühtse arusaamise neist seostest.

Mõjukaart aitab säilitada fookust, seada ja ümber seada prioriteete ning kindlaks määrata kvaliteedi parandamiseks või tagamiseks vajalikke tegevusi. Testimise ülesandeks ei ole enam lihtsalt võrrelda tarkvara pakutavat funktsionaalsust tehniliste nõuetega, vaid tõestada, et projekti tehnilised väljundid toetavad ning võimaldavad kasutajal sooritada projekti eesmärgi huvides soovitud tegevusi. Kui projekti väljund soovitud mõju saavutamisele kaasa ei aita, isegi kui tehniliselt on funktsionaalsus täiesti korrektne, on tegu ebaõnnestumisega – sellist juhtumit tuleks käsitleda kui probleemi ning kas funktsionaalsust parandada või see eemaldada.

 

Roadmap’i haldamine

Mõjukaart annab informatsiooni skoobi, eesmärkide ja prioriteetide kohta, kuid lisaks sellele esitab ka eeldused kahel tasemel. Esimene tase näitab, et projekti väljund muudab kasutaja käitumise soovitud viisil – avaldab mõju -, teisel tasemel aga näeme, et kui kasutaja käitumine avaldab mõju, töötab see ka üldisemate eesmärkide huvidas. Tänu sellise informatsiooni visualiseerimisele on mõjukaardid tõhusad vahendid projekti roadmap’i haldamisel.

Kui projekti väljund on reliisitud, saame me kasutajate käitumise tegelikku muutust ning selle mõju ärieesmärgile mõõta. Saadud tulemuste alusel oskame me ümber hinnata oma stateegiaid ning otsustada, kas jätkata tööd kaardi sama osa kallal või liikuda mujale.

 

Mõjukaardi roll tarkvara arendustsüklis

Traditsioonilist agiilset tarkvaraarendusmetoodikat saab vaadelda kui kaht ühenduses olevat hammasratast – väike hammasratas on meie ühe päeva töö, suurem hammasratas esitab aga üht sprinti või iteratsiooni. Mida kiiremini pöörleb väike ratas (mida rohkem tööd me päevas teeme), seda kiiremini pöörleb ka suurem ratas – sprindi maht kasvab.

Lisades siia aga kolmanda, kõige suurema hammasratta, mis esindab ärieesmärke, muutub olukord keerulisemaks. Äripoole huvides on saavutada ärieesmärgid võimalikult kiiresti. Seega peaks kõige suurem hammasratas pöörlema kiiresti. Mis aga juhtub sellisel juhul meie ülejäänud ratastega? Keskmine hammasratas hakkab pöörlema väga kiiresti – sprindi jooksul peame tegema pööraselt palju tööd, et eesmärke täita. Kõige väiksem hammasratas aga pöörleb veel palju kiiremini – päevatöö maht kerkib kaugelt üle pea. Lõpptulemusena lendavad kaks väiksemat ratast teljelt maha ja rataste vahelt tõuseb suitsu.

Siin astuvad mängu mõjukaardid, mille roll on vältida kiiresti edasi liikuvate ärieesmärkide tõttu arenduse kokkukukkumist. Ja kuna pilt räägib sõnadest rohkem ja paremini, siis las räägib enda eest ka järgnev joonis mõjukaartide rollist arendusprotsessis.

Mõjude kaardi roll arendusprotsessis

 

Näide

Mis annaks veel parema ülevaate pikast jutust, kui üks näide otse elust enesest. Alltoodud näide pärineb otse veebilehelt www.impactmapping.org ning on siia kaasatud just nimelt oma lihtsuse ja ülevaatlikuse tõttu.

Olgu meie ettevõtte üks toodetest online mänguplatvorm. Meie ettevõtte ärieesmärk selle toote jaoks olgu suurendada aktiivsete mängijate arvu ühe miljonini.

Mängijad kui olulised tegutsejad saavad eesmärgi saavutamisele kaasa aidata, soovitades meie mänge sõpradele, postitades mängude kohta informatsiooni sotsiaalvõrgustikes ning kutsudes ka oma sõpru mängima. Teine oluline tegutsejate grupp on reklaamipakkujad.

Näide mõjude kaardistamisest

 

Projektil on mängijate käitumise mõjutamiseks mitmeid väljundeid, näiteks poolautomaatsed kutsed teevad sõprade mängima kutsumise lihtsamaks, isiklikumaks muudetud mängukogemus mõjutab jällegi kasutajaid sõpru mängu kutsuma. Mängus uute tasemete või saavutusteni jõudmine aga võib motiveerida kasutajaid tegema meie mängude kohta postitusi sotsiaalvõrgustikes.

 

Ainult funktsionaalsusest ei piisa

Ettevõtted kaotavad tarkvaraprojektidega meeletutes kogustes raha peamiselt seetõttu, et arendus ei järgi ärieesmärke või alguses paika pandud strateegiad on arendusprotsessi jooksul iganenud.

Tarkvara on tänapäeval kõikjal ja loendamatud tooted ja projektid vajuvad vaikselt unustusehõlma, ilma et nad kunagi mingit mõju avaldaks. Seda põhjusel, et paljud projektijuhtimise metoodikad põruvad eesmärkide ning nõuete edastamisel. Ja põruvad valusalt. See ei avaldu mitte üksnes tarkvaraarenduses.

On selge, et kui me anname vastused küsimustele “mis” ja “kuidas”, ei ole see piisav valmistamaks meeskonda ette ootamatusteks. Kuid ometigi paljud nõuete esitamise mudelid just seda teevad. Kiirelt muutuvas keskkonnas, nagu seda on tarkvara tootmine, on palju olulisem anda vastused küsimustele “miks” ning “mida oodata”.

Mõjukaardid võimaldavad seda teha, kuid ei piirdu vaid funktsionaalsuse ja eesmärkide sidumisega projekti alguses, vaid annavad meile vahendid dünaamilise roadmap’i haldamiseks, mis muutub vastavalt saadud uutele kogemustele ja teadmistele. Fookuses hoitakse eesmärk, funktsionaalsus ja skoop on vaid toetavad kõrvalseisjad. Visualiseerides eeldused (assumptions), saame kiirelt edasi liikuda vastavalt sellele, kuidas neid eeldusi täidetakse või kõrvale lükatakse.

Vaatleme eeltoodud näitest väikest osa:

Toodud näites on poolautomaatsete kutsete eesmärgiks võimaldada mängijatel sõpru mängu kutsuda. Me eeldame, et vastava funktsionaalsuse olemasolu muudab mängijate käitumist. Kui funktsionaalsus on mängijatele kättesaadavaks tehtud, saame me jälgida, kas tehtud eeldus on pädev. Kui mängijad hakkavad rohkem sõpru mängu kutsuma, võime selle haru kallal tööd jätkata, vastasel juhul tuleks olukorda analüüsida ja proovida kutsete osas teisi lahendusi.

Sellel kaardilõigul on näha ka kõrgema taseme eeldus. Kui mängijad saadavad kutseid, eeldame me, et nende sõbrad tegelikult ka tulevad meie mänge mängima. Kui kaardil kutsetega seotud väljundid on reliisitud, saame uurida, kas kutsed toovad uusi kasutajaid oodatud määral. Kui jah, peaksime seda funktsionaalset osa laiendama. Vastasel juhul aga pole mõtet anda kasutajatele lisavõimalusi kutsete saatmiseks, selle asemel tuleks lähenemist muuta ning leida viise, kuidas kutsetele reageerimist parandada või hoopis teha midagi muud.

Lõpetuseks, kaardistades projekti või toote väljundite seosed ärieesmärgiga, aitab mõjude kaardistamine meil töötada ühekorraga vähemate ärieesmärkide ja nende saavutamiseks vajalike mõjude teostamise kallal. Tuleks valida kaardilt üks eesmärgile kaasa aitav mõjufaktor ning keskenduda sellele, kuni vastav funktsionaalsus on küps väljastamiseks.

Leave a Reply

Your email address will not be published. Required fields are marked *