Jak poznáme, že to je hotové?

1 Reply

Zeptal se mistr žáka: „Jak poznáš, že je tvoje práce hotová?”
„Když skončí vývoj”, odvětil žák. Mistr ho praští holí.

Další den se mistr zeptal na to samé.
„Když je to otestované“, odvětí žák a dostane další ránu.

Mistr se ptá potřetí a žák odpovídá „Už vím, když je to nasazené na produkci!“ Mistr jen smutně zavrtí hlavou.

Čtvrtého dne přijde žák za mistrem sám a říká: „Moje práce je hotová, když je vyřešen daný problém.“ Mistr se usměje a zeptá se: „A jak to poznáš?“

Ano, naše práce není hotová, když nám odpadne kód od ruky, ani když už je otestovaný, dokonce ani když je nasazený na produkci. Naše práce je hotová, až když jsme vyřešili problém, který je potřeba vyřešit. Ale jak to poznáme?

Na to potřebujeme metriku neboli kritérium úspěchu. Nějaké číslo na které se podíváme a poznáme, jestli problém stále máme nebo jestli jsme ho už vyřešili.

Tato metrika by měla splňovat dvě kritéria, která jdou trochu proti sobě. Měla by být co nejblíž businessu a zároveň co nejblíž změně, kterou jsme udělali. V ideálním případě bychom měli udělat změnu a poznat, kolik nám zrovna ta změna přinesla peněz. To většinou bohužel nejde, takže hledáme něco mezi.

Upravujeme registrační formulář, protože teď na něm odpadne 50% potencionálních zákazníků? Můžeme si říci, že to snížíme na 25%. To je pěkná metrika, která se dá přibližně převést na peníze a zároveň drží naší pozornost u registračního formuláře.

Máme pocit, že část naší aplikace je nepřehledná? Jak to měřit? Hledání metriky není vůbec jednoduché, ale i samotné hledání je nesmírně užitečné. Donutí nás to pochopit, co vlastně řešíme. Proč konkrétně nám vadí, že je aplikace nepřehledná? Vadí nám, že zákazníci nedokončí objednávku? Pojďme měřit to. Vadí nám, že zahlcují podporu? Pojďme počítat čas, který tím podpora stráví. Vadí nám, že lidi nechtějí naši aplikaci používat? I to se dá měřit. Tím, že si definuji metriku se donutím myslet na to proč ten problém vlastně řeším.

Musím zdůraznit to, že metrika by měla mít business smysl. Máme občas nutkání měřit jenom přidanou věc. Pro jednoduchost si představme, že přidáváme nové tlačítko. Můžeme měřit kolik lidí na něj kliklo? Můžeme, ale moc nám to neřekne. Tlačítko jsme tam přidávali z nějakého důvodu. Řešili jsme nějaký problém, kterým pravděpodobně nebylo chybějící tlačítko, ale něco úplně jiného. To že změříme, že lidi na tlačítko klikají neznamená, že to pomohlo s řešením problému. Co když na něj klikají omylem?

Vždycky říkám, že programátoři jsou placeni za to, že dodávají hodnotu. Metrika přesouvá moji pozornost z featury na hodnotu.

Když mám metriku, tak ji využiji v celém vývojovém procesu. Nevím který požadavek je důležitější? Ten, který má větší šanci metriku přesunout správným směrem. Cpe mi někdo něco do backlogu pod záminkou řešení aktuální priority? Zeptám se, jestli to opravdu s danou metrikou pomůže.

Největší přínos metriky je ale na konci vývojového procesu. Zabraňuje nám stát se feature factory (tenhle článek si určitě přečtěte). Často totiž tvrdíme, jak jsme agilní a děláme věci iterativně, ale když něco dodáme, tak se k tomu nevracíme. Bez metriky nemáme důvod. Když máme za úkol předělat registrační formulář a nemáme k tomu metriku, tak ho předěláme, oddemujeme nasadíme, přesuneme lísteček a hotovo, hurá na další featuru. Dodali jsme nějakou hodnotu? Koho to zajímá, vždyť to stejně neumíme poznat.

