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:
- Zimno mi.
„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.
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.
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.
0 komentarze “Czy analityk robi głuchy telefon?”
Również obserwuję „trend” postawiony w tytule. Wydaje mi się, że w ostatnim czasie, także z uwagi na tempo rozwoju produktów, świat analizy przeniósł swój środek ciężkości na stronę biznesową, właśnie dzięki popularyzacji roli analityka biznesowego. Dodając tego szybkość zmiany strategii czy taktyki biznesowej przedsiębiorstw oraz liczbę utrzymywanych systemów i aplikacji, analityk często nie schodzi na poziom komunikacji oczekiwany przez dewelopera. Często jest to poziom czarnoskrzynkowych wymagań na system. Przemyślany słownik pojęć nie nie jest wcale tak powszechnie stosowany, nie wspominając już o jego formie w postaci diagramy klas. Pozostaje jeszcze jeszcze pytanie gdzie jest Projektant? I tu właściwie tkwi moim zdaniem sedno problemu. Projektowanie oprogramowania dzieli się na dwa obszary. Pierwszy techniczny/inżynierki, odpowiada za niego architekt – dotyka obszaru architektury systemu, komunikacji między jego warstwami a także z interfejsami zewnętrznymi, czyli wszystko to co jest niezbędne, aby logika biznesowa działała sprawnie i bezpiecznie. Drugi biznesowy, odpowiada za niego analityk – opisuje działanie systemy w ujęciu logiki biznesowej (w tym miejscu język analityka i architekta musi być uspójniony). Niestety analitycy rzadko schodzą na ten poziom, gdyż wymaga on dobrego warsztatu obiektowego, który dość prostą techniką „User Stories” lub wymaganiami tylu black-box.
Spoko artykuł, zabrakło mi jednak conajmniej jednego i w sumie najwazniejszego elementu/ diagramu – najlepszego rozwiazania ze wszystkich (moim zdaniem). Chodzi mi o polaczenie sytuacji SPOC i kolejnego diagramu. Czyli analityk jest na pozycji SPOC i robi wszystko co w jego mocy aby wymagania byly jak najbardziej SMART, ale w momencie watpliwosci lub potrzeby dodatkowych informacji jest w stanie precyzyjnie wskazac najbardziej odpowiednie zrodło informacji z ktorym developer/ zespoł moze sie samodzielnie skontaktowac w celach weryfikacyjnych lub uszczegolowiajacych. Takimi osobami kontaktu moga byc klient/uzytkownik, PO (jesli analityk nie pelni takiej roli), UXa, desinger’ow czy poprostu SME. Tak otware sytuacje sa bardzo zadki, lecz z doswiadczenia moge powiedziec ze sa najlepszym rozwiazaniem.
Celem było bardziej pobudzenie do myślenia czy analityk robi „głuchy telefon”, co to znaczy i czy to źle. Nie było celem proponowanie najlepszego rozwiązania. Zresztą ciężko to stwierdzić niezależnie od projektu. 4 osobowy projekt będzie inny niż 300-osobowy. Skoncentrowana wiedza i decyzyjność osób też wymaga innych rozwiązań niż rozproszona. Ale tak – często pewnie dobrym wyjściem będzie zajmowanie się przez analityka tym, czym trzeba samemu a zostawienie bezpośredniego dogadania się tam, gdzie nie ma sensu wchodzić miedzy wódkę a zakąskę ?
Dzień dobry,
łatwo wpaść w pułapke „głuchego telefonu”. Jedna z umiejętnosci BA to wystrzeganie się podobnych sytuacji. Bez zrozumienia potrzeb biznesowych nie bedzie mógł przekazać developerom zakresu zmian wynikających z wymagań. Ani ocenić, czy dostarczone rozwiązania odpowiadają potrzebom biznesowym. Rozumienie to klucz. I telefon już nie jest taki głuchy 🙂