Radzenie sobie z okropnymi szacunkami

Ostatni projekt, nad którym pracowałem, został poważnie niedoceniony przez architekta. Szacunek wyszedł co najmniej 500%.

Niestety zostałem zaangażowany w projekt po podpisaniu szacunku z klientem. Jako starszy programista szybko zdałem sobie sprawę, że specyfikacja funkcjonalna i techniczna. zawierał ogromne luki i niepewności.

W rezultacie czułem się zmuszony do zwołania nadzwyczajnego spotkania z dyrektorami biznesowymi i technicznymi, aby poinformować ich o rzeczywistości. Jako przede wszystkim programista uznałem, że jest to bardzo stresująca i trudna sytuacja. „Biznes” oskarżył IT o niekompetencję i bycie posłańcem, otrzymałem kilka „kul”.

Klient zagroził anulowaniem konta, jednak do tej pory projekt jest nadal niedokończony i nie jestem już z nim bezpośrednio związany.

Architekt był miłym facetem społecznie, ale na podstawie tego odcinka był po prostu niekompetentny lub istniały duże naciski sprzedażowe / biznesowe wpływające na jego ocenę.

A zatem, jako programiści, jakie jest twoje doświadczenie z tego rodzaju sytuacją i jak radziłbyś sobie z nią poradzić?

Długa odpowiedź, ale hej, mam podsumowanie na końcu, więc po prostu przejdź do podsumowania, jeśli nie możesz mieć trudności z przeczytaniem całości!

Jako programista musiałem poradzić sobie z sytuacją dosłownie co drugi projekt, ale dopiero po przejściu do zarządzania projektami nauczyłem się, jak skutecznie sobie z tym radzić. Dla mnie skuteczne radzenie sobie polega na dwóch rzeczach: zarządzaniu oczekiwaniami i zrozumieniu, jak działa szacowanie.

Zacznij od założenia, że ​​nieetyczne jest przedstawianie oszacowania, zobowiązanie się do oszacowania lub jakiekolwiek inne wskazanie dokładności oszacowania, bez możliwości uprzedniego zachowania należytej staranności. Inne osoby polegają na Twojej profesjonalnej zdolności przewidywania wymaganej ilości pracy, a podanie fałszywej informacji zaszkodzi im i ich działalności.

Ale musisz coś dać, w prawdziwym życiu zaciągnąłeś się na zaimprowizowane spotkanie lub spóźniony projekt, a twój przełożony prawdopodobnie da jasno do zrozumienia, że ​​oczekują, że natychmiast wymyślisz jakąś postać lub skomentujesz szacunki, które przedstawili. Tutaj zaczyna się zarządzanie oczekiwaniami.

Wyjaśnij, że błędem byłoby podawanie jakiejkolwiek liczby lub jakiegokolwiek wskazania bez zrozumienia problemu i samodzielnego opracowania liczb. Powiedz, że ich dane liczbowe mogą być całkiem poprawne, po prostu nie wiesz, zanim sam przejdziesz ocenę. I chociaż możesz mieć dobry obraz tego, co jest tam potrzebne i kiedy, powiedz, że wciąż potrzebujesz czasu, aby obliczyć liczby. Jest tylko jeden szacunek, którego mogą oczekiwać od ciebie: kiedy będziesz w stanie podać szacunek. Podaj wszelkie dane liczbowe.

Jako programista nigdy nie bierze odpowiedzialności za (ani nie daje wskazówek, które można interpretować jako akceptację) szacunków innych osób bez możliwości ich wcześniejszej oceny. Jako kierownik projektu jest to zupełnie inna sprawa, ponieważ wtedy masz pewną kontrolę nad procesem szacowania: sposób, w jaki szacunek jest uzyskiwany i weryfikowany, i musisz polegać na innych ludziach, aby wykonać rzeczywistą pracę i musisz ją wykonać na pewno są popełnione.

Nigdy nawet nie komentuj szacunków, nie mogąc zachować należytej staranności. To jest etyczne. Prawnik lub lekarz jasno stwierdzą, że nie mogą udzielić żadnej porady, chyba że klient (lub pacjent) zastosuje się do ich zasad i najpierw przejdzie procedurę oceny. Podobnie masz prawo do zadawania pytań przed wydaniem profesjonalnej opinii.

