Jak menedżerowie marnują potencjał programistów - 10 sposobów

Menedżerowie i programiści bardzo często mają dość napięte relacje. Może to być związane ze zderzeniem się postrzeganych przez nich rzeczywistości. Wielu menedżerów dąży do maksymalizacji możliwości swoich zespołów, natomiast programiści zmagają się ze złożonością budowania oprogramowania.

Takie zderzenie rzeczywistości to istotna przyczyna wielu szkodliwych interakcji między menedżerami a programistami.

Oto dziesięć powodów, przez które menedżerowie marnują potencjał programistów. Chwyć swoją kartę bingo i sprawdź, ile z nich jest dla Ciebie rzeczywistością!

1. Składanie obietnic interesariuszom bez zgody dewelopera

Zacznijmy od tej perełki:

„Dzień dobry! Właśnie miałem spotkanie z naszym klientem. Chcą, abyśmy zbudowali ich aplikację onboardingową. Umówiliśmy się, że będzie gotowa pod koniec roku”

Jeśli kiedykolwiek Twój menedżer wypowiedział takie zdanie, to wiesz, że znalazłeś się w tarapatach. Ktoś inny złożył obietnice, których musisz dotrzymać bez wyrażenia swojej zgody.

Jakkolwiek absurdalne się to wydaje, dzieje się tak cały czas. Perspektywa generowania większych przychodów jest zbyt kusząca, aby powstrzymać się od obiecywania rzeczy, które są zdecydowanie nie w porządku.

2. Definiowanie rozwiązania

Wielu menedżerów sami byli kiedyś programistami. Czego absolutnie nie powinni robić, to dalej odgrywać tej właśnie roli. To nie od nich zależy, jak ma być zbudowane oprogramowanie.

I jest to naprawdę demotywujące, gdy ktoś mówi ci, że należy zbudować oprogramowanie w określony sposób. Nawet jeśli menedżer przedstawia to jedynie jako propozycję, to może to być toksyczne ze względu na dynamikę władzy. Nie każdy deweloper będzie otwarcie kłócił się z menedżerem.

A jeszcze gorsi są menedżerowie, którzy nie mają żadnego zaplecza programistycznego, a mimo to mają czelność proponować rozwiązania. Jak oni to sobie wbijają do głowy, że w swojej specjalności będą mieli większe know-how niż programiści? Nie mówiąc już o tym, że przekroczyli zakres własnych obowiązków.

3. Przekonywanie deweloperów do zmniejszenia szacunków

Zawsze mnie to dziwi, że menedżerowie mogą wątpić w szacunki swoich deweloperów. Normalnym zachowaniem byłoby zaakceptowanie oceny dewelopera dotyczącej złożoności pracy i wysiłku włożonego w stworzenie oprogramowania.

Jednak wielu menedżerów uważa, że w ich prawie jest dokręcenie śruby i rozpoczęcie gry negocjacyjnej w celu obniżenia szacunków. Jest to złe pod wieloma względami:

• deprecjonuje autorytet dewelopera w zakresie budowy oprogramowania,
• jest to oznaka braku zaufania,
• wywiera presję na dewelopera, aby zmniejszył szacunki.

Kiedy menedżerowie zaczynają tę grę w targowanie się, konsekwencje są katastrofalne, a deweloperzy stają się ofiarami gry o władzę.

4. Uznanie szacunków za obietnice

Zanim firma zdecyduje się zainwestować czas, ludzi i pieniądze w przedsięwzięcie, logiczne jest, że istnieje pełne zrozumienie, czy inwestycje mają szansę być opłacalne.

W przewidywalnych środowiskach, gdzie wiadomo, co trzeba zrobić, aby osiągnąć zamierzone rezultaty, można przeprowadzić dokładną analizę, a następnie mieć dobre rozeznanie co do oczekiwanych inwestycji.

Jako przykład przewidywalnego środowiska, spójrzmy na budowę domu. Zazwyczaj zaczyna się od wykonania projektu przez architekta. Na tej podstawie można zrozumieć, co trzeba zrobić w jakiej kolejności i w jakich kosztach wybudować dom.

Ten tradycyjny sposób tworzenia dokładnego projektu, a następnie szczegółowego planu, który jest skrupulatnie przestrzegany, nie sprawdza się w przypadku produktów oprogramowania, ponieważ jego rozwój jest pracą złożoną, a produkty oprogramowania rezydują w złożonej domenie.

A w złożonych domenach nie wiadomo, co może się wydarzyć. Być może masz pojęcie, ile pracy wymaga stworzenie przyrostu oprogramowania, jednak w większości przypadków zobaczysz, że twoje szacunki nie są zgodne z rzeczywistością.

Musisz uwzględnić niepewność i regularnie weryfikować swoje założenia, zamiast kurczowego trzymania się szacunków, które sporządziłeś, zanim dowiedziałeś się rzeczy, które wiesz dzisiaj. W związku z tym szacunki nigdy nie mogą być traktowane jako obietnice, a jedynie jak najlepsze przypuszczenia, do pracy z ograniczonymi informacjami, które posiadałeś w danym czasie.

5. Pozwalanie ludziom na zakłócanie pracy dewelopera

Tworzenie oprogramowania to twórcza praca, która wymaga skupienia i czasu. Deweloper pracuje najlepiej, gdy nikt mu nie przerywa. Za każdym razem, gdy ktoś mu przeszkadza, są wytrącani z trybu swojej pracy. Oprócz czasu, jaki zajmuje przerwa, dochodzi jeszcze dodatkowy czas, jaki trzeba poświęcić na powrót do tego trybu.

