Proces vývoje e-shopu – 4. díl: Projektové řízení
01.10.2020
Po úspěšném obchodním vyjednávání a vypracování zevrubné
analýzy projektu postaveném na špičkových a moderních technologiích, kterým jsme
se věnovali v minulých dílech, by se mohlo zdát, že projektový manažer už
jen sní třešničku na dortu projektu a slízne smetanu. Je tomu skutečně tak?
Rozhovor s Vítem Pavlůskem Vítek Pavlůsek, NetDirect Project Manager, zařizuje, aby každý v týmu odvedl svůj díl práce a hotový projekt nejen naplnil klientovo očekávání, ale přinesl i něco navíc.  |
Určitě si to slízne. Ale ne smetanu. 😊 Ve fázi implementace totiž teprve dojde na skutečné lámání chleba. Zákazník na začátku i v průběhu zhotovování díla poskytne finanční prostředky na výrobu. Přestože je průběžně informován o stavu realizace, až v závěrečné fázi předání do testu naplno zjišťuje, co si vlastně koupil. Nezřídka bývá překvapen, někdy i zklamán z některých částí. Předání díla se pak komplikuje. Přes veškerou snahu o co nejlepší a nejdetailnější analýzu jeho potřeb a jejich přetavení ve specifikaci zadání projektu se na konci nemusí potkat zákazníkovo očekávání s realitou. Užitečné je si nechat předem vyhotovit drátěný model, který graficky znázorňuje plánované prvky a funkce, aby nedošlo ke zklamání.
Je možné tomu předejít?
Snažíme se o to již na tzv. Kickoff meetingu, tedy zahajovací schůzce projektu. Na ní je přítomen jak Project Manager jako garant projektu, tak vedoucí výrobního a servisního oddělení, který reprezentuje vedení naší společnosti. Snažíme se v úvodu se zákazníkem naladit na stejnou vlnu, abychom navnímali jeho očekávání, a také definovali byznysové cíle. Ty jsou následně i „černé na bílém“ uvedeny na první straně v Kartě projektu. V té společně evidujeme všechny klíčové záležitosti, které s řízením výrobního projektu souvisí. Tedy od Cílů a Rozpočtu, přes Klíčové milníky, celkový Harmonogram, jeho případné změny a jejich důvody. Rovněž zaznamenáváme možná Rizika projektu a v konečné fázi i soupis Akceptačních kritérií a Registr chyb a změnových požadavků.
Změnové požadavky? Nebylo snad zadání jasně dané předem?
Specifikace zadání projektu je dokonce nedílná součást smlouvy. Je to ovšem kritická oblast, se kterou se potýkáme u každého projektu. Murphyho zákony platí neúprosně. Ať je zadání sepsáno jakkoli kvalitně, vždycky se najde skulinka. Často se stává, že téma nebylo úplně domyšleno a oběma stranám zkrátka unikne nějaká věc, což v dokumentu s velmi obšírným záběrem a nemalým počtem stran stává velmi často. Tyto oblasti se musí vyčlenit a vytvoří změnový požadavek. To samé v případě doplnění zadání o něco nového.
Původní zadání je však rovněž pomyslný mantinel, který určuje cenu díla. Pokud chceme něco měnit či doplňovat, je to spojeno s pracností, se kterou se původně nekalkulovalo. Tudíž i s penězi, které má zákazník vynaložit navíc. Proto doporučujeme tzv. projektovou rezervu – dopředu daný objem peněz nad rámec schváleného rozpočtu (např. 10 %), který se může, ale nemusí čerpat. Je to v podstatě „projektový polštář“. Dodá klidu oběma stranám v závěrečné části projektu, kdy se objeví vícepráce.
Další možnost je odsunutí změnových požadavků, které zákazník nevnímá vyloženě jako překážku bránící spuštění e-shopu, do tzv. Fáze 2. Tedy navazující, rozsahem menší projekt, který vylepšuje funkce původně navrženého a zpracovaného řešení.
Nedalo by se tomu předejít například jinou zvolenou metodikou řízení projektu?
Agilní řízení projektu by mohlo řešit některá úskalí popsaná výše. Rozdělení projektu do tzv. „sprintů“, neboli dílčích částí, které se postupně zpracovávají v daných časových úsecích, je na místě zejména u projektů většího rozsahu. V rámci našeho výrobního procesu, který funguje na principu Vodopádu, máme projekt rozdělen do položek, které postupně zpracováváme tak, aby navazovaly. Čistě agilní projektové řízení je mnohem náročnější co se týče procesů, tak zdrojů – a to i na straně zákazníka, což má nezanedbatelný vliv na náklady. Nebývá tudíž tak obvyklé u softwarových řešení jako je právě e-shop.
Co může naopak na svojí straně ovlivnit zákazník, aby zajistil co nejhladší průběh spolupráce?
Zákazník může zcela jistě zabezpečit součinnost a kapacity zdrojů na svojí straně a u třetích stran.
Jednou z největších brzd bývá integrace s informačním systémem zákazníka (ERP). Vše důležité se udržuje a ukládá právě v informačním systému – data o zákaznících, produktech, ceníky, objednávky, faktury atd. E-shop je prezentací tohoto tzv. „backendu“ navenek a musí být na něj bezproblémově navázán. Ne každá firma je natolik veliká, aby si své ERP řešení mohla spravovat, či dokonce vyvíjet sama. Proto nám do dvoustranné dohody o vývoji e-shopu vstupují i další hráči, se kterými je třeba se dohodnout a navázat spolupráci.
V neposlední řadě je potřeba přidělit e-shopu co nejvyšší prioritu a upřednostnit jej před obvyklými operativními činnostmi zaměstnanců, aby realizace proběhla hladce a kvalitně. To znamená vyčlenit dostatečné množství času, aby se stihlo projít co nejvíce variant scénářů, které nastanou v ostrém provozu.
Jaké jsou stěžejní oblasti v práci projekťáka?
- Příprava a aktualizace projektového plánu – sledovat a kontrolovat harmonogram a navázané cíle.
- Udržování pravidelné a jasné komunikace se zákazníkem a třetími stranami – zabránit přílišnému rozevření nůžek mezi očekáváním a realitou.
- Koordinace práce a výstupů členů projektového týmu – přehled o tom, na čem kdo pracuje a návaznost na časový plán projektu.
- Pravidelný reporting a případná eskalace problémů směrem k řídícímu výboru – předcházení a včasné řešení krizových situací.
- Sledovat, vyhodnocovat a rozhodovat o případných změnách a úpravách v projektovém plánu.