Druga część dotyczy sposobu szacowania. Sugeruję zbadanie różnych podejść do dokonywania szacunków i działania procesu szacowania, w tym branż innych niż tworzenie oprogramowania (produkcja, rynki finansowe, budownictwo). To da ci wyobrażenie, czego można oczekiwać od twojego szefa lub klienta i, co dziwne, pomoże w dokładniejszym przewidywaniu ilości pracy. Poprawi to twoją zdolność do obrony swoich szacunków i będziesz musiał bronić liczb za każdym razem, gdy różnią się one od tych przedstawionych przez architekta lub sprzedawcę.

Zwykle działa to tak, że twoje oszacowanie jest najpierw skanowane w poszukiwaniu dziwnie wyglądających lub stosunkowo dużych przedmiotów. Dlatego bądź przygotowany na obronę czegokolwiek o „niestandardowej” nazwie. Podziel także większe zadania, aby wszystkie zadania miały ten sam rząd wielkości, tzn. Jeśli większość zadań zajmuje 2 dni, a jedno zadanie ma 10 dni, przygotuj się na wywiercenie.

Wyjaśnij, co jest zawarte w każdym zadaniu, najlepiej rozdzielić testy deweloperskie i jednostkowe zamiast po prostu mieć programistę i przekonać kogoś, że zawiera również dokumentację. Oczywiście w ten sposób będziesz musiał sporządzić dość drobiazgowe oszacowanie.

Następnie następuje wiercenie. Ponieważ przegląd długiego podziału pracy jest dość trudny, twój klient lub szef prawdopodobnie zastosuje inną strategię: skoncentruj się na losowym fragmencie, o którym może coś wiedzieć, i analizuj, dopóki nie zdołają zdyskredytować całego oszacowania lub nie będą zadowoleni z twojego odpowiedzi Wiarygodność całego oszacowania może zależeć od losowej próby! Dlatego po raz kolejny potrzebujesz czasu, aby starannie go przygotować, uwzględnić tylko odpowiednie fragmenty, wykluczyć dodatki lub przenieść je do sekcji „miło mieć” i przemyśleć, jak będziesz bronić postaci.

Oczywiście możesz być konsekwentny w swoim podejściu, tj. Szacować na podstawie funkcji, liczby ekranów itp. Lub mieć różne podejścia, ale w każdym razie bądź przygotowany na obronę, dlaczego wybrałeś określony sposób szacowania. Przygotuj się również, aby wyjaśnić, dlaczego twoje liczby różnią się od tych, którzy próbują przewidzieć ilość wymaganej pracy.

Poznaj oczywiste oznaki słabych danych szacunkowych:

• Wypełnione ogólnymi ogólnymi zadaniami, skopiowane z szablonu (dobre oszacowania są specyficzne dla danego zadania).

• Zgrubne oszacowania (tj. Zadania dłuższe niż kilka dni).

• Szacunki wykonane na wczesnym etapie projektu lub przez osobę, która może nie mieć faktycznej wiedzy na temat wymagań lub pracy.

• Szacunki opracowane przez osoby inne niż faktyczni wykonawcy

• Niejasne szacunki (niejasne, co jest uwzględnione i, co równie ważne, wyłączone).

• Zasadnicza różnica w porządku wielkości zadań.

Ćwicz ocenianie szacunków innych osób i wiercenie liczb bez faktycznej wiedzy o szczegółach implementacji. Pomoże to w podtrzymaniu twojego roszczenia przez dodatkowy czas po naciśnięciu prośby o potwierdzenie szacunku innej osoby, gdy nie masz twardych dowodów.

Podsumować:

• Nie zobowiązuj się do okropnego lub żadnego szacunku w tej sprawie, zanim będziesz miał okazję dołożyć należytej staranności.

• Wyjaśnij od samego początku, nie pozwól nikomu zakładać, że jest inaczej, i zinterpretuj swoje milczenie jako znak zgody.

• Dowiedz się, jak działają różne metody szacowania, ich praktyczne zastosowanie i zalety, w tym te poza programowaniem.

• Przygotuj się do obrony swoich szacunków.

