Nejprve si připomeňme schéma, které znázorňuje čtyři základní přístupy k řízení projektů (viz obrázek 1). 

Obr. 1: Základní přístupy k řízení rozsahu projektů

Přístup 3: Kooperace a sdílení

Jsme-li postaveni před úkol řídit rozsah projektu v rámci relativně jednoduchého projektu, nicméně s celou řadou zainteresovaných osob, musíme se zaměřit zejména na otázku komunikace a sdílení informací. V takovém případě pro nás bude klíčové podpořit sledování změn, schvalovací proces a verzování. Zkrátka v tomto případě MS Word s tolik oblíbenými revizemi a komentáři neuhlídáme a neuřídíme. Nicméně – stále nezapomínejme na to, že musíme držet rozsah projektu pohromadě jako celek. Uvědomme si, že na rozdíl od první situace (kdy jsme se zaměřili na jednoduchost a efektivitu) máme pouze více zainteresovaných osob, ale složitost projektu je stále nízká. A tak pouze vybereme vhodnější nástroj, ale způsob a struktura zpracování požadavků může (a měla by) zůstat velmi podobná zmíněné první variantě.

Požadavky

Pro požadavky je tedy vhodné zvolit nějakou platformu, která nabízí snadné sdílení obsahu a pomůže s řízením komentářů a připomínek. Ze zkušenosti mohu doporučit například Confluence Wiki s pluginem Talk. Wiki zajistí snadnou tvorbu obsahu, jeho verzování a sdílení. Talk pak umožňuje vkládat komentáře přímo do textu, podobně jako to umí MS Word (takže pro běžné zúčastněné osoby z řad businessu není problém toto řešení efektivně používat). Variantně, pokud se rozhodneme pro výraznější používání modelu (jakkoli to není v tomto případě nezbytně nutné), existují modelovací nástroje se silnou podporou právě ve fázi schvalování a připomínkování (například nástroj CaseComplete).

Ať už zvolíme libovolný nástroj, stejně jako ve všech ostatních případech platí, že musíme mít na jednom místě vymezen celý rozsah projektu (na high-level úrovni), vůči kterému pak posuzujeme každý jednotlivý požadavek, zda je či není součástí dodávky.

Řízení požadavků

Z pohledu procesu řízení požadavků je vhodné zavést sledování stavu připomínkování a schvalování jednotlivých dokumentů či požadavků (dle zvoleného přístupu). Vzhledem k tomu, že do projektu vstupuje celá řada zainteresovaných osob, , je to poměrně kritická aktivita pro minimalizaci rizika pozdějších změn. V tomto případě můžeme možná vystačit ještě s Excelem, nicméně nejspíš nám bude chybět snadná možnost nějakého sdílení. Pokud jsme se vydali cestou wiki, není nic snazšího, než takový Excel uveřejnit právě tam, popřípadě vytvořit tabulku monitorující stav přímo prostředky wiki.

Neméně důležitou radou je mít jasně definovanou komunikační matici, zejména pak jednoznačně identifikovat osoby oprávněné vznášet požadavky. Předejde se tak nepříjemné situaci, kdy se v pozdní fázi projektu objeví s novým požadavkem osoba, se kterou jsme do té doby o požadavcích nekomunikovali. Rozhodně nám také pomůže mít předem nadefinované eskalační procedury, neboť při vysokém počtu zainteresovaných subjektů výrazně stoupá pravděpodobnost vzniku protichůdných požadavků.

Agilita

Jak se postavit k agilním přístupům v tomto případě? Agilní postupy nám rozhodně bude komplikovat vysoký počet zainteresovaných osob, o to víc, budou-li fyzicky v různých geografických lokalitách a navíc v různých časových pásmech. Nicméně přesto považuji za možné agilní přístup aplikovat. Je však nezbytné jasně vymezit komunikační strategii a nastavit jednoznačné odpovědnosti, abychom předešli situacím, kdy máme agilně vyvinuto, ale jiná skupina zainteresovaných osob začne výsledek rozporovat (viz také odstavec výše). Situaci nám může částečně vylepšit i to, pokud se nám podaří část aktivit zadavatelské role přesunout dovnitř dodavatelského týmu, což významně usnadní komunikaci a tím pádem i umožní rozsáhlejší aplikaci agilních metod a technik.

Pokud se tedy dostáváme s relativně jednoduchým projektem do prostředí s mnoha zainteresovanými osobami, mějme na paměti primárně komunikaci, sdílení a jasné odpovědnosti. Pokusme se vymanit z nekonečného kolotoče konsolidace a vypořádávání wordových komentářů a využijme vhodnější technickou platformu.

Přístup 4: Komplexní přístup

Největší výzvou (nejen) z pohledu řízení požadavků a rozsahu projektu je situace, kdy na jedné straně máte řešit složitý projekt a na straně druhé jste konfrontováni s celou řadou zainteresovaných osob. Toto je kategorie projektů, které se nezřídka dostávají do statistik zmíněných v úvodním článku (v IT Systems 3/2017) – bývají to projekty, které často nedopadnou úspěšně zejména z důvodu neuřízení rozsahu projektu a nezvládnutých požadavků.

O úspěchu či neúspěchu v oblasti řízení požadavků rozhoduje celá řada faktorů. Primárně je to samotná vyspělost dodavatele i odběratele, pečlivost při zpracování požadavků i při jejich revizi a schvalování, důsledné dodržování a sledování celého životního cyklu požadavku a změnového řízení atd. Na projektech takového charakteru většinou nikoho nenapadne jít jinou cestou než důslednou a precizní správou na úrovni jednotlivých požadavků, což je určitě dobrá zpráva.

Špatnou zprávou je, že v důsledku soustředění se na jednotlivé požadavky často uniká celkový obrázek. Jednotlivé požadavky jsou sice mezi sebou provázány, ale to nestačí. Nesmí chybět ucelený výstup vymezující (jak pozitivně, tak negativně) úplný rozsah dodávky, resp. jeho hranice či mantinely. Je jasné, že takový výstup nebude obsahovat úplný detail, ale to v úvodní fázi projektu, kdy by takový popis měl vznikat, není potřeba. Vůči této definici se pak posuzuje každý jednotlivý požadavek, zda má či nemá být (a případně v jaké podobě) součástí projektu.

Jinými slovy – zatímco jsem v úvodním dílu seriálu zmínil, že pro zjednodušení budu v tomto textu chápat pojem „požadavek“ v jeho nejširším významu dle BABOK Guide, na takto složitých projektech považuji téměř za nezbytné podívat se na jednotlivé úrovně požadavků zvlášť a zvážit, jak se k té které úrovni postavit (jinak budeme pracovat s Business Requirements, jinak se Stakeholder Requirements, jinak se Solution a Transformation Requirements).

Jak se tedy v takto komplexní situaci postavit k řízení požadavků? Popis vhodného přístupu by vydal na nejeden samostatný článek a v zásadě každá lepší kniha o řízení požadavků se touto problematikou do detailu zabývá. Zkusme se tedy zaměřit jen na možnou systémovou podporu.

Požadavky

Pro samotné požadavky platí to samé, co jsme zmiňovali v předchozí variantě. Základními hesly jsou sdílení, sledování, správa verzí, schvalování a hlavně modelování. Úskalí nastává, když potřebujeme vybrané výstupy z modelu nasdílet, připomínkovat a schvalovat. Záleží na tom, v čem projektová složitost spočívá. Nicméně pokud se jedná opravdu o nejkomplexnější situaci (projekt je složitý jak z pohledu business procesů, business pravidel i integrace), nejsem si jistý, že nějaký jeden vhodný integrovaný nástroj existuje. Jako vyhovující (ne však moc pohodlnou) kombinaci nástrojů lze využít Enterprise Architect (EA) doplněný o wiki. Case nástroj poskytne silné nástroje pro tvorbu a údržbu provázaného modelu, wiki pak již zmiňované publikování, sdílení a podporu připomínkování. Bohužel nějaký snadný recept na integraci obsahu EA na wiki, pokud vím, neexistuje. K dispozici je sice řada rozšíření EA (pro integraci s JIRA, pro export dokumentace na wiki nebo do HTML), ale každý má svá úskalí a limity.

Řízení požadavků

Proces řízení požadavků je v takto komplexní variantě naprosto kritický. Nevhodně navržený proces, nebo nedostatečná pečlivost při jeho realizaci, končí v každém případě stejně – ztrátou kontroly nad stavem projektu a neschopností ho dále řídit. Každý člen týmu je odpovědný za svou fázi zpracování požadavku a nedílnou součástí této odpovědnosti je i sledování stavu jím realizované aktivity. Z tohoto důvodu je nezbytné nasadit nějaký silný task tracking systém (např. JIRA), ten zpřístupnit všem zainteresovaným stranám a všem vysvětlit jejich roli v celém procesu řízení požadavků. Důležitou součástí takto nastaveného procesu řízení požadavků je provázanost task tracking systému se systémem, který se používá k zaznamenávání samotných požadavků. Tzn. realizuje-li se řízení požadavků v task tracking systému JIRA, měli bychom zajistit provázání na obsah konkrétního požadavku například na wiki.

