Czy kojarzysz to uczucie wycieńczenia – jest piątek wieczór, wszystkie możliwe terminy są zawalone, zespół zmęczony do granic, klient jest wściekły, produkt ma błędy, a zgłaszane poprawki zdają się nie mieć końca? Po kilku miesiącach walki, frustracja zaczyna mieszać się z nienawiścią. Klient staje się wrogiem, a zespół nie chce dalej wprowadzać zmian i zajmuje pozycje w okopach…

Najczęściej w takiej sytuacji, klient wskazuje palcem na niekompetencję programistów, a programiści na to że klient nie wie czego chce. Zaryzykuje stwierdzenie, że problem leży jednak w braku naszego zrozumienia potrzeb oraz braku analizy biznesowej w projekcie.

Świat się rozpędza

W ciągu ostatnich 10 lat powstało więcej innowacji niż przez ostatnie 100 lat. Ludzki umysł jest skonstruowany w taki sposób, żeby się przystosowywać, przyzwyczajać. Nie myślimy na co dzień o tym, że przez następne 10 lat powstanie ich jeszcze więcej. Musimy się na to przygotować. 

Projekty na których pracujemy są coraz większe, informacji jest coraz więcej, wdrożenia muszą być szybsze i tak samo bezbłędne. W końcu często od jakości oprogramowania zależą czyjeś finanse lub nawet życie. W takim otoczeniu, tym bardziej potrzeba zrozumienia problemu na poziomie ludzkim, a nie tylko precyzyjnego odtworzenia specyfikacji.

Na początku komputeryzacji jeden programista był w stanie sam zbudować program zmieniający życie milionów i rozwiązujący kluczowe problemy. Dzisiaj potrzebujemy bardzo rozbudowanych systemów, istnieje więcej wymagań, więc oprogramowanie jest tworzone przez całe zespoły. Często nie małe zespoły.

Więcej na ten temat można znaleźć w raporcie PMI Tomorrow’s Teams Today (2020).

Start with why

Dlatego tak ważne jest, żeby na samym początku zbudować zrozumienie, zdobyć możliwie dużo informacji, spróbować dotrzeć do sedna projektu – np. odpowiadając na pytania zgodnie z koncepcją golden circle Simona Sineka

  1. Dlaczego ten projekt jest ważny? Dlaczego z nami? Dlaczego teraz? Jaki realizujemy cel? Z jakich wartości to wynika?
  2. Jak powinniśmy ten projekt zrealizować? W jakiej metodologii powinniśmy działać?
  3. Co konkretnie powstanie w wyniku tych działań? Jaki będzie efekt pracy? Jakie technologie wykorzystać? Jakie następne kroki trzeba podjąć?

Powód dla którego takie postępowanie jest skuteczne, najwspanialej przedstawił sam autor tej koncepcji w swoim wykładzie Start with why.

Okazja do zbudowania zrozumienia

W trakcie badania potrzeb powinniśmy sprawdzić, czy tak samo rozumiemy zadanie jak klient. Niezwykle frustrujące jest odkrycie na końcu projektu, że właściwie to klient chciał coś innego lub inaczej wyobrażał sobie rezultat. Pracujemy na dokumentach projektowych, które z klientem omawiamy i zbieramy informację zwrotną (feedback). Mogą to być obrazy, specyfikacje, opisy, grafy, itd. Choć nie zawsze – im więcej tym lepiej – to każdy z tych elementów jest okazją do zderzenia naszej wizji produktu z wizją klienta.

Czasami to sama analiza jest produktem końcowym. Może się w jej trakcie okazać, że klient wcale nie potrzebuje zaawansowanego rozwiązania lub że potrzebuje jeszcze czasu na dokładne określenie swoich biznesowych potrzeb – on lub rynek nie jest gotowy.

Niemniej jednak, klient staje się nierozerwalną częścią zespołu projektowego. W całym procesie należy zaplanować również czas na jego reakcje, na jego pracę. W każdym projekcie, niezależnie od metodologii. Nazwijmy to modelem hybrydowym – jakkolwiek – tylko niech klient zostanie zaangażowany.

