budu se zabývat otázkou z pohledu softwarového inženýrství, ačkoli mnoho získaných poznatků se vztahuje i na jiné projekty. Vytváření přesných odhadů projektů je jedním z nejtěžších úkolů v softwarovém inženýrství a často přehlíženou dovedností, kterou většina inženýrů (včetně mě) neví, jak dobře dělat. Je to také případ, že lidé, kteří dříve nepotřebovali odhadnout časy dokončení projektů, mají tendenci podceňovat obtížnost a často si své odhady mýlí alespoň o faktor dva. Jako každá dovednost, člověk se s praxí zlepší.
Moje nejživější vzpomínka na odhady projektu se zhoršila několik měsíců poté, co se připojila jako inženýr v Ooyala, spuštění, které poskytovalo end-to-end online video platformu. V srpnu 2008, jen o něco více než rok po založení společnosti, inženýrský tým začal pracovat na přepsání přehrávače videa založeného na blesku. Naším cílem bylo učinit hráče modulárnějším a výkonnějším a mít také čistší a lépe testovanou kódovou základnu. Počáteční tým 3 lidí navrhl a napsal nějakou základní infrastrukturu, než se vtáhl do sebe a do zbytku ~10-person engineering team. Odhadovali 4 měsíce na dokončení projektu, a CTO a produktový manažer vytvořili Ganttovy grafy shrnující Rozpis práce a závislosti. Nový hráč skončil plně spuštěn o 9 měsíců později v květnu 2009 .
cíl jsme vynechali ne pro nedostatek tvrdé práce nebo talentovaných inženýrů; byla řada měsíců, kdy většina lidí v týmu vytáhla 70-80 hodinové týdny (nedoporučuje se). V rámci projektu jsme dokonce pečlivě prošli několikadenními cvičeními, kde jsme přidělili hodinové odhady poměrně podrobným úkolům. Největší zpoždění téměř vždy vyplynulo z faktorů, mnoho vnějších, které jsme v počátečních odhadech nezohlednili:
- vysoce prioritní nabídky zákazníků jsou podepsány, které vyžadovaly, aby inženýři kontext přepnuli na vlastní práci,
- chyby v kódu Adobe flash player, které ztěžovaly přesné určení, kdy bylo video skutečně pozastaveno, ukládání do vyrovnávací paměti a přehrávání,
- těžko reprodukovatelné chyby při poškození videa, které by selhaly přehrávač při hledání určitých obrazových snímků v IE,
- vývoj produktu, který potřebuje obnovit 4 měsíce do projektu, aby byla současná zákaznická základna spokojená,
- škálovatelnost problémy, které je třeba řešit jako množství analytická data rostla,
- časný inženýr opouštějící tým v polovině projektu, vyžadující velké množství přenosu znalostí hlavních částí kódové základny,
- atd.
zatímco přepis hráče byl pro společnost rozhodně nezbytný, nepředvídaný způsob, jakým se vytáhl, si při raném spuštění vybral velkou daň. Jiné projekty, na kterých jsem pracoval, viděl z druhé ruky, nebo mluvil s jinými inženýry, následovaly podobné vzorce, kdy skutečná doba dokončení často zdvojnásobuje původní odhady.
zde jsou některé z mých lekcí s sebou tak daleko od těchto zkušeností:
pokud je to možné, nechte lidi, kteří produkují odhady pro úkol, být skutečnými lidmi, kteří na něm budou pracovat. To je podobné jako u Iana Mcallistera, který používá odhad B-hráče – pro jednu osobu je již neuvěřitelně obtížné přesně předpovědět, jak dlouho by se seznam úkolů musel udělat, i když jsou úkoly poměrně podrobné; je ještě těžší předpovědět, jak dlouho by trvalo někomu jinému s jinou mírou znalosti a jinou mírou dovedností. Během přepisování hráče Ooyaly bylo zřejmé, že mnoho počátečních odhadů bylo extrémně agresivních a ignorovalo čas inženýra na části kódové základny, se kterými byl méně obeznámen.
pozor na efekt druhého systému. V mýtickém měsíci člověka, Frederick Brooks popisuje ze svých projektových zkušeností v IBM, jak lidská tendence k přepracování druhého systému vede k podstatně zvýšené složitosti, což způsobuje sklouznutí jízdních řádů projektů redesignu:
první práce architekta je apt být náhradní a čisté. Ví, že neví, co dělá, takže to dělá opatrně a s velkou zdrženlivostí.
když navrhuje první dílo, objeví se mu ozdoba za ozdobou a ozdoba za ozdobou. Ty se ukládají pryč, aby mohly být použity „příště.“dříve nebo později je první systém dokončen a architekt s pevnou důvěrou a prokázaným ovládáním této třídy systémů je připraven postavit druhý systém.
tento druhý je nejnebezpečnější systém, jaký kdy člověk navrhuje… Obecnou tendencí je přepracovat druhý systém pomocí všech nápadů a ozdůbek, které byly na prvním opatrně odvráceny.
zejména pro projekt, který zahrnuje přepisování stávajícího softwaru, je lákavé spojit spoustu nových funkcí do toho, co by jinak mohlo být přímým portem, pomocí argumentu, že tým by to mohl také udělat, pokud se stejně chystají přepsat kódovou základnu. Zvýšená složitost může vést k přepsání ani spuštění nových funkcí až výrazně později.
dávejte pozor na to, kolik času budou úkoly projektu trvat s tím, jak brzy bude projekt dokončen. Čím déle projekt trvá, tím vyšší je pravděpodobnost, že vnější proměnné prostředí vstoupí do hry a prodlouží celkovou časovou osu projektu. Opakující se tažení, které Ian zmiňuje, přispívá k časové ose projektu, ale stejně tak neočekávané události. U projektů, na kterých jsem pracoval na začátku tohoto roku v Quoře, spuštění řady z nich trvalo déle, než se očekávalo kvůli kumulativním časovým nákladům:
- reakce na neočekávaný vícedenní výpadek AWS a zotavení se z něj,
- manipulace s perioidními výstrahami pageru, aby se web udržel,
- plánované dovolené, které se kdysi zdály daleko od projektu, ale nakonec se s ním překrývaly,
- příprava na náborové akce a účast na nich,
- přepínání kontextu mezi více projekty, které se ukázaly být složitější, než se původně očekávalo.
u každého projektu by se pravděpodobně dalo uvést libovolný počet Událostí a rozptýlení, které by jednotlivě mohly být nepravděpodobné nebo neostré, ale které se kolektivně musí stát a sčítat se v dostatečně dlouhém časovém rámci. Čím déle bude projekt, tím více rozptýlení bude, a je důležité, aby rozpočet rezervoval čas na vnější, neznámé faktory.
rozpočet dostatečný čas pro všechny úkoly související s integrací. Zejména u projektů s mnoha vzájemně propojenými komponenty má mnoho inženýrů tendenci 1) odkládat integrační úkoly typu end-to-end až do samého konce a 2) výrazně podceňovat čas potřebný k integraci všech kusů dohromady do pracovního systému. Protože integrace má tendenci být tak daleko a protože rizika jsou obvykle neznámá-předpoklad integračního času je, že všechny komponenty úspěšně fungují izolovaně – podceňování integračního času bývá poměrně běžné. Projektům je často přidělen pouze nepatrný zlomek celkového času projektu pro end-to-end testování, i když je to obvykle jeden z rizikovějších aspektů projektu a ve srovnání s dřívějšími milníky vyžaduje podstatně větší režii komunikace mezi členy týmu.
důsledkem toho je zahájit end-to-end testování co nejdříve, aby bylo možné identifikovat integrační rizika a problémy dříve, aby bylo dost času na jejich řešení.
odhad na základě toho, jak dlouho budou úkoly skutečně trvat, nikoli na základě toho, jak dlouho vy nebo někdo jiný chcete, aby trvaly. Vždy bude tlak na rychlejší dokončení projektů, buď od vás, od členů vašeho týmu, od vedení nebo od zákazníků, a často emocionální reakce na tento tlak nás ukotvuje k externě požadovaným časovým osám a vede nás k systematickému podceňování úkolů. Psychologicky nikdo nechce nechat ostatní lidi dolů a je snadné si říct, že pokud pracujete jen trochu tvrději nebo efektivněji, můžete splnit určitý termín. Zejména u dlouhých projektů je však tento typ zbožného přání nakonec neudržitelný.
pravidelně revidovat a revidovat odhady projektu v průběhu projektu. Stejně jako to, jak je většina dobrého softwaru postavena a vylepšena postupně, tak i odhady projektů. Revize odhadů projektu a porovnání odhadů úkolů za poslední týden se skutečným časem pomáhají odhalit chyby odhadu a revidovat plány na základě dříve nepředvídaných rizik.
odhady projektů téměř vždy bývají spíše podceňovány než nadhodnocovány; zřídka slyšíme o dlouhých projektech dokončených v předstihu. Být si vědom toho, že odhad projektu je těžký, a přemýšlet o tom, proč se odhady na konkrétním projektu pokazily, vás povede k menším chybám odhadu v následujících projektech.
na projektu je mnohem víc než jen vytváření přesných odhadů. Pokud jste inženýr a chcete zvládnout techniky používané špičkovými softwarovými inženýry k přeměně jejich projektů na úspěchy, stáhněte si zdarma ukázkovou kapitolu mé knihy the Effective Engineer. Je nabitý stovkami příběhů, postřehy, a akční strategie od vůdců z celého Silicon Valley.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html