Odhady pracnosti

Jak se potýkáte s jejich přesností, jak vysvětlujete managementu proč je to takové nebo makové číslo?

Co kdybyste si museli vybrat z těchto možností? (časová jednotka je na vás)

0, 0.5, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, .. ->Fibonacciho řada (s lehce upraveným začátkem)

Nebo si podobnou řadu upravte  dle svých zkušeností. Pointa je jednoduchá, čím méně čísel se používá a tím jak se jejich rozestupy zvyšují si Vaše okolí rychleji zvykne na související nejistotu.

 

 

 

BI Delivery Process

Ukázkový BI Delivery process vychází z mých zkušeností na projektech. Jeho cílem je oddělení specifických BI rolí a dát komplexní přehled do vývoje BI, ukázat důležitost business analýzy a solution architektury.

Velká část firem tento proces nemá popsaný a každý projekt  si jede po svém. Proto jsem ke každému výstupu doplnil typické příznaky jeho přeskočení. Naplnění tohoto procesu má dlouhodobě vliv na snížení nákladů na vývoj a provoz BI řešení.  Implementace tohoto procesu není jednoduchá a je třeba navázat na současné zvyky. Nápady ve stylu udělat šablony a začít každý dokument tvrdě vyžadovat zpravidla nevedou k cíli.

Kdy přichází nutnost zavedení procesu? V situaci, kdy je analýza AS-IS stavu tak dlouhá, že se nedokončí a vývoj i provoz řešení stojí 2x tolik (plus náklady na pošramocené vztahy s dodavatelem a interním týmem), trvá 3x déle (za předpokladu, že nebude třeba hledat nového dodavatele) a přinese 20% očekávaných benefitů (pokud se projekt vůbec dokončí).

Výstupy procesu

Všechny výstupy budou jeden po druhém popsány zde na blogu. Na této stránce je pouze základní přehled.

Business Requirement Summary

Zpracuje: Business Analyst
Schvaluje: Business Architect
Účel: V jakém procesu a jak se promítne vyřešení požadavku? Kdo jsou stakeholdeři? Kdo je sponzor? Zjednodušeně jde o to zasadit požadavek do kontextu celé firmy a jejího fungování.
Platí, že zkušený business analytik (architekt) požadavek z 50% doplní právě o souvislosti napříč firmou a zachrání tak projekt od prvního restartu (u středního BI projektu úspora cca 3-6 měsíců času + adekvátní MD).
Když chybí: Do projektu budou nahodile přibývat stakeholdeři a každý přinese sadu change requestů, zároveň tito lidé a oddělení na projektu oficiálně nebudou (nebudou mít čas a projekt většinu jejich požadavků stejně odignoruje). Nepodaří se nahradit původní řešení. Vedení má pocit, že to zaměstnanci zbytečně blokují a zaměstnanci pochybují o kompetencích managementu. Měl-li projekt přinést úspory, zpravidla je převýší náklady na implementaci.

Delivery Packages Statements

Zpracuje: BI Solution architect
Schvaluje: Data Architect
Účel: Rozpad BI požadavku do jednotlivých BI dodávek (balíčků). Velikost balíčku je definována samostatností nasazení a odhadovaným časem implementace (do 5 měsíců). Delivery packages statements typicky obsahuje business kontext a popis high level architektury (Které DWH vrstvy budou upraveny (backend a fronted), datové zdroje, schématické etl) a komentář. Rozsah je maximálně 2 stránky.
Když chybí: Projekt s plánovaným trváním 1 rok probíhá následovně. Prvních 6 měsíců se tvoří analýza a panuje atmosféra optimismu a radosti, na konci tohoto období jsou všichni překvapeni, že výstupy z analýzy se míjí očekáváním, projekt se o půl roku prodlužuje. Začíná se vyvíjet první fáze, projekt začíná být pod tlakem. Přichází první spory mezi dodavatelem, zákazníkem a sponzorem. Steeringy jsou o tom, jak si „oplechovat pozadí“. Vzhledem k prodloužení přichází change requesty (okolí projektu se zpravidla nepodaří zmrazit), to projekt protáhne o dalších 6 měsíců. Přichází první rescopes a descopes. Po cca 2 letech je projekt dodán nebo restartován.

AS – IS BI Solution Architecture

Zpracuje: BI Analyst
Schvaluje: BI Solution Architect
Účel: Popis AS-IS stavu, v ideálně světě lze vyčíst z dokumentací, či dřívějších projektů. Typicky jde o fyzický datový model, ETL model (DFD), Manual inputs definition, případně další informace, které umožní formální implentaci (standardizaci) prototypu.
Když chybí: Nové BI řešení nebude reflektovat současný stav – špatný odhad pracností, nepodaří se odstranit původní řešení, nové řešení bude odmítnuto a skončí v propadlišti dějin. AS-IS analýza je výstup, který zajistí, že zadání projektu (které často padá shora), bude dávat smysl i na té nejnižší úrovni. Pokud je řešení nové, o to více je tato fáze nutná (někdo musí posbírat všechny excely apod.).

Functional or Non-Functional Prototype

Zpracuje: BI Analyst
Schvaluje: Business stakeholders
Účel: Co nejrychleji (a nejlevněji) vytvořit prototyp, který dokáže zpracovat vstupní data na požadované výstupy, které by mohly stakeholdeři akceptovat. Ideálně je možné tento prototyp dělat na nějakém pískovišti v produkčním prostředí.
Když chybí: Rozejde se pohled stakeholderů, architektury a vývojářů (rozebráno zde – požadavky na analytickou fázi). Nízká angažovanost stakeholderů během analýzy, píše se mnoho psaného textu, předávka vývojářům bude složitá a někdy i emotivní, vývoj a UATy se značně protáhnou.

Target BI Solution Architecture (Solution Design)

Zpracuje: BI Analyst
Schvaluje: BI Solution Architect
Účel: Popsat cílovou architekturu BI řešení. Typicky jde o fyzický datový model, ETL model (DFD), Manual inputs definition, případně další informace, které umožní formální implentaci (standardizaci) prototypu.
Když chybí: Dodané řešení bude black box a vznikne silná závislost na dodavateli. Sepsání dokumentace bude tak drahé, že se neuskuteční (nebo spíše odflákne). Příští as-is analýza se prodraží (analytik bude muset dělat reverse engineering od nuly).

Standardized BI Solution

Zpracuje: BI Developer
Schvaluje:  BI Analyst + QA + Stakeholders
Účel: Zajistit provozovatelnost prototypu -> tzn. splnit formální (technické) požadavky BI řešení (Historizace dat, datový slovník, logování, začlenění do ETL scheduleru, kvalita kódu, kompletace metadat). BI oddělení má zpravidla nějakou metodiku nebo standard, který potřeba splnit. Tento artefakt je finální BI dodávka, která bude sloužit stakeholderům.
Když chybí: Projekt nedodá klíčový výstup a skončí failem. Jedinou vyjímkou je stav, kdy se skončí prototypem (sponzor a stakeholdeři dojdou k závěru, že řešení nechtějí standardizovat, typicky v situacích, kdy se neustále mění zadání)

Documentation

Zpracuje: BI Analyst
Schvaluje: QA + Stakeholders
Účel: Potvrdit aktuálnost Target BI Solution Architecture (Solution Design) a případně rozkopírovat jeho části na místa dle zvyklostí zákazníka.
Když chybí: Target architektura (pokud byla nadefinována) zůstane zapomenuta v nějaké projektové složce a bude aktualizována až s dalším projektem (za předpokladu, že PMs fungují dobře a s novým projektem tu složku dohledají).

iBI – Pilíř I. – Středobodem všeho je dodávaný produkt!

V minulém díle jsem shrnul motivaci a naznačil směr, kterým se tento seriál vydá. Pro pochopení konkrétních postupů a nástrojů teď budou následovat články, které patří do kapitoly Základní pilíře incremental BI – právě tyto pilíře jsou návodem k ohnutí iBI do prostředí zákazníka.

