Więcej nie znaczy wolniej cz.2 - analiza

kiedy jest tylko pomysł...

Czym jest analiza? Analiza to rozkład na składniki/czynniki (wikipedia). Trochę lakonicznie, nieprawdaż? Próbą zdefiniowania terminu w interesującym nas kontekście zajmę się w kolejnym akapicie. Teraz skupmy się na tym kiedy jest czas na analizę?

Jest to aktywność, która powinna być przeprowadzona na samym początku, to wyniki analizy dają nam podstawy do stworzenia dobrego projektu.
Klient ma wizję funkcjonalności, niekiedy jest w stanie przedstawić ją w formie jednego, prostego zdania i często tutaj zaczynają się problemy. I jeżeli w tym momencie zostaną one rozwiązane, to unikniemy ich powiększenia w przyszłości. W innym wypadku? No cóż, możemy mieć okazję doświadczenia na własnej skórze, czym jest efekt kuli śnieżnej:)

przeanalizujmy pojęcie

Czym jest analiza, która jest rozważana jako etap wytwarzania oprogramowania?
Zacznijmy od końca.

Produktem analizy powinien być dokument, który w jednoznaczny sposób definiuje problem. Czym jest nasz problem? Na przykład, może być to funkcjonalność pożądana przez klienta, którą będziemy musieli zaimplementować. I tak, jak wspomniałem wyżej, klient często potrafi wyrazić ją w formie jednego, prostego zdania. Jednak on widzi za tym zdaniem dużo więcej, wszystko, co dla niego "jest przecież oczywiste".

I właśnie to jedno zdanie (bądź krótki opis funkcjonalności), to są podstawy do przeprowadzenia analizy. Musimy zadać tyle pytań i w taki sposób, aby w żadnym z dalszych etapów pracy nad funkcjonalnością nie było żadnych niejasności i niedomówień, żeby nie okazało się, że klient w pewnym momencie zaskoczy nas jakąś "oczywistością".

ach, to jedno zdanie...

Spróbujmy z przykładem:)
Załóżmy, że pracujemy w kawiarni i klient prosi o kawę. Proste? Oczywiście, przecież wiem, co to kawa, więc gdzie tu problem?

Po pierwsze usuńmy niejednoznaczności.
Klient prosi o kawę, tylko jaką? Dla mnie słowo "kawa" jest równoznaczne z kawą z ekspresu, najlepiej małe espresso (czyli nawet w moim przypadku nie jest jednoznaczne:). A co klient ma na myśli? Może chce kawę rozpuszczalną, może parzoną? Z ekspresu? Jak mocną? Jak duża?
Dobra, udało nam się ustalić, że klient pije kawę parzoną, z dwóch łyżeczek na 200-250 ml wody. Mamy naszą definicję. Obie strony wiedzą, o czym rozmawiamy, wiemy, czym jest kawa:)

To teraz skupmy się na rzeczach oczywistych
Kiedy proszę żonę o kawę, wie Ona, że piję "czystą", kiedy Ona prosi mnie o kawę, robię Jej (kawę) ze sporą ilością mleka i dwoma łyżeczkami cukru. To dla nas oczywiste. Mimo tego, że i ja i Ona prosimy o kawę, dostajemy zupełnie różne napoje.
A co z naszym klientem? Pije on z mlekiem czy bez? Z cukrem? Jeżeli tak, to z jaką jego ilością? Może z bitą śmietaną? Z jakimś likierem?
I choć dla klienta to oczywiste z czym ona ma być i przez przyzwyczajenie (zwykle prosi o kawę osoby, które znają jego smaki) może nam nie podać tych, jakże istotnych, "oczywistości".

Przeprowadzenie analizy prośby klienta pomogło nam uniknąć późniejszych komplikacji, które mogłyby wyniknąć z naszego różnego rozumienia jego wypowiedzi.
Bo jak to mogło się skończyć?

• Klient dostaje złą kawę i ją pije, nie mówiąc nic. Mimo wszystko, nie jest jednak zadowolony i najprawdopodobniej do nas nie wróci.
• Klient dostaje złą kawę, pije ją, ale narzeka na to, z kim przyszło mu obcować, skoro zrobienie prostej kawy, jest wyzwaniem. Może żądać upustu, jakiejś formy rekompensaty, a w dodatku i tak okaże swoje niezadowolenie.
• Klient dostaje złą kawę, wstaje i wychodzi, nie płacąc. Możemy go zmusić do zapłaty - w końcu poprosił o kawę, tylko, że nie sprecyzował jaką dokładnie chce. Tak czy inaczej, niesmak pozostaje i z pewnością ani on, ani jego znajomi już do nas nie wrócą.
• Klient otrzymuje taką kawę, na jaką miał ochotę, bo akurat udało nam się z całej gamy dostępnych kaw, sporządzić taką, jaką lubi.

Jak widać powyżej, bez analizy i tych, mogłoby się wydawać, prostych pytań, które mogą się wydawać niepotrzebne i banalne, a odpowiedź na nie - oczywista, bardzo trudno byłoby nam sprostać oczekiwaniom klienta.

Czy to nasza wina? Nie tylko, ale w przeciwieństwie do klienta, my jesteśmy uzbrojeni w wiedzę na temat dobrych praktyk i to nasze zadanie, żeby wyszedł od nas zadowolony. Nie możemy wymagać od niego logicznego (analitycznego) myślenia w sposobie wyrażania swoich oczekiwań, gdyż jest to nasza specjalność.

człowiek zmiennym jest...

Dobrze, ale co, gdy klient zmieni zdanie? Nagle dojdzie do wniosku, że jednak ta cała, cudowna funkcjonalność nie jest mu potrzebna? W takim wypadku nie dość, że tracimy czas na implementację, to jeszcze dochodzi do tego czas stracony na analizę. A jak wiadomo, zmiany są częstsze niż byśmy chcieli.

Prawda, zmiany pojawiają się w naszym świecie zbyt często i niestety w najmniej oczekiwanym momencie. Jednak analizowanie tego, co klient od nas chce, może nam pomóc. W jaki sposób?
Poprzez serię pytań, możemy uświadomić klientowi, że on tak naprawdę nie potrzebuje danej funkcjonalności, ponieważ np. koszta jej wytworzenia nigdy się nie zwrócą, a korzyści, jakie z niej wynikną, są niewielkie.
Po drugie, możemy uświadomić klientowi, że tak naprawdę potrzebuje czegoś innego.

To może przykład?
Klient chce wysyłać maile do użytkowników aplikacji. Chce mieć możliwość wysyłania wiadomości do wielu osób na raz, możliwość odpowiadania, dodawania załączników, przekazywania itp. :)
Oczywiście uparł się, żeby to wszystko było wbudowane w system i nie chce żadnej usługi zewnętrznej, bo chce mieć wszystko w jednym miejscu. Brzmi rozsądnie.

Ale przecież wszyscy pracownicy mają skrzynki mailowe? Wszyscy wymienili ze sobą już setki maili, cała historia tych wszystkich konwersacji już jest, tyle, że gdzieś indziej. Czy nie warto byłoby mieć dostęp do tego wszystkiego? Oczywiście, że tak. Czy w obecnej funkcjonalności czegoś brakuje? Nie. Więc może jednak nie pisać wszystkiego od zera, tylko stworzyć usługę, która zintegruje obie aplikacje? Będzie szybciej i nie stracimy tego, co już wyprodukowaliśmy?

A co z tymi wszystkimi funkcjonalnościami? Jakie dokumenty są dodawane do załączników? Czy przypadkiem nie te, które są generowane w aplikacji? W takim wypadku może lepiej w inny sposób je udostępniać, niż poprzez przesyłanie? Więc może te załączniki w obecnej chwili nie są tak niezbędne? Wysyłanie do wielu osób na raz? Czy często wysyłane są maile do całkowicie losowego zestawu użytkowników, czy może są to jakieś grupy użytkowników? Może są one już odwzorowane w aplikacji? Jeżeli nie, to może warto byłoby to zrobić?

Z powyższego przykładu już nie można wyciągnąć oczywistych wnisków. Pokazuje on jedynie szereg pytań, które mogą nam pomóc w wydobyciu cennych informacji. Nie ma tu żadnej konkluzji. Może klient uprze się na wdrożeniu od zera takiego systemu, a może nie. Różnica polega na tym, że jest to jego w pełni świadomy wybór. Poznał wszystkie inne możliwości. Na podstawie rzeczywistych przykładów stwierdził, że wszystko, co chciał na początku, jest niezbędne.

kto pyta...

Analiza sprowadza się do zadawania dużej ilości pytań, które mają na celu wyciągnięcie wszystkich niezbędnych informacji od klienta. Uzyskane odpowiedzi powinny usunąć wszystkie niedopowiedzenia i niedomówienia, ale jest jeszcze jedna, bardzo istotna rzecz - klient jest bardziej świadomy tego, z jak bardzo złożonym problemem mamy do czynienia, a to przynosi nam już wymierne korzyści. Oczywiście nie mam na myśli korzyści finansowych, ale zrozumienie ze strony klienta jest równie istotne.

Osoba doinformowana, posiadająca obszerną wiedzę na temat problemu, nie będzie do nas co pięć minut dzwoniła z pytaniem, czy już skończyliśmy, bo to przecież chodziło o "wysyłanie głupich maili, każda aplikacja to ma!?".

Zyskują obie strony. Klient dostaje system, który w dużo lepszy sposób odwzorowuje jego oczekiwania, a twórcy oprogramowania otrzymują dużo większą dawkę spokoju i spore prawdopodobieństwo stabilności podjętych decyzji oraz przekonanie, że to, co tworzą, jest rzeczywiście tym, co powinno zostać stworzone.

lepsze jest wrogiem dobrego

Jak ze wszystkim, nie można przesadzać.

Po pierwsze, nie możemy pytać klienta wiecznie o to samo, warto zapisywać w jakiejkolwiek formie wnioski z rozmów przeprowadzanych z nim.

Po drugie, istotną rzeczą jest skupienie się jedynie na interesujących nas w danej chwili aspektach. Rozmowa o wszystkim jest rozmową o niczym i nie dość, że nie przynosi żadnych korzyści, to w dodatku jest stratą czasu naszego i klienta.

Ostatnie, ale nie najmniej istotne, jest skupienie się na interesującym nas poziomie szczegółowości.
Analiza jest rozkładaniem problemu na części składowe i czasami zdarza się, że osoba odpowiedzialna za nią zabrnie za daleko i istotne dla systemu części składowe rozkłada dalej (a tą czynność można robić chyba w nieskończoność:). Warto więc zastanowić się, gdzie powinna się skończyć nasza analiza.

<< Poprzednie Następne >>