Jak odpowiedzieć, gdy zostaniesz poproszony o wycenę?

652

My, jako programiści, ciągle pytamy: „Jak długo to potrwa”?

I wiesz, sytuacja jest prawie zawsze taka:

  • Wymagania są niejasne. Nikt nie przeprowadził dogłębnej analizy wszystkich implikacji.
  • Nowa funkcja prawdopodobnie złamie niektóre założenia przyjęte w kodzie i natychmiast zaczniesz myśleć o wszystkich rzeczach, które możesz zmienić.
  • Masz inne rzeczy do zrobienia na podstawie wcześniejszych zadań i będziesz musiał opracować szacunek uwzględniający tę inną pracę.
  • Definicja „zrobione” jest prawdopodobnie niejasna: kiedy zostanie wykonana? „Gotowe” jak właśnie skończyłem kodować, czy „gotowe” jak w „użytkownicy go używają”?
  • Bez względu na to, jak bardzo jesteś świadomy tych wszystkich rzeczy, czasami twoja „duma programisty” sprawia, że ​​dajesz / akceptujesz krótsze czasy, niż początkowo przypuszczałeś. Zwłaszcza, gdy czujesz presję terminów i oczekiwań kierownictwa.

Wiele z nich to kwestie organizacyjne lub kulturowe, które nie są proste i łatwe do rozwiązania, ale w rzeczywistości w rzeczywistości pyta się cię o wycenę i oczekują od ciebie rozsądnej odpowiedzi. To część twojej pracy. Nie możesz po prostu powiedzieć: nie wiem.

W rezultacie zawsze kończę na oszacowaniach, które później uświadamiam sobie, że nie mogę spełnić. Stało się to niezliczoną ilość razy i zawsze obiecuję, że to się więcej nie powtórzy. Ale tak jest.

Jaki jest twój osobisty proces podejmowania decyzji i dostarczania wyceny? Jakie techniki uważasz za przydatne?

Sergio Acosta
źródło
4
Jeśli wymagania nie są tak jasne, możesz oszacować z 50% marginesem błędu (szerszy zakres). Jeśli wymagania są jasne, można oszacować z 20% marginesem błędu. Inną dobrą strategią, która działała dla mnie, jest podzielenie projektu na etapy. W ten sposób łatwiej jest oszacować i wystarczy oszacować tylko pierwszy etap. Kiedy masz zamiar oszacować następny etap, lepiej rozumiesz projekt. Ponadto zaufanie między tobą a wykonawcą powinno być lepsze. Zawsze też piszę swoje założenia i warunki wstępne. Nigdy nie pisz „będzie działał na IE8 lub wyższej”, bądź konkretny.
Francisco Goldenstein,
Sergio: „W rezultacie zawsze kończę na szacunkach, które później uświadamiam sobie, że nie mogę spełnić. To zdarzyło się niezliczoną ilość razy i zawsze obiecuję, że to się nie powtórzy. Ale tak się dzieje”. Jak dzisiaj czujesz się poprawiony?
Remigijus Pankevičius
4
@ r.pankevicius Szczerze mówiąc, właśnie przestałem podawać szacunki: rclayton.silvrback.com/software-estimation-is-a-losing-game
Sergio Acosta
2
Myślę, że ważne jest również dostrzeżenie niuansu między „szacunkami” a „terminami”. Szacunek nie jest zobowiązaniem, więc drobny błąd nie powinien być zbyt problematyczny. Napisałem tutaj długi post na blogu, na wypadek, gdyby ktoś był zainteresowany: marcgg.com/blog/2015/08/27/deadlines-estimates-software-startup
marcgg

Odpowiedzi:

390

Od pragmatycznego programisty: Od czeladnika do mistrza :

Co powiedzieć, gdy zostaniesz poproszony o wycenę

Mówisz „Wrócę do ciebie”.

Prawie zawsze uzyskujesz lepsze wyniki, jeśli spowolnisz proces i poświęcisz trochę czasu na wykonanie kroków opisanych w tym rozdziale. Szacunki podane w ekspresie do kawy wrócą (podobnie jak kawa), aby cię prześladować.