• Dowiedz się, jak oceniać szacunki innych osób, aby nie musieć angażować się w bardzo niedokładne dane.

Nie da się przewidzieć przyszłości. Wymaganie prognozy („oszacowania”) oznacza po prostu kłopoty. Wszyscy to robią i wszyscy się mylą.

Twoja ocena „500%” jest prawdopodobnie tak samo błędna, jak szacunek architekta. W końcu „… jak dotąd projekt jest nadal niedokończony…” Nie ma tu dostępnych faktów.

Nikt nie zna „poprawnej” odpowiedzi. I dopóki się to nie skończy, nikt się nie dowie.

I nawet po jego wykonaniu, „oryginalne” oszacowanie (z kontrolą zmian lub bez) może nie korelować z niczym, co faktycznie zostało osiągnięte.

Szacowanie jest pułapką - to gra oparta na sfałszowaniu. nie możesz wygrać, nie możesz osiągnąć progu rentowności i nie możesz nawet wyjść z gry.

Edytować

Radzenie sobie ze złymi szacunkami; Oszacowanie „starszego”, które wydaje się nieprawidłowe .

Tu jest. Nie zgadzasz się z szacunkami innej osoby. Albo pominęli coś, co uważasz za konieczne; mieli inny zakres pracy niż ty lub mieli inną wydajność. Ponadto, jeśli oszacowanie jest czymś więcej niż wysiłkiem, mają one inną podstawę kosztów. Z których wszystkie są sporne. Spytaj więc o szczegóły prowadzące do oszacowania. Nie kwestionuj ogólnej liczby - w podsumowaniu nie ma prawdziwych informacji . Sprzeciwiaj się poszczególnym szczegółom, które stanowią podstawę oszacowania. Dowiedz się, co myśleli.

Jest równie prawdopodobne, że twoje założenia są tak samo błędne, jak ich założenia. Równie prawdopodobne.

Zapytany o oszacowanie .

1. Mylisz się

   1. Kłamią na temat zakresu pracy.

   2. Nie znasz wydajności zespołu.

   3. Każda nowa technologia została wprowadzona w błąd.

2. Nie możesz po prostu wrzucić paddingu, aby przypadkowo zakryć te rzeczy. W rzeczywistości nie wiesz i nie masz podstaw do „szacowania”. To tylko zgadywanie. Pokonaj to.

Zasada 1: Ponieważ zgadujesz tylko, zgaduj w małych krokach.

Podstawowym pytaniem w każdej „szacunkowej” sytuacji nie jest przewidywanie przyszłości. Nie można tego zrobić z dokładnością w okresach znacznie dłuższych niż tydzień lub dwa. Ogranicz swoje prognozy do horyzontu czasowego, w którym masz bezpośrednią i bezpośrednią szczegółową wiedzę. Na przykład następna wersja.

Podstawowym pytaniem jest - zwykle - podejmowanie decyzji przez nabywców lub klientów. Pytanie nie brzmi „co będzie kosztować?” - to niekompletne. Pytanie brzmi: czy inwestycja będzie tego warta? Prawdziwe pytanie brzmi bardziej: „jaki jest stosunek kosztów do korzyści” i „kiedy powinniśmy przestać wydawać, ponieważ więcej inwestycji nie zapewni większego zwrotu?” To są prawdziwe pytania.

Zasada 2: Wspieraj decydenta informacjami faktycznymi.

Większość ludzi najlepiej obsługuje podejście zwinne. Pierwsze wydanie - za miesiąc - zajmie 5 osób × 4 tygodnie i przyniesie funkcję X, która naprawia straty w wysokości 1 mln USD / dzień, oraz funkcję Y, która naprawi brakujące szanse na 200 000 USD / tydzień. Masz szczegółową wiedzę o tym, co robisz, więc ta prognoza ma sens. Wydanie po tym jest trochę mgliste.

Wydanie za rok jest tak daleko w przyszłości, że wszelkie prognozy są tylko losowe. Nie przejmuj się szczegółami niczego więcej niż 6 miesięcy w przyszłości, po prostu stosuj proste zasady.

Kiedy pytają, co to jest TCO, musisz być szczery. „Całkowity koszt występuje, gdy przestajesz płacić za programowanie. Do momentu, w którym przestaniesz płacić, zawsze poniesiesz koszty”.

