Project Manager, który chce zablokować oszacowanie czasowe z podpisaną umową

Podczas poprzedniego zatrudnienia kierownik projektu (PM) nie był zadowolony z czasu dostarczenia kodu do projektu, w którym byłem. Kierownik projektu powiedział mi, że premier rozważa podpisanie przeze mnie umowy o zablokowaniu moich oszacowań czasu podanych dla zadań i terminów dostaw.

Sytuacja w projekcie polegała na tym, że pracowaliśmy z nowymi technologiami, bazą kodu, standardami kodowania i bardzo podatnymi na zmiany wymaganiami. Uczyłem się nowych rzeczy i stosowałem je najlepiej, jak mogłem, w zakresie wymagań, które ciągle się zmieniały. Wymagania w trakcie iteracji wzrosły 2-3 razy, a moje szacunki ukończenia wzrosły około 5-8 razy. Jedyne, co się nie zmieniło, to szacunki i terminy dostaw.

Tak, ostatecznie nie dotarłem do większości terminów. Pracowałem nad kilkoma nowymi technologiami, nad którymi nikt inny z całego zespołu programistów nie byłby w stanie pomóc, ponieważ nie mogliby się z tym zapoznać. Przynajmniej nie łatwo.

Wydawało mi się wtedy, że premier chciał, aby jego liczby się sumowały - i dlatego chciał, żebym podpisał umowę, aby „zapewnić”, że zawsze dostarczę działający kod na czas. Podejrzewam, że po podpisaniu umowy premier mógłby użyć go przeciwko mnie, gdybym nie był w stanie dostarczyć go na czas.

Wierzę, że to, co stało się potem, było tym, że inni menedżerowie projektów i / lub kierownicy projektów bronili mnie i nie pozwolili na to.

Moje pytanie brzmi: czy powinno to podnieść czerwoną flagę na temat menedżera? Czy menedżer często stosuje oszacowania czasu dla programisty z podpisaną umową? Lub w tym przypadku spróbuj.

Pamiętaj, że byłem pracownikiem zatrudnionym na pełny etat, a nie niezależnym konsultantem.

Aktualizacja : Chcę dodać, że co tydzień podawałem nowe prognozy, ale wygląda na to, że pierwotne prognozy i daty dostawy były tym, na czym ustalono premiera.

Moje pytanie brzmi: czy powinno to podnieść czerwoną flagę na temat menedżera?

Tak . Oznacza to, że nadszedł czas, aby zaktualizować swoje CV / CV i zacząć szukać nowej pracy. Lub oznacza to, że Twój menedżer zacznie z tobą grać w bardzo paskudne gry .

Czy menedżer często stosuje oszacowania czasu dla programisty z podpisaną umową?

Nigdy nie słyszałem o stosowaniu tego wobec pracownika.

Szacowanie czasu i wysiłku jest zawsze trudne. Zwłaszcza, że ​​nasz zawód jest pełen nadmiernego optymizmu. Istnieje kilka systemów szacowania, które mogą pomóc w oszacowaniach w przyszłości, ale muszą one zbierać historyczne statystyki od ciebie. Jednym z nich jest PSP . Kolejne to punkty funkcyjne . Wielu programistów nie lubi żadnego z nich, a znajdziesz przeciwko nim bardzo mocne opinie.

Kluczową trudnością w oszacowaniu czasu i wysiłku jest brak sprzężenia zwrotnego w naszej heurystyce szacowania. Jednym z kluczy jest zapisanie tego, co według ciebie jest oszacowaniem i jakich parametrów użyłeś do oszacowania. Następnie, w oparciu o to, co faktycznie zrobiono, porównaj to z tym, co myślałeś, że zrobisz. I użyj tego, aby zmodyfikować parametry szacowania. W inżynierii nazywamy to „ sprzężeniem zwrotnym ”.

Tak, to absolutnie powinno zabrzmieć dzwonkami alarmowymi.