W sekcji autorzy zalecają następujący proces:

  • Określ dokładność, której potrzebujesz. Na podstawie czasu trwania możesz podać szacunek z różną dokładnością. Powiedzenie „od 5 do 6 miesięcy” różni się od powiedzenia „150 dni”. Jeśli wślizgniesz się trochę w 7. miesiąc, nadal będziesz dość dokładny. Ale jeśli wpadniesz w 180 lub 210 dzień, nie tak bardzo.
  • Upewnij się, że rozumiesz pytanie. Określ zakres problemu.
  • Modeluj system. Model może być modelem mentalnym, diagramami lub istniejącymi rekordami danych. Rozłóż ten model i zbuduj oszacowania z komponentów. Przypisz wartości i zakresy błędów (+/-) do każdej wartości.
  • Oblicz oszacowanie na podstawie swojego modelu.
  • Śledź swoje prognozy. Zapisz informacje o szacowanym problemie, szacunkach i rzeczywistych wartościach.
  • Inne elementy, które należy uwzględnić w oszacowaniu, to opracowywanie i dokumentowanie wymagań lub zmian specyfikacji wymagań, tworzenie lub aktualizowanie dokumentów projektowych i specyfikacji, testowanie (jednostka, integracja i akceptacja), tworzenie lub aktualizowanie podręczników użytkownika lub plików README wraz ze zmianami. Jeśli 2 lub więcej osób pracuje razem, powstaje narzut związany z komunikacją (rozmowy telefoniczne, e-maile, spotkania) i łączeniem kodu źródłowego. Jeśli jest to długie zadanie, weź pod uwagę takie rzeczy, jak inna praca, czas wolny (wakacje, urlop, czas choroby), spotkania i inne zadania ogólne przy wyborze terminu dostawy.
Thomas Owens
źródło
32
To także duża część „Black Art of Software Estimation” McConnellsa. Nigdy go nie ściągaj.
Paul Nathan
12
Bardzo polecam książkę McConnell. Jeśli to możliwe, poproś każdego, kto potrzebuje oszacowania, aby wziął udział w quizie szacunkowym: codinghorror.com/blog/2006/06/… Możesz przedstawić go jako grę, ale często pomaga to przekazać wiadomość.
Paddyslacker,
130
Można zawsze powiedzieć „Oddzwonię do ciebie.” Jeśli ktoś powie „Cóż, potrzebuję odpowiedzi”, powiedz „Jeśli dam ci teraz odpowiedź, to będzie kłamstwo. Nie mam teraz wystarczającej ilości informacji. Byłoby dla nas obojga szkoda, żebym coś zrobił na miejscu ”.
Andy Lester,
15
@AndyLester - powstaje wiele sytuacji, w których jeśli NIE udzielisz teraz odpowiedzi, ktoś inny zabierze ze sobą projekt i pieniądze lub w dalszym ciągu obwinie cię za to, że nie oszacowałeś, że nic nie miałeś robić z. To jest do bani i jest złe, ale to niestety rzeczywistość.
Joris Timmermans
3
@ThomasOwens Nigdy nie użyłbym szacunku strzelania z biodra dla kontraktu, ale używam tych szacunków przed etapem kontraktu. Muszę podać jakiś rząd wielkości, zanim klient poświęci swój cenny czas na wwiercenie się w krwawe drobne szczegóły - jeśli to, co zamierzają zapłacić, to kilka rzędów wielkości mniej niż moje optymistyczne przeczucie, że nie ma sensu nawet początek.
Joris Timmermans
170

Szacowanie oprogramowania jest najtrudniejszym pojedynczym zadaniem w inżynierii oprogramowania. Drugim etapem jest wzbudzanie wymagań.