Nikdy, ale opravdu nikdy nikam nechoďte s tím, že jste snědli moudrost světa (i když jste po škole, ale speciálně ne, když už máte 15let praxe). Moudrost světa sníst nelze, lze se pouze zahledět do sebe. Proto je zásadní vždy dostat Váš postup práce do souladu s postupem práce Vašeho zákazníka! A zákazníkem se rozumí architekti, provoz, vývojový framework a procesy, ale také business zákazník jako takový. A aby propojení Vašich a zákazníkových best-practices bylo efektivní je dobré vědět, na jakých myšlenkách Vaše nástroje a postupy stojí – protože pokud je tady zásadní rozdíl, může se stát, že budete vzájemně nekompatibilní. A to je dobré zjistit už na začátku :).

Jak říká Zdeněk Pohlreich, nemůžete se zavděčit všem. Důležité je dodávat nadstandardní přidanou hodnotu Vaší cílové skupině. Pro iBI jí jsou takové firmy (případně týmy ve velkých korporacích), které stojí na podobných pilířích. Pojďme na to!

Pilíř I – Středobodem všeho je dodávaný produkt.

Při každém kroku v projektu musí být zřejmý vztah k produktu, který se vyvíjí/rozvíjí. Konkrétně to znamená dělat jen tu práci, která přímo utváří produkt. Typický projev tohoto směřování je rozhodnutí – budu se věnovat analýze nebo prototypu? Není to černobílé a může to vypadat asi takhle.

Zákazník: Cílem aktivity je sebrat data o fakturách a vyhodnotit obraty směrem k jednotlivým dodavatelům napříč celou firmou.

Dodavatel: Rozumím, aktivita má dvě části. Nejprve upravit backend tak, aby obsahoval data o fakturách a následně rozšířit frontend (report portal) o report obratu dodavatelů?

Architekt: Ano, nejprve musíte sepsat analýzu zdrojových dat (dodám šablonu) a následně design řešení (dodám metodiku). Po schválení analytické fáze začnete vyvíjet řešení.

Dodavatel: Chápu, mé řešení musí být v souladu s architekturou celého reportingu a datového skladu. Pojďme oddělit akceptaci zákazníkem a IT architekturou. Nejprve se zákazníkem sestavím prototyp (dohodneme na separátní schůzce) a následně s Architektem nad prototypem odladíme design standardizovaného řešení. Díky zkušenosti s prototypem dokážu mnohem lépe navrhnout správný design, co na to říkáte? Prototyp backendu i frontendu bude kombinací SQL a Excelu.

Požadavky na analytickou fázi
Architektura Zákazník Vývojář
Sestavení solution designu.
Potvrzení souladu
s celkovou datovou
a BI Architekturou.
Ověření, že zadání vede
k očekávané přidané hodnotě.
Vytvoření detailního zadání.
Dopadová analýza

K čemu došlo? Očekávání od analytické fázi jsou rozdílná, viz tabulka.
 
 
Pravidla vývoje BI řešení zpravidla nastavuje nějaké BI oddělení. Proto jsou akcentovány jeho požadavky. A tak typické schéma pro BI dodávku vypadá takto: High-level analýza (koncept řešení) -> solution design -> detailní analýza -> vývoj -> testy (na ně, ale není čas) a reklamace -> nasazení -> reklamace. Toto je happy flow. (opravdu, ale opravdu je tam reklamace vždy (i když se všichni tváří znovu a znovu překvapeně))

Dokáže zákazník vyčíst nějakou garanci, že projekt povede k očekávané přidané hodnotě ze solution designu a detailní analýzy? Dokáže někdo napsat detailní analýzu tak, aby ji vývojář vstřebal z wordu? Zkušenosti říkají, že se to nějak zvládne, ale skřípe to. Skřípe to čím dál tím více, čím je to blíže tomuhle extrému.

Inkrementální BI říká, že celá analytická fáze má být obsažena v prototypu. Prototyp totiž poslouží všem.