Włączenie klienta lub osoby z zespołu klienta do projektu sprawia, że lepiej rozumie nasze decyzje, trudności powstające w trakcie, pomaga je rozwiązać. Staje się sojusznikiem, a nie generatorem kolejnych problemów.

Kogo warto zaangażować w taki proces?

  1. Klient – pierwsza kluczowa rola. Możemy przez to rozumieć grupę osób. Wydaje się to oczywiste – jednak łatwo się zapomnieć i pracować nad rozwiązaniami pomijając klienta. Koniecznie powstające założenia i pomysły trzeba konsultować i potwierdzać z klientem.
  2. Project manager – druga kluczowa rola, pomoże zaplanować i synchronizować wszystkie działania. Często pełni rolę moderatora w rozmowach oraz pośrednika w przekazywaniu i zbieraniu informacji.
  3. UX designer – pomoże zbadać potrzeby, przełożyć je na język wizualny, przeprowadzić badania oraz połączyć wszystkie kropki w jeden spójny obraz. 
  4. Business analyst – pomoże zbadać potrzeby i przełożyć je na język systemów informatycznych, zaprojektować zrozumiałą i jednoznaczną specyfikację.
  5. Developer, devops – techniczna rola, pomaga konsultując planowane rozwiązania, zapewnia połączenie z rzeczywistością – czyli czy nasze pomysły faktycznie da się zrealizować.

Jakich problemów możemy uniknąć dzięki analizie biznesowej?

  1. Niezrozumienie zadania
  2. Błędne wytyczne, zmiana wytycznych w trakcie pracy
  3. Strata czasu na pracę na niejasnych wytycznych
  4. Wykonanie pracy która nigdy nie zostanie użyta
  5. Utrata zaufania
  6. Brak odniesienia do oczekiwań rynku / użytkowników

Pułapka oczywistości i łączenia kropek

Zacznijmy od pewnego uogólnienia – wszystkie osoby pracujące przy wytwarzaniu oprogramowania to osoby inteligentne, wykształcone, zazwyczaj wielojęzyczne i z doświadczeniem przy podobnych projektach. Jeżeli takiej dasz choćby zarys swojego pomysłu, będzie w stanie na podstawie doświadczenia uzupełnić brakujące kropki i połączyć całość w spójny obraz. 

To jednak wcale nie oznacza, że to będzie spójne z wizją klienta. Dlatego staje się ta cecha zarówno błogosławieństwem, jak i przekleństwem. Dlatego mamy dwie drogi – albo cały system opisujemy od razu bardzo dokładnie albo podchodzimy do realizacji iteracyjnie i pracujemy nad opisem kolejnych, mniejszych części projektu. O tym, że pierwsze podejście znacząco zmniejsza szansę na powodzenie projektu polecam przeczytać w raporcie Gartnera – IT Projects Need Less Complexity, Not More Governance.

Dodatkowo działa tutaj pewna sprzeczna siła. Developer rozwiązując konkretny problem – np. wyliczanie kwoty zamówienia z rabatem i przesyłką w koszyku musi wejść bardzo głęboko w sam sposób realizacji (modele, baza danych, technologia, zabezpieczenia, itd) co sprawia, że automatycznie traci spojrzenie na całość – big picture. Zazwyczaj tylko na chwilę, ale jednak powrót do obiektywizmu i dystansu jest bardzo trudny. Co więcej zazwyczaj w trakcie prac nie ma na to czasu. 

Skutkuje to tym, że jeśli później ma za zadanie uzupełnić jakieś luki informacyjne, coś czego klient nie wyraził, coś czego nie było w specyfikacji – to bardzo trudno mu będzie wejść na niezbędny poziom dystansu i połączy zamiast odpowiednich – dwie najbliższe kropki. To kolejny powód dlaczego warto poświęcić czas na badanie potrzeb i analizę biznesową.

Błędne wytyczne

Tworzenie oprogramowania to proces wytwarzania czegoś nowego. Każdy projekt to unikalny twór. Nawet jeśli się wzorujemy na czymś co już działa, nadal będzie jakiś wyróżnik. W takiej sytuacji trudno oczekiwać od klienta, że będzie wiedział co i jak dokładnie trzeba zrobić. Klient wie jaki cel chce osiągnąć (i to i tak w optymistycznej wersji). Zadaniem software house jest wspólnie z nim ustalić sposób i narzędzia potrzebne by cel osiągnąć. Bez etapu analizy, bardzo łatwo jest pomylić cel ze środkiem – a w ten sposób powstają będę wytyczne. 

Przykładowo: klient wie że chce sprzedawać swój produkt na rynku zagraniczne. Dlatego przychodzi do software house i mówi że potrzebuje sklepu opartego o WooCommerce (gdzieś słyszał, że tak robią wszyscy) w 3 wersjach językowych i z wtyczką Yoast (bo podobno sprawia że strona magicznie spełnia punkt “SEO”). Jeśli software house po prostu takie zadanie zrealizuje to teoretycznie zrealizuje cel klienta – posiadanie WooCommerce. 

Niestety nie przybliży go do celu sprzedażowego. Zadaniem analizy biznesowej jest postawienie czasem kroku wstecz i dotarcie do podstawowej potrzeby oraz rozważenie możliwych dróg dotarcia. Może wystarczy produkt wrzucić na ebay i uruchomić prosty, darmowy landing page? Z perspektywy klienta lepiej zapłacić za kilka dni warsztatów i badanie żeby poznać taką odpowiedź, niż spędzić kilka miesięcy na wdrażaniu sklepu który nie będzie sprzedawał.

Utrata zaufania

Znów pojawia się pewna sprzeczność. Dlaczego software house miałby sugerować klientowi rozwiązanie w wyniku którego nie będzie miał zysku? Jeśli zależy nam na jednorazowej sprzedaży to takie działanie faktycznie nie ma sensu. Jeśli do każdego klienta podchodzisz poważnie i po partnersku, to zależy Ci na wskazaniu najlepszych dróg do osiągnięcia sukcesu. Jeśli Twój klient osiągnie sukces, to dobrze będzie wiedział z kim to zrobił. W ten sposób na zaufaniu budujemy relację, która owocuje w przyszłości.

Jeżeli klient otrzyma coś innego niż zamawiał – to winnym temu będzie wykonawca. To jego zadaniem jest zrozumienie i wykonanie dla klienta 120% jego celu. Powinien pozytywnie zaskoczyć, a nie stracić czas klienta na wdrażanie czegoś co jest niepotrzebne lub nawet szkodliwe. Ślepe realizowanie każdego zapytania klienta będzie skutkowało utratą zaufania i w najlepszym razie rozpocznie proces zakończenia współpracy. Dla mnie to jeden z podstawowych argumentów przemawiających za poświęcaniem czasu na analizę i badanie potrzeb klienta.

Niejasne wytyczne

Nie zawsze możemy również oczekiwać, że klient będzie miał po swojej stronie możliwość stworzenia wytycznych spełniających wymogi jasnej specyfikacji, czy dokumentacji technicznej. Zazwyczaj specyfikacja to na początku 1-2 strony luźnych przemyśleń lub pomysł opisany w jednym mailu. Zrzucenie dokładnego opisu rozwiązania na klienta może doprowadzić do tego, że wchodząc coraz głębiej w swój własny pomysł i rozpisując rozwiązania, klient traci już i tak raczej niewielki dystans. Wtedy trudno jest wprowadzić jakąkolwiek modyfikacje do jego pomysłów i trzeba iść na programistyczne kompromisy. 

Jeśli wypracujemy rozwiązanie wspólnie, to klient na gorąco ma możliwość skonfrontowania swoich pomysłów z możliwościami technologii. Z drugiej strony developer dostaje wyzwanie jak zmusić technologię do realizacji oczekiwań. Tylko w wyniku połączenia tych dwóch punktów widzenia, można stworzyć produkt jednocześnie dobrze działający i spełniający wymagania klienta.

