Ku mojemu zaskoczeniu dość często dostaję pytania o możliwość zaangażowania się w roli analityka np. na rok na warunkach: 100% czasu na miejscu u klienta a wynikiem ma być specyfikacja wymagań na oprogramowanie, którego realizacja jest planowana na np. kolejne 5 lat. Nie ma to moim zdaniem żadnego sensu i nie angażuje się w takie projekty. Ale po kolei.
Już w roku chyba 2003 robiłem analizę ryzyka dużych i długich projektów, celem była ocena prawdopodobieństwa i kosztów wprowadzania zmian do zakresu projektu. Jak nie trudno się domyśleć, jest to – zmiany zakresu – najbardziej niechciana rzecz w każdym projekcie. Materiał ten był prezentowany na jednej z konferencji dotyczących wdrażania systemów ERP.
Co spowodowało moje zainteresowanie tym problemem? To co każdy w tej branży widział chyba najmniej raz w życiu: różnica pomiędzy pierwotną specyfikacją a ostatecznym produktem. W dużych projektach często te dwa stany nie mają z sobą zbyt wiele wspólnego! Więc pojawia się pytanie: po co robić wielką analizę i dokumentację skoro większość tej dokumentacji, rozdział po rozdziale, ląduje w koszu za sprawą “zarządzania zmianą”?
Jakie są najczęstsze problemy w nieudanych projektach? 70% to zmiany zakresu projektu, (Raport Jama Sofware ? O wymaganiach).
Popatrzmy na to:
Analiza i specyfikowanie wymagań to tak na prawdę prognoza mówiąca, że to co teraz projektujemy będzie w przyszłości, w dniu oddania do użytku, potrzebne w takiej formie w jakiej właśnie to projektujemy. Jak wiemy, prognozy są tym większym błędem obarczone i bardziej w przyszłość wybiegają. Powyższy diagram to typowy megaprojekt. Linia przerywana obrazuje pewną hipotetyczną granicę, powyżej której ryzyko błędnej prognozy przekracza np. 50% (czyli klasyczny rzut monetą).
Innymi słowy, rozpoczynając megaprojekt mamy niemalże pewność, że jego zakres ulegnie zmianie czyli cała praca powyżej tej linii przerywanej pójdzie do kosza (na koszt sponsora projektu ;)).
W naturalny sposób nasuwa się wniosek: nie należy robić nic ponad tę przerywaną linię. Wtedy otrzymamy taki diagram:
Robimy tylko to co z ryzykiem bliskim zera zostanie zaimplementowane bez zmian. Jak? Pierwszy etap to analiza problemu i projektowanie architektury całości – model komponentów. Jest to jakaś logika systemu na dość wysokim poziomie abstrakcji ale dająca się przetestować. Stanowi ona podstawę dalszej pracy nad każdym komponentem osobno (kolejne etapy). Uszczegóławianie wymagań odkładamy “na ostatni moment”. W ten sposób “kwartał po kwartale” doprecyzowujemy wymagania na kolejny etap i realizujemy go. Co zyskujemy? Nie wyrzucamy do kosza nadmiernie szczegółowej i rozległej dokumentacji wymagań, nie ponosimy koszów projektowania czegoś co może “wylecieć” z zakresu za pół roku z powodów np. zmian na rynku, możemy w dowolnym momencie zmienić kolejne planowane komponenty, usunąć jedne i opracować nowe bez ryzyka zbędnych kosztów.
Pierwszy etap ma pewną cechę: tworzy (taki ma cel) jeden wspólny model wszystkich projektów dla danej organizacji o wdzięcznej nazwie Architektura Korporacyjna. Kolejne konkretne komponenty architektury IT to kolejne projekty, cechujące się zrozumianym umiejscowieniem w całości organizacji i wiarygodnym, spójnym z całością zakresem.
Dlatego z reguły nie mają sensu:
- wdrożenia departamentowe oderwane od reszty (np. Dział Handlowy sobie funduje sam system CRM),
- projekty trwające dłużej niż trzy kwartały (ostatni kwartał to kolejne planowanie budżetu na kolejny rok czyli planowanie zmian),
- mega projekty ERPII czyli “all in one” dla firmy w ramach jednego projektu.
Więc jak zjeść słonia by się nie udławić? Powoli i po kawałku… I nie zapominajmy, że wyzwaniem może być nie tyle nowe oprogramowanie co zmiana nawyków ludzi… a nie ma nic gorszego niż planowanie nowego oprogramowania dla starych nawyków bo po co to robić?
Pamiętajmy, że zarządzanie zakresem projektu jest tym kosztowniejsze im więcej szczegółów ten zakres posiada. Projekt o 30 wymaganiach vs. projekt o 300 wymaganiach to nie projekt o 10-krotnie większym koszcie, ta różnica będzie znacznie większa (pomijam to jak w ogóle zdefiniujemy wymaganie).
Tak więc przeciętny projekt to dla analityka praca na nie więcej niż kwartał (mniej więcej). Jak ja opisać wymagania na systemy ERP? Nie są to setki szczegółowych wymagań, bo to nie ma sensu. To opis architektury korporacyjnej wraz z zestawem celów biznesowych dla każdego potencjalnie kupowanego modułu (podsystemu) oraz wymagania jako testy pokazujące realizację tych celów. Tych testów (wymagań) będzie raczej 30 niż 300, zaś ewentualne dedykowane funkcjonalności są projektowane “na ostatni moment” jeżeli okaże się, że żaden rynkowy produkt ich nie oferuje a nam na prawdę są one potrzebne.
P.S.
Stale mnie nurtuje pytanie: dlaczego tak często są ogłaszane przetargi na megaprojekty i są składane oferty na mega wdrożenia, skoro to co napisałem nie stanowi żadnego odkrycia? 🙂
Podzielenie dużego projektu na mniejsze części w twoim przykładzie kwartale i korekta kierunku po każdym etapie to wprost podejście scrumowe.
W “megaprojektach” jest też problem z podejściem Klienta (sponsora) i przyszłego użytkownika systemu którzy chcieliby już na początku wiedzieć co dostaną na koniec z dokładnością do “pozycji przycisku odśwież na formatce Nr45” co oczywiście nie ma wpływu na późniejsze zmiany tych z taką skrupulatnością dokonanych ustaleń ;]
SCRUM (chyba, że o czymś nie wiem) nie wymaga istnienia nadrzędnej architektury całości systemu (całej organizacji)… nie ram mam wrażenie, że to jednak rozpoznanie bojem.
Ta “całość” to kompletny model pojęciowy (nie jest to model danych!) i reguły biznesowe całej organizacji, bez czego żaden częściowy projekt nie ma ani kontekstu ani zdefiniowanych punktów styku z “resztą”. Nie przypadkiem napisałem o architekturze korporacyjnej, gdyż praktyka moich ostatnich lat wskazuje na to, że dobry system IT w danej organizacji to jeden przemyślany system podzielony na dziedzinowe podsystemy (nie ważne czy od jednego dostawcy czy nie i nie koniecznie musi to być jeden wielki zintegrowany, to ostatnie nawet jest chyba najgorsze). Zaryzykuję tezę, że ten nadrzędny system to nic innego jak obiektowy meta-meta model dziedziny systemu jaką jest cała organizacja. Tu właśnie widzę korzyści z architektury korporacyjnej ale chyba nie takiej jak TOGAF, która w moich oczach jest jednak przeformalizowana a właśnie jako Siatka Zachmana, którą on sam teraz nazywa “ontologią organizacji”.
To co napisałeś w drugim akapicie to niestety prawda. To sytuacja, w której Klient sam zabija własny projekt. Jest to efekt nadmiernego uznawania życzeń przyszłych użytkowników i umywanie rąk od tego przez sponsorów projektu (ja płacę Wy róbcie). Bez nadrzędnego modelu nie ma narzędzia do ucinania takich idiotycznych życzeń. Dodam jeszcze, że problemem wielu projektów jest traktowanie analityków jak sekretarzy w rodzaju “jak klient mówi to analityk zapisuje”. To także droga do porażki ;), bywa, ze z tego powodu (takie oczekiwanie zamawiającego) wypowiadam umowę.
Bardzo mi się podoba to podejście, jest takie idealne. Pytanie tylko, jak należałoby do tego przekonać sponsorów i jak konstruować umowy na taką realizację. Nie miałam takiej przyjemności, jednak to podpowiada rozsądek, tak powinno być.
Kluczowe jest na początku zdefiniowanie architektury.
W zasadzie nie jest to takie trudne. Umowa ma kilka etapów, każdy ma swoją cenę, każda ze stron może bez konsekwencji może wypowiedzieć jej kontynuację. Kluczem jest pierwszy etap, którego produktem jest owa architektura całości w jakiejkolwiek ale dobrze opracowanej formie.
Umowa z podziałem na etapy i zapłatą za każdy z osobna jest ryzykowna. Zapewne kluczowe jest tutaj jakie to etapy i jakie produkty one generują. Muszą być one od siebie maksymalnie niezależne (powiedzmy jak usługi w SOA), w przeciwnym razie wykonawca po np wykonaniu 3 etapów z 4 (i zgarnięciu kasy za nie) zignoruje ten ostatni i nie będzie go to bardzo bolało. Jeśli końcowy produkt zbyt mocno polegał by na działaniu modułów wyprodukowanych po tych 4 etapach, to klient zostaje z kalekim systemem i pustym budżetem.
Bezpieczniej wtedy ustalić opłatę na koniec za całość.
P.
Oczywiście, że kluczem jest to co nazwiemy w umowie etapem :). SOA czy generalnie komponentowe podejście do architektury, to pierwsze lekarstwo, drugie to tworzenie (dobrej) dokumentacji, bez której sytuacja, w której wykonawca przerwie prace (a to zawsze jest możliwe) jest tragedią.
“Umowa z podziałem na etapy i zapłatą za każdy z osobna jest ryzykowna.”
Dlaczego i dla kogo?