zajmę się tym pytaniem z perspektywy inżynierii oprogramowania, choć wiele z wyciągniętych wniosków odnosi się również do innych projektów. Tworzenie dokładnych szacunków projektu jest jednym z najtrudniejszych zadań do wykonania w inżynierii oprogramowania i często pomijaną umiejętnością, której większość inżynierów (w tym ja) nie wie, jak to zrobić dobrze. Zdarza się również, że ludzie, którzy wcześniej nie musieli szacować czasu ukończenia projektów, lekceważą trudność i często mylą swoje szacunki o co najmniej dwa czynniki. Jak każda umiejętność, tylko z praktyką staje się lepsza.
moje najbardziej żywe wspomnienie oszacowań projektu poszło nie tak kilka miesięcy po dołączeniu jako inżynier w Ooyala, startupie, który zapewnił kompleksową platformę wideo online. W sierpniu 2008 roku, zaledwie nieco ponad rok po założeniu firmy, zespół inżynierów rozpoczął prace nad przepisaniem odtwarzacza wideo opartego na technologii Flash. Naszym celem było uczynienie odtwarzacza bardziej modułowym i wydajniejszym, a także czystszym i lepiej przetestowanym kodem. Początkowy zespół 3 osób zaprojektował i napisał kilka podstawowych infrastruktur przed wciągnięciem mnie i reszty ~ 10-osobowego zespołu inżynierów. Szacowano 4 miesiące na zakończenie projektu, a dyrektor techniczny i menedżer produktu sporządzili wykresy Gantta podsumowujące podział prac i zależności. Nowy zawodnik zakończył karierę 9 miesięcy później, w maju 2009 roku .
chybiliśmy celu nie z powodu braku ciężkiej pracy lub utalentowanych inżynierów; była seria miesięcy, w których większość ludzi w zespole ciągnęła 70-80 godzin tygodni (niezalecane). W części projektu, nawet pieczołowicie przebrnęliśmy przez kilka dni ćwiczeń, w których przypisywaliśmy szacunki godzinowe do dość szczegółowych zadań. Największe opóźnienia prawie zawsze wynikały z czynników, wielu zewnętrznych, których nie uwzględniliśmy w wstępnych szacunkach:
- podpisywane są oferty klientów o wysokim priorytecie, które wymagały od inżynierów przełączenia kontekstowego na niestandardową pracę,
- błędy w kodzie Adobe flash player, które utrudniały dokładne określenie, kiedy wideo zostało faktycznie wstrzymane, buforowanie i odtwarzanie,
- trudne do odtworzenia błędy uszkodzenia wideo, które powodowały awarię odtwarzacza, gdy szukano pewnych klatek wideo w IE,
- 4 miesiące do projektu w celu utrzymania obecnej bazy klientów szczęśliwy,
- problemy skalowalności, które musiały być rozwiązane jako ilość dane analityczne rosły,
- wczesny inżynier opuszczający zespół w połowie projektu, wymagający dużego transferu wiedzy głównych części bazy kodu,
- itp.
podczas gdy przepisanie odtwarzacza było zdecydowanie konieczne dla firmy, nieprzewidziany sposób, w jaki się przeciągnął, odcisnął duże piętno na wczesnym starcie. Inne projekty, nad którymi pracowałem, widziałem używane lub rozmawiałem z innymi inżynierami, podążały za podobnymi wzorcami, w których rzeczywisty czas realizacji często podwaja pierwotne szacunki.
oto niektóre z moich lekcji na wynos z tych doświadczeń:
jak najwięcej, niech ludzie tworzący szacunki dla zadania będą prawdziwymi ludźmi, którzy będą nad nim pracować. Jest to podobne do punktu IANA Mcallistera w używaniu estymacji gracza B – już teraz niezwykle trudno jest jednej osobie dokładnie przewidzieć, jak długo lista zadań zajmie jej wykonanie, nawet jeśli zadania są dość szczegółowe; jeszcze trudniej jest przewidzieć, jak długo zajmie to ktoś inny z innym stopniem znajomości i innym stopniem umiejętności. Podczas przepisywania odtwarzacza Ooyala stało się oczywiste, że wiele początkowych szacunków było niezwykle agresywnych i zignorowało czas rozruchu inżyniera na częściach bazy kodu, z którymi był mniej zaznajomiony.
uważaj na efekt drugiego systemu. W mitycznym miesiącu człowiek Frederick Brooks opisuje na podstawie doświadczeń projektowych IBM, w jaki sposób ludzka tendencja do przeprojektowywania drugiego systemu prowadzi do znacznie większej złożoności, co powoduje, że harmonogramy projektów przeprojektowywania ślizgają się :
pierwsze prace architekta powinny być oszczędne i czyste. Wie, że nie wie, co robi, więc robi to ostrożnie i z wielką powściągliwością.
gdy projektuje pierwsze dzieło, Falbanka za falbanką i zdobienie za zdobieniem przychodzą mu do głowy. Te są przechowywane z dala do wykorzystania ” następnym razem.”prędzej czy później pierwszy system jest gotowy, a architekt, z niezachwianym zaufaniem i zademonstrowanym opanowaniem tej klasy systemów, jest gotowy do zbudowania drugiego systemu.
ten drugi to najniebezpieczniejszy system jaki człowiek kiedykolwiek zaprojektował… Ogólna tendencja polega na nadmiernym projektowaniu drugiego systemu, wykorzystując wszystkie pomysły i fanaberie, które zostały ostrożnie przesunięte na boki pierwszego.
szczególnie w przypadku projektu, który wymaga przepisania istniejącego oprogramowania, kuszące jest dołączenie mnóstwa nowych funkcji do tego, co w przeciwnym razie mogłoby być prostym portem, używając argumentu, że zespół może to zrobić, jeśli i tak zamierza przepisać bazę kodu. Zwiększona złożoność może spowodować, że ani przepisanie, ani nowe funkcje zostaną uruchomione znacznie później.
uważaj, ile czasu zajmie zadanie projektu z tym, jak szybko zakończy projekt. Im dłużej trwa projekt, tym większe prawdopodobieństwo, że zewnętrzne zmienne środowiskowe wejdą w grę i wydłuży ogólny harmonogram projektu. Powtarzające się przeciąganie, o którym wspomina Ian, przyczynia się do osi czasu projektu, ale także do nieoczekiwanych wydarzeń. W przypadku projektów, nad którymi pracowałem na początku tego roku w Quora, wiele z nich trwało dłużej niż oczekiwano ze względu na skumulowane koszty czasowe:
- reagowanie i odzyskiwanie po nieoczekiwanej, wielodniowej awarii AWS,
- obsługa perioidic Pager Duty alerts, aby utrzymać witrynę,
- zaplanowane wakacje, które kiedyś wydawały się dalekie od projektu, ale skończyło się na nim,
- przygotowywanie się do wydarzeń rekrutacyjnych i uczestniczenie w nich,
- przełączanie kontekstu między wieloma projekty, które okazały się trudniejsze niż początkowo oczekiwano.
w przypadku każdego projektu można prawdopodobnie wymienić dowolną liczbę zdarzeń i zakłóceń, które pojedynczo mogą być mało prawdopodobne lub niepostrzeżenie, ale które zbiorowo mają się wydarzyć i sumują się w wystarczająco długim czasie. Im dłuższy projekt, tym więcej zakłóceń będzie, i ważne jest, aby budżet buforowy czas dla zewnętrznych, nieznanych czynników.
budżet wystarczający na wszelkie zadania związane z integracją. Szczególnie w przypadku projektów z wieloma powiązanymi komponentami, wielu inżynierów ma tendencję do 1) odkładania kompleksowych zadań integracyjnych na sam koniec, i 2) znacznie lekceważyć ilość czasu potrzebnego do zintegrowania wszystkich elementów razem w systemie roboczym. Ponieważ integracja wydaje się być tak daleko i ponieważ ryzyko jest zazwyczaj nieznane — założenie przez czas integracji jest takie, że wszystkie komponenty pomyślnie działają w izolacji — niedocenianie czasu integracji wydaje się być dość powszechne. Projekty często otrzymują tylko niewielki ułamek całkowitego czasu projektu na testowanie end-to-end, mimo że jest to zazwyczaj jeden z bardziej ryzykownych aspektów projektu i, w porównaniu do wcześniejszych kamieni milowych, wymaga znacznie większej komunikacji między członkami zespołu.
konsekwencją tego jest rozpoczęcie kompleksowych testów jak najwcześniej, aby wcześniej zidentyfikować zagrożenia i problemy związane z integracją, tak aby było wystarczająco dużo czasu na ich rozwiązanie.
szacuj na podstawie tego, jak długo zadania będą faktycznie trwać, a nie na podstawie tego, jak długo ty lub ktoś inny chcesz, aby je zajęły. Zawsze będzie presja, aby szybciej realizować projekty, od siebie, od członków zespołu, od kierownictwa lub od klientów, a często reakcja emocjonalna na tę presję zakotwicza nas w zewnętrznych liniach czasowych i prowadzi do systematycznego lekceważenia zadań. Psychologicznie nikt nie chce zawieść innych ludzi i łatwo jest sobie wmawiać, że jeśli po prostu pracujesz trochę ciężej lub wydajniej, możesz dotrzymać określonego terminu. Jednak szczególnie w przypadku długich projektów ten rodzaj pobożnego życzenia jest ostatecznie niezrównoważony.
okresowo Przeglądaj i koryguj szacunki projektu w miarę postępów projektu. Podobnie jak większość dobrego oprogramowania jest budowane i ulepszane stopniowo, tak też są szacunki projektu. Rewizja szacunków projektu i porównanie szacunków dla zadań w ubiegłym tygodniu z faktycznym czasem wziętym pomagają w błędach szacowania powierzchni i korygowaniu harmonogramów w oparciu o wcześniej nieprzewidziane zagrożenia.
szacunki projektu prawie zawsze wydają się być niedoszacowane, a nie przeceniane; rzadko słyszy się o długich projektach kończących się przed terminem. Świadomość, że szacowanie projektu jest trudne i zastanawianie się, dlaczego szacunki poszły źle w konkretnym projekcie, poprowadzi cię do mniejszych błędów szacowania w kolejnych projektach.
wykonanie projektu to o wiele więcej niż tylko dokładne szacunki. Jeśli jesteś inżynierem i chcesz opanować techniki używane przez najlepszych inżynierów oprogramowania do przekształcania ich projektów w sukcesy, Pobierz bezpłatny, przykładowy rozdział mojej książki „skuteczny inżynier”. Zawiera setki historii, spostrzeżeń i strategii, które można wykorzystać od liderów z Doliny Krzemowej.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html