W tym odcinku przedstawiam historie i obserwacje związane z komunikacją w projektach IT.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 34 – O komunikacji w projektach IT słów kilka, część pierwsza. Na łamach naszego podcastu gości ponownie odcinek dwuczęściowy, bo gdy wpadłem na ten pomysł i zacząłem szykować materiały, to bardzo szybko okazało się, że w jednym odcinku po prostu się nie zmieszczę. A temat tego odcinka, a w zasadzie tego właśnie i następnego, wziął się, można powiedzieć, nie bez przyczyny. Zebraliśmy bowiem rozmaite przypadki, case’y z różnych wyzwań komunikacyjnych, jakie przez ponad 12 lat funkcjonowania Makimo zdarzyło nam się po prostu mieć. I inspiracją do tego odcinka było wystąpienie Darii Grochowskiej, naszej PM-ki, a także osoby odpowiedzialnej za działania na socialach, w tym związanych właśnie z tym podcastem. Pozdrowienia Daria. I również wystąpienie z moim udziałem na konferencji PM², Project Management, Pro Mastery – Ways of Agile, organizowanej przez PMI Poland Chapter Łódź, gdzie mieliśmy okazję właśnie przedstawić takie najciekawsze przypadki, a że bardzo dużo ich się zebrało, to stwierdziliśmy, że szkoda byłoby zmarnować materiał, i tak powstał właśnie ten odcinek, a w zasadzie ten i kolejny.

Zacznę od tematu takiego dość oczywistego, przyjemnego, który pojawiał się już z tego, co pamiętam, na łamach podcastu, a mianowicie używaniu Lingo slangu, czy też mówiąc wprost, słownictwa branżowego, jeżeli te dwa pierwsze słowa nie były zrozumiałe, które to słownictwo używa się czasem w komunikacji z klientami. Nie każdy programista, nie każda programistka musi się z tym mierzyć od razu, ale prawda jest taka, że prędzej, czy później dochodzi do takiej sytuacji, w której osoba będąca właśnie osobą techniczną, już tak to nazwijmy ogólnie, musi zmierzyć się z osobą, która tej wiedzy technicznej, doświadczenia po prostu nie posiada. Nie mówię tu jednocześnie o takich sytuacjach, gdzie w zespole jest na przykład obecny kierownik projektu, PM, czy też na przykład nietechniczny Scrum Master, bo nawet jeżeli to są osoby, które można powiedzieć, same nie programowały, nie mają mocnych podstaw technicznych, to jednak są one z reguły z tym słownictwem dużo bardziej oswojone. Problem pojawia się wtedy, kiedy po drugiej stronie stołu zasiada po prostu klient, pracownik klienta, czy osoba z zarządu, właściciel firmy, ktoś, kto albo wykłada tą realną gotówkę na stół, albo przynajmniej ma wpływ na, można powiedzieć, to wyłożenie. I tutaj mam taką historię. Kiedyś w trakcie spotkania na temat rozwoju aplikacji mobilnej, tutaj zaznaczę, że to nie była jakaś rozmowa sprzedażowa, to już projekt się toczył i toczył się w sumie dość dobrze, było wzajemne takie porozumienie z obu stron. Natomiast właśnie projekt zbliżał się powoli do końca i na pytanie ze strony klienta, co dalej, jeden z kolegów, już tak trochę ciesząc się po prostu, że faktycznie jeszcze kilka kroków i projekt będzie skończony, tak z rozpędu stwierdził tylko, że zdeployujemy betę na sandboxie, jakoś tak mniej więcej szło. Klient pokiwał głową, nie dał po sobie poznać, że było to takie wyrażenie cokolwiek niezrozumiałe. Ale dla pewności ja jednak postanowiłem jeszcze troszkę rozwinąć to i stwierdziłem, że umieścimy wersję do testów w środowisku demonstracyjnym. Też nie powiedziałbym, że to jest takie w pełni zrozumiałe sformułowanie, no środowisko, trzeba wiedzieć, ale już ten klient też był troszkę przez nas wyedukowany. Ale po tym stwierdzeniu wszystko stało się jasne, udało się wyjaśnić, co właściwie się wydarzy.

Tego rodzaju sytuacja nie jest absolutnie żadnym problemem, jest to właściwie, można powiedzieć, taki materiał na anegdotę, że nie był to żaden problem. Natomiast zdarzają się sytuacje trochę pokrewne, które już potrafią wygenerować o wiele większe problemy. Chodzi o sytuacje, kiedy klient ma pewną wiedzę techniczną, ale mówiąc wprost, nie do końca prawidłową. Zdarzyło mi się rozmawiać z takim prospektem, perspektywicznym klientem, on w końcu tym klientem nie został. Natomiast ten klient na dowolną część systemu, która działała po stronie serwera, czyli można powiedzieć back end, ten klient mówił, że jest to baza. Nie chodziło tu stricte o silnik bazy danych, system bazy danych, taki jak MySQL, czy Oracle. Natomiast oczywiście, kiedy pierwszy raz to usłyszałem, stwierdziłem, że jakby samo w sobie to jeszcze o niczym nie świadczy, trzeba sobie zapamiętać na przyszłość, jak ten klient będzie opowiadał o swoich pomysłach, żeby to w ten sposób interpretować. Natomiast niestety w tym przypadku była to zapowiedź troszkę większych problemów komunikacyjnych, bo nie była to jedyna nieścisłość. Klient miał dość specyficzne wyobrażenie na temat tego, w jaki sposób system, aplikacja webowa powinna działać. I tutaj trochę właśnie żałowałem, że gdyby to był klient paradoksalnie zupełnie nie znający się na tematyce tworzenia aplikacji, to można byłoby go wyedukować we właściwy sposób. Natomiast niestety, kiedy już te pewne okruchy wiedzy zostały umieszczone, znalazły się w głowie klienta, miał on, można powiedzieć, takie przeświadczenie, że on wie, co to jest baza, więc on już całkiem dobrze zna się na IT i nie da sobie kitu wcisnąć. I tak naprawdę to jest właśnie najgorsza sytuacja, jeżeli klient wie coś, wie trochę, trochę się orientuje w tym, jak działają systemy IT, ale nie do końca, a jednocześnie tą swoją wiedzę, to swoje doświadczenie bardzo wyolbrzymia.

To jest trochę tak, jak z tym memem, gdzie jest pokazany cennik usług w warsztacie motoryzacyjnym, chyba już nawet o nim kiedyś wspominałem, i jest tam jakiś koszt usługi, po czym są warianty, że koszt usługi, kiedy klient obserwuje, koszt usługi, kiedy klient komentuje. I oczywiście cały czas ten koszt rośnie, aż w końcu klient próbuje naprawić sam, pod obserwacją pracownika warsztatu. To już jest w ogóle najgorszy wariant, najdroższy też dla klienta. I tutaj jest to sytuacja analogiczna. Klient, który opiera się na częściowej wiedzy i wie lepiej, zawsze będzie problemem, nieważne czy chodzi o wymianę opon, rozrządu, czy o stworzenie aplikacji webowej.

Lepszą sytuacją jest ta, w której klienta można sobie, w pewnym sensie wyedukować, ukształtować, bo wtedy taki klient po prostu będzie lepiej współpracował. A jeżeli mówimy tutaj o takich rzetelnych relacjach z dostawcami, to taki dostawca, edukując porządnie klienta, może przysłużyć się, mówiąc wprost, też reszcie  branży. A ja tak prywatnie, mając świadomość takiej sytuacji, kiedy jestem w warsztacie, to nie staram się komentować, staram się raczej unikać wszelkich jakichś sugestii z mojej strony, chyba że jestem wprost zapytany o jakąś decyzję, ale też często zdaje się na pomoc pracowników zaufanego warsztatu.

Jak widać jesteśmy dopiero po pierwszym przykładzie. Ja sobie w notatkach zahaczyłem, że to miał być raczej przykład krótki, a rozgadałem się całkiem nieźle, więc chyba nie dziwi, że tutaj faktycznie te dwa odcinki okazały się konieczne. Kolejnym tematem, którym chciałem się zająć jest taki, naszym zdaniem, ważny warunek skutecznej komunikacji, zwłaszcza właśnie w kontekście IT, jest to takie czytelne postawienie pewnych zasad, określenie tego, co się da zrobić, i czego się zrobić nie da. Wiele z problematycznych historii, których już też wszystkich nie będę poruszał tutaj, ale tak zbiorczo o nich wspomnę, wzięło się z czasów, kiedy pracowaliśmy raczej jako podwykonawcy, będąc mniejszą, mniej doświadczoną firmą. Niestety często okazywało się, że główny wykonawca, z reguły jakaś większa firma, która starała się pozyskać dużych klientów, obiecywała nam po prostu złote góry. Czy też nawet jeszcze gorzej, po prostu zgadzała się na wszystko to, o co klient pytał, czyli czy da się, nie wiem, w systemie wbudować taką funkcję? Oczywiście, że się da. Bez pytania osób technicznych. My oczywiście potem musieliśmy to wdrażać. A jak się nie dało, bo na przykład opracowywaliśmy technologię do komunikacji audio-video w czasie rzeczywistym na urządzenia mobilne, ale ponad 10 lat temu, to klient już przestawał być taki zadowolony. W tamtych czasach akurat tematyka transmisji audio-video na nie aż tak mocnych jeszcze smartfonach wcale nie była kwestią prostą i wiele ograniczeń było dosyć, bym powiedział, odgórnych. Nie wynikało z naszego lenistwa, czy braku budżetu, tylko po prostu pewnych rzeczy osiągnąć się nie dało. I brak tych konsultacji między sprzedażowcami, a nami naprawdę generował dużo problemów w realizacji projektu. Dopiero lata później dowiedzieliśmy się, że tak naprawdę to klient nie gryzie, trzeba tylko przestrzegać jednej prostej zasady. Chciałoby się rzec, jak w tych reklamach internetowych, naukowcy nienawidzą go, odnalazł jedną prostą zasadę, natomiast ta zasada to po prostu: unikajmy obiecywania tych złotych gór, określajmy oczekiwania realistycznie. Naprawdę wiele tych rozmów wstępnych z klientami przeprowadziłem, i gdy klient widzi, że po drugiej stronie jest partner, jest osoba kompetentna, która rzetelnie opowie o tym, co się da zrobić, czego się nie da zrobić, ewentualnie co może być na przykład bardzo drogie i nieefektywne, to od razu to w taki dość pozytywny sposób ustawia relację. A jeżeli osoba, ten klient potencjalny zrezygnuje po takiej szczerej opinii, szczerej sugestii, to może to i lepiej. Może tak właśnie powinno być, że nie powinniśmy brać wszystkich tematów, wszystkich deal’i. Często spotykam się z tym, że wśród właśnie sprzedażowców trzeba brać każdego klienta, trzeba nie odpuszczać. Ja jestem trochę innego zdania.

