Minął 2016 rok, a Ty właśnie zdałeś sobie sprawę, że nie udało Ci się zrealizować wszystkich planów, jakie założyłeś na jego początku? Dziś Twoja lista ponownie się zapełnia celami na 2017 rok. Ten rok będzie przecież lepszy, cele bardziej realne. Z pewnością Ci się uda…..jeśli tylko podejdziesz do nich jak do celów biznesowych w projekcie IT. Spójrz na swoje cele jak na cele biznesowe w projekcie IT.
W pierwszej kolejności musimy odpowiedzieć na pytanie czym jest cel biznesowy w projekcie IT?
Cel biznesowy – finansowa albo niefinansowa korzyść biznesowa, jaką spodziewa się odnieść organizacja w wyniku zrealizowania projektu lub innej inicjatywy (K.Wiegers, J.Betty)
Na etapie zbierania wymagań interesariusz nie będzie mówił o swoich celach biznesowych, lecz o funkcjonalnościach jakie są jego zdaniem niezbędne. Zadaniem każdego analityka, inżyniera wymagań jest poszukiwanie celu, jaki kryje się pod opisem danej funkcji, czy funkcjonalności. W jaki sposób to zrobić? Sprawdzając czy cel biznesowy jest: S.M.A.R.T.
1. S – (ang.Simple) – PROSTY
Cel musi być sformułowany w sposób jednoznaczny, prosty oraz zrozumiały. Dobrze sformułowany cel nie pozostawia miejsca na interpretację, domyślanie się. Proste sformułowanie celu pozwala dostawcy opracować różne rozwiązania, dzięki którym cel może być on osiągnięty. Pamiętaj, że cel nie musi być wyrażony w jednym zdaniu.
2. M – (ang.Measurable) – MIERZALNY
Definiując cel biznesowy nie możemy pomijać elementu, jakim jest jego mierzenie. To miara odpowiada nam na pytania: „ Co to oznacza, że funkcja została dobrze wykonana?” „Kiedy wiemy, że funkcjonalność jest gotowa do oddania Klientowi?” Aby zdefiniować miarę założonego celu biznesowego wystarczy poprosić klienta o opowiedzenie, w jaki sposób będzie testował daną funkcję, czy funkcjonalność. Pamiętaj, że tester sprawdza jedynie, czy produkt jest zgodny z opisem przygotowanym przez analityka biznesowego, inżyniera wymagań. Klient natomiast wykonuje testy sprawdzając poprawność funkcji wykorzystując je w normalnej pracy operacyjnej. Stąd wynikają duże nieporozumienia przy odbiorze funkcjonalności przez Klienta. Jeśli przy definiowaniu funkcjonalności nie wiemy, jaki jest jej cel powstania, i dodatkowo nie dopytamy o sposób testowania funkcjonalności przez Klienta możemy mieć duże problemy przy odbiorze produktu przez Klienta. Zawsze znajdzie się argument przemawiający za tym, że wg. Klienta funkcjonalność nie jest gotowa, bo nieuwzględniona została jeszcze jedna opcja.
Jeśli cel biznesowy projektu zakłada poprawienie wydajności, bądź generowania (czegoś) nie zapominaj o mierze jakim jest czas, ilość.
Nie pisz: „Umożliwienie generowania faktur po dokonaniu zakupu’, wiem, że to ładnie brzmi i nie trzeba zbytnio się pochylać nad tym do czego będzie wykorzystywany system – przecież jest wpisane w umowie.
Zastanów się w jaki sposób będzie sprawdzał to tester i Klient? Czy wygenerowanie 1 faktury jest wystarczającym potwierdzeniem poprawności działania? Czy generowanie 1000 faktur w ciągu 10 minut jest wystarczające dla Klienta, aby móc powiedzieć, że funkcjonalność działa zgodnie z oczekiwaniami?
3. A – (ang. Achievable) – OSIĄGALNY
Realizm – to słowo, które powinno nam towarzyszyć przy definiowaniu celu biznesowego. Nie możemy zakładać celu biznesowego, który nie jest możliwy do osiągnięcia w założonym czasie i środkach, wiedzy oraz umiejętnościach. Co to oznacza w praktyce? Wspólnie z klientem należy się zastanowić czy przy użyciu wszystkich możliwości jesteśmy w stanie dostarczyć funkcjonalność realizującą dany cel.
Spójrzmy na przykład:
System umożliwiał generowanie 100 faktur w ciągu 5 minut. Celem projektu jest zwiększenie wydajności systemu, który generowałby 100 faktur, ale w ciągu 3,5 minuty.
W pierwszej kolejności sprawdzamy ograniczenia, czyli sprawdzamy, przy jakich warunkach system jest w stanie osiągnąć taki czas generowania faktur. To co z punktu widzenia klienta jest organiczeniem, dla dostawcy jest doprecyzowaniem warunków, przy których zapewnia on poprawność działania funkcjonalności.
4. R – (ang.Relevant) – ISTOTNY
Cel biznesowy musi być „krokiem naprzód” dla organizacji, musi nieść korzyść biznesową. W jaki sposób to sprawdzić? Zapytaj klienta:
„ W jaki sposób obecnie radzi sobie z problemem?”
„Ile zaoszczędzi czasu/pieniędzy, jeśli funkcjonalność nie zostanie wdrożona?”
Jeśli klient nadal twierdzi, że cel jest polepszeniem jego pracy, po wycenie realizacji funkcjonalności, która ma pozwolić mu osiągnąć ten cel ponownie zapytaj: „Ile zaoszczędzi czasu/pieniędzy, jeśli funkcjonalność nie zostanie wdrożona?”.
Zestawienie kosztów z korzyścią, jaką niesie dana funkcjonalność jest ostatecznym sprawdzianem istotności danego celu. Jeśli koszty wdrożenia są większe niż korzyść, jaką można dzięki niemu odnieść, zazwyczaj cel nie był istotny.
5. T – (ang. Timely defined) – OKREŚLONY W CZASIE
Definiując cel biznesowy musimy zdefiniować jego horyzont czasowy, w jakim zamierza się go osiągnąć. Może to być konkretna data, bądź czas, np. 2 miesiące. W przypadku tego drugiego konieczne jest podanie od kiedy rozpoczynamy mierzenie czasu.
Przykłady poprawnie zdefiniowanych celów biznesowych:
„Klient osiągnie 75% udziału w rynku IT w ciągu 6 miesięcy od 1 stycznia 2017 roku”
„ Zostanie zwiększona wydajność obsługi transakcji o 15% w porównaniu ze stanem obecnym, tj. 100 transakcji na minutę”.
