(Nie)zrozumienie – czasem trzeba wiedzy, zawsze trzeba chęci ;)

Sytuacja którą dziś wspominam tytułowe (nie)zrozumienie) miała miejsce jakiś czas temu w jednej z moich poprzednich ról. Pracowałem wówczas w szeroko pojętym ‘Biznesie‘ i jak sama nazwa wskazuje, odpowiadałem biznesowo za wdrożenia techniczne, zarówno w obszarze mainframe’a, jak i usług wspierających – formularzy, automatyzacji 🙂

Wymagało to współpracy, w zależności od obszaru wdrażanych zmian z jednym z trzech zespołów tak zwanego “IT”. Czasem trzeba było zgrać zmiany z dwoma, a czasem z trzema zespołami naraz.

Nasza współpraca układała się świetnie – na tyle dobrze, na ile pozwalała organizacja ^^ czyli takie obszary jak dział prawny, marketing, ryzyko, jednostki sprzedażowe, operacyjne, lub miks wszystkiego w różnych proporcjach. Plus polityka 🙂

Ja, Bottleneck

Moja świetna współpraca z IT, w połączeniu z dużą liczbą projektów różnej wielkości toczących się równolegle (o kanbanie, a tym bardziej limitach pracy w toku nikt Wówczas nie słyszał, zresztą nie mam przekonania, że ktoś by się do niech pozytywnie odniósł ^^) skutkowała jednym – kolejkami.

Niechybnie o swoje upomniało się Prawo Little’a, którego świetną wizualizację umieszczam poniżej (i napiszę o nim więcej innym razem). Cycle time rósł, bo przepustowość systemu była względnie stała, a tempo napływania projektów było większe niż tempo ich kończenia. Któż tak nie miał chociaż raz?

By Christoph Roser at AllAboutLean.com under the free CC-BY-SA 4.0 license.

Nadchodzi pomoc

W związku z tym, żeby mnie odciążyć, oraz zwiększyć tempo dostarczania, jedno wdrożenie systemowe do swojego projektu dostała do zaopiekowania moja dobra koleżanka (tzw. “peer”). Koleżanka z ciut krótszym stażem, ale bardzo ambitnie podchodząca do tematu.

Tak więc koleżanka udała się do kolegi programisty zajmującego się rozwojem i utrzymaniem jednego z kluczowych dla nas narzędzi. Programisty dodajmy z dużą wiedzą, stażem i doświadczeniem, którego całkiem fajny interfejs osobowy był dla niektórych ukryty za domyślnym (fire)wallem 😉

Niektórym chciało się ów firewall obejść, innym się nie chciało, lub nie byli go świadomi. Co nie zmienia faktu, że on tam był. Na szczęście ja byłem na tzw. ‘whiteliście‘ – czyli firewall kolegi przepuszczał mnie bez przeszkód oraz pozwalał na płynną, efektywną współpracę.

W trakcie tej wspólnej pracy dość dobrze poznałem specyfikę narzędzia jakim się posługiwaliśmy. Dzięki temu mniej więcej wiedziałem, które zmiany są ‘duże’, które są ‘małe’, które są do zrobienia pod stołem ‘przy okazji’, a po które trzeba się ustawiać w kolejce po budżet u dyrekcji 🙂 Czyli biznesem byłem dość ogarniętym. To ważne w kontekście dalszej historii.

Więc jesteśmy w sytuacji, w który idzie świeży biznes do umocowanego IT i coś chce. Pilnie, a jakże.

To na kiedy to będzie?

Zmiana funkcjonalna o którą się rozchodziło była czymś pomiędzy “za trzy dni będzie do testów”, a “po weekendzie powinno być”. Przynajmniej tak wynikało z mojego doświadczenia. Udała się więc koleżanka do kolegi-programisty zagaić temat, obgadać szczegóły i potwierdzić timeline. Po czym wraca po kwadransie ze łzami w oczach. "Bo on powiedział, że to będzie za trzy-cztery miesiące..."

Koleżanka w rozpaczy, bo projekt ma odpalać za, dajmy na to, miesiąc, a tu “IT się okoniem stawia”. Więc ona na pewno zbierze po głowie, jeśli projekt nie dojedzie na czas. No i jakbyśmy sytuacji nie wyjaśnili, to najprawdopodobniej nie dojechałoby na czas, i najprawdopodobniej zebrałaby wówczas po głowie ^^.

