20.10.20167 min

DataArt

Eugene Efimov: 10 niezbędnych umiejętności efektywnego managera – kolejna, ostatnia piątka

Eugene Efimov: 10 niezbędnych umiejętności efektywnego managera – kolejna, ostatnia piątka

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.

<p>Loading...</p>

Dziel się wiedzą ze 160 tysiącami naszych czytelników

Zostań autorem Readme

Hitachi Energy

Product Development Manager

senior

15 000 - 20 000 PLN

Umowa o pracę

Kraków

Praca zdalna 100%

Ważna do 26.02.2022

Bardzo dobrze
AgileSoftware Development Life Cycle Leadership skills

Simple SA

Java Developer (Mid/Senior)

medium

7 000 - 15 000 PLN

Kontrakt B2BUmowa o pracę

Praca zdalna 100%

Ważna do 26.02.2022

Dobrze
JavaSpringSpring Boot

Asseco Poland S.A.

Administrator / Starszy Administrator Systemów IT

medium

Brak widełek

Kontrakt B2BUmowa o pracę

Praca zdalna 100%

Ważna do 26.02.2022

Dobrze
PostgreSQLBash

Nokia

5G Automation Engineer, IODT

medium

Brak widełek

Umowa o pracę

Wrocław

Praca zdalna 100%

Ważna do 13.03.2022

Divante

Senior Vue.js Developer

senior

15 300 - 23 500 PLN

Kontrakt B2BUmowa o pracę

Wrocław

Praca zdalna 100%

Ważna do 13.03.2022

Dobrze
JavaScriptTypeScriptVue.js

T-Mobile Polska S. A.

Frontend Developer

medium

Brak widełek

Kontrakt B2B

Warszawa

Ważna do 26.02.2022

Bardzo dobrze
ReactReduxNode.js

Commerzbank - Centrum Technologii Cyfrowych w Polsce

Business Expert for Risk Applications

medium

Znamy widełki

Umowa o pracę

Łódź

Ważna do 26.02.2022

Dobrze
SQLMS Office
Początkująco
SAS / R / Python

Commerzbank - Centrum Technologii Cyfrowych w Polsce

Business Expert with German for Risk Analytics

medium

Znamy widełki

Umowa o pracę

Łódź

Ważna do 26.02.2022

Dobrze
MS Office
Początkująco
SQL / VBA / PythonQlik Sense / Qlik View / Arcadia

Hitachi Energy

Quality Assurance Engineer

medium

8 000 - 14 000 PLN

Umowa o pracę

Kraków

Ważna do 26.02.2022

Dobrze
automation testing .NET CoreSelenium
Początkująco
MS SQL

Więcej od DataArt

Zobacz wszystkie artykuły od DataArt