2d9c71ba879046eb02bb2b2b6c57c6d12264ece4a6efd081e8 pimgpsh fullsize distr
DataArt działa od 1997 roku. Zajmuje się konsultingiem i outsourcingiem usług IT. Jej polskie biura zlokalizowane są w Lublinie i Wrocławiu.

Eugene Efimov, QA Lead w DataArt, kontynuuje temat managerskiej efektywności, mówiąc o dobrych praktykach i ważnych błędach, które zdarzyło mu się popełnić na przestrzeni lat. Pierwsza część tekstu dostępna jest tutaj.

6. Mikrozarządzanie (najbardziej toksyczny zwyczaj; stoi za nim niekompetencja; niekorzystna zarówno dla ciebie jak i twojego zespołu; zwiększa ryzyko niedoszacowania na rzecz klienta)

Sytuacja pogarsza się zdecydowanie, kiedy zaczynasz bawić się w mikrozarządzanie. Problem jest związany również z poprzednimi przykładami. Myślisz, że nie jesteś wystarczająco zajęty, potem orientujesz się, że ludzie, którymi jesteś otoczony popełniają błędy, mijasz się z terminami i masz złe wyniki. Jedyną rzeczą, którą możesz zrobić jest podchodzenie do nich w odstępach pięciominutowych i ciągłe pytanie: „Kiedy to będzie gotowe? Sprawdziłeś wszystko?”. Zrób to dziś, a jutro wszyscy cię znienawidzą. To okropne i dla ciebie i dla twojego zespołu. Dlatego, że myślisz: „Zapytałem tego i tamtego gościa… O matko, zajęło mi to 15 minut?”.

Za tym wszystkim stoi poczucie braku kompetencji. Jeśli wiesz, że jesteś dobrym managerem i wiesz, co dzieje się w projekcie, nigdy nie wpadniesz w pułapkę mikrozarządzania. Jeśli nie rozumiesz, co dzieje się dookoła ciebie, masz poczucie zupełnej utraty kontroli, próbujesz zwracać uwagę na wszystko i zwracasz się w kierunku mikrozarządzania. To tragiczne w skutkach dla wszystkich ludzi związanych z procesem, łącznie z twoim klientem, dlatego że co 15 minut „wystawiasz” go na to, co dzieje się w projekcie, powtarzasz, że wszystko jest ok i że nie macie problemów. W tym momencie klient przyzwyczaja się do takiej sytuacji i będzie oczekiwał tego samego przez cały czas.

Jest również szansa na zbudowanie w ten sposób chorego systemu. Takiego, który nie jest w stanie niczego wyprodukować, ale celuje w ciągłe upewnianie się, że ludzie z niego nie wyjdą, nieważne, jak źle czują się jako część tego systemu. Zazwyczaj działa to na zasadzie poczucia winy i odpowiedzialności, ciągłej pracy w pośpiechu i obietnic, że lepsza przyszłość w projekcie niedługo nadejdzie.

7. Robię to, co powinno być zrobione najpierw i raportuję (pokłosie inżynierii; to musi być zrobione – nie ma czasu do stracenia; nie ma mowy o przejrzystości; napięcie wzrasta; wzrastają szanse zrobienia czegoś źle; spada poziom zaufania; wali się horyzont)

To dość interesujący punkt. Masz do czynienia z przełomem, musisz zaangażować większą ilość ludzi i naprawić wszystko tak szybko, jak to możliwe. Musisz też zaoferować klientowi najlepsza wersję i pokazać, że projekt ciągle robi postępy. I planujesz odezwę do zespołu: „Pracujmy!” – zapominasz o takich rzeczach jak raporty, Jira, Taxco, Burndown, planując wszystkie zmiany w odniesieniu do tego, co dzieje się w danej chwili.

Prowadzisz swój zespół w trakcie bitwy jako lider, ale nie jako manager. Przekonujesz ich i poprawiasz nastroje. Opowiadasz wszystkim, jak ważne jest skończenie całości. Ciągle powtarzasz: „Co zrobiłeś do tej pory? Sprawdźmy”. Dbasz o współpracę z inżynierami dbającymi o serwery, by wszystko działo się szybko i wydajnie. Ogólnie rzecz ujmując, ciągle rozwiązujesz problemy. Raporty? Przecież wiadomo bez żadnych raportów, że każdy w tym momencie ciężko pracuje. Wszyscy pracują na pełnych obrotach. Zespół przełączył się na tryb kryzysowy i działa z fantastyczną wydajnością, wydaje się, że jesteście w stanie rozwiązać wszystkie problemy.

Ale tak naprawdę sytuacja wygląda odrobinę inaczej. Dzieje się źle – spada przejrzystość zadań, klient nie rozumie co się dzieje, widzi tylko, że wszyscy biegają w popłochu. I nie ma pojęcia na jakim etapie znajduje się w tym momencie jego produkt. I nie wie, kiedy wszystko będzie gotowe.

Wzrasta napięcie wewnątrz zespołu, na zewnątrz również. Klient traci zaufanie i zaczyna wywierać presję na zespole, jeśli nie dostaje wystarczająco przejrzystych i szczegółowych raportów. Presja wywierana na zespół narasta i nikt nie czuje się dobrze.

Cały horyzont, na którym widziałeś zaplanowane zadania, zawala się. Nie masz pojęcia, co się dzieje. Myślisz o specyficznych małych kategoriach zadań, wyzwań i problemów, które powinny być w tym momencie rozwiązane, żeby wszystko się wyprostowało. I nie jesteś już w stanie przewidzieć tego, jak twój produkt będzie wyglądał za tydzień, czy miesiąc, dlatego, że cały plan się zawalił. Nawet jeśli praca w takim trybie, bez raportów i planów, oparta na pomocy wszystkim wydaje się być ok, lepiej nie rób z tego zwyczaju!

8. Horyzont runął (zwrot w kierunku celów i taktyk krótkoterminowych; możemy zderzyć się z górą lodową, możemy zboczyć z kursu; narasta zdenerwowanie)

To mała impresja na temat walącego się horyzontu i planów. Zwracasz się w kierunku krótkoterminowych celów i do nich dostosowujesz taktykę. To zdarza się, kiedy pracujesz w swoim projekcie pod presją czasu. I jeśli zwróciłeś uwagę na wszystkie poprzednie rzeczy, prawdopodobnie wszystko się uda. Po pierwsze możesz nie zauważyć czegoś dużego i istotnego – czegoś, o czym zapomniałeś na samym początku, dlatego, że wcześniej wyleciała ci z głowy odpowiedzialność i okazuje się, że najpierw nie dałeś rady z „polubieniami”, na początku miałeś zdjęcia, ale właściwie dobrze byłoby streamować wideoklipy. A rozwiązanie tego problemu zajmuje miesiąc i zaplanowałeś go na o wiele później, ale zaczęliście to robić w tym momencie i tracicie czas. Zrobiliśmy wszystko przed terminem, wszystko jest ok, wygraliśmy, ale zapomnieliśmy o istotnym zadaniu. Dlatego, że nie widzieliśmy tego, co będziemy musieli zrobić w przyszłości.

Narasta zdenerwowanie w zespole i schodzimy z kursu. Każdy może dobrze bawić się aktualnymi zadaniami i dobieraniem nowych. A manager nie rozumie co się dzieje, dlatego że nie ma pojęcia, co powinno stać się za chwilę. Klient też się denerwuje, dlatego, że nie wie, co stanie się zaraz.

9. Równowaga we wsparciu (odpowiedzialność managerska vs. branie na siebie zbyt wielu zadań; obszar odpowiedzialności jest ograniczony z góry i z dołu; odkrywaj i ustal granice; jeśli wciąż masz energię możesz powoli przekraczać granice)

Kolejna rzecz, której nie rozumiałem to granice mojej odpowiedzialności – zarówno ta "górna" jak i "dolna". Czy powinienem zwrócić się do każdego członka zespołu osobiście i przedstawić im szczegółowe instrukcje na temat raportowania, czy powinienem tworzyć raporty sam? Powinienem monitorować wszystkie ich czynności czy prosić ich o ich opisanie? A może powinienem zaangażować kogoś, kto będzie zajmował się tworzeniem i przedstawianiem takich tygodniowych raportów i mógłbym tylko szybko rzucić na nie okiem? Gdzie jest górna granica mojej odpowiedzialności? W jaki sposób jestem odpowiedzialny za cały projekt? Za budżety? Czy powinienem informować kolegów na wyższym szczeblu, że potrzebujemy powiększenia zespołu, by skończyć projekt na czas, czy to mój problem? Najważniejsze, by odkryć granice odpowiedzialności zarówno „od góry” jak i „od dołu” i je przedyskutować.

