V předchozím dílu nekonečné Spotify série jsme si ukázali spoustu kroků, jak je možné začít budovat agilní firmu bez toho, aniž byste ji museli celou překopat do tribů a squadů. Nyní se blíže podíváme na jednu ze zmíněných oblastí, která může významně pomoci zlepšit existující projekty a produkty a nasměrovat firmu k agilitě. Touto oblastí je proces sběru požadavků na (nejen IT) projekty a produkty napříč firmou, často nazývaný Demand management proces.
Tradiční proces sběru požadavků na straně byznysu probíhá zjednodušeně řečeno tak, že se jednostranně ptáme zástupců jednotlivých oddělení, co by potřebovali v následujícím roce a 2-3 dalších letech ke své práci a tyto vstupy se snažíme prioritizovat. Takový proces však obsahuje několik zásadních problémů, které jsou hlubokou příčinou v pozadí problémů projektů:
- Ptáme se zástupců sil/oddělení, kteří nereprezentují end-to-end proces zákazníka, který jde napříč těmito sily a jejich požadavky jsou vždy jen omezeným fragmentem celku.
- Ptáme se na požadavky, ne na reálné potřeby za nimi (takže byznys lidé vůbec nejsou zvyklí nám je říkat). Tyto potřeby lze v praxi mnohdy řešit jinými způsoby, levněji, rychleji a třeba i méně komplikovaně.
- Sepsáním požadavku do konkrétní formy už děláme realizační rozhodnutí, navíc přijaté „neznalou“ osobou příliš brzy.
- Požadavek je jednostranný příkaz, neprobíhá konstruktivní diskuze mezi zadavateli a realizátory, neřeší se alternativy. Zadavatel vystupuje z pozice moci a postoje „co vy tomu rozumíte“ a realizátor je zasazen do role toho dole, co to má přeci jen vykonat a stejně vše jen brzdí a prodlužuje.
- Ptáme se jen jednou za dlouhé období a v projektech později není prostor na změnu. Průběžně vzájemná (ne)pochopení neověřujeme, nereprioritizujeme a tak se zapomenuté věci a nevyřčené domněnky „tajně“ nabalují a pašují do projektů, jinak by ony projekty nedávaly smysl. Jo a za zpoždění vždy může IT, blbě to odhadlo (i když scope díky této nabalující se sněhové kouli narostl 3x nebo to vůbec nebyl IT projekt).
- Zapsáním požadavku snímáme ze zadavatele odpovědnost za výsledek. Vždyť už řekl, jak to chce a vymyslet, aby to byznysově fungovalo s ostatními procesy a omezeními, zjistit odkud vzít data, domyslet veškeré chování, ošetřit výjimečné stavy, tento zbytek je už přece pouhá realizace.
- Neověřujeme a neměříme, zda bylo projektem dosaženo to, co záměr sliboval. Velmi často je tento stav žádoucí, protože se projekt ke slibovanému dopadu ani nepřiblížil a nikdo to nechce říct, nikdo nechce převzít odpovědnost, protože by byl potrestán (ano, trestání opravdu není agilní kultura). Vlastně příčina je vždy stejná, ukáže se na blbé a pomalé IT.
Tyto příčiny neúspěšných projektů bývají ještě násobeny délkou a velikostí projektů. Čím je delší doba implementace projektu, tím je větší rozpor mezi stavem trhu, skutečnými potřebami a tím, co produkt umí a podporuje na základě dříve sepsaných domnělých požadavků. Nemluvě o tom, že dlouhý projekt plný méně potřebných funkcí, oddaluje doručení skutečné hodnoty (to, proč děláme tento projekt), která už může firmě něco přinášet.
Proces vs. nekvalitní vstupy
Snaha optimalizovat a zlepšovat proces realizace projektů, když máme na vstupu balast je snaha, slušně řečeno, podivná a hloupá. Přesto ji denně ve firmách řeší spousta lidí a očekávají změny a zlepšení, která prostě přijít nemohou. Z plesnivých odpadků (vstup) prostě Michelinské menu neuvaříte, i když máte skvělou linku a kuchaře (proces). Tím jsem se samozřejmě nechtěl dotknout byznysových lidí, kteří své požadavky sdělují. Určitě si nemyslím, že jejich mysli plodí plesnivé odpadky (požadavky). Problém nejsou oni, ale celý proces, jak tyto požadavky (málem bych napsal odpadky) zjišťujeme a sbíráme, respektive příčiny těchto problémů uvedené v seznamu výše.
Z plesnivých odpadků prostě Michelinské menu neuvaříte, i když máte skvělou linku a kuchaře.
Proto už jen změnou Demand Management procesu můžete dosáhnout úspěšnějších projektů a tím byznysových zlepšení i beze změn na straně procesu vývoje, realizace a vedení projektů! Není to nádhera? K tomu potřebnou věcí je však pokora, přijetí odpovědnosti na všech stranách a pojmenování věcí správnými jmény.
Požadavek, ale i byznys potřeba jsou falešné a zavádějící pojmy
Firmy běžně prospívají a byznys jim šlape, proto je třeba si uvědomit, že byznys požadavek je pouze PŘEDSTAVOU, jak a čím by šel náš byznys dále zlepšit. Vždyť firmě byznys funguje už nyní i bez tohoto požadavku. Navíc je to pouhý odhad na základě zkušenosti, který může ale nemusí vyjít.
Pokud jde o novou část podnikání, pak je to už jen pouhá DOMNĚNKA. Myslíme si, že by to tak mohlo být, ale nemáme to zatím ověřené a nemám k tomu žádné data ani zkušenosti. No a jak skutečně ověřit něco, co neexistuje? Buď tím, že danou věc zkusím v malém udělat nebo i tak, že se budu tvářit, že ji mám ;). Obojí je experiment, jakási první verze ověřující naše domněnky, reakce a zájem trhu a uživatelů.
Bohužel ne vždy toto myšlení máme, nepřiznáme si, že nové požadavky jsou jen domněnky a představy, které je nutné ověřit a tváříme se, že jde o jasnou věc. Směrem k IT tyto naše požadavky navíc stavíme jako nutnou podmínku fungování byznysu, který, a to znovu zopakuji, nyní funguje i bez toho požadavku.
Stavíme naše domněnky (rozuměj požadavky) jako nutnou a nezbytnou věc, ale byznys bez nich nyní v poklidu funguje.
Tyto domněnky, které tlačíme IT jako nutnou povinnost (požaduji od vás tento požadavek) pak ani neměříme, takže ani nevíme, zda tato domněnka byla pravdivá a jaký je přínos této realizace. Tato realita (požadavek s nejasnou či často s nulovou byznys hodnotou) nám ale neodebírá chuť kritizovat IT za to, že něco nedodalo nebo dodalo špatně či pozdě.
Takže znovu, požadavky jsou spíše nápady, které pomohou lépe/více naplnit ultimátní vizi firmy: větší zisk, naplněna mise neziskovky apod.
Zkušenost z praxe je taková, ze hodně požadavků má přibližně stejný přínos jako je náklad potřebný na jejich realizaci (takže se moc nevyplatí) nebo dokonce pracnost a náklad nutný k realizaci o dost víc převyšuje byznysový přínos řešení. Možná proto nikdo nechce přínos poté měřit a firmy to ani nedělají. Ne každý se chce podívat do zrcadla a přiznat si chyby. Dělají to tak přece všichni a my musíme nějak naše lidi dělat zaneprázdněné, ne?
Praxe vs. naše domněnky
Výzkumy, měření a empirie nám navíc říkají, že potřebných a v praxi používaných je asi jen 20-60% funkcí v daném produktu (podle typu byznysu, kontextu produktu apod.), zbytek jen prodlužuje realizaci a zesložiťuje používání uživatelům. My ale máme pořád jakousi obsesi, že více je více a chrlíme tuny nepotřebných funkcí.
Srovnejte oblíbené a používané produkty jako je Waze, Basecamp, Slack, Google Apps například s podobnými produkty od Microsoftu (Teams, Office 365) nebo nedej bože od SAPu. Jak se vám používají ty první a jak ty druhé? Jen taková blbost jako je přejmenování souboru zabere v O365 několik kroků a klikání oproti Google Apps. První jmenované produkty mají minimum klíčových funkcí a jsou zaměřeny na uživatele.
Říct, potřebujeme tyto funkce, proto nás uživatelé nepoužívají, je nepravda a lhaní si do kapsy (pokud to teda nejsou ty 2-3 klíčové ;)). Dokonce i důkaz, jímž jsou lidé tvrdící, že nás začnou používat jakmile tam bude to a ono, je zavádějící. Jak víme, že nebudou pokračovat stejně s dalším listem 100 položek? Jak víme, že to není jen výmluva, protože nás nechtěli ranit a říct napřímo, že naše aplikace je sračka a stejně ji nikdy používat nebudou?
Jak tedy Demand management proces upravit?
Úplně prvním krokem je přestat říkat „požadavky“ a „požadujeme“ a házet je přes zeď IT, ale zadávat chtěné, očekávané byznys cíle a přínosy. Takže nezadáváte požadavky, ale byznys cíle, což vtahuje do denního použití vizi a strategii firmy, vůči nim tyto cíle validujete, respektive tyto cíle by měly vizi naplňovat a strategii (ono „jak“) následovat. Takže místo uzavřeného požadavku obsahujícího řešení:
„přidat uživatelům možnost množstevních operací“
začneme s:
„rádi bychom zefektivnili proces objednávání, protože podle nás může interně uspořit XX a vynést XX za nyní čekající objednávky, což je jeden z bodů naší aktuální strategie“.
Dost velký rozdíl? Co říkáte?
Druhým krokem je pak společná diskuze nad těmito prvotními nápady a byznys cíli (dříve reprezentovanými požadavky) se snahou identifikovat možná řešení, která by měla tento byznys přínos a navrhnout a uskutečnit možné experimenty, které naše domněnky vyvrátí nebo potvrdí. Vhodné je použít například Impact Mapping, který nás rozpadem provede nebo i doplnit o nástroje Blue Ocean.
A nebojte se, vůbec to váš Demand Management proces nezpomalí o měsíce experimentování, naopak vypadne obrovské množství hluchých požadavků bez hodnotya se stejnými kapacitami stihnete hodnotnější věci, budete dříve doručovat menší, ale přínosné části, produkty budou jednodušší, uživatelé je budou více používat a budou spokojenější. Samé světlé zítřky a sociální jistoty, co? Nebojte se, ono to není zadarmo 😉 tuto dovednost se musíte naučit a trvá to roky, ale proč nezačít hned aspoň některým z těchto kroků:
- pozorujte uživatele/zákazníky při práci a mapujte potřeby firmy (využijte např. impact mapping), ptejte se na potřeby, když vám budou tlačeny požadavky „musíš udělat toto v přesné formě“ (tento přístup se musí naučit IT), ptejte se: proč přesně toto potřebujete? Můžeme se přijít podívat, jak s tím pracujete nyní? Co se stane, když to nebudete mít?
- zkraťte cyklus ptaní se na potřeby z frekvence jednou ročně na minimálně čtvrtletně či dokonce měsíčně a umožněte průběžné změny a zapojte zadavatele do zpětné vazby,
- zmenšete a zkraťte projekty, to už samo o sobě nutí realizovat jen core potřeby a každý projekt lze rozfázovat,
- vyžadujte value/effort analýzu například formou A3 (nástroj Leanu),
- garantujte budget jen potřebám ověřeným experimentem (s výjimkou legálních, regulačních, či security),
- zapojte zadavatele a budoucí uživatele do pravidelných demonstrací prvotních výstupů a naučte je dávat feedback (musí chtít byznys, místo tradičního: “nemáme na diskuze čas” a “co jste nám to dodali?!”),
- společně se shodněte (byznys s IT) na akceptačních kritériích a nechejte byznys, aby je zachytil formou spustitelných testů (případně nějakých popisných scénářů) – toto je nejlepší možná forma požadavku, je spustitelný, hned ověřuje funkci a máme pouze 1 artefakt – test,
- umožněte uskutečnění experimentů pro ověření našich idejí (implicitní ano, jako to má nastavené například Amazon, proti typickému NE na vše, jako je to běžné ve většině firem),
- nasazujte v omezené míře do beta pilotu prvotní verze a reagujte na zjištěné dopady, problémy, vazby a feedback od uživatelů (musí se naučit IT, musí umožňovat infrastruktura, musí se zapojit byznys a pochopit smysl, nejde vždy a všude),
- zpětně měřte a průběžně vyhodnocujte slibované dopadya podle toho upravujte backlogy projektů a produktů, dedikaci budgetů, proces sběru potřeb, ověřování, value/effort model a schvalování.
Nejtěžším, ale zato nejvíce přínosným krokem, je tedy zadávat, měřit projekty a postavit produktové roadmapy směrem k byznys cílům (co chce firma dosáhnout), místo tradiční metriky „všechny požadavky implementovány“ a požadavky z potřeb průběžně s týmem dotvářet podle výsledků neustálých experimentů. Pyšnit se implementovanými požadavky je to stejné jako byste na konci projektu řekli „peníze jsme úspěšně všechny utratili“, ale uznejte, to neříká nic o tom, zda byla doručena nějaká hodnota.
Máte k tomu co říct?