IT Business Analýza je jedno z řemesel, které můžete už pár desítek let potkat v projektových, IT nebo obecně inovačních teamech. Někdy ji dělá specialista jako svou hlavní roli, jindy business analytické činnosti dělá jako vedlejšák jiná role jako třeba projektový/produktový manažer, nebo sám programátor.
V tomto článku se Vás pokusím přesvědčit, že IT business analýzu nejde nedělat. Je možné ji dělat pozdě, dá se dělat špatně, či neefektivně někým kdo nemá potřebné znalosti a vlohy. Ale nejde ji ve světě změn a inovací nějak přeskočit a nedělat.
Z definice business analýzy dle standardu BABOK® bohužel tvrzení výše tak úplně nevyplývá. A je potřeba se podívat detailněji na nejčastější činnosti, které tvoří náplň analytické práce.
"Business analysis is the practice of enabling change in an enterprise
by defining needs and recommending solutions that deliver value to stakeholders."
Ve stručnosti analytické práce zahrnují zjištění stávajícího stavu, odfacilitování shody na cílovým stavem a pohlídání, že všechny zainteresované strany mají stejné informace a očekávání. S tím pomáhají mimo jiné best-practices jako identifikace a analýza potřeb stakeholderů, formulace a prioritizace požadavků, zjištění dopadů navrhovaných řešení a příprava podkladů pro výběr nejvhodnějšího řešení. Opravdu poctivé vymezení analýzy, včetně základních technik a příkladů z praxe se do tohoto odstavce, ani článku nevejde a je to téma na samostatné několikadenní školení.
Teď zpátky k tématu tohoto článku. Typický změnový projekt, či iterace s dopadem do IT řešení zahrnuje činnosti jako definice cílů a zadání, analýzu, návrh, samotnou výrobu, testování, nasazení do produkce a provoz, který má na začátku intenzivnější stabilizační fázi. U vývoje nikdo nebude zkoušet tvrdit, že není potřeba, protože bez toho by nevznikl žádný nový produkt.
U testování už můžeme zkusit říct, že není potřeba. Nicméně pokud nějaký team nebude mít testery, v praxi bude testovat vývojář, nebo jiná role. A pokud ne tak budou prvními testery uživatelé, kteří budou nacházet jako první chyby a nesrovnalosti. Takže nejde netestovat. Jde to odfláknout a nechat na uživatelích, ze kterých si pak team udělá externí testery.
Analogicky můžeme zkusit nedělat analýzu. Co se stane? Vývojář potřebuje vědět, co má vytvářet. Jak to zjistí? Musí se potkat ze zadavateli, zjistit co potřebují, zjistit dopady, navrhnout řešení a sladit se na tom se všemi zainteresovanými stakeholdery. A co vidíme, že dělá? Analýzu. Pokud analytické činnosti vývojáři hypoteticky zakážeme (nebo je nebude umět udělat), tak bude programátor přinucen si zadání nějak vymyslet na základě informací, které aktuálně má. Přirozeně se potom úplně netrefí do očekávání zákazníků, což se začne projevovat v testech, kdy se testeři začnou ptát: „K čemu tato funkce slouží? Jak se to má chovat. Co má uživateli přinést? Nebo co se stany když…“ A najednou nám začnou testeři těmito otázkami dohánět chybějící analýzu. Což asi nebude moc efektivní. Nakonec když se v takovém teamu dostane nějaký produkt k prvním uživatelům, můžeme čekat dvě věci. Buď to řešení nebudou používat pokud mají tu možnost, nebo se budou snažit najít pomoct na funkční podpoře. A tam se budou odehrávat hovory, kdy uživatel se ptá jak zrealizuje konkrétní případ užití a funkční podpora se bude snažit nalézt cestu jak toho v takto vyvinuté aplikaci dosáhnout. A bude se ptát: „Co potřebujete udělat? Jaké vstupní údaje máte k dispozici? Co byste říkal na alternativu X“. A zase co nám takový hovor připomíná? Standardní analytické „Interview“, kterým analytik zjišťuje potřeby a očekávání zákazníků a tedy analýzu.
Můžeme analýzu nechat na vývojářích, či funkční podpoře, ale je to efektivní? Jaký dopad to má na výslednou spokojenost uživatelů a celkovou návratnost investice do takto řízené inovace? Můj názor tušíte. 🙂
V některém z dalších článku se budeme věnovat symptomům pomocí, kterých je možné objevit, kde to teamu v analýze skřípe a díky tomu zvyšovat celkovou efektivitu dodávek.
