Co zrobić, gdy szacowanie czasu jest nieprawidłowe?

Załóżmy, że szacowany czas trwania sprawy wynosi 3 dni. Drugiego dnia zauważysz, że sprawa rośnie i pojawiają się nowe scenariusze, które nie zostały policzone, gdy dokonano szacowania czasu. Nowe odkrycie prowadzi do dodatkowych 2 dni (łącznie 5 dni). Jest to typowy problem, z którym prędzej czy później staniesz jako programista.

• Jakiej strategii można użyć, gdy zamierzasz powiadomić lidera projektu o nowym terminie dostawy?
• Często pojawia się pytanie, dlaczego? Jak motywujesz nowy czas dostawy?

Faktem jest, że wiele projektów nie poświęca wiele czasu analizom i projektowaniu podczas SDLC.

EDYCJA: W bardzo złożonych projektach, bez względu na to, ile rozsądnego czasu poświęcasz na analizę i projektowanie, zawsze są niespodzianki, ponieważ reguły biznesowe są zbyt skomplikowane. Jednak w takich przypadkach uważam, że lider projektu musi zdawać sobie sprawę ze złożoności i mieć właściwe podejście w przypadku niespodziewanych niespodzianek. Pytanie dotyczy tego, jak poradzić sobie z liderami projektów, którzy nie rozumieją złożoności.

Dostarczanie złych wieści

Absolutnie musisz niezwłocznie poruszyć tę sprawę, jednak jeśli możesz to zrobić w rozsądnym terminie (tj. Kilka godzin, nie więcej), powinieneś zrobić trochę oceny wpływu.

Jak w przypadku wszystkich złych wieści, najlepiej podać szczegółowe informacje (zamiast po prostu wymazać „to się spóźni”), więc podaj tyle / wiele z:

1) Zmienione prognozy / harmonogramy dla zadań, które przeszły.

2) Skorygowane prognozy / harmonogramy przyszłych zadań, które według ciebie, w świetle wiedzy, że niektóre rzeczy już się skończyły, mogą potrwać dłużej.

3) Bardzo krótkie powody, dla których doszło do poślizgu (nie wiruj, tak naprawdę, ale nie brzmisz jak wymówki). W tym przypadku stwierdzasz: „Szacowaliśmy na podstawie reguł X i Y, ale teraz uwzględniają Z, o którym nigdy nie wspomniano”. Może być w stanie wykorzystać to do wyjaśnienia klientom opóźnienia i uświadomienia im, jak ważne jest przede wszystkim zachowanie dokładności.

4) Jeśli to możliwe, alternatywne sposoby przywrócenia rzeczy na właściwe tory (zwykle ograniczające zakres, ale mogą istnieć inne opcje - inne części projektu mogą być spóźnione i może być możliwe przenoszenie zadań).

Pamiętaj, że w przypadku poślizgnięć wpływ psychologiczny / wiarygodności jest kulminacyjny. Możesz być w stanie uciec z jednym, ale drugi będzie znacznie trudniejszy, a trzeci trudniejszy.

Właśnie dlatego punkt 2 jest ważny - zrewiduj nie tylko to, co już się wymknęło, ale także przyszłe zadania, które według ciebie mogą potrwać dłużej niż pierwotnie zakładano. Poślizgnięcie się zdarza w IT, nie uczenie się na własnych błędach jest większym grzechem.

Zapobieganie konieczności dostarczania złych wiadomości

Istnieją tutaj dwa scenariusze: po pierwsze, nie dokonałeś szacunków sam, w którym to przypadku nie możesz zrobić nic więcej, niż zachęcać do włączenia się w prognozy następnym razem.

Po drugie, sam dokonałeś oszacowań, w którym to przypadku musisz spojrzeć na to, jak zrobić lepsze oszacowania. Dla mnie kluczowym zwrotem w pytaniu jest „zawsze są niespodzianki, ponieważ reguły biznesowe są zbyt skomplikowane” .

Z szacunkiem, jeśli zawsze tak się dzieje, nie powinno być zaskoczeniem . Jeśli dostaniesz tylko połowę reguł biznesowych, musisz założyć to w swoich szacunkach i pozwolić, by funkcja się zmieniła.

Możesz to zrobić, zwiększając szacunki dla posiadanych reguł (to działa, ale nie uczysz nikogo, co tak naprawdę się dzieje), ale lepiej jest podać w swoich szacunkach „Historycznie otrzymane reguły są uproszczoną wersją czego naprawdę chcą. Reguły, które podali, zajmą 3 dni, ale powinniśmy pozwolić na kolejne 3 dni na nieprzewidziane reguły, które prawdopodobnie zostaną odkryte podczas opracowywania i testowania ”.

Jeśli szef pyta o to, musisz przypomnieć mu o wszystkich przypadkach, w których było to prawdą (z przykładami - ciężko argumentować przykłady), a także delikatnie zasugerować, że w jego interesie jest dostarczanie na czas, jak i twoje, więc czyż nie? lepiej być konserwatywnym?