Gdybym był na tym stanowisku, dla własnej rozrywki poprosiłbym kierownika o podpisanie umowy zamrażającej wszystkie wymagania. Wyobrażam sobie, że kierownik prawdopodobnie zwolniłby kaucję. Potem odejdę.

Cóż, to proste. Po prostu powiedz swojemu menedżerowi, że podpiszesz się, aby zablokować swój szacunkowy czas, kiedy podpisze się, aby zablokować specyfikację. Ponieważ nie możesz, z pewnością podaj oszacowania czegoś, co jest nieznane. Pełna specyfikacja projektu przed rozpoczęciem, bez zmian - i możesz go ukończyć na czas :)

Jedna zmiana w specyfikacji spec => kontrakt jest nieważna. Prawdopodobnie pierwszy dzień upłynie po 10 minutach :)

Tak, to czerwona flaga. Mówi ci to, że menedżer nie rozumie, jak zarządzać ryzykiem w projektach oprogramowania. To, co powinien zrobić, to dowiedzieć się, co dokładnie spowodowało opóźnienie na pierwszym miejscu, a następnie rozpocząć instrumentowanie procesu skutecznego zarządzania ryzykiem harmonogramu, które nieuchronnie wydarzy się podczas projektu oprogramowania.

NIGDY w żadnych okolicznościach nie podpisałbym umowy z moim kierownikiem gwarantującym harmonogram. Inni wspominali, że podpisał blokadę specyfikacji. To moim zdaniem nie wystarczy. Nie uwzględnia to nieprzewidzianych trudności z narzędziami lub technologią, niekompletnych lub złych projektów, wyników innych członków zespołu itp.

To nie jest czerwona flaga, to głupota na miarę broni.

Jeśli szacunki i terminy są konsekwentnie przekazywane, racjonalnym rozwiązaniem jest identyfikacja przyczyn i usprawnienie procesów.

Jeśli obwiniasz i kopiesz konia, ponieważ nie wiesz, dokąd zmierzasz, nie zdziw się, jeśli koń cię ugryzie i ucieknie!

Podczas gdy kierownik był niezgodny z jego żądaniem. Nie jest w pełni winny. Jeśli pracujesz na całkowicie nieznanym terytorium, nie ma nic złego w powiedzeniu „nie wiem”. Dopiero po chwili uświadomiłem sobie, że odpowiedź „nie wiem” jest całkowicie akceptowalną odpowiedzią, więc wiem, ile trzeba powiedzieć. Ale jeśli naprawdę nie wiesz, to jest odpowiedź. A jeśli się na to nie zgadzają, poproś ich, aby oszacowali, ile pieniędzy zajmie stworzenie stosu tak wysokiego, jak Wieża Sears (Make Willis). I czy byliby skłonni podpisać umowę, płacąc ci każdy grosz, który byli zwolnieni?

Każdy kierownik projektu warty swojej pensji powinien wiedzieć, że niektóre rzeczy nie pasują ładnie i ładnie w arkuszu kalkulacyjnym. Czasami rzeczy są wykonywane, gdy są gotowe. Myślę, że dobrze sobie radzisz, robiąc postępy w tym, co zrobiłeś. Po prostu przestań podawać aktualizacje numerów.

Kolejnym ćwiczeniem jest rozbicie dużego zadania na mniejsze, bardziej przewidywalne jednostki. To ćwiczenie pomoże ci lepiej zrozumieć, co musisz zrobić. Sprawdź Steve McConnell za Oszacowanie Software i Stephen Withall w wymaganiach programowych Patterns uzyskać wskazówki dotyczące uszkodzi zadania i odkrywanie ukrytych potrzeb, odpowiednio.

W przybliżeniu nie strzelaj z biodra. Poświęć trochę czasu, aby to rozbić. Szacowanie dużej liczby małych zadań zapewni lepszą ogólną ocenę (z powodu prawa średnich, niektóre z twoich szacunków będą niższe, ale niektóre się skończą i będą miały tendencję do ważenia się nawzajem) dużego zadania.

Zapytaj swojego „kierownika projektu”: Czy sprzedajemy oprogramowanie lub terminy?

