Z blogchainu: 5 ideálov, ako ich pomenoval a definoval Gene Kim v knihe The Unicorn Project
Keď počujem z úst projektového manažéra "však si povedzte, ako to chcete" otvára sa mi nožík vo vrecku.
Nepočúvajme slepo a poslušne, čo máme urobiť. Už nie sme v škole.😄 Zisťujme, prečo to máme urobiť, čo je ten dôvod (problém, výzva, cieľ), ktorú sa snažíme adresovať pomocou softvérového riešenia. Pochopenie potreby, dizajn produktu (služby), produktový manažment je nadmnožinou projektového manažmentu. Ak nemá nikto z tímu formálne rolu produktového manažéra (vlastníka), mal by si ju zobrať neformálne. Stať sa adoptívnym oteckom/mamičkou budúceho softvérového riešenia.
Treba byť k tomu, čo si zadávateľ myslí, že je vhodné riešenie, kritický. Samozrejme, nielen kritický, ale aj konštruktívny. Nemôžem len zhadzovať nápady, požiadavky, potrebujem aj ponúkať alternatívy.
Zákazníci radi používajú tvrdenie "keď to uvidím, poviem, či to je ono". Ok, dajme k dispozícii zákazníkom túto možnosť, iteratívny prístup vývoja ju dokáže adresovať. V neistom prostredí je možné si pomôct ešte pred samotným vývojom namockovaním dizajnu, alebo wireframes, ak miera neistoty, čo sa má stať riešením je vysoká.
It seems more important to please the boss, go to meetings and keep the numbers on track than it is to fix what might not feel broken.
Zdroj: https://seths.blog/2020/12/insulation-from-the-user-experience/
Verím, že vyššie uvedené nie je tvoj prípad.
Kto je to ten zákazník?
- je to stakeholder, ktorý rozhoduje o tom, koľko peňazí do riešenia nalejeme, s tým, že očakáva, že sa v konečnom dôsledku realizáciou riešenia začne šetriť, alebo zárábať viac?
- je to používateľ, ktorý bude s daným riešením priamo interagovať?
- je to konečný platiaci zákazník, ktorý platí za produkt, alebo službu, ktorá je mu poskytnutá a softvér, ktorý práve vyvíjame je nejakou časťou do skladačky, aby sme službu koncovému zakazníkovi poskytovali efektívnejšie, lepšie?
V rámci zákazkového vývoja softvéru sú to všetky 3 skupiny. Tímy, ktoré vyvíjajú svoj vlastný softvérový produkt priamo pre koncových platiacich zákazníkov, môžu inšpiráciu ako (samo)riadiť vývoj hľadať v metóde Shape up.
Ako zladiť vzájomné očakávania?
Moja zásada znie, že user stories má vedieť napísať každý. Nielen analytik, alebo product owner (PO), alebo vývojár. Je to taká spoločná reč, forma pre spoločnú diskusiu. Nechcem, aby sa produktový vlastník (product owner) stal superhrdinom, ktorý je jediný zodpovedný za napísanie každej user story.
User stories sú zápisom návrhu riešenia. Pred tým, než sa pustím do vývoja riešenia, potrebujem pochopiť, čo je motiváciu, pre jeho hľadanie. Job stories sú zápisom pre zachytenie situácie, v ktorej sa zákazník (používateľ) nachádza, a odkrývajú jeho motivácie, kauzalitu. Vďaka popisu štruktúrovaným spôsobom, viem informácie prenieť na zvyšok riešiteľského tímu pre hľadanie, pomenovanie riešenia.
Vedúci pracovníci by nemali byť tí, ktorí rozhodnú a odovzdajú dielčie úlohy. Mali by odovzdavať víziu, a umožniť každému, kto sa na riešení podiela, pridať ruku k dielu, v rámci jeho skúseností ho splnomocniť, a v prípade problémov, pomôcť odstraňovať prekážky, aby sa samotné tímy, mohli realizovať.
Remíza. Ako vyberieme to najlepšie riešenie?
Jake Knapp napísal knihu Design sprint, v ktorej je popísaný kompletný návod, ako vygenerovať nápady na riešenia problémov a výziev, a s jedným konkrétnym aj začať a skúsiť ho zvalidovať. A to všetko v rámci jedného pracovného týždňa. A práve so zameraním na zákazníka.
Pointa Jake-ovej knihy v jednej vete: potrebuje jedného facilitátora, ktorý riešiteľský tím daným procesom prevedie. Jonathan-ovi Courtney-ovi zmenila táto kniha život, fakt, nekecám😄. Tiež napísal šikovnú malú príručku, ako sa stať tzv. workshopperom - Workshopper playbook. Majstrom facilitátorom v riadení workshoppov, ktoré neskončia bez hmatateľných výsledkov.
Apropos, ak ako riešiteľská skupina vygenerujeme viac nápadov, ako si potom vyberieme ten najlepší? Jednoducho: budeme hlasovať. Nie sú to nejaké komplikované techniky. Každý z riešiteľského tímu dostane rovnaký počet bodov, a proste sa návrhy obodujú. Ak by náhodou bola remíza, je potrebné zavolať pre rozhodnutie HIPPO (highest paid person in organisation), a ten by mal urobiť finálne rozhodnutie.
Ak si projektový manažér, týmto reklamným blokom sa Ti snažím povedať len toľko, že nebuď v roli príjmača objednávky, postav sa do role facilitátora, ktorý pomáha (tímu) hľadať riešenie, dáva priestor na vyjadrenie každému, a keď to vypadá, že sa nie je možné pohnúť, použije zdravý sedliacky rozum (facilitačnú techniku), aby situáciu odblokoval.
Nerobme so zákazníka rukojemníka
Hnevá ma, ak dodávatelia softvérových riešení slepo naimplementujú pre zákazníka blbosť, a potom z neho ešte vyťahujú peniaze zmenovými konaniami.
Potrebujeme odkryť, pochopiť, akú hodnotu sa snaží zákazník dopytovaním riešenia adresovať. Ak napríklad pochopím, zistím, že reálna projektovaná úspora, ktorú zákazník získa automatizáciou je 10 000 eur/mesačne, tak na základe toho dokážem, lepšie operovať s možnými alternatívami, ako keď to bude 1000eur/mesačne. Snažme sa odkryť na akej škále zákazník operuje, aby sme mu neponúkali vesmírne technológie, keď potrebuje len upratať svoj vlastný proces.
Ak ste partner pre svojich zákazníkov (pre ktorých dodávate SW riešenia), akékoľvek obvinovanie 3tích strán (iných dodávateľov), treba pustiť z hlavy. Neni som naivný, že sa nestanú situácie, ktorým by sme sa radšej vyhli. Treba dať hlavy dokopy a pozrieť ako sa takýmto situáciam do budúcna vyhnúť.