Ale sedno: jeśli zawsze lekceważysz ze względu na określony czynnik (w tym przypadku pełzanie funkcji), obliczyć to w swoich szacunkach.

Szacunki czasowe to domysły na temat przyszłości, które na dłuższą metę zawsze zawiodą. To bezcelowa bitwa, której nie można wygrać.

Przestań szacować za kilka dni i zamiast tego zacznij używać szacowania względnego . Oto prosty przykład:

1. Przypisz numer do każdego zadania. Najtrudniejszym zadaniem może być 10, a najłatwiejszym zadaniem 1.
2. Rozpocznij programowanie, aby ukończyć swoje zadania.
3. Po tygodniu przerwij pracę i zsumuj numery wszystkich wykonanych zadań. Powiedzmy, że kończysz na 14. To twoja tygodniowa prędkość.

W następnym tygodniu powtórz cały proces. Założę się, że twoja prędkość się zmieni, ale niewiele. Po kilku tygodniach twoja prędkość powinna być dość stabilna i właśnie do tego dążymy. Teraz możesz zacząć tworzyć plany z pewnością siebie. Wybierz zadania, które sumują się do twojej prędkości, a twój PM może być całkiem pewien, że zostanie wykonany zgodnie z obietnicą. W ten sposób powinieneś zmierzyć się z liderami projektu.

Jak tylko okaże się, że oszacowanie jest błędne, musisz podnieść dzwonek alarmowy. Poinformuj osoby oczekujące dostawy o opóźnieniu.

Jeśli to możliwe, poproś o pomoc kolegów z drużyny. Upewnij się, że nadal dostarczasz oprogramowanie o jak najwyższej jakości.

Skrót najprawdopodobniej wyrządzi w końcu więcej szkody i wszyscy zaangażowani powinni to wiedzieć. A przynajmniej powinno im to być wyjaśnione.

Dzieje się tak często, że żaden doświadczony menedżer projektu nie zrobi z tego wiele. Po prostu bądź szczery i nie dokonuj zbyt optymistycznych nowych szacunków; kiedy zobaczysz, że potrwa to znacznie dłużej, powiedz to. Nie mów codziennie „Potrzebuję trochę więcej czasu”.

Musisz wyjaśnić kierownikowi: czy oszacowanie było błędne, czy też niesprzyjające okoliczności (spędzony dzień na polowaniu na błąd) były przyczyną opóźnienia? W pierwszym przypadku coś jest nie tak z procesem szacowania, być może jest zbyt optymistyczne lub naiwne. W drugim przypadku jest to przypadek bufora, który, mam nadzieję, został uwzględniony w planie projektu.

Zawsze informuj odpowiednich interesariuszy o swoich postępach, w tym (zwłaszcza!), Że twoje szacunki były zbyt optymistyczne. Nie będą zadowoleni, ale będą wiedzieć, gdzie naprawdę stoi projekt i mogą odpowiednio zaplanować.

Idealnie, twoja lista funkcji będzie MoSCoWed - Must, Should, Could, Won't.

Kiedy zmierzasz do przekroczenia, wytnij Coulds, a następnie Shoulds. Wytnij funkcje, abyś mógł wysłać na czas: twój projekt zwykle nie żyje w izolacji, a przekroczenie daty premiery oznacza, że ​​kolejne projekty również przekroczą harmonogram.

Idealnie będziesz mieć tylko ~ 60% Musts. Jeśli musisz wyciąć te, masz bardzo poważne kłopoty (bardzo poważne przekroczenie), w takim przypadku będziesz musiał skrócić rogi.

Upewnij się, że masz wystarczająco dużo czasu po zwolnieniu, aby posprzątać bałagan spowodowany cięciem narożników!

Ocena projektu jest hazardowa, prosta i prosta. Nie ma nagrody bez ryzyka.

Jeśli kierownik tego nie rozumie, to pierwszą rzeczą, którą wyjaśnię.

Pytanie brzmi, kto pokrywa ryzyko?

Jeśli pracujesz na podstawie umowy o stałej cenie, ponosisz ryzyko.

Jeśli czas i materiały, to on pokrywa ryzyko.

Dlatego przy szacowaniu ważne jest, aby zrozumieć, że zgadujesz, i musisz mieć pojęcie, jak niepewna jest szacunek i kto pokrywa ryzyko.

Uważam, że najlepsza strategia stale udoskonala twoje oszacowania . Wiem, mówię: twoje pytanie jest w jakiś sposób niewłaściwe.

Czytając Przedstawiamy Deliberate Discovery autorstwa Dana Northa doszedłem do wniosku, że umieszczenie wysiłku oszacowania w fazie początkowej jest równoznaczne z przewidywaniem dokładnie wtedy, gdy twoja ignorancja na temat problemu i dziedziny jest na poziomie maksymalnym. Spójrz prawdzie w oczy, nie możesz przewidzieć, co jest niepewne, szczególnie jeśli nadal jest nieznane .

