Problém

Často slýchám, jak si zainteresované strany nebo PM stěžují, že tým inženýrů opakovaně nedokončuje svou práci včas. Ještě více by tlačili na dodržování termínů v domnění, že to pomůže. Ve skutečnosti to jen vytváří další napětí, které nikomu nepomůže. Pokusili by se také přidat umělé pufry, což by problém ještě více zkomplikovalo.

Samotné odhady jsou však problémem jen zřídka a neustálá zpoždění jsou obvykle způsobena jinými příčinami než nepřesnými odhady. Nenechte se proto držet jako rukojmí odhadů!

Přijatá opatření

Snažil jsem se zdůraznit, že odhady by neměly být chápány jako závazky, ale měly by být vykládány šířeji a zahrnovat hodnotu procesu vývoje a neměly by být vystavovány a diskutovány mimo vývoj softwaru.

Pokud se týmu nedaří dodávat včas, jsou jeho odhady považovány za nepřesné nebo nepřesné. Pouze správné poznatky nám mohou pomoci zjistit, v čem problém skutečně spočívá. Obvykle bych zjistil, že systém doručování nefunguje správně. Během plánování sprintu se totiž tým zavázal k několika problémům, které se mají realizovat, ale objevilo se velké množství neplánovaných věcí – od chyb až po různé typy blokátorů – které nebylo možné předvídat. Řešením by bylo identifikovat možné neplánované nebo ad hoc problémy a jasně definovat, za jakých okolností by mohly přerušit provádění plánovaných činností. To by zahrnovalo definování všech těchto neplánovaných problémů; například co by představovalo blokátor atd. Pokud tým řeší několik ad hoc problémů měsíčně, věci by pravděpodobně probíhaly podle plánu. Pokud by však neplánované problémy tvořily až 20-30 % produkce, způsobilo by to vážné problémy a následně zpoždění.

PM a techničtí vedoucí by také měli mít jasný přehled o tom, jaký typ práce tým vykonává; například na kolika funkcích nebo chybách pracoval, kolik podpory nabízel nebo pomáhal zákazníkům atd. Pokud máte ucelený přehled, můžete upravit očekávaný poměr a zahrnout jej do plánování dalšího sprintu. Tento přístup by pomohl s odhady, protože by poskytl záruky pro výstupy, jak jsou zahrnuty v plánu. Pokud by tým a PM jednali transparentně a pravidelně informovali zúčastněné strany o stavu funkcí, výsledkem by bylo pochopení a podpora. Pokud bychom kdykoli zjistili, že se možnost zpoždění zvyšuje, měli bychom o tom neprodleně informovat zúčastněné strany. V nejhorším případě by se informace o možných zpožděních měly uchovávat až do samotného dne doručení.

Další věcí, se kterou jsem se setkal, byla nedostatečná komunikace mezi produktem a technickým oddělením. Produkt obvykle předával požadavky a inženýři je plnili. Nejenže je to spíše přístup podobný Vodopádu, ale navíc to brzdí produktivitu inženýrství. Místo toho by produktový a inženýrský tým měly mít možnost navrhovat věci společně, což by inženýrům pomohlo pochopit složitost a všechny okrajové případy, a tím zvýšit možnost, že odhady budou správné.

Teprve po vyřešení těchto dalších otázek bych se zabýval přesností odhadů. Mohli bychom vytvořit matici, která odhalí variabilitu nebo diferenciaci odhadů. Pokud je odchylka vysoká, tým zjevně neprovádí odhady správně. Abychom to napravili, mohli bychom zavést kontrolní seznam odhadů, který by určil, co by mělo být součástí odhadů – revize kódu, QA, nasazení atd. – a měl by zahrnovat implantaci a návrh.

Získané zkušenosti

• Problémem většinou nejsou odhady. Problém je však v tom, že technika funguje jako černá skříňka. Konkrétně v případě podhodnocených prací žádám inženýry, aby zúčastněné strany neprodleně informovali.
• Nezáleží na odhadech, ale na tom, zda PM vybral ty správné funkce, na kterých by měl tým pracovat a které by byly pro zákazníky přínosné a přinesly nám největší příjmy. Proto bychom se místo na odhady měli zaměřit na stanovení priorit.

Původně zveřejněno na https://www.platohq.com 14. září 2020.