Specifikace zadání rozsahu projektu

Velmi zjednodušený postup projektu nasazení informačního systému do IT struktury zákazníka představuje následující části. Zadavatel specifikuje funkční a nefunkční požadavky na systém. Každý požadavek je analytickým týmem dodavatele ohodnocen, je odsouhlasen a na základě takto odsouhlasených požadavků se začne buď vyvíjet nový software, nebo je upravován standardní systém dle požadavků zákazníka. Následuje otestování, zaškolení a uvedení do testovacího a produktivního provozu. Ovšem již v době programování nebo při testování se vynoří otázky a připomínky typu: Nemohlo by toto tlačítko být vlevo místo vpravo? Je možné do tohoto výpisu přidat ještě tento sloupec? Jak náročné je změnit GUI obrazovky? Omlouváme se, ale zapomněli jsme definovat toto workflow pro tento typ dokumentu. My jsme předpokládali mnohem rychlejší odezvu nad aplikací. A takových změn se najednou vynoří celá řada a já se ptám: kde je hranice mezi postupným schvalováním tzv. drobných úprav systému, a kdy už se jedná o změnový požadavek na funkčnost, na uživatelskou přívětivost GUI a další případy programovacích změn ve vyvíjeném nebo upravovaném produktu? Dá se tato hranice určit striktně, nebo je to spíše určité lavírování na hraně spokojenosti zákazníka, jeho kladné reference, našeho společného výsledného úspěchu. Při každém projektu si tuto otázku kladu. Jak předejít chybné nebo nepřesné interpretaci požadavku ze strany zákazníka? Jak podpořit vzájemnou komunikaci, abychom si vysvětlili a správně „usadili“ příliš smělé požadavky na systém a omezili počet případných následujících změnových požadavků. Jsem si ovšem také vědoma, že specifikovat všechny funkce systému je pro zákazníka velmi složitý a komplexní problém, a že zákazník očekává podporu od dodavatele.

Výhody efektivní komunikace při analýze požadavků

Analýza a kategorizace požadavků je zásadním vstupem pro definování celkového rozsahu projektu. Při postupném odsouhlasení jednotlivých požadavků je potřebné provést důslednou prioritizaci jednotlivých požadavků, vyjasnit si s klíčovými uživateli přesné chápání dané funkčnosti, aby se předešlo skrytým nesrovnalostem mezi požadavky, předloženými návrhy a následnou implementací softwarového produktu. Analýza požadavků slouží i k přesné identifikaci testovacích scénářů, které zaručují akceptaci jednotlivých funkčních celků a požadavků. Jednoznačně popsané a odsouhlasené požadavky minimalizují potřebu přeprogramování funkčnosti a eliminují problémy změnového řízení. Efektivně vedená komunikace se zákazníkem ohledně správy, změn a schválení požadavků ovlivňuje projekt nejen z pohledu definice zadání a hodnocení výsledků (cílů) projektu ale také z pohledu časového řízení projektu. Úspěšně provedená vstupní analýza ušetří nejen čas, ale i investice, které je možné věnovat na rozvoj dalších aktivit.

Poznatky nabyté z praxe

Na základě dlouhodobých zkušenosti s implementací systémů správy dat vždy doporučuji následující vzájemné vyjasnění si těchto oblastí, které úzce souvisí s oblastí definice požadavků a jejího schválení.

Definujte cíle

Prvotním cílem managementu společnosti při rozhodnutí o nasazení informačního systémů, je vyjasnění strategického pohledu na využití a rozsah nasazení takového systému. Při hledání řešení je účelné zaměřit se na řešení, které podporuje již nastavené procesní standardy a schopnost začlenění do stávající podnikové infrastruktury. Nesmí jít o rozhodnutí jen současného využití systému, ale musí jít o celkovou koncepci začlenění systému do podnikového prostředí ve výhledu minimálně pěti let.

Nepodceňujte přípravu projektu

Jako při každém lidském konání je vždy výrazně větší šance na úspěch, když konkrétní akci předchází dobrá příprava, na základě které je možné mnohem lépe akceptovat požadavky a podmínky na výsledné řešení. Přípravnou fázi projektu nasazení informačního systému je možné členit na dva základní směry. Jedním ze směru je propracovaná funkční i technologická analýza. Funkční analýza nejen definuje rozsah projektu, specifikuje požadavky na systém, ale je možné získat i další pozitivní přínosy v podobě dobře nastavených metrik pro měření úspěšnosti změn v business procesu nebo hodnotných vstupů pro manažerský informační systém. Dalším osvědčeným směrem je nasazení tzv. pilotní části projektu, ve které se nejen odladí všechny požadavky na systém, omezí se funkční i technologická rizika a celkově se systém „usadí“ v IT prostředí. Pilotní nasazení systému umožňuje provést rychlou reakci na změny požadavků od uživatelů. Umožňuje efektivně odstranit chyby v systému, umožňuje postupně uvádět uživatele do problematiky a získávat zpětnou odezvu, zaučit klíčové uživatele, připravit školicí materiály přímo na odladěných datech.

Omezte rizika

Existují další aspekty, které mohou ovlivnit celkový výsledek projektu nasazení informačního systému. Je potřeba aktivně angažovat v projektu klíčové uživatele budoucího systému již od přípravné fáze. Je potřeba aktivně vnímat jejich potřeby a požadavky na systém nebo související procesy. Nasazení informačního systému bývá technologickým projektem IT oddělení, ale je také business projektem, uživatelé budou využívat jeho správně nastavené funkčnosti. Je potřeba pamatovat na finanční náklady projektu. Ale hlavně efektivně řídit případné změny. Změnové řízení vyvolává negativní reakce typu, my jsme předpokládali vaši (dodavatelskou) součinnost, my jsme předpokládali vaše doporučení pro změnu požadavků již v přípravné fázi. Vy jste přece specialisté na procesy na systém. Vy jste nám měli pomoci správně definovat požadavky.

Využijte podpory softwarových metodik

Řízení projektu představuje neustálé průběžné hodnocení jeho stavu a také předcházení rizikům, které se i z důvodů měnících se požadavků velmi často nastávají. Způsobem, jak podpořit efektivní vývoj produktu a celkové pojetí projektového řízení, je využití standardních metodik softwarového vývoje. Jednou z nejznámějších a často používaných metodik je Rational Unified Process, která je založená na přístupu ověřených způsobů užití neboli tzv. nejlepších praktik. Při vytváření této metodiky se vycházelo ze známých a opakovaně se vyskytujících problémů a závislostí. Jakkoli jsou požadavky správně definovány, nelze očekávat, že v průběhu vývoje produktu nebo jeho nastavení nedojde ke změnovým požadavkům na funkčnost systému. I zde je možné využít znalosti metodiky RUP. U každého požadavku je žádoucí vést rozsah návrhu změny, jeho finanční náročnost, jeho časovou náročnost, tak aby bylo možné neustále vyhodnocovat celkový stav změnového řízení a jeho dopad do celkového hodnocení projektu. Vzájemná kontrola a průběžné hodnocení požadovaných funkčních a technologických změn přispívá k bezproblémovému průběhu projektu.

Pár slov závěrem

Na žádném projektu vývoje softwaru se nelze vyhnout změnovým požadavkům. Změnové řízení je velmi citlivou oblastí každého projektového týmu. Nastavením podmínek změnového řízení je možné velmi ovlivnit celkový výsledek projektu. Skutečnost, že určité úpravy (změny) budou provedeny v rámci schváleného rozsahu, přispívá ke vzájemné důvěře a vzájemné součinnosti mezi dodavatelem a zákazníkem. V neposlední řadě je dodavatele neboli partnera pro implementaci systému doporučeno vybírat nejen dle zkušeností, referencí a schopnosti odladění koncepce předkládaného řešení, ale také na základě vzájemné vůle po úspěchu daného projektu.

Tamara Mazlová
Autorka zastává pozici Senior Business konzultanta ve společnosti Ness Czech.