Jestem kierownikiem projektu i programistą :-) Mógłbym długo mówić o tym, jak większość PM jest spoza branży i nie radzę sobie z niczym, co nie pasuje dobrze do modelu linii produkcyjnej ... ale ja nie, nie tutaj. Zamiast tego jest długa polemika na temat tego, co właściwie zrobić (Mr Mod, jeśli jest za długi, rób, co z nim zrobisz). Zgadzam się z komentarzami już tutaj napisanymi, niektóre powinieneś zrobić przed innymi, ale myślę, że najlepiej by był twoim pierwszym krokiem . Och, i oczywista odpowiedź na twoje pytanie brzmi „tak”, ale zostało to wyjaśnione poniżej w kolorowym i szczegółowym języku.

Zanim zacznę, zauważ jednak, że PM najprawdopodobniej daje ci smutek, ponieważ ktoś inny w dalszej części łańcucha pokarmowego daje im smutek. Są (my) prostymi stworzeniami ... Są sposoby na uniknięcie opisanej przez ciebie sytuacji - Mike Brown dobrze to opisuje. Nie ma też nic złego w warsztatowaniu czegoś przez 3/4/5 .. godzin przed rozpoczęciem go (właściwie wszystkie alarmy muszą się włączyć, jeśli tak się nie stanie). A jeśli wybierasz się na nieznane terytorium, odsuń się i poproś o tydzień na zbadanie obszaru i technologii, aby móc dokonać rozsądnego oszacowania (będziesz chciał to zrobić poprawnie, ponieważ chcesz, aby nowa technologia uczyła się i grała z donem ty?). Jeśli Twój PM i kierownictwo w miejscu, w którym jesteś, nie rozumieją tego ... zaktualizuj swoje CV i poszukaj najbliższego wyjścia, pozostawiając je losowi, na który tak bardzo zasługują. To, że premier pomyślałby nawet o zatrudnieniu pracownika na pełny etat do podpisania takiej umowy, jest złym złym znakiem ... jedyny sposób, w jaki mogłem zobaczyć, że onimoże nie być całkowicie niekompetentny, ponieważ tak naprawdę grali w gry umysłowe z liderem projektu i tobą (z tego, co przeczytałem, nie przekazali tego bezpośrednio tobie i ostatecznie nie podążyli za zagrożeniem). PMing to w końcu raj dla twojego standardowego psychopaty korporacyjnej. Dobrze, że inni poszli za tobą z tego, co powiedziałeś, więc poniższe porady prawdopodobnie okażą się dla ciebie pozytywne. Wyobrażam sobie, że mieliby rewolucję w rękach, gdyby okazało się to czymś więcej niż tylko rozmową.

Tak więc do opisanej przez ciebie rzeczywistej sytuacji / dziury , ponieważ gdzieś to się powtórzy (jak około 5 minut temu i ponownie w kolejnej 5, SchedRepeat ()). Prawdopodobnie bez głupoty kontraktowej, ale podstawowa fabuła jest zawsze taka sama. Zorganizuj spotkanie (!), Lubią spotkania ;-) wszyscy mogą poklepać się po plecach, jakby coś zostało zrobione. WAŻNY:Upewnij się, że w zaproszeniu na spotkanie umieścisz swojego kierownika projektu / lidera zespołu / architekta / kierownika projektu, który omówił już z nimi problem i zabrał ich na pokład. Im wyżej w hierarchii możesz znaleźć kogoś po swojej „stronie”, tym lepiej. Ponieważ twój PM to zobaczy i spróbuje dopasować swojego kierownika projektu do odpowiednika. Jeśli nie, są głupie i już wygrałeś. To samo w sobie przyciągnie je z powrotem do linii, ponieważ teraz są widoczne dla kogoś, kto prawdopodobnie może je zwolnić na miejscu. Jeśli grają z tobą w gry, możesz zwrócić przysługę.

