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

26

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.

Amir Rezaei
źródło
1
Myślę, że lepsze pytanie brzmi: co robisz, gdy szacunek jest prawidłowy ? Przez większość czasu tak nie będzie.
Tim Post
@Tim Post Masz rację na temat „Przez większość czasu nie będzie” Chciałem zarezerwować.
Amir Rezaei,
1
+1 - Dzięki za EDYCJĘ, która zawiera słowa mądrości. Podkreślony przez ciebie fakt („„ 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 złożone.) ”” Jest bardzo prawdziwe.
Karthik Sreenivasan,

Odpowiedzi:

17

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.

Jon Hopkins
źródło
2
+1 „Jak w przypadku wszystkich złych wiadomości, najlepiej podać szczegółowe informacje”. Jednak nie wszyscy rozumieją szczegóły / złożoność problemu.
Amir Rezaei,
@Amir - dodałem trochę więcej, ale jako osoba, która rozumie złożoność, prosta prawda jest taka, że ​​Twoim obowiązkiem jest wyjaśnienie tego. Nie nauczą się w żaden inny sposób.
Jon Hopkins,
Słuszne uwagi! „z przykładami - trudno argumentować przykłady” i „delikatnie sugeruj, że w jego interesie jest dostarczanie na czas”. Jeśli chodzi o „jeśli zawsze tak się dzieje, nie powinno to być zaskoczeniem”, problem polega na tym, że dodatkowy czas na zaskoczenie nie jest stały. Możesz więc nawet nie wziąć na nie średniej, ponieważ mają one dużą zmienność.
Amir Rezaei,
+1 „Pamiętaj, że w przypadku poślizgnięć wpływ psychologiczny / wiarygodność jest kumulatywny.”
Karthik Sreenivasan,
16

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.

Martin Wickman
źródło
Czy możesz podać przykład, w jaki sposób śledzisz rozmiar zadań? Czy tworzysz tabelę z typami zadań (np. „Stwórz nowy formularz”, „dodaj metodę do webservice X”) czy jest to bardziej przeczucie?
cringe
Wystarczy porównać z zadaniami, które oszacowałeś i wykonałeś wcześniej.
Martin Wickman,
+1 - „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ć”. Po raz pierwszy dowiaduję się o względnych szacunkach i jest to z pewnością pożywka do przemyślenia. Dzięki.
Karthik Sreenivasan,
Co za wspaniały pomysł! Na pewno to zbadam.
meetpd
3

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.

Morten
źródło
3

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.

użytkownik 281377
źródło
2

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!

Frank Shearar
źródło
4
+1 @Frank Dobra uwaga na temat „Wytnij funkcje, abyś mógł wysłać je na czas”. Problem polega na tym, że nie jestem liderem projektu.
Amir Rezaei,
@Amir W takim przypadku klient jest (uprzejmie) liderem projektu. Mówisz „Jestem z tyłu. Mogę wyciąć tę funkcję lub tę funkcję. Co mam zrobić?”
Frank Shearar,
@Frank Ponieważ robimy Scrum, a skrzynka jest przenoszona z zaległości do sprintu, wydaje się, że napisano ją w kamieniu, aby PM zmniejszył liczbę spraw. Jednak doświadczenie PM może nie mieć tego rodzaju problemu.
Amir Rezaei,
Nie lubię MoSCoW. Jedyny sprytny to akronim. Po prostu przechowuj swoje zadania w zaległych priorytetach.
Martin Wickman,
1
@Martin wzrusza ramionami „Must” oznacza „jeśli nie wyślesz tej funkcji, w ogóle nic nie masz”. To inne informacje niż zaległości, dla których priorytetem jest „która funkcja wolisz jako pierwsza?” Nadal będziesz mieć priorytetowe zaległości w MoSCoW.
Frank Shearar,
2

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.

Mike Dunlavey
źródło
1

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ć!

Arialdo Martini
źródło
1

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.

PeterAllenWebb
źródło
0

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

Hoàng Long
źródło
Zaktualizowałem swoje pytanie. Powiadomiony zostanie lider projektu.
Amir Rezaei,
Nie do końca rozumiem. Jesteś liderem projektu, czy tylko programistą?
Hoàng Long,
0

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?

źródło
1
Należy zauważyć, że każde z tych słów jest KRÓTKOTERMINOWĄ odpowiedzią na pytanie „co zrobić, gdy szacowanie czasu nie powiedzie się”. Co najważniejsze, zagrożenia na krótko zwiększają motywację , a następnie mają odwrotny wpływ.
Dan Ray
Zgadzam się, że groźby są do niczego, chociaż jestem pewien, że działają one dla niektórych osób i w niektórych sytuacjach, szczególnie jeśli planujesz pozwolić im odejść.
0

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.

Patrick Cornelissen
źródło