Sú situácie, kedy (snaha o) detailné plánovanie v rámci softvérového vývoja má zmysel. Nenaplánovať si napríklad kroky pre migráciu, ich logickú nadväznosť, teda nemať plán pre takúto činnosť, nie je vôbec dobrý nápad.

Úlohy, v rámci softvérových projektov možno rozdeliť do dvoch skupín:

• tie ktoré si viem predstaviť (že bude treba urobiť) - imagined tasks - čím viac skúsenosti máš, tým lepšie si vieš "predstavovať"
• tie ktoré objavím počas realizácie - discovered tasks - v komplikovaných alebo komplexných systémoch si môžeš predstavovať koľko chceš, nedáš to na 100%. Hlavne, vždy Ťa tlačí čas. Nemôžeš sa pripravovať, plánovať, donekonečna.

Je omnoho menej stresujúce, ak viem, že migrácia, ktorá má prebehnúť v stanovenom časovom rámci, postupuje podľa plánu, a keď aj objavím (discover) počas jazdy novú úlohu, tak sa mi sa lepšie dáva do kontrastu s niečím fixovaným (mojím migračným plánom).

Myslieť si však, že v úvodnej fáze projektu (v rámci PRINCE2 iniciačná fáza) superhrdina projektový manažér spolu s tímom zorchestrujú dokonalú WBS-ku je z mojich skúseností nemožné. Takáto WBS-ka automaticky trpí tým, že do nej je pridaná vata, keby sa náhodou niečo nestíhalo, alebo sme na nejaké úlohy zabudli (cost of delay v priamom prenose).

Identifikácia klúčových úloh

Ako večný optimistia, si samozrejme na začiatku projektu myslím, že sa všetko podarí. Ale CEO nezabudne položiť obľúbenú otázku: A kedy to bude?

Používam tieto aktivity, aby som sa dostal k roadmape, ktorá reprezentuje špecifický druh plánu:
1) identifikovať základné okruhy funkcionalít (epics)
2) identifikovať role (aj robotov), ktoré s budúcim softvérovým riešením budú interagovať
3) rozbiť na základné okruhy funkcionality do user stories
4) identifikovať integračné závislosti

Postup v týchto aktivitách nie je výsostne chronologický. Človek preskakuje z jednej aktivity na inú, dopĺňa a modifikuje jednotlivé artefakty (epics, user stories, roles, integrations).

Eposy sú niekedy výsledkom syntézy. Reflektujúc cieľ projektu, už realizačnému tímu začnú preblikovať možné spôsoby riešenia. Potrebujeme manažment objednávok, potrebujeme vystavené faktúry automaticky zaúčtovať, ...  Eposy majú za úlohu dať do spoločných mantinelov konkrétne funkcionality definované pomocou user stories. Niekedy dostaneme epos rovno na stôl. Zadávateľ (zvyčajne CEO) príbehne rovno s návrhom na riešenie (potrebujem aplikáciu na manažovanie dodávateľov), čo je samo o sebe epos. Netreba však hneď skočiť na analýzu a rozbitie na user stories, kým sa kriticky nepozriem na to, prečo. Ono, väčšina CEO má samozrejme pádne a zmysluplné dôvody, ktoré nechcem principiálne spochybňovať. Ale CEO v snahe byť super efektívny, nechcú zdržovať detailami, a dôvodmi. Tie sú však perfektným referenčným bodom počas celého snaženia identifikácie spôsobu riešenia. Približuje nás to, čo sme navrhli, k odstráneniu problému, ktorý má CEO?

Takmer žiaden systém (aplikácia) neexistuje vo vákuu, je závislý na informáciach (dátach) z iných systémov, alebo má informácie iným systémom poskytovať, takže treba jednoduchým spôsobom (diagram s krabičkami a šípkami) zdokumentovať očakávané dátové toky. Obdĺžnik - predstavuje izolovanú aplikáciu, a šípky - predstavujú dátový tok/výmenu.

Prioritizácia