Když máme za úkol zvýšit procento lidí, kteří se skrz registraci dostanou, tak nás to nutí se podívat na to jestli se to povedlo a pokud ne, tak co je další krok. Metrika nás tlačí do toho dělat věci opravdu iterativně, ne jen si na to hrát.

Jaké potřebuji zadání

2 Replies

V poslední době často řeším, jaké bych chtěl dostávat zadání. Došel jsem k tomu, že správné zadání má mít právě tyto dvě části:

  1. Popis problému, který potřebujeme vyřešit.
  2. Business metrika, kterou změříme, že se to povedlo.

Zní to jednoduše, ale nám se to ne a ne podařit. Pojďme se na to podívat postupně. Místo popisu problému stále dostáváme řešení. Místo „zákazník netuší, co má udělat na registračním formuláři“ dostáváme „tlačítko ‘Odeslat’ zvýrazněte červenou barvou“. Místo „potřebujeme ušetřit výdaje na ministerstvech“ dostáváme „postavte vládní čtvrť v Letňanech“.

I když se mi zdá rozdíl mezi popisem problému a řešením zjevný, lidi z nějakého důvodu prostě nejsou schopni se u popisu problému udržet a stále sklouzávají k řešení. Než se podíváme na důvody, proč to tak bývá, řekněme si, proč nechci přicházet k hotovému řešení.

Když dostanu připravené řešení, tak s ním často nesouhlasím. Často totiž nedává technicky nebo dokonce logicky smysl. Napadl mě následují příklad, představte si, že navrhujete auta a přijde vám požadavek – do okna spolujezdce vyrobte uzavíratelný otvor o průměru 18,7 cm.

Pokud se vám něco podobného stane, máte v podstatě jenom dvě špatné možnosti. Můžete to řešení napadnout a říci, že je potřeba vymyslet jiné. Nebo můžete sklapnout podpatky, udělat to podle zadaného řešení i když nechápete proč to děláte a technicky vám to nedává smysl.

Změna zadaného řešení je často hrozně politicky složitá, spoustu lidí na něm strávilo spoustu času, dohodlo se na tom několik vrstev managementu, už se to slíbilo zákazníkovi a teď nějaký hloupý programátor přijde s tím, že by to dělal jinak? Proč se sakra ptáš, na to jaký problém tím chceme vyřešit? Prostě udělej v okně spolujezdce otvor o průměru 18,7 cm a přestaň klást hloupé otázky. Víš kolik času jsme strávili rozhodováním, jaký má být poloměr té díry? Že to nejde? Tvoje práce je tyto drobné technické detaily řešit.

Pokud najdeme odhodlání navrhované řešení zpochybnit, potřebujeme nejdřív zjistit popis problému. Proč by chtěli mít díru v okénku? Naštěstí se můžeme někoho zeptat. „Proč chtějí díru v okně spolujezdce?“ „No, náš důležitý zákazník chce vozit dlouhé tyče, do auta se jim nevejdou, tak je chtějí držet rukou podél auto venku z okénka. Ale když mají otevřené okénko, tak jim dovnitř fouká.“ (XY problem) V těchto okamžicích si vzpomenu na strýčka Boba, který říká, že profesionál se pozná podle toho, že umí říci zákazníkovi „ne“. Takže profesionálně řeknu „ne“ a jsem označen za negativního. Nicméně je to pro mě lepší než druhá alternativa, udělat něco, co nedává smysl.

Abych to shrnul, pokud mě stavíte k hotovému řešení, nutíte mě buď vám to řešení rozbít nebo udělat něco, co firmě dříve nebo později uškodí. U díry v okénku se ty škody dají celkem slušně vysvětlit, dopad kupení hacků na hacky v složitém programu se vysvětluje podstatně hůř.

Tady arogantně předpokládám, že řešení, které přijde od neprogramátora musí být špatně. Často špatně je a to ze dvou jednoduchých důvodů. Programátoři často bývají jediní, koho napadne se ptát, co se bude dít v okrajových případech. Co se stane, když vypadne připojení v internetu v tomto okamžiku. Jak napravíme data, když operátor do toto políčka napíše špatné číslo. Co budeme dělat, když se k tomuto odkazu dostane zlý hacker. Co se stane, když držíte rukou tyč venku z okna a nabouráte? Programátoři se na takovéto otázky ptají, protože musí, potřebují to pro svoji práci. Pamatuji jen pár neprogramátorů, kteří měli podobné uspořádání mysli.

Druhý důvod souvisí. Software je celkem složitá věc, chování nejen v okrajových případech bývá komplikované a nikdo nemá šanci si zapamatovat, jak se vlastně ta vaše aplikace chová za všech okolností. To je ale informace, kterou nutně potřebujete vědět, když vymýšlíte změny. Programátor se může podívat do kódu, kde to v lepším případě zjistí. Lidi, kteří neumí číst kód nemají šanci se těmto důležitým informacím dostat.

Nicméně předpokládejme na chvíli, že máte super analytika, který všechno tajemná zákoutí vaší aplikace udrží v hlavě nebo v dokumentaci a donese vám perfektní řešení. I tak je to špatně. Když neznám problém, který řeším, tak pracuji naslepo, nevím proč dělám to dělám, měním se v robota (nebo lumíka) Když hádám, který problém řeším, můžu to uhodnout špatně a tím pádem to naimplementovat špatně. Když nechápu proč chtějí díru v okénku, tak ji pravděpodobně udělám na špatném místě, takže skrz ní ruka ani prostrčit nepůjde.

Nevýhod hotových řešení je víc, nezbývá mi tu na ně ale místo, takže si je doplňte za domácí úkol. Pojďme se teď radši zamyslet, proč je tak těžké se udržet u popisu problému.

Tichá pošta

U nás se to děje především kvůli tiché poště. Obchodník řeší se zákazníkem jeho problém. Zákazník už má samozřejmě v hlavě nějaké řešení. Obchodník si pak sedne s produktového manažerem, kde si buď řešení potvrdí nebo vymyslí lepší. Proberou to se zákazníkem, ten jim to schválí, vytesá se to do kamene a teď už jen zbývá to naimplementovat.

Tento scénář má mnoho variací, místo zákazníka může být management, místo produktového manažera analytik, místo tesání do kamene je obvyklejší grafický návrh, ale všechny ty scénáře mají jedno společné. K lidem, kteří to budou dělat a kteří celému systému obvykle rozumí nejvíc, se to dostane až když je to celé vymyšlené.

Řešení hledá problém

Abych se netrefoval jen do cizích řad, tohle se děje často vývojářům. Máme v hlavě řešení, ale nemáme k němu problém. Nemusí to být zrovna vládní čtvrť, může to být nejnovější knihovna nebo jiný hype. Pokud jste někdy ve vaší firmě slyšeli „musíme najít něco, na co bychom použili strojové učení“ tak víte o čem mluvím. U nás to většinou skončí tím, že zkusíme napsat popis problému, který bychom strojovým učením mohli vyřešit. Poté většinou zjistíme, že se daný problém dá řešit lépe nebo že ten problém vlastně nemáme.

Vymýšlení řešení je přirozené

No a to nejtěžší na konec. Lidská mysl je stoj na řešení problémů. Je tak tak dokonalá, že když žádný problém nemá, tak problémy vymýšlí, aby měla co řešit. Je hrozně těžké se udržet u popisu problému. Je těžké říci „můj problém je takový a takový“, je pro nás přirozenější říci „chci to a to“. Je těžké říci „nerozumím tomuto formuláři“, říkáme „měli byste prohodit tato dvě políčka“. Každý chce přispět svým nápadem, takže se udržet u popisu problému je opravdu náročné i když lidi přesvědčíme, že je to nezbytné.

