Dobře zpracovaná business analýza hraje při přípravě projektu významnou roli. Co přesně je business analýza a čím se zabývá se dočtete v článku Zásady a benefity business analýzy v IT. Tentokrát se podíváme na nejčastější chyby business analytiků a na to, jak zlepšit business analýzu. Ukážeme si také příklady user stories, které jsou základním kamenem úspěchu IT projektů.
Špatná komunikace
Jednou z nejčastějších chyb, kterou business analytici dělají, je nedostatečná komunikace s klientelou. To může vést k nedorozuměním ohledně požadavků a očekávání, což mívá za následek nesprávně definovaný rozsah projektu.
Efektivní komunikace je základem role business analytika. Je důležité zahrnout do procesu všechny relevantní strany, aby byly požadavky validovány z různých perspektiv a minimalizovala se tak možnost chyb v dalších fázích projektu.
Jak se vyhnout této chybě? Ptejte se na otázky jako: Jaký problém se snažíte řešit? Jaké jsou cíle projektu?
Přehlížení zpětné vazby
Další běžnou chybou je ignorování zpětné vazby od koncových uživatelů*ek systému. Business analytici by měli pravidelně shromažďovat a analyzovat uživatelskou zpětnou vazbu, aby se ujistili, že systém splňuje skutečné potřeby a je intuitivně použitelný.
Jak zlepšit business analýzu v tomto případě? Zapojení budoucích uživatelů*ek do procesu vývoje výrazně zvyšuje šance na úspěch projektu.
Nedostatečná validace požadavků
Mnoho projektů trpí kvůli nedostatečné validaci požadavků. Je klíčové, aby business analytici prováděli důkladnou validaci požadavků s klientem*kou a týmem, který na projektu pracuje. To zahrnuje revize dokumentace, simulace a prototypování. Validace pomáhá odhalit a opravit chyby v rané fázi projektu, což šetří čas a peníze.
Ignorování změn
Projekty nejsou izolované ostrovy a často jsou ovlivněny změnami v podnikatelském nebo technologickém prostředí. Business analytici by měli být vždy na pozoru a pružně reagovat na změny v externím prostředí, které mohou ovlivnit projekt. Nedostatečná adaptabilita může vést k neúspěchu projektu.
Podcenění rizik
Každý projekt nese určitá rizika a ignorování těchto rizik mívá následky. Business analytici by měli věnovat značnou pozornost identifikaci a managementu rizik. Pravidelné revize rizik a zavádění preventivních opatření jsou důležité k udržení projektu na správné cestě.
Pokud už problém nastane, nesoustřeďte se na to, kdo byl za problém zodpovědný, ale spíše na to, proč k něčemu došlo a jak se to stalo.
Nekontrolované rozšiřování rozsahu projektu
Business analytici by měli zavést jasné procesy pro dokumentaci a sledování požadavků, aby předešli nechtěnému rozšiřování rozsahu projektu, které může vést k dodatečným nákladům a zpožděním.
Chyby business analytiků v přípravě projektu mají za následek neustálé rozšiřování a zdražování projektu. Připravte se a myslete včas na způsob, jakým se budou zpracovávat změny požadavků.
Jak uvedené chyby business analytiků podchytit už v zárodku? Základem je komunikace a zájem o uživatele*ky.
Řešení: Zaměřte se na uživatele
Jedním z klíčových kroků mezi hrubou představou a funkčním výsledným softwarem jsou user stories. V této fázi ještě neřešíte konkrétní technické řešení, tedy jak se budou dané požadavky realizovat. Nejprve je důležité pochopení potřeb koncových uživatelů*ek. Chyby business analytiků často začínají už v tomto kroku.
User story je krátký, jednoduchý popis požadované funkce pohledem osoby, která si novou funkci přeje. User story hraje významnou roli v agilních metodikách vývoje, protože zdůrazňuje průběžnou spolupráci mezi vývojovými týmy a klienty*kami.
Role business analytiků je zde nezastupitelná, protože právě oni mají za úkol tyto požadavky nejen shromažďovat, ale také je efektivně komunikovat vývojovému týmu. Ideálně je předávají v takové formě, aby bylo možné vyvinout funkcionalitu, jakou si klientstvo představuje. Analyzující by měli mít dobrý přehled jak o požadavcích, tak také o možných technických řešeních.
User stories nejsou jen zápisem požadavků, ale slouží zejména jako základ pro diskuzi, která pomáhá ještě lépe definovat, co přesně má být vyvinuto a proč. Cílem je vyjasnit si, co se konkrétně od softwaru očekává a jaké úkoly má zvládnout.
Základní šablona pro user story tak zní: Jako KDO chci CO (akce nebo funkce), aby PROČ (přínos nebo důvod).
Pokud například vyvíjíte aplikaci pro projektové řízení, user story zní: „Jako projektový manažer chci přiřazovat a sledovat úkoly členům týmu, abych mohl zajišťovat průběh projektu a efektivně alokovat zdroje.“
Veškerý obsah v užitečném formátu. Rozhovory, články, life hacky a tipy ze světa businessu i korporátů na našem Instagramu.
Pojďte se připojit!
Webové stránky Mountain Goats Software nabízí ke stažení příklady různých user stories i s komentáři, zda je uvedená user story správně, či nikoliv. Podívejme se na příklady o článcích na webu. Jaké jsou možné user stories a v čem se objevují chyby business analytiků?
„Jako návštěvník webu chci jednou týdně číst nový článek na titulní stránce, abych byl informován o všech nejnovějších událostech.“
„Jako redaktor webu mohu u každého článku přidat ukázku, aby se návštěvníci mohli rozhodnout, zda chtějí číst zbytek. Ukázka se objevuje na titulní stránce pro všechny čtenáře.“
U této user story je uveden komentář, že druhá věta by tady neměla být, protože specifikuje uživatelské rozhraní. Nicméně zobrazení novinek na titulní stránce bylo zásadní pro koncept webu, takže nikdo nic nenamítal.
„Jako redaktor webu chci mít možnost označit, zda je článek veřejně dostupný nebo je pouze pro členy, aby návštěvníci byli motivováni stát se členy.“
„Jako redaktor webu mohu na web přidat článek, aby na webu bylo dostatek obsahu.“
Komentář k user story uvádí, že zdůvodnění je poněkud slabé.
„Jako redaktor webu mohu nastavit datum zahájení publikování (kdy se ukázka objeví na titulní stránce), datum starého článku (kdy zmizí z titulní stránky) a datum ukončení publikování (kdy bude z webu odstraněn, pokud vůbec) pro články, aby se články objevovaly pouze v příhodných obdobích.“
Zde jsou v user story opět detaily uživatelského rozhraní. To, co vidíme, je poměrně běžné. Jakmile se detaily uživatelského rozhraní objeví v jedné user story, tento problém přetrvává i v následujících.
Tipy pro business analytiky
User stories by měly splňovat kritéria INVEST, což znamená, že by měly být nezávislé (independent), dosažitelné (negotiable), hodnotné (valuable), odhadnutelné (estimatable), malé (small) a testovatelné (testable). INVEST pomáhá vytvářet smysluplnější user stories a eliminovat chyby business analytiků hned v zárodku.
Psaní dobrých user stories zahrnuje také tři aspekty, které v roce 2001 pojmenoval Ron Jeffries jako karta (card), konverzace (conversation) a potvrzení (confirmation):
- Karta je písemný záznam a používá se pro plánování.
- Konverzace znamená diskuzi, která slouží k doplnění detailů.
- Potvrzení jsou kritéria, která definují, kdy je user story kompletní.
Jak zlepšit business analýzu
Business analýza problémy poměrně snadno vytváří, pokud se neřídí jasnými pravidly. V úspěchu IT projektů však hraje klíčovou roli. Chyby business analytiků stojí peníze. Vyvarování se uvedených chyb a osvojení si osvědčených postupů výrazně zlepší průběh a výsledky projektů.
Nezapomeňte, že v centru úsilí stojí komunikace a správné pochopení potřeb. User stories pomáhají definovat, co užívající od softwaru potřebují a proč. Zaměřte pozornost na uživající hned od začátku projektu a business analýzu postupně zpřesňujte. Jaké kroky podniknete, aby se vaše projekty vyhnuly běžným pastem a směřovaly k úspěchu?
