Nie da się rozwiązać problemu biznesowego bez poznania przyczyny jego powstania. Dlatego tak ważne są spotkania ze zleceniodawcami, podczas których możemy poznać genezę danego problemu. Do tego potrzebny jest szereg umiejętności np. umiejętność “wejścia w buty” drugiej osoby.
– Bardzo mało osób próbuje zrozumieć drugą osobę – zrozumieć sytuację, w której aktualnie się znajduje. Często bywa tak, iż to klient wie tak naprawdę dlaczego potrzebuje rozwiązać ten problem, w taki a nie inny sposób – powiedział nam Damian Kryger, współzałożyciel Business Coders.
O co Twoim zdaniem za rzadko pytamy klientów, dla których tworzymy rozwiązania technologiczne?
Moim zdaniem, programiści za rzadko pytają się klientów o problem, z którym klient przychodzi.
Aby zarysować cały problem posłużę się metaforą, bo nie wszyscy programiści pracują na kontrakcie B2B, albo choćby jeżeli pracują to wiadomo jak jest – atmosfera jest fajna, więc czujemy się częścią firmy nie pamiętając, iż jednak cały czas pracujemy dla klienta a nie dla pracodawcy.
Dlatego wyobraźmy sobie, iż naszym klientem jest Product Manager/Product Owner (w zależności od nomenklatury przyjętej w organizacji). Wolę określenie Product Owner (skrótowo PO), więc w dalszej części będę korzystał z tej nazwy.
PO przychodzi do nas z zadaniem. Na szczęście coraz częściej przygotowują zadania tak, by były dopracowane, zawierały niezbędne szczegóły itp. No i tutaj pojawia się problem, ponieważ wielokrotnie spotkałem się z sytuacją, kiedy programista brał “taska” i po prostu go “klepał”. Moim zdaniem to tak nie powinno to działać.
Product Owner powinien posiadać dogłębną wiedzę o produkcie, którym się zajmuje i zarysować cały kontekst w ramach zadania, ale wiadomo, iż skupia się on raczej na części biznesowej.
Dlatego, w momencie gdy dostajemy od PO taska, to dostajemy tak naprawdę problem biznesowy do rozwiązania. I tutaj należy pamiętać, iż nie każdy problem biznesowy rozwiążemy dzięki kodu.
Co powinniśmy zatem zrobić, by mimo wszystko zrealizować ten task?
Musimy wysłuchać klienta, aby lepiej zrozumieć problem, z którym do nas przychodzi. Zadać mu pytania, które pozwolą doprecyzować, które pozwolą zdobyć nam cały kontekst i, które zarysują nam w głowie pewien techniczny obraz tego, co będzie potrzebne do realizacji tego zadania.
Kontekst w tym przypadku jest bardzo ważny, bo od niego zależy, czy to co zrobimy będzie jedynie małym featurkiem na trzy story pointy, epikiem czy w ogóle nowym modułem.
Niestety, w takich sytuacjach często jest tak, iż programiści olewają ten aspekt pracy z klientem. Dostają taska, klepią go jak najszybciej, wrzucają na review, do testów i po sprawie. A to, iż potem się okazuje, iż nie spełnia to oczekiwań biznesu albo (co gorsze) technicznie nie jest to wykonalne to jest już wina PO, bo to on zrobił takiego taska.
Z drugiej strony, o co częściej klienci powinni pytać zleceniobiorców?
W sytuacji, kiedy zlecam komuś wykonanie zadania to chcę mieć pewność, iż dana osoba na pewno zrozumiała to, co jest do zrobienia. Wystarczy zadać 2-3 pytania, by mieć pewność, iż dana osoba rozumie, co jest do zrobienia lub dowiedzieć się, iż tak naprawdę nic nie rozumie i w ogóle nas nie słuchała. Podejrzewam, iż podobnie jest z klientami.
W jaki sposób dowiedzieć się, czego tak naprawdę potrzebują?
Klient nigdy nie wie, czego potrzebuje konkretnie – tym bardziej, jeżeli nie jest to klient techniczny. Klient ma pewien problem. Pewnie od kogoś usłyszał, iż powinien znaleźć programistę, bo programista napisze mu aplikację, która rozwiąże ten problem i jeszcze wiele innych. No i Klient przychodzi do programisty.
Często się jednak okazuje, iż ten jeden problem można rozwiązać w zdecydowanie inny sposób i tutaj ukazuje się, jak dojrzały jest programista. Jeden weźmie zadanie, wyceni, zrobi i “skasuje” klienta, a drugi najpierw porozmawia, upewni się, iż dobrze rozumie ten problem i dopiero wtedy zasugeruje pewne rozwiązanie.
Dlaczego to takie ważne? Bo często to, czego potrzebują nasi klienci to arkusz Excela – wydaje mi się, iż 90% mniejszych biznesów można prowadzić z wykorzystaniem tego narzędzia lub podobnych, które są już dostępne w Internecie. Ewentualnie możemy pomóc w automatyzacji pewnych, specyficznych procesów. Nie ma tutaj programowania…
Bardzo lubię iteracyjnie podchodzić do rozwiązywania problemów. Wspólnie z klientem zastanawiamy się jakie będzie najprostsze możliwe rozwiązanie, które będzie działać już dzisiaj. Sprawdzamy, czy to wystarczy. o ile tak to super – klient jest zadowolony. jeżeli nie to siadamy do dalszych rozważań i szukamy czegoś większego. Dopiero na końcu tak naprawdę decydujemy się na stworzenie czegoś nowego. Ale wtedy i jedna, i druga strona dobrze rozumie, dlaczego podjęliśmy taką a nie inną decyzję.
Co utrudnia komunikację z klientem?
Tutaj moim zdaniem największym problemem jest brak umiejętności słuchania drugiej osoby – zarówno w jedną i w drugą stronę.
Często spotykałem się z sytuacją, iż moje pytania pogłębiające były ignorowane albo sprawiałem wrażenie osoby, która czepia się o wszystko. Klient nie chciał słuchać, bo miał już w głowie swoje rozwiązanie i szedł bardzo mocno w zaparte.
Z drugiej strony spotykałem się z sytuacją odwrotną, kiedy to na przykład delegowałem zadanie, starałem się wytłumaczyć wszystko dokładnie, ale w rezultacie i tak dostawałem nie to czego chciałem.
Inną umiejętnością, która moim zdaniem bardzo pomaga (a jej brak przeszkadza) w komunikacji z klientem to umiejętność “wejścia w buty” drugiej osoby. Bardzo mało osób próbuje zrozumieć drugą osobę – zrozumieć sytuację, w której aktualnie się znajduje. Często bywa tak, iż to klient wie tak naprawdę dlaczego potrzebuje rozwiązać ten problem, w taki a nie inny sposób.
I pomimo tego, iż wyżej powiedziałem, iż klient miał już gotowe rozwiązanie i szedł w zaparte, bo nie chciał słuchać – może w tamtej sytuacji to ja popełniłem błąd, bo nie spróbowałem wystarczająco dobrze zrozumieć jego sytuacji.
Jak widać to jest bardzo trudne – nie ma narzędzi, które jednoznacznie powiedzą czy z tym klientem mamy rozmawiać w taki albo w inny sposób. To wszystko zależy od naszej empatii. Ktoś kto nie ma empatii albo ma jej mało, może nie poradzić sobie w tym biznesie.
W jaki sposób organizujesz swoją pracę z klientem? Z jakich narzędzi korzystasz, jak układasz harmonogram prac?
Jeżeli pytasz o narzędzia, które wyciągną z głowy klienta to co naprawdę myśli to jeszcze takich nie ma (chyba).
Co prawda istnieje kilka technik, które pozwalają to osiągnąć, ale szczerze mówiąc to jakoś się tym nie interesowałem. U mnie jest to po prostu naturalne, iż jak rozmawiam z drugą osobą to staram się zrozumieć jej sytuację.
Staram się zadawać pytania o różne aspekty. choćby czasem sięgam po pytania, które dotyczą życia prywatnego, tego czy dana osoba ma rodzinę, czy ma dzieci, w jaki sposób pracuje, co lubi a czego nie lubi. Może wyda się to trochę kontrowersyjne, ale głęboko wierzę, iż osoby, które mają dzieci funkcjonują inaczej niż osoby, które dzieci nie mają (wiem, bo mam dwójkę małych urwisów). I na przykład wiem, iż taka osoba sobie bardziej ceni swój czas, więc priorytetem takiej osoby będzie wypracowanie rozwiązania, które ten czas zaoszczędzi. Albo na przykład takiego, które będzie w stanie obsługiwać jedną ręką, drugą karmiąc swoje dziecko.
Dlatego tak istotny jest dla mnie dogłębny wywiad. Pomaga to też w trochę innym aspekcie – nasza relacja jest bliższa. W takim momencie przestaje być formalna, więc często też mogę uzyskać więcej informacji, bo ktoś nie boi mi się zaufać.
Spotkałem się na przykład kiedyś z sytuacją, iż przyszedł do nas klient, który chciał żebyśmy pomogli mu stworzyć dla niego aplikację. No i wyobraź sobie, iż od samego początku zasłaniał się NDA – iż powie nam więcej jeżeli zgodzimy się na podpisanie umowy.
Całkowicie rozumiem to podejście, natomiast w moim przypadku zapaliły się dwie żółte lampki. Pierwsza, która dotyczyła braku zaufania już od samego początku – a to wiąże się z problemami później. Oraz druga, która jest bardziej związana ze mną. Lubię pracować w projektach, które, mówiąc kolokwialnie, mnie kręcą. Więc od klienta oczekuję, iż w czasie pierwszej rozmowy przekona mnie do swojego pomysłu dzięki czemu uwierzę w to rozwiązanie. Wierzę po prostu, iż w takiej atmosferze lepiej się pracuje.
Podczas rozmowy z Klientem zapisuję istotne informacje, które mogą potem pomóc na dalszym etapie współpracy.
Co do harmonogramu to już tak naprawdę zależy od współpracy. Natomiast moi klienci wiedzą, iż dla mnie ważne są cotygodniowe spotkania, w czasie których się wyrównujemy i ustalamy plan na następny tydzień, więc nie ma tutaj jakiegoś wielkiego harmonogramu. Ale tak jak mówię, nie z każdym klientem tak się da pracować, więc to co u mnie działa nie zawsze sprawdzi się w innym przypadku.
Na koniec opowiedz o swoim podejściu do szacowania czasu i pracy potrzebnej na realizację projektu dla klienta. Jak do tego podchodzisz?
W miarę możliwości staram się unikać podawania konkretnego terminu. Praca nad projektem, w szczególności, gdy staram się podchodzić do projektu holistycznie oraz elastycznie, jest na tyle nieprzewidywalna, iż często ciężko wyestymować, ile konkretnie zajmie realizacja tego przedsięwzięcia.
W zamian za to, proponuję moim klientom cotygodniowe spotkania, w trakcie których wyrównujemy się i sprawdzamy postęp prac. Bardzo mocno wierzę w zasady ruchu “Agile”. W trakcie takich spotkań często wychodzą rzeczy, co do których nie byliśmy świadomi na początku. Często bywa tak, iż zmienia to również to, jak będzie wyglądał finalny projekt.
Takie spotkania służą obu stronom – zarówno klientowi, ponieważ wie jaki jest aktualny stan projektu, jak i mnie, ponieważ uzyskuję natychmiastowych feedback do tego, co zrobiłem. Możemy więc wprowadzać zmiany na biężąco.
Uważam, iż w naszej pracy transparencja jest bardzo istotna. Projekty potrafią się rozrosnąć bardzo szybko, przez co może się zdarzyć taka sytuacja, iż termin z umowy zostanie przekroczony. W tej sytuacji, transparencja i dobrze zbudowana relacja z klientem bardzo pomaga. Razem podejmujemy decyzję o przedłużeniu terminu oraz o ewentualnym dostosowaniu budżetu.
Damian Kryger. Współzałożyciel Business Coders. Jego przygoda z programowaniem zaczęła się lata temu i zaprowadziła przez różnorodne firmy produktowe i software house’y. W tym czasie zrozumiał, jak ważne jest łączenie umiejętności kodowania z mocnym i kompetentnym zespołem – to właśnie ta kombinacja tworzy magiczne produkty cyfrowe.
