Jak skutecznie porozumieć się z programistą

Jak wspomniałem w poprzednim wpisie, jestem po technikum i studiach, więc podstawy techniczne miałem dosyć spore. Szybko uczę się nowych rzeczy i potrafię w miarę szybko rozwiązać problem, który dostaję. Stąd też moje motto. Jednak uważam, że moją największą mocną stroną jest komunikacja. Oczywiście nie jestem profesjonalnym mówcą. W sprawach czysto programistycznych również łatwo wskażę wiele osób o wyższym poziomie ode mnie. Mimo to jako jeden z najmłodszych z zespołu koordynowałem naszą pracę. Wiele razy słyszałem, że dobrze się ze mną pracuje. Od dawna szukałem przyczyny takiego obrotu spraw. Odpowiedź jest bardzo prosta. Skuteczna komunikacja to klucz do rozwiązania wszystkich problemów! Zapraszam do poradnika dla osób nietechnicznych, który pomoże Ci porozumieć się z programistą.

Programista a nie informatyk

Pierwsza i najważniejsza kwestia. Programiści zajmują się pisaniem oprogramowania. Spora część ma wykształcenie techniczne. A nawet jak nie, to dobrze czuje się ogólnie w technologiach. Ale to wszystko nie oznacza, że powinieneś przychodzić do programisty z problemami, które definitywnie nie są jego domeną. Dlatego pamiętaj, że pytania odnośnie skrzynki pocztowej, czy wyskakujących okienek na pulpicie to nie są problemy, które powinien rozwiązywać programista. Oczywiście możesz poprosić o pomoc, ale to bardziej w formie koleżeńskiej ale nie traktuj programistów jako kogoś, kto naprawi Ci na przykład drukarkę.

Musisz zrozumieć o czym mowa

Czy chcesz czy nie, jeśli chcesz dobrze komunikować się z programistami musisz chociaż w minimalnym stopniu orientować się o czym mówią. Nie musisz od razu rozumieć wszystkich żartów, które mówią między sobą. Nie musisz też znać wszystkich zwrotów. Chodzi o to, żebyś znał ogólne pojęcia. Można się załamać jeśli na kolejną prośbę o wyczyszczenie cache dostaje się pytanie, co to jest. To bardzo prosty przykład ale język w dużej części jest uzależniony od branży i projektu jaki jest realizowany. Jeśli naprawdę zależy Ci na tym, żeby porozumieć i dogadać się z programistą to musisz posiadać podstawową wiedzę.

Pytaj, bo niewiedza to nie powód do wstydu

Możesz zapytać w jaki sposób zdobyć wiedzę. Możesz przecież nie mieć czasu na czytanie książek, czy przeglądanie kursów. Nikt od Ciebie tego nie wymaga. Jak wspomniałem wcześniej musisz znać podstawowe pojęcia. Najłatwiej nauczysz się tego jeśli będziesz pytać. Jeśli programista powie Ci coś czego nie zrozumiesz to nie przytakuj udając, że wiesz o czym mówi. Poproś o wyjaśnienie. Doświadczeni i dojrzali programiści z chęcią pomogą, bo to oznaka zainteresowania z twojej strony. Zdają sobie również sprawę, że jeśli zrozumiesz dane zagadnienie raz, to w przyszłości będziesz mieć mniej pytań a to oszczędzi czas wszystkim. Zapamiętaj, że niewiedza nie czyni Cię gorszym. Dopytanie jest lepsze niż używanie języka, którego nie rozumiesz. Jeśli chcesz skutecznie porozumieć się z programistą zacznij stopniowo rozumieć jego język.

Pamiętaj, że stanowicie zespół

Jeśli musisz rozmawiać z programistami, a jesteś osobą nietechniczną to musisz odłożyć na bok własne ego. Jeśli chcesz, żeby wasza współpraca była owocna musisz stać się członkiem zespołu. Jeśli wzajemnie będziecie czuć, że jesteście sobie równi gwarantuję, że komunikacja będzie znacznie łatwiejsza. Oczywiście nie mam na myśli tu bardzo bliskiego spoufalania się i przeginania w drugą stronę. Nawet jeśli jesteś menedżerem to pamiętaj, że dowiesz się i zrozumiesz znacznie więcej jeśli programiści będą czuć się przy Tobie swobodnie. Tę radę można akurat przenieść również na inne branże ale ja opisuję akurat podwórko programistyczne, więc na nim się skupię się w dalszej części.

Technologia bywa nieprzewidywalna

