Projektová analýza
Vývoj nového softwaru není jen o programování a hromadě řádků kódu. Software je produkt, jehož tvorba vyžaduje poznání klienta, cílové skupiny, rizik a dalších aspektů, klíčových k vytvoření kvalitního nástroje.
Poznání klienta a jeho byznysu
Jako první je potřeba vyplnit mezeru mezi klientem a zhotovitelem. Klient často nemá povědomí o tom, jak probíhá vývoj softwaru, stejně jako my nemáme vhled do jeho podnikání. Je tedy potřeba si s klientem naplánovat několik schůzek, kde procházíte celým jeho byznys modelem, až do absolutních detailů.
V této fázi je třeba promluvit si jak s klientem, tak i s jeho zaměstnanci či cílovou skupinou, zkrátka s každým, kdo je pro budoucí produkt důležitý. Každý z nich může mít informace, které ostatní nepovažují za důležité nebo je neznají.
Například, vyvíjíte-li interní systém pro automobilku, těžko zjistíte reálné problémy na výrobní lince od CEO společnosti (i když vám bude tvrdit, že je zná).
Během těchto schůzek, byste měli být připraveni, že budete velice často opakovat dotaz: “proč?”. Jedině tím se dostanete ke skutečné podstatě, proč se projekt realizuje, jaké procesy dokáže zlepšit, jaké problémy dokáže vyřešit.
Jaké jsou klientovy představy o projektu?
Do výše popsaného procesu, ale nevstupujete úplně naslepo. Od zadavatele projektu (product owner) máte hrubé povědomí o jeho představě o projektu. Ta z pravidla vychází z poptávky projektu a první “oťukávací” schůzky, na které vám své představy nastíní.
V této chvíli je důležité myslet na to, že ne vše, co nám product owner tvrdí jsou fakta. Něco mohou být domněnky, které bychom si měli potvrdit nebo vyvrátit.
Například, když tvoříte pro B2C sektor, obvyklou domněnkou je cílová skupina. Velký varovný signál může být, když vám klient na otázku: “Kdo je vaše cílová skupina?”, odpoví: “No přece všichni”. Samozřejmě, může se stát, že narazíte na zkušeného klienta, který si pravidelně platí marketingové společnosti, které mu cílovou skupinu definují a zaměřují na ní marketingové kampaně. U těchto klientů máte značnou výhodu a kus práce hotový.
U B2B sektoru bývají “tricky part” procesy ve firmě. Co jsou skutečné problémy zaměstnanců, jak procesy teoreticky a jak v praxi atd. Není ovšem pravidlem, že by vedoucí neznali svou firmu. Je spoustu manažerů a CEOs, kteří svou firmu znají skrz na skrz a podají vám celkem přesný popis většiny věcí, které potřebujete znát pro počáteční analýzu projektu.
Skutečně je tento kanón na vrabce dost veliký?
Dalším zásadním bodem je stanovit si velikost projektu. Klient má někdy určité představy o projektu, vidí svůj vysněný produkt masivní, komplexní a do detailu prošpikovaný funkcionalitami. Ať už tato představa vychází z nějakého historického faktu nebo představy, že bez té dané funkcionality nemůže cílová skupina být apod., vždy je potřeba mu vysvětlit, že nejprve stavíme MVP verzi produktu. Tuto verzi dáme cílové skupině k feedbacku a aplikaci ladíme.
V nespočtu případů se nám stalo, že jsme, po dohodě s klientem, vynechali nějaké funkcionality, s tím, že počkáme, jestli je cílovka bude opravdu potřebovat. V obrovském procentu případů se nám stalo, že je cílová skupina nepotřebovala. Místo toho si řekla o jiné funkcionality, které se mohli udělat za právě ušetřené peníze. Nejhorší produkt je totiž takový, který má 100 funkcionalit, ale reálně se používají 3. Tohle je přesně princip agilního vývoje - utrácet peníze jen za to, co dává smysl a co přinese určitou hodnotu, o kterou si uživatel produktu sám řekne.
Dokončení analýzy
Celý proces analýzy se může někdy zdát celkem zdlouhavý. Je ale naprosto nezbytný pro správné určení rizik, stanovení high level odhadu ceny projektu a zadání. Klient by měl myslet na to, že každá hodina strávená nad analýzou a zadání nám ušetří potencionální den vývoje. Je totiž velký rozdíl, když se narazí na slepou uličku v průběhu analýzy, či tvorby wireframes, než při vývoji.
