Kas oled märganud, kui palju on Agiilsuse Treenereid võrreldes Toote Treeneritega? Miks keskenduvad ettevõtted nii palju kiirema ja sujuvama arenduse saavutamisele Agiilsuse kaudu, kuid ei pööra nii palju tähelepanu Tootejuhtide suunamisele paremate, kliendikeskseimate arendamisotsuste tegemisel? Ainult vähestel juhtudel ja alles viimastel aastatel olen näinud sisemisi Toote Arenduse Treenereid või Mentorlusprogramme. Tundub, et ikkagi valitseb üldine veendumus, et Agiilsuse Treener toetab ka Tooteinimesi. Miks see nii on?

Põhimõtteliselt ütleb see mulle, et palju investeeritakse uute omaduste ja toodete kiiremasse turuletoomisesse, kuid peaaegu sama palju ei panustata rooli ja pidurite juures - kindlustamaks, et meeskonnad mitte ainult ei liigu kiiresti, vaid ka õiges suunas, tehes häid (andmepõhiseid) otsuseid ja arendades ainult neid tooteid ja funktsioone, mis tõeliselt kliendile ja ettevõttele kasu toovad.

Tootejuhtimine Agiilsuse piiridest kaugemale

Olen nõus, et enamikule ettevõtetele on Agiilsus palju mõistlikum kui traditsiooniline Waterfall meetod. Lisaks meeldib mulle idee teha järk-järgulisi muutusi ja kiirelt „läbi kukkuda“, et saada kiiresti uusi tooteid turule ja vaadata, kas nad ujuma jäävad, ning neid seejärel parendada. Kuid see ei tähenda, et Discovery tuleks Toote Arendusprotsessis vahele jätta, see on oluline samm, mis on loodud oluliselt vähendama turuvaidlusi mittetäitva toote turuletuleku tõenäosust. Tarkvaraarendus on endiselt üheks suurimaks kulukohaks (jah-jah, teoreetiliselt on see investeering...) igas ettevõttes. Tulistamine pimedas, läbimata etappe nagu Kasutaja- ja Turuuuring, Nõuete kaardistamine, Protsessianalüüs, Toote Disain ja Prototüüpimine jne, võib olla väga riskantne investeering. Kuigi kiirelt ebaõnnestumine on oluline, on veelgi olulisem teha kõik, et vältida ebaõnnestumist juba enne arendamist alustamist.

Minu kogemuse kohaselt on need mõned kõige olulisemad Tootejuhtimise aspektid, kus Tootejuhid võivad suuresti treeneri või mentori abist kasu saada:

• Kinnitamine, et probleem on tõesti probleem ja kui suur see on. Sa võid kasutada internetist kättesaadavat teavet, küsitlusi läbi viia ja aeg-ajalt intervjueerida. Samuti on oluline hinnata probleemi lahendamise väärtust selles etapis - küsida küsimusi nagu 'kas see toob täiendavat tulu, säästab aega või suurendab kliendirahulolu?

• Kasutajate mõistmine - kuidas kasutajad probleemi kogevad, milliseid lahendusi nad praegu kasutavad ja millised on nende emotsionaalsed reaktsioonid. See annab ülevaate, millised kasutajatüübid võiksid tahta sinu lahendust ja milliseid valusid nad vajavad leevendust. Lisaks kasutajate intervjueerimisele on tööde tegemise ja kliendi teekonna kaardistamine suurepärased tööriistad selleks. Samal ajal ei tohiks unustada, et Google Analytics, Hotjar ekraanisalvestused ja kuumakaardid on sama kasulikud.

• Turgu ja seadusandlikku keskkonda mõista - See hõlmab kindlustamist, et sinu toode on kooskõlas asjakohaste seaduste ja regulatsioonidega, mis on põhiülesanne igale Tootejuhile.

• Lahenduse kujundamine ja kinnitamine. Minu hiljutine lemmik ulatuse määratlemisel põhineb Töödel, mida tuleb teha. Soovitud tulemuse avaldused koos lõppkasutajate tähtsuse ja rahulolu hinnangutega aitavad kenasti välja tuua tulevase väärtuspakkumise vajaliku ulatuse ja kohustuslikud aspektid. See lähenemine lihtsustab ajurünnakuid ja hoiab fookuse kasutajapõhiste lahenduste leidmisel.