Prawdziwe pytanie brzmi: „jakie problemy próbujesz rozwiązać?” lub „jakie nowe możliwości wykorzystujesz?” i „ile to jest warte?”

Zasada 3: Spraw, aby oprogramowanie było tańsze niż problem, który ma rozwiązać.

Jeśli nie znasz dobrze problemu, oszacowanie zostanie przeprowadzone w celu dopasowania do percepcji. Staraj się tego unikać.

Na prawdopodobieństwo . Z wyjątkiem wyniszczającej choroby lub wypadku, żadna część rozwoju oprogramowania nie jest uzależniona od rzeczywistych prawdopodobieństw. „Ryzyko” to po prostu złe zarządzanie. Zasadniczo w formie „nie wzięliśmy pod uwagę złożoności potrzeb biznesowych A lub technologii B”. Częściej w formie „gdy dowiedzieliśmy się więcej o problemie lub technologii, zmieniliśmy harmonogram”, co jest karane jako „pełzanie zakresu”.

Nie ma prawdopodobieństwa uczenia się i zmiany zakresu. To jest pewność.

W sprawie planowania . Jest „planowanie” i „szacowanie”. Planowanie, co zbudować, to jedna rzecz, najlepiej reprezentowana jako lista kontrolna lub wykres zależności. „Szacowanie” wymaganego wysiłku opiera się na niepoznawalnych czynnikach.

„Planowanie” to zwykłe dobre zarządzanie.

„Szacowanie” wymaga niepoznawalnej wiedzy. Aby dokładnie oszacować wysiłek, musisz mieć wgląd w produkt na poziomie kodu źródłowego i musisz wiedzieć, która osoba napisze ten kod źródłowy i jakie błędy popełni dana osoba. Ponieważ nie możesz tego wiedzieć, wszelkie szacunki muszą być błędne. I często źle wprowadzają w błąd i dlatego są bezużyteczne.

Jeśli szacunek został odrzucony o 500%, a projekt nadal postępował, jaką wartość ma szacunek?

Żaden. Wszystko, co zrobili, sprawiło, że ludzie byli nieszczęśliwi. Ale projekt i tak poszedł do przodu.

Ponieważ nikt nie widzi przyszłości, prawidłowe oszacowanie nic nie znaczy. Przydaj się, pomagaj ludziom podejmować decyzje.

Horyzont powinien być krótki. Dostarcz wartość jak najszybciej. Utwórz plan, który pozwala klientowi anulować projekt w dowolnym momencie i nadal mieć wartość.

Nie pozwól, aby plan stał się jedyną „świętą prawdą” w projekcie. Dostarczalna funkcjonalność jest święta. Wszystko inne powinno się zmienić wraz ze zmianą rezultatów.

Nie pozwól, aby plan przekroczył wartość, którą tworzy.

Jeśli nie ma wystarczająco dużo czasu, nie ma wystarczająco dużo czasu. Zresztą nie ma magicznego rozwiązania, które mogłoby zakończyć projekt. Moim zdaniem zrobiłeś to, co mógłbyś wyrazić. Okazało się, że musieli to znaleźć na własnej skórze. Tak to zwykle bywa. Mamy nadzieję, że architekt i zarząd wyciągnęli wnioski z błędów i nie robią tego ponownie. Jeśli jest to normalne, gdy kierownictwo jest zbyt ignoranckie, aby wysłuchać argumentów i podjąć odpowiednie działania, dobrym pomysłem może być poszukiwanie innych projektów lub innej firmy.

„Deweloperzy to rzemieślnicy, a najgorszą rzeczą, jaką możesz zrobić rzemieślnikowi, jest dostarczenie mu gównianego produktu”. Sławny cytat skądś, ale nie pamiętam skąd.

Uczciwość powinna być zawsze honorowana. Byłem na końcu „wizji architekta”, a kiedy deweloper przyszedł do mnie z tragiczną wiadomością, że całe rozwiązanie nie zadziała, poszliśmy do jednostek biznesowych i odbyliśmy okropną rozmowę. Następnie deweloper przedstawił nowe oszacowanie, które obejmowało 80% funkcjonalności, ale dostarczyło go na czas i zgodnie z budżetem.