Podczas spotkania zapoznaj się ze szczegółami technicznymi tego, z czym masz do czynienia i dlaczego zajmuje to tyle czasu. Powinny chcieć to wiedzieć (i jak mogą pomóc ci to zrobić), ale smutny fakt jest taki, że tak się nie dzieje ... prawdopodobnie dostaniesz 10 minut, zanim ich oczy powrócą do głowy. Teraz to, co chciałbym tutaj zrobić, prawdopodobnie nie jest legalne ... tak, sprawdziłem, to jest w rzeczywistości wysoce nielegalne i nie chcesz iść do więzienia na tak długo. Chodzi o to, że dołożyłeś wszelkich starań, aby być proaktywnym, a jeśli masz kilku przełożonych, twój ból jest teraz ich ... tak jak powinien. Będziesz musiał ocenić, co może się wydarzyć, ponieważ „eskalacja” się wydarzy. Jeśli przywództwo w miejscu, w którym jesteś, jest w połowie przyzwoite, zrobią dobrą rzecz, i róbcie też właściwe rzeczy. Jeśli nie, to miałbyś wcześniej swoje CV na rynku ... i tak odejdziesz przy pierwszej okazji (i wygląda na to, że ostatecznie). Przywódcy podzielą się na dwie grupy - albo są doświadczeni technicznie i natychmiast zobaczą twój punkt widzenia; czy nie są i co zamierzają z tym zrobić oprócz uśmiechu i znoszenia? Gdyby mogli zrobić to, co ty, to już by to zrobili. a co oni z tym zrobią, oprócz uśmiechu i znoszenia? Gdyby mogli zrobić to, co ty, to już by to zrobili. a co oni z tym zrobią, oprócz uśmiechu i znoszenia? Gdyby mogli zrobić to, co ty, to już by to zrobili.

Zachowaj problem zmieniających się wymagań jako karty atutowej do wykorzystania na końcu ... będzie ona służyć jako wyjście dla wszystkich. Sam projekt i ten cholerny klient / interesariusz będą na próżno przyjmować swoją nazwę. Najbardziej bezbolesnym rozwiązaniem byłoby zresetowanie projektu i być może ten premier zostałby po cichu przeniesiony do innego obszaru. Cuda zdarzają się czasami. Jeśli kwestia kontraktu została podniesiona na spotkaniu przez premiera, to wróć z wymaganiami zamrożenia popytu na kontrakty - o ile mi wiadomo, oni już spalili swoje mosty z tobą i dla całego zespołu programistów, kiedy zaczęli grając w tego rodzaju gry umysłowe.

Przed podpisaniem się: zmiana zakresu / wymagań - jeden z najlepszych powodów do przyjęcia metodologii Agile, dzięki czemu klienci / interesariusze są odpowiednio odpowiedzialni za zmianę zdania na temat tego, czego chcą ...

Aha, jeszcze jedno: w oświadczeniu „Nie wiem” zawsze byłem osobistym punktem odniesienia dla tego, jak ocenić wartość kolegi technologa lub członka jednego z moich zespołów projektowych. Uważam, że jedyni ludzie, którzy są w stanie powiedzieć, że prosto w twarz są najlepsi, przede wszystkim dlatego, że ktoś, kto wie, że są z głębi, nigdy tego nie powie - otwiera ich na wyraźną ekspozycję osoby z faktycznymi zdolnościami bicie serca. Z drugiej strony ktoś, kto wystąpi i powie to, będzie miał również podstawowy plan (nawet jeśli nie sądzono), jak radzić sobie z niewiadomymi, aby za 24 godziny była bardziej użyteczna odpowiedź, a za tydzień jeszcze lepszy. Kiedy Apollo 13 latał po ciemnej stronie Księżyca, działo się całe mnóstwo „Nie wiem”.

Tak, powinno to podnieść czerwoną flagę, szczególnie jeśli jesteś zatrudniony na pełen etat. Jakie były warunki umowy? Czy rzeczywiście zostałbyś zwolniony, gdybyś nie dotrzymał terminów? A może po prostu przegapisz bonus? Co by zrobili?

