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:

1. dostawcy oprogramowania bardzo często nie potrafią takiej analizy wykonać bo nie mają wymaganych kompetencji, ale potrafią programować i tylko na to się godzą.

2. 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!).

3. 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.

4. 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).