Jednostki biznesowe przekonał fakt, że deweloper rozmawiał z nimi zgodnie z prawdą, potwierdził niedociągnięcia jego firm i pracował jak pies. Ten facet pracował dla nas przez ostatnie 7 lat, ponieważ zawsze był uczciwy.

Cały scenariusz jest tak rzadki - w większości przypadków jednostki biznesowe uważają, że jesteś idiotą, ponieważ nie jesteś w stanie tego zrobić. Musisz odszukać tych klientów, którzy nie działają w ten sposób, ponieważ na dłuższą metę zarobisz na nich więcej, niż próbowałbyś zadowolić kretynów, którzy chcą cię traktować jak palant.

W odniesieniu do architektów, którzy nie znają swojej dziedziny, unikaj ich jak zarazy. Miałem mentora, który wzmacniał ze mną w surowy sposób - „To. Nie jest. Bo. Ćwicz!” Tolerowałby błędy tylko wtedy, gdy popełniłeś je wcześniej, poprawiłeś i nigdy więcej nie popełniłeś. Firmy, które dopuszczają nietechniczne, niedoświadczone osoby na stanowiskach wobec klientów, ponieważ mogą „komunikować się”, zasługują na wycofanie się z działalności.

Raz spotkałem się z tą sytuacją. Projekt zabrakło harmonogramu, ponieważ firma zmieniła wymóg, pojawiła się luka komunikacyjna, a kierownictwo wyższego szczebla chciało, aby projekt był realizowany na czas. Co gorsza, jeden facet, który pracował nad tym projektem został wyciągnięty, aby wypełnić kolejną lukę, która miała większy priorytet.

Mój zespół spędzał noce, aby dokończyć projekt. Późną nocą około 3:00 rano (pracowałem 19 godzin bez przerwy) wysłałem e-mail do moich menedżerów, aby coś z tym zrobić.

Następnego dnia mieliśmy spotkanie (tylko deweloperzy). Cały zespół przyszedł w weekend i przetestował projekt jeszcze przed jego ukończeniem. Niewielu dołączyło do zespołu, wykonując szybkie poprawki. W końcu udało nam się dostarczyć projekt z wysiłkiem całego zespołu (nie tylko zespołu projektowego). Postępowaliśmy tak samo w przypadku innych projektów.

Cały zespół (nawet jeśli nie jest zaangażowany w projekt) przetestował aplikację i pomógł w szybkich naprawach błędów.

Uwaga: Mój zespół składa się z około 25 osób, które ponownie miały podgrupy pracujące nad różnymi projektami.

Moja jedyna rada brzmiałaby: „Porozmawiaj z menedżerem. Powiedz im stanowczo, że projekt nie może zostać dostarczony na czas. Daj też alternatywę. Menedżer zawsze oczekuje, że dziecko zostanie dostarczone na czas, bez względu na wszystko :)”

Chociaż firmy często nie lubią prawdy, że rzeczy trwają znacznie dłużej, niż się spodziewano, wolą być jeszcze mniej zaangażowani. Im szybciej poinformujesz kogoś, jak długo to naprawdę potrwa, tym szybciej każdy będzie mógł zaplanować na podstawie okoliczności. Choć początkowo może to być trudny okres, na dłuższą metę będzie łatwiej. Zrób to dobrze za drugim razem i buduj na wypadek.

Chciałbym podkreślić jeden kluczowy punkt w kontaktach z zarządzaniem: menedżerowie doceniają rozwiązania.

Jeśli musisz zgłosić się do kierownictwa z problemem (np. Oszacowanie jest niezwykle nierealne), ciężko pracuj z wyprzedzeniem, aby znaleźć alternatywne sposoby rozwiązania tej sytuacji. Na przykład możesz wykonać analizę Pareto (reguła 80/20), aby zrozumieć wartość systemu, możesz wykonać priorytetowy przypadek wycinania funkcji (przynajmniej od pierwszego wydania), aby skoncentrować się na tych o maksymalnej wartości biznesowej, możesz poszukać alternatyw (projektów open source itp.), które są odpowiednimi zamiennikami niestandardowych części systemu itp.

