“Moim ludziom się nie chce” – przyczyny

Jak twoja organizacja hoduje Niechcemisie

(10 min)

Jeżeli wydaje Ci się, że Twoim pracownikom “nic się nie chce”, pomimo, że zatrudniacie najlepszych z najlepszych i opłacacie ich sowicie – zastanów się :

  • Czy Twoja firma pozwala pracownikom na szczerość?
  • Czy Twoi Menedżerowie potrafią i znajdują czas aby wysłuchać swoich podwładnych?
  • Jak traktujesz ludzi, którzy są “inni”, wybijają się, głośno krzyczą, mają dziwne pomysły, chcą wszystko zmieniać?
  • Kto podejmuje decyzje?
  • Czy przy podjęciu decyzji szeregowy pracownik ma szansę chociaż wypowiedzieć swoją opinię?
  • Jeśli popatrzysz na wasz produkt oraz na zespół developerski, jakie decyzje może on podjąć względem tego, jak wyglądać powinna ostateczna wersja produktu? Czy może zdecydować o tym jak przebiegać powinien proces wytwórczy bądź jakich technologii powinniście używać?

Dlaczego znalezienie szczerej odpowiedzi na te pytania jest ważne?

Od lat obserwuję organizacje i słucham pracujących w nich ludzi rożnych szczebli. Nie tylko z własnego otoczenia, ale i z rozmów ze znajomymi z innych firm oraz z wertowania niezliczonych książek o zarządzaniu można wyciągnąć wspólny mianownik.

Ogromnej większości pracowników, których zatrudniasz “chce się”. Wpadają no nowego miejsca pracy często zmęczeni barierami nie do pokonania w poprzednim i z nadzieją, że tu uda im się wszystko zacząć od nowa. Mają miliony pomysłów i często już po pierwszych kilku dniach docierają do ciebie pierwsze “listy żądań” dotyczące tego, co należy zmienić i jak powinniście zacząć pracować. To co zmienia ich w “korporacyjnych zombie” to to, jak zareagujesz, jak Twoja organizacja potrafi wspierać i wykorzystywać ten ich początkowy zapał.

To co najbardziej boli zespoły developerskie, to najczęściej:

  • Niemożliwość podejmowania decyzji odnośnie technicznych aspektów pracy.

Narzucając developerom architekturę, narzędzia, których mogą używać, wybierając za nich języki programowania i frameworki oraz narzucając procesy testowania aplikacji – zabijasz w nich kreatywność. Każda szanująca się developerka czy developer chce się rozwijać technicznie. Narzucając im ograniczenia, uniemożliwiasz im to, i jeśli sami nie będą mogli dokonywać wyborów lub choćby nie będą czuli, że ich zdanie zostało wzięte pod uwagę, a podjęta przez ciebie decyzja jest ugruntowana dobrem firmy i jest uzasadniona, to zaczną pracować z mniejszym zaangażowaniem, a po czasie zmienią pracę.

Jeśli twój projekt wymaga pewnych ograniczeń, np. jest to projekt z zakresu bezpieczeństwa, albo robisz aplikację dla branży fin-tech, lub automotive – gdzie źle podjęta decyzja, lub błąd mogą mieć katastrofalne skutki dla końcowego użytkownika, a tym samym oznaczać koniec twojej firmy, ograniczenia są oczywiste. Ale ludzie, których zatrudniasz naprawdę są inteligentni, i są w stanie to zrozumieć i zaakceptować. To czego im brakuje to:

  • Wiedzy o tym, w jakich ramach mają swobodę wyboru, a w jakich nie, i dlaczego? Z czego wynika to, że np. nie mogą samodzielnie zaprojektować architektury albo, że używacie “starej wersji” oprogramowania albo, że język w którym piszecie musi być taki, a nie inny?
  • Dostępu do jasno określonych wytycznych, w których znajdą uzasadnienie takich, a nie innych wyborów technicznych, oraz wizję rozwoju produktu, która pozwoli im ocenić czy ich propozycje (które mogą krótkoterminowo faktycznie mieć większy sens) spełnią wymogi stawiane przed produktem w przyszłości.
  • Upewnij się, że podjęta przez architektów decyzja techniczna nie spływa na zespół bez uzasadnienia. Jeśli, ktoś podjął taką, a nie inną decyzję musiała za tym przeważyć siła konkretnych argumentów. Naucz swoich liderów, również tych technicznych, aby zawsze podawali uzasadnienie swoich decyzji. Zazwyczaj wymaga to tylko dodatkowych kilku minut spotkania, a pozwala pracownikom odczuć, że się ich szanuje. Kiedy “szeregowy developer” rozumie skąd się wywodzi techniczna decyzja, nawet jeśli się z nią w pełni nie zgadza – zazwyczaj zrobi wszystko, żeby wypełnić oczekiwania najlepiej jak potrafi.