Zkuste si následující hru, podívejte se do vašeho backlogu a spočítejte kolik je tam lístečků s popisem problému a kolik čistě s popisem řešení. U těch popisů řešení zkuste zformulovat popis problému. U kolika z nich to dokážete u kolika z nich si nejste jisti? U těch, u kterých to dokážete, zkuste narychlo vymyslet alternativní řešení. Kolik z nich bude lepších, jednodušších, levnějších?

Příště se podíváme na druhý bod, business metriku, kterou to všechno změříme.

Devoxx 2018

1 Reply

Po letech jsem se byl podívat na Devoxxu, takže je na čase oprášit na blogu pavučiny a zapsat si, co jsem se naučil.

Reactive vs. Loom

Nejvíc mě dostala prezentace o projektu Loom. Na současném přístupu ke škálování mi cosi nesedělo, ale nedokázal jsem pojmenovat co. Pár firem potřebuje opravdu škálovat, a proto všichni musí začít připisovat knihovny na to, aby podporovaly RxJavu, Reactor a podobné. Musíme přepsat databázové ovladače, HTTP knihovny, přístup k souborovému systému tak, aby byl reaktivní. Za to se nám dostane té odměny, že už nebudeme muset psát v Javě, ale v jakémsi DSL, kterým budeme krásně skládat asynchronní potrubí.

Když se nad tím zamyslíte, tak je to neuvěřitelně prosakující abstrakce. Abych ji mohl použít, musím moji asynchronní knihovnu zadrátovat do API. Takže metody už nevrací T ale Mono<T>. To není prosakující abstrakce, ale cedník.

V projektu Loom si chlapci v Oraclu řekli, že to jde možná dělat lépe. Co nám vadí na vláknech? Jsou drahá, žerou paměť a jsou zbytečně blokována při čekání na sít, souborový systém nebo zámek. Co kdybychom použili jinou abstrakci, říkejme jí třeba Fiber (nitka?). Nitka se veze na vlákně, ale když narazí na blokující operaci, tak se vlákna pustí a to může jít vozit jiné nitky. Když blokující operace skončí, blokovaná nitka naskočí na jiné vlákno a provádí další můj kód. Jelikož se všechny blokující operace obvykle provádí skrz standardní Java knihovnu, kód který řeší opuštění vlákna a opětovné naskočení zpět je schovaný v JVM a jeho knihovnách. Já nemusím nic řešit. (Kdo můj poetický popis nepochopil, nechť se stydí a pustí si video).

To znamená, že jako programátor dostanu škálování v podstatě zadarmo. Můžu dál psát svůj staromódní imperativní kód a JVM zajistí, že to poběží efektivně. Samozřejmě nedostanu všechny výhody reaktivního přístupu jako backpressure (protitlak), ale možná mi to za čistší API, čitelné stack tracy a jiný konfort, na který jsem zvyklý, stojí.

Na Dovoxxu ukazovali zajímavé demo, kde vzali Jetty, místo ThreadPoolu podvrhli něco co používá Fibers a když to zrovna nespadlo, tak klasická aplikace v JAX-RS škálovala jako divá. Bohužel bude ještě pár let trvat, než dořeší všechny detaily jako ThreadLocals a podobně, ale vypadá to nadějně.

Trochu s tím rezonovala přednáška o Briana Goetze o Objektovém a funkcionálním programování. Síla objektového programování je v místech, které překračují hranice (boundaries). Tam potřebuji mít silný kontrakt v čemž OOP exceluje. Uvnitř hranic dává občas smysl zahodit ceremonii s objekty spojenou a využít sílu FP.

Nejlepší přednášky:

Co říci závěrem? Devoxx je super konference, člověk si rozšíří obzory, uvědomí si, jak moc ho programování baví a jak živý je Java ekosystém. Až na pár ojedinělých výjimek byly všechny přednášky skvělé, takže několikrát litoval, že se nemůžu rozkrájet a jít do víc sálů najednou. Nevadí, 10 Mistakes Hackers Want You to Make si pustím z YouTube.