Oprogramowanie spełniające oczekiwania i potrzeby Klienta jest wynikiem dobrze przeprowadzonej analizy oraz realizacją dokumentu opisującego wymagania biznesowe Klienta. Baza dla dokumentu, jaką są wymagania, które powinny być poprawnie zidentyfikowane oraz zinterpretowane, są wynikiem partnerskiej współpracy pracy między Analitykiem a Klientem. Na podstawie rozpoznania potrzeby Klienta, Analityk może zdefiniować wymagania, które będą zbiorem informacji CO należy zrobić, aby potrzeba Klienta została zrealizowana.
“Partnerstwo, dobrowolny związek dwu lub więcej osób, którego celem jest prowadzenie przedsięwzięcia oraz dzielenie jego zysków lub strat” The Encyclopedia Britannica, wyd. z 1990r.
W przypadku niepowodzenia wdrożenia projektu najczęściej winnym według Klienta staje się Analityk, ponieważ:
- najwyraźniej źle zrozumiał to co chciałem mu przekazać,
- nie zapytał o jakąś kwestię- a przecież miał taką możliwość,
- rozmawiał nie z tą osobą co powinien na spotkaniu.
Ta lista jest oczywiście o wiele dłuższa, ale już te kilka punktów pokazuje, że o partnerstwie w takim przypadku nie było mowy. Przecież do Dostawca jest odpowiedzialny za wszystko. Czyżby? Należy pamiętać, że obie strony (Dostawca i Klient) muszą być zaangażowani i być świadomi tego, czego potrzebują aby odnieść sukces.
Na początku projektu być może jest to oczywiste, lecz w trakcie jego trwania, tym bardziej kiedy narasta presja, o wspólnym celu łatwo zapomnieć. Klient i Dostawca nie zachowują się jak partnerzy, lecz jak strony w procesie wytwarzania oprogramowania próbujące nawzajem sobie udowodnić kto miał/ma rację. Brzmi znajomo?
W tym miejscu wyłania się kolejna kompetencja Analityka, który powinien być mediatorem, aby stwarzać atmosferę do dalszej współpracy szczególnie w sytuacjach kryzysowych.
Karta praw Klienta to 10 praw, z których mogą, a nawet powinni korzystać Klienci. Prawa te dotyczą współpracy między analitykami,programistami,wdrożeniowcami podczas wykonywania czynności związanych z wytwarzaniem oprogramowania, a dokładniej z fazą analizy i opracowania wymagań.
Jako Klient masz prawo do:
1. Otrzymania od Dostawcy system, który będzie spełniał Twoje oczekiwania i potrzeby
Jest to jedno z najważniejszych praw Klienta. Może być zrealizowane pod warunkiem, jeśli WSZYSTKIE wymagania biznesowe, jakościowe oraz funkcjonalne zostaną wyraźnie przekazane. W przeciwnym wypadku Analityk nie zadziała niczym wróżka i nie domyśli się czy czegoś nie brakuje, w szczególności jeśli dotyczy to wymagań, które zostały uznane przez Klienta za „oczywiste”.
2. Poznawania alternatywnych rozwiązań
Potwierdzenie wspólnego punktu widzenia w zespole składającym się z: analityka (po stronie Dostawcy) oraz interesariuszy po stronie Klienta pozwala na prawidłowe zrozumienie ich potrzeb a tym samym stwarza możliwość zaproponowania Klientowi wachlarzu rozwiązań. Należy mieć świadomość, że wdrożenie rozwiązania informatycznego czasem jest ostatecznością. Analityk po zapoznaniu się z oczekiwaniami Klienta, czy z narzekaniem na obecnie działający system może zaproponować wprowadzenie poprawek do procesu biznesowego, które mogą rozwiązać problem.
3. Poznania sposobów na dostosowanie wymagań w taki sposób, aby były rozwijalne
Tworzenie rozwiązania indywidualnie dostosowanego do Klienta w systemie ogólnie dostępnym może nieść ze sobą kilka uniedogodnień. Doświadczony analityk pracujący z kilkoma Klientami z łatwością skojarzy pewne podobieństwa w oczekiwaniach różnych Klientów. Dzięki temu będzie w stanie zaproponować taką modyfikację wymagania, która z jednej strony spełni wymagania Klienta, a z drugiej strony będzie uniwersalne dla pozostałych Klientów.
Modyfikacja pierwotnego wymagania czasem pozwala na skorzystanie z istniejącego rozwiązania i wymaga jedynie dostosowania go do potrzeb danego Klienta. Taka unifikacja ma jeszcze jedną zaletę – w przypadku aktualizacji funkcjonalności czy jej rozwoju jest ona niemalże od razu dostępna dla Klienta. W przypadku indywidualnego rozwiązania proces dostosowywania go do kolejnych wersji systemu jest praco – i czasochłonna.
4. Przekazywania cech systemu, które sprawią, że będzie on prosty w użyciu
Wymagania pozafunkcjonalne czasem są pomijane podczas artykułowania oczekiwań przez Klienta. Pojawiają się najczęściej na końcu procesu wytwarzania oprogramowania, kiedy Klient orientuje się, że proces trwa za długo, albo wymaga wielu kliknięć Użytkownika.
Podczas rozmów z Analitykiem niektórzy Użytkownicy „przemycają” cechy systemu, który powinien być: „przyjazny”, albo „idiotoodporny”. W takich sytuacjach Analityk powinien zadać dodatkowe pytania, które umożliwią mu zrozumienie ww. pojęć. Jeśli Analityk pominie tą część podczas spotkania, a mimo to jako Klient otrzymasz produkt spełniający Twoje oczekiwania jakościowe to masz wielkie szczęście. Proponuję, aby następnym razem nie liczyć na łut szczęścia, lecz na początku projektu jasno zdefiniować swoje oczekiwania jakościowe.
5. Oczekiwania, że analityk zarejestruje wszystkie Twoje wymagania w sposób jasny, czytelny i zrozumiały dla Ciebie
Po fazie spotkań z Analitykiem Klient otrzymuje dokument z opisanymi wymaganiami biznesowymi oraz ich propozycją realizacji. Najczęściej czytanie takiej dokumentacji przez Klienta wygląda jak na poniższym obrazku:
Wymagania powinny być pogrupowane, oznaczone i powiązane z interesariuszami odpowiedzialnymi za ich zdefiniowanie. Dodatkowo forma przekazywania opisu wymagań i realizacji powinna być dostosowana do projektu czy odbiorcy. Nie zawsze musi być to słowo pisane, w niektórych przypadkach wystarczy przygotowanie „opisu” w postaci interaktywnej makiety. Jeśli nie makieta to być może modele analityczne wystarczą. Jako Klient masz prawo żądać, aby dokument, który masz zatwierdzić był napisany językiem zrozumiałym dla Ciebie. Masz prawo do dodatkowych opisów pod elementami dla Ciebie niezrozumiałymi.
6. Oczekiwania, aby Analityk mówił Twoim językiem
Najczęstszym błędem popełnianym na spotkaniach z Analitykiem to przekazywanie przez Klienta swoich potrzeb za pomocą języka technicznego. Wynika to najczęściej z przekonania Klienta, że w ten sposób łatwiej będzie Analitykowi zrozumieć potrzeby Klienta. Nic bardziej mylnego.
Artykułowanie oczekiwań i potrzeb Klienta powinno odbywać się w języku naturalnym dla niego samego, czyli w języku biznesowym. Analityk na początku spotkań powinien zadbać o stworzenie wspólnego słownika pojęć, którymi będzie się posługiwał z Klientem. Dzięki temu unikniemy nieporozumień. Analityk jest łącznikiem między światem biznesu i światem IT, im szybciej pozna słownictwo oraz procesy biznesowe, tym lepiej będzie umiał je przekazać programistom.
7. Oczekiwania, że analityk zapozna się z twoimi zadaniami oraz celami biznesowymi
W przypadku wymiany systemu, czy migracji z jednego systemu do drugiego najlepszą praktyką jest zarezerwowanie czasu dla Analityka, aby mógł popracować na zastępowanym systemie ze wsparciem użytkownika końcowego. Jeśli to jest niemożliwe podczas spotkań warto poświęcić czas na to, aby omawiając dany proces jednocześnie pokazać go w systemie z zaznaczeniem czego brakuje, bądź co jest dla Użytkownika niewygodne.
W przypadku wdrażania nowego systemu dobrze, gdy spotkania analityczne zaczynają się od rozrysowania procesu biznesowego z zaznaczeniem ról interesariuszy. Dzięki temu podczas omawiania propozycji rozwiązania łatwiej jest użytkownikom zrozumieć, który etap w procesie ulegnie modyfikacji.
Analityk musi również poznać cel biznesowy projektu, aby cały czas weryfikować czy dana modyfikacja, czy nowe wymaganie przybliżą nas do jego osiągnięcia.
8. Otrzymywania wyjaśnienia dotyczące najlepszych praktyk związanych z pozyskiwaniem i opracowaniem wymagań
Podczas czytania dokumentacji stworzonej przez Analityka, która najczęściej zawiera elementy opisu biznesowego oraz techniczne aspekty rozwiązania, Klient nie jest w stanie zweryfikować wpisów bazodanowych, czy diagramów klas, które zostały użyte w dokumencie. Najczęściej prosi o ich usunięcie.
W takich sytuacjach zaleca się użycie w dokumencie punktu wyjaśniającego cel użycia danego diagramu. Najlepszym rozwiązaniem w takim przypadku jest wstawianie diagramów będących potwierdzeniem, zilustrowaniem wcześniej opisanej treści. W mojej ocenie najbardziej komfortowym dla Klienta jest zastosowanie rozwiązania, które praktykuję od kilku lat- wspólnie z Klientem omawiam wszystkie diagramy, tłumacząc ich zasady. Dzięki temu nie raz udało mi się je uzupełnić, czy poprawić, bo Klient uzupełnił wymagania o elementy, które później okazały się kluczowe.
9. Zmiany swoich wymagań
Prawo chyba najbardziej znienawidzone przez Dostawców. Stworzenie dokumentu opisującego wymagania, Ba! jego zatwierdzenie przez Klienta nie zagwarantuje Dostawcy, że wymagania w nim zawarte nie mogą ulec zmianie.
Wymagania mogą ewaluować w czasie, a nawet całkowicie się zmienić czy być usunięte. Wynika to z faktu, że wymagania odzwierciedlają potrzebę i oczekiwania Klienta, ale w danym momencie. Wraz z rozwojem biznesu, wymagania również muszą nadążać za jego zmianą, aby ich realizacja miała jakikolwiek sens i niosła wartość dodaną.
To, że Klient ma prawo do zmiany wymagań nie oznacza, że może je zmieniać bezkarnie. Od tego jest zarządzanie zmianą, czyli badanie jak zmiana określonego wymagania wpłynie na pozostałe wymagania, z którymi jest powiązane oraz jaki jest jego wpływ na cały projekt.
Ocena wpływu zmiany jest kompetencją analityka. To on w rozmowie z Klientem musi zapytać o wartość biznesową zmiany takiego wymagania, aby móc jednoznacznie stwierdzić jak zmiana czy pojawienie się nowego wymagania wpłynie na cały projekt. Być może to, co Klient nazywa zmianą, jest jedynie modyfikacją, bądź uproszczeniem już zidentyfikowanych wymagań.
10. Oczekiwać atmosfery wzajemnego poszanowania
Brak zrozumienia, presja czasu towarzysząca projektowi nie wpływa dobrze na atmosferę jaka tworzy się pomiędzy członkami zespołu projektowego. Spięcia na linii Dostawca- Klient to tylko kwestia czasu. Najczęściej spotykana sytuacja:
Klient: „Jak to nie można tego zrobić w projekcie? Przecież to jest dodanie tylko 2 dodatkowych pól? „
Dostawca: „Tak, ale to będzie wymagało modyfikacji w 4 miejscach systemu, nie mamy w projekcie już na to czasu, jeśli chcemy trzymać się zadeklarowanego budżetu i czasu”.
To co dla Klienta jest „proste” do zrobienia, nie jest takim dla Dostawcy. W takich sytuacjach jedynym rozwiązaniem jest wyjaśnienie Klientowi dlaczego dodanie tej „prostej” funkcjonalności może opóźnić nam projekt. Klient po takim wyjaśnieniu często zgadza się na wydłużenie harmonogramu i zmianę budżetu.
Poszanowanie czasu i pracy dotyczy całego zespołu projektowego. Brak poszanowania wynika najczęściej z faktu, iż obie strony traktują się nie jako partnerów a jedynie strony w projekcie. Podział: „my”, „oni” to prosty przepis na klęskę w projekcie. Jednej i drugiej stronie powinno zależeć na znalezieniu takiego rozwiązania, aby osiągnięcie celu, jakim jest stworzenie systemu było możliwe w okolicznościach, z jakimi przyszło się im mierzyć.