Eugene EfimovQA LeadDataArt
Eugene Efimov: 10 niezbędnych umiejętności efektywnego managera – pierwsza piątka
Żeglarze, samoloty i korporacje
Istnieje koncept określany jako błąd przeżywalności – zainteresowani mogą o nim przeczytać w książkach autorstwa Taleba: Black Swan. The Impact of the Highly Improbable i Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets.
Autor opisuje cudowny obrazek: greccy żeglarze modlą się do swoich bóstw podczas burzy – bogom się to podoba i dlatego żeglarze zostają uratowani. Burza zamienia się w lekki wiatr, statek dociera do brzegu, a cała załoga jest bezpieczna i szczęśliwa. Kiedy ludzie pytają innych żeglarzy w jaki sposób udaje im się przetrwać burze na morzu – ci odpowiadają: - Modlimy się do bóstw i zawsze docieramy cali do brzegu.
Problem jest następujący – nie możemy o to zapytać żeglarzy, którzy zginęli w czasie sztormu. Pewnie również się modlili, ale im się nie udało. Co więcej – możemy stwierdzić, że większość greckich żeglarzy była religijna w tamtych czasach i gorliwie się modliła. Wniosek jest prosty – intensywność modlitwy nie wpływała na to, czy ktoś utonął, czy przeżył.
Druga historia opowiada o Abrahamie Waldzie – matematyku specjalizującym się w statystyce – i o samolotach. Rzecz dzieje się w czasie II WŚ. Brytyjscy piloci bombowców wracają do bazy. Inżynierowie zastanawiają się, w których miejscach i jaką broń powinni dodać, by zwiększyć procent maszyn, które wytrzymają ataki. Dokładnie badają samoloty, które wróciły i stwierdzają, że warto wzmocnić najbardziej nadwyrężone części. Mówią: - Widzimy, że wrogowie celowali właśnie w te miejsca – naprawimy je i wzmocnimy – kule przeciwników odbiją się i uderzą w nich rykoszetem.
Abraham Wald zaproponował jednak coś innego – pomyślał, że jeśli wszystkie ogony i skrzydła są podziurawione, ale samoloty wróciły w jednym kawałku, należy zignorować te części podczas naprawy. Stwierdził, że inżynierowie powinni robić dokładnie odwrotnie – wzmocnić te części samolotu, które zostały nienaruszone.
Dlaczego?
Samoloty, które nie powróciły zostały uderzone właśnie w te miejsca – dlatego inżynierowie powinni lepiej osłonić na przykład śruby napędowe i kabinę – a nie skrzydła. Główna idea obejmowała przeanalizowanie nie tylko floty, która powróciła do bazy, ale także wraków, by sprawdzić, co spowodowało, że samoloty nie mogły kontynuować lotu i się rozbiły.
Steven Levitt napisał interesującą książkę pod tytułem Freakonomics. Przeanalizował dwie popularne pozycje dotykacjąca tego samego tematu – 10 kroków do sukcesu – historie korporacji, które używając innowacji wzbiły się na wyżyny. Książki zostały napisane w granicach roku 2000, a korporacje w tamtym czasie były konkurentami ze względu na wspomiane innowacje. W czasie kiedy Levitt je analizował, ¾ tych biznesów były już zamknięte, okazując się nierentownymi – ze względu na zmianę panujących warunków i ich brak adaptacji do tych zmian. Wniosek jest prosty – te success stories nie działają tak samo w każdym przypadku.
Wracając do błędu przeżywalności – dotyczy on tych, którzy zbierają statystyki dotyczące jakiegoś zjawiska tylko z łatwo dostępnych źródeł. Skupiamy się tylko na tych, którzy „przeżyli” jakiś proces, ignorując tych, którym się to nie udało. A to prowadzi do fałszywych wniosków i wpływa na sposób podejmowania decyzji. A przecież czasami ci, których wysiłki spełzły na niczym mogą podzielić się ciekawszym doświadczeniem.
Projekty i taśmociągi
(Każdy szczegół jest taki sam vs. Wszystko-od-początku; Plan i instrukcje vs. Chaos i Agile; Zależność od warunków zewnętrznych vs. System zamknięty)
W jakim przypadku możemy zbierać dane statystyczne od osób, które osiągnęły sukces? Tylko wtedy, kiedy pracujemy taśmowo. Tzn. wtedy, kiedy jakaś sekwencja określonych czynności prowadzi nas do określonych wyników.
Na przykład – gotujemy wodę, wrzucamy do niej pierogi, czekamy aż się ugotują i jemy je ze smakiem. Bardzo nieprawdopodobny jest w tym przypadku scenariusz, że jakiś czynnik zewnętrzny wpłynie na cały proces. Nie ma też konieczności ingerowania w sekwencję. Kiedy mamy – mniej więcej – zamknięty system, który w żaden sposób nie zależy od okoliczności zewnętrznych, możemy zaplanować jakąś określoną sekwencję czynności.
Projekty IT są w dużej części związane z procesami, decyzjami, zadaniami zależącymi od warunków zewnętrznych, klientami, rynkiem, naszym zespołem, naszą firmą i tak dalej. I – jeśli ta zależność od czynników zewnętrznych jest silniejsza niż procesy w ramach systemu - plany nie pomogą, dlatego, że trudno jest przewidywać biorąc pod uwagę wszystkie możliwe okoliczności niezależne od nas.
Jak używac success stories?
Fajnie wiedzieć, co zdarzyło się na końcu
Nie załamuj się powyższym – warto używać success stories! Najważniejsze, by zrozumieć, co dzieje się na końcu każdej z nich. Były w historii firmy, które miały odpowiedni know-how, ale nie przetrwały. Ważne, by zrozumieć, dlaczego, który z punktów planu zawiódł i jak skończyła się historia.
Pełen kontekst jest niezbędny
Bardzo istotny jest szeroki kontekst – kiedy ktoś opowiada ci o tym, że coś zrobił, warto zrozumieć co w tym czasie działo się dookoła niego. Na przykład – szukasz pracy i pytasz kolegę, które niedawno pomyślnie przeszedł rozmowę, na co zwrócić uwagę. Opowiada ci, że wszedł do pokoju, przedstawił się jako Jan Nowak, a firma zaoferowała mu stanowisko z miejsca. Myślisz, że poszło szybko i sprawnie – idziesz, przedstawiasz się, masz pracę! Ale mogło zdarzyć się, że dyrektor firmy nosi takie same nazwisko i to przesądziło – to nie jest dobra opcja.
Pomyśl o punktach zwrotnych
Punkty zwrotne są tak samo ważne – kiedy zmieniają się czynniki zewnętrzne w rezultacie pewne sekwencje czynności nie działają. Jeśli jesteśmy w stanie odtworzyć to samo środowisko i te same warunki – jesteśmy w stanie powtórzyć tę success story. Jeśli nie jesteśmy w stanie odtworzyć wszystkiego 1:1 – warto poszukać innych rozwiązań.
Opowiedz o konkurencji i scenariuszach alternatywnych
Ważne także, by brać pod uwagę konkurencję, by zrozumieć, co oni robili w sytuacji podobnej do twojej. Prawdopodobnie to samo – poczytaj historie o tym, co nie wyszło wpływowym ludziom i wielkim korporacjom. Istnieją ogólne zasady, które w jednym przypadku prowadzą do sukcesu w innych – do porażki. Co znaczy, że w ujęciu statystycznym właściwie nie wpływają na bieg zdarzeń.
Wejdź na meta-poziom
Warto dotrzeć do meta-poziomu. Staraj się nie uogólniać i nie mówić, że jeśli masz czapkę na głowie, nigdy nie złapiesz przeziębienia. Warto sformułować meta-zasadę: jeśli ubierasz się zgodnie z aurą, szanse na złapanie przeziębienia znacząco maleją.
Jak korzystać z porażek?
Jak korzystać z cudzych porażek? Wygląda na to, że jest prosto: nie rób tak, jak robili inni. Niekoniecznie. Porażki są jak success stories. Skłamałem, mówiąc na początku, że są bardziej przydatne. Będą przydatne, ale wciąż: musisz myśleć o szerszym kontekście i o konkurencji. I powinieneś przenieść porażki na określony meta-poziom, sformułować reguły, które są wywoływane przez środowisko zewnętrzne, ale nie będą to instrukcje, które możesz użyć wprost.
10 największych błędów, które popełniłem (pierwsza piątka)
1. Wydaje się, że nic nie robię
Kiedy byłem managerem QA, zawsze byłem w stanie poświęcić swój czas na inżynierską robotę, niezależnie od tego jak bardzo załadowany byłem pracą managerską. Były dni, w trakcie których spędzałem 8 godzin tylko na telekonferencjach, rozmowach z klientami, strategiach i planach. To wszystko. A jeśli te czynności zajmowały tylko kilka godzin, pozostały czas poświęcałem na inżynierskie zadania. Zawsze byłem zajęty i uważałem się za niezłego i efektywnego pracownika.
Wtedy zostałem Project Managerem. Czasami mój dzień pracy zajmuje 12, 13, 15 godzin, dlatego, że mam wiele rzeczy do zrobienia, zwłaszcza na początku projektu. Ale są też dni, w których wykonuję kilka telefonów, a potem nie mam nic do roboty. To wyglądało tak, jakbym nic nie robił, a moje obciążenie było niewystarczające. Kolejny projekt? Dobry pomysł. W rezultacie tych przemyśleń wziąłem na siebie 4 projekty w tym samym czasie i to było fiasko. Obciążenie managera przychodzi falami. Jeśli masz okres, w którym masz sporo wolnego, podoba ci się to – jasne, ale tylko na początku. Przez kilka dni czujesz się świetnie. A potem mówisz: Hm, nie. MUSZĘ się czymś zająć, wezmę więcej projektów.
I masz coraz więcej i więcej do roboty, czasami nawet 20 godzin dziennie, nawet jeśli dzień pracy powinien składać się z 8. Musisz zrozumieć, że jeśli od czasu do czasu masz mniej roboty, to jest normalne! Jeśli jesteś dobrym managerem i robisz wszystko tak, jak powinieneś, zawsze będą pojawiać się okresy w których nie robisz nic. Nie martw się tym. Kiedy nabierzesz doświadczenia, będziesz mógł w tym czasie robić analizy na własny użytek, budować relacje z klientami albo zając się account managementem. A na samym początku będą okresy, kiedy będziesz wolny tylko w połowie. Spotkania to też praca – jeśli wykonujesz wiele telefonów w ciągu dnia – policz to jako wykonaną robotę.
Jeśli nie zrobiłeś nic i nie ma żadnych namacalnych wyników twojej pracy to też jest ok. Bycie w pełnej gotowości przez cały dzień jest przecież uciążliwe. I wydaje ci się, że nie zrobiłeś nic, ale jesteś zmęczony. Kolejna ważna wskazówka: dobrze, jeśli poświęcisz chwilę na self-management. Jesteś w końcu swoim własnym managerem i dysponujesz zadaniami w ramach zespołu, przydzielając je również sobie. I to także część twojej pracy.
2. Robię wszystko dla wszystkich
Dokładnie tak było, kiedy ciągle czułem, że robię za mało i muszę brać na siebie nowe obowiązki. Mam czas? Dlaczego nie pomóc analitykowi w komunikacji z klientem? I stałem się częścią tego procesu. Dlaczego QA Manager komunikuje się bezpośrednio z klientem? Pomogę! I tak dalej. W ten sposób zacząłem zarządzać wszystkimi procesami komunikacji i wszystko, co działo się w projekcie przechodziło najpierw przeze mnie – potem przekazywałem to klientowi. Z jednej strony jest to wygodne, bo PM powinien wiedzieć, co dzieje się w projekcie. Ale jeśli – na przykład – masz dosyć, jesteś zmęczony i masz sporo rutynowej pracy do zrobienia, możesz ściągnąć kłopoty na cały projekt. Bo każdy będzie pytał: „Gdzie jest Jan? Zazwyczaj dajemy mu wszystkie raporty i on je wysyła klientowi! Naprawdę musimy wysłać je sami? To zadziała?”. Innymi słowy, zarządzanie komunikacją w całości to zły pomysł dlatego spróbuj tego nie robić. Zarządzaj procesami komunikacji tylko wtedy, kiedy jest to niezbędne.
3. Ciekawe zadania
Miałem masę zadań i większość z nich była nudna, ale niektóre były piekielnie interesujące. Zazwyczaj zabierałem się najpierw za te drugie, by potem szybko przejść przez to, co nudne – ale, generalnie, to nie jest dobre. Interesujące zadania to jedno, ale powinieneś pamiętać, że to nie jest właściwe ustalanie priorytetów i właściwa kolejność, w której powinieneś rozwiązywać problemy.
Mógłbym powiedzieć, że warto priorytetyzować zadania, ale to nie panaceum na wszystkie bolączki, dlatego, że twój zespół ma swoje priorytety, ty masz swoje, jeszcze inne ważne są dla firmy, a inne dla klienta. Teoretycznie powinieneś manewrować pomiędzy priorytetami ale – w praktyce – na przykład biznes nie zawsze świadomy jest swoich priorytetów. Klienci mogą myśleć, że pewne sprawy są dla nich ważne (zazwyczaj te, które ciągle mają z tyłu głowy), a inne w jakiś sposób powinny dziać się same. Na przykład – klient mówi, że ważne jest dla niego ładowanie obrazków na serwer.
Ale tak naprawdę najważniejszą rzeczą jest zapewnienie użytkownikom wiedzy, w jaki sposób mogą je polubić. Klient myśli, że to oczywiste, więc pracujemy dla niego nad obrazkami i robimy wszystko by proces działał bez zarzutu. A wtedy klient mówi: „Gdzie są moje polubienia? Po co była ta cała praca?”. I jeszcze jedna rzecz, której nauczyłem się w dosyć dotkliwy sposób: absolutnie każdy popełnia błędy.
4. Każdy popełnia błędy
To straszne, kiedy myślisz, że ktoś jest doskonały, a nagle widzisz, że popełnia błędy. Myślałeś, że nie jest w stanie niczego zepsuć, ale to zrobił – nikt nie jest doskonały, taka jest prawda. Myślałeś, że istnieje ściana z betonu, ale jej nie ma – nie istnieją przecież pola nieobarczone ryzykiem. Te obszary, które uważamy za absolutnie spokojne, mogą w każdej chwili wybuchnąć. Na przykład – nie zrozumiałeś związanych z czymś wymagań i przydzieliłeś jakieś zadanie niedoświadczonemu specjaliście, który wykonał je źle i starał się „oprawić” rzeczy, które nie były związane z przydzielonym zadaniem. Wszystko się zawaliło.
Wszyscy popełniają błędy – seniorzy i klienci także. Przy okazji – klienci popełniają fantastyczne błędy! Na przykład – mówią, albo nawet piszą, że nie potrzebują polubień, ale to nie jest to, co mają na myśli. Na końcu projektu nie są w stanie zaakceptować rozwiązania, dlatego, ze obiecali inwestorowi, że polubienia będą, a projekt bez nich jest bezużyteczny. I przyznają szczerze: „Tak, nie sprecyzowaliśmy tego, ale - mimo wszystko – nie możemy nic z tym zrobić. Nie jesteście za to odpowiedzialni, ale nie osiągnęliśmy swojego celu – projekt nie jest skończony tak, by każda strona mogła być usatysfakcjonowana”. Zawsze musimy być przygotowani na taką ewentualność. Musisz być gotowy pomóc klientowi, bardzo uważnie wytłumaczyć i poprowadzić go, by wiedzieć, co jest przez niego wymagane, a co nie. Na początku ścieżki PM popełniasz więcej błędów niż inni – jesteś piętą achillesową, ale to jest ok. Ale unikanie dużych błędów również jest istotne.
Nie ma strategii, która obroni cię przed popełnianiem błędów. Powinieneś uważnie podejmować decyzje – wtedy zwiększasz swoje szanse na sukces. Ważne, by nie karać się za błędy i nie cierpieć. Spróbuj działać racjonalnie. Zapytaj siebie: „Jeśli zrobiłem coś źle, co powinienem zmienić, by w przyszłości było dobrze?”.
5. Zawsze biorę pod uwagę przeszkody
Każdy popełnia błędy, dlatego zawsze będziemy mieć do czynienia z przeszkodami. Szacunki i plany mogą być mylące. Ale to nie znaczy, że mamy je ignorować, odmawiać planowania, szacowania, itd. Powinieneś pamiętać, by brać pod uwagę przeszkody. Inna sprawa to taka, że one się kumulują. Na przykład – programista szacuje, że może rozwiązać 10 zadań w ciągu 10 godzin, a ty jako przewidujący manager mówisz, że zajmie mu to 20 (dodajesz 10 godzin ekstra). Programista rozwiązuje pierwsze zadanie w ciągu 2,5 godzin. To znaczy, że z pozostałymi poradzi sobie w ciągu nie 11,5 godziny, ale 25. Te przeszkody będą narastać. Zawsze trzeba wprowadzać korekty w projekcie w czasie rzeczywistym i brać pod uwagę to, co może stać się za chwilę.
Jest jeszcze jedna istotna kwestia – takie korekty zawsze dodają czas na określone zadania, nigdy odwrotnie – programiści są przyzwyczajeni, że managerowie dają im więcej czasu, niż sami oszacowali. By sprawić, że manager uwierzył, że są szybcy i elastyczni, rozwiązują zadanie w godzinę, nie 3 jak poprzednio deklarowali. Ale tak naprawdę zajmuje ono tylko 15 minut w ciągu ich dnia pracy.
Prawda jest taka, że na początku projektu ludzie pracują nad wieloma rzeczami, które wymagają kreatywności i mają bardzo niewiele restrykcji dotyczących, na przykład, architektury. Można to robić szybko, łatwo i pięknie. A w połowie projektu trzeba wszystko przebudować na potrzeby integracji. Ale teraz mamy do czynienia z następującą sytuacją: oszacowałeś, że twój zespół potrzebuje tygodnia na stworzenie architektury, ale zrobili to w ciągu 3 dni, a ty zaczynasz myśleć o tym, że projekt możecie zakończyć szybciej. Nigdy nie skracaj szacowanych terminów.