Dziarski Dev

Jak pomóc sobie i ludziom z biznesu w osiągnięciu ich celów?

Krzysztof Baranowski

10 lip 2023 • 4 min read

Siema! 🫡

Z pewnością ludzie w IT dzielą się na dwa typy: tych technicznych i tych mniej lub bardziej nietechnicznych. Jest całkiem spore prawdopodobieństwo, że Ty należysz to tej pierwszej grupy.

Zgodnie z tytułem dzisiaj pogadamy o tej drugiej mniej technicznej ekipie, czyli o tym mitycznym biznesie i o tym, w jaki sposób powinieneś prowadzić z nimi rozmowy, aby wszystko działało picuś glancuś!

Bo chodzi o to, że obie te grupy pracują nad tym samym – nad produktem. Problem w tym, że obie korzystają z innego języka na co dzień, ale muszą razem współpracować. Ty mówisz językiem technicznym a ONI tym innym ogólnym i czasami udają, że wiedzą.

Dobra cała na biało wchodzi Klotylda z produktu. Dzień dobry. 👋

Co musisz założyć?

Że jak Klotylda cię kompletnie nie zrozumie, kiedy na jej pytanie:

"Jak działa u nas w apce obsługa notyfikacji o nowych zamówieniach?

Odpowiesz:

Mamy serwajs do obsługi mesedży z kolejki. W klasie OrdersSubscription mamy event busa (tutaj Klotylda już Cię nie słucha albo udaje) i on sobie nasłuchuje na odpowiednie typy się zgadzają. No i jak przyjdzie obiekt typu NewOrder to wywołujemy serwis blalbla bla bla bla bla...

Kompletny bełkot! Już pomijam, w jakim stopniu tak skonstruowaną wypowiedź zrozumie inny developer.

Nie gadaj techniczne z osobami z produktu. Koniec kropka. Jest cholernie łatwo się zagalopować i zacząć opowiadać o technikaliach, ale to droga donikąd. Pomyśl tylko, jak byś się czuł/czuła, gdyby ekspert dziedzinowy np. znający mega dobrze tematy związane ze sztuczną inteligencją zaczął Ci sypać z rękawa o sposobach i problemach przetwarzania języka naturalnego. I mówił o Named Entity Recognition, Anaphora Resolution a na koniec poopowiadał o Natural language generation.

Może i to ciekawe, ale czy się z nim szybko i sensownie dogadasz. Średnio, co nie?

😇

No, chyba że masz to szczęście, że osoba techniczna to wtedy Francja elegancja. Masz z górki.

Zanim odpowiesz na tak zadane pytanie, zastanów się, co Klotylda chce osiągnąć.

Dlaczego ona w ogóle zadaje to pytanie?
Co chce tym osiągnąć?
Czy słowa, których użyła, mają w ogóle sens i je rozumie?

🤔

Zacznij od zrozumienia, co osoba z biznesu chce osiągnąć, zadając Ci jakieś pytanie.

Dopytuj.

Doprecyzuj pytanie Klotyldy, zadając jedno zajebiście ważne pytanie:

"A czemu pytasz?"

Serio. Czasami Klotylda sama może nie zdawać sobie sprawy, dlaczego w ogóle o coś pyta. Być może tak naprawdę szuka odpowiedzi na kompletnie inne pytanie. Więc jak zaczniesz odpowiadać bez zrozumienia źródła, to rozmowa pójdzie na śmietnik. Nikt niczego nie zyska, a wszyscy stracą swój czas.

Wejdź w buty osoby, z którą rozmawiasz. Ludzie z biznesu nie programują. Dla nich jest ważny rozwój produktu. Oni używają języka biznesu, języka funkcjonalności. Myślą, że klasa to takie pomieszczenie, a nie rodzaj struktury.

Nie wymagaj od osób z biznesu używania słów technicznych. Może to prowadzić do tworzenia np. user story nacechowanego językiem technicznym (bo gdzieś tam sobie usłyszeli, że przy notyfikacjach to serwis jest używany), który już w pewnym sensie nastawia programistę na konkretne rozwiązanie, ograniczając jego zdolności kognitywne. Swoją drogą, w user story tak jak i w rozmowach musi być używany język domenowy, funkcjonalności – język produktu.

Co Klotylda powinna jednak znać?

Jeśli Klotylda jest odpowiedzialna za rozwój produktu, to zdecydowanie powinna być świadoma procesu wytwarzania oprogramowania. To ją nie ominie. Są rzeczy, które usprawnią komunikację i po prostu ułatwią codzienność obu stronom.

Z mojej perspektywy powinna z pewnością wiedzieć o:

Czym jest branch,
O co chodzi z code review.
Co oznaczają terminy takie jak master i develop z perspektywy wydawania nowych wersji.

Oczywiście to tylko kilka z tematów, ale chcę Ci pokazać, że istnieją również rzeczy techniczne, o których istnieniu właściciel produktu (ang. product owner) powinien wiedzieć. To rzeczy, które dzieją się codziennie. Tym zajmują się programiści. Pozwoli to Klotyldzie na bardziej świadome np. planowanie nowych wydań oraz tego, co powinno się w nich znajdować oraz rozumieć, na jakim etapie ze strony programisty jest konkretne zadanie.

🚀 Pamiętaj zatem:

Nie używaj języka technicznego w rozmowie z osobami z biznesu.
Znajdź DLACZEGO osoby, która zadaje Ci pytanie. Może się okazać, że szuka czegoś innego.
Nie zakładaj, że są idiotami, którzy nie są wyedukowani. Oni po prostu zajmują się innym kawałkiem tortu. Dlatego wejdź w ich buty – zyskasz ich uznanie i zwiększysz szansę na rozwiązanie właściwego problemu.
Product Owner powinien znać się na podstawach procesu wytwarzania programowania. Jeśli tak nie jest, to zastanów się, jak możesz mu w tym pomóc.

🤔 A jak u Ciebie wygląda komunikacja z biznesem? Jest spoko, średnio czy zwyczajnie do kitu? Daj mi znać i pogadajmy.

🔥 Małe ogłoszenie. Jakiś czas temu byłem gościem Mateusza Bogolubowa z jego naprawdę popularnym podcaście "Pierwsze Kroki W IT". Pogadaliśmy o apkach mobilnych – mega przeżycie. Odcinek ujrzy światło dzienne 18 sierpnia (2023) i na pewno dam Ci jeszcze znać o premierze.

Listę odcinków i info o podcaście znajdziesz tutaj: https://devmentor.pl/bc/podcast.

🔥 Często publikuje na socialach, więc zapraszam Cię do ich obserwowania. Swoją drogą od pewnego czasu jestem dostępny na Twitterze, gdzie publikuje po angielsku. Wpadaj i korzystaj:

Do następnego! 👋