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.