Spotkałam się ostatnio ze stwierdzeniem, że analityk źle wpływa na komunikację w projekcie tworząc efekt tzw. głuchego telefonu. Niepotrzebnie staje między biznesem a developerami. A popularne w analitycznej branży stwierdzenie „łączymy biznes i IT” zaczęło być odbierane negatywnie. Czy tak właśnie jest i niepotrzebnie robimy głuchy telefon? Zanim wydamy werdykt – najpierw analiza ?
Głuchy telefon
Pewnie każdy bawił się w głuchy telefon za dzieciaka ? Osoby siadają w kole lub w rzędzie. Jedna osoba wymyśla hasło i wyszeptuje je na ucho kolejnemu uczestnikowi. Ten przekazuje następnemu i tak dalej, aż dojdzie do ostatniej osoby. Ostatni mówi na głos co zrozumiał. Zazwyczaj to inne słowo, niż wymyślone hasło.
Głuchy telefon działa też w wersji rysowanej. Pierwsza osoba np. rysuje plecak, a ostatnia jakimś cudem kończy z odkurzaczem czy rakietą kosmiczną.
Trochę z teorii komunikacji
Na czym polega komunikacja? Jeden z twórców teorii informacji – zasłużony dla IT matematyk Claude Shannon oraz cybernetyk Warren Weaver stworzyli model transmisji sygnałów w układach telekomunikacyjnych wyróżniając elementy takie jak:
- źródło informacji,
- nadajnik,
- sygnał wysłany,
- źródło szumu,
- sygnał otrzymany,
- odbiornik,
- adresat informacji.
Wtrącając – głównym czynnikiem dającym efekty w zabawie w głuchy telefon daje szum powodowany szeptaniem do ucha. Czy zabawa miałaby sens, gdyby każdy uczestnik mówił głośno i wyraźnie? Jakie ma to podobieństwa do pracy analityka?
Główna różnica między światem komputerów a światem ludzi polega na tym, że ten pierwszy jest jednoznaczny, bardzo precyzyjny. Coś jest lub tego nie ma. W świecie ludzi to samo zdanie może być zupełnie inaczej odebrane przez różne osoby czy w różnych kontekstach. Zdanie „Fajna bluzka” jedna osoba odbierze jako komplement, a druga jako nabijanie się. Zależy to też od intonacji, tego jak ta bluzka wygląda, w jakim miejscu padają te słowa, od kogo do kogo, od historii relacji tych osób. Pewnie też wyzwania z komunikacją znają panowie z akcji typu „domyśl się”.
- Kochanie, czy mogę iść z kolegami na piwo?
- Rób co chcesz.
A potem foch, kiedy on zrobił, to co chciał ?
Albo:
“Aha, jest jej zimno.” W domyśle była to prośba o zamknięcie okna.
W komunikacji między ludźmi nie ma łatwo.
Inny uniwersalny model komunikacji opracował Roman Jakobson zwracają uwagę na takie elementy jak:
- nadawca,
- odbiorca,
- kontekst,
- kod,
- kontakt,
- komunikat.
Nadawca formułuje komunikat w określonym kontekście kodując go w znanym sobie kodzie. Posiada przy tym określoną intencję. Odrębną rzeczą jest interpretacja komunikatu przez odbiorcę. Ten zdekoduje wiadomość znanym sobie sposobem i zinterpretuje ją w znanym sobie kontekście.
A teraz o analizie
Komunikacja w biznesie ma inne wymagania niż komunikacja w świecie IT. Komunikat wystarczający do właściwej reakcji odbiorcy biznesowego może być niezrozumiały czy za mało precyzyjny dla odbiorcy IT. Nadawca komunikuje się w kontekście postrzeganym przez siebie wraz z wynikającymi z nimi założeniami, rzeczami zbyt oczywistymi, żeby przyszło do głowy o nich mówić i z brakiem świadomości, że niektóre rzeczy istnieją i są dla IT kluczowe. Kody stosowane przez biznes (np. żargonowe pojęcia) czy przez IT (kod, pseudokod, wymagania, user stories, UML) mogą być interpretowane odmiennie. Każda ze stron także inaczej może postrzegać kontekst, który wpływa na interpretację.
Jak wygląda to w najprostszym modelu projektowym z udziałem analityka?
Jest to widok przekazywania jednej informacji od jednego nadawcy do jednego odbiorcy. W projekcie wygląda to jednak bardziej skomplikowanie.
Załóżmy teraz, że klient/użytkownik nie jest 1, ale jest ich 5. Dajmy na to, że, developerów także jest 5.
Jak zinterpretujemy taką sytuację? Można powiedzieć, że analityk stał się główną osobą do kontaktu (SPOC – Single Point of Contact). Można też powiedzieć, że stworzył wąskie gardło komunikacji.
Co dostaniemy po usunięciu analityka?
Wygląda na to, że pozbyliśmy się wąskiego gardła komunikacji. Mamy jednak mnóstwo różnych strumieni. Co, jeśli równocześnie zajdą zdarzenia:
- Klient/Użytkownik 1 powie Developerowi 1, że chce A
- Klient/Użytkownik 2 powie Developerowi 2, że chce A i B
- Klient/Użytkownik 3 powie developerowi 3, że nie chce A
- Klient/Użytkownik 4 powie developerowi 4, że chce C, z czego wynika, że nie można zrobić B
- Klient/Użytkownik 5 powie developerowi 5, że chce A lub B
Potrzeba będzie bardziej intensywnej komunikacji między Developerami, żeby wychwytywać takie sytuacje. Po wychwyceniu jej, trzeba ją też rozwiązać, sprowadzając do wspólnego uzgodnionego stwierdzenia.
Dla usprawnienia komunikacji zespołu ze światem zewnętrznym tworzy się w Scrumie rolę Product Ownera.
PO robi też analizę.
Z założenia analityk powinien być specjalistą od komunikacji. Jego pracą jest odkrywanie i ujawnianie kontekstu, poznawanie kodów, nawiązywanie kontaktów. Będąc świadomym tych rzeczy, powinien tworzyć komunikaty, które spełniają swoje zadanie – zostają zinterpretowane zgodnie z intencją. W obie strony Biznes -> IT, IT -> Biznes. I powinien umieć weryfikować, że właśnie taka poprawna interpretacja miała miejsce. Analitycy są też szkoleni do tego, żeby ogarniać wielowątkowość komunikacji.
Przygotowanie bazy do komunikacji to: analiza interesariuszy.
Tworzenie kontekstu komunikacji to: określanie potrzeb, celów przedsięwzięcia, analiza organizacji, analiza kierunków rozwoju, analiza procesów biznesowych, analiza kontekstu zagadnienia, analiza reguł biznesowych, identyfikacja nastawienia, wpływu, zaangażowania interesariuszy.
Praca nad kodem komunikacji to: precyzowanie pojęć dziedziny, tłumaczenie znaczenia makiet, diagramów, wymagań.
Tworzenie kontaktu to nawiązywanie i utrzymywanie relacji.
Analiza komunikatu to rozbijanie go na czynniki pierwsze, zrozumienie intencji i sprawdzanie co to oznacza dla modeli działania systemów IT i w drugą stronę – dla biznesu.
Czy robisz te rzeczy w sposób sformalizowany czy nie, to sprawa drugorzędna. Byle skutecznie dla efektu komunikacji. Analityk powinien rozkminiać z kim rozmawiać w jaki sposób, kto jakie formy komunikacji lubi, kto jakie kody rozumie. Analityk powinien uwzględniać i łączyć różne potrzeby organizacji, wielu różnych klientów, użytkowników w jedno najbardziej wartościowe rozwiązanie.
Mamy różnych developerów. Jeden chce dostać konkret – co on ma zaprogramować, a na spotkaniach z biznesem usypia, bo nie pada „nic istotnego”. Inny chce dostać zadania, ale też rozumieć kontekst. Inny chce poznać problem i sam zaproponować rozwiązania (robiąc w sumie analizę). Komunikacja z zespołem to też dostosowanie się do jego potrzeb, umiejętności i chęci, mając z tyłu głowy oczekiwany efekt dla biznesu i motywacji zespołu.
Cała zabawa tkwi w tym, żeby przełożyć intencje biznesu na wpierające je system informatyczny. Czy developer sam tego nie jest w stanie zrobić? Przeważnie jest. Wyjątkiem są osoby bardzo biznesowe i bardzo techniczne, które nie mogą znaleźć wspólnego języka. Wtedy z ratunkiem mogą przyjść eksperymenty, demonstracje i dopasowanie do informacji zwrotnej. Pytanie tylko ile zajmie osiągnięcie zadowalającego efektu.
Czy analitycy nie robią błędów? Jasne, że robią. Czasem się mylą, czasem brakuje im kwalifikacji, predyspozycji czy właściwego nastawienia. Różnie bywa. Jednak z założenia, my się właśnie w tym specjalizujemy, żeby trafiać w sedno biznesu i w sedno IT.
Jeśli nie potrafisz tych rzeczy, Twój zespół developerów potrafi to zrobić lepiej niż Ty lub tak samo dobrze, to ja się pytam, co robiłeś przez ostatnich X lat? ? Trochę to zaczepny żart, a trochę nie. Bo faktycznie, bywa, że Ty jesteś młody, nowy, uczysz się, a Twój zespół siedzi w projekcie od zarania dziejów – mają prawo dużo wiedzieć, mieć dobre relacje i przetarte ścieżki komunikacyjne. Ale może być też tak, że chodzisz na spotkania, robisz za gumowe ucho, dyktafon i stenotypistkę i faktycznie nie wkładasz nic od siebie do komunikacji, przerzucając widłami z prawej na lewą, przeklejając z jednego miejsca w drugiej. Wtedy pamiętaj, że rozwój kompetencji to Twoje priorytetowe zadanie. Bo nie tak ma wyglądać praca analityka.
Co robi analityk w głuchym telefonie? Nie powtarza słowa z lewa na prawo, ale przykładowo:
- sprawdza kto mówi – czy ta osoba jest właściwą osobą do tego komunikatu, jakie ten komunikat powinien mieć znaczenie i jak powiązać go z komunikatami innych osób,
- upewnia się w jakim języku zostanie ono przekazane,
- jeśli danej rzeczy nie da się wyrazić efektywnie danym językiem, to definiuje właściwy język,
- sprawdza czy słowo występuje ono w dialekcie biznesu i developerów i czy oznacza to samo,
- jeśli nie oznacza tego samego w równie precyzyjny sposób – tworzy mapowanie języka biznesowego na IT,
- sprawdza sensowność komunikatu w kontekście biznesu, branży, firmy,
- sprawdza spójność z innymi komunikatami i obecnym działaniem biznesu i systemu IT,
- sprawdza jakie są intencje biznesu, jakie są jego prawdziwe potrzeby (strategia, cele, intencje),
- sprawdza zrozumienie IT (czy jest wystarczająco precyzyjny),
- sprawdza czy zrozumiany komunikat po wykonaniu polecenia rzeczywiście pomoże biznesowi – czy da mu wartościowy wynik zbliżający do wyznaczonego celu za warte tego pieniądze,
- …
I co? Robisz głuchy telefon? Jeśli tak, to koniecznie to zmień, bo ewidentnie jest coś nie halo.
