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





Leave a Comment

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *