Czy przekroczone terminy są wspólne w programowaniu miejsc pracy? [Zamknięte]

18

To była moja praca jako freelancer w oDesk. Wykonałem kilka prac wcześniej w danym czasie, ale po raz pierwszy przekroczyłem termin. To była bardzo długa praca i starałem się jak najlepiej, ale wciąż nie dotrzymałem terminu. Teraz się bardzo boję. Ponieważ to moja wina, że ​​nie dotrzymałem terminu.

Moje pytanie brzmi: czy jest to poważny problem, czy nie dotrzymujesz terminów wspólnych dla zadań programistycznych, więc nie powinienem się tym zbytnio przejmować?

freelancing deadlines
źródło
1
Całkowicie zależy od środowiska. Na przykład moja ostatnia praca była w agencji cyfrowej, która pobierała opłaty od klientów na podstawie szacunków. Jeśli nie dotrzymałeś terminu, firma straciła pieniądze. Moja obecna praca jest tak dynamiczna, że ​​nie ma żadnych rzeczywistych terminów. Jeśli moja uwaga jest wymagana gdzie indziej, mam odpowiedni czas na poświęcenie się temu. Być może uwzględnienie tego w pytaniu pomoże w udzieleniu odpowiedzi.
Simon Whitehead
możliwy duplikat Jaki jest najskuteczniejszy sposób komunikowania potencjalnych opóźnień w rozwoju oprogramowania?
komar
3
przekroczone terminy są wspólne dla wszystkich miejsc pracy
Steven A. Lowe
2
Naprawdę mam nadzieję, że komunikowałeś się z klientem o przekroczonym terminie. Zdarzają się przekroczenia terminów, ale nie powinno to być niespodzianką - powinieneś być w stanie zobaczyć, jak nadchodzi i się o tym komunikować. Zwykle ułatwia to po prostu napisanie „Nie, jeszcze nie gotowe”.
Bobson
6
Zrób to szybko, zrób to tanio, zrób to dobrze: wybierz dwa.
Reactgular

Odpowiedzi:

45

Tak. Przekroczenia terminów są powszechne przy tworzeniu oprogramowania.

Wielu freelancerów dotrzymuje terminów, zaciągając dług techniczny lub chowając brud pod dywan.

Parafrazując Miesiąc mitycznego człowieka Fredericka Brooksa :

Frederick Brooks, autor The Mythical Man Month

  • Terminy często się nie dotrzymują, ponieważ liderzy projektów nadal oceniają zadania związane z oprogramowaniem w taki sam sposób, jak robią to zadania z zakresu inżynierii lądowej, co jest błędem, ponieważ oprogramowanie to nowatorski przemysł rękodzielniczy bez wyraźnego zbioru norm. Jest to tak prawdziwe, że nie można odwołać „zezwolenia” programisty na kodowanie błędów, ani też nie można pozwać kogoś za programowanie bez tytułu.

  • Tworzenie oprogramowania ma naturalną złożoność, której brakuje innym dyscyplinom. Duży program może mieć więcej komponentów niż samochód, a komponenty te mogą oddziaływać na wiele różnych sposobów.

  • Oprogramowanie jest trudne do wizualizacji, więc różne rodzaje diagramów są wykorzystywane do wyświetlania różnych aspektów projektu, a te aspekty mogą nie być ortogonalne. Z drugiej strony inżynieria lądowa ma plany, które pozwalają zobaczyć orurowanie, okablowanie itp. Na tej samej mapie (lub warstwach) w ortogonalny sposób.

  • Po całkowitym zbudowaniu mostu lub budynku nie jest powszechne, aby klient całkowicie zmienił zakres projektu. Często dzieje się tak w projektach oprogramowania.

  • Stan techniki w zakresie tworzenia oprogramowania nie osiągnął punktu, w którym projekty oprogramowania są powtarzalne i prawie pozbawione ryzyka. Nawet największe firmy produkujące oprogramowanie, takie jak Microsoft, mogą przekroczyć terminy o miesiące lub lata.

  • Większość vaporware to tylko projekty oprogramowania, które zostały wycięte z powodu tego rodzaju problemów.

Podsumowując:

Złe oszacowania i niedocenianie złożoności wynikające z rękodzieła procesu tworzenia oprogramowania oznaczają, że pozostaje on niedojrzałą dyscypliną.

