Výčet klasických chyb

Dalším zajímavým čtením pro projektové manažery je Výčet klasických chyb při vývoji software od Steva McConnella. Uvedu aspoň ty, o kterých si myslím, že je na ně třeba dávat nejvíc pozor (a dovolím si trochu komentovat). Pro přehlednost je zachováno číslování z původního dokumentu.

1. Undermined motivation aneb podkopaná morálka. Rozhodně jeden z nejzávažnějších problémů, které se může vyskytnout. Když lidi nevěří tomu, co dělají, je zaděláno na hodně velké problémy.

5. Adding people to a late project aneb přidávání lidí na zpožděný projekt. Bez komentáře, tohle je klasika už od "starého" Brookse.

6. Noisy, crowded ofices aneb hlučné nebo přeplněné pracoviště. Kdo zažil, ví, jak to dokáže snížit produktivitu lidí.

9. Lack of effective project sponsorship aneb chybějící účinné sponzorství projektu. V tomto případě by se effective dalo přeložit i jako skutečné, protože o to tu jde: projekt bez skutečné podpory shora asi není myšlený vážně.

10. Lack of stakeholder buy-in aneb nedostatek zájmu o projekt od všech, kteří by se o něj zajímat měli - od vedení po koncové uživatele. Vlastně zobecněná chyba č. 9, nicméně v tomto případě opakování nevadí.

11. Lack of user input aneb chybějící vstupy od uživatelů. Ještě jednou stejné téma. Když se neúčastní ti, kteří to nakonec mají používat, čekejte problémy.

14. Overly optimistic schedules aneb příliš optimistické plány. Pokud jste četli The Chaos Report, víte, že přílišný optimismus rozhodně není na místě.

15. Insufficient risk management aneb nedostatečné řízení rizik. Projekty bez rizika neexistují, takže rozdíl je v tom, co s riziky děláte.

19. Wasted time during the fuzzy front end aneb mrhání časem v přípravné fázi projektu. V přípravné fázi opravdu nemusí být všechno jasné, ale to není výmluva, aby tato fáze trvala skoro věčně.

27. Code-like-hell programming aneb zběsilé programování. Tipnu si, že máte v týmu programátora (nebo takového alespoň znáte), který by dokázal naprogramovat chybějící modul tím správně šíleným tempem, třeba za jedinou noc. Jak dlouho se pak v dotyčném kódu budou opravovat chyby?

29. Feature creep aneb "vkrádání se" požadavků. Vždycky se objeví někdo, kdo se do projektu pokusí přidat "jen tuhle jednu malou fukci". Když si nedáte pozor, máte tam těch drobností za chvíli sto. To, co vám pomůže, je dělat důsledně change management. Ta trocha přidané byrokracie za to stojí.