Prostě a jednoduše, když se spočítají člověkohodiny, tak vedoucí programátor už nesmí project managerovi uhnout a musí trvat na plánu, žádné zkracování.
Ostatně se doporučuje všechno přesně spočítat a pak vynásobit Ludolfovým číslem. Prý to vychází.
Samozřejmě to vychází. Jenom to nesmí být Ludolfovo číslo, ale bulharská konstanta. A když to nevyjde, tak to je chyba, že se použila konstanta špatná.
Realita je ta, že u IT projektů se časová náročnost odhaduje velmi blbě. Hůře než v jiných oborech - a to i v případě, že by ten projekt měl použít řešení, která už všechna byla použita jinde.
Pokud budete řešit něco nového, něco co jste ještě nedělali (nebo nedejbože to nedělal zatím nikdo), tak jediná správná odpověď na časovou náročnost projektu je "fakt nevím". Nějaké hodiny se samozřejmě nacenit musí, takže se tam něco napíše a nějaký termín se stanoví. Ale že se to potom do těch hodin a termínu nevejde je běžná věc.
Pokud někdo (tedy kromě javamana) umí třeba odhadnout, za jak dlouho by se dal naprogramovat systém, který bude řídit hejno dronů (nebo letadel) tak, jak funguje hejno živých ptáků, tak by mu bylo mnoho týmů po světě dost vděčno :-) Ale nemusíme chodit až k tak hi-tech projektům. Ono často stačí, že chcete prohnat data přes nějaký framework a zjistíte, že v aktuální verzi toho frameworku je chyba (a autor frameworku vám neudělá hotfix, bude se čekat na release, který bude za pár měsíců). A bum - to co mělo být za 3 dny hotové budete ohýbat přes jinou funkcionalitu a bude to trvat 3 týdny.