„Tuhle funkci musíme přidat hned teď. Nemůžeme to bez ní spustit. Každý ji chce. Je to jen malá drobnost, takže to bude snadné. Měli byste to zvládnout rychle!“*
Je vám to povědomé? Jde o necelých 30 slov, ale stovky předpokladů, úkolů a požadavků. A v čem je problém?
V nevědomosti, která tímto do týmu přináší demotivaci expertů a rozhodně nevede k hladkému řešení, jenž nejspíš ani nenaplní očekávání iniciátora. Tento způsob komunikace je zkrátka zaručeným receptem na katastrofu. Zkusme na jednotlivá slovní spojení nahlédnout racionálně, co vlastně říkají:
„Tuhle funkci …“
Přirozeně se ptáme, jakou? Pokud je možné experty odkázat na správně zpracovaný use-case, je to v pořádku. Vývojáři budou přesně vědět, co se po nich chce. Pokud však představa o funkci vznikla výměnou několika emailů a během jedné porady týden před ostrým spuštěním, je to jiná situace. Není neřešitelná, jen to bude stát více peněz a posunutí termínu. Experti totiž budou muset dedukovat z myšlenkových procesů iniciátora, budou trávit více času komunikací a vyžadovat jeho větší zapojení do vývoje. A na to by měl být připraven.
„Nemůžeme to bez ní spustit. Každý ji chce.“
Pokud vyvíjíte agilně, máte vyhráno. Experti počítají s tím, že je jim práce zadávána průběžně a priority se v čase mění. Pokud se však jedná o požadavek během dodávky specifikovaného software, je to známka dluhu, který je třeba splatit. Jaký dluh? Při návrhu aplikace někdo opomenul fundamentální potřeby uživatelů. Hrozí, že vznikne „auto bez volantu“. Dále se doporučuje ověřit si, že jde skutečně o klíčovou funkci a ne jen neodbytný dojem iniciátora. Z jeho slov by se dalo předpokládat, že úspěšně provedl detailní průzkum v přesně vymezené cílovce, což je … velmi nepravděpodobné.
„… malá drobnost, takže to bude snadné.“
To záleží … neměl by to být jen dojem. Lepší je, když náročnost úprav nebo implementace nové funkce vzejde z poctivě připraveného zadání (ano, tomu se nikdo nevyhne) a technické analýzy vývojáře na seniorské úrovni. Pouze relevantní data o rozsahu prací umožní realistické plánování aktivit v kalendáři a řízení rozpočtu. A nakonec podobným prohlášením nedonutíte vývojáře jít na LinkedIn a začít si hledat svůj nový „job“ v týmu kreativních lidí hrajících fotbálek za šestimístnou měsíční odměnu.
„… zvládnout rychle!“
Včera už bylo zřejmě pozdě. Jde o změnu priorit a ta s sebou může nést důsledky, na které iniciátor má být připraven:
- Skutečně jsou volné vývojářské kapacity, které by funkci vyrobily?
- Nejspíš bude potřeba upozadit práce na jiném projektu. To může ovlivnit termíny a způsobit potíže jinde. Je to pro iniciátora akceptovatelné?
Jak z toho ven?
Celkem jednoduše. Kvalita softwarového řešení odráží kvalitu lidí, kteří ho chystají. A jako u zdraví i zde platí, že prevence před bortícím se týmem, prošvihnutými termíny, finančními ztrátami je k nezaplacení a dostupná všem. Stačí udělat několik kroků správně:
- Mějte jasný záměr a cíle digitalizace (IT projektu).
- Připravte kvalitní zadání včetně technické analýzy.
- Specifikujte, co přesně má být dodáno a v jaké licenci.
- Určete rozpočet a pravidla pro řešení servisních prací.
- Nastavte transparentní platformu pro výměnu dat a informací v realizačním týmu.
Všechny tyto služby lze také poptat u nezávislého konzultanta, který ve vašem týmu sehraje klíčovou roli. Bude kompetentním partnerem expertů na vývoj a dodávku software. Nebo chcete „kormidlovat“ IT projekt sami a lépe? Zúčastněte se semináře!
* Text převzat z knihy „Restart. Průvodce podnikatelským minimalismem“ od Fried Jason a Hansson, David Heinemeier.