Po co to cale szacowanie?

W uproszczeniu szacowanie to okreslanie przyblizonej wartosci jakiejs wielkosci przy posiadaniu niepelnych danych.
Spotykamy sie z nim caly czas. Kiedy zony gotujac obiad dzwoni do meza wracajacego z pracy i pyta: "O ktorej bedziesz w domu?" prosi go o oszacowanie czasu jaki zajmie mu dojaz. Odpowiadz jaka udzieli obarczona jest bledem nawet jesli uda mu sie przybyc na czas.Co z tego, ze maz ma super szybka fure jesli nie wie bidulka, ze dwa skrzyzowania dalej byla stluczka i objazd nie jest mozliwy. Co to spowoduje w konteksie rodzinnego obiadu? To zalezy czy maz zadzwoni do zony i zaktualizuje wczesniej przekazane jej informacje.Moze jednak zalozyc, ze jego super szybka fura nadrobi stracony czas na kolejnym etapie drogi do domu i w zwiazku z tym, zakladajac, ze nic dodatkowo nie zakluci jego jazdy, nie ma sensu dzwonic i zawracac zonie glowy. Brzmi znajomo?

Wracajac do tematu: Po co to szacowania?
Odpowiedz zalezy w duzej mierze od punktu widzenia. Inaczej odpowie na nie malo doswiadczony pracownik, inaczej stary wyjadacz, ignorant, pracus, a jeszcze inaczej ten, ktory pilnuje aby zadania zostaly zrobione dobrze, w budzecie i na czas np. team leader.
No wiec zapytalem kilka osob i takie oto otrzymalem odpowiedzi.

• Malo doswiadczony pracownik: Ktos potrzebuje cos zaplanowac i kaze mi to robic wiec to robie.
• Stary wyjadacz: kierownictwo wciaz liczy, ze cos na tym projekcie zarobi. Podaje im co jakis czas nowe szacunki, a oni obliczaja to swoje cos.
• Ignorant: kaza mi to robie ale i tak zawsze wychodzi inaczej.
• Pracus optymista: naanalizowalem sie, naliczylem i na koncu przestraszylem, obetne troche zeby szef sie nie wkurzal.
• Team leader: zeby moc cokolwiek zaplanowac. Praca Henia zalezy od pracy Piotrka, praca testerow zalezy od pracy programistow, programistow od analitykow itd. no i jeszcze ludzie chce miec jakies wakacje (sic!), a klient pyta wciaz kiedy bedzie mogl uzyc zamowiony produkt.
  

Pytanie "Po co to szacowanie?" nurtowalo mnie czesto w momentach kiedy wiedzialem, ze wymagania lub specyfikacja sa dziurawe. No po co kaza mi to szacowac terazprzeciez za 2,3 dni dojdzie nowe wymaganie, cos sie zmieni w specyfikacji i trzeba bedzie robic to na nowo. To szacowanie to marnowanie czasu. Trzeba jakis czas poczekac, az temat dojrzeje i wtedy.... No wlasnie wtedy, "wtedy" jest tu kluczowym slowem. Zamiast zastanawiac sie kiedy bedzie to odpowiednie "wtedy" przyjmijmy, ze "wtedy" oznacza teraz. I zabierzymy sie do pracy.

Estymacja to zawsze duze wyzwanie, zwlaszcza kiedy dodamy do niej takie czynniki jak:

• nieznajomosc lub slaba znajomosc technik stosowanych do estymacji
• nieznajomosc lub slaba znajomosc domeny problemu
• niedokladnie zdefiniowane wymagania
• zaleznosc pomiedzy czesciami wykonywanymi przez rózne osoby. grupy, programy
  

Zbyt szczególowa analiza wymagan, zaleznosci i ciegle zmiany moge sparalizowac estymacje i moze ona niezostac ostatecznie zrobiona. Z drugiej strony moze sie okazac, ze estymacja byla zbyt pobiezna, optymistyczna co sprawilo, ze pewne sprawy zostaly pominiete.

Jak sobie z tym poradzic? Jak wkoncu szacowac zeby to mialo sens.

Po pierwsze trzeba to ciagle robic i uczyc sie na popelnionych bledach.
Mozna tez pomoc sobie okreslajac jakie szacowanie w danym momencie ma sens.

1. Szacowanie rzedu wielkosci (porównywanie z czyms podobnym) - odchylenie 2 lub 3 krotnosc rzeczywistej wielkosci. Mozna powiedziec, ze szacowanie rzedu wielkosci to zadne szacowanie. W tym przypadku jest to jedyne oszacowanie na którym mozemy sie jakkolwiek opierac. Ma ono znaczaca wartosc dla organizacji oraz zespolu projektowego poniewaz daje pewne wytyczne dla projektu jesli chodzi o czas, ludzi i pieniadze. Lepiej wiedziec, ze cos zajmie 4-6 miesiecy niz nie miec bladego pojecie ile to zajmie.
   
2. Zgrubna estymacja - odchylenie 50-100% rzeczywistej wielkosci Pracujesz z dobrze zrozumianymi wymaganiami, oraz jest ktos dobrze obeznany z domena problemu i problemami technicznymi, które moga sie pojawic.
   
3. Estymacja dokladna: odchylenie 25-50% rzeczywistej wielkosci. Jestes bardzo obeznany z tym co ma byc zrobione i robiles to juz wiele razy wczesniej. Takie podejscie nadaje sie do czynnosci wiele razy powtazanych (np. w utrzymaniu aplikacji) gdzie rozwiazania sa znane lub przy dodawaniu dobrze znanej i rozumianej funkcjonalnosci, która juz wczesniej byla dodawana.
   

W efekcie otrzymamy oszacowanie, ktore obarczone jest jak zawsze bledem. Patrzac bardzo ogolnie blad ten moze nazywac sie:

• przeszacowanie - wtedy moze sie okazac, ze do realizacji zostanie wziety ktos inny (inna firma lub inny pracownik) lub, ze w rezultacie pewne wygania nie zostana spelnione z braku czasu, zasobow. Redukcja wymagan moze wystapic juz na wstepie.
• niedoszacowanie - wymagania zostana zaakceptowane jednak niedostateczna ilosc czy czasu lub zasobów spowoduje brak ich realizacji. Redukcja wymagan nastpuje w pozniejszej fazie projektu, potrzeba przeplanowac prace ludzi, zespolow, termin dostarczenia produktu do klienta jest niedotrzymany.
  

Podsumowujac.
Warto pamietac, ze cale to szacowanie nie sluzy do przewidywania przysylosci ale pomaga dowiedziec sie jakie decyzje nalezy podjac obecnie. Np. obecnie nie trzeba zmieniac planu i podzialu zadan poniewaz ty wciaz twierdzisz, ze sie wyrobisz, a przynajmniej nie sygnalizujesz, ze cos idzie nie tak ;)

Pani Linda Rising powiedziala bardzo ladne zdanie, ktore pasuje do tematu szacowania:

Podejmuj zdecydowane decyzje ale nie trzymaj sie ich kurczowo, dopuszczaj zmiany.

O tym napisze nastepnym razem.

Czy znasz wystarczajaco dobrze narzedzia, ktorych uzywasz?

Jaka jest twoja odpowiedz na to pytanie? Nie badz taki surowy ;) przeciez jestes wazna, nieprzecietna osoba! Jak trzeba bedzie to nauczysz sie wszystkiego w 2 dni.

Zaczne moze od tego, ze glownym powodem mojej sympatii do szeroko pojetego tematu komputerow i nauki o nich jest to, ze komputery moga wykonac szybko pewne zadane przez ludzi zadania. W ten sposob moga nam ulatwic zycie. Ulatwic zycie znaczy w pewnych sytuacjach oszczedzic nasz cenny czas.

Spojrzmy teraz na pewien zespol programistow. Jest ich 6. Codziennie spedzaja w pracy 8-9 godzin. Z tego efektywnie pracuja 4-6. Tu wtrace, ze blokowanie dostepu do pewnych zasobow internetu wcale nie poprawia, a czesto pogarsza ten wynik. Dla uproszczenia przyjme ze kazda osoba pracuje 5 = (6+4)/2 godzin dziennie. Do pracy uzywaja pewnego zbioru narzedzi. Nie znaja jednak wielu zastosowan tych narzedzi. Znaja pewne ich zastosowania i do tego maje wlasne przyzwyczajenia. Co sie stanie jesli pokazesz im jak uzywac narzedzi tak aby zaoszczedzili 10 minut dziennie?

10 min * 6 osob *20 dni pracy na miesiac * 12 miesiecy = 14400 minut
14400 minut / 60 minut / 8 godzin deklarowanej pracy na dzien = 30 dni
14400 minut / 60 minut / 5 efektywnej pracy = 48 dni!

Tak. Kazdy latwo sobie dalej przemnozy ile to pieniedzy (programisci pomnoza przez p, managerowie przez p*m, gdzie m>8). Jaki z tego wniosek?

Doskonalenie rzemiosla do pewnego poziomu oplaca sie.

W kolejnych postach opisze historie programisty Henia, ktoremu udalo sie wprowadzic pewne usprawnienia w projekcie, w ktorym pracuje. Zastanowimy sie tez ile oszczednosci moglo to wprowadzic.

A ile oszczednosci moze to wprowadzic w twojej pracy, niekoniecznie zawodowej?