Ale strata czasu nie jest tutaj jedynym problemem. Wpływa to również na morale dewelopera. To frustrujące, kiedy jest się odciąganym od pracy tak natarczywie.

Menedżerowie, którzy pozwalają na regularne przerywanie pracy, mogą nie zdawać sobie sprawy z tego, jak bardzo jest to szkodliwe. Lepiej jednak, żeby szybko się tego nauczyli, bo jest to główny zabójca morali.

6. Dokładanie pracy ponadplanowej

Ilekroć deweloperzy zobowiązują się do pracy nad zestawem działań lub osiągnięcia konkretnego celu, złym zwyczajem jest dodawanie rzeczy do tego zestawu zaledwie kilka dni później. Co więcej, bardzo często menedżer ma czelność oczekiwać, że zespół będzie nadal angażował się w realizację pierwotnego planu, a także w dodatkową pracę.

Jasne, mogą pojawić się nowe spostrzeżenia, które mogą wpłynąć na plany. Nie powinno to jednak skutkować dodatkową pracą i w efekcie dodatkową presją wywartą na deweloperach. Powinien być jakiś kompromis. Coś musi najpierw spaść z listy, zanim będzie można dodać kolejne zadanie do wykonania.

Może się to wydawać nieznaczące, jednak  menedżerowie stale tak działają. Co dla mnie jest nie do pomyślenia.

7. Jakość na skróty

Tworzenie oprogramowania ma charakter złożony, a to oznacza, że podczas wykonywania pracy uczysz się czegoś nowego. Nowe spostrzeżenia, które mają wpływ na planowanie. I w większości przypadków może to doprowadzić do niezakładanej dodatkowej pracy.

Nowa wiedza ze względu na złożoność będzie miała wpływ na przewidywane terminy deliverek. Można było coś z tym zrobić wcześniej, zmniejszając zakres działania i dostarczając mniej niż planowano. Ja jednak wiele razy widziałem, jak wielu menedżerów odpowiada w inny sposób, prosząc o pominięcie części pracy, często testów.

Argumentują oni tym, że programiści wiedzą, co robią, a testy na ogół nie wykrywają wielu błędów, i tym samym proszą o pójście na skróty z jakością.

Prosząc o coś takiego, menedżerowie ignorują fakt, że działający produkt wysokiej jakości jest ważniejszy niż dostarczenie go „na czas”. Dostarczenie wadliwego produktu, byle w czasie, tak czy siak wróci do ciebie ze zdwojoną mocą, a użytkownicy nie będą zbytnio zadowoleni.

8. Naciskanie na pracę w nadgodzinach

Inną alternatywą w celu pozyskania czasu są nadgodziny. Albo takie jest rozumowanie wielu menedżerów. Jest to jednak ignorowanie faktu, że praca w nadgodzinach może testować granice developerów.

Deweloperzy powinni jednak pracować w stałym rytmie. Jest to tempo pracy, które pozwala im być efektywnymi. Nadwyrężanie i przesuwanie ich granic nieuchronnie prowadzi do błędów, co z kolei prowadzi do poprawek i ostatecznie opóźnień.

Taka taktyka nie sprawi, że będą szybsi. I co więcej, ryzykujesz ich wypaleniem.

9. Postrzegaj porażkę jako coś złego, a nie jako naukę

Pamiętam wiele nieprzyjemnych sytuacji, kiedy musiałem powiedzieć mojemu menedżerowi, że musieliśmy opóźnić datę dostawy z powodu czegoś nieoczekiwanego podczas opracowywania naszego produktu. Po czym dostawałem solidny wykład, że oczekiwał, że będę bardziej profesjonalny.

Tworzenie oprogramowania to złożony proces. Jest to proces twórczy, w którym deweloper będzie się również uczył nowych rzeczy. Założenia, które mogłeś mieć na początku tej podróży, mogą okazać się błędne. I jest to całkowicie w porządku. Chodzi o to, aby się uczyć, a następnie adaptować, aby wcielić te nauki w życie.

Zbyt często menedżerowie postrzegają te nauki jako porażki. Deweloper powinien był lepiej przeanalizować temat, aby uniknąć niespodziewanych wpadek. Jednak w złożonym środowisku nigdy nie wiadomo, co może się wydarzyć po drodze. Nie da się tego przewidzieć. Każda nowa wiedza pomaga w dążeniu do celu.

10. Przyjmowanie oklasków

A kiedy jesteśmy już na końcu podróży, po dostarczeniu klientowi rozwiązania programowego, menedżer zbiera laury. Bo przecież bez niego nikt nie osiągnąłby takiego sukcesu.

Dopilnuje, aby klienci i organizacja o tym wiedzieli. Ich rola zostanie w dużej mierze przeceniona kosztem deweloperów.

Nie tolerujcie takiego zachowania!

Jesteś deweloperem i rozpoznajesz tutaj swojego menedżera? Nie toleruj takiego zachowania i domagaj się zmian, ponieważ te anty-wzorce nie tylko szkodzą Tobie, ale także firmie. To nie jest sposób na tworzenie wartości i w ten sposób firma się nie rozwija.

Być może masz w swoim gronie osoby, które mogą pomóc Ci wprowadzić te zmiany. Być może jest możliwość sojuszu ze Scrum Masterem lub Agile Coachem.

A może jesteś menedżerem i identyfikujesz się z powyższymi zachowaniami? Czy Ty też zabijasz kreatywność i autonomię u swoich programistów? Szkodząc przy tym swojej firmie? Jeszcze nie jest za późno na zmiany. Przyjmij do wiadomości, że tworzenie oprogramowania to skomplikowana praca. I zamiast szkodzić zespołowi, wspieraj ich w działaniach. Gwarantuję, że szybko zobaczysz pozytywne efekty.