Istnieje wiele taktyk ich tworzenia, wszystkie oparte na uzyskaniu dobrych wymagań. Ale kiedy twoje plecy opierają się o ścianę i odmawiają podania lepszych szczegółów, Fake It:

  1. Przyjrzyj się swoim wymaganiom.
  2. Dokonuj założeń, aby uzupełnić luki na podstawie najlepszego odgadnięcia, czego chcą
  3. Zapisz wszystkie swoje założenia
  4. Niech usiądą, przeczytają i zgodzą się z twoimi założeniami (lub, jeśli masz szczęście, spraw, by się poddali i dali ci prawdziwe wymagania).
  5. Teraz masz szczegółowe wymagania, które możesz oszacować.

To tak, jak moja matka groziła, gdy byłem dzieckiem „Pośpiesz się i wybierz jakieś ubrania, albo ja je dla ciebie wybiorę !”

Fishtoaster
źródło
Zadałem pytanie uzupełniające dotyczące twojego trzeciego punktu. programmers.stackexchange.com/questions/132970/…
k0pernikus
Ile czasu zajmuje napisanie dobrych wymagań?
mmehl,
142

Stworzyłem program dla faceta, który był bardzo nieugięty w kwestii dokładnych szacunków. Ustaliliśmy, co działało bardzo dobrze, to:

  • Opłacałem za cały czas szacowania. Doszło do około 20-25% tego, co naliczyłem.
  • Zrobiłem bardzo szczegółowe badanie zadań. Bez strzelania z biodra. Poszedłem do kodu, zorientowałem się, które wiersze należy zmienić, jakie inne części programu to wpłynie, ile testów muszę zrobić, aby upewnić się, że wszystko nadal działa. Oceniłbym każdy kawałek w jednostkach .1 godzin (6 minut).
  • Wysłałem mu swoją wycenę dla każdego zadania wraz ze szczegółowym podziałem.

20-25% fakturowania brzmi bardzo często.

Ale poprosił mnie o zmianę XYZ, sądząc, że zajmie to około 2 godzin. Po 1 godzinie szczegółowego oszacowania ustaliłbym, że zajmie to 8,5 godziny. Więc zdecyduje, czy warto było zapłacić 8,5 godziny. Jeśli nie, zaoszczędziłby 7,5 godziny ponad tym, co kosztowałoby go, gdybym to zrobił bez oszacowania.

A jeśli on nie chce zainwestować 8,5 godziny, szczegóły pracy zrobiłem dla oszacowania była praca bym musiał zrobić tak.

Przekonałem się, że dzięki tej metodzie byłem w stanie wykonać większość zadań na czas, a nawet wcześnie, bez nadmiernego przeceniania. Ponieważ czas był tak drobiazgowy, że mogłem wcześnie stwierdzić, czy się poślizgnęłam. Jeśli uderzę w przeszkody, aby po 3 godzinach móc stwierdzić, że moje 8,5-godzinne zadanie zajmie 12, mógłbym z nim porozmawiać o tym, zanim upłynie więcej czasu, aby mógł ponownie ocenić i szarpnąć tę funkcję, gdyby był zaniepokojony kosztami .

Czy on był niklem i przyćmił? Nie, patrzyłem na to, pozwalając mu wykorzystać pieniądze tam, gdzie widział najwięcej korzyści. Cieszyłem się z doświadczenia w szacowaniu, w którym zawsze byłem okropny.

Kyralessa
źródło
12
To brzmi jak bardzo odpowiednia technika. W rzeczywistości, gdy dokonujesz oszacowania dla własnej firmy, szacowany czas jest również wypłacany jako część twojego wynagrodzenia. Obawiam się jednak, że problem polega na tym, że większość organizacji chce oszacowań znacznie większych zadań niż te, które można wyrazić w porcjach po 1 godzinie. Dzięki za odpowiedź. (Czy jesteś tą samą Kyralessą z joela na płytach programowych?)
Sergio Acosta
1
Tak, ten sam.
Kyralessa
@SergioAcosta chodzi o to, że używasz czasu analizy / szacowania, aby rozbić zadanie na mniejsze części. To najlepsza odpowiedź, imho.
NimChimpsky
7
Więc jeśli jest to projekt na 5 miesięcy, powinieneś szacować go na miesiąc lub dłużej. Prawdopodobnie menedżerowie tego nie zaakceptują :)
Darius.V
@ Darius.V, masz rację. W tym przypadku decyzje klienta brzmiały „Tak” lub „Nie” dla poszczególnych funkcji, a nie ogólne „Tak” lub „Nie” dla całego projektu. Ta technika jest z pewnością trudniejsza, jeśli realizacja całego projektu zależy od ogólnej oceny. Z drugiej strony, jeśli budżetujesz projekt na sześć miesięcy, ale projekt może potrwać nawet rok, czy wolałbyś dowiedzieć się o tym po sześciu miesiącach, czy po dwóch lub trzech?
Kyralessa
64

Często jesteśmy proszeni o „szacunkową ocenę” podczas spotkań, podczas których otrzymujemy bardzo szerokie i szczegółowe pomysły na to, co chcieliby zrobić. Zawsze mówię: „jeśli dzisiaj chcesz uzyskać odpowiedź, to jest to rok i milion dolarów. Jeśli chcesz podać mi znacznie więcej szczegółów i trochę czasu na ich przejrzenie, mogę dopracować te liczby”.

Prawie zawsze mają rację.

Walter
źródło
7
Kiedy mówią, że to za dużo, udaję, że zastanawiam się przez chwilę, a potem mówię: „Masz rację! To 18 miesięcy i 2 miliony”.
CyberFonic,
55

To zależy od tego, do czego służy szacunek.

W przypadku wstępnego oszacowania wysokiego poziomu dla uzasadnienia biznesowego najważniejsze są:

  1. Prędkość. Jakąkolwiek metodę użyjesz, musi być szybka. Chodzi o to, że interesariusze nie są pewni, czy warto w ogóle wykonać projekt - dlatego potrzebują liczb do uzasadnienia biznesowego. Gdyby uzasadnienie biznesowe było solidne, nie potrzebowaliby twoich szacunków. Większość tych projektów nie będzie kontynuowana, dlatego ważne jest, aby nie poświęcać zbyt wiele wysiłku na dostarczenie szacunków.
  2. Podaj zasięg. Zrób to szeroko. Nie miałeś czasu analizować wymagań, warsztatów z interesariuszami, weryfikować założeń. Szeroki zakres mówi odbiorcy szacunku „Projekty oprogramowania są z natury złożone i ryzykowne - jeśli chcesz właściwego oszacowania, musisz podać mi więcej szczegółów i więcej czasu”. Problem z podaniem pojedynczej liczby lub wąskiego zakresu polega na tym, że wpycha cię w kąt, ustalając oczekiwania przed przeprowadzeniem jakiejkolwiek prawdziwej analizy.

Znajduję najlepszą technikę wyboru porównywalnego projektu, który „czuje” to samo. „Poczuj” jest całkowicie subiektywne - ale przy takim szacunku moje doświadczenie mówi mi, że nie znajdziesz obiektywnych pomiarów. Następnie zapewnij szeroki zakres. Przeczytałem kilka książek, które mówią, że zakres od -50% do + 100% jest dobry, ale zależy to od wielu czynników.

Aby uzyskać szczegółowe oszacowanie niskiego poziomu:

  1. Potrzebujesz linii bazowej. Jeśli poziom podstawowy nie jest stabilny, oszacowanie jest bez znaczenia.
  2. Najlepiej oddolnie. Uzyskaj szczegółowy podział pracy, oszacuj każdy element, a następnie zwiń go na większą liczbę. Planowanie pokera jest tutaj świetną techniką.
  3. Nieprzewidziane dokumenty. Wyjaśnij, gdzie jest dodana ewentualność. Czy jest dodawany do każdego elementu zamówienia? A może według całego szacunku? Czy na konkretne ryzyko? A może nie ma?
  4. Podaj swoje założenia. Sprawdź jak najwięcej, biorąc pod uwagę ramy czasowe.
  5. Podaj wyraźnie, co jest uwzględnione i wykluczone w oszacowaniu. Na przykład, czy opinia jest uwzględniona? Czy uwzględniono opóźnienia techniczne?
darreljnz
źródło
25

Kilka rad od ciemnej strony od tego, który nauczył się na własnej skórze.

Wymagania są niejasne. Nikt nie przeprowadził dogłębnej analizy wszystkich implikacji.

Nie dokonuj oszacowania w tym momencie. Nie wiadomo, ilu żołnierzy potrzeba, aby wygrać bitwę, nie mając pojęcia o liczebności wroga. Oszacowania dokonuje się po rozpoznaniu. Jest tak, chyba że walczyłeś już z tym wrogiem.

Nowa funkcja prawdopodobnie złamie niektóre założenia przyjęte w kodzie i natychmiast zaczniesz myśleć o wszystkich rzeczach, które możesz zmienić.

Twoim obowiązkiem jest uwzględnienie, chyba że oczekujesz od innych wiedzy specjalistycznej w tej dziedzinie.

Masz inne rzeczy do zrobienia na podstawie wcześniejszych zadań i będziesz musiał opracować szacunek uwzględniający tę inną pracę.

To samo, co powyżej, nawet w przypadku nieoczekiwanej pracy, którą tworzy obok ciebie kolega z zespołu slobowego, z prawie nieistniejącą procedurą testową, która powoduje, że kod się zepsuje, czego nie można dokładnie przewidzieć z góry. To prognoza pogody.

Definicja „zrobione” jest prawdopodobnie niejasna: kiedy zostanie wykonana? „Gotowe” jak właśnie skończyłem kodować, czy „gotowe” jak w „użytkownicy go używają”?

Zrozum tutaj wymóg użytkownika końcowego, myśl jak użytkownik. Nie rób tego, co zrobić, jeśli twoi rówieśnicy szacują, że coś się „zrobić” tylko dlatego, że niektóre podstawowe funkcje z w podstawowe workflow, że żaden użytkownik może ewentualnie tolerować to, co uważają za „done” . Pomyśl o tym z punktu widzenia użytkownika, ponieważ to tylko klient, którego szacujesz, zazwyczaj zrozumie. Oszacuj w kierunku pełnych wymagań użytkownika końcowego, a nie w oparciu o wymagania techniczne. I zdaj sobie sprawę, że Twoi klienci pytający o szacunki będą tutaj całkowicie niedokładni w kwestii tego, jak formułują słowa i rozumieją techniczne aspekty tego, co mówisz.

Bez względu na to, jak bardzo jesteś świadomy tych wszystkich rzeczy, czasami twoja „duma programisty” sprawia, że ​​dajesz / akceptujesz krótsze czasy, niż początkowo przypuszczałeś. Zwłaszcza, gdy czujesz presję terminów i oczekiwań kierownictwa.

Nie rób tego! Brzmisz jak zmotywowany pracowity i być może taki, który łatwo poddaje się przymusowi.

Problem w tym, że: powiedzmy, że ty i Joe dokonaliście oszacowań czasu dla tego samego zadania (ale między dwoma oddzielnymi pracownikami, nieświadomymi obu oszacowań naraz). Odważnie oceniacie „jeden tydzień” . W porządku, myślisz, że będziesz pracować ponad 100 godzin tygodniowo, nieodpłatne nadgodziny. Teraz spóźniłeś się trzy dni.

Tymczasem Joe ocenia 5 miesięcy. Myślisz, że to śmieszne, myślisz, że możesz to zrobić w ciągu jednego tygodnia. Ile działa Joe? 10 godzin tygodniowo? ... tyle że kończy na czas dokładnie za 5 miesięcy.

Zgadnij, kto jest postrzegany jako osioł? Zgadza się. Joe wydaje się świetnym pracownikiem, wydajesz się teraz niewiarygodnym. Nie ma to tak wielkiego znaczenia, że ​​mógłbyś osiągnąć jeszcze lepszy wynik w ~ 7% czasu, który zajął Joe. Liczy się to, że miałeś 3 dni wolne od tygodniowego oszacowania.

