Zasada Scarlett O'Hara
Organizacja projektu 11/11/2006 · Link Widzieliście zapewne film "Przeminęło z wiatrem". W pewnym momencie Scarlett zbiega ze schodów wypowiadając zdanie Pomartwię się tym jutro (przynajmniej tak to zapamiętałem - w wersji oryginalnej jak się okazuje brzmi to: I can't think about that right now. If I do, I'll go crazy. I'll think about that tomorrow. ) Zapewne nie będąc tego świadomą Scarlett udzieliła nam doskonałej rady dotyczącej planowania działań w projektach informatycznych.Zasada Scarlett O'Hara to podstawowa zasada optymalizacji działania. Mówiąc wprost polega ona na tym, że rozwiązywanie problemów odkładamy tak późno, jak to tylko możliwe. Przykład - napisany kod obsługujący wyświetlanie informacji na stronie internetowej będzie wymagał refaktoryzacji. Na razie jest ok, ale jeśli wzrośnie obciążenie - nie podoła. Wydaje nam się, że mamy ze trzy miesiące czasu, ale pada argument "i tak trzeba to będzie zrobić, więc zróbmy to teraz". Jeśli zdecydujemy się stosować zasadę Scarlett, to odkładamy to zadanie. Monitorujemy ruch, by wrócić do niego, gdy pojawi się potrzeba. Inny przykład - pojawia się nowa wersja platformy bazodanowej. W ogólności warto na nią zmigrować (i prędzej czy później będzie to konieczne, choćby ze względu na kończący się support dla starszych wersji), ale w tej chwili nie przyniesie nam to żadnych istotnych korzyści. Zgodnie z zasadą - nie migrujemy, dopóki zmiana sytuacji nie spowoduje, że zaniechanie migracji oznaczać będzie kłopoty (brak supportu, trudności z opracowaniem nowych modułów etc). Jeszcze inny przykład - w projekcie pisanym na zamówienie, w umowie jest zapisane wymaganie wykonania modułu archiwizującego stare dane. Ponieważ system jest dopiero wdrażany, więc moduł archiwizacji będzie potrzebny dopiero za dwa lata. Aplikujemy zasadę: robimy inne moduły, które będą potrzebne wcześniej. Albo tak: system będzie trzeba zintegrować z innym z wykorzystaniem JMS na JBossie. Nikt z naszego zespołu nie zna tej technologii. Skądinąd jednak wiadomo, że system z którym mamy się integrować nie będzie uruchomiony przez najbliższe pół roku. Co robimy? Nic! Czekamy. Pomartwimy się tym jak przyjdzie czas. Dlaczego to działa? Otóż z następujących powodów:- Jest to optymalizacja wykorzystania zasobów. W każdym momencie projektu powinniśmy mieć aktualną priorytetową listę zadań do zrobienia i kierować siły tam, gdzie mogą przynieść największą korzyść (czyli do najważniejszych zadań). Uwaga - priorytety zmieniają się w czasie, coś co w ogólności jest super ważne (integracja) może być dziś jeszcze nieistotne (niewdrożony system, z którym mamy się integrować).
- Unikanie niepewności. Póki nie ma fizycznie systemu z którym mamy się realnie integrować, to musimy polegać na dokumentacji. A przecież może zostanie wdrożony w innej wersji? Może dokumentacja jest niedokładna? Może życie pokaże, że użytkownicy zmienią zdanie i będą chcieli wymieniać inne dane? Im dłuższy czas między opracowaniem modułu a jego rzeczywistym wdrożeniem, tym mniej polegamy na rzeczywistych wymaganiach, potrzebach, faktach a bardziej na naszym wyobrażeniu. A delta pomiędzy faktami a wyobrażeniem jest proporcjonalna do tego odstępu czasu.
- Unikanie ryzyka zmarnowania wysiłku. Widziałem to wiele razy: moduł, który miał być potrzebny za rok, okazywał się w końcu w ogóle nie potrzebny. Projekt wdrożenia systemu, z którym trzeba się było integrować, był anulowany. Zmieniały się założenia co do technologii. Zmieniali się ludzie. Zmieniały się założenia biznesowe. Koniec końców, całe połacie kodu szły do kosza.
- Czasem rozwiązać dany problem dziś może być łatwiej, taniej, szybciej.
- Problem może zostać zapomniany i wrócić w niedobrym momencie.
- Rozwiązanie zajmuje dużo czasu i później może już być za późno.
Zobacz inne wpisy
PS. Jeszcze taka bajka: Pewien człowiek został skazany w Chinach na śmierć. W ramach wypowiedzenia ostatniej woli zwrócił się do cesarza z prośbą: "Cesarzu, mam niezwykłe umiejętności. Daj mi rok a nauczę małpę mówić. Jeśli mi się uda darujesz mi życie, jeśli nie zetniesz mi głowę.". Zaciekawiony cesarz się zgodził, ale współwięźniowie dziwili się - "Przecież wiesz, że Ci się nie uda! Tylko odsuwasz nieuniknione". Na co odparł więzień - "Kto wie? Może do tego czasu cesarz umrze? Może ja umrę? Może małpa umrze? A może... uda mi się ją nauczyć mówić?!"
11/11/2006,
Marek Rafałowicz
Zdrowa zasada. Uruchamiając nowy serwis też nie warto zajmować się wszystkimi "bokami". Można je dodać, gdy ludzie zaczną używać jego głównych funkcjonalności. Najlepiej dopiero wtedy, gdy zaczną się dodatków domagać.
Robione od początku mogą nigdy się nie przydać... a ktoś je napisał, zaprojektował itp.
Robione od początku mogą nigdy się nie przydać... a ktoś je napisał, zaprojektował itp.
18/11/2006,
tebe
Na każdy przykład gdzie nie martwienie się problemami które się jeszcze nie zmaterializowały jest dobre można podać kontrprzykład gdzie jest złe.
- Czekanie z przejęciem fragmentu kodu od podwykonawcy do momentu w którym jesteśmy zmuszeni go przejąć w najgorętszym okresie realizacyjnym.
- Czekanie z rozwiązaniem problemów wydajnościowych od momentu kiedy zaczynają być problemem (a więc oznaczają niestabilną pracę systemu)
- Czekanie z rozpoczęciem prac na dogranie wszystkich szczegółów powodujące że projekt będzie miał opóźnienie.
Zresztą to trochę tak jakby przymknąć oko na zarządzanie ryzykiem.
To nie tak że jestem za tym żeby robić wszystko na wszelki wypadek już. Ba, częściej działam jak Scarlet O'Hara, acz jeżeli już mam kierować się jakąś regułą to jest to reguła zdrowego rozsądku. Zawsze zdarzą się zarówno sytuacje kiedy lepiej "nie przejmować się tym na co nie masz wpływu" jak i takie kiedy lepiej przejmować się dziś, działać szybko i unikać problemów które na dziś są jeszcze potencjalne. Najważniejsze jest dobrze sytuację ocenić - samo przejmowanie się albo podejmowanie działań są konsekwencjami tej oceny.
- Czekanie z przejęciem fragmentu kodu od podwykonawcy do momentu w którym jesteśmy zmuszeni go przejąć w najgorętszym okresie realizacyjnym.
- Czekanie z rozwiązaniem problemów wydajnościowych od momentu kiedy zaczynają być problemem (a więc oznaczają niestabilną pracę systemu)
- Czekanie z rozpoczęciem prac na dogranie wszystkich szczegółów powodujące że projekt będzie miał opóźnienie.
Zresztą to trochę tak jakby przymknąć oko na zarządzanie ryzykiem.
To nie tak że jestem za tym żeby robić wszystko na wszelki wypadek już. Ba, częściej działam jak Scarlet O'Hara, acz jeżeli już mam kierować się jakąś regułą to jest to reguła zdrowego rozsądku. Zawsze zdarzą się zarówno sytuacje kiedy lepiej "nie przejmować się tym na co nie masz wpływu" jak i takie kiedy lepiej przejmować się dziś, działać szybko i unikać problemów które na dziś są jeszcze potencjalne. Najważniejsze jest dobrze sytuację ocenić - samo przejmowanie się albo podejmowanie działań są konsekwencjami tej oceny.
19/12/2006,
Pawel Brodzinski
Witaj Pawle,
Dzięki za interesujący wpis. Z ciekawością śledzę Twojego bloga, jest to jedno z niewielu aktywnych miejsc w polskim internecie o zarządzaniu projektami. Cieszy mnie, że zdecydowałeś się zabrać głos również tutaj.
Oczywiście masz rację, żadna reguła nie powinna zastępować zdrowego rozsądku. W szczególności dotyczy to reguły Scarlett O'Hary.
Jeśli dobrze rozumiem, Twój punkt widzenia podkreśla rolę zarządzania ryzykiem. Jego esencją jest w końcu wyszukiwanie i przewidywanie potencjalnych kłopotów i przygotowywanie się zawczasu do działań zaradczych.
Nie jest moją intencją by namawiać do ignorowania przyszłych niebezpieczeństw i zaniechania powyższych praktyk. Raczej zależało mi na tym, by pokazać również tę drugą stronę medalu. Przygotowywanie się ze wszystkim na zapas byłoby dobre w bardzo przewidywalnym środowisku, które jest niezmienne w czasie. Rzeczywistość jest jednak zwykle dramatycznie inna i dlatego decyzje lub działania, które można odroczyć, mogą właśnie to ryzyko zmniejszać.
Pragmatyczne podejście moglibyśmy pewnie więc sformułować następująco - warto przewidywać potencjalne problemy i klasyfikować je na takie, którymi:
- trzeba zająć się teraz,
- mogą poczekać,
- mogą (lub muszą) poczekać ale warto jakoś się o nich przygotować już teraz.
Zasada Scarlett odnosi wtedy do drugiej kategorii zagadnień.
Dzięki za ciekawe przykłady, zwłaszcza ten z podwykonawcami, który faktycznie jest jednym z częstszych problemów w projektach. Ostatni z nich wydaje mi się jednak potwierdzeniem mojej tezy niż kontrprzykładem - zgodnie z zasadą Scarlett właśnie dopięcie tych szczegółów, które nie są istotne dziś, powinno się odbyć jutro, a dziś warto już ruszać z programowaniem.
Pozdrawiam,
Marek
Dzięki za interesujący wpis. Z ciekawością śledzę Twojego bloga, jest to jedno z niewielu aktywnych miejsc w polskim internecie o zarządzaniu projektami. Cieszy mnie, że zdecydowałeś się zabrać głos również tutaj.
Oczywiście masz rację, żadna reguła nie powinna zastępować zdrowego rozsądku. W szczególności dotyczy to reguły Scarlett O'Hary.
Jeśli dobrze rozumiem, Twój punkt widzenia podkreśla rolę zarządzania ryzykiem. Jego esencją jest w końcu wyszukiwanie i przewidywanie potencjalnych kłopotów i przygotowywanie się zawczasu do działań zaradczych.
Nie jest moją intencją by namawiać do ignorowania przyszłych niebezpieczeństw i zaniechania powyższych praktyk. Raczej zależało mi na tym, by pokazać również tę drugą stronę medalu. Przygotowywanie się ze wszystkim na zapas byłoby dobre w bardzo przewidywalnym środowisku, które jest niezmienne w czasie. Rzeczywistość jest jednak zwykle dramatycznie inna i dlatego decyzje lub działania, które można odroczyć, mogą właśnie to ryzyko zmniejszać.
Pragmatyczne podejście moglibyśmy pewnie więc sformułować następująco - warto przewidywać potencjalne problemy i klasyfikować je na takie, którymi:
- trzeba zająć się teraz,
- mogą poczekać,
- mogą (lub muszą) poczekać ale warto jakoś się o nich przygotować już teraz.
Zasada Scarlett odnosi wtedy do drugiej kategorii zagadnień.
Dzięki za ciekawe przykłady, zwłaszcza ten z podwykonawcami, który faktycznie jest jednym z częstszych problemów w projektach. Ostatni z nich wydaje mi się jednak potwierdzeniem mojej tezy niż kontrprzykładem - zgodnie z zasadą Scarlett właśnie dopięcie tych szczegółów, które nie są istotne dziś, powinno się odbyć jutro, a dziś warto już ruszać z programowaniem.
Pozdrawiam,
Marek
16/01/2007,
Marek Rafałowicz
