Martin Snížek

IT vývoj má ve firmě obří přidanou hodnotu – může ušetřit práci celým týmům nebo otevřít příležitosti pro růst. Často je ale ve firmách slyšet, že vývoj nefunguje tak rychle a efektivně, jak by mohl. Možná se poznáte v některé z těchto situací:

• Vývoj trvá dlouho – nové věci vyvinout trvá měsíce, nebo se dokonce měsíce čeká jen na kapacitu.
• Nové funkcionality neřeší hlavní problémy zákazníků – zákazníci si stěžují dlouhodobě na konkrétní potíže nebo chtějí konkrétní funkci, ale vývoj pracuje na odlišných prioritách. Ve firmě je pohled, že vývojové priority by možná měly být na jiné věci.
• Mnohaměsíční velké projekty, které se na konci spouští celé najednou – občas to jinak nejde, ale v mnoha případech by šlo postupovat po částech a snížit riziko neúspěchu na mnoha úrovních.
• Vyvine se trochu něco jiného, než co čekali lidé ve firmě nebo zákazníci – vývojáři se snaží vyřešit jiný problém, než který by zákazníci nebo zaměstnanci potřebovali vyřešit.
• Řešení dodaná vývojem často nejsou doladěná, obsahují spoustu chyb – navíc chyby zjištěné při spuštění trvá velmi dlouho odstranit.
• Termín dodání se mnohokrát posouvá u většiny projektů.
• Po dodání se bere za úspěch hlavně to, že byla funkcionalita dodána, případně že včas. V tu chvíli ani později se ale neřeší, kolika pomohla funkcionalita zákazníkům, jestli zlepšila nějaké sledované metriky. (Tento jev se krásně nazývá feature theatre).

Když jsem se snažil o zlepšení některých z těchto problémů, narazil jsem na 7 příčin, které popíšu a přidám možná řešení.

Je důležité říct, že většina těchto příčin není způsobena vývojáři samotnými, ale spíše způsobem řízení vývoje i firmy.

1. Vývojové projekty nejsou navázány na hlavní problémy firmy

Každá firma má obvykle hlavní problémy, které se aktuálně pokouší řešit. Příležitosti, které chce oslovit. To se většinou projevuje v hlavních metrikách, které se ve firmě sledují, a v nastavených cílech.

Kupodivu ale často není vývoj na tyto problémy a příležitosti vůbec napojen – projekty ve vývoji mají technické názvy a jsou firmě nesrozumitelné. To není správně – vývoj může vygenerovat obří hodnotu a jeho kapacita by se měla používat na ty nejpalčivější problémy a příležitosti, které ve firmě jsou.

U každé firemní priority doporučuju se během plánování zamyslet, jak právě vývoj může nejlépe tu danou prioritu posunout. Častý přístup je spíš opačný, kdy se nejprve udělá seznam vývojových projektů a ty se zařazují pod firemní priority – tím se ale často opomenou velké příležitosti.

2. Cílem vývojových týmů je dodávka konkrétní funkcionality, ne výsledek pro zákazníka/business

Vývojové projekty jsou často plánovány už jako konkrétní funkcionalita webu nebo aplikace. Všichni „u stolu“ jsou přesvědčeni, že právě ta funkcionalita, o které se už dlouho spolu baví, povede k cíli. A tak se do firemních ročních/kvartálních priorit dostanou rovnou názvy konkrétních funkcí, které se nově vyvinou.

V praxi se ale ukazuje, že obvykle není možné v high-level plánování uhodnout, jaká funkcionalita nejlépe vyřeší problém nebo uchopí příležitost, o které nám jde. Hlavně proto, že nikdo nemá při plánování potřebnou úroveň detailu v pochopení zákazníka nebo problému – vždycky je potřeba jít po krůčkách, validovat nápady se zákazníky a zkoušet, co opravdu funguje (příklad k tomu níže).

Proto je lepší týmu zadat právě příležitost nebo problém k vyřešení, ideálně i s nějakou metrikou, pomocí které se dá měřit progres. Součástí práce týmu je i hledání správného řešení – a na konci třeba vznikne řešení, které by na začátku nikoho nenapadlo.

3. Vývojáři nevidí cíle stejně jako business

Co se dozvíte, když se vývojářů a manažerů vývoje zeptáte, co považují za úspěch svojí práce na projektu? Naprogramovat funkci, nebo pomoct zákazníkovi? Mají na paměti, proč tu funkci programují, k čemu to má pomoct? Rozumí tomu, jaký firma sleduje cíl? Často ne. Mnoho vývojářů je v pozici, kdy očekávají detailní zadání a „nevidí vlevo vpravo“.

Základem je sladit cíl vývojářů s tím, proč se daný projekt nebo funkcionalita dělá. Moje zkušenost je, že vývojáře smysl jejich práce velmi zajímá a k cílům určitě budou mít spoustu otázek a pohledů. Toto sladění s firmou vyžaduje čas a energii, které se ale bohatě vrátí – na větší motivaci a lepším výsledku.

Pokud máte ve firmě nějakou formu plánování kvartálních cílů oddělení a lidí (případně OKRs), tak u vývoje by se tam právě business cíle projektů měly dostat.

4. Příliš velké vývojové týmy

Nejlepší produkt vzniká v malém týmu, který je relativně autonomní – řekněme 5-10 lidí se zastoupením všech hlavních profesí (vývoj, produkt, design). V takovém týmu může každý velmi dobře rozumět cílům, je možné velmi rychle zkoušet věci na malých prototypech a měnit směr vývoje podle toho, co vypadá slibně z pohledu zákazníků a metrik. Zároveň se v tomto počtu lidí dá komunikovat bez velkého „overheadu“.

