Většina majitelů firem, kteří poprvé objednávají software, si přibližně představuje totéž: popíšete, co potřebujete, předáte to dál a po pár měsících dostanete hotový produkt.
Tak to ale úplně nefunguje.
Software na míru si nekoupíte a nepřeberete. Vytváříte ho společně — ve spolupráci mezi vámi, který rozumí byznysu, a vývojovým týmem, který rozumí technologii. A to, jak dobře tato spolupráce probíhá, závisí stejně tak na tom, co do ní přinesete vy, jako na schopnostech týmu.
Tento článek prochází každou fází typického projektu a vysvětluje, jak přesně vypadá vaše role v každém z nich — co si připravit, na co si dát pozor a kde váš vstup nejvíc rozhoduje.
Před spuštěním projektu: ujasněte si problém
Nejcennější věc, kterou můžete udělat ještě před zahájením projektu, je opravdové ujasnění toho, jaký problém chcete řešit — ne jaké funkce chcete, ale co ve vašem byznysu skutečně nefunguje tak, jak by mělo.
Co si připravit:
- Popis aktuálního stavu: jak to dnes funguje, kde je tření, co vás to stojí v čase nebo penězích
- Představu o tom, kdo je situací zasažen — kteří lidé ve firmě, kteří zákazníci
- Hrubou představu o tom, jak vypadá úspěch za šest nebo dvanáct měsíců
- Omezení, která jsou důležitá hned od začátku: orientační rozpočet, nutné integrace, regulatorní požadavky, termínový tlak
Nemusíte mít hotovou specifikaci. Potřebujete mít dost jasno na to, abyste mohli mít produktivní první schůzku. Specifikaci vám pomůže sestavit vývojový tým — ale k tomu potřebuje materiál, ze kterého bude vycházet.
Během discovery: sdílejte i nepořádek
Fáze discovery je místem, kde je váš vstup nejdůležitější — a zároveň nejpodceňovanější.
Mnoho klientů se snaží představit svoji firmu v idealizované podobě. V softwarovém projektu je to ale kontraproduktivní. Tým potřebuje pochopit, jak to u vás skutečně funguje — včetně obcházení pravidel, výjimek, neoficiálních procesů a věcí, které jsou trapně ruční.
Co byste měli dělat:
- Být opravdu dostupní na workshopech a pohovorech — ne jen vyslat náhradníka
- Zapojit lidi, kteří práci skutečně dělají, nejen ty, kdo ji řídí
- Sdílet reálné příklady: ukažte tabulku, projděte skutečnou objednávku, předveďte celý proces
- Být upřímní ohledně toho, co nevíte — „nevím přesně, jak to řešíme v takovém případě" je mnohonásobně užitečnější než jistá odpověď, která se ukáže jako nesprávná
Čím realističtější obraz tým z discovery získá, tím přesněji dokáže navrhnout a odhadnout, co vlastně staví.
Během návrhu: reagujte rychle a říkejte, co vidíte
Jakmile je discovery hotová, tým přetaví vaše požadavky do konkrétních návrhů — rozložení obrazovek, toky uživatelů, seznamy funkcí a technická rozhodnutí.
Toto je vaše poslední jasná příležitost formovat produkt, než začne vývoj. Změny provedené ve fázi návrhu nestojí téměř nic. Změny provedené v průběhu vývoje jsou výrazně dražší.
Co byste měli dělat:
- Procházet návrhy bez zbytečného odkladu — prodlení tu posouvá celý harmonogram
- Reagovat na skutečný návrh, ne na to, co jste očekávali: odpovídá to tomu, jak to váš tým bude opravdu používat?
- Upozornit na cokoli, co neodpovídá skutečnému fungování firmy
- Klást otázky i v případě, že si nejste jisti, zda jsou důležité — v této fázi je překomunikování vždy správnou volbou
- Dávat jasné odpovědi: když vám tým předloží dvě možnosti, rozhodněte se konkrétně
Neschvalujte něco jen proto, že to na obrazovce vypadá rozumně. Požádejte, aby vás někdo provedl celou cestou uživatele — jako byste tu práci dělali sami každý den.
Během vývoje: zůstaňte zapojeni, ale nepřeprojektovávejte
Vývoj je fáze, kde nese největší část práce tým — ale vaše role tím nekončí.
Zpravidla vám budou každý jeden až dva týdny ukazovány průběžné ukázky. Nejsou to jen informační schůzky. Jsou to kontrolní body, kde můžete zachytit problémy včas, dokud je jejich oprava ještě relativně levná.
Co byste měli dělat:
- Skutečně testovacím prostředím procházet — ne se jen podívat na screenshot nebo video
- Testovat scénáře, které jsou pro váš byznys nejdůležitější: běžné situace i nepříjemné výjimky
- Odpovídat na dotazy týmu bez prodlení — zpožděná odpověď může celý tým zablokovat na dny
- Pokud zjistíte, že je třeba něco změnit, řekněte to okamžitě — a zároveň počítejte s tím, že změna rozsahu má cenu v čase i penězích
Co byste dělat neměli:
- Přidávat nové požadavky bez diskuze o jejich dopadu — každý přídavek posouvá něco jiného
- Mlčet o obavách, abyste nevypadali jako problematičtí
- Předpokládat, že tým vycítí to, co mu neřeknete
Jedno praktické pravidlo: pokud vidíte něco, co nevypadá správně, řekněte to ten den. Ne příští týden.
Během testování (UAT): to je vaše odpovědnost
Uživatelské akceptační testování — kde vy a váš tým ověřujete systém před jeho spuštěním — není formalita. Je to zásadní kontrola kvality, kterou může provést jen a jen vaše strana.
Vývojový tým testuje technickou správnost: dělá systém to, co bylo specifikováno? UAT testuje byznysovou správnost: funguje systém tak, jak to váš byznys potřebuje? To jsou dvě různé otázky, a na tu druhou může odpovědět jedině vaše firma.
Na co se zaměřit:
- Procesy, které váš tým bude provádět každý den — testujte je důkladně a opakovaně
- Výjimky a hraniční případy, o nichž víte, že se v reálném provozu vyskytují
- Integritu dat: pokud migrujete ze stávajícího systému, zkontrolujte, zda se klíčové záznamy přenesly správně
- Zkušenost pro různé typy uživatelů — to, co vidí manažer, se může výrazně lišit od toho, co vidí pracovník v terénu nebo zákazník
Zapisujte si vše, co nefunguje podle očekávání. Rozdělte zjištění podle závažnosti: co musí být opraveno před spuštěním, co by mělo přijít brzy po spuštění a co může počkat.
Při spuštění: řiďte změnu uvnitř firmy
Den spuštění bývá vnímán jako moment vývojového týmu. Interní change management je ale čistě ve vašich rukou.
Technicky skvělý systém může selhat v adopci, pokud na něj lidé nejsou připraveni. Vývojový tým vám může pomoci s materiály pro školení a dokumentací — ale zvyky a kulturu vaší firmy změnit nemůže. To je úloha vás jako lídra.
Co byste měli dělat:
- Komunikovat s týmem s předstihem: co se mění, kdy a proč na tom záleží
- Identifikovat interní ambasadory — lidi, kteří pomůžou kolegům s novým systémem a budou celou změnu brát pozitivně
- Uspořádat školení před spuštěním, ne v den startu
- Počítat s přechodným poklesem produktivity, dokud se lidé aklimatizují — to je naprosto normální a stojí za to na to být připraveni předem
- Nastavit jasnou eskalační cestu pro první týdny: na koho se obrátí zaměstnanec, když něco nefunguje nebo nedává smysl?
Čím hladší interní change management, tím rychleji se vám vrátí investice, o které jste při rozhodování uvažovali.
Po spuštění: nechte někoho za to zodpovídat
Toto je fáze, která se nejčastěji přehlíží — a přitom právě ona určuje, zda se váš software stane trvalým aktivem, nebo začne pomalu zaostávat.
Každý softwarový systém potřebuje interního vlastníka: někoho, kdo odpovídá za vztah s vývojovým partnerem, za sbírání a prioritizaci zpětné vazby od uživatelů a za to, aby systém sloužil byznysu tak, jak se byznys vyvíjí.
Jak to vypadá v praxi:
- Konkrétní interní osoba, která řídí spolupráci s partnerem
- Jednoduchý způsob, jak mohou členové týmu nahlašovat problémy nebo navrhovat zlepšení
- Pravidelné schůzky s vývojovým partnerem — třeba čtvrtletně — ke kontrole toho, co přišlo, a dohodnutí dalších kroků
- Realistický, průběžný rozpočet na údržbu a přírůstkový rozvoj — ne nové vyjednávání pokaždé, když se něco objeví
Firmy, které ze svého softwaru vytěží nejvíc, k němu přistupují jako k živému produktu: k něčemu, co roste a přizpůsobuje se spolu s byznysem — ne jako k projektu, který byl dokončen, uzavřen a archivován.
Přemýšlíte o první zakázce softwaru na míru — nebo chcete zlepšit průběh projektu, který právě probíhá? Napište nám — řekneme vám přímo, jak to u nás chodí a co od vás budeme potřebovat.