Jeśli czujesz, że Twoje zespoły developerskie biernie lub aktywnie stawiają opór podejmowanym decyzjom technicznym, nie zakładaj ich złej woli. Poświęć czas aby przyjrzeć się temu w jaki sposób podejmowane są te decyzje i w jaki sposób są komunikowane zespołom. Narzucanie decyzji bez uzasadniania ich może i jest łatwiejsze ale szybko sprawi, że twoi developerzy poczują się nie brani pod uwagę i faktycznie “nie będzie im się chciało” więcej niczego proponować.

  • Brak zrozumienia struktury korporacji.

Często, kiedy Twoja organizacja jest naprawdę duża – jej bezwładność i nadmiar “warstw menedżmentu” w połączeniu z tym, że nie wiadomo kogo należy słuchać, bo wszyscy są tak samo ważni – uniemożliwiają normalną pracę zespołów developerskich wprowadzając chaos decyzyjny na poziomie priorytetów projektu.

Jeśli Twoje zespoły developerskie narzekają na zbyt częste zmiany priorytetów, to nie znaczy, że są “anty-Agile”. To może znaczyć, że każde zapytanie od kogoś wyższego stopniem, uwagę czy informację, która do nich dotrze traktują jak polecenie służbowe i zaczynają je wykonywać przełączając konteksty aktualnych zadań. Niestety często w dużych firmach widuje się takie sytuacje. Ratunkiem jest posiadanie silnego Product Ownera, który jest w stanie odfiltrować sensowne pomysły na dodatkowe funkcje od tych mniej sensownych oraz odpowiednio je priorytetyzować. Nawet jeśli Twoja firma nie pracuje w metodykach zwinnych, powinniście zrobić wszystko, żeby zespoły developerskie wiedziały kogo mają słuchać. Ich zagubienie często wynika z tego, że bardzo chcą wszystkich zadowolić, tylko z każdej strony spływa do nich zbyt wiele żądań. Tak jak dziecko, którego rodzice próbują mu wpoić ich własne wizje tego, kim powinno zostać kiedy dorośnie, tak zespół deweloperski nie może być “szarpany” na wszystkie strony przez menedżment lub stakeholderów, którzy nie wiedzą czego chcą albo jest ich zbyt wielu by spełnić oczekiwania ich wszystkich. Bo w końcu się zbuntuje, a skutki mogą być bardzo nieoczekiwane.

W takim wypadku zespołowi należy zapewnić ochronę w postaci jednej decyzyjnej osoby, przez którą będą przechodziły wszystkie żądania odnośnie zmiany priorytetów.

  • Mikro-menedżement i brak możliwości samo-organizacji.

Zdarzają się oczywiście jednostki, które uwielbiają kiedy pokazuje się im palcem co mają zrobić i ściąga z nich całą odpowiedzialność. Jednak czy zawsze warto w nie inwestować “rynkowe stawki”? Skoro już zdecydowaliście się jako firma zatrudniać tylko najlepszych, wykorzystujcie ich potencjał, bo oni tego właśnie oczekują!

Większość frameworków Zwinnych opiera się na samo-organizujących się kros-funkcjonalnych zespołach. Niestety struktura sporej części dużych przedsiębiorstw nie tylko ich nie wspiera, a wręcz zapobiega ich powstawaniu. To, z czym możemy się często spotkać to np. firmy, które posiadają osobne piony liniowe dla testerów oraz developerów. Zdarza się nawet, że takie zespoły pracują niezależnie, nawet się nie znając. Czekają tylko wzajemnie na wyniki swojej pracy, obwiniają się o wynikłe opóźnienia i brak kompetencji. Ale nawet jeśli pracują w jednym zespole to i tak, odmienna struktura liniowa, czasem odmienne standardy “dostarczania” tworzone dla developmentu i dla testów sprawiają, że testerzy bywają traktowani i mogą czuć się jak istoty niższej kategorii. Ciężko jest na dłuższą metę utrzymać motywację takich osób oraz wewnętrzną spójność takich zespołów. Nie udawaj, że twoja organizacja jest Agile, jeśli nie potrafisz zaimplementować wartości wspierających kross-funkcjonalnosć!