Flaga ta podnosi, że menedżer nie ma pojęcia, jak zarządzać projektem dotyczącym nowych / nieznanych technologii i zmieniających się wymagań, które bezpośrednio wpływają na szacowany nakład pracy. Chociaż czasem zdarzają się trudne terminy, kierownik, który zna sytuację, nie powinien próbować nakłonić pracowników do podpisania umów w celu ich egzekwowania. Późne noce i czasy chrupki będą złe, ale prawdopodobnie jest to równoznaczne z kursem. I wciąż czasem termin się przesuwa. Zdarza się, i jak ktoś napisał, jedynym sposobem na dotrzymanie harmonogramu jest ZATRZYMANIE wymagań WCZESNIE, aby pozostało wystarczająco dużo miejsca, aby zachować oś czasu.

Z tego, co powiedziałeś, dzwonki alarmowe są spóźnione o kilka miesięcy. Opieranie wrażliwego na czas projektu w oparciu o technologie, których personel jeszcze nie zna, jest zwykle ryzykowne. To niedorzeczne, jeśli nie masz pojęcia o zbieraniu wymagań i zarządzaniu zakresem.

To powiedziawszy, zgadzam się z innymi odpowiedziami. Możesz także zaktualizować swoje CV, jeśli jeszcze tego nie zrobiłeś.

Podobnie jak wszyscy pozostali respondenci, nie mogłem się bardziej zgodzić, że to powinno podnieść czerwoną flagę.

Wygląda na to, że premier nie chce brać udziału w procesie rozwoju.

W mojej osobistej praktyce od dawna odchodzę od zajmowania się szczegółowymi specyfikacjami z góry, podpisywaniem się, pełnym szacunkiem projektu lub ustalaniem cen ofertowych (z perspektywy konsultacji).

Powodem tego jest uświadomienie sobie, o czym mówi wielu guru Agile i Lean Software, że oprogramowanie to nie jest stała jednostka produkcyjna, ale w większości proces odkrywania.

Wiele osób wciąż ma problem z tym pojęciem i brzmi to tak, jak twój premier. Sprowadza się to do prostego zrozumienia kompromisów.

Sztywne specyfikacje wstępne i stałe szacunki działają w systemach, w których koszt zmian jest wysoki. Jak budowanie wieżowca. Jeśli zapomniałeś podać szyby windowe z przodu, naprawdę trudno będzie doposażyć budynek po jego wzniesieniu. Wysokie koszty zmian wymagają dużo planowania z góry, poznania nieznanych elementów i technologii oraz eksperymentów z góry. Tylko po wykonaniu wszystkich zadań domowych możesz oszacować budżet i koszty.

W oprogramowaniu ludzie bardzo przyzwyczaili się do pomysłu, że koszt zmiany jest niski, i dlatego lubią korzystać z możliwości zmiany rzeczy, gdy zobaczą wydanie, włączyć nowe rozumienie aplikacji, biznesu, klienta na na bieżąco. Wszystko to jest dobra i ogromna szansa, gdy jest właściwie wykorzystywana. Większość osób, z którymi się spotkałem i z którymi pracowałem, nie lubi spędzać dużo czasu na planowaniu lub badaniu; większość z nas (w tym PM) chce widzieć ciągłą przyczepność. Stąd pochodzi iteracyjny rozwój z jego małymi, przyrostowymi wydaniami funkcjonalności. Istnieją inne praktyki, które można zastosować, takie jak rozwój oparty na testach, aby zagwarantować, że koszty zmian pozostaną niskie, a zadłużenie techniczne zostanie ograniczone.

Wykonanie tej pracy wiąże się z „umową” między obiema stronami, właścicielem produktu (Agile mówi w imieniu swojego PM lub klientów lub zespołu kontroli jakości) i programistami. Programiści zgadzają się pracować tylko nad rzeczami, dla których priorytetem jest najważniejsza dla danej iteracji, i nie brać tego na zawsze, ale starać się często wypuszczać w pełni zintegrowane fragmenty funkcjonalności (np. Co tydzień lub co miesiąc). Natomiast właściciele produktów zgadzają się na ciągłe sprawdzanie wersji przyrostowych i udzielanie szybkiej informacji zwrotnej. Zgadzają się również ustalić priorytety następnej iteracji i raz postanowić nie zmieniać zdania na czas iteracji.

