Krótki wpis po pewnej nie długiej dyskusji na pewnym forum. Jeden z dyskutantów przytoczył definicję zakresu projektu publikowaną w WIKI:
Zakres projektu jest to możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu.
Zakres nigdy nie określa konkretnych zadań mających na celu realizację projektu. Odpowiada na pytanie, co powinno być zrobione w projekcie. Wyznacza ramy do oszacowania kosztu projektu i czasu realizacji projektu. Zakres, koszt i czas tworzą parametry projektu, tzw. ?magiczny trójkąt?. (Zakres projektu ? Wikipedia, wolna encyklopedia).
Tak więc mamy pytanie: “co powinno być zrobione w projekcie”? Pytanie jakie ja postawiłem: “czyim projekcie”? Zakres projektu dla kogo?
Księgowa
Zacznijmy od początku, pewna Księgowa chcę nowe oprogramowanie, z jej perspektywy padną następujące oczekiwania:
- wystawianie faktur sprzedaży (w załączeniu wzory faktur)
- rejestracja zamówień klientów (w załączeniu przykłady zamówień)
- oprogramowanie ma działać bezawaryjnie (dopuszczamy przerwy trwające do godziny czasu ale nie częściej niż raz w tygodniu)
- wystawione faktury mają być eksportowane do biura księgowego.
- z oprogramowania korzysta wyłącznie księgowa
Od księgowej więcej bym nie oczekiwał bo ta osoba ma za zadanie opisać tylko to czego potrzebuje do pracy. Tak zwany biznes zawsze opisze potrzebne mu narzędzie ze swojej perspektywy, podobnie jak moja mama, gdy poprosiła mnie o pomoc przy kupnie nowego telewizora: ma się nadawać do odbioru kablówki, mieć HD i mieścić w regale pod książkami. Więcej nie trzeba. To ja pilnowałem by ambitny sprzedawca nie wcisnął, nie znającej się na tej technologii emerytce, wypasionego TV na raty o przekątnej wymagającej osobnego salonu.
Wracamy do księgowej
Mamy zakres projektu, przypomnę definicję: możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu. Opis księgowej spełnia te kryteria. Ale mam problem z resztą definicji z WIKI: zakres określa “co powinno być zrobione w projekcie”. I tu WIKI w moich oczach niestety przemilcza ważny fakt: o jaki projekt chodzi, co jest tym projektem, dla kogo jest to zakres projektu?
Na pytanie “co powinno być zrobione w projekcie” odpowie dopiero projektant.
Komu księgowa postawiła zadanie? Na pewno nie programistom bo tu nie ma nic do kodowania… Przedstawiony powyżej zakres, to zakres dla Analityka biznesowego projektanta. Ktoś musi zamienić opis funkcjonalności nowego narzędzia (oprogramowanie dla Księgowej) na jego projekt (pamiętamy poprzedni artykuł o młotku). Księgowa opisała wymagania swoje funkcjonalne i poza-funkcjonalne (ograniczenia jakościowe).
Pominąłem tu ich spójność i kompletność. Jeżeli zachodzi ryzyko, że są niekompletne warto je opracować skuteczniejszą metodą niż “lista z pamięci” czy efekt “burzy mózgów“, ale to inny temat ;). Ważne jest to, by te wymagania były jednoznaczne, nie nadmiarowe, spójne. Jak to osiągnąć?
Model wymagań czyli schemat blokowy
Poniżej diagram obrazujący dokładnie to co opisała Księgowa:
Po co ten obrazek, skoro Księgowa to napisała, przecież to to samo tylko w postaci obrazka. Tak to to samo, problem w tym, że gdyby ten opis był tekstem np. na 100 stron, niemalże niemożliwe było by wychwycenie niespójności i powtórzeń. Powyższy diagram pozwala sprawdzić, czy mamy właściwie skojarzonych użytkowników z tym jakie czynności będą wykonywali, czy nie ma zdublowanych funkcjonalniej (jajeczka) i nakładających się ról (ludzik, tak zwany Aktor systemu). Najważniejszy jest tu prostokąt o nazwie Nowy Fajny System dla Księgowej, bo on pokazuje Zakres projektu. Teraz wiemy, że wykonawcę nie interesuje Biuro Księgowe, interesuje go tylko “jakie pytanie ma obsłużyć”.
Jeżeli padnie pytanie o szczegóły tych funkcjonalności, należy je jednoznacznie przyporządkować albo do Aktora albo do Systemu. Np. jak padnie pytanie o to, jak się nalicza podatek VAT, powinno paść dodatkowe pytanie: kto ten podatek ma naliczać, Aktor czy System (podział odpowiedzialności, zakres projektu). Uporządkowanie tego da nam jasny zakres projektu. Mając dobre narzędzie, można z takiego diagramu bez problemu wykonać oczekiwany tekstowy raport specyfikujący wymagania na system i wszelkie ograniczenia jakimi są umiejętności aktorów i wymagania jakościowe (tak zwane poza-funkcjonalne).
Gdyby tych wymagań było nie kilka a kilkadziesiąt, bez takiego modelu bardzo trudne było opracowanie takiej specyfikacji bez ryzyka niespójności i braków oraz zagwarantowanie, że zakres projektu jest jednoznaczny i dobrze przemyślany. Po drugie jeden taki diagram zastępuje kilka, kilkanaście stron tekstu, a z czym łatwiej się nam będzie szybko zapoznać?
Duża liczbę wymagań, dla czytelności diagramów i uporządkowania wymagań, dzieli się na kilka takich diagramów np. kontekstowo, tak by na jednym diagramie nie było więcej niż kilkanaście obiektów. Czy ten diagram, po powyższym komentarzu jest niezrozumiały? Właśnie Państwo poznali Diagram Przypadków Użycia z notacji UML.
Można spotkać te diagramy poszerzone o mało zrozumiałe dla laika pojęcia <<extend>>, <<include>> i inne, jednak moim zdaniem to niepotrzebnie je komplikuje i czyni niezrozumiałymi dla Zamawiającego, a to Zamawiający określa wymagania i diagram ten nie powinien u Zamawiającego budzić żadnych wątpliwości (powinien się pod nim bez strachu podpisać). Jeżeli więc Państwu jako Zamawiającemu, ktoś da do podpisu dokumentację, której nie rozumiecie w 100%, to po prostu nie podpisujcie się pod nią, bo to zła dokumentacja skoro jej nie rozumiecie, a powstała dla Was bo macie ją podpisać.
Na tym byśmy poprzestali gdyby celem był zakup gotowego oprogramowania. A jak nie, jeżeli z jakiegoś powodu musimy mieć dedykowane?
Co dalej?
Diagram ten w 100% opisuje zakres projektu z perspektywy Zamawiającego, ale jest zupełnie bezwartościowy dla programisty (kodera). Bo zakres projektu, opis, musi mieć adresata. Zakres projektu owszem ale dla kogo?
Szybki przegląd od końca: zakres projektu dla programisty (przypomnę definicję) jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu, to opis kodu jaki ma programista wytworzyć. Czy diagram Przypadków mu to powie? Absolutnie nie!
Zakres projektu dla programisty stworzy Architekt systemu, kluczowa rola w każdej dobrej firmie programistycznej. Co jest zakresem projektu dla Architekta systemu? Architekt oczekuje opisu tego jaką logikę ma realizować oprogramowanie, jakimi danymi i jak ma zarządzać System. Kto to ma zrobić?
Analityk biznesowy
Powyższy diagram przypadków użycia, to pierwszy etap pracy, ktoś – znowu Analityk biznesowy bo poznał i zrozumiał biznes Zamawiającego na etapie opisu wymagań biznesowych, musi teraz powyższe zamienić na, najlepiej obiektowy, model (dokumentację) całej logiki biznesowej (dane i metody ich przetwarzania) jaka ma być zaimplementowana: tak zwany model dziedziny systemu.
Zakładam, że użyte zostaną obiektowe metody i narzędzia implementacji. Obiektowe metody analizy zdobyły sobie uznanie bo dają jednoznaczne opisy, to teraz w zasadzie standard w oprogramowaniu dla biznesu.
Zakres projektu dla Architekta
Tu pojawią się więc: klasy, sekwencje, statusy klas, algorytmy metod. To jest zakres projektu dla architekta, który “wpakuje” to np. w strukturę używanego frameworka i stworzy zakres projektu dla programistów.
Na zakończenie
W moich oczach nie ma nic bardziej ryzykownego niż przekazanie Opisu Księgowej od razu programistom do wykonania. Bo mamy tak na prawdę trzy zakresy projektu, każdy inny, każdy ma innego adresata i każdy należy udokumentować inaczej, ale zawsze jednoznacznie postawić zadanie.
Praca bez tego typu dokumentów, bez jasnego wydzielenia poszczególnych etapów analizy, tak często praktykowana przez wiele firm IT, to atak na twierdzę bez mapy terenu i strategii…
P.S.
Wpadł mi dziś ręce artykuł: Sygnity wykona system e Podatki. Powiem tylko tyle: system za 232 mln. wyceniono na podstawie opisu (OPZ) mającego 23 strony: http://www.mf.gov.pl/_files_/ministerstwo/przetargi/si…, jestem pod wrażeniem metod wyceny. Każdy inny projekt inżynierski wart 232 mln. miałby pewnie pół kontenera dokumentacji przetargowej, a tu proszę 23 strony…
Moim koledzy informatycy dostrzegają zwykle sformalizowane i dobrze działające procesy, które może wykonywać “maszyna”. W rzeczywistości procesy, w których biorą udział ludzie są bardzo skomplikowane. Z pewnością jest sztuką i wymaga sporego doświadczenia opisanie ich w sposób czytelny i jednoznaczny. Bez zdobycia wiedzy na temat działania organizacji zamawiającego, niejednokrotnie spotkałem się w swej pracy zawodowej z dużymi problemami w kolejnych etapach “projektów informatycznych”.
W tym kontekście, chciałem przytoczyć ciekawą definicję wiedzy według Davnporta i Prusaka:
“Wiedza to płynne połączenie ukształtowanego doświadczenia, wartości, informacji kontekstowej i ekspertyzy, które zapewniają model oceny oraz pozwalają wcielić nowe doświadczenia i informacje. Swój początek i odniesienie znajduje w umysłach ludzi posiadających wiedze. Jest osadzona w dokumentach, repozytoriach, procedurach, procesach, praktykach i normach organizacyjnych.”
Apropos PS. 10 mln buforu na ryzyko niewłaściwych założeń na każdą stronę 🙂
To ważne, co Pan napisał o 3 perspektywach (klient, architekt, programista). Warto o to zadbać…
Jeśli chodzi o pisanie dokumentacji zrozumiałej dla klienta i jednocześnie już przedstawiającej wynik analiz (kompletność, spójność, zgodność z celami), to wydaje mi się wyzwaniem. Ma Pan więcej spostrzeżeń na ten temat? Co dla klientów jest zrozumiałe, co dla architekta jest dobrą podstawą do dalszej pracy? Czy to to samo lub czym się różni?
Pisanie dokumentacji zrozumiałej dla klienta to część pracy. “Umownie” dzielę projekty, a raczej “to co opisze”, na dwie kluczowe części: audyt czyli opis (model) tego co Klient robi (jego firma, jak pracuje itp.), to dokument, który powinien być w 100% rozumiany przez Klienta bo to jego opis. Np. opisany diagram przypadków użycia. Potem jest “jakiś projekt”, jego adresatem jest już kto inny: Architekt/Developer. Tej części Klient nie musi rozumieć, a nawet czytać. Dlaczego? Bo to jest “to czego klient nie potrafi a jest mu potrzebne”. Prosty inny przykład. Klient potrzebuje zawrzeć umowę z Chińskim partnerem. Spotyka się z prawnikiem, opisuje mu co jest celem umowy. Prawnik pyta o ryzyka planowanej współpracy i na tej podstawie opracowuje treść umowy. Te treść Klient czyta i zatwierdza. Następnie tan sam prawnik lub tłumacz, tłumaczy te umowę na Chiński. Tej części pracy Klient nie weryfikuje bo nie jest w stanie ale nie pozostaje mu nic innego jak zaufać swojemu usługodawcy lub zrezygnować.
Wydawało by się to wszystko oczywiste, a mimo to tak wielu ludzi rzuca się od razu do rozmowy z Chińczykami… Ci zaś chętnie je prowadzą bo robią za pieniądze tego pierwszego.
Zacytuje trwająca dyskusję, zgłoszono w dyskusji ważne pytanie:
” Powyższy diagram pozwala sprawdzić, czy mamy właściwie skojarzonych użytkowników z tym jakie czynności będą wykonywali, czy nie ma zdublowanych funkcjonalniej (jajeczka) i nakładających się ról (ludzik, tak zwany Aktor systemu). ”
Kluczowym testem sensu i wartości treści, np. dokumentacji wymagań, są (mogą być, gorąco polecam) tak zwane “widły Hume’a”. Czym są owe Widły Hume?a? Każdą wypowiedź (zapis w dokumentacji) należy sprawdzić dwoma pytaniami:
1. Co to znaczy?
2. Skąd to wiesz?
Jeżeli więc napiszę w dokumentacji, że “system ma ….” i tu pojawi się skończona lista wymagań (albo projekt architektury itp.), oraz dołożę do tego zapis: opracowane wymagania są spójne i kompletne, to w “profesjonalnie wykonanej dokumentacji” powinna pojawić się odpowiedź na pytanie Co to znaczy “Spójne i kompletne” a potem na pytanie “Skąd to wiemy”.
Na pierwsze pytanie odpowiedź udziela sł. j.polskiego:
spójny ?logicznie powiązany, harmonijny, konsekwentny?,
kompletny ?taki, w którym nie brakuje żadnego z elementów?
Nie, słowniki są powszechnie dostępne, wystarczy podać którego użyto (Tu SJP, PWN).
Na drugie pytanie odpowiedzią są modele, które jako narzędzia, które posłużyły do wyspecyfikowania wymagań, pokazują “skąd to wiemy, że są spójne i kompletne”.
Co do tezy “Za dużo” znaczy “źle”, prawda, wymaga jednak uzupełnienia: co to znaczy za dużo. Każdy dobrze opracowany dokument ekspercki to “jedna strona” rekomendacji i załączone “setki stron” ich uzasadnienia (pierwsze czyta każdy, drugie ten kto chce). To uzasadnienie po pierwsze uwiarygadnia rekomendacje po drugie pozwala skorzystać z narzędzia (modeli) do ewentualnej kontynuacji tej pracy (rozwoju systemu).
Tak więc specyfikacja wymagań mogła by mieć postać suchej listy i w zasadzie powinna wystarczyć. Takie dokumenty dostarcza 99% klientów lub ich analityków. Problem pojawia się gdy zadać pytanie: czy wymagania są spójne i kompletne? Jeżeli tak, to “skąd to wiemy”?
A czego się czepiam? Bo jeżeli wymagania nie są “spójne i kompletne” to zachodzi ogromne ryzyko niepowodzenia projektu. Jedynym sposobem minimalizacji tego ryzyka jest to “skąd to wiemy, że są spójne i kompletne”
Podstawowy błąd to twierdzenie w odniesieniu do dokumentacji, że “Less is more”. Powinna być na tyle obszerna by wyjaśniała “wszystko” ale nie powinna zawierać żadnych banałów, które można odsiać “Widłami Hume’a”. Dobra dokumentacja zawiera dużo informacji ale nie “za dużo” bo to faktycznie źle.
co do P.S. to dokument na 23 stronie ma liste 15 zalacznikow
1 i 2 zalacznik maja razem 900 stron, pozostale 13 dokumentow jest gdzies po 50 stron kazdy…
To prawda, jednak te załączniki nie są projektem a listą “rzeczy do zrobienia”, nawet procesy nie są zamodelowane a jedynie wymienione. To troszkę jak wycenić drapacz chmur mając w zamówieniu jedynie wymaganą listę pomieszczeń i mapę najbliższej okolicy… Moim zdaniem te 900 stron niewiele wnosi do wyceny. Ten system będzie dopiero projektowany w ramach realizacji projektu, dlatego nadal uważam, że wyceniono coś czego jeszcze nie zaprojektowano. Dodam, że wykonawca, jako projektant, będzie autorem projektu i produktu, innymi słowy zamawiający dostanie licencje lub prawa majątkowe ale wiedza o produkcie i tak zostaje u Wykonawcy z prawem re-użycia… W ten sposób powstają (tu znowu jest takie ryzyko) produkty, których rozbudowa jest zlecana bez przetargu z uwagi na prawa autorskie (Wiele firm IT już tak się ustawiło w Urzędach).
Przeciez na tym polega realizacja projektu, klient oglaszajac przetarg okresla to co chce i jest to zapisane nie na 23 stronach, a na 1500. Wydaje mi sie , ze chyba zdanie “każdy inny projekt inżynierski wart 232 mln. miałby pewnie pół kontenera dokumentacji przetargowej, a tu proszę 23 strony?” jest poprostu blednym okresleniem, bo 1500 stron dokumentacji jest chyba tym “kontenerem”. Zainteresowal mnie ten artykul przede wszystkim tym “P.S.” i kontrowersja zwiazana z 23 stronami, ale po 5 minutowym przegladzie wcale tak zle nie jest, jak Pan opisuje;)
Same “23 strony” to przyznaję mała prowokacja ale tylko “mała”. Rzecz w tym, że pozostałe setki stron, poza opisem idei, niczego nie wnoszą. Problem w tym, że to, ogłoszony przetarg i jego zakres, to zadanie dla analityka projektanta a nie dla developera. Jeżeli analityk projektant miałby tu dużo danych do wyceny swojej usługi “analiza i projektowanie”, tak nie widzę nawet jednego zdania do wyceny kosztu “wytworzenia oprogramowania”, są dane o tym jakiej infrastruktury się oczekuje ale to “dostarczenie sprzętu”. Artykuł powyższy opisuje różnicę pomiędzy wymaganiami dla “projektu realizowanego przez analityka projektanta” a wymaganiami dla “projektu realizowanego przez wytwórcę”. Dla tego drugiego ten OPZ nie zawiera nic co nadawało by się to rzetelnej wyceny. W moim, i nie tylko, odczuciu problem wielu takich projektów (i przetargów) polega na składaniu ofert na bazie tylko “wizji”, która nie raz niewiele ma wspólnego z realiami odkrywanymi w trakcie projektu. Po drugie, jeżeli ta sama firma jest projektantem i wykonawcą nie istnieje pojęcie nadzoru autorskiego bo jak wykonawca ma sam siebie nadzorować? Jest to kuriozalna sytuacja, która np. w innych dziedzinach inżynierii jest wręcz niedopuszczalna.