Zwinne metodologie rozwiązują ten problem, dzieląc żywotność projektu na kilka części (sprinty, w Scrumie) i powtarzając co tydzień szacunki (sortowanie historii). Co tydzień udoskonalamy to, co wiesz o problemie, a także szacunki.

Dla mnie oszacowanie nie może być prawdziwe ani fałszywe. Można to tylko stopniowo udoskonalić . Szacowanie nie jest zobowiązaniem. Dlatego nazywa się to szacowaniem.

Najlepsze, co możesz zrobić, gdy się spóźnisz (a także „ryzykujesz dostawą z wyprzedzeniem”, ponieważ problem jest taki sam: źle oszacowałeś), to eskalacja i jak najszybsze powiadomienie o tym klienta. To się nazywa zarządzanie ryzykiem. Im szybciej prześlesz opinię, tym skuteczniejsze będzie przeciwdziałanie. Zwykle oznacza to, że jeśli masz dowody, że nie możesz dostarczyć wszystkiego, powinieneś porozmawiać ze swoim klientem, powiedzieć jej, że możesz zrealizować tylko 70% zobowiązania i pozwolić jej zdecydować, co ma dla niej większą wartość biznesową i że powinien zostać wdrożony jako pierwszy .

Napisałem o tym tutaj Błędne oszacowanie, pomoc! Jestem spóźniony! Wytnij funkcje i przestań podlewać!

Nazywa się to szacunkiem, ponieważ jest to wykształcone przypuszczenie. Nie jest to nieomylny opis przyszłości i mam mało cierpliwości do ludzi, którzy tak traktują szacunki oprogramowania. Ostatecznie wiele rzeczy potrwa dłużej, niż się spodziewasz, w rzadkich przypadkach może to zająć rząd wielkości dłużej. Dzieje się tak nawet dla najlepszych programistów na świecie. Jak menedżer mógł oczekiwać, że ci się to nie przydarzy? Jeśli twoja menedżerka tego nie rozumie, nie ma dużego doświadczenia. Jeśli udaje, że tego nie rozumie, aby wywrzeć presję na harmonogramie, jest nierozsądna.

Najlepsze podejście jest najbardziej oczywiste. Gdy tylko zorientujesz się, że funkcja potrwa dłużej niż oczekiwano, przedyskutuj ją ze swoim menedżerem. Często istnieją sposoby, aby rozwiązać zarówno problemy, jak i problemy przełożonego. Oznacza to, że część funkcji, która spowalnia rzeczy, może być względnie nieistotna lub łatwa do modyfikacji w sposób umożliwiający szybszy postęp. W każdym razie nie bądź prześladowany w drugiej optymistycznej ocenie.

Poinformuj o tym cały zespół i spróbuj znaleźć rozwiązanie. Polecam 3 rozwiązania, od wysokiego do niskiego priorytetu:

za. Spróbuj znaleźć tymczasową poprawkę lub szybkie obejście

b. Praca, którą możesz zrobić, zrób to najlepiej. Po pokazaniu klientowi swojej doskonałej części pracy, poproś o pomoc: możemy to zrobić, ale jest jakiś problem i może spowolnić wydajność twojej pracy ... Może możesz zapytać go, czy jest jakaś niepotrzebna prośba / funkcja, którą można upuścić lub wyciąć.

Zaproponować alternatywne podejście do ich problemu, być może dobrym pomysłem.

do. Praca w godzinach nadliczbowych

Opcje:

• Wytnij funkcje
• Obniż jakość (zostaw poprawki błędów na później)
• Zwiększ produktywność
  • Znajdź i usuń blokery
  • Przerwa / odpoczynek
  • Skróć czas osobisty / sen
  • Zdobądź więcej siły roboczej
  • Zdobądź lepsze narzędzia
  • Trening
  • Zwiększ motywację
    • Darmowe jedzenie
    • [Obietnica] podwyżki / promocji / wakacji / premii / itp.
    • Zagrożenia
    • Popraw warunki pracy (lepszy sprzęt, meble itp.)
    • Zmień środowisko - pracuj w kawiarni lub przenieś cały zespół w jakieś fajne miejsce - schronisko górskie lub domek nad jeziorem?

To częsty problem :)

Jednym z prostszych podejść jest dodanie bufora do każdego oszacowania, ponieważ zawsze pojawiają się nieprzewidziane problemy. Rozmiar bufora zależy od wielkości zespołu oraz niepewności technologii i samego problemu.

Większe zespoły mają więcej osób, które mogą zachorować, i mniej osób, które wiedzą „wszystko”.

Nowe technologie są zawsze bardziej ryzykowne niż te, które już znasz.

A kiedy zobaczysz, że nie skończysz w przewidywanym terminie, wcześnie komunikuj się z interesariuszami. Może możesz zmienić priorytety rzeczy lub opóźnić niektóre funkcje po rozmowie z klientem / interesariuszem.