Ta ostatnia część umowy jest czymś, czego prawdopodobnie twój poseł nie rozumie. Wielu tradycyjnych premierów tak naprawdę nie. Niektórzy z nich myślą, że ich praca jest wykonywana, gdy rezygnują ze specyfikacji; nie chcą słyszeć o problemach, alternatywach, lepszych sposobach itp. Minusem jest to, że nie tylko przeciwdziała to rozwojowi oprogramowania, ale także szkodzi organizacji, pozostawiając wiele możliwości na stole.

Rzuć okiem na Manifest Agile: http://agilemanifesto.org/ Może cię to rezonować. Dobra książka do przeczytania to także „Lean Software Development” Mary Poppendieck

Powodzenia.

Wygląda na to, że kierownik szuka kogoś, kogo można obwinić, gdy zgłasza się do przełożonego.

Uważam, że jeśli masz nierozsądnego kierownika, który uważa, że ​​„szacunek” jest taki sam jak „ustalony okres”, najlepiej jest wymyślić bardzo hojny okres szacunkowy, a następnie podwoić go!

Ponadto zmuś menedżera do upewnienia się, że wymagania są w pełni szczegółowe i ustalone. Wszelkie zmiany od tej pory nie będą rozpatrywane bez „formalnej renegocjacji” z kierownikiem projektu nowego czasu zakończenia.

W końcu kierownik projektu dostaje pomysł i odpowiednio planuje.

Moje osobiste doświadczenia z tego rodzaju rzeczami polegają na tym, że kierownik projektu próbuje założyć papierową ścieżkę, aby się z tobą pozbyć, jednocześnie czyniąc zakończenie z własnej winy. To sprawiłoby, że byłaby to bardzo czerwona flaga. Twój przebieg może oczywiście się nieco różnić.

Dobre odpowiedzi dookoła, ale dodaję 2 centy.

Jeśli kiedykolwiek badasz prawdopodobieństwo, istnieje coś takiego jak „zmienna losowa”. Jest to liczba, której wartości nie znasz, ale możesz opisać swoją niewiedzę rozkładem, takim jak rozkład normalny (krzywa dzwonowa) lub inny.

Chodzi o to, że praca zajmie trochę czasu, ale wszelkie wcześniejsze szacunki będą błędne, trochę lub dużo, po stronie negatywnej lub pozytywnej, więc istnieje ryzyko i ktoś musi zaryzykować. Ogólnie rzecz biorąc, jeśli ludzie podejmują ryzyko, otrzymują za to wynagrodzenie. Ubezpieczenie kosztuje.

Kiedy byłem konsultantem, zwykle miałem wybór podpisania umowy na czas i materiały w porównaniu do umowy o stałej cenie. Dzięki czasowi i materiałom klient ponosi ryzyko. Ze stałą ceną ponoszę ryzyko. Dzięki stałej cenie buduję z marginesem bezpieczeństwa, ponieważ jeśli nie uda mi się osiągnąć celu, nikt nie wygrywa.

Proszenie o ustalenie terminu dostawy, zwłaszcza bez ustalonych wymagań, brzmi jak próba przeniesienia ryzyka na ciebie, nawet jeśli nie jest jasne, na co tak naprawdę ryzykujesz. W każdym razie jedną z odpowiedzi jest po prostu wprowadzenie naprawdę hojnego marginesu bezpieczeństwa.

PS Cały czas widzisz to dzięki kontraktom rządowym. Najpierw pojawia się prośba o propozycje, składane są oferty, akceptowana jest niska oferta, a następnie zaczynają się pojawiać prośby o zmianę, więc balony kosztów i wykonawca zostaje obwiniony. Sprawy działają znacznie lepiej, jeśli istnieje relacja pracy zespołowej między klientem a kontrahentem, niż kontrowersyjna.

