neděle 2. února 2014

Proč je dobré konzumovat psí žrádlo aneb jak si kdo ustele...

V angličtině se tomu říká eating your own dog food, v češtině používáme pořekadla co sis navařil, to si taky pěkně sníš a nebo nápaditější jak si kdo ustele, tak si i lehne. Tyto fráze popisují nejčistší možnou zpětnou vazbu, kterou můžete dostat. Zpětná vazba je klíčovým faktorem v zdokonalovacím procesu jakékoliv činnosti a při vývoji software to platí ještě více. V tomhle článku vám zkusím vysvětlit, proč je potřeba na eating your own dog food neustále myslet a proč je jedním ze základních pravidel psaní cynického software.


Slabá vs. Silná zpětná vazba

Když jsem před lety pracoval pro Hewlett-Packard, software, který jsme vytvářeli, byl instalován přímo zákazníky. Zákazník dostali CD/DVD a manuál, podle kterého jejich systémoví administrátoři provedli instalaci. Jestli se ten software vůbec používal, případně jakým způsobem, se k nám nikdy nedostalo. Byly to šťastná doba mého života, protože jsem nemusel žít s plody vlastní práce. Doslova a do písmene, žil jsem ve sladké nevědomosti. Tomu říkám slabá zpětná vazba. O pocit vlastní dokonalosti z dobře odvedené práce jsem začal přicházet během mých začátků v GoodData. Zlomový okamžik si pamatuji naprosto přesně. Seděl jsem zrovna s kamarádkou v oblíbené řecké restauraci a u druhé lahve výborného vína mi začal kolem půlnoci zvonit mobil. Představy o příjemném zbytku večera vzaly za své během letmého pohledu na jméno volajícího. Pokud vám o půlnoci volá šéf operations málokdy to věstí radostné noviny. Už si přesně nevzpomínám na příčinu problému, který jsem způsobil, ale během přebíhání potemnělého Žižkova směrem do našich kanceláří v Karlíně jsem si uvědomil, že co jsem si navařil, to si taky pěkně vyžeru. Silná zpětná vazba, s trochou nadsázky řečeno: i po letech mě ten večer mrzí.

Rozdíl mezi GoodData a jinými společnostmi a projekty, na kterých jsem do té doby pracoval, byl v tom, že jedna verze software - pravidelně se aktualizující každých 14 dní - sloužila všem zákazníkům. Pokud jste tedy udělali chybu, byla to většinou chyba, která se obvykle projevila u všech zákazníku v jeden okamžik a to většinou hned. Kromě nočních zásahů byl dalším důležitým faktorem ovlivňujícím zpětnou vazbu přechod z organizačního modelu s takzvanými sily - jedno oddělení GoodData vyvíjelo a jiné GoodData provozovalo - na model DevOps, kdy máme sobestačné týmy vyvíjející a provozující části GoodData. V modelu se sily docházelo u lidí z operations k neurotickým změnám v chování před každým releasem. Zatímco vývojáři měli snahu všechno doručit za 14 dní do konce sprintu v modus operandi commit a děj se vůle boží, administrátoři nechtěli prakticky povolit jakoukoliv změnu, která by měla jakkoliv byť jen hypoteticky narušit jejich již tak značně nalomené psychické zdraví.

Po přechodu do DevOps modu, kdy se náš tým začal starat nejenom o vývoj, ale i provoz naší části systému jsem začal jejich výtky chápat. Kromě drobností, jako bylo nedostatečné logování, jsem velmi rychle pochopil, jaký je rozdíl mezi dodat software a dodat provozuschopný software. Tahle zkušenost vedla k tomu, že tým najednou začal mnohem více koukat administrátorskýma očima a snažil se vymyslet, jak by se administrační úkoly daly co nejvíce zefektivnit. Tam kde jsme dříve administrátory odháněli mávnutím ruky, s tím že na to bude nějaké API, si dneska děláme management nástroj s grafickým rozhraním. Stačilo se jenom párkrát vykoušet, jak se některé úkoly dělají našemu administrátorovi přes ruku.


Proč je dobré býti konzumentem

Sníst si co jste si navařili je dobré nejenom v případě provozu software, který sami produkujete, ale prakticky pokaždé když existuje oddělení rolí producenta a konzumenta. Jedním z těch případů, který jsem několikrát zažil na vlastní kůži, byl vývoj frameworku. Tým A zodpovědný za dodání frameworku, a tým B za jeho používání. Asi nejhorší možný setup. Tým A chce po týmu B, aby přesně definoval požadavky. Tým B to s větším či menším úspěchem udělá. Tým A to podle požadavků vyprodukuje, případně si to alespoň myslí, a výsledek předá týmu B. Tým B začne framework používat a dochází k frustraci. Tým A sice vyprodukoval to co po něm tým B chtěl z funkční stránky, ale z hlediska použitelnosti to byla katastrofa. Tým A nevěděl přesně, jak to bude tým B používat. Bohužel to často nevěděl ani tým B. To je jeden z důvodů, proč by tým, který produkuje nějaký framework, měl být jeho prvním konzumentem.


eating your own dog food má jeden velmi důležitý efekt, který se projeví prakticky ihned. Lidé a týmy jsou daleko více vtažení do hry řečeno sportovní terminologií. Vývojáře přece jenom daleko více baví pracovat na něčem co sami používají. Začíná fungovat vnitřní motivace. Najednou přestanou výmluvy typu: to v zadání nebylo. Tým aktivně hledá místa, kde by se systém dal vylepšit, a přebírá z části roli zákazníka.


Jak začít konzumovat vlastní jídlo

Na závěr pár rád, které jsou jednoduché, ale hlavně tu první hodně týmů často z nepochopitelných důvodů ignoruje.

  • Začněte používat produkt, který sami vyvíjíte. Platí pokud je to alespoň trochu myslitelné.
  • Roztrhněte stereotyp konzument a producent a snažte se o vzájemné prolnutí těchto rolí. Platí to nejenom ve vztahu vývoj a provoz software, ale i pro design a vývoj, vývoj a používání.
  • Pokud nemůžete tento stereotyp roztrhnout, alespoň ho z části naleptejte viz DevOps a nebo rotace lidí v rolích. Dostaňte vývojáře blíže k zákazníkovi. Pokud je nemůžete nechat přímo komunikovat, zahrňte je třeba do řešení support tickets.