Szybki przewodnik po optymalizacji zakresu projektu
Na co dzień mamy do czynienia z wieloma wątpliwościami naszych klientów, a wśród nich często pojawia się pytanie: „Co ma kluczowy wpływ na koszty projektu?” Najbardziej oczywistą odpowiedzią jest zakres projektu. Od tego jak wiele funkcjonalności klient chce otrzymać i jak bardzo są one skomplikowane zależy w znaczącej mierze ile trzeba będzie zainwestować w projekt. Z drugiej strony projekt który nic nie wdraża nie jest nikomu potrzebny. Jak więc zoptymalizować zakres projektu IT?
Skup się na celu biznesowym
Aby projekt był efektywny, w centrum naszych rozważań musi znaleźć się cel biznesowy. Wszelkie nasze rozmowy z klientami zaczynamy od próby zrozumienia jaki cel chce on osiągnąć oraz na czym polega jego działalność, a także co jest najważniejsze by móc osiągnąć ten cel. Tylko rozumiejąc te kwestie, możemy wesprzeć klienta w optymalizacji zakresu, czyli określeniu które funkcjonalności są kluczowe i niezbędne, a które możemy wyciąć, ograniczyć lub dostarczyć później, bez szkody dla sukcesu przedsięwzięcia. Często na początku spotykamy się z oporem, bo oczywiście każdy chce zrealizować 100% tego co sobie wcześniej zaplanował. Warto jednak pamiętać o zasadzie Pareto (80/20), która sprowadza się do tego, że 20% wysiłków przynosi aż 80% wartościowych rezultatów. Dlatego konieczne jest zidentyfikowanie tej części zakresu, która przeniesie nam największy i najistotniejszy efekt, a szukanie optymalizacji w funkcjonalnościach, które nie dają tak wielkich korzyści i nie są bezwzględnie wymagane ze względów formalno-prawnych. Wszyscy funkcjonujemy w otoczeniu, które wymusza na nas czasami spełnienie pewnych formalności, które nie dają nam wymiernych korzyści, ale brak ich uwzględnienia znacząco podnosi ryzyko inwestycji. Przykładem takich formalności w obszarze systemów informatycznych są zasady RODO, pobieranie od użytkowników wymaganych zgód, czy też wymaganie akceptacji regulaminu serwisu.
Nie twórz zbędnych funkcjonalności
Kolejnym argumentem przemawiającym za skupieniem się nad kluczowymi wymaganiami, jest doświadczenie, które wskazuje na to, że w każdym systemie informatycznym jest pewien zakres funkcji, które zostały zbudowane, a później albo nie są w ogóle wykorzystywane, albo użytkownicy korzystają z nich na tyle rzadko, że inwestycja w ich realizację nigdy się nie zwróci. Pomysłodawcy danego systemu często ciężko jest oderwać się od własnej wizji i spojrzeć na system oczami innych ludzi, dlatego tak ważna jest wspólna analiza wymagań pod kątem realizacji celu biznesowego z kimś „z zewnątrz”. Jest to szczególnie istotne, jeśli mamy do czynienia ze skomplikowaną funkcjonalnością, której realizacja będzie bardzo pracochłonna. Dla przykładu, budowaliśmy kiedyś system do raportowania czasu pracy zespołu. Głównym założeniem było stworzenia narzędzia które pozwoli na łatwe raportowanie pracy nad poszczególnymi zadaniami oraz generowanie zestawień zadań w różnorodnych ujęciach, potrzebnych dla weryfikacji efektywności pracy i rozliczeń z klientami. Jednym z wymagań naszego inwestora było dodanie funkcjonalności, która zapewniłaby mu większą kontrolę nad edycją wprowadzonych wcześniej zadań. Działało to w taki sposób, że jeśli pracownik wprowadził jakieś zadanie, a później chciał je wyedytować, to zmiana nie była od razu zapisywana, lecz trafiała na osobną listę zmian do akceptacji uprawnionego managera. Funkcjonalność ta okazała się dość pracochłonna, ze względu na specyficzne wymagania dotyczące sposobu pokazywania różnic w dwóch wersjach wpisu oraz wpływ tych zadań na bieżące raportowanie czasów pracy. Wdrożenie tego wymagania opóźniło start systemu, a po jakimś czasie funkcjonowania systemu okazało się, że ta opcja nie była w ogóle wykorzystywana. Dlaczego? Ilość edytowanych zadań była tak duża, że osoba która miała być odpowiedzialna za przeglądanie i akceptowanie tych zmian, nie miała na co dzień tyle czasu by przeglądać i akceptować zmiany. Efekt – stworzyliśmy skomplikowaną funkcjonalność, która nie była w praktyce wykorzystywana, wręcz utrudniała docelowo raportowanie zadań.
Buduj przyrostowo
Aby ograniczać występowanie takich negatywnych skutków proponujemy naszym klientom przyrostowe tworzenie systemów. Zaczynamy budowanie systemu od najważniejszych funkcjonalności, niezbędnych do osiągania celów biznesowych – tak zwanego MVP (Minimum Viable Product), a następnie dodajemy kolejne funkcjonalności lub rozszerzamy i automatyzujemy te, które były już wcześniej oddane do użytku. Pozwala to na szybsze uruchomienie komercyjne projektu w bazowym zakresie i wcześniejsze czerpanie korzyści biznesowych. Dodatkowo, umożliwia zbieranie informacji zwrotnych na temat systemu lub produktu i ulepszanie ich w kolejnych etapach (więcej zalet podejścia MVP można poznać w naszym wcześniejszym artykule „Czy należy bać się MVP?”). Praktycznie w każdym projekcie jest możliwość wyselekcjonowania zakresu funkcjonalności do realizacji lub rozwinięcia już po starcie komercyjnym tj. procesy dosprzedaży do produktu głównego sprzedawanego w systemie, procesy zmiany lub utrzymania usługi po pierwotnym kontrakcie na czas określony, rozbudowane procesy obsługi reklamacji (często na start wystarczy prosty formularz reklamacyjny, obsługiwany przez dedykowaną osobę lub nawet wysłanie reklamacji przez dedykowany adres e-mail), niektóre bardziej szczegółowe raporty. Ponadto, warto zastanowić się nad opłacalnością budowy systemu w pełni konfigurowalnego przez administratora biznesowego. W każdym systemie informatycznym są parametry, które zmieniają się często i muszą być proste do zmiany np. ceny produktów w sklepie internetowym. Dla takich parametrów warto od początku implementować mechanizmy pozwalające na łatwą zmianę przez administratora biznesowego. Niestety, często klienci wpadają w pułapkę chęci samodzielnej zmiany wielu parametrów systemu, bez konieczności proszenia developera o zmianę. Pozornie wydaje się, że to dobry pomysł, by uniezależnić się od pracy programisty i pozostawić całą konfigurację w rękach biznesu. Niekiedy jednak prowadzi to do budowania bardzo skomplikowanych i pracochłonnych modułów do administracji systemem, które pozwalają na w pełni elastyczną konfigurację. Dlaczego te elementy systemu są tak pracochłonne? Ponieważ często zmieniane parametry tworzą skomplikowane zależności, a inwestor chce by system pilnował, by niedoświadczony administrator nie wprowadził błędnych danych. Wymaga to analizy i oprogramowania skomplikowanych zależności, często w przyjaznym użytkownikowi interfejsie. Jeśli dane parametry są zmieniane raz na kilka miesięcy, raz na rok lub też nie wiemy jak często będą zmieniane, nie warto inwestować na start w rozbudowany panel administracyjny. Lepiej zoptymalizować zakres i ustalić z dostawcą oprogramowania tryb wprowadzenia takich zmian. Następnie należy zweryfikować na uruchomionym komercyjnie systemie, dla których parametrów opłaca się w przyszłości stworzyć możliwości łatwej konfiguracji biznesowej.
Automatyzuj, ale mądrze
Podobną sytuację widzimy często w obszarze automatyzacji procesów. Wielu naszych klientów chce prowadzić biznes wykorzystując systemy, które automatyzują maksymalną możliwą ilość procesów biznesowych. Doskonale to rozumiemy, bo kto chciałby robić coś, co może zrobić za nas system? Mimo wszystko, warto się zastanowić czy jest to zawsze dobry pomysł. Niektóre procesy biznesowe są bardzo skomplikowane, oparte na złożonych algorytmach decyzyjnych i posiadają liczne alternatywne ścieżki. Oprogramowanie wszystkich tych opcji bywa pracochłonne, ponieważ tworząc system musimy wskazać systemowi sposób postępowania w każdej możliwej ścieżce. Często łatwo to zdefiniować dla najbardziej oczywistych opcji, ale o wiele trudniej dla tych rzadkich. Klienci mówią wtedy „ale to mało prawdopodobny przypadek”. Wierzymy, ale system musi wiedzieć jak się zachować w tej sytuacji. Często w takich przypadkach proponujemy rozwiązanie kompromisowe, automatyzujemy całkowicie najczęściej występujące przypadki, dla których ścieżka postępowania jest jasna, a te mało prawdopodobne i pracochłonne przekierowujemy do obsługi przez człowieka. Nie dlatego, że nie da się tego całkiem zautomatyzować, a dlatego że taka inwestycja się zwyczajnie nie opłaca. Po co dodawać sobie np. 2 tygodnie programowania, by obsłużyć przypadek który pojawi się raz na kilka miesięcy i może być obsłużony przez pracownika w 15 minut? Warto rozważyć taką alternatywę optymalizacji zakresu, za każdym razem, gdy oprogramowanie jakieś pojedynczej funkcjonalności wydaje się bardzo pracochłonne.
Podsumowując, nie zawsze warto wdrażać 100% pierwotnie zaplanowanego zakresu, by nie marnować zasobów na nieprzydatne funkcjonalności. Jest to szczególnie istotne w przypadku, gdy mamy do czynienia z innowacyjnym pomysłem czy całkiem nowym systemem. Warto skupić się na celu biznesowym i minimalnym rozwiązaniu które umożliwi jego osiągnięcie, tak by przetestować koncepcję biznesową. Następnie w oparciu o realne dane należy rozwijać kluczowe funkcjonalności przynoszące największą wartość biznesową oraz automatyzować procesy, dla których jest to opłacalne. Optymalizacja zakresu projektów IT zwiększa efektywność i pozwala na maksymalizację zwrotu z inwestycji. Optymalizacja zakresu to klucz do sukcesu każdego projektu IT!
Autor: Alicja Polak
#OptymalizacjaProjektówIT #ZarządzanieZakresem #MVP #AutomatyzacjaProcesów #KosztyProjektu #CelBiznesowy #RozwójOprogramowania #EfektywnośćBiznesowa #Pareto8020 #InwestycjeIT