Zdarza się tak, że programista oszacował jakieś zadanie na przykład na 4 godziny. Nie musisz od razu po tym czasie z zegarkiem w ręku stać mu nad głową i pytać dlaczego jeszcze nie skończył swojego zadania. Technologia bywa nieprzewidywalna i zdarza się, że zadania się wydłużają. Oczywiście doświadczonym programistom przeszacowanie zdarza się rzadziej ale ciągle jest nieuniknione. Opóźnienia są zdarzają i musisz się z tym pogodzić. Czasem opóźnienie wynika nie z przyczyn samego programisty. Zdarza się że problem rozwiązuje jedna linijka kodu. To jednak nie oznacza, że programista przez te kilka godzin, czy nawet dni nic nie robił. Pomijam już fakt pisania testów, procesu weryfikacji i wdrażania projektu. Dobrym porównaniem może być praca, na przykład na budowie. Robotnik może pokazać palcem, że nie położył wszystkich płytek, bo na przykład podłoga była nierówna i musiał wylać wylewkę. Albo, że nie skończył płytek bo materiał był słabej jakości i się kruszy. Programiści nie mają jak pokazać setek stron, które przeszukali i tysiąców prób jakie wykonali zanim doszli do rozwiązania. Jeśli programista faktycznie w tym czasie się obijał, to jego przełożony powinien wyjaśnić tę kwestię, nie Ty. Dlatego zanim następnym razem będziesz naciskać pamiętaj, że obsuwy się zdarzają i nie muszą wynikać z winy programisty. Poganianie jest najgorszym co możesz zrobić, bo tylko zwiększasz frustrację, która już i tak się kumuluje.

Wykaż zaangażowanie

Jeśli oczekujesz czegoś od programistów to musisz wykazać trochę zaangażowania ze swojej strony. Testowanie zmian jest nudne, prawda? Teraz wyobraź sobie, że programista musi to testować za każdym razem jak wprowadza nawet drobną poprawkę. Oczywiście nie mówię tu o tym, że programiści nie muszą testować swoich zmian. W żadnym wypadku. Dobry programista dba o to, żeby zwrócić kod jak najlepszej jakości z jak najmniejszą ilością błędów i sprawdza to za każdym razem. Jednak, te zmiany trzeba zweryfikować a to bardzo żmudne zajęcie. Jeśli możesz sobie na to pozwolić to weź na siebie przynajmniej testowanie części zmian. Pamiętaj, że jeśli odciążysz programistę w jakikolwiek sposób, bo będą Ci za to wdzięczni na długo :). I dzięki temu będzie Ci później łatwiej się z nim porozumieć.

Bądź samodzielny

Kolejny punkt, który odnosi się do zaangażowania, to samodzielność. Wiele razy byłem świadkiem sytuacji w której ktoś zwracał zadanie, bo widział błąd podczas gdy problemem był cache w przeglądarce. Jeśli programista oddał Ci aplikację do testowania i musisz ją zweryfikować a nie widzisz zmian, to spróbuj wyczyścić cache. Jeśli pracujesz z programistami webowymi to spróbuj dodać parametr w adresie URL albo skorzystaj z innej przeglądarki. Pamiętaj też, że czasem wystarczy coś wyłączyć i włączyć ponownie. To są proste kroki, które mogą znacznie poprawić twoją komunikację z programistami.

Bądź konkretny

Podczas weryfikacji zadań może się zdarzyć, że faktycznie jest jakiś błąd. Jeśli taki wystąpi to opisz go możliwie dokładnie. Wypisz kroki przed wystąpieniem błędu. Dodaj może jakiś zrzut ekranu albo wideo, które prezentuje ten błąd. Jeśli to strona internetowa to podaj link pod którym sprawdzałeś. Konkrety są ważne również przy zgłaszaniu nowych zadań. Jeśli zlecasz programiście nowy projekt albo poprawkę w już istniejącym, to opisz dokładnie co musi być zmienione. Zawrzyj wszystkie informacje które mogą być pomocne. Musisz pamiętać, że te same zdanie może oznaczać dwie różne rzeczy w zależności od kontekstu. Dlatego rozpisuj wszystko konkretnie ale jednocześnie w łatwy do zrozumienia sposób. Unikaj też domysłów. Pamiętaj, że coś co dla Ciebie jest oczywiste dla innych, w tym dla programistów nie musi takie być. Jeśli masz jakieś pytania to dobrze, jeśli docelowo będziesz oczekiwać odpowiedzi TAK lub NIE . W ten sposób możesz uniknąć wielu nieporozumień. Bycie konkretnym oznacza również, że wiesz co chcesz wdrożyć. Nie powinieneś oczekiwać, że to programista wymyśli za Ciebie rozwiązanie. A jeśli nie masz pomysłu to poproś go o konsultacje i wspólnie wypracujcie rozwiązanie. Informacja typu: “ Chcę taki bloczek podobny do tego ze strony X ale żeby działał trochę jak ten z Y ale nieco inaczej. W sumie to nie wiem jak. Wymyśl coś. ” jest bezwartościowa. A zwłaszcza zwrot “ Wymyśl coś ” jest bardzo irytujący. Bycie konkretnym bardzo pomoże Ci porozumieć się z programistą.