To, co należy zmienić jak najszybciej, to wymienić mikro-menedżerów na (lub zmienić w) edukatorów, którzy pomogą Twoim zespołom w dążeniach do kros-funkcjonalności, samo organizacji oraz umiejętności przyjmowania odpowiedzialności za podejmowane decyzje.

Na początku możesz poczuć silny opór. Część “specjalistów” ma wyraźną opinię na temat tego w jaki sposób powinni się rozwijać i jest to najczęściej rozwój pionowy, w głąb swojej głównej roli. Część programujących osób w zespole będzie zamknięta na to, aby uczyć się nowych rzeczy uważając, że “nie zostali zatrudnieni do testowania”, a część testerów będzie przerażona wizją Twoich nowych oczekiwań. Procent testerów, z którymi rozmawiałam naprawdę podświadomie uważa się za “mniej zdolnych”, otoczenie niestety karmi ich często stereotypami, według których próg wejścia w rolę testera jest dużo niższy niż dla developementu, część wybiera tę drogę nie z pasji do testowania tylko dlatego, że obawiają się, że nie poradzą sobie z programowaniem, takie osoby trzeba otoczyć szczególną troską i pomóc im przełamać tę błędną opinię oraz wspierać w rozwoju nowych umiejętności. Szczerze mówiąc to od nich często zaczyna się transformacja zespołów w kierunku kros-funkcjonalności i dlatego takie osoby są naprawdę bardzo cenne dla prawdziwej transformacji. Z czasem chętnych do dzielenia się wiedzą oraz nabywania innych kompetencji znajdzie się więcej i wiedza będzie przepływać w obu kierunkach. Należy tylko z całego serca to chwalić, wspierać, nagradzać i zatrudniać nowych ludzi, którzy są na to otwarci, a także samemu być przykładem i zdobywać nowe kompetencje spoza własnej strefy komfortu.

  • Pierwszym krokiem do wyeliminowania mikro-menedżmentu jest więc zadbanie o odpowiednią strukturę liniową zespołów developerskich. Jeśli masz zbyt wiele zespołów aby sprawnie zajmował się nimi jeden menedżer, spraw aby jeden menedżer odpowiadał za od jednego – do trzech zespołów (maksimum trzydzieści osób) i aby każdy zespół posiadał wszystkie kompetencje, które są potrzebne do stworzenia produktu.
  • Wspieranie rozwoju przez każdego z członków zespołu wszystkich kompetencji, które będą im potrzebne aby dostarczyć działający produkt.
  • Jasne określenie oczekiwań od zespołu oraz zakresu w jakim zespół może swobodnie podejmować decyzje.
  • Upewnienie się, że członkowie zespołu rozumieją jaka jest ostateczna wizja produktu, nad którym pracują, i że rozumieją kierunek, w którym zmierza organizacja.
  • Wspieranie zespołu w samo-organizacji oraz pozwalanie im na błędy jednocześnie pilnując aby z potknięć wyciągana była nauka na przyszłość, a nie konsekwencje.

Większość uznanych menedżerów przyznaje, że „upadku” nie należy traktować zbyt poważnie. Ed Catmull mawiał, że „Niepowodzenie nie jest złem koniecznym. Ba, to nawet nie jest zło. Jest to tylko oczywista konsekwencja robienia czegoś nowego”.

Podobnie do porażek zdają się podchodzić Suzy oraz Jack Welch. W swojej książce „Praktyczne MBA” (Wydawnictwo Studio Emka), koncentrują się na tym, jak wyciągnąć wnioski z porażki, a nie na tym, jak jej unikać.

1. Przyznaj, że się walnąłeś.

2. Nie przestawaj dawać z siebie tego, co najlepsze.

3. Zacznij obsesyjnie kontrolować czynniki decydujące o kosztach, wydajności i rozwoju, sugerując się dostępnymi danymi.

4. Odnów strategię.

5. Zweryfikuj swoją architekturę społecznościową.

6. Martw się efektywniej.

Jack & Suzy Welch, „Praktyczne MBA. Jak mądrze zaplanować karierę, stworzyć wspaniały zespół, zdynamizować wzrost i wygrać”, Wydawnictwo Studio Emka.
  • Brak określonych wymagań.

W tym konkretnym punkcie nie zgodzę się z szeroko dzieloną na rynku opinią developerów.