Co znamená autonomní tým? Měl by být schopen co nejvíce ze svého cíle ovlivnit sám a neměl by být příliš závislý na dodávkách jiných vývojových týmů. Pozná se to tak, že členové týmu reálně cítí vlastní ownership za týmový cíl a mají pocit, že ho dokážou ovlivnit svojí prací. V jakékoliv střední a větší firmě už se to nikdy nepodaří stoprocentně, ale jde o to jít tím směrem.

5. Nedělá se pořádně product management

Ve většině firem, které mají IT vývoj, existuje i pozice product manager nebo product owner. Product manager by měl přinášet:

1. Hluboké porozumění zákazníkovi
2. Chápání cílů firmy a její pozice na trhu
3. Porozumění technologickým omezením produktu

Výsledkem těchto hledisek je produktová vize, strategie a prioritizace. A tím pádem také velká míra ownershipu nad rozvojem svěřeného produktu.

V mnoha firmách je ale bohužel produkťák vnímán ve velmi zúženém pojetí – jako jakýsi project manager, který převezme požadavky od businessu a zajistí jejich realizaci vývojem. Ne jako nositel zákaznického insightu, vize a produktové strategie. Často se pak stane, že se vyvíjí rozsáhlé řešení, které zákazníkovi ani businessu na konci moc nepřinese.

6. Nedělá se validace příležitostí

Ve firmě je vždycky spousta konkrétních nápadů na inovace a funkcionality. Před tím, než se začnou programovat, se snažím zamyslet nad jejich validací. Ukážu to na příkladu – dejme tomu, že dodáváme zákazníkům zboží podle jejich objednávky a někteří zákazníci zmiňují, že by rádi viděli v našem systému stav své objednávky. Kladl bych si tyto otázky:

• Jaký zákaznický problém se snaží daný nápad vyřešit?
  Nejspíše, že zákazník má pochybnosti nebo nejasnosti během dodání zakázky. Bylo by dobré zjistit, v jakých fázích k tomu dochází nejčastěji, případně jestli to není spojeno spíš se situací, kdy se něco v objednávce nepodaří podle očekávání.
• Dá se ten problém řešit i jinými způsoby?
  Lze řešit jen situace, které vedou k nespokojenosti zákazníka – v nejjednodušší verzi ani nic nevyvíjet a jen dát více ručního dohledu a komunikace do objednávek, které probíhají problematicky.
  Pokud je potřeba pokrýt všechny objednávky, tak jsou implementačně různě náročné varianty – např. rozesílání informací e-mailem vs. zákaznická sekce na webu.
• Aby tento nápad vyřešil daný problém, jaká hypotéza o zákaznících se musí potvrdit?
  Pokud bychom např. zjistili, že poptávka po sledování objednávky je hlavně u objednávek zpožděných nebo jinak problematických, tak hypotéza by mohla být: „Tím, že zákazníka lépe informujeme o stavu objednávky, tak se sníží jeho nespokojenost/frustrace a s větší pravděpodobností u nás nakoupí i příště.“
• Můžu tuto hypotézu nějak levně a jednoduše validovat (ověřit) předtím, než budu implementovat celý nápad?
  Nápad bychom mohli ověřit třeba tím, že vyčleníme zaměstnance, který bude u části problematických objednávek po omezenou dobu ručně posílat e-maily/smsky o stavu objednávky, a pak si vyhodnotíme spokojenost/retenci u zákazníků, kteří tyto informace dostávali.

Jak vidíte na příkladu, z velkého vývojového projektu jsem udělal jednoduchou iniciativu, kde vývoj zatím ani není potřeba. Kapacitu vývoje můžu využít na jiné nápady, které už třeba úspěšnou validací prošly.

Tato cesta je mnohem bezpečnější. Představte si, kdybych sledování objednávek rovnou implementoval a až pak zjistil, že zákazníky ve skutečnosti štve zpoždění objednávky, a žádná úroveň komunikace o objednávce jejich spokojenost nezlepší. Díky validaci nápadu toto zjistím levným způsobem, a můžu pak vrhnout vývojovou kapacitu třeba na zlepšení toho zpoždění.

7. Technický dluh

Technický dluh je cena za rychlý postup kupředu, za rychlý vývoj:

• Není vždy čas udělat věci technicky správně.
• Některé funkce narostou do rozsahu, který nikdo nepředpokládal.

Vývoj některých jednoduchých funkcí může kvůli technickému dluhu trvat velmi dlouho – když je potřeba udělat změnu v technicky zastaralé/nevyhovující části aplikace, nebo ji celou naprogramovat od začátku znovu. Obojí může vzít hodně času a když je toho moc, tak to i demotivuje vývojáře.

Tato situace je normální. Podle mých zkušeností je optimální držet se někde „v prostředku“:

• Nenechat technický dluh narůst příliš. Investovat část kapacit i do řešení technického dluhu – zažil jsem obvykle kolem 20 %. Je potřeba i zde ale jít podle priorit, od těch nejpalčivějších míst systému, se kterými ale zároveň máte rozvojové plány.
• Na druhou stranu nežít v pohledu, že dokud se nevyřeší většina technického dluhu, musí se zastavit vývoj nových věcí. To by firmu většinou moc zpomalilo. Každý nový vývoj také generuje další technický dluh, takže stav „vyřešeného technického dluhu“ nejspíš vůbec neexistuje.

Diskuse k tomuto článku je možná na LinkedIn. Budu rád, když připojíte své zkušenosti, pohledy nebo otázky!