Zrozumieć klienta

Zdarza się, że nasi przełożeni traktują nas jak białkowe interfejsy do produkcji softu. Z drugiej strony, jeśli cokolwiek pójdzie nie tak, to i tak jest nasza wina pomimo nieprecyzyjnych wymagań.

Ciągle mówi nam się JAK mamy rozwiązać problem, ale nikt nie wspomina co rozwiązujemy i po co. Jednak czasem chcielibyśmy czegoś więcej. Chcielibyśmy wziąć w końcu na siebie większą odpowiedzialność, jednocześnie wiedzieć dokładniej jaki problem rozwiązujemy i mieć na to wpływ.

Jeśli masz podobne przemyślenia, to ten artykuł napisałem właśnie dla Ciebie.

Często podczas rozwoju kariery programisty aby przejść krok dalej, trzeba dokonać istotnej zmiany w sposobie myślenia i nauczyć się nowych rzeczy. Tym razem nie mam na myśli nowego języka programowania, czy kolejnego frameworka w JSie. Mam na myśli coś, co przyniesie Ci zdecydowanie więcej korzyści.

Czego zatem jako programista powinieneś się nauczyć, aby zostać inżynierem rozwiązań, a nie klepaczem kodu?

Odpowiedź brzmi: biznesu Twojego klienta. Jeśli poznasz kim on jest, jak wyglądają procesy w jego biznesie oraz skąd i dokąd płyną w nim pieniądze – będziesz w stanie lepiej mu pomóc. To doprowadzi do tego, że będzie bardziej Ci ufał. Z upływem czasu przejmiesz większą odpowiedzialność i dostarczysz lepsze rozwiązania jego problemów.

Na koniec dnia i tak inżynier jest winny

Wyobraź sobie taką sytuację:

Klient poprosił Cię o dopisanie nowej funkcji do systemu, nad którym pracujesz. Wyestymowałeś ją, przegadałeś z zespołem i dopytałeś o szczegóły implementacyjne. Następnie zabrałeś się za robotę.

Po dostarczeniu okazało się, że zawiodłeś oczekiwania. To, nad czym pracowałeś, nie spełnia niektórych wymagań klienta, o których dowiedziałeś się dopiero w trakcie demonstracji, lub nie jest on zadowolony z wydajności rozwiązania, gdy przetestował przypadek, o którym wcześniej nie było mowy.

W efekcie klient kieruje swoje niezadowolenie na firmę, w której pracujesz, a firma na Ciebie, np. poprzez okresową ocenę pracy. Pomimo tego, że robiłeś to, czego chciał klient i pomimo tego, że nie wiedziałeś o dodatkowych wymaganiach (które wziąłbyś je pod uwagę), wina może spaść na Ciebie.

Dlaczego?

Source: https://giphy.com/gifs/why-ryan-reynolds-1M9fmo1WAFVK0

Klient zawsze oczekuje, że rozwiążemy jego problem. Zwykle jest przyzwyczajony, że jedyne rozwiązanie jakie możemy mu dostarczyć jest w postaci kodu. Jednak to nie o kod mu, tak naprawdę, chodzi. Czasem nie jest w stanie wprost wyrazić, gdzie leży sedno sprawy, a jednocześnie próbuje komunikować się z nami językiem, który znamy. A my rozumiemy formatki, buttony, funkcje, api…

Inżynier jest odpowiedzialny za pracę, którą wykonuje. Dobre jej wykonanie często leży w odpowiedniej komunikacji pomiędzy stronami i poprawnej definicji problemu. Jak zatem dostarczyć najwyższą możliwą wartość odbiorcy?

Poznaj z kim masz do czynienia

Source: pixabay.com

Klient, przychodząc z pewnym problemem. często przekazuje wiele zaszumionych informacji. Czasem wprost domaga się konkretnej technicznej implementacji, bez wyjaśniania co za nią stoi.

Wydobycie faktycznego problemu i poznanie jego domeny z szumu informacyjnego jest trudne. Wiele osób musi zmagać się z tym na co dzień, niezależnie od roli jaką pełni w zespole.

Z tymi problemami zmagam się od lat podczas estymacji projektów oraz w codziennej pracy z klientami. Na podstawie swoich doświadczeń spisałem dla ciebie kilka podstawowych technik, dzięki którym udaje mi się wyłuskać wartościowe informacje i złożyć z nich wymagania dla projektu.

Jedną z pierwszych rzeczy, które robię podczas procesu poznawania problemu klienta jest zgromadzenie informacji na temat jego biznesu. Często na wiele możliwych sposobów.

Jakich informacji szukam?

• Czym zajmuje się firma klienta i na czym polega branża, w której się obraca?
• Jak zarabia pieniądze?
• Jakich ma klientów?

Skąd można wziąć takie informacje?

Można podpytać sprzedawców, analityków - mogli zrobić wstępne rozeznanie. Można też odwiedzić stronę firmową, portale społecznościowe, czasem KRS/odpowiednik w danym kraju.

Po co mi takie informacje?

Dzięki nim jestem w stanie przefiltrować wszystkie informacje pochodzące od klienta (maile, dokumenty itp.) pod kątem potencjalnego problemu biznesowego. Na tej podstawie mogę zbudować pierwszą listę założeń dotyczących projektu, z którym przychodzi.

Jaką wartość ma dostarczyć rozwiązanie, którego poszukuje klient? Której części jego biznesu dotyczy? Jak wygląda obecny proces, który choć zarabia pieniądze, ma pewne wady, które klient chce skorygować? Takiej listy odpowiedzi potrzebuję, by iść dalej.

Czy to wystarczy, aby zrozumieć klienta i mu pomóc? Absolutnie nie.

Zweryfikuj wnioski

Następnym krokiem musi być bezpośrednia rozmowa z klientem. Podczas niej pozwalam klientowi opowiedzieć o swoim problemie i o tym, jak powinniśmy go rozwiązać. Daj mu opowiedzieć o kryteriach sukcesu naszej współpracy, o swoim biznesie i jak on wygląda na co dzień i co chciałby ulepszyć. Może już ma jakieś „tymczasowe” rozwiązanie, które chciałby zmienić/poprawić – może je pokaże i o nim opowie.

Na bieżąco konfrontuję to, co mówi z listą założeń, które już posiadam. Jeśli coś jest niejasne lub się nie zgadza, dopytuję i weryfikuję.

Dopiero teraz, z uzyskanych informacji, można wyciągnąć odpowiedź na pytanie,  czego klient tak naprawdę chce.

Zdefiniuj problem, znajdź rozwiązanie

Po rozmowie z klientem strumień informacji powinien zostać wystarczająco oczyszczony, a specyfikacja problemu częściowo wyklarowana. Dzięki temu można stworzyć artefakt, który wprost wskazuje:

• Kto jest beneficjentem projektu?
• Jaki ma problem?
• W jaki sposób powinniśmy go rozwiązać?

Warto w trakcie takiego procesu odbić swoje przemyślenia z inną osobą. Dlaczego? Z doświadczenia wiem, że dyskusja (zwłaszcza bardzo ożywiona) przynosi najlepsze efekty w docieraniu do potencjalnych rozwiązań problemów. Przyda się również wśród nas nietechniczna osoba, która jest w stanie uciąć zbyt głębokie dyskusje na temat technikaliów.

Aktywna grupa osób, pracująca na powyżej wspomnianym artefakcie, jest w stanie wyprowadzić wysokopoziomowe wymagania funkcjonalne dla rozwiązywanego problemu. Mając takie dane, wystarczy wybrać dla każdego z nich jeden „szybki win”, który w jak najprostszy/najszybszy sposób je spełnia.

Warto rozważyć w takim przypadku gotowe komponenty, narzędzia i usługi. Celem jest spełnienie odpowiednio zdefiniowanego wymagania. Cokolwiek do niego prowadzi, jest pełnowartościowym rozwiązaniem problemu.

Jak to zrealizować?

[caption id=“attachment_300” align=“aligncenter” width=“900”] Source: pixabay.com[/caption]

Aby lepiej zobrazować ten proces, pokażę Ci to na autentycznym przykładzie, który zdarzył mi się parę miesięcy temu – nazwa firmy i domena zostały oczywiście zmienione.

Weźmy do analizy firmę Zapałex sp. z o.o.

Poproszono mnie o wzięcie udziału w estymacji projektu dla powyższej firmy. Projekt dotyczył stworzenia portalu wiedzy o produktach firmy połączonego ze stanami magazynowymi i innymi wewnętrznymi systemami.

Specyfikacja problemu składała się z wielu poszatkowanych informacji, często przeczących sobie nawzajem – nie do końca wiadomo było, o co w tym projekcie chodzi.

Buduję założenia

Wszedłem zatem na stronę Zapałexu, żeby dowiedzieć się czegoś więcej o tej firmie.

Informacje, które znalazłem to: producent zapałek, jeden z większych graczy na rynku, firma często bywa na targach branżowych, publikuje artykuły o swoich produktach, udostępnia formularze dla potencjalnych klientów. Ich klienci to więksi hurtownicy, sprzedający produkty Zapałexu do sieci handlowych i niewielkich sklepów. Tak duży gracz prawdopodobnie patrzy na to, jak zmniejszać koszty sprzedaży i ją automatyzować, niż po prostu ją zwiększać.

Wspomniałem wcześniej, że zdobyte informacje pomogą filtrować specyfikację zlecenia podaną przez klienta. Patrząc na nią, w tym przypadku, nasunął mi się wniosek, że cała integracja z magazynami i wewnętrznymi systemami może oznaczać po prostu moduł e-commerce, który po części zautomatyzuje proces sprzedaży w firmie.

Z tymi informacjami mogłem dzwonić do klienta zweryfikować założenia. Proces biznesowy i problem do rozwiązania nie były jeszcze w pełni określone – wiedziałem, że wyjdą one podczas rozmowy.

Weryfikuję założenia

W czasie rozmowy okazało się, że prawdziwym problemem klienta nie jest zwiększenie sprzedaży aktualnym klientom, czy jej automatyzacja, a stworzenie wokół firmy marki eksperckiej w branży zapałek.

Co za tym idzie, celem było sprzedawanie swojej eksperckości nowemu segmentowi klientów.

Dopiero po wyciągnięciu tej informacji okazało się, że np. cały moduł e-commerce jest na teraz kompletnie niepotrzebny. Integracja z obecnymi systemami miała wspomóc promowanie autorskich rozwiązań firmy, a nie automatyzować sprzedaż.

Oszczędziło to rozmyślań nad estymacją funkcjonalności, które nie będą przydatne z perspektywy klienta.

Skoro dopiero rozmowa przyniosła zamierzony efekt, to czy nie powinienem od razu skontaktować się z klientem, zamiast szukać informacji na własną rękę?

Zebrane informacje pomogły mi zrozumieć obecny biznes klienta i wysnuć pierwsze wnioski na temat potencjalnego problemu.

Dzięki temu mogłem poprowadzić rozmowę w taki sposób, aby wyciągnąć, co tak naprawdę klient chce osiągnąć. Bez elementu wstępnego rozpoznania nie miałbym już istniejących założeń do weryfikacji, miałbym w głowie tylko listę technicznych funkcji systemu, które klient dostarczył, bez większego obrazu w głowie.

Stworzenie pierwszego artefaktu

Kolejnym wspomnianym wcześniej krokiem jest skupienie się na zdefiniowaniu problemów, a następnie znalezienie dla nich najszybszego i pełnowartościowego rozwiązania. Pozostając w przykładzie firmy Zapałex Sp. z o. o. pokażę Ci jak implementację tego procesu.

Jednym z głównych beneficjentów projektu jest w tym przypadku nasz klient. Zatem odpowiedzi na pytania, definiujące problem, w jego przypadku wyglądają tak:

