„Prawie” robi wielką różnicę – o wpływie języka na proces tworzenia oprogramowania

Na spotkaniach podsumowujących sprinty czy podczas codziennych stand-upów członkowie zespołów mają tendencję do maskowania stanu faktycznego komunikatami „prawie gotowe”, „to zajmie jeszcze tylko chwilę” i podobnymi zwrotami.Kiedy objąłem funkcję dyrektora ro w firmie Fandom na początku 2016 roku, zauważyłem, że dwa nadzorowane przeze mnie zespoły niezależnie wykształciły ten rodzaj języka, nieświadomie i odruchowo ukrywając część niepowodzeń za zasłoną „prawie zrobione”.

Jako lingwista zwracam uwagę na te sformułowania, ponieważ kryją się za nimi poważne problemy, które mają realny wpływ na biznes. Postaram się pokazać, jak duży problem mogą sprawić te dwa słowa i jakie mają konsekwencje, jakie mogą być przyczyny pojawiania się tego zwrotu i wreszcie jak rozwiązać problem.

Potentially al most shippable, czyli wątpliwe zalety niedziałającego Scruma

Siłą Scruma i jednym z podstawowych założeń tej metodyki jest dostarczanie możliwie często skończonych, gotowych do wypuszczenia w świat wersji rozwijanego produktu. Zwieńczeniem każdego udanego cyklu (sprintu) ma być inkrement, możliwa do użytku (potentially shippable) wersja produktu. Dzięki temu założeniu poprawna implementacja Scruma skraca czas konieczny do uzyskania zysku z zainwestowanej pracy i czasu.

Zobacz również:

  • 9 cech wielkich liderów IT

„Prawie gotowe” utrudnia skorzystanie z tej zalety Scruma, sprawiając, że kolejne inkrementy produktu nie są gotowe do użytku, są natomiast wiecznie prawie gotowe, czyli de facto niegotowe. Jeśli problem „prawie gotowości” pojawia się nagminnie i nie jest korygowany, równie dobrze możemy sobie dać spokój ze scrumowym podejściem. Dlatego korekta jest konieczna.

W firmach, w których liczy się przewidywalność i dostarczanie kolejnych wersji produktu na określony termin, dodatkowym problemem jest również wpływ „prawie gotowe” na przewidywalność i odsuwanie momentu zakończenia pracy. A to z kolei może kaskadowo generować kosztowne opóźnienia w dostarczeniu finalnego produktu klientowi, sprawiać problemy w synchronizacji procesu produkcyjnego z zaplanowanymi kampaniami marketingowymi oraz całą masę innych problemów.

KONFERENCJA ZARZĄDZANIE ZESPOŁAMI IT 30-31 stycznia- sprawdź program >>

Nadmienię tutaj, że jeśli pojawia się problem „prawie gotowe”, a mimo to jakimś cudem projekt dostarczany jest na czas, to nie jest to powód do radości. Jest prawdopodobne, że finalny produkt ma wtedy gorszą jakość, niż powinien (co może generować koszty utrzymaniowe) albo że proces produkcji jest nieefektywny i dało się tę pracę wykonać w krótszym czasie.

Zgubny efekt nieprzyznawania się do błędów

Dzięki wprowadzeniu regularnych retrospektyw Scrum bazuje na pętli, która ułatwia zespołowi wyciąganie wniosków z błędów i konsekwentne ulepszanie sposobu swojej pracy. Niestety, „prawie gotowe” paraliżuje proces uczenia się na błędach i uniemożliwia analizę problemów. Dlaczego? Skoro „prawie się udało”, to znaczy, że nie jest to duży problem, prawda? Przecież niewiele brakowało. „Prawie” powoduje, że niemożliwe jest przyznanie się członka zespołu lub grupy jako całości przed sobą, do tego, że problem w ogóle wystąpił.

Taki nieuświadomiony problem nie może zostać omówiony podczas retrospektywy, często umyka też uwadze menedżera i w konsekwencji pozostaje nierozwiązany, i prawie na pewno powtórzy się w przyszłości. Ponieważ „prawie” paraliżuje możliwość zespołu do samoleczenia przez ukrywanie i bagatelizowanie problemu, sytuacja wymaga dostarczenia energii i interwencji scrum mastera lub menedżera.

Zanim jednak przejdę do tego, jak taką interwencję przeprowadzić, przyjrzyjmy się przyczynom powstawania problemu z „prawie”.

Powód: zła estymacja

Gdyby wszystko, do czego zobowiązał się zespół w danym sprincie, zostało wykonane, nie byłoby potrzeby używania „prawie” jako uniku. „Prawie gotowe” może oznaczać problem z estymacją zadań, nadmierny optymizm przy określaniu, co „zmieści się” w sprincie, lub błędne obliczanie velocity zespołu.

Na ten potencjalny powód problemu należy zwrócić uwagę, szczególnie jeśli „prawie gotowe” zadania ciągną się w nieskończoność.

Powód: brak focusu

„Prawie” w połączeniu z nieosiąganiem celów kolejnych sprintów to również sygnał, że zespół nie jest skupiony na celu. Może do sprintu brane są poboczne, mniej ważne zadania? Może środowisko w pracy rozprasza członków zespołu? Jest niemal pewne, że mamy do czynienia z brakiem focusu, jeśli „prawie gotowe” zadania regularnie rzeczywiście kończone są w 30 minut, godzinę czy pół dnia po zakończeniu poprzedniego sprintu.

Strach to ciemna strona Mocy, czyli co robi z ludźmi obawa przed osądem

Powyższe problemy zarówno z estymacją, jak i z focusem (oba opisywane rozlegle gdzie indziej) mogą jednak występować w zespole i nie prowadzić do wytworzenia się toksycznego odruchu „prawie gotowe”. Konieczny jest jeszcze jeden czynnik: strach. „Prawie gotowe” pojawi się tylko wtedy, gdy członkowie zespołu obawiają się (słusznie bądź nie), że za przyznanie się do niewykonania zadania czekają ich negatywne konsekwencje. Ważne, że nie chodzi tu o dotkliwe kary. Wystarczy obawa przed negatywną oceną przełożonej lub przełożonego, słowną bądź tylko przeczuwaną. Wykształcona ewolucyjnie reakcja walki lub ucieczki (w tym przypadku ucieczki) przydawała się naszym przodkom na afrykańskich sawannach, a nam na scrumowych spotkaniach niestety jedynie przeszkadza – a to właśnie z tym psychologicznym mechanizmem mamy tutaj do czynienia. Dlatego kluczowe jest zbudowanie relacji zaufania, która pozwoli wyeliminować lub przynajmniej zminimalizować potrzebę ucieczki i werbalnego maskowania niepowodzeń.

Zarażamy pozytywnie, czyli kreacja nowego memu w trzech prostych krokach

Jak widać, konsekwencje maskowania stanu faktycznego przez zmiękczające i wymijające używanie zwrotów w rodzaju „prawie gotowe” jest gorsze dla firmy i procesu tworzenia oprogramowania niż otwarte przyznanie, że dany wycinek pracy nie został ukończony. Przekazanie i wpojenie tego pracownikom można rozłożyć na trzy etapy, które zostaną przedstawione poniżej.

Opisany tu proces jest próbą stworzenia i zakorzenienia w zespole nowego memu, czyli wzorca postępowania i myślenia, określanego czasem mianem „wirusa umysłu”, który docelowo ma stać się częścią kultury firmowej. Skuteczne zarażenie pracowników zestawem pozytywnych memów pozwoli wywierać trwały wpływ na sposób działania zespołów i firmy.

Krok 1: prawie gotowe znaczy niegotowe

W pierwszej kolejności pokazujemy zespołowi, że „prawie gotowe” oznacza dla menedżerów i stakeholderów to samo co „niegotowe”. To zaznaczenie i pokazanie faktu, że używanie „prawie” nie stanowi drogi ucieczki.

Przykładowa scena ze sprint review:

Pracownik: Z siedmiu historyjek w sprincie dwie są jeszcze w toku, z czego jedna wymaga już tylko testów. Prawie skończyliśmy.

Menedżer: Okej, czyli... cel nie został osiągnięty i będziecie nad nim pracować w kolejnym sprincie, tak?

Ważne, żeby nie był to osąd ani wyrzut. Korygujemy język i pokazujemy stan faktyczny, nic więcej.

Sam poza werbalną reakcją na kilku spotkaniach podsumowujących sprinty wysłałem również do pracowników e-maila, w którym był zawarty powyższy przekaz, ale także przybliżyłem opisane powyżej konsekwencje. Ważne jest dotarcie z komunikatem do wszystkich członków zespołu, co może wymagać wykorzystania różnych środków komunikacji: e-maili, rozmów czy innych metod odpowiednich dla firmy i zespołu.