Niestety naprawdę niewielki procent firm, które deklarują, że pracują Zwinnie, najczęściej twierdząc, że pracują w metodyce Scrum robi to dobrze. Dzień w dzień borykam się z developerami ziejącymi nienawiścią do tej metodyki i próbującymi podważyć jej sensowność oraz skuteczność. Staram się podchodzić do tego z dozą spokoju oraz wyrozumiałością, bo wiem, że wyciągają oni wnioski, nie na podstawie doświadczenia pracy w samej metodyce, a na podstawie tego, jak źle pracowało im się w konkretnej implementacji tej metodyki w konkretnej firmie. O tym jak powinno i jak nie powinno się implementować Scrum w organizacji możemy porozmawiać kiedy indziej Teraz skupmy się na tym, dlaczego prawie każdy developer powie Ci, że jego obowiązkiem nie jest definiowanie wymagań oraz dlaczego uważa że jest to “blokerem” dla jego pracy.

Przy założeniu, że jesteś jedną z niewielkiego ułamka firm, które z sukcesem zaimplementowały Scrum (Gratulacje! 😀 Zaproś mnie, chciałabym zobaczyć jak sobie radzicie!) Twoje zespoły Scrumowe są w pełni niezależne, kros-funkcjonalne, składają się z ludzi, którzy oczywiście mogą mieć swoje specjalizacje, ale są w stanie zastąpić siebie nawzajem w ramach wszystkich potrzebnych zespołowi kompetencji. Członkowie zespołu czują się odpowiedzialni za wszystkie etapy dostarczania produktu do użytkownika końcowego oraz za wsparcie techniczne klienta lub użytkownika. Takie zespoły potrafią również zebrać od użytkowników końcowych wymagania, oraz zaproponować usprawnienia lub nowe funkcjonalności produktu. Tak jak zaznaczyłam, najprawdopodobniej zbieranie i opracowywanie wymagań nie będzie równo rozłożone na wszystkich członków zespołu Scrumowego, tylko ciężar tej odpowiedzialności najprawdopodobniej spadnie na Product Ownera. Scrum Giude mówi nam o tym, że Product Owner jest osobą, która ponosi konsekwencje – odpowiada za produkt, często zajmuje się zbieraniem wymagań oraz przekazywaniem ich do zespołów w formie “historyjek użytkownika” ale może też zlecić to zadanie zespołom, pozostając jednocześnie odpowiedzialnym za wynik takiego działania. Tego już niestety nie uczy się zespołów Scrumowych. W większości implementacji tej metodyki odcina się zespół od użytkowników, od zbierania wymagań, od generowania pomysłów, od decydowania o tym co powinno być zaimplementowane i od priorytetyzacji zadań. A szkoda. Bo widziałam taki zespół w działaniu. Miałam przyjemność go tworzyć i w nim pracować i było to dla mnie najwspanialsze doświadczenie. Poczucia odpowiedzialności, wolności, rozumienia potrzeb użytkownika i tego, że mam możliwość realnego wpływu na rozwój produktu, który tworzymy. Jeśli jesteś w stanie zapewnić to wszystko swojemu zespołowi, brak wymagań nie będzie dla niego problemem, bo będą czuli się współodpowiedzialni za dosłownie każdy etap produkcji, w tym za definicję produktu.

W rzeczywistości jednak, mało która firma jest zdolna stworzyć takie warunki. Nie chcę tu wartościować tych firm, którym się to nie udaje, bo być może po prostu Scrum nie jest dla nich odpowiedni ze względu na specyfikę wytwarzanego produktu. Nie ma w tym absolutnie nic złego, tylko przyznajmy się do tego i spróbujmy wymyślić coś innego, co będzie działać lepiej zamiast próbować wcisnąć kwadrat w trójkątną dziurę plastikowej zabawki dla dzieci.

Ponieważ miałam możliwość tworzenia zespołu, który był w stanie sam tworzyć i proponować wymagania wiem, że jest to możliwe i daje ogrom satysfakcji. Jednak jeśli z jakichś względów w Twojej firmie takie podejście nie zda egzaminu, to faktycznie musisz zadbać o to, żeby zespoły developerskie były karmione dokładnymi wytycznymi odnośnie tego CZEGO się od nich oczekuje, informacjami CO ma zostać dostarczone ale sformułowanymi w taki sposób aby nie narzucały tego JAK dana funkcjonalność ma zostać zaimplementowana. Wybór konkretnego sposobu implementacji to prawo zespołu developerskiego takie samo jak prawo do oddychania.

