Nie każdy problem biznesowy rozwiążemy za pomocą kodu. Wywiad z Damianem Krygerem

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, że 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 nawet jeśli pracują to wiadomo jak jest – atmosfera jest fajna, więc czujemy się częścią firmy nie pamiętając, że jednak cały czas pracujemy dla klienta a nie dla pracodawcy.

Dlatego wyobraźmy sobie, że 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, że 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ć, że nie każdy problem biznesowy rozwiążemy za pomocą 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, że 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, że potem się okazuje, że 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ść, że dana osoba na pewno zrozumiała to, co jest do zrobienia. Wystarczy zadać 2-3 pytania, by mieć pewność, że dana osoba rozumie, co jest do zrobienia lub dowiedzieć się, że tak naprawdę nic nie rozumie i w ogóle nas nie słuchała. Podejrzewam, że podobnie jest z klientami.

W jaki sposób dowiedzieć się, czego tak naprawdę potrzebują?

Klient nigdy nie wie, czego potrzebuje konkretnie – tym bardziej, jeśli nie jest to klient techniczny. Klient ma pewien problem. Pewnie od kogoś usłyszał, że 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, że 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ę, że 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ę, że 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. Jeżeli tak to super – klient jest zadowolony. Jeśli 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ę.

Oferty pracy z