Bądź konsekwentny

Kolejna cecha, która jest bardzo ceniona przez programistów to bycie konsekwentnym. Nic nie irytuje tak jak zmiana założeń w trakcie rozwiązywania problemu. Jeśli nie jesteś pewny co do założeń zadania, to go nie zgłaszaj. Jestem za tym, żeby zadania ze zmienionymi założeniami były po prostu odrzucane. Zmieniły się założenia? To zaplanuj nowe zadanie. Zmiana, która dla Ciebie może być prosta może wywrócić programiście pracę do góry nogami i sprawi, że będzie Ci znacznie trudniej porozumieć się z programistą.

Programista to też człowiek

Programiści nie są maszynkami do klepania kodu. Często są do niezwykle inteligentne i bardzo kreatywne osoby. Ale są to przede wszystkim ludzie. A każdy człowiek może mieć czasem gorszy dzień. Dlatego nie wymagaj, żeby ten był wiecznie uśmiechnięty i reagował na każde twoje zawołanie. Każdy w firmie ma swoje obowiązki i każdy ma prawo być zmęczony. Dlatego jeśli widzisz, że rozmowa się nie klei po prostu odpuść, przeczekaj albo postaraj się w jakiś sposób pomóc, o czym pisałem wcześniej. Każdy jest inny i do każdego trzeba podejść indywidualnie. Nie ma jednej recepty, żeby porozumieć się ze wszystkimi. Ale zwykła, ludzka serdeczność w dużej części wystarcza, żeby dobrze porozumieć sie z długim człowiekiem, a nie tylko programistą.

Programiści też grzeszą

To nie tak, że programiści są idealni i to Ty musisz się dostosować. Jak wspomniałem wcześniej programiści, to też ludzie. Jeśli ktoś jest złym człowiekiem to jest duże prawdopodobieństwo, że będzie słabym pracownikiem. Tzn jeśli ktoś nie potrafi się dogadać z innymi, jest leniwy lub kłamie to może w pracy wykazywać podobne cechy. Oczywiście zdarza się, że ludzie w pracy noszą różne maski, by nie uwydatnić swoich wad ale to temat już bardziej psychologiczny a ja nie mam aż takiego doświadczenia. Dlatego nie będę kłamać i się w to zagłębiać. Widzę natomiast, że nawet Ci co są dobrymi ludźmi czasem “ grzeszą ”. Zdarza się, że kod, który działa lokalnie nie działa na środowisku testowym. Programista mógł tego nie sprawdzić i oczekiwać testowania. Nie popieram tego ale to się zdarza. Największym grzechem jest jednak pominięcie czegoś podczas aktualizacji zmian. Przestałem już liczyć ile razy to ktoś nie wrzucił jakiejś zmiany i na zwrotke w zadaniu szybko wrzuca zmiany a odpisuję, że to pewnie wina cache. To niestety najłatwiejsza wymówka, która jest nadużywana.

Co programiści chcą usłyszeć

Przejdźmy już może do konkretów, czyli jak porozumieć się z programistą, a dokładniej co programiści chcą usłyszeć. Są to rzeczy oczywiste ale z własnego doświadczenia wiem, że często pomijane. Pytałem kolegów z branży i najczęściej padały dwie odpowiedzi. Obie dotyczyły informacji zwrotnej. Informacja, że dobrze wykonali swoją pracę jeśli ta faktycznie była wykonana poprawnie zawsze jest mile widziana. Z drugiej strony, jeśli coś było źle to również lepiej przedstawić to w formie konkretów. Programiści naprawdę chcą usłyszeć informację zwrotną, nawet jeśli ta nie zawsze jest przychylna. Jeśli chcesz skutecznie porozumieć się z programistą, nie bój się dawać negatywnego feedbacku.

Czego programiści nie chcą usłyszeć

