Jan Zámostný, Software Engineering Director v oddělení Delivery má obrovské zkušenosti s řízením velkých projektů, ale i prací programátora nebo testera. V článku se dočtete užitečné tipy pro včasné zachycení chyb i konkrétní „hlášky“, u kterých, pokud je zaslechnete ve svém projektovém týmu, byste měli zbystřit. Navazuje na sérii článků o projektovém řízení a „Jak se poučit z chyb a neustále se posouvat vpřed“ CTO Milana Bodláka a příspěvek „Dodávání projektů není sranda. Jak na to?“ od ředitele delivery Tomáše Holého.

Enehano Solutions je firma, která dodává komplexní Salesforce projekty, jejichž cílem je ve firmách transformovat obchod, marketing nebo back office. Naše práce se moc neliší od klasického vývoje na zakázku, až na to, že se od začátku pohybujeme v rámci daném právě Salesforce platformou. Nicméně činnosti, jako je sběr požadavků zákazníka, business analýza, návrh architektury, vývoj, testování nebo projektový management, máme velmi podobné „custom development“ standardu.

Ani nám se tedy nevyhýbají klasické momenty, kdy jsme něco nezanalyzovali dostatečně, něco nám uteklo, udělali jsme špatný předpoklad, nebo jsme prostě něco špatně vyvinuli. Stává se. Důležité je se zamyslet (a opakovaně se zamýšlet) nad tím, jak takové nepříjemné momenty minimalizovat.

Práce s chybou

Jak píše Milan, důležité je vůbec si uvědomit, že nějaká chyba nastala. Systematicky chyby hledat, abychom je mohli napravovat. Ale ještě lepší je se snažit, aby se chyby nestávaly, případně se vyskytovaly v co nejmenším počtu. Udělat chybu je normální. Udělat stejnou chybu podruhé už vede k mírnému rozladění. Dělat tu samou chybu pořád dokola normální není. A to nejen proto, že každá chyba stojí peníze, ať už zákazníka nebo nás, ale také má negativní vliv na naši pověst.

Než se dostaneme k tématu, jak rozpoznat symptomy projektu v nedobrém stavu, zamysleme se nad tím, jak jim předcházet. V Enehano Solutions si myslíme, že vývoj softwaru na zakázku je disciplína dostatečně popsaná, známá, s přístupy lety ověřenými. Nechceme proto „vymýšlet kolo“, ale pokorně (i kriticky) se inspirujeme tím, co už někdo vymyslel. V jednotlivých řemeslných oblastech (sběr požadavků, analýza, architektura, vývoj, PM) sledujeme nové trendy, ale i ověřené standardy, a přenášíme je do naší praxe. Tak jednoduché prostředky jako kvalitně připravené checklisty, šablony nebo how-to’s mohou ušetřit velké bolení mnoha hlav.

Jak identifikovat, že na projektu není vše úplně v pořádku?

Jak jsem už zmínil výše, chyby se stávají. Důležité je včas identifikovat, že na projektu není vše úplně v pořádku.

Věřte seniorům. Máte ve firmě člověka, který už si prošel desítkami projektů v různých rolích? Říká vám takový člověk, že něco není dobře? Věřte mu. Já vím, pro nás ajťáky je to takové neuchopitelné a nesystematické, ale on ten senior nakonec mívá pravdu. A na co se to tedy takový člověk na projektu dívá? Na celek i na detaily, a určitě by měl znát odpovědi na otázky:

1. Jsou lidi na projektu jedna parta, nebo soubor jedinců?

2. Ví všichni, co se zákazníkovi dodává a jak mu to má pomoci?

3. Ví každý, co se od něj očekává, jaká je jeho role, jaké mají být jeho výstupy?

4. Znají všichni termíny?

5. Ví všichni, jak se přistupuje k jednotlivým oblastem? Je jedno místo, kde se schází všechna dokumentace a ví o něm všichni?

6. Měří se na projektu a pracuje se s naměřenými daty?

7. Jak víme, že jedeme podle plánu? Dá se tomu věřit? Tříbarevný pocitový semafor v project status prezentacích je proklatě málo.

8. Jede projekt tak trochu samospádem, nebo je každý aspekt promyšlený, má svůj důvod?

9. Nevymýšlíme znovu kolo?

10. Máme JIRA nebo jiný nástroj pro evidence a sledování plnění dílčích úkolů?  Když se na tohle budete lidí na projektu ptát a jejich odpovědi nebudou rychlé a jasné, něco je špatně. Třeba jen lokálně, ale třeba taky ne.

‍

Hlášky, při kterých zpozorněte

Když na kick-offu projektu zjistíte, že se mezi sebou o scope dohadují dvě oddělení na straně zákazníka, když popáté slyšíte, že  „toto bude upřesněno později”, když při své práci narážíte na to, že strany, které mají poskytnout součinnost, o ničem neví, dejte si pozor.  Když při interním project review dostáváte odhady pracnosti v řádu desítek MDs (protože detail vlastně není), když jsou termíny dány přáním zákazníka, a ne plánem s reálnými základy, když prostě při poctivé snaze detailně pochopit co a jak se dodává často slyšíte „to se ještě musíme domluvit”, je něco špatně.

‍

Malá rada na závěr

Na závěr vám ještě připojím jednu svoji osobní zkušenost – nepředpokládejte. Ověřujte. Řiďte. Nic se nestane samo.

‍

‍

‍