W poprzednim wpisie pisałam o prawach Klienta, o których Dostawca nie zawsze wspomina podczas projektu.
Dzisiaj prezentuję drugą stronę medalu – obowiązki Klienta, których nie zawsze jest świadomy, a Dostawca najczęściej ich wymaga w trakcie trwania projektu. Znajomość obowiązków oraz ich przestrzeganie nie tylko usprawnia pracę w projekcie obu stronom, ale przede wszystkim jest odpowiedzią na odwieczne pytania po zakończeniu projektu: „Co poszło nie tak”. Zastanawiasz się jak uniknąć takich sytuacji? Zapraszam do dalszego czytania.
Karta obowiązków Klienta to zbiór 10 elementów, które są czynnikiem sukcesu w projekcie.Kliencie:
1. Znajdź czas na przekazanie oraz wyjaśnienie swoich oczekiwań i potrzeb
W projekcie po stronie Klienta najczęściej biorą udział osoby, które posiadają największą wiedzę w danej dziedzinie. Wiąże się to również z faktem, iż takie osoby należą do najbardziej zajętych osób w firmie. Klient nie może wychodzić z założenia, że jego rola kończy się na etapie przekazania Dostawcy swoich oczekiwań, a resztą zajmie się Analityk. Podjęcie decyzji o rozpoczęciu prac nad projektem wiąże się z tym, że na etapie analizy zgłoszonych oczekiwań Klienta jego udział oraz wsparcie Analityka powinno mieć najwyższy priorytet. Obowiązkiem Klienta jest nie tylko dostarczać na czas informacji, które będą uzupełnieniem materiału przekazanego Dostawcy, lecz stworzenie takich warunków pracy (wspólne spotkania/warsztaty analityczne), aby Analityk miał szansę w pełni zrozumieć to, co Klient chciał przekazać.
Wysiłek włożony w fazę analizy, nawet, jeśli miałyby być to 5 godzinne sesje przez 3 dni, w efekcie zajmie mniej czasu niż rozłożenie tego samego wysiłku na kilkanaście dni po 1 godzinie pracy z Klientem.
2. Staraj się być szczegółowy i konkretny w przedstawianiu informacji
Mało szczegółowe wymagania są kuszące i dla Dostawcy i dla Klienta, ponieważ pozostawiają tak duży margines niedopowiedzenia, że zawsze będzie można powiedzieć, że dane wymaganie zostało spełnione, bądź nie. Zarówno Dostawcy jak i Klientowi powinno zależeć, aby wymaganie zostało zdefiniowane precyzyjnie, konkretnie bez niedomówień. Aby Analityk mógł zdefiniować tak wymaganie potrzebuje dodatkowych informacji od samego Klienta.
Pamiętaj – im bardziej szczegółowe wymaganie tym większa pewność, że produkt spełni Twoje oczekiwania.
3. Informuj analityka o wszystkich zmianach, które wpływają na projekt
Oprogramowanie tworzone na podstawie regulacji prawnych to jeden z najtrudniejszych obszarów dla Analityka. Tym trudniejszy, im bardziej skomplikowane przepisy. Zatem, jeśli możesz wspomóc Analityka interpretacją prawną uzyskaną ze swojego działu prawnego – nie wahaj się, na pewno ułatwi to Wam pracę oraz zrozumienie zapisów. Jeśli nie posiadasz działu prawnego wystarczy, że pomożesz zrozumieć Analitykowi przepisy.
Pamiętaj, że Analityk nie jest on ekspertem w Twojej dziedzinie, zatem każde rozporządzenie, decyzja, która ma wpływ na dany projekt, nawet, jeśli nie masz pewności, że zostanie wdrożona musi być przekazana Analitykowi, aby miał świadomość o nadchodzących zmianach. Dotyczy to również reorganizacji Twojej pracy.
4. Nie bój się podejmować decyzji w projekcie
W projekcie zawsze zdarza się moment, w którym trzeba podjąć decyzję. Najczęściej dotyczy ona sprzecznych wymagań uczestników procesu, czy też zmiany procesu, która musi nastąpić wraz z wdrożeniem nowego oprogramowania. Nie bój się jej podjąć, pamiętaj, że system jest tworzony dla Ciebie i ma Tobie służyć. Im dłużej zwlekasz z podjęciem decyzji, bądź jej unikasz, tym później zespół programistów będzie mógł rozpocząć pracę nad jego tworzeniem. Jeśli nie wiesz jaka decyzja jest właściwa poproś o pomoc Analityka – ma wystarczające umiejętności, aby przedstawić Tobie argumenty za i przeciw konkretnym rozwiązaniom.
5. Określaj priorytety zdefiniowanych wymagań
Jeśli wszystko jest ważne, to znaczy, że nic nie musi być implementowane. Tymi słowami powinieneś się kierować drogi Kliencie. Priorytety wymagań są niezmiernie ważne w ocenianiu, które z nich muszą być wykonane w pierwszej kolejności, a które mogą chwilę poczekać. Aby móc określić priorytety danego wymagania powiedz Analitykowi czy z punktu widzenia prowadzenia biznesu pominięcie takiego wymagania spowoduje, że nie będzie mógł być prowadzony?
Nie wszystkie wymagania są tak samo ważne i tak samo pilne. Pilne wymaganie to takie, którego czas realizacji ma znaczący wpływ na prowadzenie biznesu, np. w ostatnim tygodniu listopada pilnym wymaganiem będzie uruchomienie promocji na stronie ze względu na akcję: „Black Friday”, ale już to samo wymaganie będzie tylko ważne, jeśli mówimy o nim na początku roku.
6. Przekazuj analitykowi kryteria akceptacji wymagań
Skąd Analityk ma wiedzieć, że wymaganie zostało spełnione? Nie wie, póki do każdego wymagania nie zostaną zdefiniowane kryteria jego akceptacji. Mogą nim być warunki po spełnieniu, których Klient może odebrać wymaganie. Takim przykładem może być wymaganie dla uruchomienia portalu, gdzie kryteriami akceptacji będzie możliwość utworzenia konta przez Użytkownika. Patrząc na wymagania poprzez kryteria akceptacji może się okazać, że wymaganie jest duże i wymaga rozdzielenia na mniejsze wymagania.
7. Oceniaj prototypy, przeglądaj wymagania z zespołem
Czy jako Klient nie masz poczucia torturowania przechodząc przez dokumentację tworzoną przez Analityka niemalże nic nie rozumiejąc licząc na to, że to, co czytasz jest tym, co przekazywałeś? Jeśli tak, to mam dla Ciebie rozwiązanie. Organizuj razem z Analitykiem przegląd tego co zapisał, dopytuj go tak długo dopóki nie uzyskasz pewności, że to co zostało zanotowane odzwierciedla Twoje potrzeby przekazane na początku projektu.
8. Nie pospieszaj analityka w fazie opracowywania wymagań
Faza opracowywania wymagań jest jedną z najważniejszych i krytycznych faz w projekcie. Od poprawnego opracowania dokumentacji zależy cała reszta. Jeśli Analityk mimo sesji spotkań z Tobą nadal potrzebuje dodatkowych wyjaśnień – nie irytuj się, staraj się zrozumieć i wyjaśnić. W trakcie opracowywania rozwiązań pojawiają się dodatkowe pytania, które nie mogły być zadane we wcześniejszej fazie, ponieważ w trakcie analizy wymagań uczestniczycie jedynie w analizie biznesowej, która nie wkracza w obszar rozwiązań, baz danych, projektowania widoków itp. Staraj się również i nie pospieszać Analityka w opracowywaniu wymagań, pośpiech nie jest tutaj rozwiązaniem. Pamiętaj, że błąd na tym etapie będzie kosztował Cię ostatecznie więcej ze względu na poprawki jakie będą musieli wykonać programiści.
9. Nie podważaj czasu, jaki został oszacowany na zgłoszone wymagania – zaufaj
„ Przecież to jest taka mała rzecz, czy naprawdę musi tyle kosztować? Czy nie da się tego zrobić w krótszym czasie?” – brzmi znajomo? Drogi Kliencie, pamiętaj, że to co widzisz to zaledwie szczyt góry lodowej, pod niewinną funkcjonalnością może kryć się wiele zależności, może wymagać danych, które obecnie nie znajdują się w systemie, bądź wymagać wydajności nieosiągalnej na chwilę obecną. Pamiętaj, że to jest jedynie „szacowanie” prac, zatem dokładaj wszelkich starań, aby wymagania, które są tworzone były precyzyjne, dzięki czemu margines niepewności, który zawsze jest zakładany przy takich szacunkach będzie mniejszy. Zamiast mówić Analitykowi: „Generowanie hasła musi być natychmiastowe” powiedz: „Hasło musi być wygenerowane w przeciągu 2 sekund od utworzenia konta użytkownika”.
10. Angażuj się w tworzenie oprogramowania
Cały problem z oprogramowaniem tkwi w tym, że jest on tworzony nie dla idei samego tworzenia, lecz po to aby był używany przez Użytkowników. Bez wystarczającego zaangażowania Klienta w proces tworzenia oprogramowania nie ma możliwości uniknięcia tego rozczarowania produktem finalnym. Powstanie luki oczekiwań, czyli różnicy między tym czego oczekiwał Klient na początku projektu a tym co stworzyli programiści na podstawie opisu jest niemiłą niespodzianką dla obu stron. Najlepszym rozwiązaniem jest ciągłe upewnianie się, nawet na etapie tworzenia oprogramowania, czy dane rozwiązanie jest tym czego oczekuje Klient. Angażowanie Klienta w tej fazie projektu może mieć różny wymiar- od testowania interfejsu po ocenianie prototypów rozwiązania. Jeszcze lepsze rezultaty daje zaangażowanie Klienta w początkowej fazie projektu, kiedy świadomie podejmuje decyzje i staje się niemalże analitykiem po stronie biznesu, bierze odpowiedzialność za swoje decyzje oraz angażuje cały zespół projektowy po stronie biznesu w tworzenie oprogramowania. Przypomina im o zależnościach między wymaganiami, czy koordynuje pracami związanymi z dostarczeniem odpowiednich materiałów dla Analityka.
Pamiętaj, że zrozumienie tych zasad i ich przestrzeganie stanowi klucz do sukcesu projektu.
