Správa požadavků

Usilovně jsem hledal a vyzvídal, jak taková agenda funguje (viz též anketa na LinkedIn). Jediné, co jsem (od školitele TOGAF-u) reálně viděl, byla naprosto nesmyslná tabulka v Excel-u, obsahující rádoby strukturovaně formulované...
...požadavky na software (navíc trapně triviální, bez sebemenší stopy po analýze potřeb). Některé interpretace (např. TOGAF na české Wikipedii) tvrdí, že správa požadavků je "fáze" a "poskytuje rámec..." Vážně to vypadá, že "správa požadavků" je "pustá teorie". Jenže bez ní budeme pořád jen zoufale improvizovat.

Podstatné - různé typy požadavků se od sebe většinou celkem výrazně liší. Často mají ledacos velmi podobného a nejspíš princip jejich vyřizování se zásadně neliší (viz později). Především dává smysl pokusit se je vyřizovat stejným (byť uvnitř rozvětveným) procesem a v jednom prostředí. Podle zkušeností to společné převažuje.

• Podnikové požadavky (enterprise requirements) - to jsou ty, které determinují činnosti popisované ADM. Jedná se o vrcholové požadavky (na strategické úrovni | procesního charakteru), ze kterých se odvozuje rámcová funkčnost informačních systémů (jaké systémy jsou potřeba - příklad - požadavek "Lepší péče o zákazníky" = analýza možností, která může vést k pořízení CRM-systému, viz později).
• Požadavky na software - funkční a nefunkční (samostatně). Ty funguji v rámci řízení vývoje systému jako součást zadání a testování (viz např. správa požadavků v DevOps)
• Požadavky na produkt (product management | product development | marketing).
• Požadavky zákazníků (CRM).
• Požadavky na podporu (např. v helpdesku) a desítky jiných typů požadavků.

Zkušenosti z praxe

V jedné velké firmě jsme spolupracovali na budování projektové kanceláře. Při té příležitosti jsme se dostali ke správě podnětů, tvorbě specifikací a fungování akceptací. 

• Po jisté době se nám podařilo vysvětlit, že se jedná o jediný konzistentní systém (zahrnující byť v minimalistické podobě i procesní model - viz schéma). Mimo jiné proto, že veškeré záměry je nutno vnímat a řídit v jejich vzájemných souvislostech - bez ohledu na to, jestli se teprve připravují, realizují nebo už využívají.
• Při analýze (nejen) IT projektů jsme se shodli, že firma má velké rezervy (příležitosti ke zlepšení) v oblasti analýzy potřeb a správy požadavků. Chvíli trvalo, než jsme se dohodli, že rozhodně není účelné zavádět jakékoli byrokratické formality (obecná verze TOGAF-u), ale dává smysl soustředit se na relevantní doporučení. Třeba architecture repository. Takže dle situace by bylo dobré pokusit se něco takového zavést.
• Využili jsme již dříve nasazený procesní model a rozšířili správu podnětů na systém pro správu požadavků a řízení analýzy potřeb (samostatně). Bylo to po malých krůčcích., ale podařilo se (částečně díky tomu, že byly společné zkušenosti s využitím procesního přístupu a automatizace) všechny tři oblasti (procesy, požadavky & podněty, projekty) propojit a poměrně slušně vybavit workflow.
• Přitom jsme zjistili, že bezprostřední a konkrétní (přinášející pro danou organizaci aktuálně srozumitelný užitek) potřeba je zpracování požadavků na jakékoli změny (v majetku) pro účely jejich finančního a organizačního zajištění. Konkrétně vzhledem k tomu, že se jedná o poněkud "tradiční" organizaci, dávají dohromady "rozpočet" na příští rok. Takže se to, co je potřeba, musí ještě "schvalovat" (každopádně porovnat s využitelnými zdroji financování).
  • Převést do plánu investic (doložit efektivnost, zajistit financování, najít termín, ...).
  • Zorganizovat nákup (oslovování, soutěž, ...).
  • Zajistit pořízení/dodávku a převzetí.

Je možná trošku sporné, co je vejce a co slepice, zatím to vypadá nadějně. Původně ten plán investic vytvářeli v Excelu. Absolutní kalamita. Další situace, která plně potvrzuje, že by se Excel měl zakázat. Jakmile potřebujete přístup více lidí k jednotlivým položkám a případně k nim shromažďovat specifické údaje, další dokumenty či záznamy, je tabulkový procesor nepoužitelný. 

Původně to vypadalo, že spojovat správu požadavků s řízením obnovy a pořízení majetku je hrozně přízemní. No, to možná je... ale je to děsně praktické. Zejména pokud nemáte hodně vyspělý systém pro správu majetku a sofistikovaný proces řízení investic.

Požadavky na systém pro správu požadavků