Ale… “Ki diabeł?”, myślę sobie. Przecież to drobiazg, więc skąd taka wycena. Zebrałem się więc w delegację na drugą część open-space’a, i przystępuję do inwestygacji.

Now we’re talkin’

Tutaj nastąpi opis dialogu, który możliwe, że wyglądał odrobinę inaczej, ale czas zaciera szczegóły, natomiast sens oddaje wiernie 🙂

"Kolego programisto, dlaczego powiedziałeś koleżance z zespołu mego, że zmiana z którą przyszła to 3-4 miesiące pracy, skoro ja wiem, że to 3-4 dni wliczając przerwy na kawę?"

Kolega spojrzał na mnie wzrokiem osoby oderwanej od analizowania wielokrotnie zagnieżdżonego IFa i zapytał rzeczowo:"To czego ona dokładnie chciała?" 😀 tu następuje opad rąk i przypomnienie sobie o firewallu, w którym ja mam na stałe wyjątek. Wdech. Wydech.

"Ona chciała to i to (nie pamiętam co dokładnie, niemniej nie ma to wpływu na historię), a przecież to drobnica".

"Aaaaa, noo pewnie, ale powiedziała, że chce to i tamto (i tu następuje opis zmiany 10-15x większej)"

(…) Wdech. Wydech.

"No jednak nie, chce tą drobnicę."

"To trzeba było tak od razu mówić, niech mi wyśle mailem szczegóły, żeby mi nie umknęło, będzie po weekendzie"

Było do piątku.

Dwie drogi

Tutaj mieliśmy klasyczną sytuację, gdzie jedna strona zadała pytanie (nieprecyzyjne i/lub niewłaściwe) bez znajomości kontekstu. Dalej mogło to pójść dwoma ścieżkami:

• ścieżka 1 – kolega programista zadałby dodatkowe pytania, żeby zrozumieć potrzebę koleżanki, która sama nie do końca wiedziała o co pyta. Po chwili dyskusji pojawiłoby się zrozumienie czego dokładnie potrzeba, i ostatecznie informacja “będzie po weekendzie” 🙂 Ale nie zawsze jest idealnie, i życie potoczyło się ścieżką numer 2, czyli:
• ścieżka 2 – kolega programista odpalił konkretną, choć niesatysfakcjonującą odpowiedź (adekwatną do pytania, choć również bez znajomości kontekstu). W dodatku obie strony niekoniecznie zadbały o to, żeby CHCIEĆ się porozumieć. I temat zawisł w powietrzu, generując napięcie.

Gdyby ta sytuacja toczyła się dalej tym torem, najpewniej trafiłaby w formie eskalacji do menedżera. Następnie do drugiego. Kolejnym krokiem byłaby pewnie prośba o przeprocesowanie zmiany systemowej zgodnie z procesem zgłaszania zmian. Po jakimś miesiącu-dwóch czekania temat trafiłby do kolegi-programisty do analizy. I na koniec okazałoby się, że procedura uzgadniania o co dokładnie chodzi trwa wielokrotnie więcej niż samo wykonanie zmiany.

Na szczęście w tej konkretnej sytuacji był ktoś, kto tę komunikację był w stanie wyprostować i wszystko dobrze się skończyło. Ale nie zawsze tak jest, co generuje mnóstwo problemów możliwych do uniknięcia w bardzo prosty sposób.

TL;DR – tzw.: I co ja z tego mam wynieść?

Jaki z tego morał? Ano taki, że warto z ludźmi gadać. W życiu, w pracy. Ale tak po ludzku, wiedząc o czym chce się pogadać, chcąc się zrozumieć i dogadać i w szerszym zakresie niż “a na kiedy to będzie?”. Bo to działa.

Można? Można 🙂

Z tego nastawienia życzę wszystkim 🙂

Pozdrawiam serdecznie,

Marcin

P.S. Taka ciekawostka, tytułowy obrazek wygenerowałem przy pomocy Microsoft Designera. Widzę potencjał 🙂