Lista życzeń

Projekty informatyczne, przynajmniej te prowadzone w naszym kraju, cierpią często na trudną przypadłość którą określam jako „lista życzeń”. Dotyczy to przede wszystkim projektów, które mają być realizowane przez zewnętrznych dostawców a przez to muszą mieć zdefiniowany w sposób formalny zakres. W założeniu – tego typu oficjalny opis powinien definiować przedmiot zamówienia w sposób ścisły i na tyle szczegółowy, że możliwe będzie oszacowanie pracochłonności i kosztów. To w teorii. Niestety w praktyce, często tego rodzaju dokumenty pt. Opis Przedmiotu Zamówienia nie są zbyt szczegółowe, a nawet więcej – ich forma i treść są problematyczne.

Brak struktury

Najczęstszą formą opisu jest krótki dokument tekstowych uzupełniony załącznikami z opisem wymagań. Opis wymagań ma przeważnie postać dokumentu xls zawierającego po prostu listę tego co system ma mieć/robić i jak się zachowywać. Na pierwszy rzut oka – nic złego tu nie widać, wymagania są opisane, każde ma ładnie nadany identyfikator. Czego się czepiać, porządek jest. Tu faktycznie można się zgodzić – wymagania są ponumerowane. I w zasadzie tyle z porządku. Brakuje:

  • priorytetów – niektóre wymagania są zapewne bardziej ważne inne mniej ważne
  • określenia poziomu – część z wymagań opisuje bardzo wysokopoziomowe funkcje (np. „system ma wspierać proces sprzedaży” mówi raczej o czymś bardzo złożonym ale też bardzo słabo zdefiniowanym, natomiast „system ma umożliwiać rejestrowanie adresu klienta” jest wymaganiem bardzo niskopoziomowym)
  • relacji między wymaganiami – część z wymagań jest powiązana wzajemnie, wpływając na siebie

Deklaratywne opisy

Osobiście uważam za jeden z poważniejszych problemów z dokumentacją, sposób opisywania w formie „system ma wspierać/umożliwiać/realizować”, czyli deklarowanie jakiejś cechy systemu a nie określanie co system ma robić. Na pierwszy rzut oka wygląda na to samo ale jednak druga forma, o ile jest dobrze opisana (o czym dalej) ułatwia przede wszystkim określenie granic wymagań (czy systemu) oraz umożliwia weryfikację realizacji wymagań. Wracając do mojego ulubionego przykładu: „system ma wspierać proces sprzedaży” znacznie czytelniejsze jest w postaci „system rejestruje nowe zapytania ofertowe, umożliwia ich weryfikację i przesłanie do systemu dziedzinowego do dalszego przetwarzania”.

Poziom szczegółowości

Proste rzeczy są opisane szczegółowo, skomplikowane są opisane pobieżnie. W efekcie mamy dokładnie opisane detale które na etapie wyceny lub wstępnej analizy nie są do niczego potrzebne, wręcz przeszkadzają. Brakuje za to informacji które pozwolą lepiej oszacować system, określić jego granice.

Silosy informacyjne

Jeżeli ktoś nie wie: silos informacyjny to taki byt który przypomina taki zwykły silos, czyli wielka beczka z metalu lub betonu w którym trzyma się bezpiecznie sypkie materiały (ziarno, cement itd). Tyle że silos informacyjny zamiast ziarna przechowuje informacje. Cała reszta jest taka sama – informacje są tak bezpieczne że dostęp do nich jest ograniczony i raczej sekwencyjny (wypływa tylko małą dziurką). Do tego nie wiadomo tak do końca co też siedzi w tymże silosie, ile tego jest i jeszcze zawór może się zaciąć albo mieć „inne zdanie”.

Określenie „silosy informacyjne” idealnie pasuje do opisu najczęstszego sposobu powstawania OPZ. Dokumenty tworzone są przez różne grupy osób zainteresowanych systemem. Lub niezainteresowanych ale zmuszonych do zajęcia się nim, a nawet zainteresowanych ale NIE wdrożeniem systemu. Do tego jeszcze najczęściej jest to robota dodatkowa, wrzucona tym ludziom poza ich normalnymi obowiązkami. Więc zrozumiałe jest, że zaczyna brakować przynajmniej jednego z niezbędnych czynników: chęci, zasobów lub czasu. Mamy więc grupy typu „zespół obsługi klienta”, „zespół marketingu”, „zespół utrzymania klienta” które tworzą w pośpiechu kawałek swoich wymagań i przepychają sprawę dalej. Czyli ze swoich silosów wiedzy sypną trochę tego trochę tamtego do wymagań, nie skupią się zbytnio na wymaganiach innych (przecież to nie nasze).
Na koniec mamy więc dokument połatany z wielu różnych elementów, często nieprzystających do siebie fragmentów, opisanych w różny sposób na różnym poziomie (patrz „brak szczegółów”). Najgorszy jest jednak brak komunikacji między osobami piszącymi dokument – mamy więc z jednej strony nierealizowalne założenia (że „zespoł xyz” będzie dostarczał/wprowadzał czy przetwarzał jakieś dane) a z drugiej strony mamy nakładające się obszary wymagań. Wręcz anegdotycznym przykładem jest jeden z dokumentów OPZ, z którym miałem do czynienia, który to definiował w trzech miejscach sposób obsługi potencjalnych klientów. Na 3 różne sposoby.

Brak wizji

– „dobra – to zróbmy sobie nowy system”

– „ok, ale po co? co my z tego będziemy mieli?”

Niestety, takie dialogi (szczególnie druga kwestia) rzadko się zdarzają. Mamy więc szczegółowy dokument opisujący detale wymagań typu pola na ekranie, ale nie zostaje zdefiniowany cel który ma być zrealizowany. I nie mam tu na myśli celów pt „będzie lepiej szybciej i fajniej” tylko o konkrety: „nie mamy tego i tego a potrzebujemy bo chcemy taką czynność wykonywać szybciej o 50%” lub „potrzebujemy dostosować naszą ofertę dla klientów na podstawie cech klientów, musimy więc zwiększyć jakość danych oraz ilość gromadzonych informacji”.

Dlaczego jednak taka informacja jest w tym miejscu potrzebna? Co właściwie obchodzi dostawcę po co jak chce mieć coś tam? Przecież stolarzowi nie tłumaczę dlaczego chcę mieć takie a nie inne szafy. I to jest właśnie błąd. Dostawcy łatwiej jest zrozumieć jak system ma zostać zbudowany i co ma robić jeżeli wie po co ma być wykorzystany. Dzięki temu niejasne obszary, niedokładnie określone, mogą być jaśniejsze bo zostanie określony kontekst.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *