8 maja 2017

Słowa, słowa, słowa

Communication breakdown / It’s always the same,
I’m having a nervous breakdown / Drive me insane!

Led Zeppelin – Communication Breakdown

Jakie jest źródło największych problemów w czasie prac nad oprogramowaniem? Dlaczego tak często projekty IT kończą się niepowodzeniem?

Nie będę oryginalny, sądzę, że każdy, kto przepracował w tej branży kilka lat, nawet jeśli jest średnim obserwatorem, wskaże ten problem. A jest nim komunikacja. Pomiędzy wszystkimi uczestnikami procesu wytwórczego. Na każdym jego poziomie. I kompletnie nie ma tu znaczenia sposób w jaki pracujesz – organizacja pracy (waterfall, agile, pospolite ruszenie), jej charakter (zespołowa czy indywidualna) czy sposób nadzoru (techniczny i hierarchiczny). Tout court: dopóki nie zidentyfikujesz i nie rozwiążesz problemów komunikacyjnych, zapomnij o sukcesie.

O komunikacji międzyludzkiej napisano grube tomy. Złotych środków i gotowych przepisów nie ma. Im większe przedsięwzięcia, im więcej zaangażowanych osób, tym trudniej, tym więcej problemów. Można popaść w fatalizm, idąc za słowami Karla Poppera: Jest niemożliwym mówić w taki sposób, by nie być niezrozumianym właściwie. Zawsze znajdzie się ktoś, kto inaczej zrozumie twoje słowa.

Ale można i działać. Naprawdę niewiele trzeba, aby rozwiązać pewne podstawowe problemy. Oto cztery, według mnie, pierwszoplanowe przy wytwarzaniu oprogramowania, wraz z krótkimi receptami jak je zwalczać. Do dzieła Scrum Masterze!

Brak wspólnego słownika pojęć

Każde nowe przedsięwzięcie, nowy projekt, nowe oprogramowanie przynosi nowe słownictwo, nowe pojęcia. Już na poziomie pomysłu pojawiają się różnego rodzaju sformułowania, terminy, próbujące przekazać zamysły autora, jego wizje. Najczęściej dominują tu różnego rodzaju neologizmy, spolszczone słowa angielskie czy po prostu znane słowa ujęte w innym kontekście, znaczeniu. W świecie software’u najczęściej tworzy to zbiór będący mieszaniną angielszczyzny i spolszczonej angielszczyzny.

Pomysł wraz ze zbiorem opisujących go pojęć po trafieniu do IT bardzo często zyskuje zupełnie inny, zaskakujący charakter, ulegając kompletnemu przekształceniu. Programiści, architekci czy – po Bożemu, tfu, Scrumowemu –  deweloperzy, postrzegają pewne pojęcia zupełnie inaczej, z innej perspektywy, z innej optyki. Dochodzi do tego swoisty żargon, zarówno ten biznesowy, jak i programistyczny. I katastrofa gotowa.

Nieraz zdarzyło mi się widywać duże projekty, gdy wszyscy wszystko wiedzieli, wszystko było zapisane, a gdy po X miesiącach przychodziło do finalnej prezentacji, okazywało się, że wszyscy używali tych samych pojęć, ale mieli na myśli zupełnie co innego.

Dlatego – pamiętaj.

Zaczynając projekt, przedsięwzięcie, miej pewność że wszyscy mówimy o tym samym Przygotuj słownik pojęć i rozpropaguj go wśród interesariuszy, wszystkich wykonawców, w końcu i całej organizacji. I pilnuj, żeby był przestrzegany, nie dopuszczaj tysięcy synonimów, bądź upierdliwy,  poprawiaj. Na przeglądach, w wymaganiach. Na lądzie, w wodzie i powietrzu.

Dopilnuj też, aby nie pojawiały się nowe szyldy w stosunku do pojęć powszechnie znanych i rozpoznawalnych. I tęp, tak, do diaska – tęp –  niezrozumiały żargon, którego używanie szczególnie mocno jest rozpowszechnione wśród przedstawicieli IT.

Brak odwagi, by powiedzieć “nie rozumiem”

Chyba każdy doświadczony pracownik IT, niezależnie od stanowiska, był świadkiem takich scenek.

Sytuacja numer jeden:

Architekt wyjaśniający programistom jak rozwiązać dany problem. Wielki mistrz z dumą, z czerwonymi policzkami peroruje, skromni uczniowie z pokorą słuchają. Wszyscy rozchodzą się szczęśliwi, bo problem rozwiązany. A architekt może triumfalnie przejść się po całej firmie, opowiadając wszem i wobec, co wspaniałego wymyślił. Szczęście to trwa z reguły albo do review, gdy okazuje się, że nie o to chodziło, albo do momentu, gdy programista wraca, by przenieść Wielkie Myśli na linijki kodu. I zdaje sobie sprawę, że kompletnie nie o to chodziło. Albo, że niczego z Wielkiej Przemowy nie zrozumiał.

Sytuacja numer dwa:

Product Owner wyjaśniający zespołowi swój pomysł. Albo i zespół wyjaśniający Product Ownerowi jak to zrobi. Jedna strona mówi coś kompletnie bez sensu, druga natomiast kompletnie nic z tego nie rozumie. Ale mimo tego, nieustannie kiwa głową i potwierdza wszystko, co słyszy, uciekając w bełkotliwy żargon lub wchodząc na poziom wysokopoziomowych uogólnień. Albo i nic nie mówi i tylko, przybierając mądre miny, po prostu przytakuje. I znów, jeden chciał hamburgera, drugi myślał o pizzy, a na produkcji hot-dog z makrelą. Smacznego.

Bo przecież wstyd przyznać się, że się nie rozumie. Bo zespół wyśmieje PO, bo PO i inni członkowie zespołu wyśmieją mnie, nieogarniętego programistę. Bo widać, że tylko ja nie rozumiem.

Oj tak, nie jest łatwo tu wesprzeć. Trzeba przede wszystkim dobrze rozumieć potrzeby biznesowe oraz proces wytwarzania oprogramowania. Znając potrzeby, wymagania, można pomóc Product Ownerowi właściwie je wyartykułować. I zadając zespołowi deweloperskiemu odpowiednie pytania, upewnić się czy je rozumie. Znając proces, a może i technikalia, można podpowiedzieć zespołowi jak to można zrealizować.

Unikanie komunikacji bezpośredniej

Jak dobrze, że wprost zanotowano to w założeniach manifestu programowania zwinnego:

Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.

Tymczasem:

  • pisałem na komunikatorze
  • zostawiłem komentarz w zadaniu
  • pisałem do niego, nie odpisał mi, to co się będę prosił
  • nie odpisał mi, to ja też mam go w d**
  • zobacz co mi odpisał, z takim *** nie współpracuję
  • przecież on jest na MCMX piętrze, nie będę marnował 30 minut, żeby na windę czekać i do niego jechać, zrobię po swojemu
  • przecież on i tak by tak zadecydował
  • wiadomo, że to jest jedyna opcja, tak zrobię
  • on i tak nie ma czasu
  • przecież było napisane wszystko
  • pewnie go jeszcze nie ma

Promuj komunikację bezpośrednią. Walcz o nią, walcz, ile sił! Tu jest najwięcej do osiągnięcia, najwięcej do uzyskania. Komentarze przy wymaganiach, komunikatory – tylko jako wsparcie. Tak, jest trudniej, bo trzeba ruszyć tyłek od biurka. Jest trudniej, bo w grę wchodzi kontakt bezpośredni z innym człowiekiem. Ale efekty przyjdą.

Brak dobrych chęci

Podsumowując nieco powyższe. Odnoszę wrażenie, że coraz częściej Scrum Masterzy pełnią rolę swoistych tłumaczy pomiędzy IT, a biznesem, a zarazem i wewnętrznych pomiędzy IT, a IT. Zwyczajnie pomagają interlokutorom się dogadać. A czemu są w tym dobrzy?

Bo mają wiedzę o domenie biznesowej projektu, wiedzą dokładnie co chcemy osiągnąć i dlaczego. Bo wiedzą jak się wytwarza oprogramowanie. Bo rozumieją obie strony – i biznesową, i IT, patrzą szeroko i bezstronnie. Bo mają empatię, chcą słuchać, cenią sobie bezpośrednią komunikację. Bo są szkoleni jak się komunikować, jak pomóc ludziom się dogadać. Huh, co za wspaniali ludzie. No, taki według mnie powinien być dobry Scrum Master. A przynajmniej do tego powinien dążyć.

A powinien mieć jeszcze jedną wspaniałą cechę. Chęci. Bo często przede wszystkim tych dobrych chęci w komunikacji brakuje. I o tym pamiętajcie.

#wokółIT#ZespółDeweloperski#ZespółScrumowy