O wymaganiach napisano wiele, ich kolekcjonowaniu jeszcze więcej, dokumentów wymagań pewnie są grube tysiące w setkach języków. Czy coś można do tego jeszcze dodać? Tak, kolejny przykład jak to robić. Po co? Bo projektów z zakresu oprogramowania, niemieszczących się w budżecie i terminach, projektów czasami wręcz szkodliwych, jest tak dużo (podobno ponad 80% to własnie takie), że warto szukać przyczyn… ale nie będę tu wyłuszczał jakiejś nudnej metodyki czy normy. Pokażę pewien przykład, który moim zdaniem jest antywzorcem analizy i specyfikowania wymagań.

W wielu dyskusjach o wymaganiach, pojawia się stwierdzenie: klient tak chciał.

Opracowanie specyfikacji często wygląda(ło) tak: klient opisał co by chciał (z reguły niestety sponsor projektu odsyła analityka do szeregowych pracownikow i ich kierowników). Analityk spisuje to co usłyszał. Niektórzy przerabiają takie user story na strukturalny tekst, bywa że zgodny z jakimiś normami narzucającymi spis treści (i jakieś oczywistości, np. że powinien być spójny i kompletny co by to nie miało znaczyć).

Kolejny etap to poinformowanie klienta o tym, że pewne jego wymagania są trudne lub kosztowne do realizacji, dochodzi do jakichś negocjacji i powstaje dokument finalny w postaci specyfikacji wymagań. Następnie bierze to do ręki programista, stara się zrozumieć co i do czego będzie służyło. Jeśli jego analityk, użył np. tak zwanych przypadków użycia, będzie troszkę łatwiej. Wielu z nas to zna. W czym problem?

Podam przykład świeży. W pewnym piśmie z branży IT ukazał się taki oto opis. Jest to opis produktu, który powstał, jest obecnie kupowany w odpowiedzi na wymagania, które ktoś kiedyś postawił i nadal stawia bo produkt jest nabywany (z tego co mi wiadomo).

Wiele kluczowych informacji przedsiębiorstwa znajduje się wyłącznie w wiadomościach elektronicznych. Zwykle jesteśmy świadomi jak ważne dla biznesu jest niezawodne funkcjonowanie poczty elektronicznej i trudno znaleźć jest firmę, w której nie byłyby wykonywane kopie zapasowe serwera pocztowego. Nie wszyscy jednak zdają sobie sprawę, że oprócz backupów, bardzo istotna jest archiwizacja poczty.

Jej podstawowym celem jest zapewnienie możliwości łatwego wyszukiwania wiadomości, niezależnie od tego, czy pochodzą sprzed kilku tygodni, czy lat, a mogą być potrzebne np. jako dowód w sprawie sądowej (warto zapamiętać termin ediscovery). […]

Najprostszą formą archiwizacji może być kopiowanie przychodzącej i wychodzącej poczty z serwera, nieco bardziej zaawansowana pozwoli na ustalenie kryteriów i zachowywanie tylko tych wiadomości, które je spełniają. Lepsze rozwiązania umożliwią przenoszenie zgodnie z polityką archiwizacji listów elektronicznych wraz z załącznikami, pozostawiając w skrzynkach użytkowników skróty (ang. stub) zawierające podstawowe dane (np. nadawca, adresat, temat, rozmiar). Ich otwarcie spowoduje przywrócenie z archiwum i zaprezentowanie oryginalnej wiadomości, a z punktu widzenia użytkownika nie będzie wiele się różnić od zwykłego otwierania wiadomości. Systemy archiwizujące pocztę wyposażane są w portal, za pomocą którego użytkownicy mogą samodzielnie wyszukiwać i wydobywać zachowane wiadomości ze swoich skrzynek oraz (jeśli otrzymają takie uprawnienia) innych użytkowników. (żr.  Archiwizacja poczty – luksus czy konieczność? – idg.pl Wiadomości).

Nie trzeba być geniuszem by się domyślić, że ktoś oczekuje właśnie tego co powyżej bo ma problemy z tymi dokumentami. Powyższy tekst mógł by być takim user story posiadacza programu pocztowego (w liczbie pracowników dziesiątek i setek w firmie), któremu coś kiedyś zginęło lub nie mógł znaleźć. Artykuł w dalszej części zawiera opis produktu pewnego dominującego na rynku IT dostawcy rozwiązań, który jest odpowiedzią na ten problem. (No i mamy w IDG klasyczny [[product placement]] a niezależnym piśmie branżowym – zainteresowanych o jaki produkt chodzi odsyłam do lektury źródła cytatu).

Tak więc jak zapytamy pracownika co by chciał, to się dowiemy że … i tu opis jak powyżej: Klient Nasz Pan. Czego ja się czepiam? Zauważyłem już jakiś czas temu, że ilość składowanych śmieci prawie zawsze dokładnie odpowiada objętości posiadanego śmietnika. Co mam na mysli?

Inny analityk 😉 spojrzał by na takie wymagania (o ile dał by się namówić na ich spisywanie w takiej postaci) i zapytał by managera: w czym problem? Zapewne usłyszał by, że pracownikom giną czasami bardzo ważne informacje, które mieli w poczcie.