Różne mapy świata

Nie możemy pominąć faktu, że każdy z nas inaczej postrzega rzeczywistość. Inaczej nazywamy te same zjawiska, tworząc różne mapy w naszej świadomości. W sytuacji kiedy mamy do pogodzenia np. klienta z branży kreatywnej oraz developera, który obraca się przede wszystkim w otoczeniu programistów javy? Nieszczęście gotowe.

Klient nie rozumie naszego żargonu, nie rozumie dlaczego coś prostego jest zmianą, a nie drobną poprawką, itd. My nie wiemy jaką rzeczywistość opisuje klient, próbujemy przełożyć jego słowa na znane nam narzędzia, ale na końcu okazuje się że to nie to. Nasze mózgi funkcjonują inaczej. Mamy różnice językowe, kulturowe, wiekowe, branżowe, różnice w doświadczeniu i wiele innych.

Z tego właśnie powodu umiejętne prowadzenie dialogu, usilne próbowanie zrozumienia co naprawdę klient ma na myśli – badanie potrzeb – jest kluczem do sukcesu wdrożenia. Polecam lekturę książki Thomasa Eriksona – Surrounded by Idiots. Daje ona obraz tego jak porażające różnice w komunikacji występują u różnych osób.

Zmiana wytycznych w trakcie pracy

To zmora większości projektów IT. Czasami po zobaczeniu pierwszych efektów pracy do klienta dociera że to nie jest do końca to co sobie wyobrażał. Czasem nawet nie wynika to z tego, że coś zobaczył tylko po prostu minął pewien czas, pomysł lepiej się w głowie ułożył i wymaga pewnych zmian – drobnych, minimalnych. To co dla klienta jest kosmetyczną zmianę, z perspektywy programisty może przekreślać tygodnie pracy.

Nawet jeśli uzgodnimy że w trakcie projektu możemy zmieniać jego założenia – wszyscy przecież chcemy pracować zwinnie – to jeśli będą takie zmiany zbyt częste lub zbyt duże powstanie produkt, który będzie niespójny. W kodzie pozostaną niepotrzebne, niedziałające funkcje, złożoność projektu będzie większa, wpłynie to na awaryjność, podniesie cenę, itd. Jeśli możemy lepiej tego uniknąć.

Nie oznacza to że projekt ma być atomowy (niepodzielny). Oznacza to, że po pierwsze musimy najpierw bardzo konkretnie ustalić big picture. Zadbać o to, żeby cały zespół wiedział jaki jest ostateczny cel i mógł dostosowywać rozwiązania żeby najlepiej go zrealizować. Po drugie, że powinniśmy stosować możliwie krótkie iteracje, wtedy delikatne korekty kursu robimy na bieżąco. Takie podejście w rzeczywistości zaprasza zmiany do procesu ponieważ, w praktyce cel też się może zmienić. Po zakończonych iteracjach warto weryfikować, czy cel nadal jest ten sam (lub też go zmienić/dostosować).

Praca w kosz

Kolejnym zagrożeniem jest to, że podczas długiej pracy nad pierwszą wersją nasz pomysł lub technologia straci swoją aktualność. Jeśli realizujemy jakiś startup czy nową usługę to jeśli ktoś to zrobi szybciej – tracimy korzyści z pierwszeństwa na rynku. Jeśli narzędzie które usprawnia naszą pracę – dłużej pracujemy w nieefektywny sposób. Jeśli po prostu odświeżamy naszą stronę – potencjalnie tracimy klientów, którzy nam nie zaufają bo strona wygląda niewiarygodnie. Krótko mówiąc – liczy się czas – im szybciej tym lepiej. 