Naprostou nezbytností je jasná komunikační matice s vyznačenými zainteresovanými osobami, které jsou oprávněné vznášet požadavky. Vzhledem k tomu, že takto rozsáhlé projekty trvají většinou poměrně dlouhou dobu, je extrémně důležité udržovat tuto matici neustále aktuální. Předejdeme tak situacím, kdy pro projekt dosud neznámé zainteresované osoby začnou vznášet nové požadavky nebo se budou pokoušet již dříve odsouhlasený rozsah projektu redefinovat. S tím také souvisí nutnost definice eskalačních mechanismů – na velkém projektu s mnoha zainteresovanými stranami je jen otázkou času, kdy narazíme na vzájemně si odporující požadavky.

Agilita

Jak se postavit k agilitě v takto komplexní situaci? Zkušenost mi zatím neukázala, že by byla silná agilita pro takové prostředí vhodná a přinášela by rychleji a spolehlivěji kvalitní výsledky. Podle mých zkušeností je v takovýchto projektech klíčové dobře a poměrně detailně specifikované a odsouhlasené zadání. Nicméně část aktivit zadavatelské role můžeme (stejně jako v předchozí variantě) v určitých případech přesunout dovnitř dodavatelského týmu, což významně usnadní komunikaci a tím pádem i umožní rozsáhlejší aplikaci agilních metod a technik.

Dobrou zprávou je, že se v poslední době začínají objevovat první vlaštovky integrovaných nástrojů, které se snaží výrazně pomoci jak s procesem definování požadavků, tak i s jejich řízením (např. Jama nebo blueprint). Primární motivací je totiž reagovat na neustálý tlak agilních přístupů, které v oblasti projektů realizovaných největšími korporacemi, tzv. enterprise sféře stále narážejí právě na složitost jak organizační, tak i projektovou. Navíc fakt, že dosud v zásadě neexistuje integrovaná systémová podpora, která by vše mohla zprůhlednit a zjednodušit, zaběhnutý (tedy málo agilní) stav věci spíše podporuje. Tyto nové nástroje tak v sobě integrují na jedné straně poměrně sofistikované nástroje pro strukturované řízení požadavků, poskytují více či méně bohaté prostředky pro vyjádření samotného obsahu a v neposlední řadě často velmi elegantně podporují netriviální proces připomínkovacího a schvalovacího řízení.

Snižujme riziko neúspěchu projektu – efektivně a s rozumem

Jak tedy v praxi naplnit tezi, kterou slibuje nadpis této série článků? Popsané je skutečně pouhým vodítkem, které nelze aplikovat dogmaticky, za všech okolností. Tak jako vždy v projektovém řízení i tady platí, že zvolené postupy a nástroje budou významně ovlivněné vyspělostí dodavatelské a odběratelské organizace, a to nejen v oblasti projektového řízení. Obecně lze asi říci, že použít o stupeň sofistikovanější přístup a nástroje nic moc nezkazí, ale je nezbytné vyvarovat se použití pověstného „kanónu na komára“, neboť v ten okamžik často dojde k zahlcení zdrojů neproduktivními a nepotřebnými činnostmi a dramaticky roste riziko neúspěchu projektu.

Je totiž nutné si uvědomit, že úspěšně řízený rozsah projektu a požadavky, a tedy úspěšně dodaný projekt, nebude nikdy zásluhou zvolených nástrojů. Je to výsledek vhodně vyvážené kombinace procesů, lidí a zkušeností, které podpoříme volbou vhodné metodiky a vhodných nástrojů.

Jan Pacovský Autor článku se více než 12 let věnuje oblasti řízení požadavků, business i systémové analýze. Působil nejen na straně dodavatelů IT řešení, ale i jako zadavatel IT projektů na straně zákazníka. Zkušenosti sbíral na projektech v České republice i v zahraničí, kde vedl velké mezinárodní projekty a pracoval ve skutečně multikulturním prostředí (Čína, Kazachstán, Vietnam a další). Nyní je Managing Consultantem ve společnosti Adastra.