CTO Milan Bodlák: Jak se poučit z chyb a neustále se posouvat vpřed

CTO Milan Bodlák: Jak se poučit z chyb a neustále se posouvat vpřed

Rok se s rokem sejde a koronavirus je tu stále s námi. Nebylo to náhodou minulý rok, kdy jsme zažívali takřka podobnou situaci jako dnes? Vypadá to, že jsme se z minulých chyb úplně nepoučili a náš přístup se příliš nezlepšil. Téma pandemie by ale bylo na jiný článek. Zmiňuji ho, protože v něm vidím jakýsi kontrast s tím, jak se snažíme pracovat u nás v Enehanu. V následujících odstavcích se logicky zaměřím hlavně na Delivery „bandu“ – tedy tým, který asi v 50 lidech, pracuje na komplexních dodávkách Salesforce projektů.

Project Lesson Learned

To, že se na projektu něco nepovede, se stává a stávat bude. Jsme přeci jenom lidé. Ale pokud se nechtěné věci opakují, je jasné, že je něco špatně. Jak se u nás opakování chyb předcházíme?  Když vezmu celý proces dodávky projektu od konce, tak na jeho závěru se vždy sejdou lidi, kteří se ho účastnili s lidmi, kteří měli možnost projekt v průběhu nepřímo ovlivnit nebo stáli u jeho zrodu.  Proběhne tzv.  „Project Lesson Learned“, kde si mezi sebou upřímně říkáme, co se povedlo, ale hlavně i to, co se nepovedlo a mohlo se udělat lépe. Například, že jsme měli zvolit jiný přístup k designu, že jsme ignorovali signály, které napovídaly, že projekt není v nejlepší kondici nebo že máme lépe komunikovat se zákazníkem potencionální dopady rozhodnutí, která se udály. Vždy je potřeba si říct a oddělit, zda se jednalo o systémovou chybu či individuální pochybení, protože první vede k úpravě metodik, doporučení nebo procesů a druhé směřuje ke zpětné vazbě klíčovým lidem.

Avšak individuální chyba vede k hlubšímu proškolování a lepší adopci již existujících materiálů.

Správně si asi říkáte, že analýza na konci projektu je super, ale už je pozdě. Stejně jako koronavirus, tak i projekt v nedobré kondici má určité příznaky. A je žádoucí mít něco, čím jsme schopni tyto příznaky identifikovat ještě v době, kdy je čas aplikovat správnou léčbu pro „uzdravení“ projektu. Jedním z nástrojů pro včasné zachycení „symptomů“ jsou pravidelné projektové statusy. Na nich vždy v obecné rovině zaznívá, jak projekt vypadá z pohledu časování, držení slíbeného dodávaného rozsahu, nákladové roviny a jak si stojí tým samotný. V rámci diskuse jsme schopni mnohé zachytit a nasměrovat správným směrem. Musíme si ovšem zachovat určitý nadhled, objektivnost a sebekritičnost lidí na projektu, kteří nám onen projektový stav podávají.

Project Review

Ne vždy je v lidských silách vidět něco, čeho jsme součástí, a proto se nám osvědčila další aktivita, které říkáme „Project Review“. O co jde? Vybraní seniorní lidé mimo projekt se po určitou dobu účastní běžného projektového dne, jsou na statusech, baví se s lidmi, projdou si projektový disk.  V žádném případě nechceme na někoho ukazovali prstem, že něco dělá špatně. Hlavním cílem je identifikovat již zmiňované nezdravé projektové příznaky, zachytit je včas a dát podněty k nápravě. „Project Review“ byl mělo proběhnou chvíli po tom, co projekt začal, protože právě na začátku jsme schopni většinu chyb zachytit. Délka této fáze je úměrná velikosti a komplexitě projektu.

Přípravná fáze – dvakrát měř a jednou řež

Už před začátkem projektu se dá předejít velké řadě budoucích problémů. Mluvíme o době, kdy se podává nabídka a společně se zákazníkem teprve definujeme a nastavujeme detaily projektu. V této fázi se držíme přísloví – „dvakrát měř a jednou řež“ a snažíme se vypozorovat signály, které by mohly vést k problémovým momentům. Mohlo by jít například o nejednoznačné rozdělení povinností a odpovědnosti mezi dodavatelem (námi) a zákazníkem, nebo situace, kdy sám zákazník zatím přesně neví, co chce, nebo je interně nejednotný. To vše je potřeba brát na zřetel a definovat podle toho parametry a fungování projektu před jeho samotným výkopem.

Závěrem bych rád dodal, že špatně fungující projekt, nebo nenaplněná očekávání nejsou cílem ani jedné ze zainteresovaných stran. Čas strávený na projektu je efektivně a příjemně strávený ve chvíli, kdy se je vše transparentně „vykopnuté“ a jakékoliv problémy se řeší včas. A taková drobnost na závěr, na projektu by v určité rovině nemělo existovat rozdělení na zákazníka a dodavatele, protože bychom měli vnímat, že jsme jeden tým, který má společný cíl.

Hleďme tedy vpřed, buďme sebekritičtí, pokorní. Jenom tak se můžeme posunout.

Autorem článku je Milan Bodlák, který před 5 lety stál zrodu Enehano Solutions, kde začínal jako Senior Consultant, pokračoval jako Head of Delivery a nyní zastává pozici Chief Technology Officer (CTO).  Byl součástí většiny klíčových projektů ať v ČSOB Pojišťovně, Equa bank, Produktboardu nebo ČSOB bance.

 

Novinky a informace

Přímo do vaší emailové schránky

Prozkoumejte související články

Řízení vztahů s obchodními partnery