Zadbaj aby informacja o tym CO ma zostać dostarczone, często właśnie w formie “historyjki użytkownika” miała określoną strukturę, między innymi wyjaśniała:

  • dlaczego jako użytkownik potrzebujemy danej funkcjonalności,
  • w jakich przypadkach będziemy jej używać oraz
  • jakich spodziewamy się wyników.

Zadbaj o to, aby zespół zanim przystąpi do zastanawiania się nad tym JAK zaimplementować daną funkcję wiedział jakie są „kryteria akceptacji” od użytkownika. Bo przecież jeśli użytkownik chce mieć coś, z czego będzie się mógł napić wody, to sposobów na wykonanie implementacji jest naprawdę wiele. Oszczędzi ci czasu i pieniędzy jeśli od razu wyspecyfikujesz wspólnie z użytkownikiem czy istnieją jakieś minimalne oraz optymalne warunki jakie musi spełnić dana implementacja. Np. czy dostarczone naczynie musi mieć uszko. Dzięki temu twój zespół nie zaproponuje wykonania butelki tylko od razu zacznie projektować garnuszek lub kubek.

  • Przedkładanie formy nad treść.

Uważaj, żeby nie wprowadzać zbyt wielu zasad. Może i upraszczają życie menedżerowi, ale mogą być poniżające dla tych 95 procent osób, które zachowują się właściwie. Nie twórz zasad tylko po to, żeby zapanować nad pozostałymi 5 procentami – indywidualnie podchodź do wszelkich wykroczeń przeciwko zdrowemu rozsądkowi. Owszem, będziesz miał więcej pracy, ale w rezultacie stworzysz zdrowsze środowisko.

Kreatywność S.A. Droga do prawdziwej inspiracji. Ed Catmull. Wydawnictwo MT Bizness.

Procesy, procesy i jeszcze raz procesy. Im bardziej twoja firma próbuje unikać popełniania błędów tym częściej będzie do nich dochodzić – niejako z premedytacji. Developer nie jest złym człowiekiem, który tylko pragnie odwalić swoje 8 godzin, minus godzina na obiad, minus 4 herbaty po 20 minut, minus dwie kawy po kwadransie no i oczywiście odjąć lunch, powiedzmy ze 30 min – w końcu nie zdrowo jest jeść zbyt szybko… Mam wrażenie, że czasem ludzi w korporacjach przelicza się na komórki w excelu o określonej wartości wyrażonej w “men-dejach”, a potem buduje się procesy oraz dobudowuje się kolejne poziomy kontroli mające sprawdzić czy efektywność developerów rośnie.

Uwielbiam wprost przypadki, kiedy zespół zaharowując się na śmierć, pracując w weekendy i po godzinach, po Sprint Review słyszy od swojego Program Menagera (czy kogokolwiek innego kto zajmuje się w twojej firmie “delivery”): “O! Świetnie dostarczyliście w tym Sprincie 100 Story Pointów (gumi-jagód, ziemniaków, nie ważne, dla menedżerów to bardzo często i tak są “men-deje” i nie próbują nawet zrozumieć, że największą głupotą jest próba przeliczania jednej jednostki bezpośrednio na drugą, zwłaszcza nie mając żadnych danych historycznych!), to teraz pomyślcie, co możecie zrobić żeby w następnym Sprincie podnieść tę wartość do 150 Story Pointów”.

No w takiej sytuacji wiadomo co można zrobić. Zwiększyć wycenę! I żadne procesy i żaden raport i żaden Project Manager nie będzie w stanie tego wykryć.

Jeśli narzucamy na zespoły developerskie zbyt wiele wymagań, nie rozumiejąc tego w jaki sposób pracują zmuszamy je do oszukiwania. Nikt nie przychodzi do pracy z myślą “Jak by tu dzisiaj sabotować pracę mojej firmy? Sasasasasa (złowieszczy śmiech)”. Ale jeśli będziecie budować procesy, które nie mają na celu usprawnienia pracy waszych zespołów, a służą jedynie waszym menedżerom w zwiększeniu poczucia kontroli jesteście przegrani. Zniszczyliście transparencję, szczerość i zaangażowanie za jednym zamachem.

Jeśli te podstawowe punkty nie są odpowiednio zaimplementowane w Twojej firmie, to może warto zastanowić się nad tym, czy Twoim developerom faktycznie “się nie chce” czy po prostu “nie są w stanie” wypełniać swoich obowiązków i w pełni angażować się w pracę oraz kształtowanie przyszłości waszej organizacji?

2 thoughts on ““Moim ludziom się nie chce” – przyczyny

Comments are closed.