Zákazník si na něm dobře ověří jeho přidanou hodnotu.
Architekt vidí solution design v praxi a může ho velmi levně měnit. Prototyp totiž bude v rámci standardního vývoje stejně přepsán.
Vývojář dostává skvělé detailní zadání formou dat a kódu. Tomu bude vývojář vždy rozumět více než 50ti stránkovému elaborátu.

 

Proto dodavatel v rozhovoru výše tlačí na prototyp a upozaďuje klasické wordové matariály. Tento dodavatel totiž ví, že prototypem staví produkt. Zatímco dokumentem s dokumentem ve wordu to tak jednoznačné není.

Když dáte vývojáři detailní analýzu, jeho první krok je, že si jde všechno ověřit do dat (jednotky MDs). Pokud mu dáte prototyp, tento krok už má hotový. Samotný prototyp má pak své best-practice – psaní maxima komentářů, modelování, popisování algoritmů apod. Je dobré si toto předem potvrdit.

Požadavky zákazníka


Jak zachytit požadavky zákazníka v souladu s tímhle pilířem? Produkt je kód. Takže odrážky ve wordu to nebudou (i když lepší než nic). Jaký kód by to mohl být? V IT na to existují celé oddělení a v BI se to de facto neprovozuje, co to je? Ano, TESTY! Představte si, že jste schopní neustále prokazatelně vyhodnocovat kolik požadavků již je splněno a kolik jich ještě zbývá. Jsou-li testy dobře navržené – zvládnou pokrýt až 80% nálezů a to bez pálení zdrojů zákazníka. V ideálním světě by to bylo 100%, ale Paretovo pravidlo má smysl i zde.

Je dobré na těch prvních spolupracovat s IT testerem (specializované BI testery zatím neseženete), který zná vámi používané technologie. Tyhle testy dokáží významně zlepšit vztahy s vaším interním zákazníkem – je z nich totiž zřejmý rozdíl mezi dobře zadaným a rozmyšleným projektem a těmi ostatními. Pokud váš tester(s podporou senior analytika) řekne, že zvládl do testů přepsat pouze 20% požadavků, je zadání vágní. To není nutně špatně, v případě, kdy nastavujete například úplně novou alokaci nákladů to prostě nejde zadefinovat na více než pár desítek procent. Na konci téhle aktivity ale bude celému projektů jasné, jak si má nastavit buffery a kolikrát se změní zadání prototypu. Dokonce to pro Vás bude silný impuls a argument, že prototyp uděláte jako funkční a nasadíte na produkci a zastandardizujete do DWH až po odladění. Toto rozhodnutí šetří miliony!

Vedlejší efekty

Jak poznáte, že jste tento pilíř implementovali do svého stylu práce? Navrhuji sledovat Vaše chování v následujících situacích.

Situace: Zákazník tlačí, abyste v rámci dodávky reportu tržeb rozšířili i metodiku reportingu.

Jak tady pomůže pilíř, že středobodem všeho je produkt? Vaším dodávaným produktem je přeci report. Souvislost produktu report s produktem reportingová metodika je nepřímá. Dokud máte tento pilíř na zřeteli, je Vám jasné, že zákazník od vás chce nový produkt, nikoliv změnu stávajícího. Tzn. Nejdřív udělám report a teprve potom rozšířím metodiku, je to Vás ok? Budu to fakturovat jako dva produkty. Ano, pokud je středobodem všeho produkt měli timesheetovat alespoň v granularitě produkt. (v rámci projektu zpravidla dodáte víc produktů).

Situace: Zákazník po mě chce status, kde mám říct, jak pokročily práce na produktu.