Ak už som v štádiu, že môj zoznam user stories, identifikovaných rolí a predpokladaných integrácii, je ako tak stabilizovaný, môžem pristúpiť k dvom aktivitám:
1) identifikácia kľúčových funkcionalít (čo)
úprimne si odpovedať, či je fakt nevyhnutné tú ktorú user story implementovať, aby celé riešenie zafungovalo. Ja zvyknem používať prioritizovanie pomocou číslovania (1 - musí byť, 5 - nice to have), v praxi sa často používa aj MoSCoW - Must, Should, Could, Would. Ak sa prichytíš, že nejaká funkcionalita je mixom Must/*, tak sa nebráň rozbiť user story tak, že obsahuje iba nevyhnutne minimum (Must) a ostatné (Should/Could/Would) sa dostane do samostatnej story s nižšou prioritou.
2) časové zarámcovanie (kedy)
Ak zoberiem všetky Must funkcionality, tak viem, čo nevyhnutne musím urobiť, aby riešenie začalo prinášať hodnotu. Ak si počul skratku MVP, minimum viable product, tak sumár Must funkcionalít je práve jeho stelesnením.

Odhadovanie

O odhadovaní (čo je predispozícia pre plánovanie) softvérových projektov bol napísaný nespočet kníh, blogov a alchymistických príručiek. Ja sa držím dvoch prístupov, ich kombinácie:

• "expertný" odhad
• time box

Nechcem byť úplne vo vzduchoprázdne, a ani nahrubo nemať šajn, koľko niečo môže trvať. Je lepšie mať aspoň niečo ako nič, a tak si môžem expertný odhad stanoviť: jedna user story bude trvať programátorovi dva dni (prvý deň kým ju pochopí, premyslí, druhý kým ju dotiahne). Ak si chceš preštudovať ako k odhadovaniu pristupuje agilný svet, tak neváhaj a daj do google výrazy ako: story points, t-shirt size, velocity, planning poker...

Moja rada vyššie je v rámci prvých nesmelých pokusov o odhad "len" hypotéza. Psst, odhad je vždy len hypotéza. Ak si v informačnej nevýhode, respektívne nemáš chuť robiť rozborku toho, ako dlho by sa mal implementovať jednoduchý formulár v REACTe, je vo všeobecnosti lepšie použiť timebox.

"Expertný" odhad urobí vývojar (dodávateľ), ty definuješ mantinel: čo mi viete realizovať za timebox (napríklad prvú iteráciu, či už bude 2 týždňová, alebo dlhšia)?

Ak niekomu nastavíš mantinel, začne aplikovať prioritizáciu, a zároveň táto dynamika podporuje hľadanie alternatív (áno, aj workaroundov), resp. človek získava spätnú väzbu v zmysle, že " toto nie je možné urobiť" (v danom čase).

Ak idem do Tesca kúpiť rožok, tak viem, čo za tých 10 centov dostanem.
Jasné, že softvérové riešenia, nie sú rohlíky, ale ak sa softvérová firma špecializuje (robí napríklad výhradne PrestaShop eshopy), tak sa ich proces výroby eshopového riešenia a manažment potrieb zákazníka začína približovať výrobe rohlíka. Preto generické softvérové domy majú v mojej optike nevýhodu voči tým, ktoré sa špecializujú. Špecialisti sa vedia zaviazať k tomu, že očakávaný výsledok dodajú aj v kratšom čase, keďže je to ich denný chleba. Ja potom ako zákazník zase nemôžem slepo žiadať od nich cenu referovať na time&material. Oni mi nepredávajú len svoj čas, oni mi predávajú aj skúsenosti, ktoré rokmi nadobudli.

Ako platiaci zákazník, ktorý obstaráva riešenie dodávateľsky, je mi v princípe jedno ako si dodávateľ vypočíta náklady (na scope). Mňa zaujíma viac hodnota, prínos, ktorá mi bude dodaná. Ak si začnem hovoriť, že peniaze, ktoré som nalial do riešenia sa mi prestali zhodnocovať, je to začiatok konca vzťahu s dodávateľom, ak nepríde k zmene. To je memento k tomu, že riešenia (dodávky) majú slúžiť, nie byť slepo realizované.

Roadmapa

To k čomu sa ja snažím dopracovať teda nie je dokonalý plán na dni. Snažím sa dopracovať k roadmape, ktorej časová granularita je maximálne v týždňoch, zvyčajne v mesiacoch, na ktorej sú zachytené eposy (s logickou následnosťou).

Roadmapa nie je vytesaná do kameňa, práveže ju potrebujem aktualizovať reflektujúc to, čo sa už udialo. Agilný prístup je práve o tom, že reflektujem, to čo sa udialo a na základe toho mením smerovanie, priority.

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úť.

Z blogchainu: 5 ideálov, ako ich pomenoval a definoval Gene Kim v knihe The Unicorn Project

Naformátovaní na obavy

Škola nás (bude nás asi stále dosť) "naformátovala", že robenie chýb sa trestá. Strach z urobenia chyby nás následne rôznymi spôsobmi paralyzuje. Škola nás nastavila, aby sme vyhoveli požiadavkám autorít (zvládnuť test), nie aby sme sa zameriavali na riešenie problémov (v ktorých riešení vidíme sami zmysel, potrebu). Táto istá dynamika prenesená do pracovného prostredia znamená, že dosť veľa energie venujeme tomu, aby sme  v rámci politických manévrov v kancelárii (office politics) niekomu nestúpili na otlak alebo sa mu snažili zapáčiť.

Túto energiu by bolo vhodnejšie presmerovať do spoločného riešenia problémov, a nastaviť sa tak, že si vzájomne dôverujeme. A ak sa aj nejaký výkuk v tíme nájde, tak ho v rámci spoločných retrospektív - pravidelná reflexia dobrého i zlého z posledného obdobia za účelom identifikácie udržiavacích/nápravných opatrení - postavíme na svetlo sveta.

Nechcem Ťa tu motivovať, aby si sa bezhlavo vrhal na akýkoľvek problém bez rozmyslu, bez váhania veril svojim inštinktom. Ale ak sa prichytíš pri obavách, skús si dať odstup a racionalizovať, aký je možný najhorší scenár.

Počet takých, čo dosahujú dobré výsledky pod stresom, alebo v strachu, sa limitne blíži k nule. Potrebuješ byť v pohode. Ak máš šéfa, čo Ťa "straší" (teraz tým nemyslím až mobbing), tak ho buď pošli do hája (odíď), alebo prečítať si tento článok.

Blameless postmortem

Ak sa stane chyba, tak ako tímoví hráči, nehrajme blame game "za to môže Karol!". Ako tímoví hráči sa pýtajme, čo môžeme urobiť do budúcna, aby sa taká situácia neopakovala. Čo sme mohli urobiť inak, ešte skôr ako sa táto chyba stala. Ako môžeme túto chybu do budúcna eliminovať systémovo.

You are in an organization where everyone is making decisions, solving important problems every day, and teaching others whay they’ve learned… Your victory is inevitable.
Zdroj: The Unicorn project

Bezpečné prostredie je charakterizované tým, že:

• nemáš problém povedať, že máme (niekde) problém. Že sa neobávaš toho, že budeš za Ťa za to šéf pokefuje, alebo sa kolega bude cítiť dotknutý.
• nemáš problém povedať "ja neviem". Aj keď si šéf.
• máš priestor sám robiť rozhodnutia, a ak by aj boli zlé, tak neskončíš hneď "na koberčeku".

Hľadanie zmyslu (života)

V knihe Hľadanie zmyslu života Viktor Frankl popisuje svoje osobné skúsenosti z koncentračného tábora. Jeho "zážitky" sa stali základom pre logoterapiu (doslovne povedané liečenie cez zmysel). Všetci jeho spoluvezni, ktorí v nejakom okamihu svojho pobytu v koncentračnom tábore stratili zmysel svojho života (aj keď v danej situácii vypadal ako veľmi ťažko dosažiteľná méta), sa zakrátko stali obeťami (zomreli).

Cez tento veľmi zvláštny záver Ti chcem len pripomenúť: čo je tým zmyslom v tvojej práci? Je to riešenie konkrétnych výziev (problémov) v bezpečnom priestore, samozrejme nie však úplne bez rizík, alebo manévrovanie na hranici strachu a psychologického vypätia v nevyspytateľnom vesmíre kancelárskej politiky?

Z blogchainu: 5 ideálov, ako ich pomenoval a definoval Gene Kim v knihe The Unicorn Project.

Lean sa zameriava na to, aby sa veci riešili tak neskoro ako to je možné, tok hodnoty nebol prerušovaný, a eliminovali sa všetky kroky navyše - odstraňovalo plýtvanie. Mne aplikácia lean princípov aj do procesu tvorby hodnoty za pomoci softvérových riešení dáva zmysel.  Nemožno ju však okopírovať 1:1.

Daily work is less important as daily work improvement.

Opäť sa odkážem na lean výrobu (aj keď teda tvorba softvéru nie je fabrika), a pripomeniem, že bežná denná práca je menej dôležitá, ako investícia do vylepšovania mojej dennej práce.

Andon

V rámci systému kvality Andon má každý operátor na linke možnosť “zastaviť výrobu”, a jeho supervisor má práve čas taktu (často menej ako 1 minúta), na to, aby problém vyriešil, inak sa zastaví celá výrobná linka.
To len malá pripomienka toho, že je dôležité sa venovať “maličkostiam”, ktoré ovplyvňujú moju každodennú prácu. A všetko, čo znehodnocuje tok hodnoty (vykazuje známky plýtvania) sa snažiť odstraňovať.

V knihe Making Work Visible Dominica DeGrandis identifikovala 5 neduhov, ktoré ovplyvňujú nielen našu (pracovnú) efektivitu, ale aj emočnú alebo psychologickú bezpečnosť:
a) veľa rozpracovaných veci - Work in progress (WIP)
b) neznáme závislosti - Unknown dependencies
c) protichodné priority - Conflicting priorities
d) zanedbávana práca - Neglected work
e) neplánovana práca - Unplanned work

Nech si akokoľvek budeš myslieť, že dokážeš pri svojej práci efektívne multitaskovať, musím ťa vyviesť z omylu. Prehnaným prepínaním kontextu strácaš pozornosť, ktorú musíš znova nadobudnúť, oberáš sa o možnosť vstúpiť do stavu pohltenia (flow), a z dlhodobého pohľadu si koleduješ o vyhorenie.

To, že funguješ ako Yes-man, ktorý na každú požiadavku povie áno, čo mu vygeneruje zásobu úloh na najbližších pár rokov, nie je nikoho iného problém, len tvoj vlastný. Treba sa naučiť hovoriť nie.

Každá závislosť Ťa chceš, či nechceš, limituje. Tá, o ktorej najprv nevieš, a dozvieš sa o nej neskoro, je tým najlepším nepriateľom tvojho plánovaného postupu pri riešení úlohy. Tu si samozrejme nedávam na nos ružové okuliare ako bežný waterfallový projekták, ktorý ťahá gantt charty, ako keby všetku prácu bolo možné naplánovať (imagined tasks), a žiadnu sme počas projektu neobjavili (discovered tasks). Áno, áno, ten skúsenejší, si tam dá vatu. Ale, že tou umelou vatou je pôvodný plán z 3 mesiacov umelo nafúknutý na 6, má tiež svoje potencionálne náklady (cost of delay). Ach, odbáčam.

Každopádne, keď sa do koktailu veľa rozpracovaných veci s nejasnými závislosťami pridajú protichodné priority, človek má chuť sa na to všetko vybodnúť a ísť sa pozrieť na profesiu. Klincom do rakvy je (v prípade vývojarov) už len neustále hasenie požiarov (neplánovaná práca) prevažne spôsobené nedostatočným adresovaním technologického dlhu (zanedbávaná práca).

Čo je však riešením vyššie uvedených problémov? Ako prezrádza titul samotnej knihy. Urobiť prácu viac viditeľnou. Ale ako?

Kanban

Jedným z konkrétnych nástrojov je kanban tabuľa, v rámci ktorej sú aplikované limity pre WIP a má minimalistické horizontálne a vertikálne členenie. Neexistuje univerzálne odporúčanie ako urobiť/nastaviť kanban tabuľu na prvú dobrú. Proste treba začať, a postupným upravovaním (vylepšovanim) ju vylaďovať. Tabuľa môže reflektovať prácu mňa ako jednotlivca, kde pravdepodobne použijem pre horizontálne členenie iné kategórie, ako na súhrnnej tabuli sumarizujúcej úlohy celého tímu.

Kanban tabuľa nemá nekončený rozmer (najmä fyzická, digitálna už sa dá viac zbastardiť). Ak toho dáš na kanban tabuľu veľa - či už štruktúrou alebo obsahom, začne tam byť neporiadok, čo je mimochodom dobrý vizuálny signál, že je treba upratať (odobrať niečo).

Nebudem si klamať, že napriek nastaveným limitom, a riadeniu prietoku toho, čo sa na tabuľu dostane, sa nikdy nestane výnimka, nepríde HiPPO (highest paid person in the office), ktorý bude chcieť riešiť svoj problém bezodkladne. Na to zvyknem vždy do tabuľe rovno dávať priority line.

Snáď nemusím páliť čas na popísaní základných príncípov fungovania kanban boardu, je toho plný internet. Ale, ak máš akekoľvek otázky, kľudne ma kontaktuj.

The Way We’ve Always Done It

Len toľko som chcel dnes. Nedržme sa hesla: však takto to tu robíme odjakživa.

Z blogchainu: 5 ideálov, ako ich pomenoval a definoval Gene Kim v knihe The Unicorn Project.

Chcem krvopotne (za každú cenu) riešiť efektivitu, alebo byť radšej štastný človek?
Poznáš ten pocit, ked veci neodsýpajú? A poznáš ten pocit, keď odsýpajú?

Myslím, že tvoja preferencia bude vždy tá neskôr menovaná (byť štastný, byť v stave, keď veci odsýpajú).

Ak si bol niekedy v automobilke na exkurzii, alebo si pozeral dokument o tom, ako celý megakolos na vyrobenie auta, ktoré je bežne z 30000 komponentov, a ktoré apropos nesedia v sklade a čakajú kým z nich niekto sfúkne prach, funguje, tak si bol svedkom dokonale vyladeného komplexného systému.

Tvorba softvérových riešení v Dobe softvérovej nefunguje na štýl fabriky na výrobu áut, ktorá dotiahla svoj lean proces výroby do nepríčetna a urobila z ľudí robotov, ozubené kolieska veľkého systému, ktorých je možné ľahko nahradiť kus za kus.

Môj flow

Tak ako je dobré vyhodnocovať kvalitu toku hodnoty (flow) na úrovni firmy je dobré sa pozerať na ňu aj na mikro úrovni (u seba). Profesor Mihaly Csikszentmihalyi o flow píše vo svojej knihe, ako o stave, v ktorom keď sa nachádzame, sa cítíme štastní.

Preto si je dobré položiť otázku: Čo konkrétne ma od toho štastia (v práci) oddeľuje? Aké vyrušovače a nepotrebné kroky mi degradujú flow? Ako môžem do svojich návykov zaradiť malé (zdanlivo nepatrné) kroky, ktoré však kumulovane vytvoria zdravý návyk (správanie mňa samého, alebo môjho okolia)?

Úlohou šéfov, lídrov, manažérov je dbať o pocit naplnenia a šťastia svojich kolegov. Veľa sa hovorí o work/life balance. Ono sa to u vedomostých pracovníkov (knowledge worker) ako napríklad projektový manažér, programátor, analytik, nedá veľmi ten pracovný a súkromný život oddeliť. Oni sa tie dva životy vzájomne ovplyvňujú, a treba k prípadným nenaplneným očakávaniam zo strany profesného života, brať do úvahy aj súkromný život.

Od projektu k produktu

Koľko plýtvania vzniká, keď prepínaš kontext? Ako plynulý je tok (flow), ak musíš bootovať vždy do novej témy? Cítiš sa kompetentný k niečomu sa vyjadrovať, keď to poznáš povrchne?

Nedávno (máj 2020) som na jednom webinári  o nástrojoch na projektové riadenie od Microsoftu započul otázku jedného z účastnikov webinára na to, či dané (prezentované) nástroje budú schopné pokryť 2 ročný projekt s 50 programátormi (otázka smerovala voči avizovanému, ale neupresnenému limitu nástroja na počet konkuretných používateľov, členov projektových tímov).

Meniť enterprise architektúru formou veľkých transformačných projektov je možné. Ale pravdepodobnosť úspechu týchto projektov je podstatne menšia, riziko, že doručia hodnotu a stávka podstatne väčšia.

Ja by som vylepšoval enterprise architektúru nie formou (veľkých) IT projektov, ale po menších častiach. Od veľkých projektov prejsť k mikro-projektom, až samotnú starostlivosť o staranie sa o enterprise architektúru a jej schopnosti (capabilities) zveriť do rúk tímom, ktoré sa špecializujú na danú časť/oblasť tvorby hodnoty, tímy ktoré danej problematike rozumejú (po biznisovej stránke). Koncept, že skladám vždy ad-hoc projektové tímy pre doručenie hodnoty,  prináša viac frustrácie, ako prístup, ak mám existujúce tímy okolo produktov (tvorby hodnoty).

..utilizing persistent teams who support a product or service, a change that might best be shortened from “building teams around work” to “bringing work to existing teams.”

Hering, Mirco. DevOps for the Modern Enterprise (p. 143). IT Revolution Press. Kindle Edition.

Asi sa nájde pár jedincov, ktorí preferujú neustálu zmenu, chcú sa stále zúčastňovať nových projektov. Efektivitu, ale aj spokojnosť (teda stav flow), majstrovstvo, autonómnosť zabezpečím tým, že ľudia sa venujú konkrétnym hodnotovým tokom, ktoré firma má. Nie že preskakujú z jedného na druhý. Keď majú príležitosť pochopiť hlbšie súvislosti, a prečo to robíme.

Inak povedane to znamená, že sa zameriavajú na riešenie a podporu konkrétnej aplikácie (alebo skupiny aplikácii, systémov), ktoré sú súčasťou enterprise architektúry. A tieto v rámci celofiremných iniciatív následne modifikujú, aby bolo možné celofiremné iniciatívy doručiť.

Z blogchainu: 5 ideálov, ako ich pomenoval a definoval Gene Kim v knihe The Unicorn Project.

Jeden môj kamoš zvykol používať svojho času takúto hlášku:

To je nadlho a komplikované.

To bola univerzálna odpoveď, keď on sám nevidel východisko zo situácie, v ktorej sa nachádzal, alebo práve naopak, z jednoduchej situácie (problému) urobil z komára somára.

Vieš aký je rozdiel medzi komplikovanýcm a komplexným? Komplexné je porozumiteľné, i keď je zložené z viacerých úrovni (vrstiev). Komplikované je už horšie porozumiteľné, lebo vzájomné pôsobenie prvkov systému nie je možné jednoducho alebo v rozumnom čase rozlíšiť.

❓Koľko ľudí je potrebných zapojiť do procesu realizácie zmeny softvérového riešenia?
❓Máš pocit úzkosti, keď má byť nasadená zmena v softvérovom riešení?

Ideál jednoduchosti ma za cieľ pripomínať, že sme si niektoré pracovné postupy prekomplikovali (organizačná komplikovanosť). Že naše technické riešenia majú vysoký technický dlh, a keď v nich chceme spraviť zmenu, tak to bolí, alebo to vlastne už ani nie je možné (technická komplikovanosť).

Ak riešenia navrhujeme jednoducho, táto jednoduchosť podporuje lokálnosť.
Lokálnosť?! Lokálnosť znamená, že nepotrebuješ pre vykonanie rozhodnutia n povolení, alebo pripojiť tu telekonferencii 5 achitektov a analytikov, aby sa v konečnom dôsledku vyjadrili, ako sa to nedá, alebo len s veľkými obtiažami.

if a team couldn’t be fed with two pizzas, it was too big.
Jeff Bezos

Aplikácia jednoduchosti a lokálnosti po organizačnej stránke je napríklad pravidlo tzv. 2 pizza tím - stačia ti dve pizze, aby si nasýtil tím ľudí, ktorý by mal vedieť problémy a výzvy samostatne riešiť? Ak nie, tak tvoj tím je pravdepodobne príliš veľký, aby fungoval efektívne.

Aplikáciou jednoduchosti po technickej stránke je napríklad princíp jednej zodpovednosti a voľných väzieb.  Majestátny monolit má svoje miesto v sieni slávy vývoja softvérových riešení. O tom inokedy. Je však potrebné si
na pomyselnej škále od monolitu až po microservices architektúru na každú malú IT capabilitu, klásť opakovane otázky:

• nepreháňam to už s prípravou na potencionálne škálovanie?
  alebo opačne
• netlačím kopec funkcionality do jednej megaaplikácie (monolitu), ktorá by si už zaslúžili, aby bola vytiahnuté do samostatnej služby?

Koľko dní, týždňov, mesiacov ubehne od iniciálnej myšlienky na zmenu až po jej nasadenie do prevádzky? (flow time) Ak je tento čas neprimerane dlhý, tak výsledkom je strata príležitosti šetriť, alebo zarábať (cost of delay), alebo sa jednoducho rýchlo niečo naučiť (objaviť, dozvedieť), frustrácia z nevyhnutnej potreby prepínať kontext (tu čakám, tak idem zatiaľ na iné zadanie).

Treba si neustále pripomínať, či si organizačne nehádžeme polená pod nohy (treba chodiť cez 5 úrovní, aby bolo možné zmenu/vylepšenie nasadiť, uvedomenie si hodnoty pre zákazníka). Či sa po technickej stránke neprichytíme v stave úzkosti, že plánovanou zmenou sa rozbije nejaká neznáma vnútorná závislosť (ktorá z tej spleti kódu nie je jasná).

Inak povedané, môžeš aplikovať dve základné pravidla:

• snažiť sa potreby pokrývať jednoduchšími riešeniami. Skôr sa snažiť uberať/prerobiť to čo už mám, ako pridávať nové a ligotavé (ktoré sa po nasadení do života okamžite stáva novým "bohatým" dedičstvom - legacy)
• snažiť sa zachovať môžnosť rozhodnúť sa lokálne (mať zodpovednosť a rozhodovaciu právomoc od nadriadeného, pýtať sa, čo na kom som závislý a prečo, vedome tvoriť menšie tímy)

Myslím, že ste sa už stretli s tvrdením, že vlastne zákazníci nevedia, čo potrebujú. Respektíve ich návrh na riešenie je krátkozraký.

If I had asked people what they wanted, they would have said faster horses.(Vraj) výrok Henry-ho Forda.

Inak povedané. Nechcem sa zákazníkov (používateľov) pýtať,  čo by potrebovali - aké riešenie navrhujú, ale pochopiť podstatu ich problému - situáciu v ktorej sa nachádzajú.

Dnes opäť o teórii Jobs-to-be-done (JTBD), ktorá pomáha lepšie odhaliť motivácie, kontext a kauzalitu, vďaka čomu dokážem lepšie adresovať riešenie (inovovať).

All I want for xmas is progress

Každý človek má potrebu napredovať. Stať sa lepšou verziou samého seba. Samozrejme naše životné hodnoty a skúsenosti definujú, čo si pod týmto napredovaním (progress) každý predstavíme.

Teória JTBD sa snaží empiricky odhaliť "práce" (jobs), pre ktoré ako zákazníci "zamestnávame" (hire) konkrétne riešenia.

Aby sme príčiny (ne)záujmu o naše produkty (služby) neodhalovali náhodne (gut feeling, pokus/omyl), ale skôr k tomu pristúpili ako inžinieri, môžeme aplikovať túto teóriu.

Typy customer jobov

Práce (jobs) je možné rozdeliť do 3 základných kategórií:

• funkčné (functional) - chcem niečo konkrétne dosiahnuť
• emocionálne (emotional) - chcem sa nejako cítiť
• sociálne (social) - chcem byť nejako vnímaný ostatnými

Čo bráni napredovaniu?

Pri zamestnaní nového riešenia na môj job som vystavený 4 rôznym silám, ktoré ovplyvňujú, či chcem zamestnať nové riešenie. Sily možno rozdeliť do dvoch kategorií:

I. Motivujúce:

• push - aktuálna situácia, problém, ma tlačí do hľadania nového riešenia (narodenie dieťaťa)
• pull - samotné riešenie ma magnetizmus, atribúty, ktoré ma priťahujú (napríklad chcem nové auto, aj keď to staré stále slúži)

II. Demotivujúce:

• obavy (anxieties) - pre zmenu riešenia si často kladiem otázky, čo sa stane ak, zmením
• zvyky (habits) - moje návyky ma udržujú v status quo

Narodenie dieťaťa je spúšťačom, ktorý ma tlačí hladať nové riešenia pre moju situáciu. Napríklad začnem sa pozerať po väčších autách, keďže mám problém poskladať kočík do svojho kabrioletu.
Pri narodení dieťaťa sa zvyčajne rýchlo zbavujeme svojich pôvodných zvykov, lebo situácia je taká intenzívna, že aj naše pôvodné obavy sa teraz presmerujú úplne na inú úroveň.

It’s really an engineer’s way of looking at the market.
http://jobstobedone.org/radio/unpacking-the-progress-making-forces-diagram/

Všetko, čo mi bráni adaptovať nové riešenie na môj job sa prejavuje demotivujúcimi silami (obavami a zvykmi). Pre to, aby som zákazníkovi, nove riešenie "predal", potrebujem adresovať aj tieto sily.

Ak som napríklad projektový manažér, ktorý rieši migráciu nejakého systému na iné riešenie, môžem sa obávať o to, ako prebehne migrácia. Svedomitý riešiteľ sa preto bude proaktívne pýtať, alebo ponúkať riešenie na to, z ktorých nástrojov dokáže migráciu zabezpečiť už dnes, alebo ak je aktuálny systém neznámy, proaktívne bude túto obavu adresovať.

Job story

Job story zápis vymyslel Alan Klement spolu s ľudmi so spoločnosti Intercom. Predpis je nasledovný:

(role/context) When (in situation) I want to (motivation) so I can (outcome)

Konrétne príklady:

(som matka) Keď sa mi narodí dieťa chcem maximum podpory od štátu, a aby to bolo bez okolkov, a ja som sa mohla venovať dieťaťu.

(som dispečer)  Keď vznikne nová objednávka na vyzdvihnutie zásielky na odoslanie chcem vedieť o tých, ktoré je problém zrealizovať, aby som mohol proaktívne kontaktovať odosielateľa.

💡Persóny ako point in time snapshoty nie sú veľmi osožné. Rozhodovanie o "zamestnaní" riešenia nie je definované primárne mojimi atribútmi (muž, do 40 rokov, VŠ vzdelanie, zapadné Slovensko). Je definované situáciami, v ktorých sa nachádzam, je postupne formované na časovej osi (timeline).
Job story služia ako efektívny spôsob zachytenia potreby, ktorú majú (budúci) používatelia nášho riešenia. Pre dizajn riešenia zachytávajú kontext, kauzalitu a motivácie.

Hľadanie jobu

Nie nevyhnutne platí, že pre adresovanie jobov (hľadanie riešenia) musíme začať "na začiatku".

Môžeme mať aj super nápad na riešenie, ktorý vybublal na svetlo sveta vďaka našim doterajším skúsenostiam a vedomostiam.
Dodatočné zarámcovanie voči jobu nám však pomôže často neskôr v rozhodovaní, čo do súboru funkcionalít (riešenia) pridať, alebo nie. Na čo sa máme sústrediť, aby sme adresovaný job ešte lepšie obslúžili.

Toto je jedno z riešení, ktoré odporúčam aplikovať pre udržanie projektu v dobrej kondícii.

Na aktualizácie ohľadom víťazstiev, alebo zásadnejších prekážok odporúčam udržiavať pulz projektu pomocou tlkotov (heartbeats). Tlkoty sú krátke písomne aktualizácie, ktoré sa týkajú projektu. Ak sa nič nedeje, tak tlkot napíše na pravidelnej báze (týždennej, obtýždennej) projektový manažér, ale nič nebráni aj inému členovi tímu prispieť. Je to ekvivalent steny facebookovej stránky venovanej výhradne projektu a vecí s ním súvisiacich.

Aký sú joby, ktore riešenie "tlkot" adresuje? Tu sú dva konkretné príklady, ktoré je možné s riešenia vyčítať:

Keď som členom projektového tímu, chcem mať k dispozícii všetky aktualizácie pre kľúčové informácie, aby som vedel robiť správne rozhodnutia podľa aktuálneho kurzu projektu.

Keď mám novú kľúčovú informáciu hodnú zdieľania, mám skúsenosť, že email je čierna diera, v ktorej to zapadne, chcem ju oznámiť tímu, aby ju zobrali na vedomie.

Situáciu je možné ešte okoreniť takto:

Keď skončím meeting s klientom, šoférujem v aute, neviem písať, iba rozprávať, a mám novú kľúčovú informáciu hodnú zdieľania, chcem ju oznámiť   tímu, aby ju zobrali na vedomie.

A ako je (už len pre refenciu) možné zapísať už konkrétny návrh riešenia formou user story - predpis: As a (user) I want (result) so that (benefit)?
Kde tu osolené akceptačnými kritériami (viď odrážky).

As project manager I want to share information with my team so that they stay informed

As project manager I can set priority of information to ensure that cricital one are acknowledged

As project's team member I want to be aware with all critical information about project
- email notification is not expected solution
- stream of all critical information in chronological (DESC) order

As project't team member I'm able to confirm "message received" for  critical information distribution

As project manager I'm aware of all team members which not yet confirmed "message received"

Používať job story pomáha tomu, aby som kontext, motivácie a kauzalitu efektívne zdokumentoval pre seba, aj ostatný tím pre hľadanie riešenia. Vďaka tomu sa pri hľadaní riešenia zodpovie veľa otázok, riešenie sa nasmeruje na adresovanie tých najviac vypuklých trápení. A odpovie aj na obľúbenú na otázku: prečo sme to takto urobili? 😄

Ak Ti sú známe 4 piliere agilného manifesta, potom pochopíš, prečo (z)brojím proti siahlodlhým dokumentáciam, plánom... keďže sa vo väčšine softvérových projektov nachádzame v prostredí neistoty, nie je efektívne tráviť veľa času teoretizovaním - písaním 30 stranového wordu, ktorý pôjde ešte na 3 schvaľovacie kolečká, a potom sa vráti ako 60 stranová funkčná špecifikácia.

Je lepšie konať. Ja viem, že sa to môže javiť ako prílišné zjednodušovanie. Ok. Ale fakt si treba opakovane pokladať otázku ako štíhly je proces, ktorý zabezpečuje riešenie od vzniku potreby. Ako dlho trvá, kým sa (dobrá) idea stane skutočnosťou?

Čo je WD-40 pre softvérové projekty?

Kto netuší, čo je WD-40, tak šup, pozrieť stránku výrobcu.

WD-40 Multi-Use Product protects metal from rust and corrosion, penetrates stuck parts, displaces moisture and lubricates almost anything.
Zdroj: https://www.wd40.com/

Tak ako je WD-40  schopné rozhýbať niečo zahrdzavené (zaseknuté), ako je schopné zároveň hrdzaveniu (zaseknutiu) zabrániť, tak je kontexte softvérového projektu možné nájsť artefakty, postupy a odporúčania, ktoré pomáhajú efektívnejšie zabezpečovať tvorbu hodnoty  - funkčný softvér (viď hodnota č. 2 agilného manifesta), eliminovať plýtvanie.

Dnes sa pozrieme bližšie na detail artefaktu: user story. Internety sú plné vystvetlení, čo je user story. Ja som sa tomu tiež venoval, a rovnako som písal ako o tom, ako napísať dobrú user story).

User story je z môjho pohľadu neukecaná dokumentácia toho, čo biznis potrebuje z pohľadu rolí (aktérov), ktorí s aplikáciou (systémom) interagujú. Plus, okrem toho, že to je efektívný spôsob popísania to be stavu, a rovnako po doručení sa stáva zoznam user stories aj efektívnym prehľadom stavu as is (toho čo máme, aké už funkcionality už naše softvérové riešenia majú).

Kde použiť user story?

IMO, všade tam, kde sa popisuje interakcia bežných ľudí so strojom. V ľudskej reči pisujem, čo očakávam, že bude na vstupe a čo dostanem vo finále na výstupe. Zároveň nič nebráni tomu, aby sa aj zo stroja stal "človek", a jeho úlohy boli zaznamenané v tejto forme.

As robot I sent automatic email reminders about not paid invoices to ensure better cashflow.

Doména doma

Ak Ti softvérové riešenie dodáva externý partner, ak user stories tvoríš, vieš vytvoriť, (s)poznáš lepšie svoje problémy, aj (potencionálne) softvérové riešenia. S user story preberáš viac porozumenia vlastnej doméne na seba. Ako biznisový problém alebo výzva sú dopytom po po riešení, je práve riešenia zadokumentovávané vo forme user stories ponukou na tento dopyt. Ty nepotrebuješ vedieť softvér vytvárať (byť prográmatorom). Áno, je dobré ak poznáš diely, z ktorých programátori riešenia vytvárajú, ale nie je to nevyhnutné predispozícia.

User story nie je vytesaná do kameňa. Je spôsobom, ako odovzdáš tvoju myšlienku, ako myslíš, že by riešenie na problém mohlo vypadať. Ak sa tvojim prográmotorom nezdá, je práve vítané, aby sa žiadna strana nezaľúbila do svojho nápadu, a bola pripravená diskutovať (dávať spatnú väzbu). Preto aj oni by mali byť uvedený do kontextu a mal by im byť známy problém/cieľ.

Aj keď veľa krát finálna učesaná user story vypada jednoducho a elegantne, tak cesta k nej nie je až taká jednoduchá, a zvyčajne ju človek nenapíše na prvú dobrú.

Ale, ...

Je mi jasné, že nemôžeš formou user story zapísať všetko. Jasné, že nie, ale na popis riešenia sa snaž nestratiť zreteľ z toho, že user stories sú efektívny a zároveň štruktúrovaný (a) As ..., b) I want ... , c) so That ...) spôsob, ako dokumentovať.

Čo iné sa ponúka pre doplnenie user stories:

• Épos (epic) - lepidlo, ktoré na jednom mieste dokumentuje kontext k identifikovaným problémom/výzvam. User stories naň referujú.
• Iniciatíva (initiative) - združenie éposov, ktoré sa viaže na konkrétny cieľ biznisu. Stratégiu biznisu rozložíme do jednotlivých iniciatív. Tieto iniciativy následne reflektújú nase "stávky", hypotézy - old-schoolisti používajú slovo projekty :) - ktoré sa pokúšame overiť v praxi.
  Platíme (dobre, veľa) programátorov preto, aby sa realizovali. A tí dobrí programátori potrebujú vedieť aj kontext, nielen len slepo sledovať príkaz, čo majú urobiť.
• Job story - to je práve spôsob, ktorým situáciu tvojho zákazníka (či už interného alebo externého) efektívne zachytíš pre zvyšok tímu. Formalizácia informácií, ktoré zistíš pri rozhovore so zákazníkom.
• Chyba (bug) - jasné, ak narazíš na chybu v existujúcom riešení, nebudeš sa ju snažiť napasovať do formátu user story.
• Problem story - niektoré atribúty enterprise architektúry nie je možné priamo prepojiť na funkčné očakávania biznisových používateľov. Stav architektúry softvérových riešení podlieha entropii (neporiadku). Ak EA necháme hniť, dobehne nás to. Popísanie (často technického) problému a k nemu riešenie, sa rovnako nebudem snažiť našiť do formátu user story. Tak ako sú chyba, alebo user story viditeľné, odstraňovanie (mitigácia) rizík, alebo technologického dlhu, je neviditeľná ale za to kľúčová pre našu agilitu do budúcna.

Život je tak komplikovaný, aký si ho urobíme. Skúsme si ho zjednodušiť. Už píšeš prvé user stories? Ak máš problém, otázku, kľudne ma kontaktuj.

Pri riešení biznisových problémov alebo príležitostí pomocou softvéru sa veľa dôrazu venuje funkcionalitám (features) a prípadnému následnému odstraňovaniu nedostatkov (defect, bug). Je to pochopiteľné, sú to pre ľudí mimo IT dve jasne uchopiteľné kategórie.

Ak dlhodobo sústredím všetku kapacitu výhradne na vývoj funkcionalít, tak sa mi ľahko môže stať, že sa dostanem do začarovaného kruhu, začne ma prenasledovať stále väčší počet chýb.  Skúsenému CIO sa zježia chlpy ak zistí, že sa v rámci vývoja priebežne neadresuje technologický dlh, alebo sa neodstraňujú potencionálne riziká (security, data protection). Tento krát sa nechcem sústrediť na situáciu, keď ma prekvapí záškodník, a budem čeliť bezpečnostném incidentu.

Ak sa stakeholderi prichytia pri tom, že považujú investície do odstraňovania technologického dlhu softvérových riešení ako neplánované náklady, bude vhodné si teraz naliať čistého vína.

Entropia

Väčšina softvérových riešení (systémov) podlieha zmenám. A ak sa tie zmeny nedejú v nich, tak sa dejú vedľa nich (v iných systémoch s ktorými komunikujú - horizontála, alebo na ktorých základoch stoja - vertikála). Tým, že do systémov realizujeme úpravy, systémy sa zozložiťujú (stávajú sa viac komplexnými).

Modifikáciou systému sa zvyšuje úroveň entropie (neporiadku), kým vedome nezasiahnem proti jeho tvorbe. Pomenovanie pre tento nahromadený a neuprataný neporiadok sa nazýva technologický dlh.

Proces odstraňovania entropie (v softvérovom systéme) sa nazýva refaktoring.

Ak pri navrhovaní softvérového riešenia rešpektujem odporúčania (slabé väzby medzi systémami, návrhové vzory) je menšia pravdepodobnosť, že celá moja chlpatá guľa (enterprise architektúra) bude trpieť príliš skoro na technologický dlh. Ale, príde okamih, a bude.

Čas

Chceme to hneď. ASAP. Prečo softvéristi navrhujú systémy, ktoré podliehajú entropii?!

Základnym dôvodom je čas. Treba hľadať rozumný kompromis medzi tým ako dlho uvažuješ (čas), kým sa do niečoho pustíš. Pomalosť má svoju cenu - Cost of delay. Ako dlho trvá kým sa od nápadu dopracuješ k realizácii?

Na jednej strane Ťa môže postihnúť paralýza analýzy, na opačnej strane zase strmhlavé hodenie sa do riešenia problému bez akéhokoľvek uvažovania v širších súvislostiach (architektúra riešenia, reflektovanie aktuálnych best practices a možností riešenia).

Vo všeobecnosti v neistom prostredí platí, že je lepšie hypotézu overiť v praxi, ako dlho teoreticky laborovať. Ideálne je overovať svoje hypotézy, v čo najmenších krokoch.

Je potrebné hľadať vyvážený pomer medzi tým, ako veľmi pripravujem riešenie na možnú budúcnosť, a ako rýchlo sa mi darí adresovať súčasný problém/požiadavku. Napríklad sa často softvérové riešenie hneď od začiatku komplikuje s očakávaním pre potrebu vysokého škálovania, ktorá nikdy nenastane.

(Kreatívnych) spôsobov ako riešiť ten istý problém pomocou softvérových riešení, je vždy viac ako jeden. IMHO, toto je dôvod - možnosť hračíčkovania - ktorý láka ľudí venovať sa softvérovému inžinierstvu (nerob to pre peniaze).

Refaktoring nie je náklad

Aby to nevyznelo ako čierny scenár, že sa je lepšie vecí nechytať, máme nástroje a techniky, ktoré pomáhajú s tým, aby zmeny aplikované do systému boli čo najmenšie (user story splitting), a transakčné náklady spojené s aplikáciou zmien minimálne (continuous deployment, canary release, feature flag, automated testing).  

Nepozerajme na elimináciu technologického dlhu len ako na náklad, pozerajme na neho ako príležitosť urobiť našu enterprise architektúru viac agilnou. Rovnako sa pýtajme našich dodávateľov, alebo zhotoviteľov softvéru, ako napĺňajú očakávania v tejto “neviditeľnej” rovine, prípadne či sa nám neboja povedať správy, že by sme sa mali refaktoringu tej ktorej aplikácie povenovať.

IT svet firmy nemôže byť tajomný black box, v ktorom netuším, čo sa deje. Rovnako ako predáci, alebo manažér fabriky vie, ako mu tečú materiály, kde sú potenciálne úzke hrdlá, tak potrebujem vedieť ja, aj moji non IT kolegovia o tom, čo sa deje v IT, ktoré je neoddeliteľnou súčasťou mnohých biznisov dneška.

Prirovnávať vytváranie a údržbu softvéru k výrobnej fabrike nie je dobrý nápad. Inšpirovať sa však vo výrobe, ktorá aplikuje LEAN princípy, dobrý nápad je.

Technológie do biznisu neimplementujeme preto, aby sme ich implementovali (že, štátna správa, lebo v tvojom prípade to tak vypadá?!). Technológie majú prinášať hodnotu. Ideálne je pochopiť ako (v akých hodnotových tokoch - value streams) je hodnota vytváraná. Aby pre “ostatný” biznis bola “IT hodnota” zrejmá, je možné (dľa Flow framework) zakategorizovať položky vytvárajúce hodnotu do 4 kategórii:

1. Funkcionalita (feature)
2. Chyba (defect)
3. Dlh (debt)
4. Riziko (risk)

Funkcionalita mení, dopĺňa enterprise architektúru (pod ktorou si ja predstavujem technológiu -  hadvér, softvér - procesy, dáta, ľudí) o atribúty, ktoré očakávam, že prinesú hodnotu. Prečo píšem, že očakávam? Totiž, tvorba softvéru nie je stavanie mostu, alebo rodinného domu. Je to pohyb v neistom prostredí, a spôsobov, ako biznis požiadavku vyriešiť pomocou softvéru, nebýva len jeden. Preto je veľmi na zváženie, či je projektový prístup vhodný pred aplikáciu produktového (točiaceho sa okolo hodnotového toku pomyselných softvérových produktov).

Chyba je nám všetkým dôverne známe správanie softvéru, ktoré by sme najradšej nevideli.

(Technologický) dlh, je niečo, čo je bežnému človeku neviditeľné. Dlh nám znemožňuje byť agilným do budúcnosti. Preto na jeho odstraňovaní je potrebné pracovať priebežne. Je dôležité transparentne komunikovať, že dlh máme. A že pracujeme na tom odlžovaní naších softvérových riešení.

Riziko predstavujú hlavne očakávania, ktoré vyplývajú zo správania okolitého sveta. Bezpečnosť aplikácie (riziko, že sa mi do aplikácie dostane neoprávnený používateľ), ochrana osobných údajov (GDPR).

Tieto 4 kategórie sú jednoduchým, ale efektívnym základom pre monitorovanie a komunikáciu (toku) hodnoty, ktorú vytvárajú softvérové riešenia. Keď sa nabudúce budeš (so stakeholderom) baviť o tom, čomu je sa potrebné venovať v tvojom softvérovom projekte (inak lepšie produkte), tak skús kategorizovať danú tému do niektorej z týchto kategórií. A dohodnúť sa, v akom pomere sa budeme vzhľadom na aktuálnu situáciu jednotlivým kategóriám venovať.

Neexistuje univerzálny nástroj, framework, postup, na každý tvoj problém. Ale uvedomenie si toho, že máš problém, je začiatok cesty.

Nechcem malovať čerta na stenu, ale prepadol ma pocit, že snáď tie problémy, ktoré generuje priepasť medzi IT a biznisom, vidím len ja sám.  Minimálne v mojich chabých sociálnych kruhoch. 😄

Výchádzajme z toho, že stále platí, že veľa IT projektov, končí neúspechom, tak som si dovolil napísať sedmoro (7) odporúčaní na aktivity/atribúty, ktorými je dobré byť vyzbrojený pri riešení biznis problémov a príležitostí pomocou softvéru.

Ľudia majú radi zoznamy, checklisty, tak toto je môj príspevok:

• odstraňuješ plýtvanie - t.z. implementuješ len to nevyhnutné a zmysluplné, a overuješ, či to čo si implementoval aj plní účel. To druhé (plnenie účelu, používanie softvéru) je často opomínaná aktivita.
• podporuješ učenie (skorú exploráciu) - nerobíš návrh len od zeleného stola, ale vyrábaš mockupy (wireframy), bárs aj v powerpointe (i keď máme aj lepšie nástroje ako figma, indesign, marvel) a na tých sa učíš od užívateľov/zákazníkov, či je navrhované riešenie OK, zmysluplne.
• rozhoduješ sa tak neskoro ako sa dá - t.z. nepíšeš 2 mesiace 30 stranový dokument s detailnými požiadavkami, na ktorý potom dostaneš 60 stranovú funkčnú špecifikáciu, ale softvér detailizuješ tak neskoro, ako je to možné.
• doručuješ rýchlo a zbesilo (a kvalitne) - koľko trvá kým niečo príde ako požiadavka/nápad, až do okamihu kým to začne slúžiť? Hodiny, dni, alebo týždne? Alebo si obeťou zdĺhavého schvaľovania, budgetov, opakovaných odovzdávaní, testovacích kolečiek (UAT), obáv pri nasadení zmien do produkcie.
• máš dostatok dôvery rozhodovať - dostávaš okrem úloh aj širší kontext, dôvod prečo to robíme, a oprávnenie rozhodnúť (a aj urobiť chybu)? Dostávaš príležitosť, aby si navrhol, ako môžeme problém vyriešiť?
• máš pocit integrity - vieš a rozumieš tomu, na čom sa pracuje? Ako jednotlivé časti zo sebou súvisia? Nerobíš súčasne na 20 frontoch? Nezahadzuješ (to dobré) čo si sa naučil, a nejdeš robiť úplne niečo nové.
• pozeráš sa na veci aj z nadhľadu - vieš, čo sa deje u kolegov na iných projektoch, produktoch? Máš priestor uvažovať nad tým, ako tieto orgány (softvér, ľudia) vo veľkom organizme (firme) fungujú (alebo nefunguju)?

Ak ti teraz cinklo, že predsa len budú v niektorých vyššie uvedených aktivitách u Teba nedostatky, netráp sa, nie si v tom sám.

Vieš aký je rozdiel medzi tým čo si predstavujeme, a tým čo si zažijeme? Už sa ti asi stalo, že bol priepastne veľký.

V kontexte plánovania úloh pre softvérové projekty, sú úlohy, ktoré si predstavíš (imagined tasks), že bude treba urobiť, a potom sú úlohy, ktoré objavíš (discovered tasks). Hovorím nielen za teba, aj za členov tvojho tímu.

Treba si naliať čistého vína, a povedať si, či sme vo fáze istoty, kde už vieme, čo treba urobiť krok za krokom, alebo stále neistoty, kde je vysoko pravdepodobné, že nové úlohy budú objavené.

Prvý príncíp  agilného manifesta poukazuje, že treba priebežne a často dodávať fungujúci softvér, ktorý prináša hodnotu zákazníkovi.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

https://agilemanifesto.org/principles.html

Oficiálna príručka k SCRUM hovorí, že zodpovednosť za maximalizáciu hodnoty (softvérového) produktu má rola produktového vlastníka (PO - product owner)

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

Ako však hodnotu identifikovať už záleží od kontextu (to je tá druhá veta v citácii vyššie).

Nie je hodnota, ako hodnota. Hodnota pre zákazníka (customer), hodnota pre používateľa (user), alebo hodnota pre biznis (stakeholderov) sú iné kontexty.

Urobím zmenu v internej aplikácii pre tímlídra, pričom riaditeľ plánuje reinžiniering procesov, a tím už nebude treba (resp. bude sa venovať úplne iným činnostiam).

Koho by mal PO počúvať, komu by mal hodnotu prinášať? Nie je to jednochá rola.

Aj keď stakeholderi tvrdia, že tieto funkcionality X a Y musia mať, všetky majú prioritu no. 1, a na dôvažok aj podložili svoje žiadosti očakávaným prínosom hodnoty, stále sa aj oni pohybujú v rovine teoretickej, hodnotu si iba predstavili (naplánovali).

Realita však už môže dopadnúť úplne inak. Hodnota (napríklad meraná ROI) sa často krát krásne plánuje, ale sedliacky rozum hovorí, že je potrebné často skôr odhaľovať (discovery), ako naplánovať (imagine). Samy organizácie sú zložité organizmy. Často nedokážeš dopad akejkoľvek zmeny ovplyvniť. Len zmenu vykonať a pozorovať a adaptovať sa.

Ak si v údolí neistoty, never slepo plánom o ROI, a pokús sa čo najmenšími experimentami overiť, objaviť, čo hodnotu bude prinášať. A určite sa nestaň slepým prijímateľom objednávky od stakeholderov. Vlastni produkt.

Že user story vie (na)písať každý je lajtmotív mojej misie.

Do mojej schránky dorazila otázka:

“Keď bude biznis vedieť sám písať user story, a komunikovať de facto priamo s výrobcom softvéru, potom nebude treba projektových manažérov?”

V striktnom ponímaní lean a agile všetko ostatné okrem kódovania (t.z. aktivity, ktoré netvoria softvérový produkt) sa považuje za odpad (waste, overhead). V tejto optike niekto (projekťák) kto pripomína prioritu úloh, prestavuje dátum splnenia, sa javi ako veľmi nepotrebný člen tímu.

Čo?! Ok, neni to take čiernobiele, tak čítaj ďalej. Všetci hardcore agilisti, hlavne extrémni programátori (xP), nemusia pokračovať v čítaní ďalej. Pre nich však mám posolostvo, že  ja vidím zmysel v tom, aby sme sa hrali najprv so slovami (písali user stories, dizajnovali procesy) a kreslili procesné diagramy, mockovali hrubé prototypy (breadboarding), až potom išli kódiť.

Osobne si myslím, že niektorí súčasní projekt manažéri softvérových projektov budú konvertovať k produktovým vlastníkom (PO - product owner). Hlavne tí, ktorí inklinujú viac k tomu, čo riešime, nie ako zabezpečíme zdroje (na riešenie).

PO je špecifická rola v metodike SCRUM. Častovať niektorých PO produktovými manažérmi môže byť overkill alebo urážka produktových manažérov. Každopádne produktový manažér je strategická rola, PO je taktická rola. Stále platí, že to môže byť tá istá osoba. PO je zvyčajne osoba ktorá robí prepojenie medzi biznisom a IT, a varí user stories.

Od projektu k produktu

Rola projekťáka sa transformuje do role odstraňovača prekážok. Úspešných self managed tímov nebude (zatiaľ) až tak veľa, a keď príde na to, že:
a) treba pritlačiť a niečo presadiť u C-level,
b) treba sa zbaviť nejakého neproduktívneho člena tímu,
všetci tieto “manažérske” úlohy, radi odovzdajú na vyriešenie niekomu inému.

Riešiteľský tím si žije v tak kvalitnej bublinke, akú im dokáže manažér zabezpečiť.

Ako sa priblížiť k agilnému a lean prístupu?

Pre firmu, ktorej hlavným produktom/službou nie je IT produkt/služba, vieš aplikovať metodiku SCRUM (presne podľa príručky) len v prípade in-house vývojárskeho tímu. Ak IT službu obstarávaš od dodávateľa, je treba sa prispôsobiť. Ideálne je sa tomuto scenáru (mať inhouse tím vývojárov) približovať, ale to nie vždy je možné.

Agilné metodiky nepoznajú rámcovanie projekt. Organizácie práce sa točí okolo priebežného došpecifikovávania eposov (epic) do detailnejších user stories, požiadavka na to, aby user stories po doručení v rámci šprintu (časové ohraničenie pre vývoj) mali aj biznis hodnotu (rešpektovali tzv. definition of done).

Odporúčam každému projektovému manažérovi, aby dĺžku projektov vedome skracoval, čo má potom vplyv na to, že zásadné otázky, ktoré riešim ako projektový manažér (viď tabuľka), majú menšiu váhu, preto môžu napáchať menej škody.

Aby som však neriešil diskonektnuté mini projekty, potrebujem víziu produktového vlastníka, ako tieto (mini) projekty na seba nadväzujú (ako sa dopĺňajú) - roadmapu. V SCRUme produktový vlastník túto víziu preberá od C-level manažérov. Alebo sami C-level manažéri sú produktovými vlastníkmi.

Projekt v kontexte vývoja digitálneho produktu je vlastne vedomé rámcovanie toho, ako plánované vylepšenie (inkrement, deliverable) na produkte dosiahnem. Medzi hlavné atribúty projektu patri čas (zostáva kvalita a peniaze). Planovať na dlhé obdobie a myslieť si, že ten plán splním je naivné. A ešte horšie je, keď potom všetko prispôsobujem tomu, aby som ten plán (čas naplnil).

Čím chceš byť?

Ak som ti dnes pomohol odpovedať na otázku, čím chceš byť, keď budeš veľký, tak som trafil týmto článkom klinec po hlavičke. Uvedomenie si zodpovedností a kompetencií spomínaných rolí a zameranie sa na jednu z nich prinesie lepšie konečné výsledky. Never tomu, že generalistov ako MacGyver čaká svetlá budúcnosť. Tá čaká T-shaped špecialistov. 😄

V tejto situácii sa najčastejšie môžeš vyskytnúť, ak ti softvérové riešenie dodáva externý partner (software house, integrátor). Ak funguješ s internými vývojovým tímom, agilne, scrum, atď. tak snáď týmto neduhom, ktorý budem opisovať, netrpíš.

Mentálne cvičenie

Prácne spíšeš biznis požiadavky vo forme eseje (dlhý wordovský dokument). “Finálnej” verzii dokumentu predchádzalo niekoľko výmien, v rámci ktorých si požiadavku klarifikoval so stakeholderom (zadávateľom), a v niektorých prípadoch aj s vývojárom (dodávateľom), aby si neprestrelil (technické požiadavky, rozumné možnosti).

A potom, ako si požiadal o návrh riešenia od vývojára (zvyčajne po pár dňoch) dostaneš novú esej. A túto esej musíš (niekto v tíme) skontrolovať, či si s ňou spokojný, či niečo nevypadlo z toho, čo si pôvodne napísal do tvojho zadania požiadaviek, či to bolo správne pochopené.

Čím väčší rozsah požiadavky, tým väčšia mentálna energia potrebná na vykonanie tejto kontroly, porovnania.

❓Je toto efektívna cesta? Nie. Čo je alternatíva? Použi user stories. UTFUS - use the friendly user stories.

Čo mám spraviť?!

1. Nepíš esej, použi štruktúru (tabuľku), zoznam user stories s akceptačnými kritériami
2. Snaž sa rozsah jednotlivých user stories držať na bare minimimum (postupy: user story splitting, INVEST)
3. Vývojár (programátor) má za úlohu naplniť hlavné očakávanie popisané samotnou user story notáciou (As <role> I want <something> to have <benefit>), a skontrolovať naplnenie všetkých akceptačných kritérii. Voči akceptačným kritériam, ich kombinácii, je možné napísať testovacie scenáre.
4. Na (do)ladení požiadavky spolupracujú všetky zúčastnené strany (zákazník aj dodávateľ) a pracujú nad rovnakým zoznamom (zdieľaným v oblaku, ideálne s version control  - keby náhodou). Na písanie dokonalého zadania nie je priestor, dokonalé zadanie je mýtus. Lepšie je začať good enough, ktoré sa doladí.
   

Má ešte esej miesto na život?

Áno, tým miestom je epos (Epic). Tam máš odomňa zelenú, aby tam sumarizoval:

• braindump (čo povedal koncový zákazník, že chce, alebo čo treba spraviť),
• status quo (kde sa nachádzame, aký máme problém, alebo príležitosť),
• vízia budúcnosti, ciele (kam sa chceme dopracovať).
  

Prosím, ak ide o definíciu toho, čo má robiť softvér, použi na to user stories. Má to aj ďalšie benefity:

• dobre čitateľná dokumentácia pre BFU,
• prehľadná štruktúrovaná dokumentácia,
• identifikácia must-have a nice-to-have funkcionalít.
  

💡Ak si zatiaľ na napísanie požiadaviek vo forme user stories netrúfaš, žiaden problém. Kým sa to naučíš, požiadaj o to svojho dodávateľa, aby tvoje zadanie spracoval týmto spôsobom.