Przecież analizę zrobimy sami, a jak nie – to zrobi to dostawca. Tak często rozpoczyna się tak zwana „Droga do klęski”. Jednym z typowych listów inicjujących współprace z wieloma moimi klientami był ten:
Planujemy wdrożenie nowego oprogramowania, chcemy tym razem uniknąć presji ze strony dostawcy oprogramowania. Poprzednim razem dostawca oprogramowania upraszczał sobie pracę, już na etapie analizy, którą wykonywał sam. Analiza wymagań polegała na wywiadach i warsztatach grupowych, skończyła się zwykłym opisem, tabelkami i kilkoma nieczytelnymi schematami. Podczas analizy i wdrożenia stale wmawiano nam, że „tego nie można”, „to należy uprościć” albo „tak się nie robi” my zaś nie potrafiliśmy tego ocenić. Wiele naszych potrzeb odkrywaliśmy dopiero podczas instalacji kolejnych prototypów, zaś dostawca unikał wprowadzania zmian i obiecanych dostosowań. Dostaliśmy w efekcie nieprzydatne i niezgodne z biznesowymi potrzebami oprogramowanie. Czy może nam Pan tym razem pomóc?
Czy to propaganda? Niestety nie. W czym problem? A mianowicie w metodzie prowadzenia analizy i potem treści specyfikacji wymagań. Łatwo powiedzieć: zebrać wymagania.
Powszechnie uważa się, że analiza wymagań na oprogramowanie to prosty, ale pracochłonny proces prowadzenia wywiadów i skrzętnego zapisywania tego, czego oczekuje przyszły użytkownik. Nic bardziej błędnego – jest to najgorszy sposób.
Wśród wielu tego typu metod są te najprostsze i najbardziej ryzykowne a mianowicie: wywiady, ankiety, [[sesje JAD]]. Sama ich istota zakłada, że klient wie co chce, należy to tylko z niego wyciągnąć i uporządkować. Być może czasami tak jest, ale z reguły kończy się to klasycznym stwierdzeniem klienta na koniec projektu:
Tak, dostarczyli nam Państwo dokładnie to co chcieliśmy ale zupełnie nie to, czego potrzebujemy.
Dlaczego tak się dzieje, choć wielu (analityków) tak bardzo się stara? Jak analiza może wyglądać napisałem tu już nie raz. Ale po co tyle zachodu? Dlaczego upieram się przy tych śmiesznych formalizmach, skoro można po ludzku zapisać co powiedział user a potem zamienić to na wypunktowane listy lub wiersze ładnej tabeli? Najlepiej jeszcze gdy liczą sobie najmniej kilkaset pozycji. Jednak tak pracuje analityk dyktafon.
Dobra specyfikacja wymagań na oprogramowanie, to wynik analizy i modelowania organizacji, kompromis pomiędzy możliwościami technologii a celami biznesowymi wdrożenia. Nie ma tu znaczenia czy będzie to gotowy system ERP, czy dedykowane rozwiązanie. Ale po kolei.
Czym grozi analityk dyktafon?
Tu pozwolę sobie skorzystać z zawartości krótkiego artykułu kolegi prowadzącego blog O wymaganiach. Poniżej kilka statystyk oraz mój komentarz co do ich przyczyn. a że problem jest poważny wystarczy wiedzeć, że:
Błędy w wymaganiach to jedna trzecia wszystkich defektów w projektach. [Dean Leffingwell, Don Widrig – „Managing Software Requirements” (1999)]
Produktem analizy wymagań są wymagania, jak już wspomniałem, można je zbierać metodami „rejestracyjnymi” (odpytywanie klientów) oraz „badawczymi”. Te drugie to kolejno: analiza i model organizacji klienta, identyfikacja celów biznesowych i czynników wpływających na ich osiągnięcie, projekt rozwiązania: co ma zostać dostarczone, opis projektu czyli specyfikacja produktu. Wywiady są łatwe a pełna analiza trudna. Nie trudno się więc domyślić, których się robi najwięcej. I mamy główną przyczynę, to właśnie:
Procesy związane ze zbieraniem wymagań są źródłem większości poważnych problemów z jakością. [Gerald Weinberg – „Quality Software Management” (1997)]
Jakość specyfikacji wymagań to między innymi jej kompletność, spójność itp. Jak dokument wymagań jest niskiej jakości to typowym objawem jest tak zwane odkrywanie wymagań w trakcie trwania projektu, czyli zmiany zakresu projektu, a:
Zmiany zakresu są jednym z najczęstszych źródeł dodatkowych kosztów w projektach i często prowadzą do porzucenia projektu. [Capers Jones – „Assessment and Control of Software Risks” (1994)]
Co jeszcze? Skąd te rozdęte budżety, przeterminowane projekty typu „czas i materiał”? Bo:
Naprawa błędów związanych z wymaganiami pochłania 70 – 80% kosztów ponownej pracy w projektach IT. A całkowite koszty ponownej pracy zjadają nawet do 50% kosztów projektu. [Dean Leffingwell – „Calculating and Return on Investment from More Effective Requirements Management” (1997)]
Kolejny etap, to koszty utrzymania:
Szukanie i naprawianie błędów wymagań po wdrożeniu systemu jest 100 razy kosztowniejsze niż szukanie i naprawianie tych samych błędów podczas zbierania wymagań. [Barry Boehm, Victor R. Basili – „Software Defect Reduction Top 10 List” (2001)]
I tyle o złych wymaganiach.
Analityk zamiast dyktafonu
Jeżeli wymagania specyfikuje się metodą prostej obserwacji (odsłuchu) otrzymujemy opis faktów a nie ich przyczyn. Rzecz a tym, że fakty nic nie mówią o ich przyczynach. Kolejny cytat:
Wyobraźmy sobie kogoś, kto chce napisać program symulujący grę w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi powierzchownie cechę: „Gracz uderza biała kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewna odległość w pewnym kierunku.” Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować parametry każdego uderzenia i jego skutki. Jednak tą metodą i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie. (źr. Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997).
Inny przykład, z nieco innej dziedziny ale doskonale oddający efekty polegania na obserwacji. Przez wiele lat uznawano, że Ziemia to centrum wszechświata. Ludzie obserwowali Niebo z Ziemi. To co widzą, po protu rejestrowali ufając, że sama obserwacja da właściwy wynik. W efekcie uzyskiwali takie oto trajektorie planet i gwiazd:
Nie dawały się opisać żadnym prostym równaniem, a te równania które powstawały były nie tylko przybliżeniami ale także bardzo złożonymi zależnościami dla każdego ciała niebieskiego z osobna. Powyższy rysunek to namiastka tego przynoszą z sobą analitycy obserwatorzy.
Prawdę odkrył i udokumentował Kopernik, człowiek który nie szukał poklasku ani u zwykłych ludzi patrzących z wiarą w niebo, ani u tych, w których interesie było, by Ci ludzie wierzyli, że Ziemia to stanowi centrum ich świata. Odkryta prawda w efekcie wszystkim dobrze służy ? mimo początkowego oporu, a wygląda ona tak:
System heliocentryczny jest prosty, zrozumiały dla każdego, łatwy do opisania (mimo to wielu ludziom nadal trudno się pogodzić z tym, że nie są pępkiem świata a jedynie jego częścią i to nie centralną). Poszczególne komórki organizacyjne w firmach i organizacjach, owe firmy na rynku, są jak poszczególne ciała niebieskie we wszechświecie, pracownicy tych organizacji jak różni obserwatorzy tego samego Nieba. Każdy ma swoje osobiste spojrzenie na swoją część ale nikt z nich nie widzi całości 'z góry”. Każdy ma swój, geocentryczny widok. Typowe wywiady to zlepek takich opisów.
Praktyka pokazuje, że systemy (firmy, organizacje) obserwowane z ich wnętrza wydają się bardzo skomplikowane i tak też są opisywane przez większość ludzi (patrz wyżej diagram systemu geocentrycznego). W rzeczywistości większość systemów jest znacznie prostsza, jednak odkrycie tego wymaga głębokiego spojrzenia z zewnątrz.
Rzemieślnicy produkujący ?przed Kopernikiem? skomplikowane i kosztowne przyrządy do określania położenia planet i gwiazd z wiadomych powodów nie byli zainteresowani upraszczaniem tego modelu i swoich skomplikowanych przyrządów. Dlatego zapewne nie raz jeszcze usłyszę, że dobra analiza to setki stron, tysiące wymagań, miesiące pracy.
Jednak dobra analiza to tylko: dziesiątki stron i wymagań, tygodnie pracy ale zaawansowane metody takie jak formalna analiza systemowa oparta na modelach i ich testowaniu.
Warto jednak zaznaczyć, że tak jak projekty dedykowane mają sens od ok. 75 tys. zł. (wyliczenie w jednym zw wcześniejszych artykułów) tak zaprzęganie takich metod analizy ma sens nawet jeżeli wartość projektu (wartość ryzyka) przekracza już 10 tys. czyli nie tak wiele…. (koszt tego typu analiz to ok. 20% budżetu projektu).
Na zakonczenie cytat:
Niestety najczęstszymi przyczynami [problemów i dużych kosztów w projektach] są źle przeprowadzona analiza przedwdrożeniowa i niestety zbyt małe doświadczenie partnera wdrożeniowego. Zwłaszcza przy dużych projektach, gdzie specyfika przedsiębiorstwa wymaga oddzielnych rozwiązań uzupełniających i dużej wiedzy programistycznej, pojawiają się problemy. (źr. Wdrożenie ERP ? koszt czy zysk? – ERP -view.pl.)
Wydaje mi się, że upraszczasz Jarku wywiady, spotkania i warsztaty. Na takich warsztatach można bardzo dobrze zrozumieć klienta i jego problem oraz pomóc zrozumieć klientowi, czego tak naprawdę potrzebuje. Na warsztatach można również tworzyć modele i na bieżąco je walidować.
Nie chcę tutaj jednoznacznie orzekać, które podejście jest lepsze, ale wydaje mi się, że takie „straszenie” sesjami JAD i warsztatami jest dla nich krzywdzące.
Owszem upraszczam ale tylko do pewnego stopnia, polecam dwa artykuły na ten temat, a szczególnie komentarze praktyków pod nimi:
1. http://it-consulting.pl/autoinstalator/wordpress/index.php/2011/01/13/wymagania-klient-to-nasz-pan-czy-pacjent/
oraz
2. http://it-consulting.pl/autoinstalator/wordpress/index.php/2010/11/08/mozliwe-wyjasnienie-metod-typu-user-story-use-case-driven-%E2%80%A6-prototyping-i-klopotow-inzynierow/
Ja także proszę o wyrozumiałość: w 100% przypadków gdy audytowałem dokumentację wymagań „zawalonych” projektów były to zapisy spotkań, ankiet, sesji JAD itp. Te metody sprawdzają się przy tworzeniu interaktywnych portali dla klientów firmy, ale moim zdaniem nie są dobre do systemów biznesowych. W biznesie wymagania stawia szef a nie jego pracownik. Po drugie wewnątrz firmy ankiety i sesje JAD to prawie zawsze walka pracowników o wpływy a nie modelowanie firmy.
Z kilkoma Twoimi tezami postawionymi w podanych artykułach nie mogę się zgodzić. Wydaje mi się, że wynika to z tego, że próbujesz traktować JADy zbyt płytko. Są analitycy, którzy potrafią bardzo efektywnie przeprowadzać warsztaty i są z nich bardzo zadowoleni. Co więcej, klient wówczas też jest bardziej zadowolony.
Pod tymi tekstami wypowiedziało się tak naprawdę dwóch praktyków, co wydaje mi się zbyt małą grupą, aby jasno potwierdzały Twoje tezy.
Najbardziej chyba nie zgadzam się z tym, że nie powinniśmy przejmować się użytkownikami, bo to prezes firmy jest naszym klientem i to jego powinniśmy słuchać (tak na marginesie, to właśnie mam w przygotowaniu wpis o tej tematyce na swoim blogu). Użytkownicy potrafią być skarbnicą wiedzy. Rzekłbym nawet, że często prezes nie wie, co i jak system ma robić. Oczywiście przesłanki biznesowe najbardziej rozumie zarząd, co do tego nie ma wątpliwości, ale to użytkownicy korzystali z poprzedniej wersji systemu i będą korzystać z nowej wersji. Ja bym nie ośmielił się odstawić ich na bok i nie skorzystać z ich wiedzy.
Tak przy okazji dzięki Jarku za Twoje teksty, które niejednokrotnie zmuszają mnie do przemyślenia niektórych kwestii. Co prawda na niektóre sprawy mamy inne spojrzenie, ale właśnie dzięki temu Twoje teksty są dla mnie jeszcze bardziej wartościowe 🙂
Ścierają się różne tezy i to ma największą wartość. Bronię swojej bo przyjmuje pewne założenia na początku projektu. Z zasady są w projektach dwie główne role: rola sponsora projektu i rola użytkownika. Od końca: użytkownik ma decydująca role jeśli on decyduje o tym czy w ogóle będzie systemu używał. Ma to miejsce praktycznie w każdym projekcie, w którym powstaje „strona anonimowego” aktora jakim jest „jakiś użytkownik sieci”. Wtedy robi się sesje warsztatowe, badania focusowe, ankiety itp. Jednak i tu nie wykroczymy poza „czarną skrzynkę” przypadków użycia.
Uważam, za bardzo niebezpieczne dla projektu powoływanie się na „poprzednio używany system” gdyż często jest wymieniany właśnie z tego powodu, że jest kulą u nogi, ale jest to ważne, jeśli mowa o korzystaniu z portali konkurencji. Tak więc w większości projektów, jak je nazywam, portalowych, user wyznacza potrzeby a sponsor je realizuje. W projektach biznesowych, umownie wnętrze firmy, sponsor zabezpiecza swoje potrzeby.
Mój opór do sesji JAD (i podobnych metod) bierze się z tego, że ich wyniki są nieweryfikowalne. Są to deklaratywne, demokratycznie ustalane zapisy oczekiwań, które mnie się kojarzą raczej z ustalaniem wynagrodzeń na zebraniu związków zawodowych (mówię teraz o projektach biznesowych).
Moim zdaniem metody nie raz doskonale działające w projektach internetowych nie sprawdzają się w projektach biznesowych. Niestety widzę nie raz jak wykładają się na biznesowych projektach znane i dobre agencje interaktywne. Po drugie w biznesie jest drugi istotnie inny element: w proces biznesowy jest zaangażowanych wiele osób ale każda zna go tylko na „swoim odcinku”. Jeżeli więc np. ja jako klient sklepu internetowego sam jestem aktorem całego procesu zakupu książki i mam prawo o nim mówić, tak jako pracownik magazynu nawet średniej firmy nie mam, żadnych podstaw by dyskutować o procesie logistycznym. To jest zresztą kluczowy powód by takie analizy robił ktoś z zewnątrz ale nie dostawca (ten ma już swoje rozwiązanie i będzie forsował, nawet jeśli jest to developer i tylko jakiś jego framework i zestaw wypracowanych własnych bibliotek).
I tak, i nie 🙂
Wcale nie twierdzę, że na warsztatach, JADach i innych takich powinien zakończyć sie etap zbierania wymagań. Mam raczej zdanie, że warsztaty właśnie (ale odpowiednio przeprowadzone, z dobrze zarysowanym celem, odpowiednim przygotowaniem i przeprowadzeniem) mogą nam pomóc lepiej zrozumieć problem biznesowy sponsora oraz użytkowników. A później można to przełożyć na weryfikowalne modele.
Powoływanie się na poprzedni system ma tę zaletę, że pozwala znaleźć problemy, które można spróbować rozwiązać w kolejnej wersji systemu. Chociaż czasami może być to niebezpieczne, szczególnie w przypadkach, gdy użytkownicy boją się zmiany. W takiej sytuacji mogą próbować utrudniać pracę niestety.
No to zbliżamy się do celu: jeżeli JAD ma pomóc lepiej zrozumieć problem biznesowy sponsora oraz użytkowników, to ja w to miejsce żądam od klienta zestawu przykładów dokumentów (np. trzy egzemplarze każdego, z informacją kto jest wystawcą każdego z nich i komu go przekazuje) i na tej podstawie „odtwarzam” procesy w firmie oraz wstępny model dziedziny. Jak nie trudno się domyśleć, modele te są dziurawe jak ser i wymagają uzupełnień, i tu spotykam się z ludźmi (lub nawet tylko dzwonię) by wyjaśnić braki. Po pierwsze dokumenty są obiektywne, wywiady już nie koniecznie. Po drugie cały taki proces jest szybszy i mniej kosztowny (nie zbieram na całe dnie dużych zespołów ludzi klienta, sam nie tracę czasu na nie raz gorące dyskusje, robię to sam, czyli kolejne niższe koszty) więc klient odnosi korzyść. Zaś problem i cel klienta musi być ustalony na samym początku projektu poprzez sakramentalne: na grzyba Panu/Pani ten system 🙂 bo to daje światełko w tunelu na cały czas trwania projektu …
Witaj Jarku, dziękuję Tobie za wiele wartościowych artykułów, które, oprócz przekazywania wiedzy, zmuszają również do przewartościowania pewnych rzeczy.
Jednak jeśli analityk biznesowy ograniczy/umniejszy za mocno ilość i wartość wiedzy od użytkowników systemu, to moim zdaniem istnieje zagrożenie, że będzie forsować swój model referencyjny (czyli bazować tylko na rozwiązaniach z poprzednich analiz i swojego doświadczenia). W efekcie powstanie analiza oderwana od rzeczywistości – przedstawiająca ideał przedsiębiorstwa, a nie stan faktyczny. Często bywa tak, że procesy faktyczne różnią się od tego, jak się wydaje kadrze zarządzającej najwyższego szczebla (sponsorowi). Bez rozmów z użytkownikami/pracownikami firmy nie można takich odchyleń wychwycić.
Inną kwestią jest to, że np. nie dowiemy się, że poprzedni system próbował wprowadzić procesy zbyt modelowo/teoretycznie (za duża ingerencja w procesy firmy), które ze względu na opór przed zmianą były sabotowane przez użytkowników lub po prostu niepraktyczne w danym przedsiębiorstwie (np. wydzielenie funkcji do różnych modułów, które są obsługiwane przez tych samych użytkowników).
Oczywiście zbyt obszerne bazowanie na wywiadach i warsztatach z użytkownikami może prowadzić do ścierania się różnych sił w przedsiębiorstwie. Jednak, gdy użytkownicy zobaczą nowy dedykowany system zbyt późno, może się okazać, że nowy system jest gorszy od starego (tak ogromny jest opór przed zmianą, która nie wynika oddolnie). No i jeszcze trzeba uważać, by nie „zabetonować” nieoptymalnych procesów biznesowych. A jednocześnie przez przypadek nie dostosować dobrych procesów do procesów referencyjnych, co może z bardzo dobrego przedsiębiorstwa uczynić przeciętne.
Problem nie jest prosty. Osobiście uważam, że znane z organizacji i zarządzania podejście trójwarstwowe (podział organizacji na warstwę budowania strategii, procesów biznesowych i realizacji) daje podstawę do prowadzenia projektów analizy przed-wdrożeniowej i projektowania oprogramowania. Cel biznesowy musi wyjść od Zarządu, który wie co chce osiągnąć. Procesy biznesowe opisują to co i po co się dzieje w organizacji. Procesy realizują cel biznesowy firmy (stanowią wewnętrzny łańcuch wartości). To jak pracują ludzie to sposób wykonywania tej pracy w konkretnych warunkach. Po latach funkcjonowania te trzy warstwy są „zintegrowane”, ludzie pracują, firma funkcjonuje. Ale: to Zarząd podejmuje decyduje, że coś będzie sprzedawał, proces wystawiania faktury VAT musi istnieć, to jak faktura zostanie wystawiona zależy już od wielu lokalnych warunków – to specyfika wykonania. Zarząd jednak narzuca regułę (biznesową): wszystkie dokumenty operujące wartością 10.000zł lub więcej muszą być zatwierdzane przez zarząd. Rola analityka biznesowego jest praca bliska destylacji zmieszanego płynu: musi to wszystko rozdzielić na owe trzy warstwy. Oprogramowanie z jednej strony wspiera procesy biznesowe więc wspiera powstawanie produktów procesów. Tu mamy przypadki użycia (usługi systemu). Z drugiej strony oprogramowanie to narzędzie pracy, wiec pojawia się pytanie jak ma to robić i tu mamy scenariusze tych przypadków użycia (to warstwa realizacji). Na koniec: cała organizacja pracuje z jakimiś informacjami (danymi) więc potrzebny jest model informacyjny. Teraz należy się zastanowić: w czym, w którym etapie tej pracy może na pomóc pracownik pracujący w jednym miejscu (na jednym stanowisku)?