Jakmile si jednou objednáte software na míru, víte věci, které jste předtím nevěděli. Ne proto, že projekt skončil neúspěchem — někdy byl i úspěchem — ale proto, že vás zkušenost naučí věci, které žádný zadávací dokument ani obchodní rozhovor nepokryje.
Mluvili jsme s mnoha majiteli firem, kteří prošli alespoň jedním softwarovým projektem. Když se jich ptáme, co by příště udělali jinak, znovu a znovu se objevuje stejných pět lekcí. Žádná z nich není složitá. Ale jsou snadno přehlédnutelné, když to děláte poprvé.
1. Váš brief není totéž co požadavky
Většina klientů přichází na první schůzku s dobře promyšleným popisem toho, co chtějí. Obvykle jde o dokument, prezentaci nebo podrobný e-mail popisující požadované funkce, očekávané uživatele a přibližný rozpočet.
Je to dobrý výchozí bod. Ale není to totéž jako sada požadavků.
Rozdíl se projeví, jakmile vývoj začne. Brief popisuje myšlenku zvenčí — co má software dělat. Požadavky popisují, jak software skutečně musí fungovat, krok za krokem, pro každý typ uživatele, v každém scénáři, který může nastat.
Mezera mezi těmito dvěma věcmi je místem, kde žije většina problémů projektu.
Majitel firmy může napsat: „Uživatelé by měli mít možnost odesílat objednávky." Vývojář stavící na tomto tvrzení se zeptá: Jaký typ uživatelů? Jaké produkty lze objednávat a v jakých kombinacích? Co se stane, když je položka vyprodána? Jaké potvrzení uživatel obdrží? Lze objednávky zrušit, a pokud ano, kým a do kdy? Co se stane, když selže platba?
Každá z těchto otázek má odpověď, která ovlivňuje způsob, jakým je software postaven. Pokud jsou tyto odpovědi nalézány během vývoje — a nikoli předem — způsobují zpoždění, přepracování a někdy i zásadní přeprojektování.
Co zkušení klienti dělají jinak: Vyhrazují čas na strukturovanou fázi požadavků ještě před napsáním jakéhokoli kódu. Do rozhovoru brzy zapojí lidi, kteří budou systém skutečně používat. Přistupují k úsilí o definování požadavků nikoli jako k překážce před zahájením — ale jako k samotnému začátku projektu.
2. Vnitřní sladění je důležitější, než čekáte
Objednávku softwaru obvykle zadává jedna osoba: majitel, generální ředitel nebo vedoucí oddělení. Ale software samotný bude používat mnohem širší skupina lidí — a tito lidé mají często velmi odlišné představy o tom, co potřebují.
Tato mezera mezi osobou s rozhodovací pravomocí a koncovým uživatelem je jedním z nejstálejších zdrojů tření v projektu. Obvykle se projevuje zhruba v polovině vývoje, kdy interní zainteresované strany uvidí první verzi a zjistí, že ne zcela odpovídá tomu, co měly na mysli.
Někdy je nesoulad malý a snadno opravitelný. Někdy je natolik velký, že vyžaduje značné přepracování. V každém případě to stojí čas a peníze, které by nebyly potřeba, pokud by správní lidé byli přítomni u jednacího stolu dříve.
Nejde o kritiku klientů. Většina firem je zaneprázdněna, interní procesy jsou složité a sladění všech vyžaduje úsilí. Ale náklady na toto úsilí jsou téměř vždy nižší než náklady na nápravu nesouladu během vývoje.
Co zkušení klienti dělají jinak: Identifikují klíčové interní zainteresované strany — vedoucí oddělení, vedoucí týmů, klíčové uživatele — ještě před zahájením projektu a zapojí je do procesu definování požadavků. Pořádají interní workshopy, shromažďují protichůdné názory a řeší je dříve, než vývojovému týmu předloží jednotný brief. Budují vnitřní sladění stejně explicitně, jako by budovali jakoukoli jinou část projektového plánu.
3. První cenová nabídka zřídka odpovídá konečné ceně — a to není známka nepoctivosti
Jedním z nejvíce zneklidňujících okamžiků softwarového projektu je chvíle, kdy se cena začne odchylovat od původně nabídnuté částky. To se může jevit jako trik — a v ojedinělých případech špatných hráčů jím skutečně je. Ale mnohem častěji to odráží jednoduchou skutečnost: projekt nebyl plně definován, když byl dán první odhad.
Cenové nabídky na software jsou odhady, nikoli fixní ceny — pokud není rozsah pevně stanoven, požadavky podrobně popsány a nejistoty vyřešeny. Když vám firma dá nabídku na základě briefu a nikoli podrobné specifikace, odhaduje na základě předpokladů. Jakmile jsou tyto předpoklady testovány realitou během plánování a vývoje, číslo se upraví.
Nejde o nepoctivost. Tak funguje odhadování u složitých, zakázkových prací. Stavební firma vám nemůže dát pevnou cenu za budovu bez průzkumu půdy, architektonických výkresů a specifikace materiálů. Softwarová firma stojí před stejnou výzvou.
Klienti, kteří se cítí nejvíce podvedeni překvapeními v rozpočtu, jsou obvykle ti, kteří zacházeli s rannými odhady jako se závazkem, ještě než byly požadavky pevně stanoveny.
Co zkušení klienti dělají jinak: Žádají o odhady v různých fázích — přibližné rozmezí ve fázi briefu, podrobnější číslo po discovery fázi a fixní cenu (pokud to chtějí) teprve poté, co jsou požadavky důkladně definovány. Do svého rozpočtu zahrnují rezervu — obvykle 15 až 20 procent — na pokrytí změn, ke kterým téměř vždy dochází. Vývojovému týmu se ptají konkrétně, jaké předpoklady jsou základem odhadu.
4. „Funguje" a „připraveno k použití" jsou dvě různé věci
V téměř každém softwarovém projektu nastane fáze, kdy vývojový tým oznámí, že funkce je hotová. A pak přijde okamžik, kdy ji poprvé použijete a zjistíte, že — i když technicky funguje — něco na ní není zcela správně.
Tlačítko je na špatném místě. Pracovní postup neodpovídá tomu, jak tým skutečně pracuje. Popisky používají technické termíny, kterým nikdo v kanceláři nerozumí. Nejdůležitější funkce vyžaduje tři extra kliknutí, která vše zpomalují.
Nic z toho neznamená, že software je rozbitý. Znamená to, že software potřebuje testování a zpětnou vazbu, než je skutečně připraven — a toto testování musí provádět skuteční uživatelé, kteří plní skutečné úkoly, nikoli jen vývojáři, kteří kontrolují, zda kód běží.
Tato fáze se nazývá akceptační testování a právě zde se formuje velká část praktické hodnoty projektu. Je to také fáze, do které mnoho prvotimových klientů nedostatečně investuje. Vidí ji jako formalitu — zaškrtnutí políčka před spuštěním — spíše než jako nezbytnou součást budování něčeho, co lidé budou skutečně dobře používat.
Co zkušení klienti dělají jinak: Plánují čas a kapacitu pro řádné uživatelské testování před spuštěním. Do přezkoumávání každé funkce zapojí skutečné uživatele — nejen manažery. Zpětnou vazbu z testování vnímají jako očekávanou a cennou, nikoli jako důkaz, že se něco pokazilo. Vývojovému týmu dávají strukturovanou, konkrétní zpětnou vazbu, nikoli obecné dojmy.
5. Vztah s vývojovým partnerem je důležitější než smlouva
Před zahájením projektu se smlouva zdá důležitá. Definuje, kdo je za co zodpovědný, co se stane, když něco selže, a jak se řeší spory. Na těchto věcech záleží a dobrá smlouva stojí za to ji mít.
Ale v průběhu skutečného projektu ke smlouvě zřídkakdy dochází. To, co přichází konstantně — na každé schůzce, v každém e-mailu, při každém rozhodnutí — je kvalita vztahu mezi klientem a vývojovým týmem.
Dobrý vývojový partner vám řekne, když to, o co jste žádali, není nejlepší přístup. Upozorní vás, když se rozsah rozšiřuje, ještě než se to stane problémem. Technická omezení vysvětlí srozumitelným jazykem, místo aby se skrýval za odborný žargon. Vaše obchodní cíle bude brát jako měřítko úspěchu, nikoli jen seznam úkolů.
Obtížný vztah — i s technicky zdatnými vývojáři — přináší projekty, kde problémy doutnají, kde otázky zůstávají nezodpovězeny, kde zpětná vazba není slyšena a kde jsou nakonec obě strany nespokojeny, i když každá technicky dělala svou práci.
Zkušení klienti věnují stejnou pozornost kvalitě komunikace v procesu prodeje jako technickým pověřením a ceně. Protože rozhovory v průběhu návrhu vám hodně říkají o tom, jaké budou rozhovory v průběhu vývoje.
Co zkušení klienti dělají jinak: Věnují pozornost tomu, jak je vývojářská firma reagující, upřímná a srozumitelná, ještě před podpisem čehokoli. Hledají partnery, kteří kladou pronikavé otázky, zpochybňují předpoklady a vysvětlují své uvažování — ne jen ty, kteří se vším souhlasí a slibují rychlé dodání. Investují do samotného vztahu: pravidelná komunikace, včasná zpětná vazba a přistupování k vývojovému týmu jako ke spolupracovníkům, nikoli dodavatelům.
Žádná z těchto lekcí nevyžaduje výjimečný vhled, aby ji člověk pochopil. Jsou to věci zdravého rozumu, jakmile je vidíte naplno. Výzva spočívá v tom, že je snadné je podhodnotit, než projekt začne — kdy je vše ještě plné možností a zdá se předčasné přemýšlet o tom, co by mohlo jít špatně.
Právě tehdy na nich záleží nejvíce.
Pokud plánujete softwarový projekt a chcete si před zahájením promyslet některý z těchto bodů, ozvěte se nám. Tyto rozhovory jsou vždy snazší, než je smlouva podepsána.