Zeptejte se zkušeného softwarového týmu, co nejčastěji stojí za nezdarem projektů, a uslyšíte vždy totéž: problém téměř nikdy nespočívá v tom, jak byl napsán kód.
Skutečné problémy začínají dřív — ve způsobu, jakým byl projekt definován. Vágní zadání, neověřené předpoklady, rozsah, na němž se nikdy jasně nedohodli. Než se začne psát kód, bývá škoda již napáchána.
Zde jsou chyby, které se opakují znovu a znovu — a co dělat místo nich.
Chyba 1: Popisujete řešení místo problému
To je ta nejčastější. Podnikatel přichází s jasnou představou, co chce: „Potřebujeme dashboard s pěti pohledy, export reportu do Excelu a mobilní aplikaci pro terénní tým."
Zní to konkrétně. Ale přeskakuje to nejdůležitější otázku: jaký problém vlastně řešíme?
Když definujete řešení dopředu, svazujete vývojovému týmu ruce dřív, než měl šanci přemýšlet, co by skutečně fungovalo nejlépe. Popsaná věc práci zvládne — ale někdy existuje jednodušší, levnější nebo efektivnější přístup, který by dobrý tým navrhl, kdybyste mu nejdřív popsali problém.
Co dělat místo toho: Začněte popisem bolestivého místa. Co je teď rozbité, pomalé nebo chybí? Jak vypadá úspěch? Nechte řešení vzejít z rozhovoru.
Chyba 2: Klíčoví uživatelé se nezúčastní přípravy zadání
Projekt bývá běžně definován jednou osobou — manažerem, který ho objednal — bez zapojení lidí, kteří budou systém každodenně používat.
Výsledkem je systém postavený na předpokladech, které se ukáží jako mylné. Skladový tým má obezličku, o níž nikdo nevěděl. Obchodní zástupci pracují v CRM na mobilu, ne na desktopu. Finanční oddělení potřebuje pole, které nebylo v zadání.
Tato zjištění pozdě ve vývoji jsou drahá. Táž zjištění v prvním týdnu jsou levná.
Co dělat místo toho: Než napíšete jediný požadavek, strávte čas s lidmi, kteří budou systém používat. Jeden nebo dva rozhovory mohou odhalit omezení a potřeby, které zcela přetvoří rozsah projektu.
Chyba 3: Rozsah považujete za pevnou smlouvu
Někteří klienti přicházejí k vývojovému projektu s očekáváním, že každá funkce je uzamčena od prvního dne a jakákoli změna je problém. To vytváří perverzní dynamiku: tým je odrazován od upozorňování na problémy a klient má pocit, že každá úprava znamená, že se něco pokazilo.
Ve skutečnosti určitá změna rozsahu je normální a zdravá. Jak vývoj postupuje a klient vidí skutečné obrazovky a skutečné pracovní postupy, dozví se věci, které nemohl vědět předem. Otázka je, zda struktura projektu takovéto učení umožňuje, nebo se mu brání.
Co dělat místo toho: Dohodněte se na jasném počátečním rozsahu, ale vybudujte proces řízení změn — jak se diskutují, upřednostňují a oceňují. Dobrý vývojový partner tento proces zprůhlední, místo aby vás trestal za přizpůsobení.
Chyba 4: Podceňování složitosti integrací
Téměř každý byznysový systém potřebuje komunikovat s jinými systémy: ERP, e-commerce platformou, platební bránou, CRM. Integrace jsou v zadáních projektů často zmíněny jako jedna kulka. V praxi mohou představovat značnou část celkové práce.
Každá integrace zahrnuje pochopení dvou systémů, ošetření okrajových případů, správu autentizace a plánování toho, co se stane, když se jedna strana změní. Zadání, které říká „integrovat s naším ERP" bez dalšího upřesnění, není úplné zadání.
Co dělat místo toho: Pro každou integraci zdokumentujte, jaká data mají proudit, jakým směrem, jak často a co se stane v chybových scénářích. Pokud neznáte odpovědi, pojmenujte to brzy — tato nejistota je součástí rozsahu.
Chyba 5: Ignorování toho, co se děje po spuštění
Zadání, které končí slovem „spuštění", vynechává polovinu obrázku. Software, který je nasazen, není hotový — je udržován, aktualizován, monitorován a rozšiřován.
Klienti, kteří nepřemýšlejí o fázi po spuštění, se pak diví průběžným nákladům na hosting, podporu a aktualizace. Zjišťují také, že funkce, které chtěli nejvíce, jsou ty, které přidali až ve verzi dvě.
Co dělat místo toho: Zeptejte se vývojového partnera na fázi po spuštění, ještě než cokoli podepíšete. Jak vypadá průběžná podpora? Kdo spravuje infrastrukturu? Jak se rozsahují a oceňují budoucí změny? Partner, který o tom přemýšlel, bude mít jasné odpovědi.
Chyba 6: Záměna „hezké mít" a „musí mít"
Každé projektové zadání obsahuje směs věcí, které firma skutečně potřebuje, a věcí, které někdo napadlo přidat. Problém je, že se tyto dvě kategorie zřídkakdy explicitně oddělí.
Když je vše označeno jako požadavek, vše se postaví. Projekt roste. Náklady rostou. Datum spuštění se posouvá. A když je hotovo, polovina funkcí se nepoužívá, protože nikdy nebyla skutečně potřeba.
Co dělat místo toho: U každé položky v zadání se zeptejte: „Pokud bychom spustili bez tohoto, přinese systém stále hodnotu?" Cokoli projde tímto testem, je musí-mít. Cokoli ne, může počkat.
Chyba 7: Vynechání discovery fáze
Mnoho klientů chce přeskočit rovnou od „tady je náš nápad" k „začněte stavět". Discovery — fáze, kdy vývojový tým se noří do problému, mapuje pracovní postupy a ověřuje přístup — působí jako zdržení.
Discovery je ale místo, kde se odehrává skutečné přemýšlení. Je to místo, kde se z 12měsíčního projektu stane 4měsíční, protože někdo objevil jednodušší cestu. Kde se požadavky, které se zdály jasné, ukáží jako protichůdné. Kde tým přijde na to, co vlastně staví.
Přeskočení discovery neušetří čas. Přemění nejistotu na drahá překvapení později.
Co dělat místo toho: Vnímejte discovery jako nezbytnou investici, ne byrokratický krok. Dobrá discovery fáze se zaplatí mnohonásobně ještě před napsáním prvního řádku kódu.
Jak vypadá dobré definování projektu
Dobře definovaný softwarový projekt není 50stránkový specifikační dokument. Je to jasný popis problému, dohodnutý rozsah pro první verzi, sdílené pochopení nejistot a proces řízení toho, co se po cestě změní.
Cílem není dokonale předvídat vše. Je to začít s dostatečným sdíleným porozuměním tak, aby překvapení byla malá a zvladatelná, ne velká a drahá.
Ve Workboxu procházíme tyto otázky s každým klientem společně — ještě před zahájením vývoje. Pokud chcete svůj projekt promyslet tímto způsobem, ozvěte se nám.