Проект-менеджерам (и тем, кто мечтает стать начальником) посвящается.
Писать тонны кода сложно, а управлять людьми — еще сложнее! Так что вам просто необходима эта книга, чтобы научиться делать и то и другое.
Можно ли объединить прикольные истории и серьезные уроки? Майклу Лоппу (также известному в узких кругах как Рэндс) это удалось. Вас ждут выдуманные истории о выдуманных людях, обладающих невероятно полезным (хотя и выдуманным) опытом. Именно так Рэндс делится своим разнообразным, порой странным опытом, полученным за годы работы в крупных 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 высылается электронная версия книги.
P.S.: 7% от стоимости книги пойдет на перевод новых компьютерных книг, список сданных в типографию книг .
Источник: habr.com