Nie ma wątpliwości, że pięciofuntowa torba nie pomieści dwudziestu pięciu funtów piasku, ale częścią pomagania kierownictwu w przyswojeniu nieprzyjemnej wiadomości jest dostarczenie dowodów na to, że jesteś zaangażowanym sojusznikiem.

Możesz być zainteresowany tym artykułem IEEE, o którym pisałem wcześniej na blogu . Oto najważniejsze informacje.

• Jednym z największych powodów niepowodzenia projektu jest zbyt optymistyczne oszacowanie.
• Jednym z głównych powodów, dla których szacunki są zbyt niskie, jest zbyt duża presja ze strony szczytu, aby dostarczyć je wcześnie.
• Drugim jest pełzanie zakresu podczas wdrażania bez ponownej wizyty szacunków.

Po pierwsze, nieformalnie porozmawiam z danym architektem i przejrzę listę waszych problemów z jego oceną, i spróbuję przekonać go, gdzie są problemy, i różnicę czasu, jaką zajęliby na rozwiązanie.

Potem spróbuję pójść do twojego przełożonego / kierownika projektu i przedyskutować to z nim / nimi.

Pod koniec dnia architekt podał SZACUNKI, więc mogą ulec zmianie, a czasem w dużych ilościach, o ile zostaną o tym poinformowani, aby mogli tworzyć alternatywne plany, takie jak wprowadzenie produktu na rynek. fazy, zmniejszając jego funkcjonalność lub w inny sposób.

Na koniec dnia, gdy już to zrobisz, nie jesteś już odpowiedzialny.

Zdecydowanie nie powinieneś iść bezpośrednio do klienta lub szefa architekta, to tylko promuje złe uczucia i prawie zawsze otrzymasz część winy.

Najlepszą rzeczą, jaką możesz zrobić, to wyciągnąć wnioski ze swoich (nie twoich osobiście, w tym przypadku) złych szacunków. Należy się nauczyć, aby nigdy nie pozwalać komuś innemu niż osobie wdrażającej pomysły oszacować, ile to zajmie. Prędkości programistów mogą się różnić o rząd wielkości, więc oszacowanie dla kogoś innego jest prawie niemożliwe.

