Darmowy fragment publikacji:
Zarz¹dzanie projektami
informatycznymi. Eseje
Autor: Joe Marasco
T³umaczenie: Agata Kliber, Pawe³ Kliber
ISBN: 83-246-0273-9
Tytu³ orygina³u: The Software Development Edge:
Essays on Managing Successful Projects
Format: B5, stron: 352
Zarz¹dzanie projektami informatycznymi ró¿ni siê od zarz¹dzania projektami
innych typów. Jest to zwi¹zane przede wszystkim ze specyfik¹ bran¿y i produktu.
Projekty IT oddawane nieterminowo, nie spe³niaj¹ce za³o¿eñ funkcjonalnych
i wielokrotnie przekraczaj¹ce za³o¿one bud¿ety przesz³y ju¿ do legendy.
Co jest przyczyn¹ takich sytuacji? I co trzeba zrobiæ, by ich unikn¹æ?
Odpowiedzi na te pytania znajdziesz w ksi¹¿ce „Zarz¹dzanie projektami
informatycznymi. Eseje”. Jej autor, Joe Marasco, legendarny mened¿er z firmy Rational
Software, przedstawia swój punkt widzenia na temat kierowania projektami IT.
Czytaj¹c jego przemyœlenia, dowiesz siê, czy mo¿liwe jest stworzenie realnego
harmonogramu, rozwi¹zanie typowych problemów w niekonwencjonalny sposób
i zbudowanie zgranego zespo³u programistów. W ka¿dym eseju znajdziesz ciekawe
spostrze¿enia i sporo humoru.
(cid:129) Problemy, przed jakimi staje ka¿dy kierownik projektu
(cid:129) Metodologie wytwarzania oprogramowania
(cid:129) Modelowanie w UML i jego znaczenie w projekcie
(cid:129) Tworzenie harmonogramów
(cid:129) Budowanie zespo³u i zarz¹dzanie nim
(cid:129) Sposoby rozwi¹zywania sytuacji kryzysowych
(cid:129) Wypuszczanie produktu na rynek
Jeœli chcesz tworzyæ wartoœciowe produkty, dostarczaæ je klientowi na czas i nie
przekraczaæ zaplanowanego bud¿etu, ta ksi¹¿ka jest przeznaczona w³aœnie dla Ciebie.
IDZ DO
IDZ DO
PRZYK£ADOWY ROZDZIA£
PRZYK£ADOWY ROZDZIA£
SPIS TREŒCI
SPIS TREŒCI
KATALOG KSI¥¯EK
KATALOG KSI¥¯EK
KATALOG ONLINE
KATALOG ONLINE
ZAMÓW DRUKOWANY KATALOG
ZAMÓW DRUKOWANY KATALOG
TWÓJ KOSZYK
TWÓJ KOSZYK
DODAJ DO KOSZYKA
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
CENNIK I INFORMACJE
ZAMÓW INFORMACJE
ZAMÓW INFORMACJE
O NOWOŒCIACH
O NOWOŒCIACH
ZAMÓW CENNIK
ZAMÓW CENNIK
CZYTELNIA
CZYTELNIA
FRAGMENTY KSI¥¯EK ONLINE
FRAGMENTY KSI¥¯EK ONLINE
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
O autorze
Wstęp
Przedmowa
CZĘŚĆ I OGÓLNIE O ZARZĄDZANIU
Rozdział 1. Zacznijmy od początku
Dlaczego potrzebne jest dobre oprogramowanie?
Punkty stałe
Odbiorcy
Przyrostowe rozwiązywanie problemów na zegarze
Podsumowanie
Rozdział 2. Moja droga do informatyki
Wyzwanie
Odpowiedź
Jak to działało?
Dlaczego to pokolenie inżynierów było wyjątkowe?
Obliczenia
Szacowanie rzędu wyniku
Co zatem z komputerami?
Nasza spuścizna
Podsumowanie
Rozdział 3. Wspinaczka
Wspinaczka na wysoką górę
Najczęstsze przyczyny porażki
Składniki sukcesu
Czynnik ludzki
Podsumowanie
11
13
15
19
21
22
23
24
25
28
29
29
30
31
33
34
35
37
38
39
41
42
48
49
51
51
6
SPIS TREŚCI
Rozdział 4. Zarządzanie
Kierowanie zespołem
Podsumowanie
CZĘŚĆ II RÓŻNICE W OPROGRAMOWANIU
Rozdział 5. Rzeczy najważniejsze
Programowanie przyrostowe
Roscoe Leroy
Rezygnujemy z modelu kaskadowego
Inna skrajność
Pierwszy rysunek Roscoe
Drugi rysunek Roscoe
Chwileczkę!
Skracanie wektorów
Zastosowanie do produkcji oprogramowania
Nauka stosowana i kierunek krótkich wektorów
Namierzanie ryzyka
Czy słyszałeś to już wcześniej?
Więcej o nauce praktycznej
Zastosowanie biznesowe
Efekt zatrudnienia
Na chłopski rozum
Podsumowanie
Rozdział 6. Modelowanie
Jak wyjaśnić, co to jest UML?
Co to jest UML i dlaczego jest ważny?
Drugi przykład, mniej trywialny
Trzeci przykład
A teraz jak to się ma do programowania…
Podnosimy poziom abstrakcji
Podsumowanie
Rozdział 7. Kodowanie
Jak menedżerowie mogą uczyć się nowych języków programowania?
Lepiej zdefiniowany problem
Co powinien zawierać „standardowy problem”?
„Zgadnij, jakie to zwierzę”
Czy „Zgadnij, jakie to zwierzę” spełnia właściwe kryteria?
A czy przechodzi przez test „No i co?”?
To jest Twoja gra
Podsumowanie
Rozdział 8. Wychodzimy z tym na świat
Zbuduj je, a oni przybędą
Na początku była skrzynia z piaskiem
A właściwie dlaczego tworzenie produktu ma być trudne?
A co z podejściem przyrostowym?
Podsumowanie
53
54
60
63
65
65
66
67
69
69
70
71
72
72
73
74
75
76
77
78
80
81
83
84
85
85
87
89
90
90
93
94
95
95
97
98
99
100
100
103
104
105
106
111
111
SPIS TREŚCI
CZĘŚĆ III Z PUNKTU WIDZENIA MENEDŻERA PROJEKTÓW
Rozdział 9. Coś za coś
Piramida projektu
Pięć, a nie cztery
Wchodzimy do piramidy
Nowa zmienna — wysokość
Objętość piramidy jest stała
Dygresja statystyczna
Dobry pomysł, zły rozkład
Znaczenie dla rzeczywistych projektów
Jak to się ma do rzutu monetą?
Więcej ufności
Ważne ograniczenia
A wszystko to przez ryzyko
Podsumowanie
Rozdział 10. Estymacja
A jeśli kierujemy się zdrowym rozsądkiem?
Czekolada a wanilia
Roscoe wyjaśnia
Roscoe kontynuuje
Kalendarz Roscoe
Obliczenia Roscoe
Roscoe zabiera się za oprogramowanie
Roscoe składa relację
No proszę, jednak zrobiliśmy coś dobrze
Roscoe podsumowuje
Roscoe podnosi rękawicę
No proszę, jednak zrobiliśmy coś dobrze — część druga
Roscoe przyjęty do bractwa kierowników projektów informatycznych
Podsumowanie
Rozdział 11. Harmonogramy
Roscoe porusza problem: jak bardzo się spóźnimy?
Joe ma okazję się odgryźć
Roscoe powraca
Kronika przestępców wg Roscoe
Wykres Roscoe
Ostatnie zastrzeżenie
Niemiła uwaga końcowa
Podsumowanie
Rozdział 12. Rytm
Postępy prac projektowych widziane okiem fizyka
Wtrąca się rzeczywistość
A co z podejściem przyrostowym?
Ostatni wykres
Podsumowanie
7
113
115
116
118
119
120
120
121
124
126
126
127
128
133
134
137
138
138
139
139
140
141
141
141
142
143
143
144
145
146
147
148
149
150
151
151
152
153
154
155
156
165
166
171
173
8
SPIS TREŚCI
CZĘŚĆ IV CZYNNIK LUDZKI
Rozdział 13. Polityka
Kontekst
Definicja
Trzy możliwości
Polityka jest nieunikniona, ale…
Gdy w grę wchodzi polityka
Postrzeganie polityki przez inżynierów
Środowisko wysokiego zaufania
Inne rodzaje złej polityki
Podsumowanie
Rozdział 14. Negocjacje
Komunikacja jest wszystkim
Roscoe wykłada swoją teorię
Czy to już wszystko?
Podsumowanie
Rozdział 15. Werbowanie
Roscoe się sparzył…
…i natychmiast przechodzi do sedna sprawy
Wezuwiusz wybucha
Jak to się robi w Teksasie?
Znaczenie dla programowania
Pies zjadł moją pracę domową
Wojna o specyfikację?
Trzy najczęstsze wymówki
Jeszcze jedna sprawa
Pchnięcie, parada i riposta
Gra w kurczaka przy dużym projekcie
Koniec znanego nam sposobu tworzenia oprogramowania?
Rozwinięcie kontra konstrukcja
Trudna przyjaźń
Podsumowanie
Rozdział 16. Wynagrodzenia
Ruszyć z przepływem
Przepływ a produktywność programistów
Zastosowanie modelu przepływu do kwestii wynagrodzeń
Pieniądze to nie wszystko
Podsumowanie
CZĘŚĆ V MYŚLENIE NIEKONWENCJONALNE
Rozdział 17. Lekcja historii
Nie pozwólmy, aby król był architektem
Rzeczy nie zawsze są takie, jakimi się wydają
175
177
178
179
179
181
182
185
186
187
188
191
191
192
198
199
201
202
202
202
203
204
204
205
207
208
209
210
210
211
212
212
215
216
217
219
228
229
233
235
236
236
SPIS TREŚCI
Sprawdzanie planów
Znaj swoją niewiedzę
Kontynuacja przywództwa
Jak zwykle w pośpiechu
Skupiamy się na rzeczach nieistotnych
Gdy plan jest zły
Testowanie
Prototyp kontra produkt
Śledztwo
Podsumowanie
Rozdział 18. Błędne analogie
Houston, mamy problem
Prawa Newtona
Wszystko jest względne
Kwantowy nonsens
Śmierć cieplna
Inne przykłady
Dobra nauka
Podsumowanie
Rozdział 19. Problem aktualizacji
Odświeżanie oprogramowania wbudowanego
Obecna sytuacja
Gry w aktualizację oprogramowania
Skromna propozycja
Jeszcze raz — aktualizacja oprogramowania
Dodatkowe korzyści
Dlaczego będzie to działać?
Dalsze możliwości
Co z piractwem komputerowym?
Zanim przejmie to słońce
Podsumowanie
Rozdział 20. Nie tak bardzo losowe liczby
Roscoe zaczyna opowiadanie
Symulacja uderzenia
Pierwsze kroki
Kolejne kroki
Otrzymanie większej liczby prawdopodobieństw
Oczywiście, dawno już zapomnieliśmy o baseballu
Rzeczywistość jest paskudna
Rozwiązanie Poniedziałka
Lekcja nauczona
Podsumowanie
9
236
237
237
237
237
237
238
238
238
238
239
239
241
243
246
249
251
252
252
253
254
255
256
256
257
258
259
260
261
262
262
265
266
266
268
270
271
273
273
274
279
280
1 0
SPIS TREŚCI
CZĘŚĆ VI SPRAWY ZAAWANSOWANE
Rozdział 21. Kryzys
Pięć dni ryby
Rynek ryb
Dzień pierwszy — nieświadomość
Dzień drugi — nie poruszamy tematu
Dzień trzeci — wkracza „Złota Rączka”
Dzień czwarty — punkt zwrotny
Dzień piąty — dwie ścieżki krytyczne
Morał
Podsumowanie
Rozdział 22. Wzrost
Kwestia wzrostu
Model naiwny
Konsekwencje modelu
Przykład
Nieliniowość
Wezwanie do działania
Wnioski
Nomogram
Arkusz kalkulacyjny
Podsumowanie
Rozdział 23. Kultura
Czym jest kultura?
Słabe i silne kultury
Określanie wartości, jakimi kieruje się przedsiębiorstwo
A przy tworzeniu oprogramowania oznacza to…
Tworzenie silnej kultury
Gdy szukamy pracy
Ostatnie słowo
Podsumowanie
Rozdział 24. Zbieramy wszystko razem
Chłopiec na posyłki
Macher
Mistrz
Więcej o mistrzu
Rozkład populacji
Jeszcze kilka słów o modelu
Podsumowanie
Podziękowania
Skorowidz
281
283
284
284
284
284
285
286
286
287
287
289
289
291
294
299
301
302
304
305
307
307
309
310
311
312
315
317
321
322
322
323
324
326
329
330
331
333
333
337
341
R O Z D Z I A Ł 1 1 .
ak naprawdę to dopiero na tym poziomie zaczyna się problem. Przeciętny
menedżer projektów traktuje harmonogram jako dokument, nad którym się
stale pracuje, natomiast jego przełożony — jako kontrakt. Ta „subtelna” róż-
nica jest przyczyną wielu nieporozumień.
Cała sytuacja prowadzi do tego, że zwykle powstają dwa harmonogramy:
jeden, tzw. „harmonogram wewnętrzny”, jest dość napięty, tak aby programi-
ści zmieścili się z pracą w czasie krótszym niż wymagany; drugi, tzw. „ze-
wnętrzny”, przeznaczony jest dla reszty firmy i stanowi modyfikację harmo-
nogramu wewnętrznego o pewną granicę bezpieczeństwa. Szczerze mówiąc,
nigdy nie byłem zwolennikiem dwóch harmonogramów. Trudno jest utrzy-
mać je w ukryciu, a kiedy sytuacja wyjdzie na jaw, każdy z nich traci wiary-
godność, bez względu na to, jak bardzo staramy się wyjaśnić, że jeden jest
„harmonogramem prac programistycznych”, a drugi: „harmonogramem biz-
nesowym”. Radziłbym trzymać się jednego harmonogramu i starać się, aby
był on jak najbardziej spójny.
Ostatecznie trudno jest dyrektorowi naczelnemu dyskutować z kierownikiem
produkcji oprogramowania o jego harmonogramie. Na podobne trudności
napotyka kierownik produkcji oprogramowania, próbując omawiać harmo-
nogram stworzenia komponentu czy podsystemu z kierownikiem technicznym,
odpowiedzialnym za tę część. Przyczyna jest prosta — trudno tu o cokolwiek
się targować. Oczywiście można się spierać, że coś mogłoby zostać wykonane
szybciej, ale ostatecznie jest to kwestia subiektywnego osądu i naprawdę bardzo
rzadko się zdarza, żeby czas wykonania jakiejś części był bardzo źle oszaco-
wany. W rzeczy samej, trudności w szacunkach dotyczących prac przy pro-
jektach informatycznych mają dwie przyczyny. Pierwsza z nich to zależności,
1 4 8
ZARZĄDZANIE PROJEKTAMI INFORMATYCZNYMI. ESEJE
które na początku projektu nie są znane. Skutkiem jest to, że jeśli jedna część
się opóźnia, to opóźnia się też inna, której projektanci czekają na krytyczny
komponent, dotychczas nieznany. Dopiero jeśli okaże się, że jeszcze jakaś
część się opóźnia, zależność zostaje wykryta.
Dobrym rozwiązaniem problemów związanych z opóźnianiem się harmo-
nogramów jest podejście przyrostowe. We wczesnych iteracjach następuje
bowiem złożenie dużych części w celu przetestowania, jak będzie z grubsza
działał cały system. To złożenie powinno pozwolić na wykrycie „ukrytych”
zależności. Następnie można spróbować zastosować rozmaite strategie: wy-
musić rozłączenie związanych ze sobą elementów, skupić więcej uwagi na
punkcie krytycznym i inne. Innym sposobem jest zmuszenie poszczególnych
zespołów do dopracowania zewnętrznych interfejsów podsystemowych, za-
nim jeszcze zostaną stworzone interfejsy wewnętrzne. W ten sposób, dzięki
zaistnieniu publicznych interfejsów, inne grupy będą mogły kontynuować
pracę. O ile interfejsy zewnętrzne pozostaną stabilne, wnętrze podsystemu
może się zmieniać bez szkody dla całości.
Druga, bardziej zdradziecka przyczyna opóźnień w projektach informa-
tycznych wynika z tego, że opóźnienia następują stopniowo i przyrostowo.
Fred Brooks wykazał już wiele lat temu, że projekty, za każdym razem opóź-
niając się o dzień, opóźniają się o rok. Jeśli osiągnięcie pierwszego kamienia
milowego opóźni się o tydzień czy dwa, to prawdopodobnie prac nie da się
już przyśpieszyć i pozostałe kamienie milowe zostaną osiągnięte z takim sa-
mym lub większym opóźnieniem. Tak przysłowiowa kropla drąży kamień.
Nawet posiadając najbardziej gorliwego menedżera, trudno jest tego unik-
nąć. Z drugiej strony menedżer, który nie ma oczu i uszu otwartych, powi-
nien mieć się na baczności!
Roscoe porusza problem:
jak bardzo się spóźnimy?
Już wcześniej poznaliśmy Roscoe Leroya1, niecierpliwego, emerytowanego
inżyniera górnictwa. To był ponury, deszczowy dzień, gdy Roscoe zaparkował
swojego pikapa przed moim domem i, walcząc z wiatrem, dobiegł do drzwi.
„Nadchodzi słońce”, pomyślałem.
Jak zapewne pamiętacie, Roscoe jest kumplem mojego taty, człowiekiem
z bogatym doświadczeniem życiowym. Przyczyną, dla której słucham Roscoe,
jest to, że wnosi on powiew świeżości do wszystkiego, czego się tknie, a jego
sposób myślenia nie jest obciążony mądrością konwencjonalną, powszechnie
1 Czytelnik, który czyta tę książkę nie po kolei i jest to jego pierwsze spotkanie z Roscoe,
powinien zajrzeć do rozdziału piątego: „Rzeczy najważniejsze” i dziesiątego: „Estymacja”.
ROZDZIAŁ 11. HARMONOGRAMY
1 4 9
uznanymi doktrynami czy teoretycznymi dywagacjami. Moje źródła donoszą,
że uratował więcej niż jedną inżynierską skórę w trakcie swojej „kariery”2.
„No więc”, zacząłem, „jak ci idzie kariera menedżera projektów informa-
tycznych?”.
„Oglądacie skutek braku porozumienia”, rozpoczął cytatem z filmu Nie-
ugięty Luke3. Niemalże ujrzałem przed oczami błysk ciemnych okularów ka-
pitana i mogłem tylko mieć nadzieję, że zakończenie będzie mniej tragiczne
niż w filmie.
„Po pierwsze, projekty informatyczne zawsze mają opóźnienia. Zawsze.
A to wcale nie jest dobrze. Poza tym podając jakiekolwiek oszacowania,
uwzględnia się zwykle błąd: »plus minus coś tam«. Co do projektów infor-
matycznych — zdaje się, że zgubiliście gdzieś ten »minus«. Ten, kto dokonuje
szacowania, mógłby równie dobrze powiedzieć: zrobimy, co w naszej mocy”.
Nie mogłem się z nim nie zgodzić. Obserwacje Roscoe nie były pozbawio-
ne dozy słuszności. Roscoe skrytykował mnie za tę „dozę”.
„Pokaż mi choć jeden projekt, który udało się zrobić przed czasem!”, za-
żądał. Skrzywiłem się. Owszem, przypominam sobie, że raz osiągnęliśmy
kamień milowy przed czasem, ale cały projekt?
„Według mnie problem z oszacowaniem długości prac polega na tym, że
należy obliczyć, jak bardzo się opóźnimy”, uśmiechnął się Roscoe.
Joe ma okazję się odgryźć
Na chwilę odebrało mi mowę. Pomyślałem, że mógłbym ukazać w nieco in-
nym, pozytywnym świetle moje lata opóźnień przy projektach. Pokażę temu
przemądrzalcowi, że nie zjadł wszystkich rozumów.
„W zasadzie, Roscoe”, rozpocząłem spokojnie, „w projektach nie robimy
jednego oszacowania. Na początku dokonujemy oszacowań wstępnych. Na-
stępnie, kiedy się już trochę wdrożymy, dokonujemy kolejnej estymacji. W za-
sadzie oszacowań czasu zakończenia dokonuje się przez cały czas trwania
projektu. Jeśli więc dokonujemy predykcji czasu zakończenia, możemy jedy-
nie powiedzieć, jak bardzo się spóźnimy, pod warunkiem że wykonamy
ostatnie oszacowanie, gdyż tak naprawdę to właśnie ostatnia estymacja za-
wiera wszystkie informacje, jakie mamy aż do danego momentu”.
2 Roscoe uśmiałby się, słysząc słowo „kariera” w odniesieniu do jego pracy.
„Po prostu staram się zrobić to, co do mnie należy, synu”, odpowiada, gdy zapytać
go o którekolwiek z jego osiągnięć czy klęsk.
3 Nieugięty Luke, USA (1967), reż. S. Rosenberg (cytat „What we’ve got here is failure
to communicate” pochodzący z filmu zajął 11 miejsce w rankingu 100 najsłynniejszych
cytatów filmowych, przeprowadzonym w 2005 r. przez Amerykański Instytut Filmowy
— przyp. tłum.).
1 5 0
ZARZĄDZANIE PROJEKTAMI INFORMATYCZNYMI. ESEJE
„Zgadza się, synu”, powiedział Roscoe. „I powiem ci coś jeszcze. Lepiej,
żeby twoje oszacowania w miarę upływu czasu były coraz dokładniejsze. Są
dwa powody. Po pierwsze, w miarę jak prace się posuwają, stajesz się mą-
drzejszy i bardziej doświadczony. Po drugie, jest coraz mniej do zrobienia. Na
początku masz dużo niewiadomych i dużo problemów do rozwiązania. Z dru-
giej strony — masz więcej czasu na naprawę poprzednich błędów. Niech się
zastanowię…”.
Przyjąłem, że ta runda zakończyła się remisem. Roscoe dokończył swoją
kawę (czarna, bez cukru) i, z pewną złością, zapalił swoje cygaro. Mógłbym
powiedzieć, że dałem mu trochę do myślenia. Było jasne, że starał się roz-
gryźć, dlaczego oszacowanie końca prac w projektach informatycznych było
o wiele trudniejsze niż w przypadku innych projektów, którymi kierował
wcześniej.
Roscoe powraca
Nie minęło dużo czasu, gdy Roscoe powrócił. Nastawiłem się na ponowne
wywrócenie mojego małego wszechświata do góry nogami.
Roscoe był tym razem dużo spokojniejszy. „Jak wykazałem poprzed-
nim razem, najprawdopodobniej każdy projekt informatyczny będzie miał
opóźnienie. Pozostaje pytanie: jak bardzo? No więc myślę, że mam pewien
pomysł”.
„Jak zwykle rozwiązanie wymaga policzenia pierwiastka kwadratowego,
a jednostką pomiaru jest — ta dam! — tydzień. Uważam, że dobrze zarządzany
projekt informatyczny będzie miał opóźnienie, mierzone w tygodniach, równe
pierwiastkowi z liczby tygodni pozostałych do końca projektu. Jeśli na przy-
kład powiesz mi, że skończysz za 16 tygodni, to uznam, że będziesz gotów
gdzieś między 16 a 20 tygodniem”.
Widać było, że Roscoe głęboko to przemyślał. Znów pierwiastki kwadra-
towe? Jakim cudem? Czy Roscoe ma jeszcze coś w zanadrzu?
„W zasadzie można wyróżnić pięć osobnych przypadków”, kontynuował.
„Rozpracowałem wszystkie”.
Im dalej Roscoe zagłębiał się w swoje teorie, tym uważniej go słuchałem.
„Po pierwsze, wyróżniłem projekty dobrze zarządzane, kierowane przez
faceta, który wie, co robi. To on właśnie zakończy projekt gdzieś między
swoim oszacowaniem a pierwiastkiem z tygodni pozostałych do końca pro-
jektu”.
„Od czasu do czasu zdarzają się tacy menedżerowie, którzy są dobrymi
prognostykami, a także wspaniale sprawdzają się w roli słomianego szefa4.
4 Dla naszych przyjaciół zza oceanu: słomianym szefem nazywamy faceta, który
zarządza nami z dnia na dzień. Nazywamy go też czasem: „kopiącym w tyłek”.
ROZDZIAŁ 11. HARMONOGRAMY
1 5 1
„Moc”5 zstąpi na niego i tak dalej i uda mu się wcześnie skończyć. Może na-
wet z dokładnością do jednego pierwiastka. To też może się zdarzyć”. Przy-
pomniałem sobie moją konsternację, kiedy ostatnio nie mogłem podać takiego
przykładu.
„To są te pozytywne przypadki”, dodał Roscoe.
Kronika przestępców wg Roscoe
„Kolejne 75 stanowią pozostałe trzy przypadki. Będą to przede wszystkim
ci, którzy kończą szybciej niż jeden pierwiastek kwadratowy. Tych denerwu-
jących typów nazywamy szczwanymi lisami. Są niebezpieczni, dlatego że ge-
nerują wysokie koszty. Nie ze względu na spóźnienia, ale na przeszacowanie.
Jedynym sposobem na to, aby skończyć szybciej niż jeden pierwiastek, jest
błędnie oszacować czas zakończenia. A właściwie osobą, którą powinieneś
wylać, jest szef, który kupił to oszacowanie. Albo nie, jak się lepiej zastano-
wię, powinieneś zwolnić obu”.
Zacząłem utwierdzać się w przekonaniu, że pan Leroy zrewolucjonizuje
sposób, w jaki postrzegamy problem.
„Potem mamy jeszcze tych, którzy kończą między jednym a dwoma pier-
wiastkami. Z nich może jeszcze będą ludzie. Prawdopodobnie dopiero zaczy-
nają. Muszą się jeszcze wiele nauczyć w sprawach estymacji i zarządzania.
Oni też generują koszty, ale jeśli trochę nad nimi popracujemy, uda się nam
przenieść ich do przedziału jednego pierwiastka. Jeśli mają choć trochę oleju
w głowie, znajdą się ostatecznie w odpowiednim miejscu”.
„No i na końcu są jeszcze ci, którzy opóźniają się bardziej niż o dwa pier-
wiastki. Cóż, albo wymknęli się oni spod kontroli, albo nie mają zielonego
pojęcia o estymacji. Sam musisz zdecydować, czy są oni beznadziejnymi pro-
gnostami, czy też w ogóle nie potrafią zarządzać. W zasadzie to, jaka jest od-
powiedź, nie ma znaczenia. Jedynym rozwiązaniem jest wyrzucenie tych ludzi,
gdyż pracując z nimi, szybko możesz pójść z torbami”.
Wykres Roscoe
Wtedy Roscoe z dumą wyciągnął swój wykres (rysunek 11.1) w celu zilustro-
wania przedstawionej teorii. Był tak dumny z tego, że mógł użyć swojej nowej
zabawki — Microsoft Excel, że omal nie pękł. „Tych dobrych menedżerów
oznaczyłem jako „bardzo dobrzy” i „świetni”. Tych, którzy kończą między
jednym a dwoma pierwiastkami, oznaczyłem jako „potrzebują praktyki”. Dwa
przypadki patologiczne też są odpowiednio oznaczone”.
5 Domyślam się, ze Roscoe odwołuje się tu do boskiej interwencji.
1 5 2
ZARZĄDZANIE PROJEKTAMI INFORMATYCZNYMI. ESEJE
Rysunek 11.1. Szacowanie końca prac
„No to masz wszystko. Granica między „bardzo dobrym” a „świetnym” to:
„na czas”. Wszystko, czego potrzebujesz, na jednej kartce papieru”.
Tu Roscoe zakończył, moszcząc się wygodniej na krześle.
Ostatnie zastrzeżenie
„No dobrze, Roscoe”, odpowiedziałem. „Jak zwykle zrobiłeś coś z sensem.
I naprawdę, jestem pod wrażeniem, że chcesz policzyć, jak bardzo się spóźnisz.
Ale jest jeden słaby punkt twojej teorii”.
Roscoe natychmiast się ożywił. Zawsze lubił wyzwania.
„Problem leży w tym, że nie wiem, do której kategorii należy menedżer,
z którym pracuję. Jeśli wiem, że pracuję z asem, to nie ma problemu, ale co,
jeśli nigdy wcześniej nie pracowałem z tym człowiekiem?”.
„Ha!”, odpowiedział Roscoe. „To nic innego, jak problem kalibracji. Zaraz
ci pokażę, jak to zrobić”.
„Przede wszystkim, za każdym razem, kiedy proszę kogoś o zrobienie czegoś,
proszę o też o oszacowanie czasu zakończenia pracy. A następnie — i teraz
uważaj — zapisuję to”.
ROZDZIAŁ 11. HARMONOGRAMY
1 5 3
W tym momencie nieopatrznie rzuciłem ciętą uwagę o jego krótkim ołówku.
„Słuchaj, Panie Mądraliński. Najkrótszy ołówek jest dłuższy niż najdłuższa
pamięć. I nie zapominaj, że pan Tiger Woods6, kiedy gdzieś tam walczy o swoje
miliony, też zapisuje swoje wyniki przy pomocy takiego krótkiego ołówka”.
Po takiej krytyce, zdecydowałem się zamknąć usta i zamienić się w słuch.
„A więc, wracając do oprogramowania, spróbowałbym skłonić moich
kandydatów do zaangażowania się w rozmaite podprojekty i zadania o róż-
nym czasie trwania. Naturalnie, powinieneś uzyskać od nich oszacowania na
początku każdej iteracji w projekcie przyrostowym. Zapisujemy każdą pro-
gnozę i sprawdzamy, jak nasi kandydaci sobie poradzili”.
„Otrzymujemy masę punktów na moim wykresie dotyczącym czasu sza-
cowanego i rzeczywistego. Niektórzy stale plasują się w jednej strefie. Świetnie.
Zostali ustawieni”.
„Niektórzy będą »rozrzuceni« po całej mapie. Na twoim miejscu usiadł-
bym razem z nimi i spróbował wspólnie to zrozumieć. Ale wcześniej czy póź-
niej i oni staną się przewidywalni, albo ty sam skierujesz ich na odpowiednią
drogę. I nawet ty już wiesz, co zrobić z tymi, którzy znajdą się w strefie
»szczwanych lisów« lub »więcej niż dwa pierwiastki«. Uważaj tylko, żeby
drzwi nie uderzyły ich za mocno w plecy, jak będą wychodzić”.
„To narzędzie jest naprawdę przydatne dla tych, którzy znajdą się w strefie
»potrzebują doświadczenia«. Musimy pokazać im, co powinni zrobić, aby
pomóc nam w zdobywaniu pieniędzy, a nie traceniu ich. Muszą postarać się
pracować tak, aby trafić do strefy »mniej niż jeden pierwiastek«, niezależnie
od ich oszacowań”.
„Widzisz, Joe”, uśmiechnął się Roscoe, siadając ponownie, „dopóki rzecz
jest przewidywalna, to się nie martwię. Mogę przeżyć opóźnienie wielkości
jednego pierwiastka, jeśli wiem, że taki będzie rozmiar strat. Mogę to za-
planować”.
Zrobić coś z niczego. Nigdy o tym nie pomyślałem.
Niemiła uwaga końcowa
„Nawiasem mówiąc”, zakończył Roscoe, „czy zauważyłeś, co się dzieje w moim
modelu, kiedy zbliżamy się do końca projektu?”. Nie zauważyłem, ale teraz
mnie to uderzyło jako interesujące przejście graniczne.
„Kiedy dochodzimy do prognozy: »skończymy za tydzień«, pierwiastek z 1
daje 1. Koniec z precyzją. W ostatnim tygodniu zawsze możemy powiedzieć,
że potrzebujemy jeszcze tygodnia. Bądźmy szczerzy — zawsze znajdzie się jakaś
6 Tiger Woods (ur. 1975r., Cypress, Kalifornia) — amerykański gracz w golfa,
jeden z największych przedstawicieli tej dyscypliny — przyp. tłum.
1 5 4
ZARZĄDZANIE PROJEKTAMI INFORMATYCZNYMI. ESEJE
rzecz do zrobienia natychmiast po tym, jak poprzednią wykreśli się z listy.
Więc, nawet teoretycznie, projekty mogą trwać w nieskończoność, wydłuża-
jąc się z tygodnia na tydzień”.
„Dlatego nazywamy to »dążeniem do najkrótszego strzału«7.W ostatnim
tygodniu podejmujesz decyzje o innym charakterze. Szacowanie, jak wiele
masz jeszcze zrobić, mija się z celem. Mogę cię doprowadzić do ostatniego ty-
godnia, ale wykończenie to już twoja sprawa”.
Mam szczerą nadzieję, że Roscoe będzie rozwijał swoją karierę. Tak wiele
musimy się jeszcze nauczyć.
Podsumowanie
Kiedy mówimy o harmonogramach, zawsze pojawiają się dwie kwestie doty-
czące ludzi. Pierwsza z nich to przewidywalność. Menedżerowie ciągle się
skarżą, że nie mogą żyć w tej niepewności. Jak wykazał Roscoe, winne są wy-
niki, które pojawiają się niezależnie od planu, tak jak im się podoba. Gdyby
ludzie stale się opóźniali, można by z tym jakoś żyć.
To prowadzi nas do drugiej kwestii: pomysłu kalibracji. Aby poprawić
przewidywalność, należy ustalić dla każdego programisty, co zapisy histo-
ryczne mówią o jego zdolnościach do estymacji. Jeśli wiemy, kto jest zwykle
zbyt optymistyczny, a kto widzi wszystko na czarno, jest to cenna informacja.
Wydaje mi się, że dobrzy menedżerowie robią to wszystko w ramach ana-
lizy jakościowej. Roscoe pokazuje, że powinniśmy zbierać dane w trakcie po-
suwania się prac projektowych, kalibrując i ponawiając kalibrację oszacowań
naszych pracowników przez cały czas. Wiedząc, do jakiego stopnia można
ufać ich przewidywaniom, możemy uzyskać lepszą jakość szacunków zawar-
tych w naszych harmonogramach.
Interesujące, jak zwięzły jest ten rozdział. Zawdzięczam to Roscoe, które-
go pomysły są tak treściwe. Jeszcze raz udowodnił on, że nie trzeba być roz-
wlekłym, żeby przedstawić dobry pomysł.
W następnym rozdziale przeanalizuję dziwne zjawisko. Wszystkie udane
projekty wydają się mieć jakiś wewnętrzny rytm, który rządzi ich postępem.
Skąd się on bierze? Przedstawiam model, który może wyjaśnić ten fenomen.
7 Jedno z nielicznych nawiązań Roscoe do golfa. Aby zdobyć punkt, należy wbić piłkę
do dołka. Są to zazwyczaj tzw. „krótkie strzały”. Dążenie do krótkiego strzału oznacza
dokonanie ostatnich poprawek, aby zakończyć pracę.
Pobierz darmowy fragment (pdf)