Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00129 002596 22742114 na godz. na dobę w sumie
wyszukaj dokładnie | pobierz wtyczkę
Zarządzanie projektami informatycznymi. Eseje - książka
Zarządzanie projektami informatycznymi. Eseje - książka
Autor: Liczba stron: 352
Wydawca: Helion Język publikacji: polski
ISBN: 83-246-0273-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook, audiobook).
Czytaj online.
Komentuj

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.

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.

Znajdź podobne książki Ostatnio czytane w tej kategorii

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)

Gdzie kupić całą publikację:

Zarządzanie projektami informatycznymi. Eseje
Autor:
Sklep
Format
Cena
Helion.pl Helion.pl
książka
47,00 zł
Idź do sklepu »

Opinie na temat publikacji:

Inne popularne pozycje z tej kategorii:

Czytaj również:

Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: