Problém

Často slyším stakeholdery nebo PM stěžovat si, že inženýrský tým opakovaně nedokáže dokončit svou práci včas. Tlačí ještě více na termíny za předpokladu, že to pomůže. Ve skutečnosti to jen vytváří další napětí, které nikomu nepomáhá. Také se snaží přidávat umělé buffery, což problém dále komplikuje.

Odhady samotné jsou však málokdy problémem a neustálá zpoždění jsou obvykle způsobena něčím jiným než nepřesnými odhady. Proto se nenechte odhady držet v zajetí!

Podniknuté kroky

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 interpretovány šířeji tak, aby zahrnovaly hodnotu vývojového procesu, a neměly by být vystavovány a diskutovány mimo rámec softwarového vývoje.

Pokud tým nedokáže doručit včas, jeho odhady jsou považovány za nepřesné nebo nekorektní. Teprve použití správných poznatků nám může pomoci zjistit, o čem problém skutečně je. Obvykle jsem zjistil, že systém dodávky nefunguje správně. Konkrétně během sprint plánování se tým zaváže k několika issues, které mají být implementovány, ale objeví se velké množství neplánovaných věcí — od bugů po různé typy blokerů — které nebylo možné předvídat. Řešením je identifikovat možné neplánované nebo ad hoc issues a jasně definovat, za jakých okolností mohou přerušit implementaci plánovaných aktivit. To zahrnuje definici všech těch neplánovaných issues; například co by představovalo blocker atd. Pokud tým řeší několik ad hoc issues měsíčně, věci budou pravděpodobně probíhat podle plánu. Ale pokud neplánované issues tvoří 20–30 procent výstupu, způsobí to vážné problémy a v důsledku toho zpoždění.

PM a tech leadi by také měli mít jasný přehled o typu práce, kterou tým dokončuje; například kolik funkcí nebo bugů řešili, kolik supportu poskytli nebo pomohli zákazníkům atd. Pokud máte komplexní přehled, můžete upravit očekávaný poměr a začlenit to do plánování dalšího sprintu. Tento přístup pomůže s odhady, protože poskytne záruky pro výstup, jak je zahrnut v roadmapě. Pokud tým a PM budou jednat transparentně a pravidelně informovat stakeholdery o stavu funkcí, výsledkem bude porozumění a podpora. Pokud si v kterémkoli okamžiku všimneme, že možnost zpoždění roste, měli bychom o tom stakeholdery okamžitě informovat. Nejhorší scénář je držet informace o možných zpožděních až do samotného dne dodání.

Další věc, se kterou jsem se setkal, byla nedostatečná komunikace mezi produktem a inženýrstvím. Produkt obvykle předal požadavky a inženýrství je doručilo. Nejenže je to spíše waterfall přístup, ale brzdí to produktivitu inženýrství. Místo toho by produkt a inženýrství měly mít příležitost navrhovat věci společně, což by pomohlo inženýrům pochopit složitost a všechny okrajové případy a tím zvýšit pravděpodobnost, že odhady budou správné.

Teprve poté, co jsou tyto další problémy vyřešeny, bych se podíval na přesnost odhadů. Můžeme vytvořit matici, která odhaluje variaci nebo diferenciaci odhadů. Pokud je variace vysoká, pak tým jasně nedělá odhady správně. Abychom to opravili, můžeme implementovat estimation checklist, který identifikuje, co by mělo být součástí odhadů — code review, QA, deployment atd. — a měl by zahrnovat implementaci a design.

Ponaučení

• Odhady nejsou většinou problém. Problém však je, že inženýrství jedná jako černá skříňka. Konkrétně v případě podhodnocené práce žádám inženýry, aby neprodleně informovali stakeholdery.
• Nejsou to odhady, na kterých nejvíce záleží, ale to, zda PM vybral správné funkce, na kterých by měl tým pracovat a které přinesou zákazníkům užitek a nám nejvíce tržeb. Proto bychom se místo zaměření na odhady měli zaměřit na prioritizaci.

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