Darmowy fragment publikacji:
Tytuł oryginału: The Manager s Path: A Guide for Tech Leaders Navigating Growth and
Change
Tłumaczenie: Bartosz Sałbut
ISBN: 978-83-283-3899-9
© 2018 Helion S.A.
Authorized Polish translation of the English edition of The Manager s Path ISBN
9781491973899 © 2017 Camille Fournier.
This translation is published and sold by permission of O’Reilly Media, Inc.,
which owns or controls all rights to publish and sell the same.
All rights reserved. No part of this book may be reproduced or transmitted in any form
or by any means, electronic or mechanical, including photocopying, recording or by any
information storage retrieval system, without permission from the Publisher.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu
niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą
kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym,
magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź
towarowymi ich właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce
informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za
ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub
autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności
za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/odidom
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
Printed in Poland.
• Kup książkę
• Poleć książkę
• Oceń książkę
• Księgarnia internetowa
• Lubię to! » Nasza społeczność
Spis treści
Podziękowania ....................................................................13
Wprowadzenie ....................................................................15
Jak czytać tę książkę? ...........................................................................17
1. Podstawy zarządzania ......................................................19
Czego oczekiwać od menedżera? ...........................................................19
Spotkania jeden na jeden ...............................................................20
Informacje zwrotne i wskazówki robocze ...........................................22
Szkolenie i rozwój zawodowy ...........................................................24
Zarządzanie od strony pracownika .........................................................27
Refleksja nad oczekiwaniami ...........................................................27
Sam jesteś za siebie odpowiedzialny ................................................28
Menedżer też człowiek ....................................................................29
Mądrze wybieraj menedżerów ..........................................................30
Ocena własnego doświadczenia .............................................................31
2. Mentoring .......................................................................33
Znaczenie mentoringu dla młodszych stażem członków zespołu .................33
W roli mentora ....................................................................................34
Mentor dla stażysty .........................................................................35
Mentor dla nowego pracownika ........................................................40
Mentoring techniczny bądź zawodowy ..............................................43
Dobry menedżer, zły menedżer: techniczny samiec alfa ............................45
Wskazówki dla menedżera nadzorującego pracę mentora .........................47
Wnioski dla mentora ............................................................................51
Wykazuj zainteresowanie i zachowaj otwarty umysł ...........................51
Słuchaj podopiecznego i mów jego językiem .....................................52
Nawiązuj kontakty ..........................................................................52
Ocena własnego doświadczenia .............................................................53
Poleć książkęKup książkę 8
Od inżyniera do menedż era
3. Lider techniczny ..............................................................55
Dziwna sztuczka znana każdemu świetnemu liderowi technicznemu ..........60
Podstawowe informacje o pracy lidera technicznego ................................61
Główne role lidera technicznego ......................................................62
Zarządzanie projektami .........................................................................65
Zarządzanie projektem ..........................................................................70
Decyzja: kariera techniczna czy menedżerska? ........................................73
Wyobrażenia na temat życia starszego specjalisty .............................73
Prawdziwe życie starszego specjalisty ...............................................74
Wyobrażenia na temat życia menedżera ...........................................76
Prawdziwe życie menedżera ............................................................77
Dobry menedżer, zły menedżer: car procesu ............................................79
Przepis na świetnego lidera technicznego ................................................81
Rozumie architekturę .....................................................................81
Potrafi grać zespołowo ....................................................................81
Przewodzi przy podejmowaniu decyzji technicznych ..........................82
Sprawnie się komunikuje ................................................................82
Ocena własnego doświadczenia .............................................................83
4. Zarządzanie ludźmi ..........................................................85
Podwaliny pod dobre relacje z nowym podwładnym .................................86
Szacunek i porozumienie ................................................................86
Plan na 30/60/90 dni .....................................................................88
Aktualizacja dokumentacji jako źródło motywacji do zaangażowania .....88
Informacja o stylu pracy i oczekiwaniach ..........................................89
Informacje zwrotne od nowego pracownika ........................................89
Komunikacja z zespołem .......................................................................90
Regularne spotkania 1-1 .................................................................90
Planowanie spotkań 1-1 .................................................................90
Dostosowywanie spotkań 1-1 do indywidualnych potrzeb ...................91
Różne style spotkań w formule 1-1 ........................................................92
Spotkanie pod znakiem listy zadań do wykonania ..............................92
Spotkanie typu „co słychać?” ...........................................................93
Spotkania służące przekazywaniu informacji zwrotnych .....................93
Spotkania w sprawie postępów ........................................................94
Spotkania zapoznawcze ..................................................................95
Mieszanka stylów ...........................................................................95
Dobry menedżer, zły menedżer: mikrozarządzanie i delegowanie zadań ......96
Praktyczne rady dotyczące skutecznego delegowania zadań ......................98
Cele zespołu jako kryterium wyboru szczegółowych zagadnień
wymagających uwagi ......................................................................98
Najpierw informacje z systemu, potem od ludzi .................................99
Poziom zainteresowania zależny od stadium projektu ......................100
Standardy dotyczące kodu i systemów ............................................100
Poleć książkęKup książkę
Spis treś ci
9
Neutralny lub pozytywny stosunek do otwartości w zakresie
przekazywania informacji — zarówno dobrych, jak i złych .................101
Stwarzanie warunków dla ciągłego przepływu informacji zwrotnych .........102
Oceny wyników .................................................................................105
Opracowywanie i przekazywanie oceny wyników ..............................106
Wspieranie karier ...............................................................................111
Wyzwania: jak zwolnić kogoś, kto sobie nie radzi? .................................114
Ocena własnego doświadczenia ...........................................................118
5. Zarządzanie zespołem ....................................................121
Zachowanie kompetencji technicznych .................................................123
Rozwiązywanie problemów dysfunkcyjnego zespołu
― kwestie podstawowe ......................................................................126
Brak wyników ...............................................................................126
Ludzkie przywary ..........................................................................127
Niezadowolenie wynikające z przepracowania .................................128
Problemy ze współpracą ................................................................129
Tarcza ochronna ................................................................................131
Nakierowanie na dobrą decyzję ...........................................................133
Kultura zespołowa oparta na danych ..............................................133
Wysiłek produktowy ......................................................................134
Spojrzenie w przyszłość ................................................................134
Analiza skutków decyzji i projektów ................................................135
Analiza retrospektywna procesów i codziennego funkcjonowania .......135
Dobry menedżer, zły menedżer: unikanie konfliktów
a łagodzenie konfliktów ......................................................................135
Konflikt — co robić, a czego nie robić? ...........................................137
Wyzwania: czynniki szkodliwe dla spójności zespołu ..............................140
Genialny palant ............................................................................141
Tajniak ........................................................................................143
Pracownik okazujący brak szacunku ...............................................144
Zaawansowane zarządzanie projektami ................................................144
Ogólne zasady zarządzania projektami ...........................................145
Ocena własnego doświadczenia ...........................................................149
6. Zarządzanie wieloma zespołami ......................................151
Zarządzanie czasem: co jest tak naprawdę ważne? ................................156
Decydowanie i delegowanie ................................................................161
Delegować należy zadania proste i częste .......................................163
Samodzielnie należy wykonywać zadania proste i nieczęste ..............163
Zadania złożone i nieczęste należy wykorzystać jako materiał
szkoleniowy dla przyszłych liderów .................................................163
Zadania złożone i częste należy delegować,
aby zespół mógł się rozwijać ..........................................................164
Poleć książkęKup książkę 10
Od inżyniera do menedż era
Wyzwania: jak powiedzieć „nie”? .........................................................166
„Tak, z tym że…” .........................................................................167
Definiuj politykę ...........................................................................167
„Pomóż mi powiedzieć »tak«” ........................................................168
Argument budżetowy ....................................................................168
Praca zespołowa ..........................................................................169
Nie wykręcaj się ...........................................................................169
Kwestie techniczne niezwiązane z kodem .............................................171
Ocena kondycji zespołu programistycznego ...........................................172
Częstotliwość wersji ......................................................................172
Częstotliwość aktualizowania kodu .................................................174
Częstotliwość zdarzeń kryzysowych ................................................175
Dobry menedżer, zły menedżer: my kontra oni a gracz zespołowy ............177
Cnoty lenistwa i niecierpliwości ...........................................................180
Ocena własnego doświadczenia ...........................................................182
7. Zarządzanie menedżerami ..............................................185
Spotkania z podwładnymi podwładnych ...............................................189
Odpowiedzialność menedżera ..............................................................192
Dobry menedżer, zły menedżer: zadowolić wszystkich ............................195
Zarządzanie początkującymi menedżerami ............................................199
Zarządzanie doświadczonymi menedżerami ..........................................203
Zatrudnianie menedżerów ...................................................................205
Usuwanie błędów w dysfunkcyjnej organizacji .......................................211
Hipotezy ......................................................................................212
Analiza danych ............................................................................213
Obserwacje dotyczące zespołu .......................................................213
Pytania ........................................................................................214
Ocena dynamiki zespołu ...............................................................215
Aktywna pomoc ............................................................................215
Ciekawość ...................................................................................216
Konkretne oczekiwania i terminowa realizacja .......................................216
Wyzwania: niepewność dotycząca mapy drogowej .................................219
Strategie postępowania z czynnikiem niepewności ...........................220
Na bieżąco z kwestiami technicznymi ...................................................222
Nadzór nad inwestycjami technicznymi ..........................................223
Trafne pytania ..............................................................................223
Analiza i omówienie kompromisów inżynierskich i biznesowych ........223
Konkretne oczekiwania .................................................................224
Doświadczenie jako klucz do instynktownej oceny ...........................225
Ocena własnych doświadczeń .............................................................226
Poleć książkęKup książkę
Spis treś ci
11
8. Pierwsza liga .................................................................229
Modele myślenia o przywództwie wyższego szczebla ..............................232
Czym się zajmuje wiceprezes do spraw projektów technologicznych? .......235
Czym się zajmuje dyrektor techniczny? .................................................238
Zmieniające się priorytety ...................................................................243
Definiowanie strategii .........................................................................246
Gromadzenie danych na dużą skalę ...............................................247
Zestawienie odkryć i pomysłów ......................................................247
Potencjalne kierunki strategiczne ..................................................248
Dopasowanie komunikatu do stylu typowego dla zarządu ..................248
Wyzwania: jak przekazywać złe wieści? ................................................250
Współpracownicy odpowiedzialni za inne obszary ..................................254
Echo .................................................................................................257
Strach rządzi, zaufanie wskazuje drogę .................................................260
Korygowanie kultury strachu ..........................................................261
Gwiazda Polarna ................................................................................264
Zalecana lektura ................................................................................266
Ocena własnego doświadczenia ...........................................................267
9. Tworzenie kultury ..........................................................269
Ocena własnej roli ..............................................................................275
Tworzenie kultury ...............................................................................279
Podstawowe wartości w praktyce .........................................................281
Tworzenie polityki kulturowej ..............................................................284
Tworzenie opisu ścieżki awansu zawodowego .......................................287
Zespół interdyscyplinarny ....................................................................293
Struktura zespołów interdyscyplinarnych ........................................295
Kształtowanie procesów inżynierskich ..................................................297
Rada praktyczna: proces decyzyjny bez czynnika osobowego ..................299
Inspekcja kodu .............................................................................299
Analizy poawaryjne .......................................................................300
Ocena architektury .......................................................................301
Ocena własnego doświadczenia ...........................................................303
Podsumowanie ..................................................................305
Skorowidz ........................................................................307
Poleć książkęKup książkę 12
Od inżyniera do menedż era
Poleć książkęKup książkęROZDZIAŁ 3
Lider techniczny
Liderem technicznym zostałam wiele lat temu. Dostałam awans na sta-
nowisko starszego inżyniera i pracowałam w ramach małego zespołu wraz
z kilkoma innymi starszymi inżynierami. Trochę byłam zaskoczona, gdy
wybrano mnie na lidera technicznego, w zespole znajdowali się bowiem lu-
dzie z większym doświadczeniem i zajmujący w firmie wyższe stanowiska.
Z perspektywy czasu stwierdzam jednak, że miałam kilka zalet. Przede wszyst-
kim oprócz kompetencji technicznych mogłam się pochwalić również dużą
skutecznością w komunikacji. Potrafiłam redagować przejrzyste dokumenty
i dobrze sobie radziłam podczas prezentacji. Byłam w stanie skutecznie
tłumaczyć różne kwestie ludziom z innych zespołów i innych działów firmy.
Poza tym potrafiłam wyznaczać priorytety. Zależało mi na tym, aby jak naj-
szybciej doprowadzić zadanie do końca. Nie miewałam kłopotu z rozstrzy-
gnięciem, czym się należy w dalszej kolejności zajmować. Umiałam też przyj-
rzeć się wszystkim elementom układanki i stwierdzić, co trzeba zrobić, aby
sprawa posuwała się naprzód. Powiedziałabym, że zasadnicze znaczenie
w tym przypadku miało zapewne właśnie to pragmatyczne dążenie do celu.
Lider techniczny to jak by nie patrzeć funkcja o charakterze przywódczym,
choć nie kierowniczym.
Wielokrotnie miałam okazję obserwować, jak liderzy techniczni sobie
nie radzą. W pamięć zapadł mi jeden przypadek świetnego inżyniera, który
potrafił pisać naprawdę dobry kod, ale zupełnie nie lubił rozmawiać z ludź-
mi i często przywiązywał nadmierną wagę do różnych technicznych detali.
Raz po raz patrzyłam, jak się pakuje w różne tarapaty i jak menedżer pro-
duktu skrzętnie wykorzystuje jego nieuwagę, aby nakłonić zespół do wpro-
wadzenia kiepsko zaprojektowanych i zbyt daleko idących zmian w pro-
dukcie. Projekt pogrążał się w chaosie, a lider techniczny zajmował się
Poleć książkęKup książkę56
Od inżyniera do menedż era
kolejną refaktoryzacją, ponieważ głęboko wierzył, że wszystkie jego pro-
blemy wynikają z niewłaściwej struktury kodu. Zapewne dobrze to znasz,
bo to historia, jakich wiele. Nawet doświadczonym menedżerom zdarza się
popełnić błąd i ulec przekonaniu, że funkcję lidera technicznego należy po-
wierzyć temu spośród inżynierów, który ma największe doświadczenie, po-
trafi sobie poradzić z najbardziej złożonymi aspektami produktu albo pisze
najlepszy kod. Zadań lidera technicznego nie należy tymczasem powierzać
komuś, kto pragnie poświęcić całą uwagę najróżniejszym detalom swojego
kodu. Taki lider techniczny nie będzie się w pełni wywiązywać ze swoich
obowiązków. Na czym bowiem konkretnie polega ta praca? Czego należy
oczekiwać od kogoś, kto taką funkcję pełni?
Podobnie jak w przypadku wielu innych stanowisk w dziedzinie IT,
również w przypadku lidera technicznego trudno o powszechnie uznawaną
definicję. Dlatego pozostaje mi odwołać się do praktycznych doświadczeń
— własnych i cudzych. Ja jako lider techniczny nadal pisałam kod, oprócz
tego jednak reprezentowałam grupę w kontaktach z kierownictwem, weryfi-
kowałam plany wdrażania nowych funkcjonalności i zajmowałam się naj-
różniejszymi szczegółami związanymi z procesem zarządzania projektem.
Mogłam pełnić funkcję lidera technicznego — pomimo niższego szczebla
w strukturach firmy — ponieważ chciałam i potrafiłam wykonywać zwią-
zane z tym obowiązki, podczas gdy pozostali moi współpracownicy woleli
skupić się wyłącznie na tworzeniu programu. Gdy wspólnie z zespołem z Rent
the Runway pracowaliśmy nad strukturą hierarchiczną pionu technicznego
naszej firmy, świadomie zdefiniowaliśmy funkcję lidera technicznego jako
zbiór zadań, które można powierzyć do wykonania inżynierom z różnych
szczebli hierarchii. W ten sposób chcieliśmy wyrazić przekonanie, że ze-
społy zmieniają się i ewoluują, a zadania lidera technicznego może wyko-
nywać inżynier dysponujący mniejszym lub większym doświadczeniem
— oraz że mogą one zostać przekazane komuś innemu bez konieczności
zmiany jego stanowiska na wyższe w hierarchii firmy. W różnych firmach
zadania lidera technicznego mogą być inaczej zdefiniowane, mogą one zresztą
wyglądać odmiennie nawet w poszczególnych zespołach funkcjonujących
w obrębie tej samej firmy. Chciałam jednak wyraźnie podkreślić, że funk-
cja ta wiąże się z wykonywaniem konkretnych zadań o charakterze tech-
nicznym, ale wymaga też pewnych kompetencji przywódczych, a ponadto
chodzi raczej o pewien zbiór tymczasowo realizowanych obowiązków niż
Poleć książkęKup książkęLider techniczny
57
o konkretne stanowisko. Mając to wszystko na uwadze, spróbujmy odpo-
wiedzieć na pytanie: kim jest lider techniczny? Oto definicja, którą przy-
jęliśmy na potrzeby firmy Rent the Runway:
Rola lidera technicznego nie wpisuje się w strukturę hierarchiczną, lecz
stanowi zbiór obowiązków, które można powierzyć do wykonania każde-
mu starszemu inżynierowi. Zadania te mogą, ale nie muszą wiązać się
z zarządzaniem ludźmi, jeśli zaś się wiążą, to od lidera technicznego
oczekuje się przestrzegania wysokich standardów zarządzania obo-
wiązujących pracowników technicznych RtR. Wspomniane standardy
przewidują:
regularne (cotygodniowe) spotkania kontrolne w formule 1-1;
regularne przekazywanie informacji zwrotnych dotyczących rozwoju
kariery, stopnia realizacji celów, obszarów wymagających dosko-
nalenia oraz osiągnięć zasługujących na uznanie;
współpracę z podwładnymi przy rozpoznawaniu obszarów dokształ-
cania oraz wsparcie w zakresie pozyskiwania nowej wiedzy poprzez
pracę przy realizacji projektów, udział w zewnętrznych szkoleniach
bądź dodatkowe wsparcie mentorskie.
Od lidera technicznego oczekuje się, że będzie zapewniał wsparcie
mentorskie oraz służył radą innym członkom swojego zespołu, nawet jeśli
nie sprawuje nad nimi bezpośredniego nadzoru kierowniczego.
Lider techniczny doskonali umiejętności niezbędne do skutecznego
zarządzania projektami technicznymi, a w związku z tym stara się rów-
nież skutecznie delegować zadania i unikać mikrozarządzania. Skupia
się na produktywności zespołu jako całości i dąży do zwiększania siły
oddziaływania produktu pracy tego zespołu. Ma możliwość niezależ-
nego podejmowania decyzji w imieniu zespołu i uczy się rozwiązywać
problemy związane z zarządzaniem i przywództwem. Uczy się także
skutecznie współpracować z innymi działami, w szczególności odpowie-
dzialnymi za produkt i analitykę.
Inżynier może osiągać postępy w pracy zawodowej, nie pełniąc funkcji
lidera technicznego, ale takie doświadczenie najczęściej ułatwia przej-
ście z poziomu starszego inżyniera 1. stopnia do 2. stopnia, a także
Poleć książkęKup książkę58
Od inżyniera do menedż era
z poziomu starszego inżyniera 2. stopnia do głównego inżyniera. W prak-
tyce trudno jest awansować powyżej poziomu starszego inżyniera 2.
stopnia bez uprzedniego doświadczenia w roli lidera technicznego, na-
wet jeśli ktoś skupia się w swojej pracy na dokonaniach o charakterze
indywidualnym. Ma to związek z faktem, że na wyższych poziomach
struktury zarządzania duże znaczenie odgrywają odpowiedzialność i kom-
petencje przywódcze.
Dobry skrót tej definicji przedstawił Patrick Kua w swojej książce za-
tytułowanej Talking with Tech Leads1:
Lider odpowiedzialny za zespół programistów, który poświęca przynajm-
niej 30 procent swojego czasu na tworzenie kodu we współpracy z ze-
społem.
Lider techniczny ma możliwość podejmowania działań typowych dla
kierownika projektów technicznych. Może w dużym zakresie czerpać ze
swojego doświadczenia, aby usprawniać funkcjonowanie zespołu. Ma moż-
liwość podejmowania niezależnych decyzji i odgrywa dużą rolę w procesie
koordynacji współpracy z partnerami reprezentującymi dziedziny niein-
żynierskie. Jak zapewne zauważyłeś, nie ma tu mowy o konkretnych za-
daniach o charakterze technicznym. Funkcję lidera technicznego pełni star-
szy inżynier, nie należy jednak zakładać, że zwykle powierza się ją najlepszemu
lub najbardziej doświadczonemu spośród członków zespołu. Aby skutecznie
przewodzić, trzeba umieć wzbudzać w ludziach zaangażowanie, dlatego od
początkujących liderów technicznych oczekujemy nie tyle dużego doświad-
czenia w kwestiach technicznych, ile przede wszystkim gotowości do rozwi-
jania kompetencji interpersonalnych. Pełnienie tej funkcji wiąże się jednak
także z doskonaleniem umiejętności w niezwykle ważnej dziedzinie o cha-
rakterze technicznym, a konkretnie w obszarze zarządzania projektami.
Rozpisywanie projektu na zadania w znacznym stopniu przypomina pro-
jektowanie systemów, a doskonalenie tych umiejętności przydaje się również
inżynierom, którzy nie planują w przyszłości zajmować stanowisk mene-
dżerskich.
1 https://leanpub.com/talking-with-tech-leads
Poleć książkęKup książkęLider techniczny
59
Jeśli powierzono Ci funkcję lidera technicznego, możesz być z siebie
dumny! Najwyraźniej ktoś uznał, że potrafisz skutecznie reprezentować
swój zespół. Teraz powinieneś przyswoić sobie kilka nowych umiejętności.
W roli lidera technicznego
Praca lidera technicznego to ćwiczenie w zakresie oddziaływania bez
formalnej władzy. Jako lider techniczny przewodzę zespołowi, ale wszy-
scy teoretycznie podlegamy temu samemu menedżerowi odpowiedzial-
nemu za kwestie techniczne. Muszę zatem skutecznie oddziaływać nie
tylko na moich kolegów, ale również na menedżera, aby ten właściwie
ustalał priorytety. W tym zakresie musiałam zmierzyć się z dużym wy-
zwaniem. Otóż zaraz po objęciu funkcji lidera technicznego musiałam
jak najszybciej doprowadzić do tego, aby zespół przestał się zajmować
rozwijaniem cech produktu, a skupił się na długu technicznym. Dla
mnie było oczywiste, że sprawa długu technicznego była już zbyt długo
odkładana na później. Wdrażanie nowego kodu przebiegało z trudem,
obsługa dotychczasowych usług pochłaniała ogromne koszty, a dyżury
przerodziły się w istny koszmar. Uznałam, że powinniśmy teraz zwolnić,
żeby w przyszłości móc przyspieszyć. Deweloperów trudno było jednak
do tego przekonać. Oni chcieli tworzyć fajne nowe funkcjonalności. Me-
nedżerowi też się to nie podobało, klienci bowiem zgłaszali mu coraz
to nowe żądania. Ostatecznie jednak przekonałam wszystkich do swoich
racji, skupiając się na różnych korzyściach, które dzięki takiemu roz-
wiązaniu mogli uzyskać poszczególni członkowie zespołu. Dla jednych
liczyła się większa niezawodność usług, innym zależało na przyspiesze-
niu iteracji, jeszcze inni cieszyli się z poprawy sytuacji związanej z dy-
żurami, bo teraz mogli się w nocy wyspać. Podczas rozmów z mene-
dżerem kładłam nacisk na obniżenie kosztów stałych, zwracając przy
tym uwagę, że dzięki temu w przyszłości zespół będzie mógł bardziej się
skupić na funkcjach produktu.
Odkąd objęłam funkcję lidera technicznego, musiałam trochę zmienić
podejście do pracy. Teraz w pracy nie chodzi już w takim stopniu o mnie
i formułowanie technicznie ambitnych pomysłów czy realizację najfaj-
niejszych projektów. Teraz skupiam się w większym stopniu na zespole.
Jak sprawić, żeby czuli, że mogą coś osiągnąć? Jak usunąć przeszkody,
Poleć książkęKup książkę60
Od inżyniera do menedż era
które spowalniają ich pracę? Być może lepiej bym się bawiła, pisząc
od nowa jakiś fragment kodu albo pracując nad ciekawą nową funkcją.
Być może mogłabym w ten sposób w pełni wykorzystać swój potencjał
techniczny. W tamtym momencie z punktu widzenia zespołu ważniejsze
było rozwiązanie problemu długu technicznego i skupienie się na kwe-
stiach operacyjnych. Ostatecznie moja inicjatywa zakończyła się wielkim
sukcesem. Liczba krytycznych alertów pagerowych spadła o połowę,
a w kolejnym kwartale udało nam się zrealizować blisko dwukrotnie więcej
wdrożeń.
— Caitie McCaffrey
Dziwna sztuczka znana każdemu
świetnemu liderowi technicznemu
Skoro jesteś liderem technicznym, to znaczy, że wiesz co nieco na temat
programów komputerowych, a Twój menedżer najwyraźniej uznał, że po-
dołasz jeszcze większej odpowiedzialności ― związanej z prowadzeniem
projektów. Kompetencje techniczne i dojrzałość na nic się jednak nie zda-
dzą, jeśli nie opanujesz najważniejszej sztuczki lidera technicznego. Chodzi
mianowicie o to, że musisz na chwilę zapanować nad potrzebą pisania kodu
i poszukać stanu równowagi między własnym zaangażowaniem w sprawy
techniczne a potrzebami zespołu jako całości. Musisz przestać polegać wy-
łącznie na starych kompetencjach i zacząć zdobywać nowe. Z czasem dzięki
temu opanujesz sztukę utrzymywania równowagi.
Od tej pory na każdym kolejnym etapie Twojej kariery poszukiwanie
równowagi stanowić będzie jedno z największych wyzwań związanych
z wykonywaniem obowiązków zawodowych. Jeśli chcesz mieć całkowitą auto-
nomię w zakresie wykonywania swoich zadań, jeśli chcesz w pełni dowolnie
decydować o tym, nad czym i kiedy będziesz pracować, musisz najpierw
zapanować nad swoim czasem i nauczyć się go odpowiednio zagospoda-
rowywać. Niestety w wielu przypadkach będziesz też musiał zrezygnować
z aktywności, która przychodzi Ci bez trudu i sprawia Ci przyjemność (a więc
choćby z pisania kodu), na rzecz zadań, których jeszcze nie potrafisz wy-
konywać. Nie ma nic dziwnego w tym, że wolisz zajmować się czymś, co
Poleć książkęKup książkęLider techniczny
61
dobrze Ci wychodzi. Konieczność częściowej rezygnacji z tego, do czego
masz talent, aby zająć się nowymi rzeczami, których dopiero musisz się
uczyć, będzie rodziła zrozumiałe poczucie dyskomfortu.
Czasami trudno będzie znaleźć równowagę między sprawami związa-
nymi z zarządzaniem projektem a bezpośrednim nadzorem nad kwestiami
technicznymi. Plan Twojego dnia raz będzie bardziej przypominał pracę
inżyniera, kiedy indziej zaś wypełniać go będą przede wszystkim zadania
o charakterze menedżerskim. Metodą prób i błędów będziesz się musiał
nauczyć, jak zarządzać czasem w taki sposób, aby wszystkie zadania dało się
pomyślnie doprowadzić do końca. Największy błąd, jaki można popełnić na
etapie planowania harmonogramu, polega na chaotycznym wypełnianiu czasu
kolejnymi spotkaniami. Trudno się pisze kod, jeśli co godzinę jakieś spo-
tkanie wyrywa Cię z odpowiedniego rytmu.
Nawet w najlepiej ułożonym harmonogramie nie zawsze udaje się wy-
gospodarować czas na rozwiązywanie problemów programistycznych. Nie-
kiedy będziesz więc musiał zrezygnować z tego zajęcia nawet na kilka dni
z rzędu. Na szczęście zapewne zdołałeś już opanować umiejętność dzielenia
pracy na mniejsze elementy i nie będziesz potrzebował kilku dni pełnego
skupienia, aby doprowadzić zadanie techniczne do szczęśliwego finału.
Z drugiej strony wiesz, że praca Twojego zespołu powinna zostać zorgani-
zowana w taki sposób, aby jego członkowie mogli się skupiać na rozwijaniu
kodu w dłuższych blokach czasowych — ponieważ oni powinni się kon-
centrować na rozwiązywaniu problemów programistycznych przez kilka
dni z rzędu. Lider techniczny powinien ponadto w taki sposób koordy-
nować współpracę z innymi interesariuszami, w szczególności z przełożo-
nym i menedżerem produktu, aby zespół się nie rozpraszał. Kalendarz spo-
tkań należy ustalać tak, aby nie był zbyt obciążający dla poszczególnych
inżynierów.
Podstawowe informacje o pracy lidera technicznego
Załóżmy, że wraz z menedżerem produktów i zespołem złożonym z czterech
inżynierów pracujesz przy dużym, rozpisanym na kilkanaście tygodni pro-
jekcie, który ma się zakończyć uruchomieniem nowego przedsięwzięcia.
W takim przypadku lider techniczny ma do wykonania wiele różnych zadań,
Poleć książkęKup książkę62
Od inżyniera do menedż era
przy czym zakres jego obowiązków zmienia się wraz z rozwojem projektu.
Na pewno będziesz musiał od czasu do czasu napisać trochę kodu, na
pewno będziesz podejmować decyzje o charakterze technicznym. Na tym
jednak się Twoja rola nie kończy i też nie ta rola będzie w tym przypadku
najważniejsza.
Główne role lidera technicznego
Lider techniczny powinien przede wszystkim potrafić spojrzeć na projekt
w szerokim kontekście, aby praca cały czas posuwała się naprzód. Jak przejść
od organizacji i planowania własnej pracy przy pisaniu kodu do organizacji
i przywództwa w zakresie całego projektu?
Architekt systemów i analityk biznesowy
Występując w roli architekta systemów i analityka biznesowego, będziesz
odpowiedzialny za wskazywanie podstawowych zmian w systemach oraz naj-
ważniejszych funkcji, bez których nie da się wdrożyć planowanych projektów.
Twoje zadanie będzie polegać na nakreśleniu pewnej struktury, w ramach
której można wyliczać wartości szacunkowe i porządkować pracę. Nie mu-
sisz dokładnie definiować poszczególnych elementów projektu, zdecydowanie
jednak powinieneś zastanowić się nad różnymi czynnikami o charakterze
zewnętrznym, jak również nad potencjalnymi trudnościami związanymi
z jego realizacją. W tej roli będziesz się musiał wykazać rozległą wiedzą na
temat ogólnej architektury systemów oraz pogłębioną znajomością zasad
projektowania złożonego oprogramowania. Poza tym musisz też rozumieć
podstawowe wymogi biznesowe i uwzględniać je przy tworzeniu oprogra-
mowania.
Planista projektu
Planista rozpisuje projekt na ogólnie zdefiniowane produkty. Wcielając
się w tę rolę, uczysz się rozpisywać pracę w taki sposób, aby zespół mógł ją
sprawnie wykonać. Wyzwanie polega w tym przypadku między innym na
tym, aby możliwie dużo zadań było realizowanych równolegle. W praktyce
może się to okazać trudne, ponieważ dotychczas kwestię organizacji pracy
rozpatrywałeś z perspektywy indywidualnej, a nie grupowej. Zasadnicze
znaczenie ma poszukiwanie punktów, w których równoległa realizacja zadań
Poleć książkęKup książkęLider techniczny
63
stanie się możliwa dzięki zastosowaniu uzgodnionych abstrakcji. Na przy-
kład gdy aplikacja sieciowa pobiera obiekty JSON z API, kompletna im-
plementacja tego API nie jest konieczna, aby można było rozpocząć pracę nad
aplikacją. W takim wypadku wystarczy jedynie kompletna specyfikacja
formatu obiektów JSON. Możecie uzgodnić format JSON i zacząć go ko-
dować z wykorzystaniem obiektów dummy. Jeśli masz szczęście, miałeś już
kiedyś okazję widzieć, jak się to robi, i będziesz mógł wykorzystać już wy-
pracowane schematy. Na tym etapie powinieneś gromadzić dane od ekspertów
wchodzących w skład Twojego zespołu. Rozmawiaj z ludźmi, którzy posia-
dają szczegółową wiedzę na temat tych części programu i będą Ci mogli po-
móc w konkretnych sprawach. Poza tym w ramach tego procesu powinieneś
również zacząć definiować priorytety. Które elementy programu mają zna-
czenie krytyczne, a które można traktować jako opcjonalne? Jak to zrobić,
żeby tymi krytycznymi zająć się już we wczesnej fazie projektu?
Programista i lider zespołu
Programiści i liderzy zespołów piszą kod, zwracają uwagę na konkretne
wyzwania i rozdzielają zadania. W miarę rozwoju projektu z pewnością
pojawiają się różne nieoczekiwane przeszkody. Czasami lider techniczny
będzie odczuwał pokusę podjęcia heroicznego wysiłku w celu ich samo-
dzielnego przezwyciężenia. Będzie przesiadywać w pracy długo po godzinach,
żeby się ze wszystkim uporać. Pracując jako lider techniczny, powinieneś
nadal pisać kod, ale nie pisać go za dużo. Nawet jeśli masz ochotę zaimpo-
nować całemu światu zaradnością, przed podjęciem jakichkolwiek działań
powinieneś poinformować wszystkich o wystąpieniu przeszkody. Mene-
dżer produktu powinien dowiedzieć się o tym możliwie szybko. W miarę
możliwości zaangażuj do pomocy swojego menedżera do spraw technicz-
nych. W zdrowej organizacji nikt nie będzie miał do Ciebie pretensji, że na
wczesnym etapie zwróciłeś uwagę na potencjalny problem. Wiele zespołów
sprowadza na siebie poważne kłopoty przez to, że marnuje zasoby na pracę
nad czymś, z czego menedżer produktu byłby skłonny zrezygnować w obli-
czu zaistniałych trudności. Na krótko przed ostateczną datą realizacji du-
żego projektu kilka funkcji z pewnością zostanie skreślonych. Zacznij się
też zastanawiać, które zadania mógłbyś delegować. Delegowanie zadań
odgrywa istotną rolę zwłaszcza w sytuacji, gdy jesteś odpowiedzialny za
stworzenie części systemu, a dotychczas nie miałeś czasu się tym zająć.
Poleć książkęKup książkę64
Od inżyniera do menedż era
Jak zapewne łatwo wywnioskować z powyższych rozważań, praca lidera
technicznego wiąże się z wykonywaniem zadań typowych dla programisty,
architekta systemów, analityka biznesowego i lidera zespołu zdolnego
dokonać rozróżnienia na zadania, które wymagają jego własnego zaanga-
żowania, i zadania, które można zlecić do wykonania komuś innemu. Na
szczęście nie musisz realizować wszystkich tych zadań jednocześnie. Z po-
czątku może Cię to wszystko przytłaczać, z czasem jednak będziesz nabierać
wprawy i łatwiej Ci będzie wypracować odpowiednią równowagę.
Pytanie do dyrektora technicznego:
Nie cierpię pracować jako lider techniczny!
Wydawało mi się, że to będzie fajna sprawa, ale teraz się okazuje, że
muszę pilnować tych różnych szczegółów związanych ze statusem pro-
jektu. Menedżer oczekuje, że będę go na bieżąco informować, kiedy co
zostanie zrobione. Okropna sprawa. Dlaczego nikt mi wcześniej nie po-
wiedział, że to taka beznadziejna praca?
Zdaję sobie sprawę, że ogrom nowych obowiązków może Cię przy-
tłaczać. Zwykłam w tym przypadku mówić o „kamieniu triumfu” (od-
wołanie powinno być czytelne dla fanów Simpsonów). Kamień triumfu
to symbol uznania, którym człowiek cieszy się do momentu, gdy nagle
sobie uświadamia, że trzeba za nie zapłacić wysoką cenę. Zjawisko to
występuje na wielu etapach rozwoju inżyniera o aspiracjach przywód-
czych, zdecydowanie wyraźnie daje się jednak odczuć w związku z obję-
ciem funkcji lidera technicznego. Bardzo rzadko się zdarza, aby lider
techniczny mógł liczyć na podwyżkę lub awans w związku z objęciem
nowej funkcji, a podejmując się tej roli po raz pierwszy, człowiek zwykle
nie wie, czego powinien się spodziewać. Jak wspominałam na etapie
definiowania istoty tej funkcji, w wielu firmach rola lidera technicznego
ma charakter tymczasowy i stanowi zbiór obowiązków, które człowiek
podejmuje na pewien czas wielokrotnie w ciągu swojej kariery zawodo-
wej. Często jest to niezbędny krok na drodze do awansu na wyższe sta-
nowisko, na ogół jednak nie przynosi żadnych bezpośrednich i nama-
calnych korzyści.
Poleć książkęKup książkęLider techniczny
65
Dlaczego praca w roli lidera technicznego bywa tak wielkim obcią-
żeniem? Lider techniczny bierze na siebie obowiązki, których zakres
wykracza poza opis stanowiska starszego inżyniera odpowiedzialnego
wyłącznie za konkretny aspekt prac. Lider techniczny ma uczestniczyć
w tworzeniu architektury projektu i podejmować działania związane
z planowaniem pracy. Oczekuje się od niego, że zadba, aby zespół w pełni
rozumiał wymagania projektu, znał plan pracy i skutecznie realizował
poszczególne zadania. Często przy tym lider techniczny nie posiada szcze-
gólnych kompetencji menedżerskich ani też nie ma za sobą szkolenia
w zakresie wykonywania tych konkretnych obowiązków. W praktyce więk-
szość menedżerów oczekuje, że lider techniczny będzie pisać tyle samo
kodu co przed objęciem nowej funkcji, a dla niego oznacza to po prostu
zwiększenie zakresu obowiązków i ilości pracy do wykonania. Jeśli więc
podejmujesz to wyzwanie po raz pierwszy, to z całą pewnością masz
ręce pełne roboty.
Gratuję Ci zatem, ponieważ otrzymujesz kamień triumfu! Na szczęście
nosząc ten ciężar, z czasem staniesz się silniejszy i nabędziesz umie-
jętności przydatnych na kolejnych etapach kariery. Ten kamień nie zaw-
sze będzie tak ciężki, jak Ci się dziś wydaje.
Zarządzanie projektami
Bardzo dobrze pamiętam swoje pierwsze doświadczenie związane z za-
rządzaniem złożonym projektem. Pełniłam wówczas funkcję lidera tech-
nicznego po raz pierwszy w życiu, a mój zespół otrzymał do wykonania
bardzo złożone zadanie. Nasz stary system zbliżał się do granic wytrzy-
małości. Zastosowaliśmy już wszystkie możliwe hacki, więc przyszła pora
zastanowić się, w jaki sposób można by go rozdzielić na kilka maszyn. To
było w czasach, gdy koncepcja systemów rozproszonych dopiero raczko-
wała, a większość programistów nie znała dobrych praktyk związanych ze
stosowaniem tego rozwiązania. Dysponowaliśmy jednak zespołem napraw-
dę błyskotliwych ludzi, uznaliśmy więc, że uda nam się coś wymyślić.
Rzeczywiście się udało. Nie stało się to szybko, ale ostatecznie byliśmy
skuteczni. Sporo czasu potrzebowaliśmy, aby zastanowić się nad samym
projektem i nad sensownym rozłożeniem procesów obliczeniowych na
Poleć książkęKup książkę66
Od inżyniera do menedż era
różne maszyny. Potem pewnego dnia mój szef, Mike, zaprosił mnie do
swojego biura i powiedział, że mam przygotować plan projektu.
To było straszne!
Musiałam zapanować nad całym tym zbiorem straszliwie skompliko-
wanych zadań i stwierdzić, które z nich są od siebie zależne. Musiałam
uwzględnić najróżniejsze zależności. Jak to miałoby funkcjonować w ramach
naszego złożonego systemu testów? Jak miałoby wyglądać wdrożenie?
Kiedy trzeba zamówić sprzęt do testów? Ile czasu zajmą testy integracji?
Kolejne pytania tylko się mnożyły. Co chwila chodziłam z tym do Mike’a.
Siadałam po drugiej stronie dużego drewnianego biurka i wspólnie anali-
zowaliśmy opisy zadań, daty ich wykonania oraz podział. Trochę mi po-
magał, ale potem polecał samodzielnie zająć się tym, co jeszcze wymagało
dopracowania.
Zupełnie mi się to nie podobało. Zapamiętałam to doświadczenie jako
szereg frustrujących i nużących kroków prowadzących do przezwyciężenia
niepewności i strachu przed błędem czy pominięciem czegoś istotnego.
Chciałam stworzyć plan, który Mike by zaakceptował. Potem przyszła pora
na równie żmudne porządkowanie tych wszystkich informacji do postaci,
którą można by przedstawić przełożonym do akceptacji. Ledwo dałam radę.
Z drugiej strony była to jedna z najcenniejszych lekcji, jakie odebrałam
w całym swoim życiu zawodowym.
Czy w modelu zwinnego tworzenia programowania zarządzanie pro-
jektem w ogóle jest konieczne? Tak. Zwinne tworzenie programowania to
świetna koncepcja pracy. Zmusza człowieka do poszukiwania sposobu na
rozpisanie zadań na drobne elementy i tworzenia planu na ich podstawie.
Dzięki temu wartość można generować stopniowo, a nie od razu. To jednak
bynajmniej nie oznacza, że nie trzeba poznać zasad zarządzania projektem.
Na pewno nie raz zdarzy Ci się pracować przy projekcie, którego nie da
się zrealizować w jednym sprincie, ani nawet w dwóch krótkich sprintach.
Na potrzeby swojego zespołu kierowniczego będziesz zatem musiał ocenić
długość projektu, jak również wyjaśnić, jakie czynniki o niej decydują.
W przypadku niektórych projektów — zwykle wtedy, gdy w opisie pojawiają
się hasła takie jak infrastruktura, platforma czy system — trzeba z dużym
wyprzedzeniem zaplanować pewne kwestie i nakreślić architekturę. Jeśli
projekt obejmuje znaczną liczbę niewiadomych, a przy tym ma względnie
sztywno wyznaczone ramy czasowe, możesz dość szybko dojść do wnio-
Poleć książkęKup książkęLider techniczny
67
sku, że trudno jest go realizować zgodnie ze standardowymi założeniami
zwinnego procesu.
W miarę nabywania doświadczenia będziesz się też musiał nauczyć,
jak rozdzielać zadania, które są na tyle skomplikowane, że przekraczają
możliwości pojedynczego pracownika. Większość ludzi z niechęcią myśli
o długofalowych projektach zespołowych. Mnie się taka praca wydaje czymś
żmudnym, a niekiedy również odrobinę przerażającym. Zależy mi, aby ge-
nerować wartość. Nie lubię rozpisywać na poszczególne elementy produktu,
którego szczegóły implementacyjne nie zostały jeszcze precyzyjnie okre-
ślone. Boję się odpowiedzialności i martwię się, że mogłabym pominąć coś
ważnego, przez co projekt mógłby się nie udać. Alternatywa przewiduje jed-
nak, że tragiczny finał po prostu trochę się opóźni.
Nie każdym projektem trzeba szczegółowo zarządzać, organizacje zresztą
często z tym przesadzają. Osobiście niechętnie zatrudniam menedżerów
projektu, ponieważ inżynierowie nadmiernie na nich polegają zamiast uczyć
się planować własną pracę i zadawać sobie ważne pytania o istotę i sens
wykonywanych zadań. Obecność menedżera projektu powoduje, że ini-
cjatywa zwykle traci zwinny charakter i zbliża się do modelu kaskadowego.
Ogólnie jednak od zarządzania projektami nie da się uciec, a Ty jako lider
techniczny powinieneś w razie konieczności — zwłaszcza w przypadku
projektów o wysoce technicznym charakterze — wziąć to zadanie na siebie.
W ostatecznym rozrachunku o wartości planu nie decyduje to, na ile
dokładnie został zrealizowany i czy udało się uwzględnić każdy szczegół
i przewidzieć przyszłość. Liczy się przede wszystkim samodyscyplina w dzie-
dzinie refleksji. Chodzi o to, aby pewne kwestie przemyśleć z wyprzedze-
niem, a nie zacząć działać i na bieżąco obserwować, co się będzie działo.
Chodzi o to, aby tam, gdzie da się pewne rzeczy przewidzieć i zaplanować,
faktycznie się przez chwilę zastanowić. Sam plan — i to, na ile pokrywa
się z rzeczywistością — ma mniejsze znaczenie niż czas poświęcony na
planowanie.
Wróćmy jednak do moich pierwszych doświadczeń związanych z za-
rządzaniem projektem. Czy ten projekt udało się zrealizować dokładnie
zgodnie z planem? Oczywiście, że nie. Komplikacji, błędów i opóźnień nie
dało się uniknąć. Pewne rzeczy umknęły też naszej uwadze. Ogólnie jednak
udało nam się zakończyć projekt mniej więcej w terminie i wcale nie trzeba
Poleć książkęKup książkę68
Od inżyniera do menedż era
było w tym celu zarywać nie wiadomo ilu nocy. Zdołaliśmy wprowadzić
niezbędne zmiany i stworzyć na podstawie złożonego systemu artefakt roz-
proszony, mimo że jednocześnie czterdziestu innych programistów odpo-
wiedzialnych za kod główny cały czas wprowadzało do niego swoje zmia-
ny. O naszym sukcesie zadecydowały dwa czynniki: świetny zespół i plan.
Zastanawialiśmy się, do czego konkretnie zmierzamy. Udało nam się rów-
nież z wyprzedzeniem przewidzieć potencjalne czynniki zagrożenia.
Od czasu, gdy raz po raz frustrowałam się u Mike’a w gabinecie, miałam
okazję wielokrotnie uczestniczyć w spotkaniach poświęconych planowaniu
projektów, tyle że tym razem to ja siedziałam na miejscu przełożonego, po
drugiej stronie mając Carla, Alicię albo Tima. Wszyscy się frustrowali na myśl
o tym, że pewne szczegóły trzeba jeszcze dopracować. Wszyscy wychodzili
i nieco wbrew sobie poświęcali czas na refleksję nad czymś innym niż kod,
czego nie da się precyzyjnie przewidzieć. Wszyscy oni mieli okazję dopro-
wadzić złożony projekt do szczęśliwego finału, a dzięki temu posiadają dziś
szersze kompetencje w zakresie tworzenia bardziej rozbudowanych sys-
temów i kierowania większymi zespołami — ponieważ dobrze rozumieją,
na czym w istocie polega rozpisywanie projektu na zadania.
Znajdź czas na wyjaśnienia
Pod koniec przewodu doktorskiego przychodzi czas na obronę pracy.
W tym momencie doktorant, który ma za sobą wiele lat badań, przed-
stawia wyniki swojej pracy komisji złożonej z ekspertów w danej dziedzi-
nie. Oni zaś oceniają, czy kandydat zasługuje na przyznanie mu tytułu
naukowego. Wiele lat temu udało mi się uzyskać tytuł doktora nauk ma-
tematycznych w ramach jednego z najbardziej prestiżowych amerykań-
skich programów matematyki stosowanej. W komisji zasiadał wówczas
uznany specjalista w dziedzinie analizy numerycznej. Po pomyślnie prze-
prowadzonej obronie powiedział mi coś, o czym pamiętałam na każdym
kolejnym kroku mojej kariery zawodowej (niezwiązanej z matematyką
jako taką). Otóż powiedział: „Od lat nie czytałem tak przemyślanej i ja-
sno napisanej pracy. Dziękuję”. Cieszyłem się z tych wyrazów uznania,
ale jednocześnie byłem nieco zaskoczony. Wcześniej zakładałem, że
ten człowiek — jako światowej klasy matematyk — po prostu „wszyst-
ko wie” i tylko „śledzi” bieg myśli w mojej pracy. Z jego słów wynikało
Poleć książkęKup książkęLider techniczny
69
tymczasem, że faktycznie wiedział, ale przede wszystkim dlatego, że za-
dałem sobie trud omówienia podstawowych zagadnień związanych z prze-
strzenią problemu i źródłami moich pomysłów. To była lekcja, o której
nigdy nie zapomniałem. Od wielu lat zajmuję się programowaniem i pra-
cuję w dużych organizacjach, ale dziś doceniam te słowa nawet bardziej.
Nam, inżynierom, wydaje się, że menedżerowie rozumieją, czym
się zajmujemy. Wystarczy przecież przeczytać sobie kod! Ten program,
którym my na co dzień żyjemy, powinien wszak być czymś zupełnie
oczywistym dla każdego fachowca z branży technologicznej. Prawda?
Otóż nie jest. Menedżerowie odpowiedzialni za kwestie techniczne za-
trudniają — jeśli im się uda — najlepszych możliwych fachowców, któ-
rym powierzają do rozwiązania bardzo trudne problemy. To jednak nie
znaczy, że wszystko rozumieją. Menedżerowie techniczni wysokiego
szczebla często mnie zaskakiwali, dziękując za wyjaśnienie im w przy-
stępny i niearogancki sposób pewnych bardzo podstawowych nowych
kwestii (na przykład: „O co chodzi z tym całym NoSQL i dlaczego powin-
no mnie to interesować?”).
Ostatnio jeden z menedżerów biznesowych wysokiego szczebla po-
prosił mnie o rozmowę twarzą w twarz i zapytał, dlaczego powinniśmy
przejść od tradycyjnej architektury grubego klienta na platformę hostin-
gową. Mocno na niego naciskano w tej sprawie, a on nie potrafił zro-
zumieć, dlaczego to jest konieczne. Pewnie też nie bardzo chciał pytać
o to przy wszystkich. Zajęło mi to dwie godziny, ale z powodzeniem
mu to zagadnienie wyjaśniłem (bez konieczności korzystania z programu
PowerPoint). Dziś korzystam z każdej nadarzającej się okazji, aby tłu-
maczyć ludziom z różnych szczebli organizacji różne podstawowe za-
gadnienia i przyczyny podjęcia różnych decyzji. Oni dzięki temu mogą
pogłębić wiedzę w komfortowych warunkach. Nabierają przy tym zaufa-
nia do mnie i moich rad, a następnie razem wcielamy zmiany w życie.
Naprawdę warto poświęcić trochę czasu na tłumaczenie różnych kwestii.
— Michael Marçal
Poleć książkęKup książkę70
Od inżyniera do menedż era
Zarządzanie projektem
Zarządzanie projektem wymaga rozpisania złożonego celu końcowego na
mniejsze elementy, a następnie ustawienia tych elementów w optymalnej
kolejności. Chodzi o to, aby zadania były wykonywane w możliwie efek-
tywny sposób. Należy też wskazać te elementy, nad którymi prace mogą
się toczyć jednocześnie, oraz te, które należy wykonywać w określonej kolej-
ności. Warto usunąć z projektu niewiadome, które mogłyby spowolnić
prace lub doprowadzić do fiaska całego przedsięwzięcia. Masz do czynienia
z niepewnością, starasz się wskazać niewiadome. Musisz mieć przy tym
świadomość, że pomimo najszczerszych chęci nie da się uniknąć wszystkich
błędów ani uwzględnić nieprzewidzianych zdarzeń. Oto kilka podstawowych
wskazówek:
1. Rozdziel pracę na mniejsze części. Wykorzystaj arkusz kalkulacyjny,
diagram lub dowolne inne narzędzie, które Ci najlepiej pasuje. Zacznij
rozpisywać efekt końcowy (a więc na przykład system rozliczeniowy)
na konkretne zadania. Zacznij od największych elementów, potem spró-
buj podzielić je na mniejsze, a te na jeszcze mniejsze części. Nie musisz
wszystkiego robić sam. Jeśli pewne elementy tego systemu nie do końca
rozumiesz, poproś o pomoc kogoś, kto się na tym zna. Po rozdzieleniu
pracy na mniejsze elementy zajmij się jej porządkowaniem. Które zada-
nia można od razu przekazać do realizacji? Zleć je ludziom, którzy będą
potrafili sprowadzić je do poziomu ticketów.
2. Uporaj się ze szczegółami i niewiadomymi. Cała sztuka z zarządza-
niem projektami polega na tym, aby nie rezygnować, gdy coś przestanie
iść albo gdy praca zacznie nas męczyć. Jak już wcześniej wspomina-
łam, ta praca z natury swojej jest męcząca i żmudna. Najprawdopo-
dobniej nie będziesz wiedzieć, jak sobie z nią poradzić. Spróbuj zatem
przezwyciężyć irytację, znudzenie i ból. Dobry menedżer na pewno Ci
podpowie, nad czym jeszcze trzeba pracować. Być może zada Ci pyta-
nia naprowadzające albo nawet pomoże uporać się z niektórymi kwe-
stiami. Dla niego to też nie będzie przyjemne, ale to element procesu
kształcenia podwładnych. Niewiadome należy poddawać analizie do
momentu, w którym dojdziemy do wniosku, że dalsze rozważania nie
przyniosą już żadnych dodatkowych korzyści.
Poleć książkęKup książkęLider techniczny
71
3. Realizując projekt, na bieżąco modyfikuj plan. Dzięki skutecznemu
planowaniu można potem mniej więcej stwierdzić, jaką część projektu
udało się już zrealizować i ile jeszcze przed nami. Gdy coś pójdzie nie
tak — a stanie się to na pewno — informuj wszystkich zainteresowanych
o stanie projektu. Zamiast jednak wybiegać nie wiadomo jak daleko
w przyszłość, skup się na dotychczasowych osiągnięciach i wyjaśnij, co
jeszcze zostało do zrobienia.
4. Wykorzystaj spostrzeżenia poczynione na etapie planowania, aby
zarządzać wymaganiami. Rozpisując projekt na zadania, miałeś okazję
sformułować wiele różnych wniosków dotyczących jego wymagań. Jeśli
w trakcie pracy wymagania te ulegną zmianie, będziesz mógł wykorzystać
poczynione wcześniej spostrzeżenia, aby odpowiednio dostosować swoje
założenia. Jeżeli zaistniałe zmiany powodują istotny wzrost ryzyka zwią-
zanego z projektem, rodzą konieczność podjęcia dodatkowych prac
w zakresie planowania, ewentualnie po prostu zwiększają ilość pracy
do wykonania w ramach projektu, wówczas powinieneś jasno określić
związane z tym koszty. Gdy termin jest sztywny, możliwość przewidy-
wania zakresu prac niezbędnych do osiągnięcia celu pomaga przy usta-
laniu priorytetów, a także przy ograniczaniu bądź upraszczaniu pewnych
zadań w celu ustalenia optymalnego poziomu funkcjonalności czy jako-
ści, względnie racjonalnego terminu realizacji.
5. Pod koniec projektu ponownie poddaj analizie różne szczegóły. Kiedy
projekt jest na ukończeniu, znów czeka Cię trochę żmudnej pracy. Teraz
musisz na poważnie pochylić się nad szczegółami. Czego dotychczas
zabrakło? Jakich testów? Jakiej weryfikacji? Przeprowadź tak zwaną
analizę premortem, w ramach której analizuje się poszczególne przy-
czyny ewentualnego niepowodzenia projektu w momencie jego uru-
chomienia. Należy wytyczyć linię „dość dobrego wyniku”, a następnie
przekazać ją wszystkim do wiadomości i przyjąć jako punkt odniesienia.
W związku z wytyczeniem tej linii z niektórych zadań należy po prostu
zrezygnować, skupiając się na kwestiach najistotniejszych z punktu wi-
dzenia ostatecznego rezultatu. Opracuj plan uruchomienia projektu.
Opracuj również plan wycofywania zmian. A gdy już skończysz, nie
zapomnij tego uczcić!
Poleć książkęKup książkę72
Od inżyniera do menedż era
Pytanie do dyrektora technicznego:
Nie wiem, czy chcę być liderem technicznym
Mój menedżer ciągle próbuje mnie namówić do objęcia roli lidera tech-
nicznego. Chce mi powierzyć duży projekt. Mam pełną świadomość, że
jeśli się zgodzę, to będę mieć znacznie mniej czasu na pisanie własne-
go kodu, bo przecież będę uczestniczyć w różnych spotkaniach i będę
mieć liczne obowiązki związane z koordynowaniem pracy. Wydaje mi się,
że nie mam na to ochoty. Tylko nie do końca potrafię się zdecydować.
Mam bardzo ściśle sprecyzowane własne zdanie na temat przymu-
szania ludzi do pełnienia funkcji kierowniczych. Uważam mianowicie,
że nie należy tego robić. Jeśli nie czujesz się gotów, by wziąć na siebie
obowiązki związane z zarządzaniem, to po prostu ich nie bierz. Nie ma
nic złego w tym, że człowiek zajmuje się wyłącznie technologią, zwłasz-
cza jeśli daleko mu jeszcze do osiągnięcia poziomu eksperckiego.
Dobry menedżer poszukuje talentów, którym można by powierzyć
ambitniejsze zadania kierownicze, w rezultacie jednak skutkuje to przed-
wczesnym odrywaniem ludzi od pracy związanej z kodowaniem. Coś
takiego może mieć bardzo niekorzystny wpływ na przebieg Twojej kariery
zawodowej, ponieważ na wyższych stanowiskach kierowniczych brak
dostatecznych kompetencji technicznych może utrudniać awans. Zde-
cydowanie łatwiej jest uczyć się rzemiosła w roli szeregowego pracowni-
ka niż wtedy, gdy jednocześnie trzeba również opanowywać umiejęt-
ności związane z zarządzaniem.
W pewnym momencie zapewne będziesz musiał objąć funkcję lidera
technicznego, jeśli będziesz myśleć o awansie (a być może również wtedy,
gdy będziesz chciał zachować swój dotychczasowych status specjalisty).
To jednak nie oznacza, że musisz się na to decydować już teraz. Skoro
masz poczucie, że ciągle jeszcze powinieneś się skupiać na doskona-
leniu kompetencji czysto technicznych i że wolałbyś zajmować się przy
tym projekcie konkretnymi zadaniami, niekoniecznie zaś sprawami or-
ganizacyjnymi, to nie podejmuj się funkcji lidera technicznego. Jeżeli
jednak stwierdzisz, że zadania o charakterze czysto technicznym nie
będą dla Ciebie dostatecznym wyzwaniem, to może powinieneś spró-
bować nauczyć się czegoś nowego — zadania związane z funkcją lidera
technicznego to po temu dobra okazja.
Poleć książkęKup książkęLider techniczny
73
Decyzja: kariera techniczna czy menedżerska?
Decyzja o tym, czy skupić się na rozwoju kompetencji czysto technicznych,
czy raczej wybrać menedżerską ścieżkę rozwoju, nie należy do łatwych.
Ponieważ wymaga uwzględnienia konkretnego kontekstu, nie jestem w sta-
nie niczego w tej kwestii doradzać w ciemno. Sama jednak zawsze marzy-
łam o dwutorowej karierze i na taką się też zdecydowałam, mogę więc po-
dzielić się z Tobą moimi wyobrażeniami na temat obu tych ról — i mogę
też napisać, jak to wyglądało w praktyce w moim przypadku. Zastrzegam
z góry, że wnioski są nieco przerysowane i mogą z czasem stracić na aktu-
alności. Tak czy owak, pozwolę sobie opowiedzieć o tym, jak się w moim
przypadku miała rzeczywistość do wyobrażeń.
Wyobrażenia na temat życia starszego specjalisty
Twoje dni upływają na głębokiej refleksji, rozwiązywaniu problemów, które
stanowią nowe i ciekawe wyzwanie intelektualne, oraz na współpracy z in-
nymi myślicielami. Zajmujesz się programowaniem, więc od czasu do cza-
su zdarzy Ci się zrobić coś mało produktywnego, niekiedy jednak trafiają
się też bardzo interesujące zadania. Do tego wszystkiego możesz w dużym
stopniu decydować, czym się będziesz zajmować. Uwielbiasz pisać kod, po-
prawiać kod, przyspieszać kod i uczyć komputery nowych rzeczy. Większość
swojego czasu poświęcasz właśnie na to.
Masz duże doświadczenie zawodowe, więc menedżerowie zwracają się
do Ciebie po radę w sprawie wyboru najlepszego podejścia do rozwiązania
problemu. Wiesz, co się dzieje, ale nie musisz zaprzątać sobie głowy szcze-
gółami projektowania. Uczestniczysz tylko w tych spotkaniach, podczas któ-
rych zapadają rzeczywiście istotne decyzje. Zebrania odbywają się na tyle
rzadko, że możesz spokojnie pracować. Mniej doświadczeni programiści
traktują Cię jak autorytet i podążają wiernie za Twoimi wskazówkami. Cze-
kają na Twoje uwagi, ale nie zajmują Ci zbyt wiele czasu.
Cały czas pniesz się w górę w strukturach organizacji, a ambitnych wy-
zwań, przy których mógłbyś się wykazać, nigdy nie brakuje. Na co dzień
ciężko pracujesz, ale nikt raczej nie oczekuje od Ciebie, żebyś zostawał po
godzinach albo przychodził do pracy w weekendy. Wszyscy doskonale
wiedzą, że nie da się wydajnie pracować przez nie wiadomo ile godzin w ty-
godniu. Jeśli już zostajesz do późna, to tylko po to, aby nie tracić rozpędu
Poleć książkęKup książkę74
Od inżyniera do menedż era
i doprowadzić do końca prace nad jakąś fascynującą funkcją, ewentualnie
po to, aby usunąć jakiś właśnie odkryty błąd.
Masz czas pisać książki, wygłaszać wykłady i tworzyć oprogramowanie
open
Pobierz darmowy fragment (pdf)