Jenom stručně. Více je v metodice. Považujeme tyto zkušenosti a na jejich základě vytvořené know-how za poměrně zásadní. Rozumí se požadavky na funkčnost procesu a podpory správy (nejen architektonických) požadavků (zde se zaměřením na pořízení majetku). Původně byl systém koncipován pro podnikové požadavky. Pokud chceme proces podpořit workflow, mají být v jednom systému všechny požadavky včetně  např. dílčích technických požadavků na informační systém / software nebo na pořízení nového auta. Téměř jistě i externí požadavky (zákazníků, dodavatelů, institucí a dalších partnerů).

• Kdokoli může zadat požadavek (web, mobil, popř. e-mail). Ten bude (podle svého typu adekvátně) posouzen. Zamezit duplicitám. Mechanismus by měl být jediný (komplexní, centrální) pro sběr naprosto veškerých požadavků (podnětů, návrhů, problémů, nedostatků,  omezení, neshod, ...).
• Formulace požadavku může být naprosto nekorektní - povinností správce požadavků musí být zajistit zjištění podstaty (která bezpochyby může být zcela jiná) potřeby a formulaci validních požadavků.
  Bezesporu je rozumné podporovat inteligentní rozhraní (průvodci, šablony, ...) tak, aby těch nekorektních bylo co nejméně (možná to vede k řízení "péče" o korektní chování zadavatelů).
• Musí být k dispozici šablony (dle typu požadavku - číselník typů/šablon). Nejlépe "inteligentní" (využitelné formou průvodce, kterého si může parametrizovat včetně rozšiřování uživatelsky správce daného/-ých typů požadavků).
• Současně není použití šablony povinné. Dala by se využít generativní "AI" pro analýzu případného textu zadávaného pro "netypový" požadavek, která může formulovat doplňující dotazy. Ty standardní by měly být položeny ještě před umožněním textového popisu požadavku.
• Přijetím požadavku se spouští workflow - pro věcně příslušného správce vzniká úkol (pokud je správců víc a nebyla určena oblast, musí ten, kdo zpracovává takové požadavky, jeho oblast určit, případně ve spolupráci s iniciátorem).
• Požadavek musí být posouzen. Pokud není k odpovídajícímu vyhodnocení požadavku dostatek informací, musí být možno jednoduše spustit / vyžádat analýzu potřeb. Získané údaje jsou součástí požadavku nebo jednoduše odkazují na zdroje. To stejné platí pro doklady a data z provozu stávajícího majetku (opravy, provozní náklady, poruchovost, informace o případné havárii či škodě atd.).
• Požadavky musí být možno propojovat mezi sebou i mezi již běžícími projekty.
• Typu požadavku odpovídá struktura údajů (dynamická, uživatelsky definovatelná… např. typy obsahu SharePoint, popř. virtuální struktury).
• Podle typu a obsahu se řídí i postup zpracování (co se s tím má dělat - parametrizace nebo výběr větví workflow). Např. formou uživatelské parametrizace (např. mít možnost doplňovat rozhodovací tabulky a podle zadaných údajů určovat následující činnosti či role).
• Pokud je požadavek schválen/zamítnut, může/nemusí (zaškrtávátko v zadáni a nastavení uživatele) iniciátor dostat notifikaci (ale již přijetím dostává odkaz, takže se k němu může kdykoli vrátit). Totéž platí pro sledování životního cyklu - jakmile je např. zahájena práce na realizaci…
• Po nalezení / výběru řešení daného požadavku se vybraná možnost včetně zamítnutých variant včetně zdůvodnění zaznamená.
• Součástí požadavku (na pořízení majetku) je zdroj financování a cílový čas pořízení (resp. všech informací, které časové aspekty ovlivňují - obvyklé zdržení při obstrukcích výběrového řízení, dodací lhůty dodavatelů apod.).
• Je možno označené (v příslušném stavu) návrhy seskupovat dle času, potenciálních dodavatelů atd. a tímto způsobem je transformovat do plánu investic / rozpočtu v prakticky libovolné struktuře. Pokud není možno řešit schválení / úpravy přímo v rámci systému, zpětně importovat/aktualizovat projednaný návrh (schválené a zamítnuté položky).
• Podpořit pořízení (organizaci výběru dodavatele a případně řízení dodávky). Celý životní cyklus požadavku, možná až do využití nově pořízeného majetku v provozu.

Sporné / problémy

• Je rozumné mít na jednom místě požadavky na nákup nového traktoru a vybudování nového systému strategického řízení?
• Jsou požadavky současně "náměty" - "záměry" & případně projekty?
• Pořadí/priorita + lhůta jsou podmínkou pro "seřazení". Jak správně definovat prioitu? Jakou roli v tom může mít řízení rizik.
• Kde jsou "úkoly" - měly by být někde jinde. Některé budou MBO, některé "jednoduché".

Nechcete si promluvit o tom, jestli by i ve vaší organizaci nebyl užitečný systém správy požadavků? Nic nevnucujeme. Pokud již máte M365, tak je to jedna z oblastí, která pravděpodobně nevyžaduje komplexní změny. Může je následně vyvolat, ale mohl by to být nutný minimalistický začátek.