Tak zwane “[[lessons learned]]” ( “czego nas to wszystko nauczyło”) to “obowiązkowy” (ostatni) etap każdego dobrze zarządzanego projektu. W moim przypadku robię to niezależnie od tego czy był to mój projekt czy jedynie mam dostęp do wiedzy o cudzym projekcie. Okazji mam nie mało, bo nie raz po kimś coś kończę a raczej robię to u klientów “po swojemu” jeszcze raz. Przykładem mojego własnego lessons learned była opisana tu droga na skróty i rozwiązanie umowy.
Jednak z tych lekcji wyłania się pewien ogólny wniosek, zresztą nie taki nowy. Zapewne wielu z Państwa znane jest stare przysłowie o wybieraniu drogi na skróty: “kto drogi prostuje ten w domu nie nocuje” i ono doskonale oddaje istotę problemu. Ale po kolei.
Typowe kroki projektu związanego z reorganizacją (jakąkolwiek) firmy to:
- Decyzja (jej wypracowanie nie raz także może zająć jakiś czas) o podjęciu działań mających na celu jakąś poprawę.
- Audyt, jego celem jest udokumentowanie stanu obecnego, zrozumienie aktualnej sytuacji. Powstaje model biznesowy, czyli opis tego jak firma tworzy wartość i zyski. Audyt powinien być zwieńczony rekomendacjami audytora na temat ewentualnych optymalizacji i związanych z nimi formalizacjami działania.
- Jeżeli pojawi się “coś co warto zmienić”, należy to rozważyć i podjąć działania. Zwracam uwagę, że zaniechanie rekomendowanych działań to także działanie i powinno być świadome. Ten etap (głównie formalizacja) “oczyszcza” firmę z ryzyk wynikających z jej nieprzewidywalnością (brak procedur, niekompletne i sprzeczne zakresy kompetencji itp.). Na tym etapie często pojawiają się dodatkowe projekty z zakresu zarządzania wiedzą i zarządzania ciągłością działania firmy.
- Po “skonsumowaniu” wyników audytu pojawia się (może się pojawić) wniosek, że usprawnienie organizacji wymaga wdrożenia (lub wymiany) oprogramowania o pewnych cechach (lub zmian organizacyjnych, innych metod zarządzania itp.). Wyspecyfikowanie tych cech wymaga analizy, której produktem jest specyfikacja wymagań, a konkretnie usług jakich oczekujemy od nowego oprogramowania. Gdyby się okazało, że “takiego” oprogramowania (modułu) nie ma na rynku, należy ocenić rentowność jego zaprojektowania i wykonania, przy pozytywnej decyzji, zlecić wykonanie. Powstaje kompletna specyfikacja wymagań nowego systemu. Na jej podstawie dopiero wybieramy produkt i jego dostawcę.
- Teraz pora na realizację projektu wdrożeniowego. Mamy wiedzę co chcemy osiągnąć i jak to osiągnąć. Wiemy czego oczekiwać, więc łatwo stwierdzić, czy wdrożenie się udało: czy otrzymaliśmy to co miało zostać dostarczone i czy odbyło się w czasie i budżecie jaki zaoferował dostawca.
Powyższe kroki można zobrazować w następujący sposób (kliknij by powiększyć):
Jak widać, każdy etap daje “poważny” wsad w etap następny.
Wykonajmy małe ćwiczenie myślowe: jakie ryzyko wnosi decyzja o pomięciu któregokolwiek z etapów pośrednich? A teraz ostra jazda: projekt zaczynamy od razu od realizacji czyli mamy sytuację, w której projekt zaczyna się od wdrażania jakiegoś konkretnego oprogramowania lub od razu zlecamy firmie programistycznej tworzenie oprogramowanie bez projektu, czyli realizowany jest od razu ostatni opisany etap z pominięciem wszystkich poprzednich… jakie jest ryzyko takiego podejścia?
Zwracam uwagę, że praktyka (kolejne “nauczki”) pokazuje, że projekt związany z dostarczeniem i wdrożeniem oprogramowania powinien zamknąć się w granicach roku obrachunkowego z uwagi na prawdopodobne zmiany sytuacji rynkowej, wewnętrznej sytuacji firmy i wielu innych. Rozpoczynanie projektu planowanego z góry na trzy, a nie raz i pięć lat (typowy czas wdrażania dużego zintegrowanego systemu ERP), praktycznie z góry skazane jest na niepowodzenie, a mimo to wiele firm zgadza się na taką właśnie drogę…
Opisane tu podejście często nazywane jest “kaskadowym” (waterfall – wodospad). Jest ono dość często wskazywane jako mityczny powód porażek projektów, ale moim zdaniem jest to pewna demagogia, gdyż tak na prawdę przyczyną większości tych problemów jest nie tyle “wodospadowe” podejście (ono jak widać z powyżej opisanego procesu, ma głęboki sens), co wzięcie sobie na barki projektu (zawarcie umowy z dostawcą na trzy lata to przyjęcie w dniu jej zawarcia ponad rocznego harmonogramu łamiącego opisaną powyżej zasadę) na lata, zaniedbując zupełnie fakt, że otoczenie rynkowe obecnie zmienia się nawet co kwartał.
Mamy więc kuriozalne zestawienie: podjęcie projektu od razu od ostatniego etapu (wybór dostawy, produktu i realizacja) i zaplanowanie go od razu na np. trzy lata. To projekt w rodzaju “nie wiem co tu jest grane ale kupujemy [ten system] i wdrażamy go”. To nie ma prawa się udać…
A nasze “lessons learned”? No właśnie, znane mi projekty zakończone kłopotami, to właśnie projekty na skróty. Projekty prowadzone w myśl powyższych zasad (krótkie i dobrze zaplanowane odrębne etapy) są znacznie bardziej odporne na kłopoty.
Najgorszym powodem wdrożenia nowego oprogramowania jest chęć wdrożenia nowego oprogramowania…
Zawsze byłeś zwolennikiem rzetelnych danych, więc nie wiem dlaczego waterfall określasz mianem mitycznego powodu porażki – skoro badanie realizowane na tysiącach projektów pokazują, że właśnie założenia tego modelu wytwarzania są podstawową przyczyną porażki. Albo przyjmujemy rzetelne informacje, albo nie – myślę, że nie można sobie pozwalać na demagogie i wybiórczość.
Poza tym waterfall w samej swojej konstrukcji uniemożliwia realizację projektu, który odbywa się w jakkolwiek zmiennym środowisku, ponieważ zamknięcie etapu jest ostateczne. Nic co zostało zrobione na etapie analizy wymagań nie może się zmienić, bo trwa projektowanie.
Założenie, że jest możliwe odkrycie i opisanie 100% wymagań na system przed rozpoczęciem jego tworzenia jest błędne i to ono prowadzi do porażki. Potem przy pierwszym release ZAWSZE okazuje się, że znaczna część projektu jest do zmiany – czasem ta która jest objęta releasem (pech:P) czasem ta zaplanowana potem (szczęście:)). Bezpośrednie powody takiej sytuacji są różne, ale występuje ona niemal zawsze.
Ja bardzo lubię pracować na formalnej analizie wymagań, ale nie jest prawdą, że jest to lek na całe zło. Trzeba szukać złotego środka – a ten w każdym projekcie jest nieco gdzie indziej – doświadczenie pozwala w kolejnych znajdować go szybciej.
Na tyle na ile przejrzałem różne “badania” wychodzi, że przyczyną porażek jest próba utrzymania mega wymagań w “długich” mega-projektach projektach. Wieloletni projekt ma change-management wpisany w życiorys. Zjawisko kompletnie nie występuje (z moich obserwacji) w projektach “krótkich”, o takich piszę.
Nie demonizował bym tej “ostateczności” w sytuacji, gdy projekt obejmuje konkretny “wąsko-dziedzinowy” zakres, który z zasady nie powinien się zmieniać w jednej iteracji. Po trzecie nikt nie wyklucza tu zmiany lub dodania funkcjonalności. Ale haczyk polega na tym, że planując budowę złożonego roweru zapewne nie wiesz co powstanie po roku, ale projektując kierownicę nie będziesz jej zmieniał w połowie projektu, jak dobrze przemyślisz będzie OK. Zmienisz koła, pedały, liczbe przełożeń, ale to zmiany na poziomie architektury a nie komponentu. Zmiana wymagań dotyczy najczęściej skali “makro” ale raczej nie, dziedzinowych samodzielnych, służących do konkretnej rzeczy, obszarów.
Po pierwsze wymagań się nie odkrywa tylko analizuje i dokumentuje. Założenie, że jest możliwe określenie wymagań w 100% jest jak najbardziej słuszne, pod warunkiem, że dotyczy konkretnego zamkniętego obszaru projektu. Jak porządnie zaprojektujesz fakturę VAT to ona nie ma prawa się to zmienić, mogą się zmienić etapy jej zatwierdzania wtedy dodamy nową ścieżkę w procesie (częstym błędem jest “wbijanie” kodu obsługi faktury w klasę faktury!), jak zmienią się przepisy dodamy nową fakturę (lub tylko nowe stawki podatku), dodamy, dodamy ale nic nie ZMIENIAMY!. Nie wywracamy projektu do góry nogami…
Model dziedziny – nie wolno go upraszczać bo to właśnie dokonane uproszczenia czynią szkody w rodzaju “zmieniła się sytuacja, zmieniamy projekt”.
Ów waterfall jest “szkodliwy” w metodach strukturalnych, tu mamy znormalizowany wielki całościowy model danych i stertę funkcji, tu faktycznie zamrożenie jest tragedią i większość “statystyk” wskazujących na szkodliwość “waterfall” to właśnie strukturalne projektu (większość projektów w narzędziach obiektowych jakie widuję to niestety projekty tak na prawdę strukturalne, sam fakt projektowania relacyjnej znormalizowanej bazy wystarczy by go tak zakwalifikować). W dobrze prowadzonym projekcie obiektowym zjawisko to (zmiana projektu) w zasadzie nie występuje (normalizacja jest procesem stratnym, nieodwracalnym, zmiana warunków wymaga zmian modelu).
Tak więc broniąc tego co napisałem: klucz tkwi w modelu dziedziny i tego jak go tworzymy. Pojawia się modny ostatnio CQRS (planuje artykuł o tym), który “załatwia” kwestie wydajności i jednoczesnej wierności modelu… (nie upraszczamy modelu dziedziny by był wydajniejszy, dodajemy dedykowane, redundantne konstrukcje tam gdzie jakaś operacja ma być szybka, np. trzymam bardzo złożone i nie uproszczone (!) agregaty opisujące produkty w magazynie (kartoteka produktu), ale buduję dodatkowo prostą trwałą kolekcję (zreplikowany klon) będącą prostym i szybkim cennikiem na potrzeby jego przeglądania i filtrowania. Po znalezieniu potrzebnego towaru na bazie jego indeksu wyszukuje konkretny złożony agregat by poznać szczegóły produktu. Nie jest to żadna trwała relacja, szczegółowy opis produktu znajdę na podst. nr. indeksu a nie asocjacji towar-towar.
Złotym środkiem jest na pewno rozsądek i pragmatyzm ale moim zdaniem na pewno nie nadmiar uproszczeń i dróg na skróty.
Popatrz na prezentowany diagram i wyobraź sobie, że analiza i specyfikowanie wraz z realizacja trwa poniżej roku, projekt większy jest ‘rozbijany” na komponenty mieszczące się w takich rygorach realizacji.
A może to właśnie “zmienne środowisko” jest przyczyną porażek ?
Z resztą – waterfall jest dość “pojemną” metodyką i na pewno nie wyklucza “zmiany potrzeb biznesowych” o ile zachodzą one przed rozpoczęciem np. implementacji; jeśli ktoś twierdzi, że można “łatwo” zmienić wymagania podczas realizacji to IMHO, w najlepszym przypadku – kłamie (w trochę gorszym – zupełnie się nie zna na tym co robi)
Powiedzmy tak – mało kto potrafi robić dobrą analizę (bez zmian “co chwile”), mało kto potrafi dobrze implementować (bez “codziennej refaktoryzacji”) i w związku z tym w IT jest taka sytuacja a nie inna.
Zmienne środowisko jest “środowiskiem projektu” ;), faktem jest że zmienność ta nie ułatwia pracy, ale też zmienność ta ma swoje granice 9proces legislacyjny i terminy “wchodzenia w życie” itp. Powtarzając po :”decydentach” u moich klientach można chyba się zgodzić z tezą, że problemem nie jest zmienność sama w sobie (jest ograniczona jednak) a to jak sobie z nią radzimy. Można sobie łatwo wyobrazić rower z kilkoma zmiennymi podzespołami, który pozwoli wybrać się w nieznane… z oprogramowaniem jest moim zdaniem podobnie: nie ma sensu projektowanie “szytego na miarę obcisłego garnituru” i próba szycia go rok… trzeba przewidzieć zaszewki, możliwość wymiany kamizelki, rezygnacji z kapelusz ana korzyść kaszkietu…
@JW Akurat refaktoryzacja (za Fowlerem) powinna odbywać się codziennie :). W zasadzie powinna być ciągle przeplatana z wprowadzaniem nowej funkcjonalności.
Zależy o jakiej refaktoryzacji mowa, jak znam Fowlera to myślenie o kodzie, w tym jego ulepszanie to jedno, a publikowanie kolejnych wersji dla użytkownika to drugie (no bo nie codziennie ;)). Druga rzecz to czym innym jest wypuszczenie wersji o poprawionej jakości ale o nie zmienionej funkcjonalności 9to można robić “często”), a czym innym jest zmiana zachowania systemu to jest nowe lub zmienione funkcjonalności, (to powinno być niezbyt często)…
@JW Waterfall nie jest pojemna metodyką. W oryginale nie zakłada reakcji na zmianę. To o czym wywód zrobił pan Jarek to przedstawienie wyższości procesu iteracyjnego który powinien składać się z kaskad waterfall`a. A fakt że firmy wciąż wymagają tworzenia pełnego projektu przed rozpoczęciem prac i co gorsza narzucają harmonogram przed zaprojektowaniem funkcjonalności jest przyczyną w mojej opinii porażek.