Na několika projektech jsem narazil na noční můru dodavatele informačního systému (ať už externí firmy nebo interního IT): na situaci, kdy zákazník nepovažoval analýzu, na jejímž základě se řešení či produkt vyvíjelo, za závaznou. Při předávání produktu k akceptaci pak uživatelé požadovali řadu změn s argumentem, že v průběhu analýzy „nad papírem“ nebylo možné si všechny funkce představit a do detailu promyslet. Řešení této situace ke spokojenosti zákazníka ze strany dodavatele pak bylo možné pouze s vynaložením nemalého objemu víceprací. A dodržení rozpočtu a předem dohodnutých termínů bylo – diplomaticky řečeno – velikou výzvou.
Změny na projektu tvoří vůbec samostatnou kapitolu projektu. U nezkušených zákazníků jsem se setkal s tendencí vnímat požadavek na změnu jako něčí chybu. Je nutné si uvědomit, že ke změnám dochází a že se jedná o normální součást všech projektů. Proto je vhodné, když zákazník od počátku počítá s tím, že cena za „fixed-price“ projekt nemusí být konečná. Dodatečné změny mohou mít dopad na pracnost i termíny, a promítnou se tak i do celkové ceny. Málokdy však rozpočty prvních projektů s tímto „fenoménem“ počítají. Osvědčilo se mi zákazníka i v tomto směru předem informovat.
Další tlak na změny jsem zaznamenal také v případech, kdy nebyly požadavky na vyvíjené řešení dostatečně dobře specifikovány nebo nebyl zákazník dobře obeznámen s metodikami na projektu použitými (metodika projektového řízení, vývoje apod.).
Podle mne by mělo být samozřejmé, že by dodavatelská firma měla (nejen méně zkušenému) zákazníkovi poskytnout ještě před zahájením projektu školení v oblasti zvolených metodik. Ten tak získá možnost pochopit všechny důsledky z této volby vyplývající. Na druhé straně, ne vždy jsem se setkal s vůlí akceptovat ověřené metody a postupy a pak je v průběhu celého projektu společně dodržovat.
Správně nadefinované požadavky jsou, podle mého názoru, plně v kompetenci dodavatele. Je na jeho zkušenosti zákazníkovy požadavky identifikovat a zaznamenat tak, aby později nemohlo docházet k nedorozuměním. Z praxe však vím, že specifikaci požadavků nelze provádět bez úzké spolupráce s pracovníky zákazníka. Tito odpovědní zaměstnanci tak musejí mít vyhrazený čas na kooperaci nejen v průběhu analýzy, ale i v dalších fázích vývojového cyklu. Nepopiratelnou zodpovědností zákazníka pak musí být i to, že jím akceptované požadavky budou považovány za závazné a případné změny budou předmětem změnového řízení.
Domnívám se, že dopady zmíněné situace lze zmírnit použitím iterativního přístupu při vývoji aplikace – tedy již v průběhu analytické fáze vytvářet na kritické části aplikace prototypy a betaverze, na nichž budou koncoví uživatelé plánované funkcionality zkoušet. Připomínky a návrhy na změny pak přicházejí dříve a jejich zapracování je méně nákladné.
Tato základní „pravidla“ by podle mne měli mít všichni na paměti na začátku každého projektu. Napomohou totiž úspěšnému dodání výsledného produktu ke spokojenosti všech zúčastněných stran v příjemné týmové atmosféře.
jan.pacovsky@adastracorp.com
PŘEDPLATNÉ
ČLÁNKY DO MAILU