Zaczynamy od „CO”

Wymagania biznesowe specyfikują czego potrzebuje Biznes. I pierwsza wątpliwość, czy to naprawdę jest ważne?

Ale przez chwilę prześledźmy ten proces. Projekt rozpoczyna się od tzw. analizy biznesowej i wówczas to pozyskujemy osoby z Biznesu i one nam tworzą listę życzeń zwanych wymaganiami funkcjonalnymi, czasem potrzebami biznesowymi.  Czyli każdy „lider obszaru” albo co gorzej, szeregowi pracownicy specyfikują co robą i/lub czego by chcieli. Co ważne o niczym nie można zapomnieć a im większa szczegółowość tym bardziej wartościowa będzie analiza, bo będzie tego duuuużo. Będą wielkie excele, albo dużo zagadnień w repozytorium analitycznym np. w Enterprise Architect.

Jednym słowem biznes mówi CO chce.  I w tym momencie nasz projekt właśnie się rozpędza aby przywalić z dużym impetem w betonową ścianę. Tą ścianą jest rzeczywistość.

Teraz może pojawić się zdziwienie, że co? Przecież każdy zbiera wymagania, jak można bez tego? I owszem tak się robi ale nie tam, gdzie trzeba zrobić coś co wniesie nową jakość. Np. kilka poniższych zdjęć pokazuje efekty projektów w których nie było wymagań biznesowych. Tych imponujących budowli nie stworzono na podstawie listy życzeń ówczesnych mnichów, szewców, piekarzy, żebraków, itp..

To jest efekt pracy projektantów, architektów i wizjonerów.

• 

• 

• 

• 

Natomiast to poniżej już mogło powstać w oparciu o wymagania przyszłych użytkowników.

• 

• 

• 

• 

I teraz stereotypowo PM nie posiadający odpowiedzialnego analityka weźmie tę listę życzeń przekaże następnie do Wykonawcy i powie, to trzeba zrobić. Często też wcześniej poprosi Wykonawcę o wycenę, który zinterpretuje, to po swojemu.

Może nie „CO” tylko „PO CO?”

Nie potrafię zrozumieć po co się te wymagania zbiera. Zbieranie wymagań biznesowych w organizacji, to tak jakby robić reverse engineering kodu programu, który chcemy zastąpić. Jaki to ma sens? Jeżeli organizacja działa dobrze, to nie trzeba nic zmieniać, jak działa źle to odtwarzaniem złego działania, nic na lepsze nie zmieni.

Szaleństwem jest robić wciąż to samo i oczekiwać różnych rezultatów

powiedział kiedyś Albert Einstein

Więc pierwsza konkluzja, jeżeli w projekcie zbiera się wymagania biznesowe, to znaczy, że nikt nie wie co chce zrealizować i po co. Jak nie wie co chce osiągnąć, nie ma wizji, nie ma określonych celów, mierników, to czy najlepszym rozwiązaniem jest go zamknąć zanim wystartuje i zeżre jakieś koszty?

Owszem ktoś mógłby powiedzieć, że „u nas”, to jest zupełnie inaczej, dla wymagań określa się priorytety, tworzy przypadki użycia itp. itp. Wszystko fajnie ale to jest nadal malowanie trawy na zielony, albo gorzej, zamalowywanie kupy na kolor podłogi. A tu trzeba postępować jak z tą kupą, posprzątać a najlepiej nie robić na podłodze tylko w stosownym miejscu. Tak też jest z wymaganiami.

To zbierać wymagania czy nie?

NIE! One wprost nie szkodzą, ale szkodzą pośrednio. Bo korcą aby wykorzystać. Albo organizacja wie jakiego produktu potrzebuje, zna swoje procesy biznesowe i wie co chce osiągnąć albo nie. Jak nie zna, to lepiej poszukać produktu w z półki i wdrożyć cokolwiek, przynajmniej będzie to jakieś. Bo produkt z półki, będzie przynajmniej zawierał jakąś wiedzę zebraną z wcześniejszych wdrożeń przetworzoną przez dostawcę który istnieje na rynku i posiada renomę (o ile posiada).

A co w zamian?

W zamian są procesy biznesowe organizacji i analityk. Z Biznesem trzeba oczywiście rozmawiać, ale Biznes nie może tworzyć założeń projektowych a tym są wymagania. Jak powstaną, to będą musiały być zweryfikowane, czyli zrealizowane, czyli będzie musiała powstać kupa. Więcej szczegółów na ten temat wkrótce, zapraszam.