3 błędy przy komunikacji z „biznesem”

W ostatnich miesiącach w pracy mocniej poszedłem w stronę rozmów z klientem i prowadzenie zespołu programistów. Z resztą od zawsze w obecnej firmie mamy bezpośredni kontakt z ludźmi od klienta. Nie tylko tymi technicznymi. I im więcej w tym siedzę i obserwuję różne reakcje i rozmowy tym więcej widzę powtarzających się problemów naszej komunikacji z osobami, które raczej zajmują się wymaganiami biznesowymi albo są po prostu użytkownikami.

Podobne listy przewijają się co jakiś czas w internecie. Sam przynajmniej kilka razy spotkałem się z podobną, czy to gdzieś na blogu czy w jakimś podcaście.

1. Szukamy problemów

Coś co nie tylko regularnie rzuca mi się w uszy, ale też sam popełniałem i nadal czasami popełniam. Chodzi o to, że kiedy osoby od wymagań pytają nas czy jakaś funkcja będzie mogła być zrobiona praktycznie od razu przechodzimy do dyskusji co będzie ciężkie do zrobienia, co może się nie udać, gdzie będzie dużo roboty itd.

I mimo, że pod spodem cały czas mamy w głowie, że oczywiście taką funkcję zrobimy to jednak od razu straszymy biznes wszystkimi potencjalnymi problemami.

Oni nas wynajmują do rozwiązywania problemów (nawet jak pracujemy nad wewnętrznym produktem), a nie wymieniania wszystkich jakie jesteśmy w stanie sobie przypomnieć. Bo to w żaden sposób nie przybliża ich do odpowiedzi na pytanie czy to co wymyślili da się zrobić. I nie zajmie to roku czasu. A to jest najważniejsze.

Moja rada jest taka, że na pytanie czy da się coś zrobić odpowiedz, że da się (jeśli jesteś pewien) i ile czasu to zajmie. Albo powiedz, że potrzebujesz x czasu na sprawdzenie czy na pewno da się to zrobić w sensownym czasie i wrócisz za x+1 czasu z odpowiedzią (która też powinna być zwięzła i nie nastawiona na wymienianie problemów). Zdziwisz się, że osoba po drugiej stronie najpewniej to po prostu zaakceptuje, bo ufa, że wiesz co mówisz. Albo zapyta dlaczego tyle czasu potrzeba. Wtedy wymień co może sprawdzić kłopot. Ale jeśli jesteś w stanie podać alternatywę, która np. pozwoli oszczędzić czas chociażby używając gotowej aplikacji, z którą się połączycie, to zrób to od razu w tym momencie. Ostatecznie biznes zaakceptuje podany czas i argumenty bądź nie, ale za to będziecie operować językiem, który dla niego jest ważny.

2. Mówimy zbyt technicznie

Spotkanie związane z nowymi zadaniami. Na sali programiści, analitycy, może jakiś użytkownik. Pojawia się pierwsze zadanie związane z dodaniem pola w formularzu. I ze strony programistów zaczyna się rozmowa… Bo to trzeba będzie SQLa poprawić. A bo tam pewnie ten token można zmienić. Może jakaś biblioteczka do walidacji tego pola się znajdzie? Style chyba będą potrzebować zmiany. I tak dalej, aż wszyscy poza wami przejrzą już wszystkie strony w internecie i w końcu powiedzą, że może przejdziemy do kolejnego punktu i to omówimy potem.

Znasz takie sytuacje? Jestem prawie pewien, że tak. Tylko niekoniecznie jesteś jej świadomy. Bo dla nas jest to naturalne. I zadanie biznesowe od razu w głowie mapujemy na zadania w kodzie. Tylko, że nie o tym jest teraz mowa i gwarantuję Ci, że reszta osób maksymalnie po drugim zdaniu przestanie Was słuchać i zacznie myśleć o przerwie. Bo dla nich to nic nie znaczy. Tak samo jak dla Was nic by nie znaczyła rozmowa o jakichś wskaźnikach i badaniach rynku, które można zrobić jak będą wymyślane kolejne zadania kiedy ktoś z biznesu by zaczął o tym rozmawiać w tym momencie.

Jeszcze częściej podobne rozmowy można trafić na spotkaniach związanych z postępem prac. Gdzie są na nich też osoby nietechniczne. Zamiast powiedzieć, że dodaliśmy ten przycisk i teraz można zapisać dodatkowe pole w formularzu zaczynamy wyliczać – zmieniliśmy tabelę, przepisaliśmy kawałek klasy, CSSy trochę musieliśmy zmienić, itd.

A pytaniem było czy użytkownik może już zapisać dodatkowe pole. Czy jednak potrzebujecie na to jeszcze trochę czasu. Tylko tyle i aż tyle. Bo nie zawsze ostatecznie na to pytanie udzielimy odpowiedzi…

3. Nie komunikujemy korzyści

Ostatni punkt trafia się zwłaszcza w sytuacji kiedy to my chcemy coś narzucić. Najczęściej dotyczy to jakiegoś refactoringu, zmiany w konfiguracji albo innych kwestii technicznych.

Na spotkaniu proponujemy, że wprowadzimy nową bibliotekę, musimy przepisać jakiś kod albo pracujemy nad wyczyszczeniem klas z nieużywanych fragmentów. Fantastycznie! Tylko, że mówiąc w ten sposób nasz klient jedyne co słyszy to „wydajemy niepotrzebnie pieniądze żeby programiści się bawili w kodzie”.

Oburzysz się teraz i powiesz „ale przecież bez tego zaraz nie będzie się dało nic zrobić!”, „ta biblioteka zwiększa bezpieczeństwo!”, „im mniej kodu tym łatwiej nam szukać błędów!”. Świetnie, że to wiesz! Teraz niech dowie się o tym też klient. Wtedy przestanie myśleć o niepotrzebnych wydatkach.

Bo tak jak świetnie i praktycznie od początku rozmowy potrafimy mówić co może pójść nie tak i co będzie trudne tak nie myślimy o tym, żeby powiedzieć co właściwie z tych naszych pomysłów wynika. I w takim przypadku biznes zgodzi się raz, może dwa razy na refactoring albo pisanie jakichś testów lub podmianę biblioteki. Ale tylko po to żebyśmy przestali marudzić na chwilę. Ale jeśli powiemy mu co on będzie z tego miał to rozmowa będzie zupełnie inna. Bo będziemy mówić tzw. językiem korzyści, który świetnie sprzedaje pomysły. W marketingu, który też poznaję od jakiegoś czasu, już to dawno odkryli.

A jeśli w tym miejscu nie potrafisz znaleźć korzyści dla biznesu to warto się zastanowić po co tak naprawdę chcecie jakąś zmianę wprowadzać. Czy nie jest to przypadkiem „CV Driven Development” albo „Hype Driven Development”?