Jesteś Project Managerem i masz swoich przełożonych, zwłaszcza w komunikacji z klientem. Istotne, by zdecydować, czy chcemy powiedzieć klientowi, że możemy dodać każdą funkcjonalność. Prawdopodobnie praca nad szeroką gamą funkcji będzie wyzwaniem, najlepiej zgodzić się na te, które – na przykład – nie wymagają więcej niż 4 godzin pracy. Jeśli klient wymaga dodania jednej funkcjonalności miesięcznie, możesz zezwolić na to bez informowania, tych, którzy są nad tobą.

Powinieneś ustalić i przedyskutować te granice na samym początku. Moim największym błędem było delegowanie mojej odpowiedzialności managerowi, kiedy potrzebowałem pomocy. W rezultacie w pewnym momencie zaczął on wykonywać moją pracę zamiast pomagania mi od czasu do czasu z zasobami czy dzielenia się doświadczeniem.

10. Wyprzedzanie oczekiwań (zawsze komunikuj mniej i rób więcej; nie ustalaj nowych oczekiwań; rób listę obowiązków na jutro)

Nigdy nie obiecuj więcej, niż jesteś w stanie zrobić, lepiej mówić mniej i robić więcej. Najfajniej, kiedy robisz „prezent” swojemu klientowi. Na przykład – godzisz się na zrobienie jakiejś dodatkowej funkcjonalności na rzecz klienta, kiedy jesteś pewien, że jest raczej niewielka i łatwa do zrobienia (jeszcze lepiej, kiedy zostało to już zrobione, ale nie zostało zaprezentowane).

Przykładowo – klient zapytał o terminy i obiecałeś, że coś będzie gotowe kolejnego dnia. Mogłeś przesunąć deadline, ale tego nie zrobiłeś. I jeśli jutro praca nie będzie skończona, klient będzie bardziej niezadowolony niż jeśli powiedziałbyś, że potrzebujecie więcej czasu – obiecałeś i nie dotrzymałeś obietnicy.

Zawsze podążaj za złotą zasadą: "mów mniej, rób więcej". Ale tutaj powinieneś również pamiętać o jednym, znaczącym niuansie. Ludzie, którzy napędzają rynek IT są inteligentni. Znają specyfikę pracy w branży i nie tylko słuchają tego, co mówisz, ale widzą, co robisz. Szybko zdają sobie sprawę z tego, że kiedy zgadzasz się na zrobienie czegoś w ciągu tygodnia i za każdym razem pokazujesz im to we czwartek, okazuje się, że potrzebujesz na to tylko 3 dni. Następnym razem poproszą o zrobienie tego samego w ciągu 3 dni. Dlatego ważne jest, by nie ustalać nowych oczekiwań.

Podobny efekt dotyczy wynagrodzeń. Na przykład – jeśli wypłacasz miesięczną premię 6 miesięcy z rzędu, pracownicy zaczynają traktować to jako pewnik, nie jako wynagrodzenie za wykonaną - ogromną - pracę. I jeśli za którymś razem nie zostaną wynagrodzeni bonusem, będą zaskoczeni. Zapytają: „Gdzie moja premia? Przyzwyczaiłem się do miesięcznych bonusów!”. Jeśli więc nie jesteś przygotowany na podwyżkę, wypłać im wyższą premię w jednym miesiącu, rezygnując z tego w kilku kolejnych – w ten sposób nie zaczną traktować wyróżnienia jako regularnej podwyżki.

Wracając do terminów i produktywności – jeśli zawsze robisz podobną rzecz w ciągu trzech dni (a właściwie zespół jest w stanie stworzyć tę rzecz w takim czasie), możesz stworzyć listę zadań na kolejny dzień, ale nie raportować tego klientowi raz na 3 dni, a raz w tygodniu. Dwa dni, które pozostaną mogą zostać poświęcone na twoją ukochaną refaktoryzację i inne przydatne rzeczy.