Tak, oczywiście podnosi to flagę dotyczącą doświadczenia i kompetencji twojego byłego szefa. Tak, jak sugeruje większość ludzi, byłby to dobry moment na aktualizację twojego CV.

Tak, jak podają inne odpowiedzi, w większości sytuacji nie chcesz podpisywać tej umowy. Chciałbym jednak zasugerować, że mogą zaistnieć sytuacje, w których można rozważyć podpisanie go.

Większość programistów i menedżerów zdaje sobie sprawę z ciągłego tarcia między funkcjonalnością, terminem i budżetem. Wielu wyznaczy również jakość jako czwarty wymiar („Mogę dostarczyć do jutra dowolny zestaw wymagań, które ci się podobają, przy niskim budżecie, o ile będziesz gotów zaakceptować, że to nie zadziała!”)

Ale jest jeszcze inny wymiar: ryzyko. Jeśli będę potrzebować tylko z sukcesem w 50% przypadków, mogę znacznie obniżyć swoje prognozy; są wyściełane, aby obsługiwać znacznie wyższą szybkość dostawy.

Możemy zająć się ryzykiem na wiele sposobów (jednym z nich jest szacowanie wypełnienia). Menedżer nie jest skłonny zaakceptować żadnego ryzyka i chce obciążyć go ramionami. Zwykle powinieneś odrzucić taki ruch ... chyba że jesteś dobrze wynagradzany.

Jeśli jesteś w stanie wyznaczyć swój termin, z wzajemnie akceptowalną ilością dopełnienia, aby poradzić sobie z nieoczekiwanymi opóźnieniami, i jesteś w stanie wynegocjować (bardzo dużą) premię, jeśli go dotrzesz, i jesteś w sytuacji finansowej, aby móc obsłużyć kary (np. zwolnienie), jeśli nie możesz, może okazać się, że opłaca się „ryzykować” samemu ryzykować i podpisać umowę - z odpowiednimi klauzulami do obsługi zmian wymagań.

To jest wprost głupota. Nie wiem, jaki był ostateczny cel, ale każdy w połowie przyzwoity kierownik projektu odpowiedzialny za oprogramowanie powinien być świadomy, że szacunki są dokładnie tak, jak się je nazywa: szacunki. Nie są obietnicami i nie da się ich uczynić bez wyczerpania twórcy oprogramowania całej energii lub zmuszenia ich do złamania „obietnicy”.

Jeśli chcesz pokazać, jak śmieszna jest taka umowa, oto dwie sugestie:

a) Bardzo zawyżone do tego stopnia, że ​​projekt zajmuje pięć lub dziesięć razy więcej, niż można by oszacować bez umowy. Jeśli kierownik projektu zapyta, dlaczego szacunki są tak wysokie, po prostu powiedz, że upewniasz się, że możesz wypełnić umowę.

b) Zostało to już zasugerowane: Poproś o umowę, która zapewni, że nie zmieni się ani jeden wymóg, i upewnij się, że obejmuje to poprawienie błędów ortograficznych. Z mojego doświadczenia wynika, że ​​nie ma jednego projektu oprogramowania, w którym wymagania nie zmieniają się w pewnym momencie podczas programowania. Kierownik projektu jest bardziej narażony na zerwanie umowy niż ty.

Jeśli kierownik projektu zgodziłby się na którąkolwiek z tych dwóch sugestii, wiedziałbyś na pewno, że są poza ich umysłem.

Nawiasem mówiąc, jak mogłaby w ogóle obowiązywać umowa dla pracownika zatrudnionego w pełnym wymiarze godzin? Nie wiem o regulaminie pracy w innych krajach, ale jako pracownik zatrudniony na pełen etat w firmie nie sądzę, aby ktokolwiek zmusił cię do podpisania wiążącej umowy w celu dotrzymania terminu i uzasadnienia sprawy. Jasne, mogą dać ci piekło, jeśli nie dotrzymasz terminu, ale nie potrzebują na to umowy. Nikt nie może cię zwolnić ani dać mniej pieniędzy. W najgorszym przypadku mogą obniżyć uzgodnioną premię. Tak więc, chyba że w innych krajach jest inaczej, wydaje się to bardziej pustym zagrożeniem niż czymkolwiek, co należy poważnie potraktować.

