Wczoraj odbyła się w Warszawie konferencja Inżynieria Wymagań, na której miałem przyjemność wygłosić referat o klasyfikacji wymagań. Celem mojej prezentacji było zwrócenie uwagi na to, że zarządzanie wymaganiami to nie tylko ich „zbieranie i klasyfikowanie” oraz, że wymagań jest więcej niż tylko „funkcjonalne i poza-funkcjonalne”.
Powszechny w literaturze przedmiotu termin „pozyskiwanie wymagań” jest bardzo różnie rozumiany. Można wymagania „pozyskiwać” podczas sesji warsztatowych JAD, burz mózgów, z pomocą ankiet, pisania „user story” itp. Wszystkie te metody mają jedną poważną wadę: produkują ogromną ilość deklaratywnych, nieweryfikowalnych treści. Lista wymagań w postaci tabeli z setkami wierszy nikogo tu nie zaskakuje. To nie działa!
Inżynieria wymagań
Coraz częściej zaczyna pojawiać się pojawiać nie tylko w prasie, pojęcie „inżynieria wymagań”. Dla zasady popatrzmy na znaczenia słów (sł. j. polskiego):
inżynieria ?projektowanie i konstruowanie obiektów oraz urządzeń technicznych?
wymaganie ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?
wymagany ?niezbędnie potrzebny?
Tak więc inżynieria wymagań to „projektowanie niezbędnych warunków, którym coś [rozwiązanie] musi odpowiadać”. Moim zdaniem istotne jest jest użycie słowa „projektowanie” a nie „zbieranie”. Zbieranie to praca stenografa. Projektowanie to już zupełnie inna praca. Raz, że twórcza, dwa że rządząca się pewnymi prawami: przede wszystkim specyfikacja wymagań to pewna określona konstrukcja. Jaka? Zgodnie z zasadami: spójna, niesprzeczna, weryfikowalna i kompletna. Czy takie cechy ma np. stenogram z kilkudniowych warsztatów JAD czy burzy mózgów albo dane zebrane z ankiet wśród przyszłych użytkowników danego rozwiązania? Szczerze wątpię.
Pojawia się kolejne pytanie: co z wynikami analizy wymagań po zakończeniu projektu wdrożeniowego? Niemalże w 100% przypadków są odkładane na półkę, a kolejne wdrożenie lub rozbudowa posiadanych narzędzi, to kolejna, prowadzona od zera analiza wymagań. Jak słusznie zauważył jeden z prelegentów, wyłączając start-up’y, projekty wdrożeniowe (wybór, zakup, implementacja) to tak na prawdę zarządzanie zmianą a nie „nowe projekty”.
Wyobraźmy sobie, że zamiast odkładać dokumentację wymagań do lamusa, utrzymujemy jej aktualność i wyciągamy ją za każdym razem, gdy rozpoczynamy kolejny nowy projekt, wymagający zmiany jakiejś funkcjonalności lub pozyskania całkiem nowej. Wtedy, zamiast prowadzić kolejną kosztowną i długą analizę wymagań, analizujemy planowane zmiany i nanosimy je na posiadaną już i konserwowaną dokumentację. Próby korzystania z analiz poprzednich ad-hoc najczęściej kończą się fiaskiem, gdyż z reguły każdą robi inny dostawca rozwiązania, więc każda jest inna i najczęściej niespójna z innymi.
Spójrzmy teraz na poniższy diagram:
Na diagramie mamy dwie linie (linia przerywana to koszty bieżące, ciągła to koszty narastająco): czerwona to koszty tradycyjnego modelu prowadzenia niezależnych analiz, „od zera” dla każdego projektu. Niebieska pokazuje koszty modelu, w którym zarządzamy zmianą. Realia pokazują, że oszczędności są jeszcze większe, gdyż w modelu analiz ad-hoc, pomniejsze projekty realizowane są „zwinnie” bez żadnej dokumentacji, gdyż albo nie ma na jej opracowanie czasu (bardzo często) albo wielkość (mały) projektu skłania do podejmowania ryzyka pracy bez dokumentacji. Niestety praca bez dokumentacji często prowadzi do odkrywania wymagań dość kosztowną metodą prób i błędów (prototypowanie). Jak wiemy, prawie 80% projektów to projekty wadliwe, w 100% przypadków źródłem jest (między innymi) zła specyfikacja wymagań.
Jak widać, z zupełnie z innej strony „odkryliśmy” coś co nazywamy architekturą korporacyjną. Skoro każda analiza wymagań w istniejącej organizacji, to każdorazowa analiza od poziomu motywacji biznesowej projektu, przez wymagane usługi aplikacyjne, integracje aż do platform sprzętowo-systemowych, to mamy nic innego, jak projekt dokumentowania architektury korporacyjnej. I na koniec bardzo ważna moja uwaga: za jakość wymagań odpowiada i ponosi konsekwencje w 100% kupujący, nigdy dostawca!
Ma sens? Ma!
Na koniec polecam bardzo ciekawy artykuł Bogdana Berezy o inżynierii oprogramowania w dzisiejszym (19 Marca 2014) numerze [[COMPUTERWORLD]].
Co Cię skłoniło do uczestnictwa:(
Wiesz co ma sens? Sens ma zatrudnienie się tam, gdzie są pieniądze. Ja widziałem na własne oczy dokumentację utrzymaną w postaci zawsze aktualizowanego modelu przed implementacją – w Twoich 'ulubionych’ wordach. Pełna, aktualizowana z roku na rok, przez zespół analityków dokumentacja systemu bankowego. Albo inny projekt dla zupełnie innej branży, w pełni utrzymana dokumentacja w EA (kolejny Twój konik;) jednego z największych projektów na rynku. Te dywagacje o analizie wymagań to są dywagacje na poziomie chłopaków w liceum, którym ojciec dał budżet na komputer 3500, a oni cały czas mażą o tym jakby to było mieć sprzęcior
Co do tabeli wymagań to wyobraź sobie, że to ma ma zastosowanie. Wtedy gdy robisz wymagania do przetargu, w ten sposób powstaje checklista dwustu wymagań, którą z całą pewnością się prześledzi przy odbiorze. Na tej konferencji powinna więc paść jedna bardzo istotna uwaga – pracować należy z ludźmi przy kasie i wtedy można mówić o rosnącym z roku na rok doświadczeniu.
Znalazłbym też i inną istotną poradę – certyfikaty należy mieć te które są wymagane w przetargach, a nie wszelakie. Zwiększa to szanse na pracę w projektach w których jest kasa, czyli w tych których jest szansa by były procesy lepiej poukładane.
O co chodzi z tym że za jakość wymagań ponosi odpowiedzialność zawsze kupujący? Jeśli utrzymujesz corowy system w banku, to co oznacza taki tekst o odpowiedzialności bo nie rozumiem? Odpowiedzialność przy krytycznych systemach jest zupełnie inaczej rozłożona. Chyba mówiliście o jakichś projektach realizowanych na sztukę, gdzie utrzymanie pełnej dokumentacji stale aktualnej jest nierealizowanym światem doskonałym, a nie rzeczywistością codziennej pracy? Przecież to nie jest niespotykana sprawa prawidłowe utrzymanie aktualnej dokumentacji dużego systemu, tylko to kosztuje. Cały czas trwają rekrutacje do takich projektów, jak ktoś ma zacięcie archeologa pincetą przesypującego pustynię może sił próbować.
Myślę, że i takie opinie warto tu publikować, mimo, że anonimowe. I mała korekta: nie używam ani worda ani Enterprise Architecta do analizy bo to bardzo słabe narzędzia do tego celu. Przetargi, patrząc na ich efekty, są bardzo dobrym anty-przykładem… pokazują jak się kończy praca w projekcie gdzie wymagania są deklaratywną listą kilkuset „wymagań”: projekt jest odbierany przez prawników a produkt do niczego się nie nadaje (a dostawca „zarobił pieniądze”, takie specyfikacje to bardzo dobre narzędzie do „robienia pieniędzy” na przetargach). Odpowiem na pytanie „O co chodzi z tym, że za jakość wymagań ponosi odpowiedzialność zawsze kupujący?”: właśnie przetargi (większość) są przykładem tego „jakie wymagania taki dostarczony produkt”, metoda jak wyżej. Uwag o pieniądzach i certyfikatach nie skomentuję.
Prawdę mówiąc, jednym z często spotykanych powodów, dla których moi klienci mnie zatrudniają to ochrona przed takimi ludźmi (firmami ich zatrudniającymi) jak autor tekstu powyżej…