Okiem programisty, kiedy masz mnie za wróżkę, a ja nie wiem co się dzieje

Zanim zostałem programistą przez pewien czas szkoliłem się z zarządzania. Na jednym z warsztatów prelegent podzielił nas na 5-cio osobowe zespoły. Następnie posadził jedną osobę na krześle z przodu, jedną na krześle za nią, i trzy w jednym rzędzie z tyłu. Chwilę później każdy z nas otrzymał zadania do wykonania, a przynajmniej ja miałem takie wrażenie siedząc z przodu. Moim zadaniem było zebranie nazwisk, które otrzymały na swoich kartkach osoby w ostatnim rzędzie, i otrzymać je w porządku alfabetycznym od osoby tuż za mną.

Dla ułatwienia prelegenci zabronili uczestnikom rozmawiać i przygotowali karteczki na których mogliśmy pisać sobie wiadomości. Dali też tylko kilka minut na wykonanie zadania. Ku mojej konsternacji po wysłaniu karteczki „zbierz nazwiska” i otrzymałem karteczkę zwrotną „jakie nazwiska?”. To był początek chaosu, gdy zacząłem rzucać krótkimi wiadomościami do tyłu ze wszystkimi informacjami, które przyszły mi do głowy. Chociaż nie widziałem co działo się za mną, miałem wrażenie, że tam chaos był jeszcze większy. A zadanie przecież takie proste. Pomimo posiadania relatywnie długiego czasu, zadanie udało nam się skończyć dopiero na kilka sekund przed jego zakończeniem.

Chaos w projektach IT

Gdy później zacząłem pracować jako programista zacząłem odnosić nieodparte wrażenie, że tym razem to ja jestem tą osobą z tylnego rzędu. Przedni rząd (osoby wytyczające kierunek firmy i decyzyjne) oraz średni rząd (management średniego szczebla) z dowolnego powodu bardzo często nie dzielą się ani posiadaną wiedzą, ani wizją dotyczącą produktu. Traktują to jak wiedzę, która powinna być dostępna tylko osobom o pewnych uprawnieniach, bądź po prostu jako coś oczywistego. Umyka im, że osoby z tylnych rzędów (Ci tworzący produkt) nie byli na spotkaniach dotyczących obgadywania wizji i produktu, nie wiedzą gdzie i dokąd ma ona zaprowadzić. Co gorsza, dostają często bardzo mylące wytyczne. Dla przykładu weźmy MVP i zamiast często używany przykładu, gdzie od deskorolki przechodzimy do auto powoli rozbudowując środek lokomocji, użyjmy przykładu, gdzie rozbudowujemy namiot starając się w kolejnych krokach dojść do wieżowca (namiot -> szopa -> domek letni -> dom -> kamienica -> wieżowiec). I w realnych projektach często wygląda to mniej więcej jak w poniższej historii:

Co budujemy i dla kogo? Tego nie wie nikt

No więc jestem sobie programistą i przychodzisz do mnie, że macie super produkt i żebym Ci postawił namiot. No to stawiam ten namiot. Potem chcesz szopę. No dobra to budujemy z desek, jest. Potem domek letni. I to jest ten moment kiedy zaczynasz podejrzewać, że coś jest nie tak, bo postawiłem go na totalnym bezludziu, gdzie żeby dojechać trzeba posiadać samochód terenowy. Toi-toi i bojler, do którego musisz wlewać wodę z baniaka na ten moment w projekcie jest jeszcze ok, bo bieżąca woda była stretch golem, a ja się postawiłem okoniem i stanowczo stwierdziłem, że nie dam rady tego zrobić.

Masz to niejasne przeczucie, że coś jest nie tak, choć jeszcze nie potrafisz tego ugryźć. Aż do momentu, gdy przekształcając domek letni w dom ja wciąż nie poprowadziłem do niego drogi, w domu nie ma toalety, a toi-toi jak stał tak stoi. Jedyna bieżąca woda jest z butelki i w rynnach jak pada. Po długiej rozmowie, w czasie której starasz się wytłumaczyć mi czemu bieżącą wodą i toaleta w budynku są ważne, a ja przekonać Cię, że tego się nie da zrobić, wychodząc słyszysz jak mówię za Twoimi plecami, że nie wiesz czego chcesz i jest to dla mnie szok, że jeszcze tu pracujesz. Może i byłoby Ci przykro gdyby nie to, że myślisz dokładnie to samo, tylko o mnie.

Konflikty i nieporozumienia

Tydzień później masz już całkowite przekonanie, że jestem kretem, i chcę, żeby ten projekt upadł, kiedy dowiadujesz się, że wstawiłem toi-toi do budynku i staram się Ciebie przekonać, że mieszkańcy mogą go wymieniać, nawet pokazuję Ci jak można by dodać to do projektu. W końcu dogadujemy się, że zrobimy koło domu gnojówkę, żeby był odpływ. Projekt staje na kilka miesięcy, bo najbliższe dojście do bieżącej wody jest kilkanaście kilometrów od naszego domku i trzeba pociągnąć stamtąd rury. Ty płaczesz po nocach, że programiści Cię nienawidzą, i że to są wstrętni ludzie. Ja, że będę przez Ciebie kilka miesięcy kładł rury zamiast budować domy, co jest totalnie poniżej moich umiejętności i cofa mnie w rozwoju i karierze. Nasz szef w tym czasie szuka innej firmy, której projekt wieżowca jest na ukończeniu, i ją kupuje, a następnie przenosi nas do tego projektu, żeby go dokończyć i podtrzymywać, bo wychodzi mu tak taniej, niż czekać aż po pół roku nie dostarczania żadnej wartości biznesowej wznowimy pracę nad produktem i będzie można cokolwiek nowego pokazać inwestorom i klientom. Jak naszemu szefowi to wyjdzie ja się pewnie nie dowiem, bo w połowie składania tych rur zmienię projekt albo wręcz firmę mając dosyć bałaganu jakim jest nasz produkt, i zastoju w rozwoju, jakim jest ciągłe kładzenie rur w ziemi.

Dziel się z innymi tym, co jest w Twojej głowie

Widziałem takie projekty nie raz, a przykłady, które podaję miały pokrycie w rzeczywistym życiu (dotyczyły głównie projektów programistycznych, choć nie tylko). Każdy ma poczucie, że pracownicy zawsze zarabiają wystarczająco dużo, żeby unikać zapraszania ich na wszystkie możliwe spotkania i nie powinni na wszystkich być, bo niewiele zrobią. Ale powinni być na tych kluczowych nawet po to, żeby tylko posłuchać, i powinny te spotkania mieć przygotowane wprowadzenie, co się działo dotychczas, i o czym rozmawiamy. Nie może tam być miejsca na nic, co sprawi, że nie będą wiedzieli o co chodzi bo się wyłączą.

Maile informujące o kierunku podejmowanych decyzji również są ważne. Jeśli uważasz, że nie masz na to czasu proponuję odświeżyć starą bajkę o Zabłockim. Bo w podanym przeze mnie przykładzie wystarczyłoby, żeby programista wiedział, że chcesz mieć tam kiedyś ten blok i mniej więcej kiedy i postawiłby ten namiot na działce blisko miasta, tak żeby była bieżąca woda, prąd, i odpływ do ścieków.