• Prioriseerimine ja Teejoonestamine - Discovery etapi põhjal muutuvad prioriseerimine ja teejoonestamine omamoodi mänguks. Lihtsad ja tõhusad meetodid (https://foldingburritos.com/blog/product-prioritization-techniques/), nagu MoSCoW, RICE, Väärtus vs Kulu või Loo kaardistamine, muudavad prioriseerimise sirgjooneliseks, andmepõhiseks ülesandeks. Teejooned aga hakkavad andma parema ülevaate, mis toimub üldises skeemis, mitte killustunud tegevuste nimekirjas, mida on strateegilisest vaatepunktist keeruline mõista. Armastan Productboard'i (productboard.com) teejoone ja prioriseerimise jaoks muide.

• Prototüüpimine ja Kasutajakogemuse testimine - prototüüp (klõpsatav UI disaini makett, mis täpselt kujutab teie tulevast digitaalset toodet) on sinu viimane ja parim viis teha lõplikku testi, et aru saada, kas sinu probleemieelistused, lahenduse väärtuspakkumine, toote soovitavus ja kasutatavus tõesti paikapanevad või on sul veel midagi viimistleda. See on esimene kord, kui kogu lahendus ühilduvalt ühele ekraanile tuleb, muutes selle kasutajatele kergesti mõistetavaks ja andes sügava tagasiside. Mida realistlikum (ilma programmeerimiseta) makett, seda parem. Figma on loomulikult mu lemmik tööriist koos natuke disainerite abiga, kuid InVision oli aastaid mu lemmik, sest seda on lihtsalt nii lihtne kasutada.

• Ettevalmistus arenduseks - siin on väljakutseks lahenduse jagamine hallatavateks arenduse ülesanneteks, hoides tasakaalus detaile ja selgust.

• Ettevalmistus toote turuletulekuks - kas lanseerid selle beetaversioonina väikesele kasutajate grupile ja kogud tagasisidet enne, kui avalikkusele kättesaadavaks teed? Gmail oli beetana ligikaudu 5 aastat. Kas teed vaikselt lansseerimise, et meeskond saaks kiiresti vigu parandada või toimub pärast turuletulekut ka turunduskampaania? Kuidas riske vähendada?

Tootejuhtide juhendamine

Agiilsuse Treenerid võivad kindlasti aidata Toote arendamisel, kuid Tootejuhtide õlgadel lasub terve maailm vastutusi, mis ei pruugi olla seotud Agiilse praktikaga. Tootejuhtide ja Toote Omanike, samuti Ärianalüütikute ja Kasutajauurijate juhendamist peaks ideaalis suunama kogenud Tootejuht. See ei ole aga alati praktikas võimalik. Peamiselt on põhjus praktilisus: Tootejuhid jongleerivad sageli paljude vastutusaladega ja juhivad suurt meeskonda. Paljudel juhtudel ei pruugi need, kes juhivad Toote meeskondi, omada valdkonnas otsest kogemust ja tiimid on mõnikord allutatud IT-le või turundusele, jättes juhi ilma valmisolekuta pakkuda tõhusat juhendamist oma Tootejuhtidele.

Seetõttu eeldatakse minu kogemuse kohaselt sageli, et Tootejuhid on iseseisvad, omades loomulikku arusaamist oma rollist, võimekust identifitseerida oma parendusalasid ja initsiatiivi oma isiklikke professionaalse kasvu plaane arendada ja järgida. See ei ole aga pikemas perspektiivis jätkusuutlik. Kui töötad üksinda, ilma pideva tagasiside või võimaluseta oma tööd koos teise professionaaliga peegeldada, on üllatavalt lihtne arendada pimekohti, märkamata oma erialase kasvu võimalusi. Võid isegi arvata, et oled õppinud juba kõik, mida on teada saada. Olen ise olnud selles olukorras, seega mõistan, milline väljakutse see on.

Usun, et suurepärane lahendus oleks, kui iga Toote meeskond omaks oma meeskonnale pikaaegset Toote Treenerit, nagu paljudes ettevõtetes on igal meeskonnal oma Scrum Master või Agiilsuse Treener. Treener, kes sukeldub nende töösse, pakub mentorlust ja väljaõpet, kui see on vajalik ja mis peamine - annab pidevat otsepuhast tagasisidet tehtud töö põhjal.

Kokkuvõte

Kuigi võime kiirelt ja hõlpsalt arenduse kaudu edasi liikuda koos pühendunud ja motiveeritud meeskonnaga on väga oluline, on see vaid pool lugu. Täiuslikult teostatud Agiilsusmeetodid ei taga üksi edu. Suurepärased tooted tulevad tõeliselt arusaamisest, mida kasutajad vajavad ja teadmist, mida tänapäeva tehnoloogiaga saab teha. Oleks tore, kui võiksid lihtsalt küsida endalt, oma sisemisi sidusrühmi või kliente, mida nad tahavad, kuid selline käitumine viib tavaliselt ainult väikeste muudatuste või kiirete parandusteni, mitte nende suurte, dramaatiliste muutusteni, mida me üritame saavutada, et tõeliselt liikuda edasi.

Investeeri oma Toote meeskondade juhendamisse, et paremini probleeme tuvastada ja paremaid lahendusi unistada. Ma luban, et see tasub ära.