Nigdy nie błądzić po stronie dokładniejszego oszacowania. Błąd po stronie luźniejszych danych szacunkowych. W Twojej firmie istnieje reputacja i nie będzie ona oparta na długości szacunków prawie tak samo, jak dokładność szacunków. Łatwo jest być dokładnym z oszacowaniem, które jest zbyt długie, po prostu masz więcej czasu na pracę nad problemem i lepsze jego rozwiązanie. Szacunek, który jest zbyt krótki, wcale nie pozostawia miejsca na oddech, albo desperacko go spotkasz, albo wpadniesz w szał.

ChrisF
źródło
2
To świetna odpowiedź, daje mi bardzo przydatne informacje na temat szacowania i rozważania rzeczy, dziękuję
mboullouz
18

"Dwa tygodnie!"

Poważnie. Moje pierwsze oszacowanie to zawsze dwa tygodnie. Ponieważ mam jakiś dziwaczny blok myślowy, który sprawia, że ​​myślę, że wszystko brzmi jak za dwa tygodnie.

Staram się to obejść, naprawdę zastanowić się, ile czasu zajmie, próbując zidentyfikować wszystkie potencjalne punkty problemów i bity, które wyglądają na zbyt czarne, żebym mógł je dokładnie oszacować. I spróbuj rozpoznać, że jeśli moja odpowiedź brzmi „Dwa tygodnie!”, Prawdopodobnie tego nie zrobiłem.

Prawie każdy dobry menedżer, którego nauczyłem się rozpoznawać „Dwa tygodnie!” jako odpowiedź, która wymaga łagodnego ustnego uderzenia alfonsa w odpowiedzi.

BlairHippo
źródło
3
Prawdopodobnie dlatego większość drużyn wykonuje 2-tygodniowe sprinty :)
Cristian E.
17

Jest wpis na blogu, w którym opisano, jak prowadzić rejestr dokładności poprzednich szacunków, a następnie następnym razem, gdy powiesz komuś „to będą dwa tygodnie”, możesz spojrzeć na swoją poprzednią historię i zobaczyć, jak długo to potrwa ostatnio zajęło mi to, że powiedziałeś „to będą dwa tygodnie”.

Sam tego nie próbowałem, ale chciałbym zobaczyć, jak dokładne są moje szacunki.

Richard
źródło
2
Joel's Fogbugz idzie dalej i analizuje twoje dane za pomocą planowania opartego na dowodach. Oznacza to, że każdy programista podaje, ile czasu zajmie każde zadanie, a później, jak długo to zadanie zajęło, i określa, jak dokładny jest każdy programista z ich szacunkami, aby stworzyć krzywą prawdopodobieństwa dla daty zakończenia.
Chris Buckett,
Tak, a następnie zrób trochę GDD - Gauge Driven Development i zrujnuj wszystko
Claudiu Constantin
11

To zależy od organizacji i sposobu wykorzystania szacunków.

Jeśli oszacowanie ma jedynie dać ogólny wyobrażenie o tym, kiedy będzie gotowy, ogólnie mogę dokonać szybkiego oszacowania na podstawie mojego doświadczenia. Często do szacunków dołączam wszelkie niepewności lub możliwe zmiany wraz ze sposobem, w jaki zmiany mogą wpłynąć na inne obszary systemu i wymaganym zakresem testów regresji.

Jeśli oszacowanie stosuje się w odniesieniu do jakiejkolwiek umowy lub w scenariuszu, w którym wymagany jest bardziej precyzyjny harmonogram, wykonuję pełny podział pracy. Jest to więcej pracy i wymaga głębszego przemyślenia na temat projektu i zmian w systemie, ale jest znacznie dokładniejsze, szczególnie w przypadku większych prac.

W obu przypadkach kluczowa jest ciągła komunikacja. Jeśli natrafisz na coś nieoczekiwanego, poinformuj o tym zamiast czekać na termin. Jeśli wymagania nie są jasne, upewnij się, że udokumentowałeś ich zrozumienie i funkcjonalność, którą planujesz dostarczyć. Jest to również pomocne przy wszelkich przyjętych założeniach. Jeśli chodzi o konkurujące priorytety, gdy jedna praca uderza w drugą, jasno określ, jak wpłynie to na harmonogram.

