Na początek historyjka. Stolarz ma zwykły młotek, którego używa do wbijania gwoździ. Prosty młotek to trzonek i prosty pobijak. W miarę rozwoju firmy pojawia się problem: stolarze mają problem z otwarciem piwa podczas pracy, zaczynają szukać sposobu, często odbijają kapsle młotkiem, nie raz uszkadzając butelkę. Z uszkodzonej butelki picie jest niebezpieczne więc odpowiedzialni pracownicy, w takich przypadkach, muszą iść do sklepu po drugie piwo. Powoduje to stratę czasu i spadek wydajności. Pojawia się wymaganie biznesowe: poprawić wydajność stolarzy w procesie prac budowlanych. Strategia: usprawnić narzędzia. Taktyka: zaprojektować młotek, który nie uszkadza kapslowanych butelek podczas otwierania.
Analityk musi zrozumieć problem i zaproponować rozwiązanie
No to do roboty: czynności wykonywane przez stolarzy w procesie konstruowania drewnianych konstrukcji to wbijanie gwoździ (czyli ogólnie „pobijanie”) oraz otwieranie kapslowanych butelek z piwem. Obie czynności ma realizować „młotek” (przyjęta taktyka rozwiązania problemu). Czynności te więc stają jego, młotka, przypadkami użycia.
Młotek świadczy jedną usługę: wsparcie stolarza w czynnościach, których nie można wykonać dłońmi. Decydujemy (decyzja projektowa), że oba przypadki użycia (usługę tę) będzie realizowała główka młotka (klasa usługowa), a nie np. trzonek zakończony otwieraczem. Tak więc na bazie wykonywanych czynności i wiedzy, że ma to być to samo narzędzie pracy, uznajemy, że młotek ma mieć dwa przypadki użycia: pobijanie oraz odkapslowanie. Projektujemy młotek, model dziedziny ma dwie klasy: trzonek i główka. Główka to usługowa klasa i będzie miała dwie operacje: pobijanie i otwieranie kapslowanych butelek.
Implementacja (obraz po lewej) to dzieło producenta narzędzi: młotek typu drugiego. Jak widać główka świadczy usługę (trwały metalowy element roboczy) użyteczną do pobijania i otwierania butelek (ma dwie operacje).
Co więc mamy? Wymaganie biznesowe, produkt wraz z tym jakie usługi potrafi świadczyć, przypadki użycia czyli to, do czego faktycznie można (chcemy) użyć tego młotka oraz projekt realizacji.
Czynności w procesie biznesowym (model biznesowy) mapują się na przypadki użycia produktu (model – [[projekt jako czarna skrzynka]] – tego produktu).
Jednak niczego nie wiemy o tym, co należy zrobić do czasu, gdy ktoś nie opracuje projektu produktu. Autor pomysłu zawarł w projekcie dwa elementy: trzonek i dwu-funkcyjną główkę czyli dwie klasy dziedzinowe i ich operacje (główka: Uderz oraz Zerwij kapsel i trzonek: połącz dłoń z główką młotka). Implementacja (design, dobór materiałów itp. to inżynierska „robota” czyli realizacja projektu. Tu są realizowane wymagania poza-funkcjonalne np. młotek ma wytrzymywać 1 mln. uderzeń, nie może ważyć więcej niż 1,5 kg.
Można było stolarza zaopatrzyć w standardowy otwieracz do butelek, jednak mamy tu ograniczenie strategiczne: nie chcemy powiększać liczby przedmiotów w wyposażeniu stolarza. Tak więc taktyka musiała być taka jaką tu wybrano.
Mam nadzieję, że ten prosty przykład obrazuje „taksonomię” (klasyfikację) wymagań. Sam kiedyś miewałem z tym problem, szczególnie gdy projekt się rozrastał.
Problemem większości projektów programistycznych jest nie tyle lista wymagań (choć może być niekompletna lub niespójna, jeżeli powstanie jako deklaratywna lista rękami pracowników), problemem projektowym jest zamiana wymagań na usługi systemu i projekt ich realizacji.
Co więc mamy w projektach, których celem jest dostarczenie oprogramowania:
- wymagania biznesowe – wymagania względem nowego lub zmienianego modelu biznesowego lub strategii czyli co chcemy osiągnąć w organizacji,
- wymagania produktowe – to czego oczekujemy od nowego produktu (narzędzia pracy) czyli jak to chcemy osiągnąć (zapadła ewentualna decyzja o potrzebie posiadania stosownego produktu),
- usługi produktu – to co produkt potrafi zrobić dla jego użytkownika czyli co produkt powinien „umieć”,
- proces biznesowy – lista czynności jakie wykonują przyszli użytkownicy produktu czyli kiedy będziemy używać produktu,
- przypadki użycia wywodzone z procesów – to do czego użytkownik chce użyć produktu,
- model produktu – struktura opisująca wewnętrzne elementy produktu (moduły) i ich możliwości (operacje jakie potrafią wykonać) oraz ich wzajemną współpracę (scenariusze współdziałania), pozwalającą na wykonanie usługi (zrealizowanie kolejnych przypadków użycia) czyli jak powinien być skonstruowany produkt (jego obiektowy model – dziedzina systemu); model produktu to wymagania dziedzinowe.
Odpowiedzialność za wymagania w projektach programistycznych
Projekty programistyczne i analiza poprzedzająca ich realizację, powinny być dostosowane (poczynione pewne założenia) do dostępnej na rynku technologii i metod wytwarzania oprogramowania. Wśród nich są metody obiektowe analizy i projektowania oraz obiektowe języki programowania i szkielety oprogramowania (frameworki), pozwalające na implementację projektów wykonanych w obiektowym paradygmacie.
Wydaje się, że obiektowe metody są najskuteczniejsze w przypadku oprogramowania dla biznesu. Bardzo popularny i chyba najstarszy obiektowy wzorzec projektowy to wzorzec [[Model, View, Controller (MVC)]]. W dużym uproszczeniu:
- Model opisuje dziedzinę systemu,
- View opisuje to co widzi użytkownik,
- Controller steruje tym wszystkim.
Stosuję ten wzorzec do podziału zadań (odpowiedzialności) w projektach z następującymi konsekwencjami:
- View (widok): klient „zamawia” formularz (papier/ekran), bo klient wie „co chce mieć”,
- Analityk tworzy Model Dziedziny: 100% obiektów dziedzinowych z regułami (atrybuty i operacje biznesowe),
- Analityk dostarcza listę wymagań poza-funkcjonalnych (oczekiwane wydajność, bezpieczeństwo, dostępność itp.),
- Developer implementuje Model Dziedziny tworząc oprogramowanie, z pomocą używanego szkieletu oprogramowania rozwiązuje problemy poza-funkcjonalne lub zgłasza ograniczenia ich realizacji.
I tak mamy: 100% interfejsu użytkownika zamawia użytkownik (sam lub z pomocą specjalistów), 100% wymagań funkcjonalnych realizuje Model Dziedziny (projekt analityka-projektanta), 100% wymagań poza-funkcjonalnych realizuje developer (projekt i implementacja). Developer także implementuje model dziedziny z pomocą technologii jakiej używa.
A jeżeli klient powie: nie mamy tych wzorów dokumentów i ekranów! To pierwszy sygnał, że nie ma podstaw do zamawiania jakiegokolwiek oprogramowania, bo najpierw trzeba „wiedzieć co się chce”.
Jak to zrobić? Tu kłania się analiza biznesowa: modelujemy procesy biznesowe, dla każdego z nich ustalamy wejście oraz efekt (produkt) czyli właśnie owe „wzory dokumentów”. Po uporządkowaniu tego i upewnieniu się, że nie ma w tym bałaganu (powtórki, braki, niekonsekwencje, sprzeczności itp.) możemy pytać o gotowe oprogramowanie lub „zamawiać” jego wytworzenie. Produktem pracy analityka powinny być, poza modelami procesów bo one są narzędziem a nie celem, obiektowy model dziedziny czyli model tego jakimi informacjami i jak zorganizowanymi operuje organizacja, oraz to jak pracownicy tej organizacji chcą się komunikować z oprogramowaniem (źrodłem informacji jest jednak klient).
Mamy czysty podział odpowiedzialności i łatwość rozliczenia projektu. Na czym polega haczyk? Klient nie może unikać odpowiedzialności za skutki swoich decyzji i udzielanych informacji. Ale też, co jest kluczowe: Analityk musi zrozumieć problem i zaproponować rozwiązanie.
Jednak nie jest rolą analityka wykonanie oprogramowania! To „jak – technologia – ma to zostać zrealizowane” jest decyzją developera. Ma dużo pracy. Nie zapominajmy, że kod realizujący tak zwaną logikę biznesową to ledwie kilka procent całości kodu aplikacji, jednak nie zapominajmy także (programiści), że zła logika biznesowa dyskwalifikuje całe to oprogramowanie z prostego powodu: staje się nieprzydatne.
___
Po wielu dyskusjach na szkoleniach prezentuję zgodny z UML diagram przypadków użycia dla młotka:
Znakomity case! 🙂
„Analityk musi zrozumieć problem i zaproponować rozwiązanie.”. Jasne, wtedy mamy pewność, że robimy oprogramowanie, które pomaga. Czasem jednak klient nie chce dzielić się problemem lub dla usprawnienia pracy podaje rozwiązanie wg swojej wiedzy. Wtedy tracimy kontrolę: czasem się ono sprawdzi, innym razem nie.
„A jeżeli klient powie: nie mamy tych wzorów dokumentów i ekranów! To pierwszy sygnał, że nie ma podstaw do zamawiania jakiegokolwiek oprogramowania, bo najpierw trzeba ?wiedzieć co się chce?.”. Gorzej, kiedy wyciąga cokolwiek potwierdzając do samego końca etapu wytwarzania, że to właśnie odpowiednie ekrany, a potem zmieniając zdanie 🙂
Często spotykam się z sytuacją, w której sponsor projektu zawiera umowę, a jako „źródło informacji” wyznacza „zwykłych” pracowników, przyszłych użytkowników systemu. To największy błąd, rozkładający projekty. Niestety wielu konsultantów i programistów firm dostarczających (tworzących) oprogramowanie własnie taka metodę forsuje jako najlepszą… to troszkę jak by zlecić opracowanie wymagań na nowy system wynagrodzeń wynagradzanym pracownikom… Projekty, w których źródłem informacji o wymaganiach są wyższe kadry kierownicze są obłożone znacznie mniejszym ryzykiem.
Ale „nie ma obowiązku zawierania umowy”… a powyższe to niestety coś, po czym ja znajduję pracę…
Z mojego doświadczenia zaobsewowałem również, że niektóre firmy decydują się na tworzenie zaplecza analityków biznesowych, wśród własnych pracowników. Doskonale rozumiem, że część wiedzy jest zbyt ważna, wręcz strategiczna, aby łatwo przekazywać ją na zewnątrz. Niestety, czasami zadarza się, że wewnętrzni analitycy, pełnią dodatkowo w oragnizacji wiele innych ról, dopiero zaczynają gromadzić stosowną wiedzę, nie mają doświadczenia, a powieża im się projekty o znaczeniu strategicznym dla firmy. Jakie są tego skutki…? na tym forum i czytelnikom ninijeszego bloga z pewnością nie muszę opisywać.
Swego czasu powiedziałem pewnemu Prezesowi, gdy mnie zapytał „Po co mi Pana usługi, mam swój cały dział IT i analityków od wielu lat”. Odpowiedziałem: „Co by Pan powiedział o lekarzu, który przez kilkanaście lat leczy wyłącznie Pana, jak oceniłby Pan praktykę i różnorodność doświadczenia, wiedzę osobistego lekarza? Jakim specjalistą jest mechanik, który całe życie ma do czynienia wyłącznie z własnym samochodem?”
Kilka wątków, z którymi można mocno dyskutować
– „źródło informacji”: myślę, że ani wyższe kierownictwo ani, szeregowi pracowanicy nie są w satanie niezależnie dostarczyć kompletu informacji. Po pierwsze każdy trzyma swoją perspektywę, a po drugie występują silne tendencje do „upiększania” rzeczywistości. Rozwiązaniem jest zangażowanie obu szczebli, czy to poprzez niezależne modelowanie procesu, czy chociaż jego weryfikację(zaczynamy od pracownika i dyskutujemy z kierownictwem + wspólne wyjaśnienia)
– „wewnętrzni analitycy vs. zewnętrzni” – tu kompletnie się nie zgodzę z uogólnieniem, wszystko zależy od kompetencji i doświadczenia. Miałem okazje obserwować obie strony z obu perspektyw i różnie to bywało. Rozwiązanie jest gdzieś po środku, są rzeczy ktore lepiej zrobi zewnętrzny analityk, są takie które wewnętrzny no i zdarzają się przypadki, że współpraca daje super efekty.
Pozdrawiam M
Co do „źródła informacji” to prawda, dlatego zawsze model procesu jest weryfikowany z jednymi i drugimi, jednak „nie dopuszczam” do pobożnych życzeń. Obie strony informuję, że należy „wykazać” na procesie sens i potrzebę każdego wymagania. Modele są tu kluczowym narzędziem pracy (a nie spowiedź usera czy userstory).
Co do „analityków wewnętrznych, zewnętrznych i analityków dostawcy”. Jeżeli uznamy, że nie dyskutujemy o poziomie ich kompetencji (nie podważamy ich kompetencji), to pozostają rzeczy, na które zwracają uwagę moi klienci:
– jeżeli pojawiają się jakieś ograniczenia analityk dostawcy lobbuje na korzyść marży dostawcy a analityk kupującego na korzyść potrzeb kupującego, osobiście uważam, że tu „racje ma ten, który płaci” bo to jemu ma to oprogramowanie pomagać.
– jeżeli chodzi o kwestie analityk własny lub zewnętrzny u kupującego, to po pierwsze: zewnętrzny nie jest niczyim podwładnym i nie musi z nikim „trzymać”, a to ryzyko jest prawie pewne (w końcu to pracownik tej firmy); niejeden projekt zabiły kompromisy wynikające wyłącznie z tego, że „własny analityk” ma wszystko poza jednym: jego niezależność = 0. Praktycznie na każdym szkoleniu zamkniętym słyszę: „Pan może ale my nie możemy tego powiedzieć przełożonym, my tam po projekcie zostaniemy”, ale jeżeli projekt dotyczy rozwoju oprogramowania, własny analityk jest nieocenionym partnerem dla zewnętrznego (o ile własnemu testosteron do głowy nie uderzy :))
Ogólnie bazuję na blogu w 100% na ryzykach różnych kombinacji i sytuacji, ale owszem nie da się wykluczyć wyjątków, które wyłamują się powyższym „zarzutom”. Jednak moim zdaniem należy uznać fakt, że te ryzyka (opisywanych tu patologii) istnieją i owocują ponurymi statystykami…
Ryzyko „głupiego kompromisu” jest poważne i na pewno się materializuje, ale poważne ryzyka występują również w przypadku zewnętrznego analityka np. chęć zbyt szybkiego zamknięcia kontraktu, przydzielanie w późniejszych etapach projektów mniej kompetentnych zasobów itp…
Z mojego doświadczenia wynika, że bardzo dobrze sprawdza się model z silnym i umocowanym liderem wewnątrz organizacji, który umiejętnie korzysta i z zewnętrznych(wnoszących świeże spojrzenie i inne podejście) i wewnętrznych(znających i rozumiejących organizację) sił analitycznych.
Oczywiście taka współpraca stwarza pewne wyzwania, ale dobra organizacja pracy da w rezultacie win-win.
Stawiam na drugi akapit 🙂
W opisywanym przypadku zastosowałbym moje ulubione, aczkolwiek niezbyt wyrafinowane narzędzie analizy – 5 WHY („ale po co?”). W efekcie otrzymalibyśmy dogłębne rozpoznanie problemu i potrzeb użytkownika. Następnie analityk powinien zaproponować potencjalne rozwiązania, oczywiście uzupełnione o kompleksową analizę SWOT każdego z nich. W powyższym przypadku mamy case już rozpracowany.. ale czy lepszym rozwiązaniem dla sponsora projektu, nie byłoby tutaj „piwo w puszce” 🙂 ??
Dręczenie ludzi metodą '5 x why” zakłada, że „w końcu z nich to wyciągniemy”… co niestety rzadko jest prawdą. Tej puszki piwa na pewno tą metodą klient „nie wykoncypuje”. Puszka piwa jednak odpada, bo to projekt rozwoju młotka. Owszem do rozważenia jest oddzielenie tych dwóch dziedzin od siebie ale analiza wskazuje, że celem jest narzędzie a dwie dziedziny: stolarka i spożywanie piwa.
Analizy SWOT to testy zaistniałych pomysłów (produkt, firma, …) a nie szukanie rozwiązań. Analiza SWOT to narzędzie z obszaru analizy wykonywalności. Owszem spotykam dokumenty, że każde wymaganie jest poddawane analizie SWOT ale to już raczej przerost formy nad treścią.
Czy „piwo w puszcze” było by tu lepsza dla sponsora? Piwo i jego sposób pakowania jest tu całkowicie poza zakresem projektu, to element otoczenia na który nie mamy wpływu. Wymaganie brzmi: kapsel :).
Ale poruszyliśmy ciekawy temat: kto ma wiedzieć co ma powstać? Naście lat doświadczenia, i kolejne lata, utwierdzają mnie w przekonaniu, że użytkownik nie powinien być projektantem: ani domów, ani samochodów, ani samolotów ani oprogramowania. Może być tym, kto zgłosi uwagi do rozwiązania, które dostał. Dlaczego? Po pierwsze to nie jego rola w projekcie, jestem przeciwnikiem tezy, że odpowiedzialność za niepowodzenie projektu ma być zrzucana na „usera który nie wie czego chce”, on nie jest projektantem. User story prawie zawsze prowadzi to efektów „dostałem dokładnie to czego chciałem a nie to czego potrzebuję”…. Żaden „oficer bezpieczeńtwa” nie pyta się czego chce „user”, tylko dostaje wymagania biznesowe i projektuje politykę bezpeczeństwa, user musi się do niej stosować… i chyba obaj wiemy dlaczego: większość rozwiązań technologicznych chroni userów przed nimi samymi 🙂 …