Dvanáct známek toho, že pracujete v továrně na kód

4 min readJan 11, 2021

This story is a translation of John Cutler’s blog “12 Sign You’re Working in a Feature Factory”. I recommend to follow him on Twitter and have a look at The Beautiful Mess.

Tento článek je překladem blogu Johna Cutlera “12 Sign You’re Working in a Feature Factory”. Všem, kteří se zabývají vývojem softwaru, doporučuji sledovat jeho twitter a jeho knihu The Beautiful Mess.

John používá pojem továrna na kód (volně přeloženo z anglického Feature Factory) už několik let od doby, kdy jeho přítel —programátor — si posteskl, že “jen sedí v továrně, kóduje jednu funkčnost za druhou, a posílá je dál jako po páse.”

Jak poznáte, že pracujete v továrně na kód?

Žádná měření. Týmy neměří účinek své práce. Případně, pokud k měření dochází, je děláno samostatně produktovým managementem a sdíleno jen někdy. Jako vývojář netušíte, zda práce byla užitečná
Rychlé změny týmů a projektů (neboli týmový tetris). Místo zajímavého a podnětného poslání, týmy dostávají úkoly na dílčí funkčnost a jsou přiřazovany na projekty. Soustavně se pracuje na více věcech najednou a nestíhá se
Divadlo úspěchu po dokončení práce bez diskuze ohledně toho, co to přineslo. Hodně lze poznat podle toho, co se ve firmě oslavuje
Přiznat neúspěch je výjimkou. Nepoužívané funkce se neruší. Základním měřítkem úspěchu je množství nové funkčnosti v produktu, ne její důsledky. Pokud se zjistí, že práce k ničemu moc nebyla, jen zřídka se smaže. Často týmům chybí pocit bezpečí k tomu, aby přiznali, že jejich úsilí nevedlo ke kýženým výsledkům
Chybí napojení na hlavní metriky produktu. Jen málo se diskutuje o očekávaných výsledcích jak z hlediska firmy, tak i pro zákazníky. Tým nechápe, jak jeho práce vede ke zlepšení důležitých firemních výsledků a spokojenosti zákazníků. Není možné najít pojítko mezi současnou prací a tím, co je “nejdůležitější” z hlediska firmy
Není retrospektiva ohledně produktového managementu. Produktoví manažeři nedělají pravidelné retrospektivy ohledně produktových rozhodnutí a neporovnávají očekávané výsledky se skutečnými. Vývojáři testují kvalitu kódu, ale kvalita produktových rozhodnutí se netestuje. Místo toho se bere objem dokončené funkčnosti jako hlavní ukazatel úspěchu
Posedlost plánováním. Nepanuje soulad mezi tím, jak vážně se posuzuje to, na čem se bude pracovat, a validací toho, zda to byly skutečně ty správné věci. Přísné plánování se děje zejména z důvodu, aby uvnitř firmy panovala důvěra k zvolenému plánu. Hodně úsilí se věnuje výběru toho, na čem se bude pracovat, a pak chybí prostor pro neočekáváné změny na základě později zjištěných informací. Roadmapy vypadají spíše jako seznam funkčností produktu než oblastí nebo cílů, na které tým zaměří
Není čas na doladění. Jakmile je kód “hotový”, tým hned přechází na další “projekt”, aniž by dostal čas vylepšit produkt na základě kvalitativních a kvantitativních dat
Kultura předávání práce. Než tým začne na něčem pracovat, je to “připraveno pro vývojáře” jiným týmem. Tým se neúčastní výzkumu, zkoumání problému, experimentace nebo validace. Jakmile je kód dokončen, tým má malý kontakt s technickou podporou nebo obchodním oddělením
Práce ve větších dávkách. Když není potřeba experimentovat, tak není důvod dodávat užitečnou funkčnost postupně po menších samostatně užitečných částech. Tým může sice “agilně” pracovat ve sprintech, ale jednotlivé sprinty nepřináší pro zákazníky nic nového
Přílišný důraz na rychlé příjmy. Pracuje se jen na tom, co přinese brzké zisky. To není v podstatě špatně, ale často tato ekonomická rozhodnutí stojí na velmi vratkých základech a nezohledňují nelineání nárust složitosti produktu. Čtvrtletní cíle jsou sice splněny, ale později za to mnohokrát zaplatíte. Tento přístup opět posiluje myšlenku, že množství funkčnosti odpovídá celkové hodnotě
Co se třpytí, je zlato. Ačkoli známé přísloví říká opak, hlavní důraz je novou funkčnost. Refaktoringu, snižování technického dluhu nebo celkové technické připravenosti se nevěnuje dostatečná pozornost. Honba za pozlátkem má přednost před zdravím produktu jako celku. Dopad nové funkčnosti na použitelnost (a udržovatelnost i rozšiřitelnost) stávajícího produktu se nebere v potaz.

Pokud váš zajímá řešení, John se tomu věnuje na svém blogu:

Dvanáct známek toho, že pracujete v továrně na kód

Written by Petr Plavjaník