O szkoleniu
Ameryka przyjechała do nas, Darryl Booker, który 20 lat (poza pracą na uczelni) pracuje jako konsultant, analityk biznesowy był trenerem na szkoleniu, które mam właśnie za sobą.
Z jednej strony trzy dni poznawałem coś do czego sam dochodziłem, co w zasadzie znam i potrafię, jednak z drugiej strony szkolenia prowadzone przez ludzi z dużym doświadczeniem zawsze mają dwa aspekty: po pierwsze początkujący dowiedzą się jak należy pracować i co powinno podczas tej pracy powstawać po drugie dla mnie (dla każdego z dużym doświadczeniem) bardzo cenne są kontakty z innymi ludźmi z branży, bo porównanie wiedzy, wymiana doświadczeń oraz dyskusje pozwalają porównać swoje dokonania z cudzymi. W wielu projektach i na konferencjach słyszę, że wymyślam jakieś niestworzone rzeczy bo nikt tak nie robi (modelowanie, testowanie wymagań, proof-of-concept, itp.). Otóż nie prawda, po prostu bardzo wielu ludzi (w bardzo wielu projektach) nie zarządza ryzykiem przyjmując generalnie optymistyczne wersje wydarzeń.
Czego się nauczyłem na tym szkoleniu? Że warto planować, projektować i analizować, bo wtedy projekty są przewidywalne zamiast być loterią.
Jak to się robi? Od kilku lat promuję ideę naukowej analizy systemowej: opis celu, opis problemu, stawianie hipotez, modele i scenariusze, rekomendacje i projekt. Nie musi to być i nie jest żaden tak zwany “wodospad” projektowy (watter fall model IT), zwinność tu polega na reagowaniu na każdym etapie projektu na problemy i wprowadzanie zmian, produkt projektu jest zawsze modelowany i testowany na każdym etapie. W efekcie specyfikacja tego co ma powstać jest kompletna, nie wymaga “prototypowania” na żywym ciele (powstaje kod dla klienta, który zgłasza uwagi do tego co zobaczy) a zamawiający wie co dostanie w dniu zamówienia i wie ile to będzie kosztowało.
Mity dostawców oprogramowania
Dostawcy gotowego oprogramowania szermują tezą, że oszczędzą Wam kosztów analizy bo mają wiedzę i doświadczenie “zawarte” w swoim produkcie. Ryzyko, że wymagania biznesowe zostaną źle zdefiniowane i ryzyko, że dostarczony produkt nie spełnia tych wymagań jest ignorowane (klient zamówił to klient dostanie, czy to będzie mu potem potrzebne to nie nasz problem).
Developerzy oferujący wykonanie dedykowanego oprogramowania bez analizy wymagań a np. tylko z pomocą tak zwanych sesji JAD (ang. Joint application design) i kolejnych prototypów, w ogóle nie biorą pod uwagę ryzyka niekompletności tak określonych wymagań ani braku ich spójności (znany problem odkrywania wymagań w trakcie wdrożenia). Klient powie co chce i będzie OK a oprogramowanie i tak ma być bo każdy ma.
A ryzyko, że analiza potrzeb i projekt tego co ma powstać, wykonana przez przyszłego wykonawcę, będzie tak na prawdę tylko specyfikację tylko tego co dostawca potrafi wykonać?
Dlaczego tak często projekty łamią zasady rozsądku i zarządzania ryzykiem?
Wczoraj na sali i w kuluarach padły między innymi takie odpowiedzi:
dostawcy oprogramowania bardzo często nie potrafią takiej analizy wykonać bo nie mają wymaganych kompetencji, ale potrafią programować i tylko na to się godzą.
dostawcy oprogramowania doskonale wiedzą, że istnieje ryzyko że ich produkt nie spełnia wymagań więc bardzo często nie dopuszczają do takich analiz forsując od razu wdrożenie (wręcz tępią w projektach zewnętrznych analityków!).
klienci mają stale do czynienia z dostawcami a bardzo rzadko z niezależnymi analitykami i bardzo często przyjmują wiarę w to co mówią dostawcy.
nie istnieją niezależni analitycy.
Na ostatnie odpowiem tak: jest ich (nas) mało… ale to łatwo sprawdzić: poprosić o referencje i zapytać co rekomendowali. Dobry analityk nigdy nie rekomenduje implementacji a tylko tworzy specyfikację biznesową. Po trzecie, warto angażować ludzi znanych w branży z tego, że nie są na prowizjach u producentów.
Agile…
Wielu z developerów idzie dalej: nie trzeba analizy, trzeba od razu zacząć tworzyć rozwiązanie, Agile Manifesto – hasło przewodnie tej metody jasno mówi, że chodzi o to by programować a nie o to by coś dokumentować, szkoda czasu na głupoty (zawsze tak określone metody zwinne kojarzyły mi się z homeopatią: dostawcy obiecują coś nie wiedząc co na prawdę boli i nie biorą żadnej odpowiedzialności za skutki, co ciekawe żadne dane nie potwierdzają skuteczności tych metod).
Inna ciekawostką metod Agile jest to, że projekt kończy się nie wtedy gdy powstanie to co zamówił (a raczej wyobrażał sobie klient bo nic nie zamówił, w końcu nie powstała żadna specyfikacja) tylko to co powstanie dopóki nie skończy się budżet. Co powstanie? Zobaczymy jak skończymy.
IIBA czyli czym jest ta Analiza Biznesowa
Od pewnego czasu IIBA promuje idee Analizy Biznesowej, która jest poważnym zagrożeniem dla opisanych wyżej dostawców. Dlaczego? Bo promuje tworzenie dokumentów pozwalających najpierw dokładnie wyspecyfikować to co jest potrzebne (czytaj pomoże w biznesie!), potem dopiero zostaje to zamówione i dostarczone lub wykonane.
Nie da się tak? A właśnie, że się da. Czy to kosztowne? Zadam pytanie: Co lepsze nieprzydatny produkt za 100tys. zł czy przydatny za 120tys.? Co lepsze, projekt planowany na pól roku za 100tys. i wykonany w terminie czy obiecany za 50tys. w kwartał a dostarczony za 250 tys, po dwóch latach?
To się nazywa RYZYKO a analiza i projektowanie to zarządzanie tym ryzykiem!
Co oferuję jako analityk a IIBA zaleca
Porządny projekt analityczny kończący się specyfikacją wymagań (IIBA nazywa to Dokument Wymagań Biznesowych):
A teraz to co mogę polecić: szkolenie Analiza Biznesowa w MT&DC. Dostawców nauczy pracy a klientów wiary, że można lepiej. Dlaczego tak polecam to szkolenie? Bo jego koszt to nic w porównaniu do strat jakie generuje źle zaplanowany projekt a których można uniknąć lub znacznie zminimalizować. Nawet jeśli ktoś po szkoleniu nie będzie potrafił sam od razu takiej analizy wykonać (bo raczej po trzech dnia nie) to na pewno będzie w stanie ocenić to co proponują dostawcy a potem zarządzać takim projektem. Potem z czasem sam (lub na kolejnych szkoleniach) nauczy się dobrej analizy biznesowej.
Na koniec najważniejsze, parafrazując stwierdzenie Daryll’a: analitykom, których jedynym narzędziem pracy jest pakiet MS Office, w szczególności Excel i PowerPoint, z góry dziękujemy (on używa profesjonalnych narzędzi CASE i pakietów do zarządzania projektami).
Niestety w wielu firmach kuleje jeszcze analiza, bo albo nie ma czasu, albo większość wychodzi z założenia: “Dokładnie wiem czego chcę, a dokument? no dokument uzupełnimy później”, czyli wizja jest najważniejsza. Owszem jest ważna, ale nadal nie rozumiem tej obawy, że jeśli poświęcimy odpowiednio dużo czasu do przeanalizowania wszystkich możliwych scenariuszy dla danej funkcjonalności to nagle stracimy możliwość realizacji naszej wizji. Totalna bzdura!!! Przecież takie przewidywanie to uniknięcie porażki, czy zaskoczenia, że nagle coś nie działa tak jak powinno, czy też słynne słowa Klientów:”Myślałem, że to będzie “wyglądało” inaczej”…..
Dodatkowo pojawia się także ten powód: “a co będzie jak produkt który oddamy będzie inny niż specyfikacja? lepiej więc nie robić tej specyfikacji…”. Niestety nie raz tak zwany “biznes” nie pali się do analizy bo to wymaga podejmowania decyzji… a tych niektórzy nie lubią…
A na diagramie porządnego projektu analitycznego nie powinno być jeszcze kroku “Akceptacja wymagań”? Czy walidacja wymagań obejmuje również ich weryfikację oraz zdefiniowanie założeń i ograniczeń? Trochę to przypomina połączenie technik zwinnych oraz BABOK.
To co opisałem powyżej to 100% BABoK. Zwinność tu polega na reagowaniu na każdym etapie walidacji (wykrycie niezgodności to adaptacja projektu). Nie ma tu jednak nic a nic z Agile Manifesto. Wymagania to konsekwencja celu biznesowego, ten jest zatwierdzany. Na końcu jest przecież także zatwierdzenie rezultatów. Tym rezultatem jest właśnie BRD czyli Business Requirement Document czyli specyfikacja wymagań. Po jej zatwierdzeniu startuje wykonanie i dostarczenie produktu. Jednak specyfikacja jest zawsze wcześniej przechodzi testy.
Dodam, że w procesie powyższej analizy biznesowej nie powstaje nawet linijka kodu…podobnie jak w następującym zaraz po niej weryfikacji wymagań i testowaniu “białej skrzynki” (use case’y to “czarna skrzynka”)
Może mieć miejsce także problem z wydłużaniem czasu realizacji projektu z powodu oczekiwania na zatwierdzenie tych spisanych wymagań przez klienta. Każdy w różnym stopniu angażuje się w projekt, niekiedy zamawiający nie zdają sobie sprawy ile zaangażowania wymaga od niego takie zatwierdzanie wymagań. Może być zaangażowany w prowadzenie swojego biznesu i przez to mało dostępny. Niekiedy brak jednej decyzji (posiadającej wiele implikacji) może powodować przestój w dalszych pracach analitycznych czy uniemożliwiać ich zakończenie. Jak radzi Pan sobie w takich przypadkach?
To zależy od konstrukcji umowy. W zasadzie mamy dwie: czas i materiał oraz “fixed price” (czyli umowa o dzieło). Przestój z winy Zamawiającego, zawsze bije w Zamawiającego, który albo płaci za czas zaangażowania analityka albo przesuwa mu się termin oddania dzieła (o ile mu to przeszkadza). Minus dla analityka polega na tym, że przeciąganie z winy zamawiającego wpływa na inne projekty. Kodeks Cywilny chroni tu wykonawce Dzieła: ma prawo wystawić fakturę i żądać zapłaty jeżeli “pozostawał w gotowości do wykonania dzieła a zamawiający, mimo zawartej umowy, nie udzielał wymaganego wsparcia”.