Teraz w drugą stronę, czyli to czego programiści nie chcą słyszeć. Chyba w każdym zawodzie nikt nie chce usłyszeć niezasłużonej reprymendy. Podobnie jest u nas. Ale jest coś jeszcze czego nie chcemy słyszeć. Chodzi o wytykanie, że praca idzie wolno. I to nie tylko od bezpośredniego przełożonego ale właśnie od osób nietechnicznych. Bardzo trudno jest skupić się na pracy jeśli zewsząd słychać docinki, że praca idzie wolno i prawdopodobnie programista się obija podczas gdy napotkał jakiś błąd, który rzeczywiście blokuje pracę. Odniosłem się już wcześniej do analogii z budowlańcami, którzy w przeciwieństwie do nas mogą konkretnie wskazać przyczyny opóźnienia. Na szczęście ten problem może być rozwiązany na “ daily ”, czyli codziennym spotkaniu na którym opisuje się problemy. Kluczowe jest, żeby z podczas takiego spotkania słuchać programistów i wyciągać z niego wnioski. Dobre przygotowanie do takiego spotkania skutecznie poprawi Waszą komunikację.

Jak mówić do programistów

Chyba kluczowy punkt tego wpisu. Jak pisałem wcześniej, programiści często są bardzo inteligentni jednak warto mówić do nich jak do dziecka. Ale nie w celu ich obrażenia. Do dziecka najczęściej mówi się prostym językiem i konkretnymi instrukcjami. Tego właśnie oczekują programiści, konkretnych i jasnych instrukcji. Najlepiej jeśli wszystko byłoby rozbite na czynniki pierwsze. Pamiętajmy też jedną, kluczową kwestię - to że coś jest oczywiste dla Ciebie nie oznacza, że będzie oczywiste dla innych. Posłużę się tu przykładem. Zróbmy wspólnie proste zadanie. Zadanie polega na zrobieniu kanapki. Zaprezentuję dwa możliwe scenariusze.

Po prostu - zrób kanapkę

Pierwszy scenariusz. Programista dostaje proste zadanie - zrobienie kanapki. Nic nie jest opisane. Robi więc taką kanapkę jak sam lubi, czyli bierze kromkę chleba, z jednej strony smaruje masłem, kładzie tam szynkę, ser i pomidora. Całość posypuję solą i pieprzem. Wszystko wygląda w porządku. Ale osoba, która zleciła kanapkę zwraca ją bo:

• Woli bułkę zamiast chleba
• Nie lubi masła
• Woli ogórka zamiast pomidora
• Zawsze je kanapki składane
• Całość jest zbyt pierna

Przecież to oczywiste, że kanapka bez masła jest lepsza bo te jest przecież niezdrowe. A przecież kanapki muszą być składane, żeby łatwiej zabrać je do pracy.  Widzicie? Taka prosta czynność a już może być źle zrozumiana. Spróbujmy teraz przedstawić jak lepiej można by to zaprezentować

Instrukcja do kanapki

• Zrób kanapkę.
• Użyj bułki bo nie lubię chleba
• Nie używaj masła - to niezdrowe
• Kanapka musi być składana
• W kanapce daj szynkę, ser
• Jeśli masz ogórka to daj 3 plasterki.

Taka instrukcja jest już znacznie bardziej wartościowa. Oczywiście można się przyczepić, że nie ma kolejności składników, itd. Ale o to można dopytać. Ważne jest, żeby zdać sobie sprawę, że nic nie jest oczywiste i nawet proste zadanie jak zrobienie kapanki może być źle zrozumiane. To bardzo ważny punkt i pamiętaj, że jesli chcesz skutecznie porozumieć się z programistą musisz to zapamiętać.

Co mówić do programistów

Wiemy już co programiści chcą usłyszeć, czego nie chcą oraz jak do nich mówić. Przejdźmy do tego co mówić. Przede wszystkim konkretne informacje. Powtarzałem to już w tym wpisie wielokrotnie ale jest to niezwykle istotne. Konkrety to jest coś co programiści cenią najbardziej. Dlatego informacje do dokładnie ma zostać zrobione są bardzo cenne. Równie ważna jest informacja jak coś ma działać. Mówię oczywiście o stronie użytkowej a nie technicznej. Jeśli jakieś okienko ma się wyświetlać po 5 sekundach to podaj konkretnie, że ma się okienko pojawić po 5 sekundach a nie po “jakimś czasie”. Kolejną cenną informacją dla programistów jest określenie deadline. Tu temat zależy od wielkości projektu, metodyki pracy itd. Ja mam na myśli ten najniższy poziom. Jeśli dogadujemy się, że programista ma na przykład danego dnia zrobić 3 zadania to ustal z nim jakie są priorytety tych zadań, określcie wspólnie kolejność ich wykonywania i spróbuj wyrobić jakieś ramy czasowe. Bardziej zaangażowani programiści również cenią sobie informację dotyczącą tego co właściwie chcemy osiągnąć. Pomaga to spojrzeć na produkt szerzej dzięki czemu pojedyncze, małe problemy mogą być rozwiązywane bardziej przyszłościowo. Jak się z to zagłębić to są to proste kwestie a skutecznią pomogą Ci lepiej porozumieć się z programistą.