Krok 2: nagroda za mówienie wprost

Mając jasny obraz sytuacji, konieczne jest jeszcze zapewnienie, żeby członkowie zespołu zobaczyli, że za mówienie o tym nie tylko nie grozi kara, ale że wręcz należy się pochwała. To właśnie ten czynnik buduje dla pracowników bezpieczne środowisko, w którym zespół może podzielić się wynikami sprintu, bez obaw o reperkusje.

Przykładowa scena ze sprint review:

Menedżer: Jeden komentarz ode mnie na koniec. Dzięki za jasne pokazanie, co zostało skończone, a co nie.

Ważne, żeby odróżnić dwie kwestie. Nie chwalimy za nieukończoną pracę, to by było niepoważne. Chwalimy za jasne i klarowne mówienie o tym, co zostało osiągnięte, a co nie. Symetrycznie, na próby ukrywania stanu faktycznego (w większości zdrowych firm niecelowe) reagujemy impulsem negatywnym.

Przykładowa scena ze sprint review:

Pracownik: Ten kawałek jest już prawie zrobiony.

Menedżer: Nie „prawie”, tylko nie jest skończony. Słuchajcie, nie możecie owijać w bawełnę. Albo „done”, albo „not done”.

Krok 3: internalizacja komunikatu

Żeby to trafiło do zespołu i rzeczywiście zmieniło jego sposób myślenia i działania, mem musi zostać zakorzeniony w umysłach osób z grupy. Informacje i wnioski zawarte w powyższych przykładowych scenach należy powtarzać, aby zapadły w pamięć. W różnych sytuacjach i w różnych kontekstach.

Sygnałem, że osiągnęliśmy sukces i rozpoczęliśmy proces zmiany wewnątrz zespołu, jest dopiero podchwycenie i powtarzanie ww. komunikatów przez członków zespołu. Jeśli któryś z nich sam zwróci drugiemu uwagę na „prawie” lub pojawi się inna negatywna reakcja zespołu na użycie tego zwrotu, to znaczy, że wszyscy rozumieją, o co chodzi.

Taka zmiana nie następuje jednak od razu i konieczne jest powtórzenie komunikatu kilka lub kilkanaście razy w ciągu kilku tygodni lub nawet kilku miesięcy. Dużo zależy od częstotliwości powtarzania komunikatu, a więc także od przyjętej długości sprintów.

Podsumowanie

Pokazane językowe i psychologiczne wgryzanie się w znaczenie i przyczyny używania przez naszych pracowników problematycznych fraz może być kluczem do zdiagnozowania i rozwiązania problemów obniżających efektywność zespołu. Stosując uważnie i z rozmysłem jasne, klarowne komunikaty oraz mechanizmy kar i nagród, uda się stworzyć w głowach naszych koleżanek i kolegów nowy mem – trwałą ideę, która po zakorzenieniu w umysłach, zwyczajach i języku zespołu sprawi, że nie będzie wymagana już ingerencja ze strony menedżera.

Mem, którego stworzenie opisałem, można nazwać „prawie gotowe znaczy niegotowe” („almost ready means not ready”). Po wprowadzeniu go w pierwszym kwartale 2016 roku w moich dwóch zespołach w Fandomie przy okazyjnym utrwalaniu i odświeżaniu w ciągu roku, dziś ma się dobrze i będzie niebawem zaszczepiany kolejnemu zespołowi. Jego zakorzenienie się w zespołach pozwoliło bardziej otwarcie rozmawiać o problemach i dużo szybciej na nie reagować, co miało i ma pozytywny wpływ na przewidywalność prowadzonych prac.

Podobny mechanizm diagnozy i memetycznego rozwiązywania problemu można zastosować również do innych kwestii. Szerzej o memetyce i innych przykładach zastosowania memów w zarządzaniu opowiem podczas konferencji „Zarządzanie zespołami IT”, która odbędzie się 30-31 stycznia 2017 roku w Warszawie. Do zobaczenia!

„Prawie” robi wielką różnicę – o wpływie języka na proces tworzenia oprogramowania
Łukasz Garczewski, Director of Engineering, Fandom powered by WIKIA

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200