Poświęciliśmy 3 lata na zbudowanie naszego idealnego startupu i jesteśmy wreszcie gotowi do startu? W tym czasie klient sam już pewnie nie jest tak bardzo zakochany we własnym pomyśle, zapał zgasł, świat się zmienił. W najlepszym razie trzeba po prostu część produktu przepisać na nowo, w najgorszym kilka lat pracy rozpoczyna w ten sposób powolny proces umierania aby ostatecznie trafić do kosza.

Zawsze mamy ryzyko że część pracy będzie musiała zostać wyrzucona do kosza, jednak im szybciej weryfikujemy pomysły, tym mniejsze fragmenty pracy i naszego czasu stracimy.

Co na to rynek?

Innym aspektem badania potrzeb jest to że tworzymy przestrzeń do tego, żeby sprawdzić czy dany pomysł lub produkt jest dopasowany do rynku. Sprawdzamy tak zwany market-fit. To szczególnie ważne, w przypadku nowych produktów i startupów.

Dzięki takiej analizie możemy wspólnie wypracować MVP. Pierwszą wersję projektu, która przy możliwie minimalnym nakładzie środków pozwoli nam sprawdzić tezy projektu i szybko dostosować się do tego w jaki sposób odpowie rynek. A jeśli produkt nie znajdzie swojego rynku – względnie szybko i niedrogo możemy się wycofać i przekierować energię gdzie indziej.

Dlaczego klient ma za to płacić?

Czy nie jest tak, że jest to potrzebne wykonawcy, a nie zamawiającemu? To zrozumiała obawa. Wynika ona jednak z wąskiej perspektywy spojrzenia na projekt. Czas poświęcony na analizę przedwdrożeniową realnie pozwala zaoszczędzić pieniądze przy kolejnych etapach realizacji. Może też w ogóle zatrzymać realizację jakiegoś projektu.

Na porządnych materiałach – specyfikacjach i makietach – mniej pracy ma później projektant. Z dobrze przygotowanym i przemyślanym projektem graficznym i systemem – mniej pracy mają programiści. Po prostu mogą od razu zająć się tym na czym najlepiej się znają. Nie muszą zagłębiać się w pytania natury “co autor miał na myśli”, wracać z pytaniami, czekać, tworzyć przestoje. Dzięki temu wycena etapów projektowania i produkcji może być bardziej realna oraz obarczona mniejszym marginesem.

Nie oznacza to oczywiście całkowitej eliminacji błędów. Pozwala jednak zredukować je do minimum. Skutkiem tego cały zespół nie jest tak zrażony do zmian w trakcie, co otwiera pole do kontrolowanych, korzystnych i przemyślanych zmian już podczas realizacji. Cały projekt powstaje wtedy przyrostowo i zwinnie. A na tym przecież zależy i nam i klientowi.

Słowem podsumowania

Badanie potrzeb jest to etap przygotowań, który pozwala zrozumieć prawdziwą potrzebę, rzeczywisty cel klienta. Analiza biznesowa to proces ciągły i pozwala zbudować prawdziwą relację oraz komunikację. Tworzymy niezbędne, wzajemne zaufanie.

Dobrze przeprowadzone badanie potrzeb i stale prowadzona analiza biznesowa nie zabezpiecza nas oczywiście przez zdarzeniami losowymi, które mogą nam pokrzyżować plany projektowe. Znacząco jednak obniżają ryzyko zachwiania procesu realizacji oraz zwiększają powtarzalność efektów. Rozwój systemu od razu planowany jest na lata, a jednocześnie pierwsza – zupełnie funkcjonalna – wersja dostępna jest dużo szybciej. Szybciej też weryfikujemy nasze pomysły.

Chociaż zwykle zarówno wykonawca, jak i klient chciałby możliwie szybko przystąpić do realizacji projektu. Chociaż w tym momencie często szybkie rozpoczęcie realizacji wydaje się niezbędną koniecznością (przecież terminy gonią, a wciąż jest tyle pracy). Warto zatrzymać się i najpierw ustalić co jest celem i w jaki sposób możemy go osiągnąć. Przygotować materiały oraz plan, aby później ze spokojem obserwować powstawanie kolejnych części projektu.

Sharing is caring!