Idę tutaj pod prąd.

Sytuacja, którą opisujesz, nie jest wcale taka niezwykła na poziomie zespołu inżynierów , szczególnie po szczególnie późnym projekcie / wydaniu. W wielu sytuacjach kierownictwo i cała organizacja mogły faktycznie zapisać się na konkretną datę wydania, a inne części organizacji będą przygotowane na tę datę. Na łańcuch zarządzania może być ogromna presja, by osiągnąć ten termin.

W tym momencie pojawia się proces inżynierii ogólnej. Prawdopodobnie słyszałeś o modelu wodospadu. Istnieją inne modele, ale ostatecznym celem wszystkich z nich jest konsekwentne dostarczanie czegoś, kiedy jest to oczekiwane, i zawieranie tego, co zostało uzgodnione. Specyfikacje funkcjonalne, projekty, listy zadań itp. Mają na celu uczynienie z tego procesu przewidywalnego. Komunikacja, analiza ryzyka i (jak powiedziałeś) regularne aktualizowanie oczekiwań dotyczących harmonogramu zmniejsza niespodzianki i udostępnia informacje jak najszybciej, aby umożliwić dostosowanie planów. I tak, należy dodawać lub usuwać funkcje w planie.

W niektórych zespołach, z którymi współpracowałem, nie zawahałbym się traktować moich szacunków jako podpisanych zobowiązań, ale odzwierciedla to jakość zespołów i kierownictwa, a nie jakąkolwiek umiejętność szacowania. Zespół , który jest gotów podpisać umowę na dostarczanie na czas jest wskaźnikiem zespół dobrze pracuje, a nie czerwona flaga.

Mówię, postaw się w jego / jej butach i spróbuj zrozumieć, co to motywowało. Potencjalni menedżerowie / księgowi potrzebują numeru, aby uzasadnić to, co się dzieje i jak się sprawy mają.

Możliwe, że wyśmiewany w sali posiedzeń zarządu za przesunięcie terminów, brak zbyt wielu terminów, próbował najprostszego możliwego sposobu, aby je zamknąć. Podaj mi numer i podpisz tutaj! Będąc na drugim końcu, mogłeś tylko zauważyć, że jest to coś przeciwko tobie. Bardziej przydaje mu się jednak dokonywanie szacunków i uświadomienie sobie, że należy je dostosować. Jeśli zrozumiesz, co uzasadnia tę prośbę i jaki jest prawdziwy problem, przed którym stoi, możesz pomóc mu i sobie. Jako programiści rozwiązujemy problemy. Nie inaczej jest, zrozum i rozwiąż jego problem, a on będzie twoim najlepszym przyjacielem. Jest tyle pracy do zrobienia, że ​​nikt nie ma czasu na przygotowanie osobistej wendety! Potrzebuje pomocy w pracy, najprostszym rozwiązaniem było podpisanie dokumentu przez kogoś! Prawdopodobnie otrzymał to z książki kierownictwa ds. Manekinów: „Niech twoi pracownicy podpiszą się i będą odpowiedzialni za pewną liczbę”. Śmieszne, ale smutne

„Chodzenie po wodzie i tworzenie oprogramowania ze specyfikacji jest łatwe, jeśli oba są zamrożone”.

- Edward V. Berard

Jeśli zmieniają się Twoje wymagania, nie można oczekiwać, że początkowe szacunki będą dokładne. Tak, powinna to być czerwona flaga.

Czy umowa przewiduje karę za niedotrzymanie terminu? Jeśli tak się nie stanie, nie będzie to wcale problemem - po prostu podpisujesz szacunek w oparciu o twoją wiedzę w tym czasie.