Czego nie mówić do programistów

Jest coś, czego nie mówić programistom? Może nie używać jakichś zwrotów? Nie. Do tej pory opisałem już prawie wszystko. Ten punkt będzie zatem bardziej podsumowaniem. Przede wszystkim nie powinno się programiście mówić ogólników. Ogólnikowe informacje są tylko szumem i zabierają czas, którego najczęściej i tak brakuje. Poza tym moim zdaniem nie powinno się obarczać programistów winą za coś co nie leży w ich kwestii. Jeśli programista zaimplementował interfejs zgodnie z makietą a ta okazała się całkowicie niewygodna to nie powinno się go za to obwiniać. Oczywiście doświadczony programista powinien zwrócić na to uwagę, ale jeśli zapadła taka a nie inna decyzja i klient czy inny współpracownik się uparł to nie obarczajmy później winą tego programisty. To nie tylko nie powzoli sie dobrze porozumieć ale też może zaprzepaścić wiele tygodni wcześniejszego budowania relacji.

Jak współpracować z programistami

Na koniec porozmawiajmy o tym jak współpracować z programistami. Przede wszystkim na równi. Nie traktuj programisty jako gorszego klepacza kodu. Musisz wiedzieć, że nam, programistom również zależy na projekcie i dla nas dużą satysfakcją jest jeśli końcowy produkt jest sukcesem. Wspólnie możemy osiągnąć bardzo dużo. Nie bez powodu najlepsze zespoły są multidyscyplinarne. Dobra współpraca opiera się na rozmowie. Pamiętaj o tym. Z drugiej strony część programistów ma opory przed rozmowami i dużo łatwiej jest z nimi komunikować się poprzez maila. Żeby dobrze porozumieć się ze wszystkimi programistami musiz dobrać odpowiedni kanał komunikacji. Jeśli o współpracy mowa to zapamiętaj kolejną, kluczową kwestię. Programiści podczas pisania oprogramowania potrafią wpaść w pewnego rodzaju trans i nie powinieneś im przeszkadzać. Jeśli temat o którym chcesz porozmawiać nie jest pilny to poczekaj. Wyślij maila albo przypomnienie na komunikatorze ale nie bombarduj wiadomościami. Wybicie z takiego transu bywa frustrujące i ciężko później ponownie się skoncentrować. Przeszkadzając w pracy nie będziesz mógł się dobrze porozumieć z programistą bo ten nie będzie miał czasu na wykonanie swoich obowiązków.

Podsumowanie

Współpraca z programistami wbrew pozorom nie jest taka trudna. Wystarczy trochę cierpliwości i zwykłego ludzkiego podejścia. Każdy jest inny i do każdego musisz podejść indywidualnie. Jedni lubią rozmawiać a inni są bardziej skryci ale to nie znaczy, że z nimi się nie dogadasz. Do takich osób lepiej trafiają maile lub komunikatory. Pamiętaj żeby nie przeszkadzać im w pracy i nie odrywać ich z błahych powodów. Ostatecznie powinieneś używać prostych i zwięzłych komunikatów, dokładnie tak jakbyś rozmawiał z dzieckiem. Nie zawsze to co jest oczywiste dla Ciebie jest też oczywiste dla innych. No i w końcu te samo sformułowanie może oznaczać dwie różne rzeczy w zależności od kontekstu. To wszystko może wydawać się proste i oczywiste ale gwarantuję,  że jeśli zastosujesz się do powyższych rad twoja komunikacji w zespole poprawi się nie do poznania i w końcu będziesz mógł skutecznie porozumieć się niemal z każdym programistą.

Wpis powstał na prośbę nietechniczej osoby, z którą mam przyjemność pracować :)
Nasze relacje były różne ale ostatecznie udaje nam się skutecznie porozumieć i razem potrafimy stworzyć kawał dobrej aplikacji.
PS. Dzięki za dobry pomysł na wpis ;)