Tulains Córdova
źródło
11
+ Dobra odpowiedź, ale mając pewne doświadczenie w inżynierii mechanicznej i inżynierii lądowej, zabawne jest, jak programiści dokonują łatwych porównań do budowania mostów i innych rzeczy, gdy nie mają najmniejszego pojęcia, jak są one budowane.
Mike Dunlavey
3
Zgodziłbym się z pomysłem, że oprogramowanie jest planowe (w zakresie inżynierii - opisując każdy szczegół projektu). W przypadku inżynierii dominuje czas budowy fizycznej, więc duża zmienność w planowaniu nie odgrywa żadnej roli. Jednak ponieważ oprogramowanie składa się wyłącznie z planu ... „Stan techniki w zakresie tworzenia oprogramowania nie osiągnął punktu, w którym projekty oprogramowania są powtarzalne i prawie wolne od ryzyka” - w takim razie dlaczego projekt w ogóle? Jeśli coś jest powtarzalne i można je zautomatyzować, nie trzeba tego robić wiele razy, ale można to zrobić raz i skopiować.
Maciej Piechotka
2
@ user61852: Źle mnie zrozumiałeś. „Plan” inżynierii jest „źródłem” dla informatyki - tzn. Szczegółowy opis każdego elementu - ale kiedy już go mamy, możemy go zbudować (wprowadzić makelub cokolwiek). Czym jest „plan” w informatyce byłby „planem” planu ”w inżynierii. Różnica polega na tym, że makew informatyce zajmuje co najwyżej kilka godzin, podczas gdy pisanie kodu źródłowego (w tym testów i integracji) zajmuje miesiące, podczas gdy w inżynierii planowanie może zająć miesiące (w tym obliczenia konstrukcyjne), a budowanie trwa lata, więc wariancja planowania ma mniejszy wpływ na tym drugim.
Maciej Piechotka
1
@ user61852: Jeśli chodzi o powtarzalność - komputery są świetne w automatyzacji. Powiedz, że musisz zbudować prosty blog - w momencie, gdy będziesz miał dokładne „szacunki”, otrzymasz wordpress (lub inny system blogowania), więc nie musisz nic robić (w przypadku pomostu) nadal masz inne środowisko, więc musisz dostosować się bardziej ostrożnie, ponieważ skała może być inna lub może istnieć siedlisko ptaków lub może to zniszczyć widok) - programiści mogą być bardziej odpowiedzialni za tworzenie narzędzi (standardowy model mostu).
Maciej Piechotka
2
Premia za cytowanie Miesiąca Mitycznego Człowieka; Frederick Brooks wytrzymuje po tylu latach, ponieważ skupia się na ludziach, a nie technologii.
Michael Shopsin
3

Przekroczenia terminów nie powinny stać się powszechną praktyką, jeśli chcesz nadal otrzymywać pracę.

To powiedziawszy, zazwyczaj chcesz zostawić sobie trochę dodatkowego „poruszenia” w swoich szacunkach na wypadek, gdyby coś się wydarzyło (i zawsze tak się dzieje). Nie musisz ujawniać, że dodałeś w dogrywce, po prostu nie rób tego nierozsądnie. Może od 5 do 10% całkowitego czasu? Jedynym sposobem, aby się dowiedzieć, jest zrobienie tego kilka razy.

Aby naprawdę dobrze oszacować, musisz wiedzieć, ile czasu zajmuje kodowanie określonego typu widżetu ... na przykład załóżmy, że musisz utworzyć nieskończony widżet przewijania dla klienta X. Jeśli zajmie Ci to tydzień aby wdrożyć go do produkcji bez błędów, możesz użyć go jako podstawy dla swoich nieskończonych oszacowań przewijania.

TJ Trapp
źródło
2
Zawsze robię 20% miejsca, kiedy robię oszacowanie. 5-10% to za mało. Myślę, że to zależy od tego, jak bardzo jesteś rozproszony. Deweloper solowy może wcale nie być rozproszony
BЈовић
Jestem programistą solo i zwykle biorę 10% marży na moje projekty.
Konsole
Hmmm ... patrz Hofstadter's_law
Philip
1
W porównaniu do 5-20%, myślę, że 100% margines jest lepszy. Poważnie. Pozwala znacznie lepiej poznać dostępne opcje. I odpowiedz na więcej pytań na temat wymiany stosów.
Acumenus
O tak, to wina programisty, gdy 15-letni doświadczony kierownik projektu wywiera presję na 1,5-letniego inżyniera oprogramowania, aby podał mu szacunek, a następnie dostosowuje go, aby był jeszcze bardziej agresywny i zachowuje się, jakby deweloper zwlekał, gdy projekt został podzielony . Nigdy nie pracowałem dla menedżera lub premiera, który w ogóle mógłby pisać oprogramowanie, a mówisz mi, że przekroczenie terminów nie powinno stać się powszechną praktyką, jeśli chcesz nadal otrzymywać pracę? Przekroczenia terminów mają charakter endemiczny, ponieważ większość premierów jest dosłownie niekompetentna w swojej pracy. Mój najlepszy menedżer nadal nie był inżynierem oprogramowania, po prostu znał swoje ograniczenia.
downbeat
3

Niedotrzymywanie terminów nie jest rzadkością w tworzeniu oprogramowania. Dokładne oszacowanie czasu trwania projektu oprogramowania jest prawie niemożliwe.

Profesjonalizm przejawia się w tym, jak sobie z tym radzisz. Jeśli wiesz, że nie dotrzymasz terminu, poinformuj go jak najwcześniej, aby mógł odpowiednio zaplanować.

Philipp
źródło
2

To dość powszechne, ale możesz być lepszy. Możesz spojrzeć na szacowanie za pomocą czegoś abstrakcyjnego, takiego jak punkty opowieści , i śledzić swoją prędkość, aby obliczyć swoje rzeczywiste oszacowania. Te pojęcia są najczęściej kojarzone ze scrumem, ale można ich użyć, nawet jeśli nie robisz scruma.

Niesamowite w prędkości jest to, że obejmuje wszystkie rzeczy niematerialne, takie jak przerwy i nieoczekiwana złożoność, którą programiści mają trudności z rozliczeniem w swoich szacunkach. Wszystkie prawdopodobieństwa uśredniają się w czasie. Uśrednione w ciągu 10 tygodni nasze oszacowania prędkości były dokładne w granicach około 5%. Jednak gdy oceniamy te same zadania w godzinach, dokładnie ten sam zespół konsekwentnie nie docenia o 30-50%.

Karl Bielefeldt
źródło
1

Moja teoria (niepotwierdzona) jest taka, że ​​ludzie ewoluowali, by nie doceniać skomplikowanych prac o dwa lub trzy do jednego. Za każdym razem, gdy Kongres pyta NASA o coś takiego: ile kosztuje zbudowanie promu lub podróż na księżyc, wracają w ciągu tygodnia z liczbą. Po wyczerpaniu wszystkich oczekiwanych kosztów odkryją, że będzie to kosztować trzy razy więcej.

W latach 70. mieliśmy żart: weź dowolny programista, podwoj liczbę, a następnie przenieś ją do następnej jednostki czasu. Dlatego jeśli programista powie, że można to zrobić za dwa tygodnie, skończy to za cztery miesiące.

Jeśli ktoś przebudował kuchnię, na ogół myśli „Cóż, zrobię to za dwa tygodnie”. Kończą to około sześć tygodni później.

Meredith Poor
źródło
1
Co NASA ma wspólnego z moim pytaniem?
1
Co więcej, co ewolucja człowieka ma wspólnego z twoim pytaniem? NASA jest wyraźnie udokumentowanym przykładem w publicznym rejestrze przeszkolonych i doświadczonych ludzi, którzy nie doceniają dużych projektów. Krótko mówiąc, twoje doświadczenie jest „naturalne”.
Meredith Poor
Chociaż zgadzam się, że szacunki większości ludzi są co najmniej dwukrotnie większe, ale następna jednostka czasu ... hmmmm. W każdym razie NASA jest bardzo dobra w szacowaniu zadań, które już wiedzą, jak wykonać. Problem polega na tym, że ludzie nie są zbyt dobrzy w szacowaniu zadań, gdy nie wiedzą, czego nie wiedzą. Ponieważ NASA wykonuje naprawdę pionierską pracę, nic dziwnego, że niewiele wiedzą o tym, co robią, dopóki nie zaczną tego robić. Przyczyna początkowego niedoszacowania. Ponadto niektórzy ludzie są predysponowani do optymizmu, a inni do pesymizmu. Nie jestem pewien, czy w grę wchodzi ewolucja.
Dunk