Ten Inny analityk pochylił by się na tym i zapytał by, czym są te ważne informacje. Najczęściej są to jakieś ustalenia, oferty, treści umów itp. Jeden scenariusz rozwiązania tego problemu już znamy (powyżej). A jaki drugi?

Należy ograniczyć pojemność skrzynek pocztowych do ok. 100Mb (tak 100Mb! w tym kosz i spam). W efekcie pracownicy zostaną zmuszeni  do selekcji tego co otrzymują i jest im potrzebne. 100MB to i tak dużo jak na bieżącą komunikację. Przy tak małej ilości miejsca każdy, nawet średnio rozsądny pracownik, zacznie kopiować na swoim (lub sieciowym dysku, kwestia architektury sieci w danej firmie) wszystko co ma jakąkolwiek wartość, a praktyka pokazuje, że stanowi to może 10% treści korespondencji. Uzgadnianie treści dokumentów często wymaga kilku, kilkunastu listów. Biorąc pod uwagę, że w zasadzie każdy używa opcji cytowania, rośnie tasiemiec powielanych cytowań w kolejnych listach. Czy ma sens przechowanie tego wszystkiego? Raczej nie.

Tak więc, skoro w firmie i tak robimy kopie zapasowe dysków sieciowych i zasobów pracowników a dyski są coraz tańsze po co tworzyć drugi i bardzo kosztowny serwer plików z systemu pocztowego? Po co używać serwera pocztowego do zarządzania dokumentami skoro i tak jest to tylko cześć ważnych rzeczy a pozostałe i tak są na dyskach sieciowych jako pliki i nie unikniemy systemu zabezpieczenia tych zasobów także? Skoro współdzielenie plików na dyskach sieciowych jest proste i w zasadzie bez kosztowe to po co dopłacać do serwera pocztowego za opcje portalowego dostępu do swoich i cudzych maili, za możliwość zarządzania prawami do cudzych maili by kolega, koleżanka lub szef mogli skompletować historię korespondencji z klientem? Dlaczego trzymać ważne pliki w serwerze pocztowym skoro odzyskiwanie ich stamtąd jest znacznie trudniejsze niż z katalogów na dyskach? Takich pytań można zadać jeszcze wiele. Czy życzenie pracownika (który ma prawo nie wiedzieć, że są inne metody lub ukryje je bo wymagały by zmian) jest wystarczającym powodem?

Tak więc Inna analiza wymagań, wykonana przez Innego analityka wyglądała by tak:

1. zidentyfikowano by i opisano problem biznesowy (organizacyjny, zarządczy itp.)
2. zbudowano by jakiś model organizacji pozwalający  na odtworzenie problemu i zrozumienie miejsca i przyczyn jego powstawania, zbadano by różne warianty
3. zidentyfikowano by i sprecyzowano przyczyny istnienia problemu,
4. opisano by możliwe warianty rozwiązania problemu w postaci dwóch lub więcej koncepcji rozwiązania
5. oceniono by potencjalne szkody obecnego stanu i oszacowano próg rentowności zakupu czegoś nowego

Na tym etapie dostajemy opis problemu, zidentyfikowaną jego przyczynę i wskazania z ryzykami, jak problem rozwiązać. Możliwe, że rozwiązanie organizacyjne by sprawę rozwiązało (drastyczne ograniczenie pojemności skrzynek zamiast ich powiększanie). Może innym rozwiązaniem byłby jakiś [[system zarządzania treścią]] (może [[system zarządzania dokumentami]])? Z takimi informacjami manager może poprosić kilku dostawców rozwiązań o oferty na produkt i/lub usługę rozwiązania problemu.

Nasz Inny analityk, jeżeli ma wiedzę i doświadczenie w roli projektanta, może przygotować jako kontynuacje takiego projektu od razu koncepcję rozwiązania. Ma to te duża zaletę, że unikamy ryzyka, że dostawca opracuje taką koncepcje pod siebie. Koncepcja rozwiązania to nie wskazanie produktu a określenie co powinien robić i jakie są tu ograniczenia. Nadal bez decydowania o szczegółach (piszemy co a nie jak ma zostać zrealizowane, jednak nie zapominamy o ograniczeniach które należy także w takich wymaganiach umieścić – zwane często wymaganiami pozafunckjonalnymi)  organizujemy konkurs ofert (przetarg) i świadomie wybieramy optymalne rozwiązanie.

Nasz lokalny inżynier, może na to po pierwsze nie mieć czasu, po drugie to nie są kompetencje inżynierskie! Jaka technologia zostanie wybrana? Przy poprawnie określonych wymaganiach i ograniczeniach: będzie kompatybilna z naszymi zasobami, będzie kosztowo optymalna,  będzie spełniała swoją rolę bo w końcu mamy także ograniczenia (tu nasz inżynier się niewątpliwie popisze i słusznie).

Jeżeli więc Wiele kluczowych informacji przedsiębiorstwa znajduje się wyłącznie w wiadomościach elektronicznych to ja życzę powodzenia tej firmie – sugeruje szybko to zmienić. Po drugie klient dobrego analityka to nie jego Pan a Pacjent. Mamy dwa scenariusze, manager ma wybór. Czy ja mam rację? Nie wiem. Moją rolą eksperta jest zbadać problem, opisać skutki i warianty rozwiązania. Decyduje manager (klient analityka).