Większości z nas w trakcie kariery przynajmniej raz zdarzyło się brać udział w procesie tzw. „bidowania”, czyli tworzenia oferty projektowej. Podobnie jak projekty tak i tworzenie ofert w niewielu przypadkach jest powtarzalne, ale jest jeden problem, z którym większość z nas zderza się niezwykle często – niechęć klientów to inwestowania w analizę i parcie na jak najszybsze rozpoczęcie developmentu.
Najczęstszym powodem rezygnacji z analizy jest niechęć do ponoszenia dodatkowych kosztów. Dokładne przeanalizowanie problemu i przygotowanie dokumentacji jest przede wszystkim czasochłonne, nie tylko dla analityka, ale i przedstawicieli biznesu który analizujemy. Tym sposobem nie mogą być oni zaangażowani w działania operacyjne, co często wpływa na koszty lub utratę części przychodów (kiedyś usłyszałem, że sprzedawcy „zamiast sprzedawać rysują coś tam z analitykami”). Jak więc przystąpić do dyskusji z klientem który „na dzień dobry” jest na nie wobec analizy? W poniższym artykule postaram się przytoczyć kilka argumentów pozwalających, jeśli nie na przekonanie klienta, to przynajmniej zmuszających go do rozważenia uwzględnienia analizy w harmonogramie.
Przede wszystkim skupmy się na najważniejszym – kosztach. Czas to pieniądz, ale czy dodatkowa inwestycja w analizę to naprawdę strata środków? Jest kilka kluczowych argumentów, które mogą przekonać klienta, że ta inwestycja może się zwrócić i w dłuższej perspektywie pozwoli ograniczyć koszty rozwoju oprogramowania.
Po pierwsze – dobrze opisane procesy pozwalają dobrze poznać jak faktycznie działa nasze przedsiębiorstwo. Często aby zaoszczędzić czas oprogramowanie rozwija się w oparciu o historyjki na podstawie których tworzone są nowe funkcjonalności. Taki stan może utrzymywać się przez lata – systemy rosną, ludzie pracują, wszyscy są zadowoleni. Przychodzi jednak taki moment, gdy liczba danych wprowadzanych manualnie do systemów zaczyna ciążyć i pojawia się temat integracji. Brak wcześniejszej analizy AS IS może to znacząco utrudniać i tu kłania się analiza procesowa. Starajmy się uświadomić klienta, że przede wszystkim w dobrze opisanym procesie łatwo jest zidentyfikować punkty styku pomiędzy systemami oraz zidentyfikować zbędne czynności które np. dublują się w obu systemach. Gdyby analizę zrobiono wcześniej, być może udałoby się uniknąć kosztów poniesionych na rozwój dublujących się funkcjonalności, późniejszą migrację danych czy też uspójnianie słowników. Patrząc na stawki rynkowe programistów o wiele taniej byłoby poświęcić więcej środków na prace analityczne niż oprogramowanie dublujących się funkcjonalności lub poprawki wynikające z braku wcześniej przeprowadzonej analizy.
Po drugie – modele procesów pozwalają lepiej zaplanować prace i ustalić dla których kluczowe jest natychmiastowe wdrożenie a które mogą poczekać. Jest to cenny argument nie tylko dla projektów z ograniczonym budżetem, ale również dla projektów time and material. W ten sposób możemy pokazać klientom, że staramy się im pomóc jak najlepiej wykorzystać ich środki. Dodatkowo, patrząc na proces, można zdecydować, że dane funkcjonalności powinny być wdrożone w innym systemie niż pierwotnie planowany, co może pomóc zredukować koszty (rozwój różnych narzędzi ma różną cenę), lub przyspieszyć realizację.
Po trzecie – pamiętajmy, że większość osób to jednak wzrokowcy i jeżeli coś można przedstawić graficznie a nie w formie tekstu to lepiej to zrobić. Korzyść dla klienta to przede wszystkim uproszczenie procesu komunikacji zamodelowanego procesu w organizacji (np. nowym członkom), ułatwienie optymalizacji (możemy szybko wyłapać czynności zbędne lub wymagające automatyzacji) oraz jasne określenie odpowiedzialności, kto w organizacji odpowiada za poszczególne kroki w procesie.
Czwartym argumentem jest brak konieczności inwestowania w dodatkowe narzędzia. Na rynku jest ponad 70 narzędzi do modelowania, z czego część jest całkowicie bezpłatna i zapewnia najbardziej podstawowe funkcjonalności. Porównanie narzędzi to materiał na osobny artykuł, ale na pewno każdy znajdzie coś dla siebie. Dodatkowo na rynku jest dostępna szeroka gama narzędzi wspierających analizę i pozwalających na tworzenie prototypów narzędzi, makiet itp. Dzięki temu klient może uzyskać lepsze wyobrażenie o docelowym rozwiązaniu.
Podsumowując – klient, co nie jest odkryciem – jest zainteresowany jak najlepszym wydaniem swoich pieniędzy i kluczem jest przekonanie go, że pieniądze poświęcone na analizę procesową zaprocentują w przyszłości. Zgodnie z cyklem Deminga nie da się udoskonalić czegoś, czego kształtu nie znamy i to właśnie procesy pozwalają nam poznać naszą organizację i w przystępny sposób opisać jej funkcjonowanie. Nie każdy klient jest tego świadomy, ale holistyczne podejście do analizy problemu biznesowego, jakie możemy uzyskać modelując procesy biznesowe w organizacji, pozwoli nam rozsądnie rozwijać oprogramowanie z naciskiem na utrzymanie właściwej jakości, rozsądne wykorzystanie zasobów i przede wszystkim zaplanowanie prac w całej organizacji a nie „szarpane” rozwijanie funkcjonalności przez każdy system na własną rękę.
Zostaw komentarz