O komunikacji dev-biz

Komunikacja dev-biz. Podejrzewam, że to jeszcze ktoś z PGS-ów tak mnie zainspirował, a może z mojej pracy w bankach. No i teraz zrzutmy, jeśli jest następujący. Która ze stron powinna się dokształcić? Ponieważ tytuł podcastu jest komunikacja, ale tam był komunikacja dev-biznes, dlatego też pojawiają się strony. Która ze stron jest bardziej odpowiedzialna za dobrą komunikację? Która ze stron powinna... której ze stron powinno zależeć na dogadaniu się? Jak się dogadać? Gdzie mogą być problemy? Co z tego może wynikać, z tych problemów? No i takie... jak żyć. Jak żyć. To wtedy było popularne chyba, jak żyć, tak? Bo wtedy była faza, że... Panie premierze, ja się na to wciągę, bo tutaj nie wymieniliśmy jeszcze jednego ojca chrzestnego, bo Jerzy Łukasz na Instagramie też dorzucił takie grupy myśli, to je później mogę przeczytać.

Aha, dobra. Możemy też tutaj, że będziemy udowadniać, który z nas jest lepszy. Chyba tak rozumiem ten komentarz. Dobra, to co, no to okej, wyjaśniłeś co tutaj, to na pierwsze mamy tak, która ze stron powinna się dokształcić. Tak, no i właśnie, czy dev, no właśnie, no i to z czemu. Znaczy, tak, jeśli chodzi o dev, Stronę wydaje mi się dobrze dokształcić. Zakładamy, że nie jest dokształcona, bo możemy założyć, że tak jakby to nie jest problem. Może inaczej. Mamy taki problem, że strona techniczna, nie musi być to dev, nie może się skomunikować dobrze ze swoją stroną biznesową. I teraz pierwszy z tych problemów może być taki, taka kłoda może być, że my nie do końca rozumiemy, co oni do nas mówią.

Ja bym nawet chciał, bo tak jak mówię, są plusy tego. Natomiast z drugiej strony nie chciałbym, wiesz, że nie mogę użyć jakiegokolwiek słowa technicznego, bo ktoś, wiesz, piśnie i zrobi tak aaaa, jak takie słowo użyję. Więc ja bym powiedział, że pośrodku z lekkim może przechyłem na, że może tech się powinien dokształcić. O ile tak jakby, wiesz, jest w ogóle taka potrzeba, bo może od razu jest na takim etapie, że okej, tak, ja się chcę dokształcić, tak. Nie wiem, czy już chwilę potrzebujemy. Nie, nie, nie, spoko. Znaczy, ja miałem taką prezentację kiedyś, dev i biznes na Żabach.

No ale gdzie dev-biz, gdzie tu jest? Tu jest Człek Człek. Człek Człek. Human-to-human interface, tak? No tak. Znaczy, no trochę się zgadzam. Chciałem właśnie powiedzieć, że ostatnio miałem jakieś tam zapytania na LinkedInie i nawet dostałem takie post-zapytanie, jak już odmówiłem, że dlaczego odmawiam. I musiałem wypisać dlaczego. I bo oni... Hej GPT, podaj mi kilka dobrych powodów, że tylko odmawiam w pierwszej pracy. Miałem, miałem. Znaczy akurat... Akurat, że tak powiem, w tej ofercie miałem powody, żebym jej nie chciał, więc powiedziałem takie powody. I akurat była praca w jakichś tam konkretnych godzinach, od tej do tej. Ok. Na przykład, nie tylko to.

Mówił też i inni z boteki, że dev powinien umieć wskazać dziury, błędy w pomysłach biznesu grzecznie, tak by się biznes nie obraził. Dopiero w obecnej firmie w praktyce zobaczyłem, jak zespół dev wypytuje klienta wewnętrznego, czemu ma służyć dana funkcja czy przycisk, jaka się za tym kryje rzeczywista potrzeba, co klient chce zrobić lub osiągnąć. To myślę, że tak dość spójnie z tym, co już mówiliśmy dzisiaj, aczkolwiek przypomniał mi się, że chyba właśnie widziałem jedną prezentację, był tam Sławek i ktoś jeszcze i to był chyba taki sketch, że właśnie odgrywają rolę, że jeden jest z biznesu, drugi jest z technicznej i sobie tam właśnie gadają, że ja tu chcę tego feature'a, a tu za trzy tygodnie panie coś tam.

Ale żeby tak było, to dev powinien w głowie zamienić sobie problem techniczny na pytanie biznesowe, analityczne. Ale to wymaga właśnie dokształcenia z komunikacji i słuchania. Biznes jest zabezpieczony umową. Jak im nie zrobimy tego, co chcieli, to będą wyciągali konsekwencje. A jak my nie będziemy chcieli zrozumieć i posłuchać, co mamy zrobić, to my będziemy siedzieli do skutku i poprawiali i narzekali, aż zrobimy albo zaczniemy kontynuowanie kariery poza strukturami firm. Ok, faktycznie podobne tony. Tak, aczkolwiek tu chciałem powiedzieć, że ta zamiana tego technicznego na biznesowy może być dość trudna. Tutaj to, co Marek napisał, że powinien sobie dopytać, jeżeli coś tam jakiś widzi problem techniczny, to powinien dopytać, ale biznesowo.

W sensie, że nie czy na przykład mogę w tabelce sobie składować dane jakoś tam inaczej, Tak, tylko jakoś to faktycznie przełożyć, zapytać, no a jak te dane będą, nie wiem, zduplikowane z jakimś tam innym widokiem, to czy to będzie problem? No coś takiego, nie wiem, teraz wymyślam i macham rękami. Aczkolwiek tutaj chciałem to, co chciałem w tym wcześniejszym komentarzu zapytać, jak to faktycznie wygląda. To mnie ciekawi, że tutaj napisał, że dopiero w obecnej firmie w praktyce zobaczymy, jak zespół dev wypytuje klienta, czemu ma służyć dana funkcja, czy przycisk jakiś się za tym kryje. Jak to wygląda? Ciekawi mnie tak, że jak to faktycznie musi, z tego komentarza zrozumiałem, że musi Dość inaczej wyglądać niż w poprzednich.