Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00029 002897 20668014 na godz. na dobę w sumie
wyszukaj dokładnie | pobierz wtyczkę
Od inżyniera do menedżera. Tajniki lidera zespołów technicznych - książka
Od inżyniera do menedżera. Tajniki lidera zespołów technicznych - książka
Autor: Liczba stron: 312
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-3899-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook (-25%), audiobook).
Czytaj online.
Komentuj

Zarządzanie grupą ludzi nie jest proste w żadnej branży. Trzeba sporego wysiłku, wiedzy i doświadczenia, aby z kilku czy kilkunastu osób o różnych charakterach stworzyć prawdziwy zespół, który wspólnie będzie podążał do celu i rozwiązywał problemy. Zarządzanie pracą inżynierską jest szczególnym wyzwaniem — lider inżynier musi mieć zarówno kompetencje przywódcze, jak i wiedzę techniczną. Wiele świetnie rokujących projektów poniosło spektakularną porażkę tylko dlatego, że zabrakło menedżera technicznego o odpowiednich umiejętnościach.

Niezależnie od tego, czy jesteś osobą kierującą dużym zespołem, początkującym menedżerem, czy inżynierem czuwającym nad pracą stażysty, znajdziesz w tej książce sporo praktycznych rad, które pomogą Ci w przezwyciężeniu problemów typowych dla zespołów inżynierskich. Znalazły się tu informacje dotyczące mentoringu, wdrażania nowych pracowników, pracy liderów technicznych, kierowników i menedżerów zarządzających wieloma zespołami. Opisano metody radzenia sobie z konfliktami i neutralizowania czynników osłabiających spójność zespołu. Nie zabrakło również praktycznych wskazówek dotyczących zarządzania czasem, delegowania zadań i oceny ich realizacji, a także kreowania strategii firmy i budowania jej kultury.

W tej książce:

Stworzyć zespół z inżynierów — oto wyzwanie godne lidera!

Camille Fournier jest doświadczoną liderką łączącą rozległe kompetencje przywódcze z szeroką wiedzą techniczną. Była wiceprezesem ds. technologii w firmie Goldman Sachs w Nowym Jorku, a obecnie jest opiekunką projektu open source Apache ZooKeeper i regularnie publikuje dla O’Reilly Media. Jest chętnie zapraszana do udziału w licznych konferencjach, podczas których często zabiera głos na tematy związane z technologią IT, przywództwem w zespołach inżynierskich i kierowaniem projektami.

Znajdź podobne książki Ostatnio czytane w tej kategorii

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)

Gdzie kupić całą publikację:

Od inżyniera do menedżera. Tajniki lidera zespołów technicznych
Autor:
Sklep
Format
Cena
Helion.pl Helion.pl
książka
44,25 zł
Idź do sklepu »

Opinie na temat publikacji:

Inne popularne pozycje z tej kategorii:

Czytaj również:

Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: