Праект-мэнэджарам (і тым, хто марыць стаць начальнікам) прысвячаецца.
Пісаць тоны кода складана, а кіраваць людзьмі - яшчэ складаней! Так што вам проста неабходна гэтая кніга, каб навучыцца рабіць і тое і іншае.
Ці можна аб'яднаць прышпільныя гісторыі і сур'ёзныя ўрокі? Майклу Лопу (таксама вядомаму ў вузкіх колах як Рэндс) гэта ўдалося. Вас чакаюць выдуманыя гісторыі аб выдуманых людзях, якія валодаюць неверагодна карысным (хоць і выдуманым) досведам. Менавіта так Рэндс дзеліцца сваім разнастайным, часам дзіўным досведам, атрыманым за гады працы ў буйных IT-карпарацыях: Apple, Pinterest, Palantir, Netscape, Symantec і інш.
Вы праект-менеджэр? Ці хочаце зразумець, чым жа ваш чортаў бос займаецца ўвесь дзень? Рэндс навучыць вас выжываць у Таксічным Міры надзьмуты Індык і квітнець сярод агульнага вар'яцтва дисфункционально-яркіх людзей. У гэтай дзіўнай супольнасці маніякальных разумнікаў ёсць яшчэ больш дзіўныя істоты - кіраванцы, якія праз містычны арганізацыйны рытуал атрымалі ўладу над планамі, думкамі і банкаўскімі рахункамі мноства людзей.
Гэтая кніга не падобная ні на адзін манускрыпт па менеджменце ці лідарству. Майкл Лоп нічога не хавае, ён проста распавядае ўсё як ёсць (магчыма, не ўсе гісторыі варта было б даводзіць да агульнага ведама: Р). Але толькі так вы зразумееце, як вам выжыць з такім босам, як кіраваць гікамі і нердамі і як ужо давесці да хэпі-энду «той гробаны праект»!
Урывак. Інжынерная ментальнасць
Разважанні на тэму: ці трэба вам працягваць пісаць код
У кнізе Рэндса аб правілах для кіраўнікоў ёсць вельмі кароткі пералік сучасных мэнэджарскіх "must-do". Лаканічнасць гэтага пераліку вынікае з таго факту, што паняцце "must" - гэта нейкі абсалют, а калі гаворка заходзіць аб людзях, то абсалютных паняццяў становіцца вельмі мала. Удалы метад кіраўніцтва адным супрацоўнікам стане сапраўднай катастрофай для іншага. Гэта думка і ёсць першы пункт мэнэджарскага "must-do" спісу:
Заставайся гнуткім!
Лічыць, што вы ўжо ўсё ведаеце, - вельмі дрэнная ідэя. У сітуацыі, калі адзіным нязменным фактам з'яўляецца той факт, што ў свеце адбываюцца пастаянныя змены, гнуткасць становіцца адзіна дакладнай пазіцыяй.
Парадаксальнай выявай другі пункт пераліку дзіўна нягнуткі. Аднак гэты пункт - мой асабісты фаварыт, таму як я лічу, што менавіта ён дапамагае стварыць падмурак для мэнэджарскага росту. Гэты пункт абвяшчае:
Спыні пісаць код!
Тэарэтычна, калі вы хочаце быць кіраўніком, вы павінны вучыцца давяраць тым, хто на вас працуе, і поўнасцю перадаць ім напісанне кода. Гэтая рада звычайна цяжка «пераварваецца», асабліва новасьпечанымі кіраўнікамі. Верагодна, адной з прычын, па якой яны сталі кіраўнікамі, з'яўляюцца іх прадукцыйнасць у справе распрацоўкі, і калі ўсё ідзе наперакасяк, іх першая рэакцыя - звярнуцца да навыкаў, у якіх яны цалкам упэўненыя, гэта значыць да свайго ўмення пісаць код.
Калі я бачу, што новы кіраўнік «апускаецца» да напісання кода, я кажу яму: «Мы ведаем, што ты ўмееш пісаць код. Пытанне ў іншым: ці ўмееш ты кіраваць? Ты больш не адказваеш за сябе аднаго, ты адказваеш за ўсю каманду цалкам; і я хачу быць упэўненым у тым, што ты зможаш зрабіць так, каб твая каманда вырашала праблемы самастойна, без таго, каб табе самому даводзілася пісаць код. Твая задача складаецца ў тым, каб высветліць, як маштабаваць самога сябе. Я хачу, каб ты не быў адным-адзіным, я хачу, каб такіх, як ты, было шмат».
Добрая рада, праўда? Маштаб. Мэнэджмент. Адказнасць. Такія ходкія модныя слоўцы. Шкада, што парада няслушная.
Няверны?
Ага. Савет няслушны! Не тое каб абсалютна няслушны, але дастаткова няслушны, каб мне прыйшлося патэлефанаваць некаторым былым калегам і папрасіць прабачэння: «Помніш тое маё любімае сцвярджэнне аб тым, што ты павінен спыніць пісаць код? Яно няслушнае! Так… Зноў пачынай праграмаваць. Пачні з Python і Ruby. Так, я сур'ёзна! Ад гэтага залежыць твая кар'ера!»
Калі я пачынаў кар'еру распрацоўніка ПЗ у Borland, я працаваў у камандзе Paradox для Windows, а гэта была велізарная каманда. Толькі адных распрацоўшчыкаў дадатку было 13 чалавек. Калі дадаць людзей з іншых каманд, якія таксама стала працавалі над ключавымі тэхналогіямі для гэтага праекту, такімі як асноўны рухавічок базы дадзеных і асноўныя сэрвісы прыкладання, то атрымлівалася 50 інжынераў, напроста занятых распрацоўкай гэтага прадукта.
Ні адна іншая каманда, у якой я калі-небудзь працаваў, нават не наблізілася да падобных памераў. Насамрэч, з кожным мінулым годам колькасць чалавек у камандзе, у якой я працую, паступова скарачаецца. Што ж адбываецца? Няўжо мы, распрацоўшчыкі, калектыўна становімся ўсё разумнейшыя і разумнейшыя? Не, мы проста размяркоўваем нагрузку.
Чым распрацоўшчыкі займаліся апошнія 20 гадоў? За гэты час мы напісалі фігаву хмару кода. Мора кода! Мы напісалі так шмат кода, што вырашылі: нядрэнна б усё спрасціць і перайсці на адчынены зыходны код.
На шчасце, дзякуючы інтэрнэту гэты працэс зараз стаў максімальна простым. Калі вы распрацоўшчык ПЗ, то можаце праверыць гэта прама зараз! Пашукайце сваё імя ў Google або ў Github, і вы ўбачыце код, пра які вы даўно забыліся, але які можа знайсці кожны, хто пажадае. Страшна, так? Вы не ведалі, што код жыве вечна? Так, ён жыве вечна.
Код жыве вечна. А добры код не толькі жыве вечна, ён расце, таму што тыя, хто яго шануюць, увесь час клапоцяцца аб тым, каб ён не губляў сваёй свежасці. Гэтая куча высакаякаснага і які змяшчаецца ў добрым стане кода дапамагае скараціць сярэдні памер інжынірынгавай каманды, таму што дазваляе нам факусавацца не на напісанні новага кода, а на ўжо існым кодзе і выконваць працу з меншай колькасцю прыцягнутых людзей і за карацейшыя тэрміны.
Гэты ланцужок разваг гучыць гнятліва, аднак ідэя складаецца ў тым, што ўсе мы - гэта толькі купка інтэграцыйных аўтаматаў, выкарыстоўвалых клейкую стужку для таго, каб злучаць паміж сабой розныя часцінкі ўжо існых рэчаў для стварэння трохі іншай версіі таго ж самага. Гэта класічны ход думак вышэйшага кіраўніцтва, які любіць аўтсорсінг. «Гэта можа зрабіць любы, хто ўмее карыстацца Google і ў каго ёсць клейкая стужка! Тады навошта мы плацім кучу грошай нашым аўтаматам?
Мы плацім гэтым тыпам з кіраўніцтва рэальна вялікія грошы, а яны думаюць такую лухту. Яшчэ раз: мая ключавая ідэя складаецца ў тым, што на нашай планеце мноства геніяльных і вельмі руплівых распрацоўнікаў; яны сапраўды геніяльныя і старанныя, хоць і не патрацілі ніводнай хвіліны на сядзенне ў акрэдытаваных універсітэтах. О так, зараз такіх становіцца ўсё больш і больш!
Я не прапаную вам пачаць турбавацца за сваё месца толькі таму, што нейкія геніяльныя таварышы нібы на яго палююць. Я прапаную вам пачаць турбавацца за яго, таму што эвалюцыя распрацоўкі ПЗ, магчыма, рухаецца хутчэй, чым вы. Вы працуеце ўжо дзесяць гадоў, з іх пяць гадоў як кіраўнік, і думаеце: "Ужо я-то ведаю, як распрацоўваецца софт". Так, вы ведаеце. Пакуль...
Спыніце пісаць код, але...
Калі вы будзеце прытрымлівацца маёй першапачатковай радзе і перастанеце пісаць код, то адначасова вы па ўласным жаданні перастанеце ўдзельнічаць падчас стварэнняў. Менавіта з гэтай прычыны я не асабліва актыўна выкарыстоўваю аўтсорсінг. Аўтаматы не ствараюць, яны вырабляюць. Добра распрацаваныя працэсы дазваляюць эканоміць шмат грошай, аднак яны не прыўнясуць у наш свет нічога новага.
Калі ў вас невялікая каманда і яна робіць шмат за невялікія грошы, то ідэя спыніць пісаць код падаецца мне дрэнным кар'ерным рашэннем. Нават у кампаніях-монстрах з іх бясконцымі рэгламентамі, працэсамі і палітыкай вы не маеце права забыцца, як самастойна распрацоўваць софт. А распрацоўка софту бесперапынна мяняецца. Яна мяняецца прама цяпер. У вас пад нагамі! У гэтую самую секунду!
У вас ёсць пярэчанні. Разумею. Давайце паслухаем.
«Рэндс, я па дарозе ў дырэктарскае крэсла! Калі я працягну пісаць код, ніхто не паверыць, што я здольны расці».
Я хачу спытаць вас вось пра што: з тых часоў, як вы селі ў сваё крэсла "Я хутка стану дырэктарам!", Ці заўважалі вы, што сфера распрацоўкі софту мяняецца нават у межах вашай кампаніі? Калі ваш адказ "так", то я задам вам іншае пытанне: як менавіта яна мяняецца і што вы збіраецеся зрабіць у сувязі з гэтымі зменамі? Калі на маё першае пытанне вы адказалі "не", то вам трэба перасесці ў іншае крэсла, таму што (зуб даю!) сфера распрацоўкі софту змяняецца ў гэтую самую секунду. Як вы наогул збіраецеся расці, калі вы павольна, але дакладна забываеце, як распрацоўваць софт?
Мая рада складаецца не ў тым, каб даручыць сабе рэалізацыю тон функцый для вашага наступнага прадукта. Трэба ўвесь час прымаць меры, каб заставацца ў курсе таго, як ваша каманда стварае софт. Вы цалкам можаце рабіць гэта і будучы дырэктарам, і будучы віцэ-прэзідэнтам. Нешта яшчэ?
«Уф, Рэндс! Але ж нехта павінен быць арбітрам! Нехта павінен бачыць агульную карціну. Калі я буду пісаць код, то я страчу з-пад увагі далягляд».
Вы па-ранейшаму павінны заставацца арбітрам, вы па-ранейшаму павінны трансляваць рашэнні, і вы па-ранейшаму кожную раніцу панядзелка павінны чатыры разы абыходзіць увесь будынак разам з адным са сваіх інжынераў, каб на працягу 30 хвілін слухаць яго штотыднёвую тыраду «Мы ўсе асуджаныя !». Але апроч усяго гэтага, вы павінны захоўваць у сабе інжынерная выява мыслення, а для гэтага вам не абавязкова быць праграмістам на поўную стаўку.
Мае парады па захаванні інжынернай ментальнасці:
- Выкарыстоўвайце асяроддзе распрацоўкі. Гэта значыць, што вы павінны быць знаёмыя з інструментаром сваёй каманды, уключаючы сістэму зборкі кода, кантроль версіі і мову праграмавання. У выніку гэтага вы будзеце валодаць мовай, якой ваша каманда карыстаецца, калі кажа аб распрацоўцы прадукта. Гэта таксама дазволіць вам працягваць выкарыстоўваць ваш любімы тэкставы рэдактар, які выдатна функцыянуе.
- Вы павінны ўмець намаляваць падрабязную архітэктурную схему, якая апісвае ваш прадукт, на любой паверхні і ў любы час. Цяпер я не маю на ўвазе спрошчаны варыянт з трыма ячэйкамі і двума стрэлачкамі. Вы павінны ведаць дэталёвую схему прадукта. Самую складаную. Не проста якую-небудзь сімпотную схему, а схему, якую цяжка растлумачыць. Гэта павінна быць карта, прыдатная для поўнага разумення прадукта. Яна ўвесь час змяняецца, і вы заўсёды павінны ведаць, чаму адбыліся тыя ці іншыя змены.
- Вазьміце на сябе рэалізацыю адной з функцый. Я літаральна ўздрыгваю, калі пішу гэта, таму што гэты пункт тоіць у сабе шмат утоеных небяспек, але я сапраўды не ўпэўнены ў тым, што вы зможаце выканаць пункт № 1 і пункт № 2 без таго, каб узяць на сябе рэалізацыю хаця б адной функцыі . Дзякуючы самастойнай рэалізацыі адной з функцый вы не толькі будзеце актыўна ўдзельнічаць у працэсе распрацоўкі, гэта таксама дазволіць вам перыядычна пераключацца з ролі "Кіраўніка, які адказвае за ўсё" на ролю "Чалавека, які адказвае за рэалізацыю адной з функцый". Гэтая сціплая і непатрабавальная пазіцыя будзе нагадваць вам аб важнасці маленькіх рашэнняў.
- Я ўсё яшчэ ўвесь дрыжу. Здаецца, нехта ўжо гарлапаніць на мяне: «Кіраўнік, які ўзяў на сябе рэалізацыю функцыі?! (І я з ім згодзен!) Так, вы па-ранейшаму застаецеся кіраўніком, а значыць, гэта павінна быць якая-небудзь невялікая функцыя, добра? Так, у вас па-ранейшаму шмат спраў. Калі вы ніяк не можаце ўзяць на сябе рэалізацыю функцыі, то ў мяне для вас запасная рада: займайцеся ўхіленнем некаторых багаў. У гэтым выпадку вы не будзеце адчуваць радасці стварэння, але ў вас будзе разуменне таго, як ствараецца прадукт, а значыць, вы ніколі не застанецеся не ў спраў.
- Пішыце модульныя тэсты. Я ўсё яшчэ раблю гэта на позніх этапах вытворчага цыклу, калі людзі пачынаюць вар'яцець. Разглядайце гэта як чэк-ліст працаздольнасці вашага прадукта. Рабіце гэта часта.
Зноў пярэчанне?
«Рэндс, калі я буду пісаць код, то я буду збіваць з панталыку сваю каманду. Яны не будуць ведаць, хто я - кіраўнік або распрацоўшчык ».
Добра.
Так, я сказаў: "Добра!" Я рады, што вы лічыць, што зможаце збіць з панталыку сваю каманду толькі тым, што плаваеце ў сажалцы распрацоўшчыкаў. Тут усё проста: межы паміж рознымі ролямі ў сферы распрацоўкі софту ў сапраўдны момант моцна размытыя. Хлопцы, якія займаюцца карыстацкім інтэрфейсам, робяць тое, што можна ў цэлым назваць праграмаваннем на JavaScript і CSS. Распрацоўнікі ўсё больш і больш даведаюцца аб праектаванні ўзаемадзеяння з карыстальнікам. Людзі маюць зносіны адзін з адным і даведваюцца аб памылках, аб крадзяжы чужога кода, а таксама аб тым, што не існуе ніякай уважлівай прычыны для таго, каб кіраўнік не мог удзельнічаць у гэтай масіўнай, глабальнай, крыжавана апыляльнай інфармацыйнай вакханаліі.
Акрамя таго, вы ж хочаце быць часткай каманды, якая складаецца з лёгказаменных складовых элементаў? Гэта не проста зробіць вашу каманду больш спрытнай, гэта дасць кожнаму яе сябру магчымасць бачыць прадукт і кампанію з самых розных пунктаў гледжання. Як вы зможаце яшчэ мацней запаважаць Фрэнка, таго спакойнага хлопца, адказнага за кампаноўку, калі не пасля таго, як убачыце простую элегантнасць яго зборачных скрыптоў?
Я не хачу, каб у вашай камандзе панавалі блытаніна і хаос. Наадварот, я хачу, каб камунікацыя ў вашай камандзе стала больш эфэктыўнай. Я ўпэўнены ў тым, што калі вы самі ўдзельнічаеце ў стварэнні прадукта і працуеце над функцыямі, вы будзеце бліжэй да сваёй каманды. І што яшчэ важнейшае — вы будзеце бліжэй да сталых змен у працэсе распрацоўкі софту ў межах вашай арганізацыі.
Не пераставайце распрацоўваць
Адна мая калега з Borland аднойчы вербальна атакавала мяне за тое, што я назваў яе "кодэрам".
«Рэндс, кодэр - гэта бязмозглая машына! Малпа! Кодэр не робіць нічога важнага, акрамя напісання сумных радкоў бескарыснага кода. Я не кодэр, я распрацоўшчык софту!»
Яна мела рацыю, яна б зненавідзела маю першапачатковую раду новаспечаным кіраўнікам: «Перастаньце пісаць код!» Не таму, што тым самым я як бы мяркую, што яны - кодэры, а больш таму, што я проактивным чынам прапаную ім пачаць ігнараваць адну з найважнейшых частак іх працы - распрацоўку ПЗ.
Такім чынам, я дапрацаваў сваю параду. Калі вы жадаеце быць добрым кіраўніком, тыя вы можаце перастаць пісаць код, але…
Будзьце гнуткімі. Памятайце, што значыць быць інжынерам, і не пераставайце распрацоўваць софт.
Пра аўтара
Майкл Лоп - ветэран у галіне распрацоўкі праграмнага забеспячэння, які ўсё яшчэ не пакінуў Крамянёвай даліну. За апошнія 20 гадоў Майкл паспеў папрацаваць у самых розных інавацыйных кампаніях, уключаючы Apple, Netscape, Symantec, Borland, Palantir, Pinterest, а таксама паўдзельнічаць у стартапе, які павольна сплыў у нябыт.
Апроч працы Майкл вядзе папулярны блог аб тэхналогіях і менеджменце пад псеўданімам Рэндс, дзе абмяркоўвае з чытачамі ідэі ў сферы менеджменту, выказвае турботу з нагоды сталай неабходнасці трымаць руку на пульсе і тлумачыць, што, нягледзячы на шчодрыя ўзнагароды за ствараны прадукт, ваш поспех магчымы толькі дзякуючы вашай камандзе. Блог можна знайсці па спасылцы .
Майкл жыве са сваёй сям'ёй у горадзе Рэдвуд, штат Каліфорнія. Ён заўсёды знаходзіць час на тое, каб пакатацца на горным ровары, пагуляць у хакей і выпіць чырвонага віна, бо быць здаровым важней, чым занятым.
» Больш падрабязна з кнігай можна азнаёміцца на
»
»
Для Хаброжыцеляў зніжка 20% па купоне Managing Humans
Па факце аплаты папяровай версіі кнігі на e-mail дасылаецца электронная версія кнігі.
PS: 7% ад кошту кнігі пайдзе на пераклад новых кампутарных кніг, спіс здадзеных у друкарню кніг .
Крыніца: habr.com