Czuję twój ból ... Nie jestem pewien, jak poradzić sobie z tą frustracją :(

https://stackoverflow.com/questions/541873/developing-on-for-a-moving-target

W przeszłości miałem do czynienia z menedżerami projektów, którzy obcinali szacunki, aby uzyskać dane, które zdaniem działu handlowego były w stanie zapłacić klientowi. Kierownik był zdania, że ​​lepiej błagać o wybaczenie niż prosić o pozwolenie.

To dlatego programiści nauczyli się wypełniać swoje szacunki, ponieważ wiedzą, że zostaną odcięci przez swoich menedżerów. Więc jeśli podwoisz szacunek i dodasz 30%, masz dużą szansę na uzyskanie rozsądnego harmonogramu.

Klienci zawsze chcą, aby było tańsze, a jeśli przyjdziesz do nich z rozsądnym szacunkiem, będą się na to drażnić i zażądają obniżenia kosztów lub pójdą. Ale jeśli pójdziesz za wysoko, po prostu będą chodzić bez dyskusji („Rozważymy to i skontaktujemy się z Tobą”).

To gra zarządzanych oczekiwań.

Problem nie polegał na tym, że pierwotne szacunki zostały wydane - to, że kierownictwo ci nie uwierzyło.

Najlepszym sposobem na skłonienie kierownictwa do podjęcia decyzji jest:

1. Zarysuj problem wraz z dowodami na jego poparcie; i
2. Zapewnij im różne rozwiązania do wyboru (w kolejności od najmniej preferowanej do najkorzystniejszej).

W przypadku (1) implementacja Scruma i śledzenie wartości rzeczywistych na podstawie podejrzanych szacunków działa dobrze, aby poprzeć twoje roszczenia.

W przypadku (2) jedną z moich opcji byłoby „Opracowanie priorytetowej listy funkcji z klientem (inaczej Backlog produktu w kategoriach Scrum)”. Byłoby to trudne w organizacjach o stałej cenie lub biurokratycznych, ale jest to możliwe .

Mam nadzieję, że to pomaga!

Ja (jak jestem pewien prawie każdego, kto koduje) wczuwam się. Moja ostatnia firma była dość okropna z tego powodu - faceci ze sprzedaży wchodzili i sprzedawali projekt, a potem wchodzili, oglądali prognozy i po prostu się śmiali.

Jak wspomniał Tomh - dzień ma tyle czasu. Nawet jeśli nie śpisz.

Myślę, że trzy rzeczy.

W większości przypadków wystarczy zarządzać oczekiwaniami klienta i zachować przejrzystość . Bądź szczery z tym, co możesz zrobić i pokaż, co zrobiłeś - wszystko. Jest to szczególnie prawdziwe, jeśli otrzymujesz wymagania, które są zbyt grubo podzielone (jak wspomniał Totophil). Jeśli widzą ilość pracy, którą musiałeś wykonać, mogą zobaczyć, jak źle oszacowano. Jeśli widzą produktywność i postęp, jest to ważniejsze niż cokolwiek z mojego doświadczenia.

Myślę, że oprócz zarządzania oczekiwaniami i zachowania przejrzystości w pracy, drugą dużą rzeczą jest zarządzanie zakresem . Istnieje duży obszar między byciem analnym / ofensywnym w byciu nazistą a zakryciem własnego ogona. Jeśli ktoś chce tej dodatkowej funkcji lub funkcjonalności - zaakceptuj ją! A następnie dać im stosunkowo dokładne oszacowanie, ile czasu, że doda do projektu (lub następnego wydania). Plusem tego jest nie tylko nie zapychanie się do innej 80-godzinnego tygodnia pracy - masz jakiś pad w tym szacunków też do możliwie dogonić drugiego.

Powodzenia!

Nigdy nie bierz niczego na siebie, nie widząc ani nie rozumiejąc. Jeśli klient lub twój własny mgmt nie są w stanie cię na to pozwolić, nie przygotowują cię do sukcesu.

Był to (i często jest) niezrozumienie szczegółów, danych i ich interakcji w obrębie budowanej aplikacji. Przyjmuje się założenia, zamiast zadawać pytania, znajdować odpowiedzi i przybijać wszystko.

Jedną rzeczą, którą często powtarzam moim klientom, jest to, że jeśli zamierzasz mnie powiesić, przynajmniej pozwól mi powiesić się na własnej linie lub zastrzelić mnie własną bronią i kulami, a nie kimś innym.

Posiadanie obrotowych drzwi osób próbujących je rozwiązać będzie dla nich znacznie gorsze.

Nierealistyczne, złe planowanie i brak przewidywania mogą być sygnałem problemu dotyczącego całej organizacji, w którym to przypadku lepiej się przyzwyczaić lub przejść dalej.

Najpierw zastanów się nad możliwością przeszacowania zakresu projektu. Sprzedawcy i architekci wyolbrzymiają swoje rozwiązania. Nie bierz ich za dobrą monetę; prawdopodobnie oczekują, że wymyślisz mniej niż obiecał klientowi.

Chciałbym tutaj poświęcić tyle czasu, ile mam, i spędzić go tak mądrze, jak potrafię. Ustal priorytety klienta i zrealizuj je. Dziewięć na dziesięć razy klient będzie zadowolony, że jego najważniejsze priorytety zostały spełnione, i przeoczy 80% niewykonanej pracy.

Ostatnią rzeczą, którą chcesz zrobić, jest zwoływanie spotkań awaryjnych i oskarżanie ludzi o bycie złym. Mówisz:

„daj im poznać rzeczywistość”

ale rzeczywistość to tylko opinia! Odpręż się, wykonuj swoją pracę i wydawaj swój kapitał polityczny na rzeczy, które są dla Ciebie ważne . Jak promocja, więcej pieniędzy, więcej wakacji.

Twój szef handlujący promocją za to, że naprawdę ciężko pracujesz nad klientem, ma sens. Wchodzisz w szał w imieniu klienta, nie.

Jedną rzeczą do zapamiętania jest to, że szacunki nie uwzględniają pełzania zakresu ani nieuniknionych opóźnień (lub problemów opartych na tym, że klient nie daje ci wahania, jak twierdzą, że na przykład plik informacji w określonym formacie).

Nauczyliśmy się przesuwać zarówno szacunek, jak i termin, za każdym razem, gdy zdarzy się jedna z tych rzeczy. Dodaj nową funkcję, uzyskaj nowy kosztorys i nowy termin. Nie podałeś potrzebnych informacji na temat uzgodnionego terminu, uzyskaj nowy termin. Podaj informacje, ale spraw, aby były niekompletne lub nieprawidłowe lub w jakikolwiek inny sposób niż obiecany, wyślij nowy kosztorys i termin, zmień wymagania dotyczące uzgodnionych funkcji, uzyskaj nowy kosztorys i termin. Przestań pracować nad projektem, ponieważ klient chciał, abyś pracował nad wyższym priorytetem, wyślij nowy termin (i być może nowy szacunek, ponieważ będzie czas nadrabiania zaległości, jeśli projekt zostanie wstrzymany na długo).

Jeśli pierwotne oszacowanie pochodzi spoza grupy deweloperskiej i nie zostały z nim skonsultowane, to kiedy je dostaniesz, przygotuj własne oszacowanie (na szczegółowym poziomie wszystkich zadań, które według ciebie będą miały - na znacznie wyższym poziomie szczegółów niż szacunek, który otrzymałeś) i natychmiast podaj go w górę łańcucha i zapytaj, co powinieneś wyciąć, aby spełnić szacunek, który otrzymałeś.

Jeśli odpowiedź jest niczym, nalegaj, aby klient został poinformowany o nowej wycenie, teraz, gdy przyjrzeliśmy się tej sprawie bardziej szczegółowo. Jeśli zarząd nadal nalega, aby klient zapłacił tylko za X godzin, zapytaj go, kto zapłaci za resztę godzin opracowywania, ponieważ opisanej ci pracy nie można wykonać krócej niż szacujesz. Może się okazać, że firma jest gotowa podjąć działania i sami zapłacić za godziny.

Jeśli nie będą chcieli czerpać tego z zysku i nie powie klientowi, że potrzebują więcej godzin, a firma nie poprze szczegółowych szacunków personelu programistycznego nad sprzedażą ”- według nas klient aby wygrać projekt "oszacuj, bierzesz udział w marszu śmierci, a najlepszym rozwiązaniem jest jak najszybsze wyjście. Możesz wskazać, że klient będzie szczęśliwszy wiedząc, że projekt potrwa jak najszybciej, niż będzie to możliwe, gdy spędzisz 50 godzin, za które zgodzili się zapłacić, i nie są nawet bliscy ukończenia z 500, których naprawdę potrzebujesz. Przypomnij im, że zbyt optymistyczne szacunki są jednym z największych predyktorów niepowodzenia projektu. Nie będzie działać z tego rodzaju firmami, ale być może w końcu zatoną, jeśli powtórzysz to wystarczająco dużo razy.

Biorę również pod uwagę udoskonalenie szacunków. Mam na myśli „jak widzę teraz, ten projekt zajmie X roboczogodzin”. Po 20-30% ponownie oszacuję i tak dalej.

W końcu w jaki sposób narzędzie do pobierania plików dokonuje oszacowania? To stale go udoskonala.

Myślę, że za mało estymatorów nie kładzie wystarczającego nacisku na fakty: „Oszacowanie polega na tym, że prosisz mnie o matematykę i zgaduję, jak w przydatny sposób przewidzieć przyszłość” oraz „Zaangażowanie, które podejmujemy, jest całkowicie niezależne od matematyki, którą wykonujemy dokonać oszacowania; możemy zgodzić się na wykonanie głupich prac, zgodzić się na rzeczy, które prawdopodobnie nie zakończymy, ale żadna z nich tak naprawdę nie zmienia matematyki rozwiązania ”i„ Możemy wykonać metodologie rozwoju, które nie są gigantyczne partia funkcji A zostanie ukończona przed datą B, co znacznie zmniejsza prawdopodobieństwo awarii ”

Do wielu szacunków użyto języka negocjacji. Muszą być sformułowane w języku matematyki i mówić o niejasnościach matematyki .

Estymator nie może nic zrobić, aby rzeczywistość zakrzywiła się woli przedsiębiorców negocjujących go. Jego jedynym zadaniem jest sprawienie, by przestali próbować.