• Kto jest beneficjentem projektu? – Zapałex
• Jaki ma problem? – Klienci nie postrzegają firmy jako eksperta w swojej branży, a zwykłego producenta zapałek, nie czerpiemy zysków z segmentu klientów, którzy szukają porady, a nie pudełka zapałek.
• W jaki sposób powinniśmy go rozwiązać? – Udostępnić przestrzeń, gdzie firma może dzielić się materiałami branżowymi , takimi jak artykuły, relacje z konferencji branżowych, czy poradami ze swoimi klientami.
• Przykład „szybkiego winu” – do zaspokojenia tego problemu wystarczy klientowi dobrze skonfigurowany i zintegrowany z systemami firmowymi Wordpress.

Po zakończeniu tego etapu warto ponownie zweryfikować z klientem, czy nie zbaczamy z kursu. Należy również dowiedzieć się, czy wybrane rozwiązania problemów składające się z gotowych rozwiązań są akceptowalne.

Może się okazać, że Wordpress z powyższego przykładu jest nieakceptowalny z perspektywy klienta – wówczas należy zastanowić się jak ugasić ten ból w inny sposób. Jeśli klient nie akceptuje – adaptujemy założenia i powtarzamy cykl.

Dlaczego to działa?

Docieranie do sedna problemu klienta i znajdowanie dla niego rozwiązań jest trudne. Nie sposób przewidzieć wszystkiego, a informacje, które posiadasz zarówno ty, jak i klient, nigdy nie są kompletne.

Bardzo ciężko jest wyciągnąć konkretne informacje z chaosu, a często tak wyglądają pierwsze wersje specyfikacji, czy opis pożądanej funkcjonalności.

Uporządkowanie podstawowych informacji i bieżąca weryfikacja u źródła może tylko pomóc – co więcej, nie kosztuje dużo czasu. Ten proces pełni rolę unit testów podczas refaktoryzacji. Potrzebujesz ich, żeby wiedzieć, że nic nie zepsułeś.

Jeśli zapamiętasz, aby przed przystąpieniem do implementacji rozwiązania najpierw odkopać z natłoku informacji:

• Kim jest klient? Czym się zajmuje?
• Jak zarabia pieniądze?
• Jak wygląda jego proces biznesowy?

Może się okazać, że klient wcale nie potrzebuje tego, co właśnie miałeś implementować, a czegoś kompletnie innego. Dzięki temu będziesz mógł faktycznie pomóc w jego problemie, a nie bezrefleksyjnie wytwarzać kod na zawołanie.

W taki sposób staniesz się lepszym inżynierem, jednocześnie mniej skupiając się na samym kodzie.

Co z powyższego wziąć ze sobą jutro do pracy?

Komunikacja ludzi technicznych ze światem biznesu nie jest łatwa, ale jest nieodłącznym elementem naszej pracy. To, jak dobrze sobie radzimy z tym zadaniem, definiuje jakość naszej pracy bardziej niż techniczne podejście do implementacji rozwiązania problemu.

Kiedy klient przyjdzie do Ciebie z kolejną funkcją lub projektem, pamiętaj:

• Znajdź odpowiedź na pytanie: jaki proces biznesowy już jest u klienta? Następnie znajdź w nim dziurę, skąd uciekają pieniądze i znajdź sposób na jej załatanie – najlepszą metodą na to jest zgromadzenie informacji o kliencie od osób, które już z nim pracują lub z internetu, a następnie rozmowa z klientem w której on mówi, ty słuchasz i dopytujesz.
• Informacja zawsze jest niekompletna po każdej stronie barykady – iteracyjna weryfikacja założeń z klientem i z innymi beneficjentami projektu przybliża do sukcesu projektu.
• Szybkie i proste rozwiązania problemu, które dostarczają wartość, są zawsze lepsze, nawet jeśli oznacza to, że mniej jest w nich naszego kodu (lub nie ma go w ogóle).

Mając na uwadze powyższe rady, zwiększysz swoją skuteczność w docieraniu do prawdziwych wymagań dla problemu, który rozwiązujesz.

Dzięki temu firma, dla której pracujesz, zarobi pieniądze, klient będzie zadowolony, a Ty przestaniesz być maszynką do generowania kodu – staniesz się inżynierem rozwiązań, którego warto zapytać o zdanie. Będziesz gotów przyjąć na siebie większą odpowiedzialność.