Jedna z ciekawszych historii, i tutaj może akurat tematu nie odpuściliśmy, wręcz przeciwnie, ale właśnie, postawiliśmy realistycznie oczekiwania, wiąże się z tym, jak zaczęła się nasza przygoda w świecie e-learningu. Jak często wspominam, oczywiście na łamach podcastu moja wiedza, moje doświadczenie bierze się z naszej pracy w Makimo przede wszystkim, gdzie zajmujemy się tworzeniem głównie oprogramowania dedykowanego, czyli szytego na miarę, robionego często, jak to się mówi, od podstaw. Natomiast ładnych kilka lat temu, tak chyba z pięć będzie już, odbyłem ciekawą rozmowę, która sprawiła, że zacząłem myśleć o oprogramowaniu w zupełnie inny sposób. Rozmawiałem wówczas ze swoją dobrą znajomą, która potrzebowała wdrożyć u siebie rozwiązanie właśnie do e-learningu. Były jednak dwa problemy: budżetowy, był określony budżet, było jakieś dofinansowanie i trzeba było się w nim zmieścić. Co prawda, ten budżet był trochę mały, natomiast to nie on był największym problemem, bo był też budżet czasowy, było ograniczenie czasowe, bodajże tam były 3 miesiące. Kiedy usłyszałem, co jest do zrobienia, stwierdziłem, że nie da się tego zrobić, nie da się tego zrobić oprogramowaniem dedykowanym. Natomiast zacząłem myśleć z tą swoją znajomą o rozwiązaniu problemu. Oderwałem się w ogóle od oprogramowania dedykowanego. I jak to się często mówi, nie przepadam za tą frazą, ale myśląc out of the box, spoza pudełka, stwierdziłem, że jest przecież taka platforma e-learningowa Moodle, którą znałem najpierw jako student, a potem jako wykładowca jednej z łódzkich uczelni, gdzie po prostu korzystałem z tego narzędzia, wrzucałem materiały studentom, oni sobie mogli je pobierać. Nie znałem go dobrze od tej strony takiej biznesowej, w jaki sposób można je wdrożyć, ale jednak jakaś tam wiedza administracyjna była. I historia oczywiście trochę się toczyła, natomiast po wprowadzeniu pewnych modyfikacji, pewnych rozszerzeń fragmentu oprogramowania dedykowanego, ale przede wszystkim od razu komunikując się, co można zrobić w tym Moodle’u, czego nie można, co ewentualnie możemy dobudować jakby ponad tym Moodle’m, okazało się, że zmieściliśmy się w budżecie, zmieściliśmy się też w czasie, co nawet ważniejsze. I koniec końców projekt okazał się być wdrożonym po prostu prawidłowo, skutecznie i z sukcesem.

Na tym kończę ten odcinek, a w zasadzie tę część tego dwuodcinkowego mini cyklu. Jak widać pomysły na historie są często krótkie, ale jak już się rozgadam, to niestety, a może stety trochę czasu to zajmuje. Jeżeli chcesz podzielić się jakimś swoim komunikacyjnym sukcesem, bądź też porażką, to daj znać, zachęcam do wypowiadania się w komentarzach, ewentualnie w pisaniu na priv. Na dziś już kończę, bardzo dziękuję za uwagę, kłaniam się nisko i do usłyszenia!

KONIEC