Co je středobodem vaší komunikace? Produkt. Jak ale na statusu ukázat produkt – z toho kódu přeci nikdo nic nepochopí? Podobné otázky si musíte průběžně ujasňovat, jedna věc je totiž jistá – informace, že jste spálili 4MD z 8MD o produktu vůbec nehovoří, vůbec! V ideálním světě máte unit testy, seznam požadavků, počet objektů (a jejich složitost) v produktu a mnoho dalšího co stav prací na produktu vyjádří lépe. A ano, přípravě na status byste měli věnovat nějaký čas (třeba spuštění unit testů :), což je méně než 1 minuta). A že jste ještě v DWH neviděli unit testy? Tak čtěte další díly!


Changelog
26.4.2017 – přidána kapitola Požadavky zákazníka

Incremental BI – úvod

Je to nějaký pátek, kdy jsem jako studující pracující poprvé začal vnímat projektovou realitu v Business Intelligence. Tou dobou jsem nechápal, proč nám na škole důležitě vyprávějí o analýzách, metodikách, inkrementálních přírůstcích, projektovém trojúhelníku apod. Vždyť je to jasné – než něco udělám, tak si to rozmyslím a naplánuji, lehké. Realita byla šok.

Šok č.0

Žádná firma neřídí své projekty v souladu s informacemi ze školy (mluvím o firmách, které mají často velká IT i projektová oddělení). Vždy je tisíce vlivů, které to znemožní – nákupní oddělení, sponzor projektu, protichůdné požadavky na projekty, mylné projektové předpoklady, nezkušenost / neznalost lidí na projektu a mnoho dalšího.

Šok č.1

Většina lidí ve firmách se nevyzná v IT a netuší základní zákonitosti oboru. Občas člověk musí vyvracet neskutečné mýty, ale je to je zcela v pořádku. Naopak se tito lidé vyznají v obchodu, ve financích, marketingu a jiných důležitých oblastech (od nich se zase učím já). Občas se vyskytnou tací, kteří rozumí více těmto oblastem najednou – s těmi je pak radost pracovat, ale zase zpravidla nemají čas.

Šok č.2

Tato většina často poptává BI řešení a celkem logicky dávají najevo své překvapení – „musí to být dříve, musí to být levnější, vypadá to jinak, než jsem chtěl, jak je možné, že po roce práce jste nic nedodali? Nebo je to smířlivější – dobře, do konce příštího roku už to bude! Rozumím, bude to stát 2x tolik, chápu, užitná hodnota bude výrazně nižší, ale zase to stihnete v termínu.“

Těmto hlasům pak většina z BI nebo IT světa vrací úder stejně chápavým tónem – „To nejde, nejdříve sepište přesné zadání, musí se udělat analýza, musí to schválit vedení, to je změnový požadavek, nerozumím tomu, co chcete, ale ok, dejte mi peníze a já to udělám (případně z vás vytáhnu časem další peníze a až pak to dodělám).“

Tohle je realita 75% projektů, o které jsem se za 5 let otřel. Tyto projekty nakonec stály cca 2x tolik, než kolik se čekalo a výsledný scope se často lišil od původního. Michodem i délka trvání byla většinou krát dva. Pro neznalé, nic moc, přesto to považuji za úspěch, všechny tyto projekty nakonec byly zákazníkem akceptovány a zažili produkční provoz!  Během této doby jsem dával dohromady postup, který by dokázal spojit informace ze školy a běžnou praxi. Hlavní inspirací mi byly seniorní kolegové, metodiky, knihy, vlastní praxe a v poslední době různá oborová setkání, kdo můžete, určitě navštivte micrososft SQL Saturday – přednášky a lidé z těchto akcí mě posunuly o mílové kroky.

Mé zkušenosti a postupy shrnu pod články s tagem Inkremental BI (IBI). Cílem bylo vybrat takové pojmenování, které bude mít neutrální nádech. Protože Watterfall = pomalé, drahé, těžkopádné, ale jsme na něj zvyklí. Protože Agile = chaos a většinou především výmluva pro nepsání dokumentace a shit delivery obecně. Protože PRINCE 2 – projektová metodika, kvůli které musíte vyplňovat tunu dokumentů apod. Jde o to ukázat, co mě funguje, co se mi osvědčilo. A určitě se to bude vyvíjet až do mého BI důchodu, to slibuji!