g.
źródło
2
+1 za potrzebę ciągłej komunikacji. IMO, jest to najbardziej przydatna część modelu Agile.
Scott Weldon,
Jest to pierwsza przyzwoita odpowiedź tutaj po prostu dlatego, że jest to jedyna tak dalece (czytam od góry do dołu), która podkreśla „ciągłą komunikację”. Wszyscy inni uważają, że komunikacja szacunkowa jest zdarzeniem jednorazowym. To zła rada i złe podejście do tych rzeczy. Ta odpowiedź jest dobrą radą.
Adam Cameron,
9

Szacunki na co? Małe zadania lub kompletne rozwiązania.

Te ostatnie rzadko robię, ale po prostu zgaduję, dodaj trochę, poproś menedżera, aby dodał trochę i przekształcił go w zakres, z małą notatką obok stwierdzającą, że powyższe jest przypuszczeniem.

Małe zadania - Planowanie pokera Stwierdziłem, że działa naprawdę dobrze (nie idealnie, niektóre zadania 1pt zajęły znacznie dłużej, a niektóre zadania 5-minutowe zajęły minuty, ale ostatecznie wszystko wyrównało się).

mlk
źródło
Tak, planuję pokera!
Sean McMillan
7

Zaprezentuj ofertę w oparciu o to, co wiesz dzisiaj. Użyj Stożka Niepewności, aby określić zasięg wokół początkowych szacunków.

Co tydzień obliczyć, ile pozostało do zrobienia, ponownie oszacuj na podstawie tego, co wiesz. Gdy będziesz mieć wystarczająco dużo próbki, ile pracy wykonujesz każdego tygodnia, podaj 90% przedział ufności dla tego, co pozostało, aby dać (zwykle) zawsze zawężający się zakres dat w miarę postępu projektu i pozostałej pracy (mam nadzieję, że ) kurczy się.

Paddyslacker
źródło
7

Ufnie. Nie potrafię powiedzieć, ile razy spartaczyłem pierwsze spotkanie z klientem, nie zakładając profesjonalizmu przy wycenie. Nawet jeśli wydmuchujesz liczby z powietrza - upewnij się, że zawsze masz jakieś szacunki. To powiedziawszy, uważaj, aby nie ocenić siebie w dziurze. Różne rzeczy wymagają różnej ilości czasu, wysiłku i zasobów. Oto dobry sposób, aby to zrobić:

Im: Ile to będzie kosztowało?

Ja: To zależy od tego, co chcesz, żebym zrobił. Ogólnie rzecz biorąc, ten projekt zaczynam od około X $.

Mosze
źródło
6

Czasami szacowanie staje się ogromnym wyzwaniem dla Ciebie i Twojego zespołu, szczególnie gdy mówimy o szacowaniu projektu oprogramowania.

Kiedyś postanowiliśmy podzielić się naszym doświadczeniem i naszą wiedzą na temat procesu szacowania oprogramowania i zdefiniowaliśmy cztery różne typy szacunków :

  • figura piłki nożnej
  • kosztorys usługi
  • ocena funkcji
  • szacunek składowy

Oczywiście te typy są różne. Ballpark jest często nazywany „guesstimate”. Jest to więc przybliżona liczba lub zakres, który daje ogólne wyobrażenie o kosztach i może pomóc potencjalnemu klientowi zdecydować, czy chcieliby kontynuować dyskusję.

Z reguły klienci potrzebują postaci na boisku na początku projektu. Nasza rada jest taka: omówienie projektu i podanie danych liczbowych powinno być tylko krokiem w kierunku otrzymania oszacowania częściowego (który jest elastyczny, można skorzystać z oszacowania typu częściowego dla całego procesu rozwoju. Nie trzeba dokonywać ponownej oceny od zera, kiedy chcesz dodać, usunąć lub zastąpić funkcje, usługi itp.).

