Głupie błędy w zarządzaniu, część pierwsza

Niedoszacowałem czasochłonności projektu. Ale tym nie jestem zdziwiony, jeszcze wiele wody w rzece upłynie, zanim będę w stanie w miarę dokładnie terminy przewidywać. Popełniłem inny błąd -- nie zadbałem, by możliwie wcześnie skonsultować odpowiednie fragmenty dokumentacji z osobą, która byłaby kompetentna nam wykazać rozjazdy z rzeczywistym modelem biznesowym. Szczyt kretynizmu jak teraz na to patrzę. Grrr.

Skutek? Kilka mniejszych i niestety kilka większych dziur wymagających poprawek w kodzie. Przy czym ja, jako szef, za swoje błędy płacił nie będę. Nadmiarową robotę będzie miał programista.

Niskoopłacany niedoświadczony programista, który chyba dopiero na tym projekcie zaczyna rozumieć, że "naiwna ocena czasochłonności", typowa dla początkujących koderów ("Ten projekt? Tydzień, maks dwa.") nijak się ma do rzeczywistego mozolnego kodowania. Programista, który zaczyna się wypalać na moich oczach. Programista, którego potrzebuję na zaraz do następnego projektu.

Szlag by to. Przydałoby się zrobić coś konkretnego, tylko co. Na początek niech będzie zapewnienie, że terminy są bardzo fajne, gdy wydają pocieszne dźwięki przelatując nad naszymi głowami. I że nie ma się nimi za bardzo po co przejmować.

  1. 1. rozie

    Jedna z niewielu przydatnych rzeczy wyniesionych ze studiów ekonomiczno-informatycznych dotycząca projektów (nie tylko informatycznych): jeśli nie jesteś doświadczony w danej dziedzinie, to szacując zasoby potrzebne do wykonania projektu na końcu pomnóż je przez 2. Niestety, sprawdza się. Na pocieszenie – zwykle ‘zleceniobiorca’ woli uargumentowany dalszy termin, niż partaczenie w terminie.

  2. 2. sztywny

    Może zainteresuje:

    http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

  3. 3. sztywny

    Sorry, zepsułem Ci layout ;)

  4. 4. Jajcuś

    No niestety… tak już jest z niedoświadczonymi programistami… a trudno zatrudnić od razu doświadczonego, jeśli ten już na dzień dobry kręci nosem nad projektem (niedoświadczony jest pełen entuzjazmu), podaje dużo mniej optymistyczny przewidywany termin i jeszcze każe sobie więcej płacić...
    Ale nie będzie doświadczonych programistów, ani doświadczonych managerów, póki ktoś nie da szansy tym niedoświadczonym…

  5. 5. deely

    Skąd ja to znam… Gdzieś czytałem, że przy szacowaniu czasu na dany projekt (tak jak napisał rozie) należy pomnożyć czas przez 2, a najlepiej przez 4 by pozostało go również na dokładne przetestowanie.

  6. 6. ciekawski

    Moja metoda szacowania czasu wykonania przedsięwzięcia:
    oszacowanie naiwne x 2 i w wyniku zmienić jednostkę czasu na następną dłuższą.

  7. 7. danadam

    Ciekawy artykuł o planowaniu: http://www.joelonsoftware.com/items/2007/10/26.html

Adde commentarium: (textile lite)