Dedykowany menadżerom projektów (oraz tym, którzy marzą o zostaniu szefem).
Pisanie ton kodu jest trudne, ale zarządzanie ludźmi jest jeszcze trudniejsze! Potrzebujesz więc tej książki, aby dowiedzieć się, jak zrobić jedno i drugie.
Czy można połączyć zabawne historie z poważnymi lekcjami? Michaelowi Loppowi (znanemu także w wąskich kręgach jako Rands) udało się. Znajdziesz fikcyjne historie o fikcyjnych ludziach z niezwykle satysfakcjonującymi (choć fikcyjnymi) doświadczeniami. W ten sposób Rands dzieli się swoimi różnorodnymi, czasem dziwnymi doświadczeniami zdobytymi przez lata pracy w dużych korporacjach IT: Apple, Pinterest, Palantir, Netscape, Symantec itp.
Czy jesteś kierownikiem projektu? A może chcesz zrozumieć, co twój cholerny szef robi przez cały dzień? Rands nauczy Cię, jak przetrwać w toksycznym świecie napompowanych indyków i prosperować w ogólnym szaleństwie dysfunkcjonalnie ekstrawaganckich ludzi. W tej dziwnej społeczności maniaków-mózgów żyją jeszcze dziwniejsze istoty – menedżerowie, którzy poprzez mistyczny rytuał organizacyjny zdobyli władzę nad planami, myślami i kontami bankowymi wielu ludzi.
Ta książka nie przypomina żadnego innego podręcznika o zarządzaniu i przywództwie. Michael Lopp niczego nie ukrywa, po prostu opowiada, jak jest (może nie wszystkie historie powinny być upubliczniane: P). Ale tylko w ten sposób zrozumiesz, jak przetrwać z takim szefem, jak zarządzać maniakami i nerdami i jak doprowadzić „ten cholerny projekt” do szczęśliwego zakończenia!
Fragment. Inżynierska mentalność
Myśli na temat: Czy powinieneś kontynuować pisanie kodu?
Książka Randsa na temat zasad obowiązujących menedżerów zawiera bardzo krótką listę „obowiązkowych zadań” współczesnego menedżera. Lakonizm tej listy wynika z faktu, że pojęcie „musi” jest swego rodzaju absolutem, a w przypadku ludzi pojęć absolutnych jest bardzo niewiele. Skuteczna metoda zarządzania dla jednego pracownika będzie prawdziwą katastrofą dla innego. Ta myśl jest pierwszą pozycją na liście „obowiązkowych” zadań menedżera:
Zachowaj elastyczność!
Myślenie, że już wszystko wiesz, jest bardzo złym pomysłem. W sytuacji, gdy jedynym stałym faktem jest to, że świat ciągle się zmienia, elastyczność staje się jedyną słuszną postawą.
Paradoksalnie druga pozycja na liście jest zaskakująco sztywna. Jednak ten punkt jest moim osobistym faworytem, ponieważ uważam, że pomaga stworzyć podstawę rozwoju menedżerskiego. Ten akapit brzmi:
Przestań pisać kod!
Teoretycznie, jeśli chcesz być menadżerem, musisz nauczyć się ufać tym, którzy dla ciebie pracują i przekazywać im całkowicie kodowanie. Ta rada jest zwykle trudna do przetrawienia, zwłaszcza dla świeżo upieczonych menedżerów. Prawdopodobnie jednym z powodów, dla których zostali menedżerami, jest ich produktywność w rozwoju, a gdy coś pójdzie nie tak, ich pierwszą reakcją jest poleganie na umiejętnościach, do których mają pełne zaufanie, czyli umiejętności pisania kodu.
Kiedy widzę, że świeżo upieczony menadżer „pogrąża się” w pisaniu kodu, mówię mu: „Wiemy, że potrafisz pisać kod. Pytanie brzmi: czy potrafisz przewodzić? Nie jesteś już odpowiedzialny tylko za siebie, jesteś odpowiedzialny za cały zespół; i chcę mieć pewność, że Twój zespół będzie mógł samodzielnie rozwiązywać problemy, bez konieczności samodzielnego pisania kodu. Twoim zadaniem jest wymyślenie, jak skalować siebie. Nie chcę, żebyś był tylko jednym, chcę, żeby było wielu takich jak ty.
Dobra rada, prawda? Skala. Kierownictwo. Odpowiedzialność. Takie popularne hasła. Szkoda, że rada jest błędna.
Błędny?
Tak. Rada jest błędna! Nie do końca błędne, ale na tyle błędne, że musiałem zadzwonić do kilku byłych kolegów i przeprosić: „Pamiętasz moje ulubione stwierdzenie o tym, jak powinieneś przestać pisać kod? To jest źle! Tak... Rozpocznij programowanie ponownie. Zacznij od Pythona i Ruby. Tak jestem poważny! Od tego zależy Twoja kariera!”
Kiedy zaczynałem karierę jako programista w firmie Borland, pracowałem w zespole Paradox Windows, który był ogromnym zespołem. Samych twórców aplikacji było 13. Jeśli dodamy do tego osoby z innych zespołów, które również stale pracowały nad kluczowymi technologiami dla tego projektu, takimi jak rdzeń silnika bazy danych i podstawowe usługi aplikacyjne, otrzymamy 50 inżynierów bezpośrednio zaangażowanych w rozwój tego produktu.
Żaden inny zespół, dla którego kiedykolwiek pracowałem, nie jest nawet zbliżony do tej wielkości. Tak naprawdę z każdym rokiem liczba osób w zespole, w którym pracuję, stopniowo maleje. Co się dzieje? Czy my, programiści, wspólnie stajemy się coraz mądrzejsi? Nie, po prostu dzielimy się obciążeniem.
Co deweloperzy robili przez ostatnie 20 lat? W tym czasie napisaliśmy mnóstwo kodu. Morze kodu! Napisaliśmy tak dużo kodu, że zdecydowaliśmy, że dobrym pomysłem będzie uproszczenie wszystkiego i przejście na oprogramowanie typu open source.
Na szczęście dzięki Internetowi proces ten stał się teraz tak prosty, jak to tylko możliwe. Jeśli jesteś programistą, możesz to sprawdzić już teraz! Wyszukaj swoje imię i nazwisko w Google lub Github, a zobaczysz kod, o którym dawno zapomniałeś, ale który każdy może znaleźć. Straszne, prawda? Czy nie wiedziałeś, że ten kod żyje wiecznie? Tak, żyje wiecznie.
Kod żyje wiecznie. A dobry kod nie tylko żyje wiecznie, ale rośnie, ponieważ ci, którzy go cenią, stale dbają o to, aby pozostał świeży. Ten stos wysokiej jakości, dobrze utrzymanego kodu pomaga zmniejszyć średnią wielkość zespołu inżynierów, ponieważ pozwala nam skoncentrować się na istniejącym kodzie zamiast na pisaniu nowego kodu, a także wykonać zadanie przy mniejszej liczbie osób i w krótszym czasie.
Ten sposób rozumowania brzmi przygnębiająco, ale pomysł jest taki, że wszyscy jesteśmy tylko bandą automatów integracyjnych używających taśmy klejącej do łączenia różnych fragmentów istniejących rzeczy w celu stworzenia nieco innej wersji tego samego. Jest to klasyczny sposób myślenia wśród kadry kierowniczej wyższego szczebla, która kocha outsourcing. „Każdy, kto wie, jak korzystać z Google i ma trochę taśmy klejącej, może to zrobić! Dlaczego więc płacimy dużo pieniędzy za nasze maszyny?”
Płacimy tym menadżerom naprawdę duże pieniądze, a oni myślą takie bzdury. Jeszcze raz podkreślam, że na naszej planecie jest wielu genialnych i bardzo ciężko pracujących programistów; są naprawdę błyskotliwi i pracowici, chociaż nie spędzili ani minuty na akredytowanych uniwersytetach. O tak, teraz jest ich coraz więcej!
Nie sugeruję, abyś zaczął martwić się o swoje miejsce tylko dlatego, że rzekomo polują na niego jacyś genialni towarzysze. Sugeruję, abyś zaczął się tym martwić, ponieważ ewolucja rozwoju oprogramowania prawdopodobnie postępuje szybciej niż Ty. Pracujesz dziesięć lat, w tym pięć jako menadżer, i myślisz: „Już wiem, jak powstaje oprogramowanie”. Tak ty wiesz. Do widzenia…
Przestań pisać kod, ale...
Jeśli zastosujesz się do mojej pierwotnej rady i przestaniesz pisać kod, dobrowolnie przestaniesz także uczestniczyć w procesie tworzenia. Z tego też powodu nie korzystam aktywnie z outsourcingu. Automaty nie tworzą, one produkują. Dobrze zaprojektowane procesy pozwalają zaoszczędzić sporo pieniędzy, ale nie wnoszą niczego nowego do naszego świata.
Jeśli masz mały zespół, który dużo robi za niewielkie pieniądze, to pomysł zaprzestania pisania kodu wydaje mi się złą decyzją zawodową. Nawet w gigantycznych firmach z ich niekończącymi się przepisami, procesami i politykami nie masz prawa zapomnieć, jak samodzielnie tworzyć oprogramowanie. A rozwój oprogramowania ciągle się zmienia. To się teraz zmienia. Pod twoimi stopami! W tej właśnie sekundzie!
Masz zastrzeżenia. Zrozumieć. Posłuchajmy.
„Rands, idę na fotel reżysera! Jeśli będę dalej pisać kod, nikt nie uwierzy, że mogę się rozwijać.”
Chcę Cię zapytać: odkąd zasiadłeś w fotelu „Zaraz zostanę dyrektorem generalnym!”, czy zauważyłeś, że krajobraz tworzenia oprogramowania zmienia się, nawet w Twojej firmie? Jeśli Twoja odpowiedź brzmi „tak”, to zadam Ci kolejne pytanie: jak dokładnie to się zmienia i co zamierzasz zrobić z tymi zmianami? Jeśli na moje pierwsze pytanie odpowiedziałeś „nie”, to musisz przenieść się na inne krzesło, ponieważ (założę się!) dziedzina tworzenia oprogramowania zmienia się w tej sekundzie. Jak będziesz się rozwijać, jeśli powoli, ale z pewnością zapomnisz, jak tworzyć oprogramowanie?
Moja rada jest taka, aby nie angażować się we wdrażanie mnóstwa funkcji w następnym produkcie. Musisz stale podejmować kroki, aby być na bieżąco z tym, jak Twój zespół tworzy oprogramowanie. Możesz to zrobić zarówno jako dyrektor, jak i jako wiceprezes. Coś innego?
„Uch, Rands! Ale ktoś musi być arbitrem! Ktoś musi zobaczyć szerszą perspektywę. Jeśli napiszę kod, stracę perspektywę.”
Nadal musisz być sędzią, nadal musisz transmitować decyzje i nadal musisz chodzić po budynku cztery razy w każdy poniedziałek rano z jednym ze swoich inżynierów, aby przez 30 minut słuchać jego cotygodniowej tyrady „Wszyscy jesteśmy skazani” minut.! Ale poza tym wszystkim musisz zachować inżynieryjny sposób myślenia i nie musisz być programistą na pełen etat, aby to robić.
Moje wskazówki, jak zachować mentalność inżyniera:
- Skorzystaj ze środowiska programistycznego. Oznacza to, że powinieneś znać narzędzia swojego zespołu, w tym system budowania kodu, kontrolę wersji i język programowania. Dzięki temu będziesz biegły w posługiwaniu się językiem, którego używa Twój zespół, mówiąc o rozwoju produktu. Umożliwi to także dalsze korzystanie z ulubionego edytora tekstu, który działa doskonale.
- Musisz być w stanie w dowolnym momencie narysować szczegółowy schemat architektoniczny opisujący Twój produkt na dowolnej powierzchni. Nie mam tu na myśli uproszczonej wersji z trzema komórkami i dwiema strzałkami. Musisz znać szczegółowy schemat produktu. Najtrudniejszy. Nie byle jaki ładny diagram, ale taki, który trudno wyjaśnić. Powinna to być mapa umożliwiająca pełne zrozumienie produktu. Ciągle się zmienia i zawsze powinieneś wiedzieć, dlaczego nastąpiły pewne zmiany.
- Przejmij realizację jednej z funkcji. Dosłownie się krzywię, kiedy to piszę, ponieważ ten punkt niesie ze sobą wiele ukrytych niebezpieczeństw, ale naprawdę nie jestem pewien, czy uda ci się osiągnąć punkt 1 i punkt 2 bez zobowiązania się do wdrożenia przynajmniej jednej funkcji. Samodzielnie wdrażając jedną z funkcjonalności, nie tylko będziesz aktywnie zaangażowany w proces rozwoju, ale także pozwoli Ci okresowo przełączać się z roli „Menedżera odpowiedzialnego za wszystko” na rolę „Człowieka odpowiedzialnego za wdrożenie funkcji.” Ta pokorna i bezpretensjonalna postawa przypomni Ci o znaczeniu małych decyzji.
- Nadal cała się trzęsę. Mam wrażenie, że ktoś już na mnie krzyczy: „Menedżer, który wziął na siebie realizację funkcji?! (I zgadzam się z nim!) Tak, nadal jesteś menadżerem, co oznacza, że powinna to być jakaś mała funkcja, dobrze? Tak, masz jeszcze wiele do zrobienia. Jeśli po prostu nie możesz zająć się implementacją funkcji, to mam dla Ciebie dodatkową radę: napraw kilka błędów. W tym przypadku nie poczujesz radości tworzenia, ale będziesz miał zrozumienie, w jaki sposób powstaje produkt, co sprawi, że nigdy nie pozostaniesz bez pracy.
- Napisz testy jednostkowe. Nadal robię to na późnym etapie cyklu produkcyjnego, kiedy ludzie zaczynają wariować. Pomyśl o tym jak o liście kontrolnej stanu zdrowia Twojego produktu. Rób to często.
Znowu sprzeciw?
„Rands, jeśli napiszę kod, zdezorientuję mój zespół. Nie będą wiedzieć, kim jestem – menedżerem czy programistą”.
Dobrze.
Tak, powiedziałem: „OK!” Cieszę się, że myślisz, że możesz zmylić swój zespół po prostu pływając w stawie deweloperskim. To proste: granice pomiędzy różnymi rolami w tworzeniu oprogramowania są obecnie bardzo niewyraźne. Specjaliści od interfejsu użytkownika zajmują się czymś, co można ogólnie nazwać programowaniem JavaScript i CSS. Programiści dowiadują się coraz więcej o projektowaniu doświadczeń użytkownika. Ludzie komunikują się ze sobą i dowiadują się o błędach, kradzieży kodu innych osób, a także o tym, że nie ma dobrego powodu, aby menedżer nie brał udziału w tej masowej, globalnej, krzyżującej się bachanalii informacyjnej.
Poza tym chcesz być częścią zespołu składającego się z łatwo wymiennych podzespołów? To nie tylko sprawi, że Twój zespół będzie bardziej zwinny, ale da każdemu członkowi zespołu możliwość zobaczenia produktu i firmy z różnych perspektyw. Jak możesz zacząć szanować Franka, spokojnego faceta odpowiedzialnego za kompilacje, bardziej niż po zobaczeniu prostej elegancji jego skryptów kompilacji?
Nie chcę, aby Twój zespół był zdezorientowany i chaotyczny. Wręcz przeciwnie, chcę, aby Twój zespół komunikował się skuteczniej. Wierzę, że jeśli będziesz zaangażowany w tworzenie produktu i pracę nad funkcjonalnościami, będziesz bliżej swojego zespołu. A co najważniejsze, będziesz bliżej ciągłych zmian w procesie wytwarzania oprogramowania w Twojej organizacji.
Nie przestawaj się rozwijać
Kiedyś moja koleżanka z firmy Borland zaatakowała mnie werbalnie za nazwanie jej „programistką”.
„Rands, programista to bezmyślna maszyna! Małpa! Koder nie robi nic ważnego poza pisaniem nudnych linii bezużytecznego kodu. Nie jestem programistą, jestem programistą!”
Miała rację, nienawidziłaby mojej pierwszej rady skierowanej do nowych dyrektorów generalnych: „Przestań pisać kod!” Nie dlatego, że sugeruję, że są programistami, ale bardziej dlatego, że aktywnie sugeruję, aby zaczęli ignorować jedną z najważniejszych części swojej pracy: tworzenie oprogramowania.
Dlatego zaktualizowałem swoją radę. Jeśli chcesz być dobrym liderem, możesz przestać pisać kod, ale...
Bądź elastyczny. Pamiętaj, co to znaczy być inżynierem i nie przestawaj tworzyć oprogramowania.
O autorze
Michael Lopp to doświadczony programista, który wciąż nie opuścił Doliny Krzemowej. Na przestrzeni ostatnich 20 lat Michael pracował dla różnych innowacyjnych firm, m.in. Apple, Netscape, Symantec, Borland, Palantir, Pinterest, a także brał udział w startupie, który powoli odchodził w zapomnienie.
Poza pracą Michael prowadzi pod pseudonimem Rands popularny blog o technologii i zarządzaniu, na którym omawia z czytelnikami idee z zakresu zarządzania, wyraża zaniepokojenie ciągłą koniecznością trzymania ręki na pulsie i wyjaśnia, że pomimo hojne nagrody za stworzenie produktu, Twój sukces jest możliwy tylko dzięki Twojemu zespołowi. Bloga można znaleźć tutaj .
Michael mieszka z rodziną w Redwood w Kalifornii. Zawsze znajduje czas na jazdę na rowerze górskim, grę w hokeja i picie czerwonego wina, bo zdrowie jest ważniejsze niż bycie zajętym.
» Więcej szczegółów na temat książki można znaleźć na stronie
»
»
Dla Khabrozhiteley 20% zniżki przy użyciu kuponu - Zarządzanie ludźmi
Po opłaceniu papierowej wersji książki, elektroniczna wersja książki zostanie wysłana e-mailem.
PS: 7% ceny książki zostanie przeznaczone na tłumaczenie nowych książek komputerowych, spis książek przekazanych drukarni .
Źródło: www.habr.com