Każdy powinien pamiętać o ryzyku związanym z szacowaniem rozwoju oprogramowania: niedoszacowaniem, przeszacowaniem, całkowitym epickim scenariuszem awarii itp.

Możesz przeczytać więcej na naszym blogu!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Mam nadzieję, że te informacje pomogą ci!

Olha
źródło
5

Zawsze kończę na oszacowaniach, które później uświadamiam sobie, że nie jestem w stanie spełnić. Stało się to niezliczoną ilość razy i zawsze obiecuję, że to się więcej nie powtórzy.

Brzmi jak prośba o zobowiązanie, a nie szacunek. Są to różne rzeczy, ale jeśli potrafisz rzetelnie zarządzać zobowiązaniami, naprawdę pomoże ci to w wiarygodności i karierze.

Kilka porad opartych na moim ~ 10-letnim doświadczeniu:

  • Zawsze podawaj zakres (tj. Dolną i górną granicę). To poinformuje o twoim poziomie niepewności
  • Jeśli masz bardzo dużą niepewność, poproś o odroczenie (np. 1 dzień na wykonanie analizy, a następnie podaj mniejszy zakres)
  • Jeśli zadanie jest zbyt duże, rozbij je i podaj zasięg każdego elementu
jamesfmackenzie
źródło
4

Po pierwsze, jeśli jakieś zadanie zostało mi przydzielone, podzieliłbym je na podzadania. Oszacowałbym czas dla każdego podzadania i prawdopodobnie z podzadaniami mógłbym znaleźć problematyczny obszar, a zatem byłbym w stanie przewidzieć, jak długo to potrwa wziąć do pewnego stopnia.

Ale nadal całe planowanie pomogłoby tylko do pewnego stopnia. Dopiero po rozpoczęciu kodowania można znaleźć dokładne problemy

Gopi
źródło
1

Jeśli wykonujesz wiele projektów dla tego samego szefa lub klienta, możesz próbować oszacować w szerokich pociągnięciach złożoności zamiast tygodni lub miesięcy, być może w rozmiarach koszulek. Zidentyfikuj kilka poprzednich projektów i przypisz im rozmiary S, M, L, XL.

A potem zadaj sobie pytanie: który projekt brzmi podobnie do zakresu? A następnie zamiast odpowiadać „2 miesiące”, możesz odpowiedzieć „brzmi dla mnie jak L” (lub jakakolwiek inna kalibracja dla twojego projektu).

Jest to dość łatwe do zrozumienia i jasne jest również, że w tych domysłach jest wiele niepewności.

Następnie, gdy zmieniają się wymagania, możesz powiedzieć „ta zmiana sprawia, że ​​brzmi bardziej jak XL”.

Moritz
źródło
jest to całkiem sprytne (jeśli wolno ci go używać): wolę iść z podobnym podejściem, ale po prostu uogólniając wartości czasu, więc odpowiem „zajmie to około tygodnia” lub „będzie to kwestia dni ”na coś małego i unikaj odpowiedzi, gdy projekt będzie dłuższy niż miesiąc i potrzebujesz właściwej prognozy
Edoardo
0

Trochę późno, ale kiedy byłem w wojsku, poinstruowano nas, aby użyć PERT do ustalenia szacunków. Wymaga to doświadczenia w swojej dziedzinie i wykonywanego zadania. Był zaskakująco dokładny przy określaniu szacowanego czasu ukończenia podczas konserwacji i naprawy urządzeń elektronicznych (skomplikowanych urządzeń radiowych i łączności satelitarnej), gdzie dowolna liczba rzeczy może być błędna lub znaleziona i wymagała naprawy podczas rutynowej konserwacji. Oszacowania były ważne, ponieważ inne jednostki mogą nie działać, dopóki nie odzyskają sprzętu łączności. Jednym z nich jest darmowy kalkulator PERT online

xtreampb
źródło
1
Ten link Darmowy kalkulator PERT online już nie działa.
krokodilko
@krokodilko I został zbudowany nowe narzędzie PERT, która jest bardziej nastawiona na szacunkach oprogramowania tutaj: estimates.rokkincat.com .
slang