Kitobni o'qish: «Карьера разработчика. Стафф – круче, чем senior»

Права на издание получены по соглашению с O'Reilly. Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.

Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги. Издательство не несет ответственности за доступность материалов, ссылки на которые вы можете найти в этой книге. На момент подготовки книги к изданию все ссылки на интернет-ресурсы были действующими. В книге возможны упоминания организаций, деятельность которых запрещена на территории Российской Федерации, таких как Meta Platforms Inc., Facebook, Instagram и др.

Authorized Russian translation of the English edition of The Staff Engineer's Path

© 2022 Tanya Reilly.

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.

© Перевод на русский язык ТОО «Спринт Бук», 2025

© Издание на русском языке, оформление ТОО «Спринт Бук», 2025

⁂

Отзывы о книге «Карьера разработчика. Стафф – круче, чем senior»

Жаль, что у меня не было этой книги, когда я перешла на должность принципал-разработчика. Таня подробно описала путь разработчика уровня стафф+ и дала множество содержательных практических советов. Если вам интересно, кто такой стафф+ разработчик и как добиться успеха в этой роли в вашей организации, то эта книга для вас. Она даст инструменты, которые помогут вам преуспеть на инженерном пути развития, оказывая влияние на людей и процессы и принося пользу.

Сара Уэлс, независимый консультант и автор книг, бывший принципал-разработчик Financial Times

Мне не хватало этой книги на протяжении всей карьеры. Таня изложила на бумаге многогранность роли стафф-разработчика и дала замечательные конкретные указания по управлению временем, поиску консенсуса и т. д., и это чрезвычайно ценно.

Я буду часто цитировать эту книгу.

Титус Винтерс, принципал-разработчик Google и соавтор книги «Software Engineering at Google»¹

Таня – идеальный автор для этого исключительного мануала, который поможет сориентироваться в непонятной роли стафф+ разработчика. В каждой главе она делится своим огромным практическим опытом, я многому у нее научился.

Уилл Ларсон, технический директор, Calm, автор книги «Staff Engineer»

Должность старшего руководителя в карьере индивидуального контрибьютора долго была неоднозначной и не поддавалась определению. Эта книга представляет собой незаменимое руководство, которое поможет добиться успеха в роли, являющейся пока что достаточно новой для нашей отрасли. Таня проделала отличную работу: она рассказала об опыте крупных компаний и дала оценку вызовам, с которыми они сталкиваются, предлагая всесторонний взгляд на то, как стать успешным стафф-разработчиком.

Сильвия Ботрос, принципал-разработчик и соавтор 4-го издания книги «High Performance MySQL»²

Когда вы почти достигли вершины карьеры индивидуального контрибьютора, вы, образно говоря, получаете компас и некоторый пункт назначения. Как туда добраться – ваша проблема. Как привести туда всех остальных – общая. Таня предлагает надежные инструкции с картами, которые помогут вам провести людей из пункта А в пункт Б. Эта книга станет прочной опорой для тех индивидуальных контрибьюторов, кто только начинает свой путь на старших уровнях, и откроет много нового для тех, кто уже имеет большой опыт. Стафф-разработчики, познайте себя.

Изар Тарандач, принципал-архитектор по безопасности и соавтор книги «Threat Modeling»

Таня Рейли с пугающей точностью передает то ошеломляющее чувство, которое я испытал, когда впервые стал тем, «кто должен что-то сделать». Эта книга – подробное исследование того, что на самом деле означает эта фраза для людей, работающих на уровне стафф-разработчика.

Ниалл Ричард Мерфи, учредитель, генеральный директор, соавтор книг «Reliable Machine Learning» и «Site Reliability Engineering»³

В книге «Карьера разработчика. Стафф – круче, чем senior» Таня Рейли привнесла крайне необходимую ясность в непростой и часто неверно понимаемый вопрос о том, как быть старшим техническим лидером, не имея прямых подчиненных. Каждая страница наполнена ценными идеями и практическими советами, которые помогут вам сориентироваться в новой роли и в организации, а также проложить свой карьерный путь, причем все тонкие наблюдения преподносятся в фирменном стиле Тани, остроумном и непринужденном. Эта книга – шедевр.

Кэти Сайлор-Миллер, старший стафф-архитектор по фронтенду, Etsy

Если вы как старший инженер раздумываете о том, какую карьеру дальше выбрать – стафф-разработчика или руководителя стафф-разработчиков, – эта книга для вас. Она раскрывает множество особенностей этой роли, о которых вам никто не расскажет и на самостоятельное изучение которых уйдут многие годы, даже если вас будут сопровождать самые прекрасные менторы. Книга предлагает наблюдения, ментальные модели и знания о роли стафф-разработчика из первых рук в более сжатом виде, чем любая другая книга до этого.

Гергели Орош, автор книги «The Pragmatic Engineer»

О научном редакторе русского издания

Евгений Войнов – стафф-разработчик в компании КРОК, 6 лет руководил группой Java-разработчиков, 3 года был техническим менеджером. Имеет более 15 лет опыта разработки систем для государственного и коммерческого сектора, регулярно участвует в трансформации процессов департамента. Ментор разработчиков и будущих руководителей, преподаватель в учебных программах BrainZ by CROC для студентов и школьников.

От издательства

Мы выражаем огромную благодарность компании КРОК за помощь в работе над русскоязычным изданием книги и их вклад в повышение качества переводной литературы.

Ваши замечания, предложения, вопросы отправляйте по адресу

comp@sprintbook.kz

(издательство «SprintBook», компьютерная редакция).

Мы будем рады узнать ваше мнение!

Предисловие

Когда в 2016 году я писала книгу «The Manager’s Path»⁴, передо мной стояло много задач. Я хотела поделиться уроками, которые получила, развиваясь как менеджер. Я хотела показать тем, кто стремится стать менеджером, на что похожа эта работа. Я хотела, чтобы отрасль признала, что мы должны предъявлять больше требований к менеджерам и что менеджеры, которых мы сейчас продвигаем, часто не могут качественно выполнять свою работу, потому что они не умеют правильно распределить свое внимание между потребностями подчиненных, контролем за техническими процессами, продуктом и развитием собственных инженерных навыков. Если кратко, то я хотела изменить традиции, сложившиеся в технической отрасли: во-первых, менеджмент должен восприниматься серьезно, так как играет критически важную роль, во-вторых, менеджмент не должен считаться возможностью по умолчанию для амбициозных разработчиков, которые хотят сделать карьеру.

Хочу сказать, что частично я добилась успеха. Каждый раз, когда кто-то говорит мне, что он прочитал мою книгу и решил не становиться менеджером, я праздную свою маленькую победу. Ведь хотя бы некоторые люди, ознакомившись с моей книгой, осознали, что эта работа им не подходит. К несчастью, для альтернативного варианта карьерного роста индивидуального контрибьютора, пути стафф-разработчика, нет аналогичного пособия. Это привело к тому, что многие все равно идут в управленцы, даже если не хотят нести ответственность за все бо́льшие и большие группы людей: они просто не видят другой возможности развиваться. Это огромное разочарование как для разработчиков, так и для менеджеров: большинству менеджеров нужны сильные разработчики уровня стафф+, но они не знают, как повысить их статус в компании, а многие разработчики хотят продолжать заниматься программированием, но не видят реальных возможностей продвижения по служебной лестнице, кроме перехода в менеджмент.

На пути к уровню стафф+ возникает одна большая трудность: от разработчиков ожидают, что они самостоятельно и без специальных указаний разберутся, как до него добраться. Если вы стремитесь стать стафф+ разработчиком, то, по общепринятому мнению, вы должны сами выяснить, как это сделать. Стоит ли говорить, что это обескураживающий подход, который не способствует профессиональному росту. По мере того как все больше компаний осознает потребность в разработчиках уровня стафф+, мы как отрасль не можем позволить себе полагаться на верования и предубеждения о карьере таких специалистов и игнорировать основные навыки, которые ведут технических лидеров к успеху.

Учитывая все вышесказанное, представьте, как я обрадовалась, когда Таня Рейли (Tanya Reilly) захотела написать о пути стафф-разработчика, то есть раскрыть тему, которую моя книга оставила без внимания. Я знаю Таню по ее статьям и выступлениям об инженерном лидерстве, и для меня было очевидно, что она хочет избавиться от сложившихся стереотипов в технической отрасли относительно стафф+ разработки, так же как я хотела изменить устоявшиеся традиции в менеджменте. В частности, Таня предпринимает попытку разобраться, насколько важны для профессионального успеха технического специалиста способности к программированию и решению технических задач, а также выяснить, какие умения позволят сильным разработчикам успешно повышать эффективность компании, не управляя при этом людьми.

В этой книге Таня описывает три основополагающих навыка, которые критически важны для успеха стафф+ разработчика. Она объясняет, как применять панорамное мышление, успешно реализовывать проекты и повышать квалификацию других сотрудников, тем самым распространяя свое влияние за пределы индивидуального практического вклада.

Раскрывая многогранную структуру карьеры стафф+ разработчика, Таня не пытается дать конкретный набор умений, необходимых на каждом уровне выше сеньора. Она поступает мудрее и сосредоточивает внимание на том, как использовать эти три основных навыка в тех или иных условиях. Эта книга проведет вас через все этапы стафф-разработки от создания технической стратегии до успешного руководства большими проектами, от ментора до идейного вдохновителя на уровне организации и покажет, что можно способствовать успеху компании, выходя за рамки написания кода.

Ваш карьерный рост в руках только одного человека, и этот человек – вы. Определение своего профессионального пути является не только великолепным шансом, но и серьезным испытанием, и чем раньше вы поймете, что все зависит от вас (и небольшой толики удачи), тем быстрее вы научитесь разбираться в возможностях продвижения по карьерной лестнице. Данное руководство разъясняет, какие навыки нужны, чтобы пройти путем стафф+ разработчика, и является необходимым дополнением к библиотеке каждого программиста.

Камиль Фурнье, автор книги «The Manager’s Path», редактор книги «97 Things Every Engineering Manager Should Know», управляющий директор, член правления JP Morgan Chase ACM Queue, Нью-Йорк, сентябрь 2022 г.

Введение

Кем вы видите себя через пять лет? Этот стандартный вопрос на собеседовании – то же самое, что вопрос «Кем ты хочешь стать, когда вырастешь?», только для взрослых. У него достаточно далекий горизонт планирования и несколько социально приемлемых ответов, которые не предполагают принятия на себя каких-либо обязательств.⁵ Но если вы сеньор-разработчик программного обеспечения и хотите продолжать продвигаться по карьерной лестнице, то этот вопрос становится очень серьезным.⁶ Как вы думаете, куда вы идете?

Два пути

Представьте, что вы стоите на развилке дороги (рис. В.1) и перед вами простираются два пути. Если вы пойдете по первому, то возьмете себе подчиненных и станете менеджером. Если по второму – станете техническим лидером без подчиненных, таких специалистов часто называют стафф-разработчиками (staff engineer). Если бы вы правда могли увидеть себя через пять лет, то обнаружили бы, что у этих двух вариантов много общего: они ведут почти в одну и ту же сторону, и чем дальше вы идете, тем больше одинаковых навыков они требуют. Но в начале эти пути кажутся очень разными.

Рис. В.1. Развилка дороги

Путь менеджера понятен и хорошо известен. Переход в менеджмент – это самый распространенный и, наверное, даже стандартный карьерный шаг для тех, кто умеет хорошо коммуницировать, оставаться спокойным в критической ситуации и помогать коллегам улучшать их навыки. Скорее всего, вы знаете людей, которые выбрали этот вариант. Вероятно, у вас тоже был начальник, и у вас сложилось мнение о том, что он делал правильно и в чем ошибался. Менеджмент – это хорошо изученная дисциплина. Слова «повышение» и «лидерство» часто ассоциируются с фразой «стать чьим-то начальником», а киоски в аэропортах заполнены книгами с рекомендациями о том, как стать хорошим управленцем. Менеджмент – не самая простая дорога, но вы хотя бы сможете разобраться, как выглядит это путешествие.

Путь стафф-разработчика покрыт туманом. Сейчас многие компании позволяют специалистам расти как сеньор-разработчикам, без подчиненных, но этот «инженерный путь» до сих пор не проторен и на нем почти нет никаких дорожных знаков. Программисты, которые его выбрали, могли никогда не работать рядом со стафф-разработчиками, или эта должность встречалась им так редко, что стала похожа на миф. (Хотя это не так. Стафф-разработке тоже можно научиться.) У каждой компании свои ожидания от этой роли, а критерии для принятия на работу или повышения стафф-разработчиков расплывчаты и не всегда выполнимы.

Зачастую обязанности не становятся понятнее, даже если вас уже приняли на эту должность. Я разговаривала со стафф-разработчиками из разных компаний, которые не до конца понимали, чего от них хотят, а также с техническими менеджерами, которые не знали, как взаимодействовать со стафф-разработчиками.⁷ Вся эта неопределенность может стать источником стресса. Если круг ваших обязанностей четко не очерчен, то как узнать, хорошо или плохо вы работаете? И работаете ли вообще?

Даже если требования к вам понятны, то может быть неясно, как им соответствовать. Представьте, что вы только что устроились стафф-разработчиком и слышите, что от вас ожидают инженерного лидерства, принятия решений, выгодных бизнесу, влияния без авторитарности, – но как это сделать? С чего начать?

Основополагающие навыки для стафф-разработки

Мне знакомо это чувство. Я шла к уровню стафф целых 20 лет, которые проработала в отрасли, а теперь я старший принципал-разработчик (senior principal engineer) и одновременно старший директор (senior director) согласно штатному расписанию моей компании. Несмотря на то что я много раз думала перейти на менеджерскую должность, я все время приходила к выводу, что именно «инженерный путь» вдохновляет меня и ради него я каждое утро прихожу на работу. Я хочу, чтобы у меня было время изучать новые технологии и глубже вникать в архитектуру ПО. Вы становитесь лучше в том, на что тратите время, а я хотела стабильно развиваться как технический специалист.⁸

Однако на ранних этапах карьеры мне было трудно разобраться в специфике этой должности. Когда я была «мидлом», я не понимала, зачем нужны уровни выше «сеньора»: что эти люди делают целый день? У меня было недостаточно профессионального опыта, чтобы постичь значимость этой роли. Позже, когда я сама стала стафф-разработчиком, я обнаружила, что нигде не говорится ни о требованиях к нам, ни о навыках, которыми мы должны обладать. Я не могла все это сформулировать, не говоря уже о том, что я не знала, как действовать. Много лет я училась и получала опыт на разных проектах, как успешных, так и неудачных; как у своих замечательных коллег, так и у подчиненных из других компаний. Теперь роль стафф-разработчика обрела смысл, но я бы хотела узнать то, что знаю сейчас, намного раньше.

Если вы раздумываете о карьере стафф-разработчика или уже выбрали ее, добро пожаловать! Эта книга для вас. Если вы работаете со стафф-разработчиками или руководите ими и хотите побольше узнать о специфике их деятельности, для вас здесь тоже найдется много полезного. В следующих девяти главах я хочу поделиться своими знаниями о том, как стать хорошим стафф-разработчиком. Сразу предупреждаю, что я не дам инструкций по каждой теме: круг обязанностей на этой должности обширный и разнообразный, и на многие вопросы можно ответить: «Все зависит от обстоятельств». Но я покажу вам, как ориентироваться в этом разнообразии, выделять главное и не терять связь с другими коллегами-руководителями.

Роль стафф-разработчика включает три основополагающих навыка: панорамного мышления, реализации проектов и повышения квалификации сотрудников, с которыми он работает.

Панорамное мышление

Панорамное мышление – это способность отступить на шаг назад и посмотреть на картину в целом. Это означает учитывать не только текущие события, но и обстоятельства, в которых вы работаете. Это способность мыслить на более долгую перспективу: начинать проекты длиной в несколько лет, создавать ПО, которое будет легко вывести из эксплуатации, или прогнозировать, что понадобится вашей компании через три года.⁹

Реализация проектов

Проекты, с которыми вы столкнетесь на уровне стафф-разработчика, не будут иметь четкого плана и однозначно интерпретируемого результата. Чтобы успешно их реализовать, вам потребуется больше людей, влияния и личного авторитета, а также придется побороться с устоявшимися стереотипами.

Повышение квалификации сотрудников

Чем выше ваша должность, тем больше ответственность за стандарты и квалификацию разработчиков из вашей организации: это может быть ваша команда, коллеги или программисты всей компании или отрасли. В ваши обязанности входит как явное повышение квалификации сотрудников через обучение и наставничество, так и неявное, поскольку младшие специалисты обычно берут пример с более опытных профессионалов.

Ваше содействие успеху организации основано на этих трех навыках, как показано на рис. В.2.

Рис. В.2. Три навыка для роли стафф-разработчика

Обратите внимание, что эти навыки опираются на прочный фундамент технических знаний и опыта. Этот фундамент имеет решающее значение. Чтобы воссоздать панорамную картину, нужно уметь просчитать все возможные варианты и обладать здравым суждением. Во время реализации проектов вы должны принимать решения, которые действительно устраняют проблему. Если вы выступаете в качестве примера для подражания, то ваши комментарии на ревью должны улучшать код и архитектуру, а ваше мнение должно быть хорошо продуманным – вы должны быть правы! Техническое мастерство лежит в основе роли стафф-разработчика, и вы должны продолжать его совершенствовать.

Но одних инженерных способностей недостаточно. Для успеха и роста на уровне стафф+ вам понадобится нечто большее. Чтобы научиться мыслить панорамно, реализовывать крупные проекты и обучать коллег, вам понадобятся следующие «человеческие» навыки:

• коммуникабельность и лидерство;

• преодоление трудностей;

• умение видеть перспективы и результаты своей работы;

• менторство, спонсорство и делегирование;

• умение сформулировать задачу так, чтобы ее могли выполнить специалисты уровнем ниже;

• умение действовать как лидер, независимо от того, чувствуете вы себя таковым или нет.¹⁰

Эти навыки похожи на дополнительные опоры, которые можно увидеть в готических соборах (как на рис. В.3): они не заменяют стены – вашу инженерную квалификацию, – но помогают построить более высокое, величественное и впечатляющее здание.

Рис. В.3. Лидерские качества похожи на дополнительные опоры, которые помогают стабилизировать массивные постройки

У каждого из трех основополагающих навыков есть набор обязательных умений, и ваши способности в каждом из них могут быть очень разными. Кто-то находится в своей стихии, когда возглавляет и доводит до конца крупные проекты, но ему страшно выбрать одну стратегию из двух. Другие могут тонко чувствовать, куда движется компания и отрасль в целом, но быстро теряют контроль над ситуацией, разбираясь с инцидентом. Третьи умеют повышать квалификацию всех, с кем они работают, но им трудно достичь консенсуса по техническому вопросу. Хорошая новость в том, что все эти умения можно развить, и вы можете стать мастером всех трех основных навыков.

Эта книга разделена на три части.

Часть I. Панорамное мышление

В первой части мы разберем, как получить широкий панорамный вид на свою работу. Глава 1 начнется с глобальных вопросов о вашей роли. Чего от вас ожидают? Зачем нужны стафф-разработчики? В главе 2 мы еще уменьшим масштаб и получим некоторую перспективу. Мы посмотрим на контекст вашей работы, сориентируемся в организации и выясним, каковы ваши цели. Наконец, в главе 3 мы рассмотрим, как дополнить панорамную картину с помощью технической концепции и стратегии.

Часть II. Реализация проектов

Вторая часть – тактическая, она переходит к практическим советам по управлению проектами и устранению проблем. В главе 4 мы рассмотрим, как выбрать задачи, над которыми стоит работать: я поделюсь техниками, которые помогут определить, на что потратить время, как управлять своей жизненной энергией и «инвестировать» оказываемое вам доверие и накопленный вами социальный капитал так, чтобы не растерять их. В главе 5 я расскажу, как управлять проектами, затрагивающими несколько команд или организаций: как создать условия для успеха, принимать решения и поддерживать эффективную передачу информации. В главе 6 мы рассмотрим, как справиться с трудностями на вашем пути, отпраздновать успешное завершение проекта или провести ретроспективу (и при этом праздновать!), если проект отменился и необходимо завершить его без негативных последствий.

Часть III. Повышение квалификации

В третьей части мы рассмотрим, как поднять уровень квалификации в вашей организации. Из главы 7 вы узнаете, как развивать навыки каждого сотрудника, подавая личный пример хорошей разработки, как учиться, не скрывая этого, и как создать психологически благоприятную корпоративную культуру. Мы также рассмотрим, как сохранять выдержку и не терять контроль над ситуацией во время инцидентов и технических разногласий. В главе 8 я расскажу о более осознанных формах развития навыков ваших коллег, таких как обучение, коучинг, ревью архитектуры и кода, внесение изменений в культуру разработки. Наконец, в главе 9 мы рассмотрим, как повысить свой собственный уровень: как обеспечить себе профессиональный рост и позаботиться о своей карьере. Куда вы пойдете после этой должности? Я покажу вам несколько вариантов.

Прежде чем мы отправимся дальше, я хочу предупредить: эта книга о том, как остаться на инженерном пути. Но это не учебник для инженеров. Как я уже сказала, чтобы стать стафф-разработчиком, вам нужен крепкий технический фундамент. Эта книга не поможет его создать. Техническое мастерство зависит от предметной области, и если вы здесь, то я предполагаю, что у вас уже есть – или вы собираетесь приобрести – все специальные навыки, которые необходимы, чтобы стать одним из самых старших разработчиков в сфере ваших профессиональных интересов. Что бы вы ни понимали под словом «технический»: программирование, разработку архитектуры, UX-дизайн, моделирование данных, анализ уязвимостей или что-то другое, – почти в каждой предметной области есть множество книг, веб-сайтов и курсов, которые вас поддержат.

Если вы думаете, что для стафф-разработчика важны только инженерные навыки, то скорее всего, в этой книге вы не найдете ничего полезного. Но как ни странно, вы также можете стать тем, кто возьмет из нее максимум. Невважно, насколько глубоки и сокровенны ваши технические знания, работа станет меньше вас раздражать, если вы научитесь убеждать других людей в своей правоте, повысите уровень окружающих вас разработчиков и разберетесь с организационными трудностями, которые тормозят все процессы. Эти навыки не просто освоить, но я гарантирую, что это возможно, и в этой книге я постараюсь показать, как это сделать.

Вы точно хотите стать стафф-разработчиком? Вам могут не нравиться старшие технические роли, и это нормально. Также нормально перейти на путь менеджера (или периодически переходить туда и обратно!) или оставаться на уровне сеньор-разработчика, решая задачи, которые вам интересны. Но если вы хотите помогать организации достигать ее целей и наращивать технологические мускулы, повышая навыки ее разработчиков, тогда продолжайте читать.

Благодарности

Спасибо всем, всем, всем, кто помогал мне с этой книгой.

Спасибо Саре Грей (Sarah Grey), лучшему ведущему редактору, и всей великолепной команде издательства O’Reilly, включая шеф-редактора Мелиссу Даффилд (Melissa Duffield); выпускающего редактора Лиз Фаерм (Liz Faerm); редактора Джоша Оледжарца (Josh Olejarz); Сьюзан Томпсон (Susan Thompson), создавшую эту необыкновенную обложку, и иллюстратора Кейт Даллеа (Kate Dullea), которая превратила мои карандашные наброски в прекрасные рисунки. Я пишу книгу в первый раз, и вы помогли мне преодолеть мой страх.

Благодарю Уилла Ларсона (Will Larson) за его одобрение и поддержку, а также за то, что он помогает стафф-разработчикам объединиться в сообщество. Благодарю Лару Хоган (Lara Hogan) за ее энтузиазм и подсказки, после того как я задала ей вопрос «Получится ли у меня написать книгу?» в личном сообщении. Спасибо вам обоим за то, что показали, как должна выглядеть настоящая поддержка.

Мне крупно повезло встретить на своем пути двух самых мудрых и проницательных разработчиков, которых я когда-либо знала. Циан Синнотт (Cian Synnott) и Катрина Состек (Katrina Sostek), эта книга стала значительно лучше благодаря вашим ревью и обратной связи за последний год. Особенно я признательна вам за вдумчивые предложения по тем частям, которые никак не получались. Критиковать конструктивно всегда сложнее, и я благодарна за ваше время и силы.

Некоторые люди потратили много личного времени на то, чтобы поговорить о моих идеях, предложить обратную связь или чему-то меня научить. Хочу особенно поблагодарить Франклина Ангуло, Джеки Беновиц, Кристину Беннетт, Сильвию Ботрос, Мохита Чеппудира, Джона Колтона, Триш Крэйн, Джунипер Кросс, Степана Давидовича, Тиарнана де Бурка, Росса Дональдсона, Тесс Доннелли, Тома Драпо, Дейл Эмбри, Лиз Фонг-Джонс, Камиль Фурнье, Стейси Гэммон, Карла Гайссера, Полину Гиральт, Тали Гутмана, Лиз Хетерстон, Моджтаба Хоссейни, Кейт Хьюстон, Джоди Ноуэр, Роберта Кенигсберга, Рэндала Коутника, Лерх Лоу, Кевина Линча, Дженнифер Мейс, Глен Мейлер, Киви Макминн, Дэниэла Микола, Зака Миллмана, Сару Милштейн, Исаака Перес Мончо, Дэна На, Катрину Оуэн, Еву Пэриш, Иветту Паскуа, Стива Примерано, Шона Риза, Джона Риза, Макса Шуберта, Кристину Шульман, Патрика Шилдса, Джоану Смит, Беату Страк, Карла Сазерленда, Кэти Сайлор-Миллер, Изара Тарандач, Фабианну Тассини, Элизабет Вотау, Аманду Уокер и Сару Уэллс. Также благодарю многих (очень многих!) людей, с которыми я переписывалась в личных сообщениях и по электронной почте, с которыми мы разговаривали в холле или вели вдохновляющие беседы в Slack. Вы сделали эту книгу лучше, я очень вас ценю.

Спасибо всем, кто пил со мной чай после обеда: каждый день вы демонстрировали единство нашего сообщества. Спасибо всем участникам канала #staff-principal-engineering в Rands Leadership Slack за вашу неустанную поддержку и за то, что вы по-дружески делились своим опытом. Огромная благодарность моим коллегам в Squarespace и сообществе Google SRE. Я многое от вас узнала. Также хочу поблагодарить Рут Ярнит (Ruth Yarnit), Роба Смита (Rob Smith), Мариану Валетт (Mariana Valette) и весь персонал конференции Lead Dev за невероятные материалы по инженерному лидерству, которыми они поделились с миром. Спасибо за то, что вы делаете.

Спасибо семье Хилфокс, включая их замечательную собаку. Мне повезло быть вашим другом, я очень этому рада. Спасибо, что позволили мне работать над книгой в вашем фургоне (и провести там карантин, пока я болела COVID!). Надеюсь на долгую дружбу и мечтаю увидеть, как вырастут маленькие дубки, которые вы посадили.

Наконец, спасибо всей моей семье – родителям Дэнни и Кэтлин и всему многочисленному клану – за ваше терпение, которое вы проявили в последний год, пока я писала книгу и выпала из жизни.

И конечно, спасибо Джоэлу и Мисс 9! Я с нетерпением жду новых встреч с вами по субботам. Спасибо Джоэлу (которому пришла идея о том, что человеческие навыки похожи на «дополнительные опоры»), за прекрасные разговоры об инженерных компаниях и о создании хорошего программного обеспечения. И спасибо за ваши сэндвичи. Спасибо Мисс 9 (когда я написала первый черновик этой книги, она была Мисс 6!) за отличные идеи, рисунки и объятия. Я ценю вас, неваляшки.

Часть I. Панорамное мышление

Глава 1. Как вы думаете, что вы здесь делаете?

Идея карьеры стафф-разработчика (или «инженерный путь») является новой для множества компаний. Организации расходятся во мнениях о том, какими качествами должны обладать самые старшие программисты и какую работу те должны выполнять. Сильвия Ботрос (Silvia Botros) пишет (https://oreil.ly/xwgRn), что тем не менее большинство единодушны в следующем: вершина инженерной карьеры – это не просто «еще более сеньорный сеньор», хотя ясного понимания, что это такое, нет. Поэтому первая глава моей книги начинается с экзистенциального вопроса: зачем компаниям нужны «самые старшие» разработчики? Потом, вооружившись ответом, мы раскроем суть роли стафф-разработчика: разберем требования к техническим навыкам и лидерские качества, которые необходимы на этой должности, а также выясним, что означает «работать самостоятельно».

Обязанности стафф-разработчика могут быть самыми разными, и существует множество способов выполнять их качественно. Однако каждая из них нацелена на решение конкретной задачи, и не любой компании нужен специалист со всем спектром возможных функций. В этой книге я расскажу, что подразумевает роль стафф-разработчика: сфера ответственности, степень влияния на рабочие процессы, место в служебной иерархии, основная цель и другие составляющие. Вы сможете использовать мой опыт, чтобы понять, как вам работать, в каком направлении профессионально развиваться или кого нанять. Наконец, поскольку разные компании по-разному понимают функционал стафф-разработчика, мы постараемся согласовать эти представления с мнением ключевых фигур компании.

Давайте начнем с того, в чем заключается работа стафф-разработчика.

Кто вообще такой стафф-разработчик

Если бы существовало только одно направление карьерного роста (как показано на рис. 1.1 слева), то многие программисты столкнулись бы с трудным и даже жестоким выбором: остаться на должности разработчика и продолжать совершенствовать свое мастерство в написании кода или перейти в менеджмент и развиваться как управленец.

Поэтому многие компании теперь предлагают «инженерную» карьеру, или путь индивидуального контрибьютора (individual contributor), позволяя программистам расти параллельно тому, как растут выбравшие «менеджерскую» карьеру. Пример такого карьерного пути показан на рис. 1.1 справа.

Рис. 1.1. Две карьерные возможности: с одним путем развития и с двумя

Карьерные возможности в разных компаниях сильно отличаются друг от друга, и для их сравнения даже создали специальный веб-сайт levels.fyi.¹¹ Количество этапов карьерного пути и их названия также могут быть различными. Вам даже могут встретиться одни и те же названия в разном порядке.¹² Но слово сеньор используется очень часто. Марко Роджерс (Marco Rogers), директор инженерного направления, который разработал должностные иерархии для двух компаний, назвал уровень сеньора «переходным» (https://oreil.ly/MpwsJ). Роджерс говорит: «На позициях ниже сеньора люди развивают способность работать самостоятельно, на должностях выше сеньора возрастает влияние на процессы в компании и ответственность за результат».

Иногда уровень сеньора рассматривается как «вершина»: вам больше не нужно расти в должности.¹³ Но если вы все же продолжаете свой служебный рост, то становитесь «техническим лидером». Следующая ступень после сеньора обычно называется «стафф-разработчик», это название я и буду использовать далее.

На рис. 1.1 показаны два варианта карьерного роста, и программист уровня сеньор может выбирать, развиваться ли как менеджер или как стафф-разработчик. После перехода на следующую ступень изменение должности со стафф-разработчика на менеджера или наоборот нужно рассматривать как горизонтальное перемещение, а не карьерный рост. Сеньор-стафф-разработчик находится на том же уровне, что и старший менеджер, принципал-разработчик находится на уровне директора и т. д.; в служебной иерархии отдельных компаний могут быть и более высокие уровни. (Я обозначу должности, расположенные выше сеньора, словом «стафф+», которое придумал и описал Уилл Ларсон (Will Larson) в своей книге «Staff Engineer».)

Немного о должностях

Иногда я слышу, как люди настаивают на том, что должности не имеют (или не должны иметь) значения. Они приводят разумные доводы в пользу того, что их компания является эгалитарной меритократией, которая сторонится опасностей иерархии, и говорят: «Мы живем в демократическом обществе и с уважением принимаем все идеи». Конечно, их позиция достойна восхищения: мнение любого человека важно, даже если он находится в самом начале своего карьерного пути.

Но все же должности имеют значение. Команда разработчиков среднего звена написала статью, в которой обозначила три причины необходимости должностей: «Они помогают осознать, что вы растете как профессионал, помогают преодолеть укоренившиеся в отрасли предрассудки и информируют окружающих об уровне вашей компетентности» (https://oreil.ly/oUkHe).

Первая причина является субъективной и, наверное, мотивирует не всех, но две другие описывают эффект, который должности оказывают на людей вокруг вас. Неважно, является компания эгалитарной или нет, в ней всегда будут те, кто по-разному относится к людям, находящимся на разных должностных уровнях, и большинство из нас хотя бы немного волнует собственный статус. Доктор Кипп Круковски (Dr. Kipp Krukowski), профессор практики по предпринимательской деятельности Государственного университета Колорадо, в своей работе 2017 года «The Effects of Employee Job Titles on Respect Granted by Customers» пишет: «Должности работают как символы, с их помощью компании информируют людей внутри и вне фирмы о компетентности своих сотрудников» (https://oreil.ly/zD3kp).

Мы постоянно оцениваем людей и неосознанно строим предположения. Если мы не приложим усилия, чтобы разобраться со своими подсознательными оценками, то скорее всего, попадем под влияние стереотипов. Например, исследование 2015 года (https://oreil.ly/snmmY) показало, что примерно половину из 557 темнокожих и латиноамериканских женщин – специалистов в области науки, технологий, инжиниринга и математики, участвовавших в исследовании, ошибочно принимали за обслуживающий или административный персонал.

Аналогичные предрассудки существуют и в отношении программистов. Бытует мнение, что белые и азиатские мужчины-разработчики более опытны и технически подкованны, а также лучше разбираются в коде, независимо от того, работают ли они уже несколько десятилетий или только вчера выпустились из университета. Женщины, особенно небелые, иногда воспринимаются как менее опытные и менее квалифицированные. Всем им приходится прилагать дополнительные усилия, чтобы доказать свою компетентность.

В вышеупомянутой статье разработчиков среднего звена сказано, что должности помогают разрушить стереотипы и дают представление об уровне компетентности программиста. Формирование правильных ожиданий сберегает специалистам время и силы, которые в противном случае пришлось бы потратить, снова и снова подтверждая свой статус. Это экономит им несколько часов в неделю.

Должность также может повлиять на работу, которую вы получите в будущем. Как и многие представители технологической отрасли, я каждый день получаю электронные письма с предложениями работы от LinkedIn. Лишь три раза я получила от рекрутеров, не читавших мою анкету, приглашение на более высокую должность, чем была у меня на тот момент. В остальных случаях мне предлагали либо позицию, которая в точности соответствовала моей, либо более низкую.

Вот что представляет собой должность стафф-разработчика в иерархии компаний. Но давайте посмотрим, зачем нужны уровни технических лидеров. Во вступлении я назвала три основополагающих навыка инженерной карьеры: панорамного мышления, реализации проектов и повышения квалификации. Почему именно инженеры должны обладать такими умениями? Зачем вообще нужны стафф-разработчики?

Зачем нужны разработчики, умеющие видеть картину в целом?

Работа в любой инженерной компании требует постоянного принятия решений: какие технологии внедрить, что разрабатывать, продолжать инвестировать в систему или отказаться от нее. Часто круг лиц, обязанных сделать важный выбор, четко определен и последствия предсказуемы. Но некоторые решения имеют фундаментальный характер и затрагивают всю программную архитектуру, и никто не может знать, как это повлияет на другие компоненты системы.

Для принятия правильных решений нужен контекст. Опытные разработчики знают, что ответ на большинство технологических вопросов зависит от обстоятельств. Недостаточно понимать плюсы и минусы выбранной технологии: вы должны разбираться в деталях конкретной ситуации. Что вы пытаетесь сделать? Сколько у вас времени, денег, упорства? Каков приемлемый уровень риска? Что нужно бизнесу? Ответы на эти вопросы и есть контекст принятия решения.

Определение контекста требует времени и сил. Каждая команда склонна принимать решения исходя из своих интересов, а каждый программист, скорее всего, будет сфокусирован на достижении целей своей команды. Но часто решения, принятые одной командой, имеют последствия для всей компании. Локальный максимум – это лучшее решение для отдельной команды, которое может оказаться неудачным для организации в целом.

На рис. 1.2 показан пример, в котором команда выбирает между двумя программами А и Б. У обеих программ есть необходимые функции, но программу А намного проще установить: запустил – и работает. Программа Б немного сложнее: чтобы она заработала, пару спринтов придется потратить на обсуждение. Никто не хочет так долго ждать.

С точки зрения команды, программа А – абсолютный победитель. Зачем выбирать что-то другое? Но остальные предпочли бы программу Б. Оказалось, что программа А будет постоянно нагружать работой юристов и отдел безопасности, а необходимость аутентификации означает, что ИТ-отделу и команде разработчиков платформы придется работать с этой программой особым образом. Выбрав программу А – локальный максимум, – команда неосознанно выбирает решение, которое потребует намного больших затрат от всей организации. Программа Б всего лишь немного хуже для команды, но намного лучше для компании, а дополнительные два спринта окупятся за квартал. Но сделать правильный выбор может только человек, способный просчитать влияние отдельного решения на все ключевые бизнес-процессы предприятия.

Рис. 1.2. Локальный максимум vs лучшее решение

Чтобы избежать необъективности локального максимума, команде нужен человек, ответственный за принятие решений (или хотя бы способный повлиять на этот процесс), который может взглянуть на ситуацию со стороны, то есть учесть интересы нескольких команд и выбрать путь, удовлетворяющий целям организации или бизнеса в целом. В главе 2 я расскажу, какие приемы позволят получить более объективную картину и принести компании успех.

Необходимо не только проанализировать условия, актуальные в настоящий момент, но и спрогнозировать, какое влияние принятое решение окажет на бизнес в будущем. О чем вы будете жалеть через год? Что принесет вам пользу через три года? Чтобы двигаться в одном направлении, команды должны согласовать технические стратегии: на какие технологии делать ставку, какие платформы стандартизировать и т. д. Все эти серьезные шаги неоднозначны и часто вызывают споры, поэтому для принятия решения нужно выявить все значимые обстоятельства и донести до окружающих их важность. Глава 3 посвящена выбору направления развития всей команды.

Так что если вы хотите принимать основополагающие решения, нацеленные на будущее, то вам нужны люди, которые могут мыслить панорамно. Но разве менеджер этого не может? Или, например, может ли технический директор (CTO, chief technology officer) разобраться в потребностях бизнеса, перевести их на технический язык и рассказать всем, что нужно делать?

Иногда может. В маленьких командах менеджер зачастую является самым опытным инженером, принимает ключевые решения и выбирает направление технологического развития бизнеса. В маленькой компании CTO может быть глубоко вовлечен в разработку мельчайших деталей каждой задачи. Может быть, таким компаниям и не нужны стафф-разработчики. Но положение начальника может затмить технические аргументы: подчиненным часто неудобно спорить с руководством, даже если выбранное им инженерное решение не самое лучшее. К тому же управление людьми само по себе занимает полный рабочий день. Если человек тратит время на то, чтобы стать хорошим управленцем, у него остается мало времени на изучение технических новинок, а если человек старается глубоко погружаться в технические детали, то у него будет меньше возможностей заниматься подчиненными. На коротком промежутке времени это может не вызвать значительных трудностей: некоторые команды успешно функционируют, не требуя особых организаторских усилий. Но если потребности команды вступают в противоречия с техническими задачами, то менеджер должен выбирать, на какой проблеме ему сосредоточиться. И тогда либо участники команды, либо технические вопросы останутся без должного внимания со стороны руководства.

Это одна из причин, по которой организации разделяют управление технической деятельностью компании и руководство людьми. Если у вас несколько разработчиков, то проводить каждое решение через CTO или старшего менеджера неэффективно, не говоря о том, что это демотивирует сотрудников. Если опытные инженеры получат полномочия, позволяющие им принимать решения по техническим вопросам, а также возможность погружаться в задачи и определять их контекст, то результаты и разработки только улучшатся.

Это не означает, что инженеры должны в одиночку определять техническую политику предприятия. Менеджеры, ответственные за назначение людей на технические проекты, тоже должны участвовать в принятии решений. Как поддерживать согласованность действий менеджеров и разработчиков, я расскажу далее в этой главе, а также в главе 3, в которой мы поговорим о стратегии.

Что насчет ИТ-архитекторов?

В некоторых компаниях должность ИТ-архитектора считается одной из инженерных в должностной структуре. В других компаниях архитекторы – это проектировщики каких-то систем со своим особым карьерным путем, отличным от карьеры программиста, применяющего эти системы. В этой книге я буду рассматривать разработку программного обеспечения и его архитектуры как часть обязанностей стафф+ разработчика, но имейте в виду, что в нашей отрасли это не всегда так.

Зачем нужны разработчики, которые ведут кросс-командные проекты

В идеале команды должны дополнять друг друга, как фрагменты пазла, закрывая все потребности проекта. А еще в идеале имеется новый прекрасный проект, в котором нет ни априорных ограничений, ни унаследованных систем, а каждая команда целиком и полностью посвящает себя работе. Сферы ответственности команд четко определены, и в них никто не сомневается. В начале проекта каждой команде поручают работу только над одним из компонентов продукта. Технические консультанты компании Thoughtworks назвали такое деление на команды обратным законом Конвея (https://oreil.ly/HdKyK). Конечно, на этом идеальном проекте возникают только трудности, связанные с фундаментальными научными исследованиями и поиском новаторских решений, а люди жаждут разгадывать технические головоломки, чтобы покрыть себя неувядаемой профессиональной славой.

Я бы хотела поработать на таком проекте. А вы? К сожалению, в жизни все совсем иначе. Команды, вовлеченные в любую кросс-командную работу, наверняка образовались до того, как этот новый проект был задуман, и работают над чем-то другим, может быть, даже над чем-то, что, по их мнению, является более важным. На середине проекта внезапно появляются новые обстоятельства. Сферы ответственности команд начинают пересекаться и разрываются, и это негативно сказывается на программной архитектуре. Сложные и непонятные вопросы оказываются не увлекательными алгоритмическими и исследовательскими задачками, а необходимостью пробираться через лабиринты унаследованного кода, вести переговоры с перегруженными командами, не желающими ничего менять, а еще нужно угадать намерения разработчиков, уволившихся несколько лет назад.¹⁴ На старте виден не весь объем работы, и даже понимание того, какие именно изменения нужно внести, может стать большой проблемой. Внимательно прочитав проектную документацию, вы, скорее всего, обнаружите, что ключевые решения, требующие максимальной согласованности действий команд, были отложены на потом или от них вовсе отказались.

Вот так выглядит реальный проект. Вы можете сколь угодно тщательно распределять части масштабного проекта между командами, но все равно в итоге какие-то задачи не достанутся никому, а какие-то – попадут сразу в две команды. Могут возникнуть задержки в передаче данных и появиться неточности при переводе на другие языки, и все это приведет к конфликтам интересов. Команды будут принимать решения, которые выгодны только им (принцип локального максимума), и заведут проект в тупик.

Если вы хотите, чтобы работа продвигалась, то вам нужен человек, который будет отвечать за весь проект, а не за отдельные его части. На начальном этапе этот человек определит объем работ и распределит задачи. Как только проект перейдет в стадию реализации, этот человек, скорее всего, станет автором или соавтором высокоуровневых требований и главным контактным лицом по этим вопросам. Он будет поддерживать должное качество технической работы, прогнозируя риски и задавая вопросы, которые другие боятся задать. Он также будет заниматься неформальным обучением и наставничеством руководителей отдельных частей проекта или просто послужит им хорошим примером. Если работа застопорится, он сможет выявить причины пробуксовки и устранить их, поскольку обладает исчерпывающей полнотой знаний о бизнес-процессах в компании (см. подробнее в главе 6). Он посвятит в тонкости проекта людей, не задействованных в нем, и разъяснит им, в чем ценность продукта и как результаты отразятся на каждом сотруднике.

Почему технический программный менеджер (technical program manager, TPM) не может заняться поиском консенсуса между командами и проведением переговоров? Конечно, здесь есть некоторое пересечение сфер ответственности. Но все-таки TPM отвечает за конечный продукт, а не за разработку и качество кода. TPM следит за тем, чтобы проект завершился в срок, а стафф-разработчик контролирует, чтобы проект соответствовал техническим нормам. Также стафф-разработчик отвечает за то, чтобы в итоге система получилась надежной и хорошо вписывалась в технологический ландшафт компании. Он старается избегать технического долга и всего, что может создать трудности людям, которые будут поддерживать работоспособность системы. TPM не разрабатывает технические проекты, стандарты тестирования или код-ревью, а на совещании по интеграции он не будет углубляться в дебри скриптов унаследованной системы. Если стафф-разработчик и TPM успешно сотрудничают на большом проекте, то они могут построить команду мечты.

Зачем команде авторитетные разработчики?

Программное обеспечение влияет на жизнь каждого из нас. Системы, которые мы разрабатываем, напрямую затрагивают благосостояние и доходы людей: почитайте список багов, приведенный в Википедии (https://oreil.ly/eNIXO), впечатляет? Крушения самолетов (https://oreil.ly/iJgF2), сбои в системах скорой помощи (https://oreil.ly/s9GQf), неисправности в медицинском оборудовании (https://oreil.ly/fr7Dj) – ошибки и сбои в программах могут привести к фатальным последствиям, и наивно думать, что в будущем таких трагедий станет меньше.¹⁵ Поэтому к разработке ПО нужно подходить со всей серьезностью.

Даже если риски для жизни и здоровья людей минимальны, на разработчиках все равно лежит большая ответственность за достижение поставленных целей. За редким исключением, связанным с исследованиями и новыми разработками, инженерные компании работают совсем не для того, чтобы на планете стало на одну технологию больше. Они заняты решением актуальных бизнес-задач или создают что-то для пользы людей. Они хотят достичь своих целей: создать продукт приемлемого качества и эффективно использовать ресурсы, сведя к минимуму возможные издержки в будущем.

Качество, эффективность и правильность выполнения проектов могут оказаться далеки от обещанных, особенно если поджимают сроки. Иногда сделать что-то «правильно» означает потратить больше времени, но команды, которые спешат сдать работу, могут попытаться схалтурить: пропустить тестирование или оставить код-ревью без должного рассмотрения. Написать хорошую программу непросто, одной интуиции тут недостаточно. В команде должны быть старшие, которые уже отточили свои навыки, увидели победы и поражения и теперь могут взять на себя ответственность за создание программ, которые будут работать стабильно.

На каждом проекте мы узнаем что-то новое, но опыт одного человека все равно ограничен. Это значит, что мы должны учиться на ошибках и успехах других людей. Менее опытные участники команды, может быть, никогда и не видели, как пишутся качественные программы, и думают, что главная цель разработки – написать как можно больше кода. Более опытные инженеры могут сильно повлиять на них, внедряя ревью кода, а также лучшие архитектурные практики и инструменты, которые помогут всем создавать более надежное ПО и делать это быстрее.

Стафф-разработчик – это пример для подражания. Менеджеры формируют культуру общения в команде, призывая к взаимоуважению и обеспечивая соблюдение социальных норм. А вот технические стандарты задаются самыми авторитетными инженерами. Неважно, что говорят инструкции: если самый опытный разработчик не пишет тесты, все остальные тоже не будут. Это социокультурный феномен, и никакими нравоучениями его не изменить. Когда вышестоящие сотрудники во всеуслышание хвалят чужую работу, относятся друг к другу с уважением, задают уточняющие вопросы, остальные с легкостью делают то же самое. Когда молодые программисты видят в ком-то «разработчика, которым они хотели бы стать», они стремятся работать так же, как этот специалист. (В главе 7 мы рассмотрим, как с помощью личного примера вывести организацию на новый уровень результативности.)

Теперь вы убедились, что инженерам нужно мыслить панорамно, уметь руководить крупными проектами и оказывать положительное влияние на молодых коллег, но есть одна проблема: сделать это при полной нагрузке сеньор-разработчика невозможно. Если вы продумываете стратегию, делаете код-ревью или устанавливаете стандарты, то вы не пишете код и не разрабатываете архитектуру новых систем, то есть вы не делаете работу, которую можно назвать работой программиста. Если самые опытные разработчики компании пишут код целый день, то кодовая база, конечно, улучшится, но задачи, которые могут решить только эти специалисты, выполнены не будут. В обязанности стафф-разработчика входит поиск решений для задач, оказавшихся непосильными для других инженеров. Вот это и есть его работа.

Хватит рассуждать. Что делать-то?

Обязанности стафф-разработчика могут варьироваться в разных компаниях, тем не менее у этой роли есть отличительные признаки, о которых я расскажу здесь и далее буду принимать за аксиомы.

Вы не менеджер, но вы – лидер

Стафф-разработчик прежде всего – лидер. По уровню старшинства он часто приравнивается к линейному менеджеру, а принципал-разработчик – к директору. Стафф+ разработчик находится на одной ступени с менеджером того же уровня, а значит, он должен быть таким же компетентным. Может быть, вы даже окажетесь авторитетнее и опытнее некоторых менеджеров в вашей организации. Всякий раз, когда возникает ощущение, что «кто-то должен действовать», то скорее всего, этот «кто-то» – вы.

Обязаны ли вы быть лидером? Мидл-разработчики часто спрашивают меня, можно ли продвинуться по карьерной лестнице, не развивая все эти «мягкие навыки» («софт скилы»). Разве технических недостаточно? Если вы не любите общаться с людьми и стали программистом, чтобы делать инженерную работу, может показаться несправедливым, что ваш карьерный рост останавливается из-за отсутствия умения коммуницировать. Но с одними технологиями вы не сможете далеко продвинуться по карьерной лестнице. Если вы хотите выполнять масштабные задачи, то вам придется работать с большими группами людей, а для этого вам потребуется более широкий набор навыков.

Чем выше ваша зарплата, тем дороже ваше время, а это значит, что вы должны выполнять более важную работу и приносить больше пользы компании. Ваши технические решения должны соответствовать реалиям бизнеса, и вы должны понимать, стоит ли вообще браться за ту или иную задачу. По мере повышения квалификации вас будут привлекать во все более крупные проекты, которые закончатся неудачей, если в команде не будет духа сотрудничества, хорошей коммуникации и согласованности действий; ваши блестящие идеи превратятся в пыль, если вы не сможете убедить других в своей правоте. Хотите вы того или нет, с вас будут брать пример: младшие сотрудники наблюдают за разработчиками с высокими должностями, чтобы понять, как действовать в той или иной ситуации. Так что да: вам придется стать лидером.

Однако лидерство стафф-разработчика отличается от лидерства менеджера. Обычно у стафф-разработчика нет непосредственных подчиненных. Он вносит свой вклад в развитие инженерных навыков других разработчиков, но не отвечает за их производительность, а также не подписывает график отпусков и ведомости на оплату. Он не может уволить или продвинуть по службе (хотя менеджеры учитывают его мнение, оценивая навыки и результаты участников команды). Влияние стафф-разработчика на бизнес-процессы компании проявляется по-другому.

Лидерство может быть разным, и иногда его видно не сразу. Разработать «счастливый путь», который защитит программистов от общих ошибок; сделать ревью кода и проектных решений других участников команды, чтобы они стали увереннее в себе и развили свои навыки; показать, что проектное предложение не соответствует истинным потребностям бизнеса, – все это виды лидерства. Обучение – это лидерство. Планомерное повышение уровня каждого разработчика – тоже лидерство. Выбор технологического направления – лидерство. И наконец, репутация выдающегося технического специалиста, который может вдохновить других людей на реализацию своих планов просто потому, что они ему доверяют, – это тоже особый вид лидерства. Если вы нашли у себя эти черты, то вы – лидер.

Интровертом быть можно, малоприятным типом – нельзя

Многих людей пугает идея лидерства. Но не волнуйтесь: не все стафф– и принципал-разработчики работают по схеме «человек – человек». Среди стафф-разработчиков найдется место для интровертов: даже самые скромные люди могут задать технологическое направление компании благодаря своим знаниям и авторитету. Чтобы стать лидером, не обязательно находиться в центре внимания. Достаточно подавать положительный личный пример и хорошо относиться к людям.

Многие из нас слышали истории про «одного программиста», которого все сторонились, потому что с ним было слишком трудно общаться. Этот типаж, описанный Саймоном Травальей (Simon Travaglia) (https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell), был широко известен в 80-х и 90-х годах. В Usenet¹⁶ и других подобных ресурсах есть множество подтверждений того, что таких людей вполне можно встретить в реальной жизни. Коллеги этого программиста не только терпели его поведение, но и принимали его странные технические решения, только чтобы с ним не связываться. Однако сегодня такой разработчик станет обузой для всех. Какова бы ни была его производительность, сложно представить, что инженер, который не хочет работать в команде, может стоить проваленных проектов, а также результатов и карьеры других программистов. Если такой человек станет еще и примером для подражания в организации, то ее ждут большие проблемы.

Если вы думаете, что этот абзац про вас, зайдите на сайт Kind Engineering (https://kind.engineering/), где Эван Смит (Evan Smith), SRE-менеджер в Squarespace, дает конкретные рекомендации, как стать по-настоящему доброжелательным коллегой. Вы удивительно быстро сможете избавиться от репутации человека, с которым трудно работать.

Вы – технический специалист

Стафф-разработчик не только начальник, но и хороший специалист. Он должен обладать техническими знаниями и навыками, а также интуицией, основанной на опыте работы в инженерной отрасли. Чтобы завоевать авторитет, вы должны знать, что такое первоклассное программирование, и следовать этому образцу в своих разработках. Делая ревью, вы должны улучшать исходный код или архитектуру, а также учить своих коллег чему-то новому. Если вы принимаете технические решения, то вы должны видеть все их преимущества и недостатки и помогать другим в них разобраться. Вы должны вникать в детали, когда это необходимо, задавать правильные вопросы и понимать ответы. Если вы обсуждаете конкретный план действий или изменения в технической политике компании, то вы должны понимать, о чем идет речь. Поэтому вам необходим прочный фундамент технических знаний.

Это не означает, что вы будете писать много кода. На уровне стафф+ ваша цель – эффективно решать проблемы, и скорее всего, вам не придется программировать. Возможно, вам стоит заняться архитектурным проектированием или взять на себя обязанности руководителя, то есть делать то, с чем справитесь только вы, а программирование оставить другим. Стафф-разработчики часто решают трудные, неоднозначные и запутанные задачи, проделывая ровно столько работы, сколько необходимо, чтобы эти задачи стали понятны другим и их мог довести до конца кто-то еще. Как только проблема становится разрешимой, она превращается в возможность для развития менее опытных разработчиков (иногда с поддержкой стафф-разработчика).

Для некоторых стафф-разработчиков самым эффективным инструментом решения проблем является глубокое погружение в код. Другие получают хорошие результаты, если пишут документацию, или становятся мастерами в области анализа данных, или проводят невероятно много индивидуальных встреч. Неважно, как вы решаете проблемы, главное, что вы их решаете.¹⁷

Вы стремитесь к самостоятельности

Когда вы только начали работать программистом, скорее всего, вами руководил менеджер: он выдавал вам задачи и способы их решения. Когда вы стали сеньором, возможно, менеджер подсказывал вам, какие проблемы важно решить в первую очередь, а поиск решения оставлял за вами. На уровнях стафф+ менеджер только делится с вами информацией, но именно вы говорите ему, что важно, а что нет. Сабрина Леандро (Sabrina Leandro), принципал-разработчик в компании Intercom, задается вопросом (https://oreil.ly/FOI1L): «Теперь вы знаете, что должны работать над важными и актуальными проблемами. Но где вы возьмете этот волшебный список отложенных трудоемких задач, которые вы должны выполнить?» И сама отвечает: «Вы же его и напишете!»

Когда вы станете руководителем, вам придется разрываться между различными направлениями деятельности компании. Но вы сами отвечаете за распределение своего времени. Количество часов в неделе ограниченно (см. главу 4). Вы сами выбираете, на что их потратить. Если вас просят выполнить какую-то работу, проявите свою компетентность: оцените, насколько высок приоритет у этой задачи, сколько времени потребуется на выполнение и какую пользу можно извлечь из достигнутого результата (включая возможность наладить дружеские отношения с людьми, попросившими вас о помощи), и решите сами, делать или нет. Если вас о чем-то просит генеральный директор (CEO, Chief Executive Officer) или другой начальник, то вы придаете его просьбе соответствующий вес. Но где самостоятельность, там и ответственность. Если выполнение поручения приведет к росту издержек для бизнеса, вы обязаны предупредить об этом. Не стоит молча наблюдать, как проблема разрастается до все больших масштабов. (Конечно, чтобы вас услышали, нужно заслужить доверие и научиться делать верные прогнозы.)

Вы задаете направление технологического развития компании

Стафф-разработчик – это технический лидер, и именно он должен убедиться, что компания выбрала верное технологическое направление развития. Основной продукт или сервис, который предлагает предприятие, – это набор технических решений: архитектура, системы хранения данных, фреймворки и инструменты, которые используются, и т. д. Неважно, на каком уровне приняты решения: команды, нескольких команд или всей организации. Ваша обязанность проконтролировать, что все сделано качественно и задокументировано. Смысл не в том, чтобы самостоятельно продумывать все (или даже некоторые необходимые!) аспекты, а в том, чтобы убедиться, что действенное решение найдено и согласовано со всеми заинтересованными сторонами.

Вы часто и продуктивно общаетесь с людьми

Чем выше ваша должность, тем прочнее должны быть ваши коммуникативные навыки. Что бы вы ни делали, вам придется получать и передавать информацию. Чем лучше вы излагаете свои мысли, тем легче вам будет работать.

Разбираемся в специфике роли стафф-разработчика

Все вышеперечисленные наблюдения дают основное представление о роли стафф-разработчика, но начав работать в должности, вы быстро поймете, что есть еще множество насущных деталей! В жизни все может быть несколько иначе. Обязанности, которые вам придется выполнять, будут зависеть от размера и потребностей вашей компании, а также от ваших личных предпочтений и стиля работы.

Такая вариативность означает, что сравнивать работу разных стафф-разработчиков проблематично. И в данном разделе мы посмотрим, насколько отличается понимание функционала этой должности в разных компаниях.

Давайте начнем с позиции стафф-разработчика в должностной структуре компаний.

Место в структуре организации

Пока что в нашей отрасли у стафф+ разработчиков нет общепринятого места в иерархии должностей. В некоторых компаниях самые старшие разработчики подчиняются главному архитектору или команде технического директора; в других компаниях стафф+ разработчики подчиняются директорам разных структурных подразделений, или менеджерам разных уровней, или вообще и тем и другим одновременно. Здесь нет одного правильного варианта, но есть много неправильных, и все зависит от поставленных целей.

Ваша позиция в иерархии компании (см. пример на рис. 1.3) влияет на многое: какую поддержку вы получите, к какой информации вам предоставят доступ и зачастую то, как вас будут воспринимать коллеги вне вашей группы.

Рис. 1.3. Стафф+ разработчики на разных уровнях иерархии. Разработчику А намного проще получить исчерпывающую информацию о бизнес-процессах организации и говорить на уровне директоров, чем разработчику D, даже если разработчики А и D имеют одинаковый уровень профессионализма

Ваш руководитель находится высоко в служебной иерархии

Если ваш непосредственный руководитель занимает высокую должность, например, это директор или вице-президент, то вы получите более полную картину бизнес-процессов компании. Вам откроется доступ к важной и значимой информации, но в то же время вам придется решать более серьезные задачи. Работая под руководством компетентного и опытного человека, вы сможете наблюдать, как он принимает решения, ведет совещания или выходит из сложной ситуации, и получить уникальный и ценный опыт.

С другой стороны, такой руководитель будет уделять намного меньше времени вашей работе, чем менеджер вашего подразделения. Вы будете меньше общаться, а значит, у него будет меньше возможностей поддерживать вас и помогать развиваться профессионально. Разработчик, который тесно сотрудничает с отдельно взятой командой, но подчиняется директору, может чувствовать себя оторванным от остальных коллег или отвлекать директора на разногласия, которые можно урегулировать на более низком уровне.

Если вашему руководителю часто не хватает времени, чтобы разбираться в работе, которую вы делаете, или его втягивают в обсуждение низкоуровневых технических решений, растрачивая его время впустую, то вам, скорее всего, будет комфортнее работать с менеджером, задачи которого в большей степени совпадают с вашими.

Ваш руководитель находится низко в служебной иерархии

В том, что ваш непосредственный руководитель занимает более низкую должность в структуре компании, есть свои преимущества и недостатки. Возможно, он будет уделять вашей работе больше времени и сможет оказывать вам поддержку в сложных ситуациях. Если вы предпочитаете фокусироваться на какой-то одной технической области, то вам будет удобнее работать с начальником, который хорошо в ней разбирается.

Однако стафф-разработчику, закрепленному за отдельной командой, будет трудно оказывать влияние на принятие решений, касающихся деятельности всей организации. Нравится вам это или нет, но люди обращают внимание на статус, позицию в структуре должностей компании и порядок подчинения. У вас будет меньше возможностей влиять на рабочие процессы, если вы будете в подчинении у линейного менеджера. Вы не сможете получать исчерпывающую информацию о деятельности компании в целом, и вам придется довольствоваться только теми данными, которые необходимы для решения задач вашей отдельной команды. Если у вашего руководителя нет доступа к какой-либо информации, то и у вас, скорее всего, его тоже не будет.

Если ваш начальник линейный менеджер, он может оказаться менее опытным, чем вы. Это не проблема, но это ограничивает ваши возможности учиться у своего руководителя, и это точно не будет способствовать вашему карьерному росту: ваш начальник просто не сможет вам помочь. Но все это не важно, если ваши потребности в опытном наставнике закрываются другими способами.¹⁸ Например, если должность вашего руководителя недостаточно высокая, постарайтесь найти возможность принимать участие во встречах «через уровень» (skip-level meetings), то есть в совещаниях с начальником вашего начальника.¹⁹ Найдите способ оставаться в курсе всех ключевых событий в вашей организации.

Если у вас и вашего руководителя разные представления о том, каким образом вы можете принести наибольшую пользу компании, то между вами могут возникнуть разногласия. В итоге вы можете столкнуться с проблемой локального максимума, которую я упоминала ранее, когда ваш начальник хочет, чтобы вы работали над задачами, важными для команды, хотя существуют цели, которые важны для всей организации и которых можете достичь только вы. Если начальник может повлиять на оценку вашей работы в компании и размер причитающегося вознаграждения, то вам будет трудно обсуждать с ним технические вопросы и приоритетные задачи на равных. Если с вами происходит что-то подобное, то, возможно, вам следует поднять вопрос о переводе на более высокий уровень подчинения.

Сфера ответственности

Позиция в структуре должностей компании, скорее всего, повлияет на то, какой будет ваша сфера ответственности: какие задачи вам предстоит решать и с какими командами работать, отвечая за их результаты, даже если вы формально не будете являться их руководителем.

Вы должны будете определять краткосрочные и долгосрочные цели команды, быть в курсе важных нововведений, иметь свое мнение насчет планируемых изменений и поддерживать коллег, которые не имеют достаточных полномочий, чтобы воспрепятствовать принятию технических решений, негативно влияющих на их работу. Вы должны продвигать и развивать следующее поколение сеньор– и стафф-разработчиков, находить и предлагать проекты и возможности, которые помогут им вырасти по службе.

Может быть, ваш начальник будет ожидать от вас, что бо́льшую часть своего времени и мастерства вы посвятите решению проблем, которые находятся в его компетенции. Или вас просто «припишут» к какой-то команде, а на самом деле вы будете заниматься увольнениями и повышениями во всей организации. Если вы окажетесь в подчинении у директора, то другие сотрудники, возможно, будут неявно подразумевать, что вы работаете на высоком уровне и связываете воедино все, что происходит в компании, или же вас могут явно распределить в какую-то подгруппу команды директора или назначить ответственным за определенный круг технических вопросов. Выясните, что именно вас ждет.

В критические моменты жизни компании будьте готовы выйти за пределы своей сферы ответственности: например, во время программных сбоев понятия «не моя работа» не существует. Также научитесь выходить за рамки своей ежедневной рутины: руководить, когда потребуется, учиться тому, чему вы должны научиться, чинить то, что сломалось. Стафф-разработчик приносит пользу компании, только если не сидит на своем месте, как «сверчок на шестке» из пословицы.

Так или иначе, я рекомендую вам тщательно разобраться, за что вы отвечаете в компании, даже если ваши обязанности со временем изменятся.

Сфера ответственности слишком велика

Если ваша сфера ответственности слишком велика (или не определена), то у вас могут появиться следующие проблемы.

Отсутствие ощутимых результатов

Если на вас можно свалить что угодно, то скорее всего, на вас свалят вообще все, особенно если в организации слишком мало старших сотрудников. С другой стороны, может случиться так, что вы будете выполнять только побочные квесты, не имея какой-либо основной цели.²⁰ Постарайтесь не распыляться на мелочи. Иначе у вас (или у того, кто вас нанял) появится ощущение, что вы ничего не достигли.

Снижение скорости принятия решений

Если в организации есть старший сотрудник, который «делает все», то остальные сотрудники могут подумать, что он должен участвовать в принятии любого решения. В итоге вместо того, чтобы ускорить работу организации, такой сотрудник, наоборот, ее замедлит, потому что без него никто ничего не сможет решить.

Усталость от принятия решений

Если вы не научились не распыляться на мелочи, значит, вы постоянно тратите силы на то, чтобы решить, что именно вам нужно сделать. В главе 4 мы поговорим о том, как выбирать себе задачи.

Сложности в налаживании дружеских связей

Если вы работаете с большим количеством команд, то вам будет сложнее установить регулярные контакты и построить дружеские отношения, которые облегчают выполнение задач (и делают работу приятной!). Остальные разработчики тоже в проигрыше: они не получают наставничества и поддержки, которую может дать «свой» стафф-разработчик, вовлеченный в их задачи.

Если в компании вы можете заниматься буквально любыми вопросами, то вам будет трудно работать. Лучше выберите одну проблему, поработайте над ней и добейтесь ощутимого результата. Полностью посвящайте свое время решению строго определенных задач. Затем, если будете готовы, переходите к другой проблеме.

Сфера ответственности слишком мала

Узкой сферы ответственности также стоит остерегаться. Вот типичный пример: стафф-разработчик является членом команды и подчиняется линейному менеджеру. Менеджерам это даже нравится: они получают очень опытного программиста, который может решать множество задач по проектированию программной архитектуры и техническому планированию и также может быть техлидом или тимлидом на проекте. Некоторых разработчиков это тоже устраивает: они по-настоящему могут углубиться в технологии и задачи команды, понять все тонкости работы. Но помните, что у слишком узкой сферы деятельности есть свои риски.

Отсутствие ощутимых результатов

Возможно, вы потратите свои силы на то, что не требует внимания и мастерства стафф-разработчика. Если вы решили все свое время посвятить одной команде, то у этой команды должны быть критически важные задачи; если вы задумали по-настоящему углубиться в технологию, то это должна быть технология центрального компонента системы; в любом случае это должно быть что-то очень значимое для компании.

Упущенные возможности

На стафф-разработчиков обычно высокий спрос. Если вы прикреплены к одной команде, вам будет трудно участвовать в решении других проблем организации, например, ваш начальник просто не захочет вас отпускать.

Другие разработчики уходят на второй план

Узкая сфера ответственности может означать, что для вас недостаточно работы. Вы можете затмевать собой менее опытных специалистов и не давать им профессионально расти. Если у вас достаточно времени, чтобы ответить на все вопросы и взять на себя абсолютно все запутанные задачи, то у других нет возможности развиваться.

Чрезмерное усложнение

Не сильно загруженный разработчик часто делает ненужную работу, чтобы чем-то занять себя. Если вам встретилось чрезмерно сложное решение простой задачки, то скорее всего, это дело рук стафф-разработчика, которому в следующий раз надо дать кейс потруднее.

Некоторые технические области и проекты настолько сложны, что программист может посвятить им всю свою жизнь и так и не исчерпать всех возможностей. Просто выясните, работаете вы в такой области или нет.

Какова ваша роль в компании?

Если все в компании согласны, что ваша работа важна и приносит ощутимые результаты, у вас появляется достаточно свободы выбора в том, как именно ее выполнять. В том числе определить для себя, в чем именно она заключается. Задайте себе следующие вопросы:

Вы выбираете подход «в глубину» или «в ширину»?

Вы предпочитаете четко фокусироваться на конкретной проблеме либо технологической области? Или же вы склонны работать с несколькими командами либо технологиями и фокусируетесь на одной проблеме только тогда, когда ее нельзя решить без вас? Ответы на эти вопросы во многом зависят от индивидуальных черт вашей личности и вашего стиля работы.

Однозначно правильного варианта нет, но если ваши предпочтения совпадут с вашими служебными задачами, то вам будет легче и приятнее выполнять свои обязанности. Например, если вы хотите заняться разработкой технической политики предприятия, то вам нужно будет ознакомиться со всем спектром мнений по этому вопросу. Вам придется участвовать в принятии решений и браться за проблемы, затрагивающие множество команд. Если же вы сосредоточитесь на одной, пусть даже важной, архитектурной задаче, то у вас не будет достаточно полной информации обо всех аспектах и нюансах процесса и стратегической цели по изменению технической политики вы не достигнете. С другой стороны, если вы хотите стать экспертом в определенной технической области, то вам нужно сосредоточиться на ней и посвящать ей бо́льшую часть своего времени.

Какое из четырех направлений работы в компании вас привлекает больше?

Ведущий разработчик Twitter Йонатан Цунгер (Yonatan Zunger) описал четыре направления абсолютно любой профессиональной деятельности (https://oreil.ly/3S9HE).

Основные технические навыки

Сюда можно отнести все, над чем работает любой практикующий специалист: программирование, рассмотрение судебных споров, создание контента, приготовление еды.

Управление продуктом

Выяснение того, что именно нужно сделать и зачем, документальное сопровождение этого процесса.

Управление проектами

Разработка конкретных способов достижения целей, наведение порядка в делах, отслеживание выполнения задач, выявление причин пробуксовок в работе и их устранение.

Управление людьми

Превращение группы людей в команду, развитие их навыков, продвижение по карьерной лестнице, наставничество и помощь в решении задач.

Цунгер отмечает, что чем выше ваш карьерный уровень, тем меньше все эти навыки отражаются в названии вашей должности: «Чем квалифицированнее вы становитесь, тем больше это воплощается в жизнь, и от вас все чаще ожидают, что вы сможете легко и непринужденно переключаться между этими четырьмя видами деятельности и заниматься любым из них».

Все эти навыки нужны каждой команде и каждому проекту. Стафф-разработчику они тоже необходимы. Однако не обязательно блестяще владеть каждым из них. У всех разные способности, и работа, которая нам нравится или не нравится, у каждого своя. Может быть, вы точно знаете, что любите делать, а чего стараетесь избегать. Но если вы не уверены, Цунгер предлагает обсудить каждое направление с близким другом и попросить его проследить, как будет меняться ваше настроение и энтузиазм, пока вы будете рассказывать. Если вы сильно не любите какой-то вид деятельности, то постарайтесь найти того, кто жаждет за нее взяться. Неважно, какой подход вы выбираете, «в глубину» или «в ширину»: сделать карьеру, обладая лишь техническими навыками, едва ли возможно.

Карьера гиперспециалиста

В редких случаях в области знаний, критически важной для бизнеса, сильный сеньор-разработчик может стать успешным, не умея планировать наперед или влиять на людей. Цунгер называет это ролью «гиперспециалиста», но отмечает, что «…со временем его авторитет будет ослабевать. На самом деле на старших уровнях очень мало узкоспециализированной работы. Это не то, что нужно людям». Патрик Куа (Pat Kua) называет роль гиперспециалиста «истинным путем индивидуального контрибьютора» (https://oreil.ly/9IF0B), отмечая, что на этом этапе также требуются хорошие навыки сотрудничества и коммуникации. В зависимости от компании, карьера «гиперспециалиста» может быть такой же, как у стафф-разработчика, либо совершенно иной.

Есть ли у вас потребность программировать?

Что касается «кодинга», не стесняйтесь погружаться в инженерную работу, которая до данного момента была главной в вашей карьере. Этот набор навыков привел вас туда, где вы сейчас находитесь, и вам, может быть, неприятно чувствовать, что ваши умения устаревают и покрываются ржавчиной. Некоторые стафф-разработчики читают много кода или делают код-ревью, но сами почти не программируют. Другие вносят основной вклад в проект, программируя каждый день. Третьи находят причины писать код: они берут на себя интересные и познавательные некритичные задачи, которые не задерживают основной проект.

Если вы очень хотите писать код каждый день, то не берите на себя слишком много объемных или архитектурных задач, на которые у вас просто не будет времени. Придумайте, как вам удовлетворить свое желание «поко́дить». Это поможет устоять перед искушением взяться за задачи по программированию, бросив на произвол судьбы что-то более важное.

Как вы относитесь к отложенному вознаграждению?

В программировании цикл обратной связи достаточно короткий: каждая успешная компиляция или запуск тестов говорят о том, как идут дела. Это успокаивает. Как будто у вас каждый день маленькое перформанс ревью. Но работа, которая не имеет никаких встроенных циклов обратной связи, способных подтвердить, что вы на верном пути, может демотивировать.

Если проект долгосрочный или охватывает несколько подразделений организации либо вносит изменения в бизнес-стратегию компании или ее корпоративную культуру, то четкий ответ на вопрос, работает ли ваша идея, может идти к вам несколько месяцев или даже дольше. Если на проектах с длинным циклом обратной связи вы чувствуете себя некомфортно, то попросите менеджера, которому вы доверяете, честно и регулярно рассказывать, как идут дела. Если вам нужна обратная связь, но получить ее невозможно, то обратите внимание на проекты с более короткими временны́ми рамками.

Являетесь ли вы менеджером и разработчиком одновременно?

У большинства стафф-разработчиков нет подчиненных, но у некоторых есть. Техлид (tech lead manager, TLM), иногда его называют тимлид (team lead), – это некая гибридная роль, когда стафф-разработчик является техническим лидером команды и одновременно управляет ею как менеджер. Как известно, это сложно (https://oreil.ly/uRrBq, https://oreil.ly/8eFBM, https://oreil.ly/8S4vR). Трудно одновременно отвечать и за людей, и за технические результаты, потому что часто возникает чувство, будто вы где-то что-то недоглядели. Также сложно найти время на совместное развитие обоих навыков; я даже слышала, что из-за этого техлиды жалуются на отсутствие карьерного роста.

Некоторые работают менеджером пару лет, потом переходят на должность стафф-разработчика, потом снова возвращаются на позицию менеджера и т. д. Такая смена должностей позволяет оттачивать оба навыка.²¹ В главе 9 мы подробнее рассмотрим такой «маятник» и роль техлида.

К какому архетипу вы относитесь?

Уилл Ларсон (Will Larson) в своей статье «Staff Archetypes» (https://oreil.ly/cYVGl) описывает четыре ярких архетипа стафф-разработчиков. Вы можете определить, к какому архетипу относитесь или хотели бы относиться.

Техлид

Вместе с менеджером руководит работой одной или нескольких команд.

Архитектор

Отвечает за качество и техническое направление самой важной области.

Решатель

Решает по одной сложной проблеме за раз.

Правая рука

Увеличивает лидерские ресурсы организации.

Если ни один из этих архетипов вам не подходит или ваша роль сочетает в себе несколько архетипов, – это нормально! Архетипы не являются обязательными; они помогают понять, как мы предпочитаем работать.

Какова ваша главная цель?

Мы обсудили ваше место в должностной иерархии и сферу ответственности: где вы находитесь в структуре организации и за что отвечаете. Мы также рассмотрели ваши предпочтения: в каком стиле вы любите работать и какие навыки вас привлекают. Но даже если вы разобрались с этим и четко представляете, какова ваша роль в компании, остается еще один вопрос: над чем вы собираетесь работать?

По мере роста вашего влияния в организации люди будут нуждаться в вас все больше и больше. Кто-то собрал в одном документе лучшие практики код-ревью и хочет узнать ваше мнение. Группа нанимает сотрудников, и ей нужно помочь составить вопросы для собеседования. Против некоторых предложений нашлись возражения, и нужна поддержка стафф-разработчика. И это только утро понедельника. Что вам делать?

Иногда ваш менеджер или его начальник явно указывают, на чем вам нужно сосредоточиться; может быть, вас даже наняли специально, чтобы решить какую-то конкретную задачу. Однако бо́льшую часть времени вы будете самостоятельно выбирать, что именно важно сделать в первую очередь. Каждый раз, когда вы определяете, над чем работать, вы также думаете над тем, что отложить, поэтому не спешите и тщательно проанализируйте, какие проблемы вы возьмете на себя.

Что действительно важно?

Представьте, что вы находитесь в начале своей карьеры и нашли решение сложнейшей задачи, которое впоследствии оказалось ненужным; однако это не уменьшит ценность достигнутого вами результата. Но на уровне стафф-разработчика все, что вы делаете, имеет высокие «издержки упущенных возможностей», поэтому вы должны делать только важное.

Давайте разберемся. Под «важной работой» я понимаю не новомодные и привлекательные технологии или инициативы вице-президента. Обычно самая важная работа – это та, которая никому не видна. Возможно, будет трудно даже объяснить ее необходимость, потому что у ваших команд еще не выработаны соответствующие ментальные модели. В разработке ПО есть много неприятных задач, например: собрать недостающую информацию, исследовать код, покрытый слоем пыли, изучить документы, к которым десятилетиями никто не прикасался. Как видите, важная работа бывает разной.

Выясните, действительно ли задача, над которой вы работаете, является стратегически значимой, и если это не так, займитесь чем-то другим.

Что требует вашего участия?

Бывает и противоположная ситуация, когда старшие специалисты занимаются задачами по программированию, с которыми может справиться любой мидл-разработчик. Вы собираетесь блеснуть своим мастерством, но, вероятно, есть работа вашего уровня, с которой мидл-разработчик не справится. Я приведу поговорку, которую однажды глубокомысленно изрек мой ребенок: «Не во что будет водички налить, ежели в бочку траву посадить».

Старайтесь не участвовать в проектах, в которых и так задействовано много старших сотрудников. Выясните, кто еще бьется над этой проблемой и есть ли у них шансы на успех. Иногда работа может даже замедлиться, если к ней подключить дополнительных лидеров.²² В общем, если людей, выступающих в роли «мудрого разума», больше, чем тех, кто реально пишет код (или что там надо), то вам там делать нечего. Постарайтесь выбрать задачу, которая действительно требует вашего внимания и которой оно пойдет на пользу. В главе 4 я поделюсь тем, какие приемы использую, чтобы определить, надо ли мне участвовать в проекте.

Согласовываем вашу роль с коллегами

На данный момент у вас должно сложиться довольно четкое представление о том, какова ваша сфера ответственности, что входит в круг ваших обязанностей и какие текущие задачи вы решаете. Но как вы думаете, совпадает ли ваше представление о собственной роли в компании с мнением других людей? Ваш начальник и ваши коллеги могут совсем иначе понимать, кто такой стафф-разработчик и какие решения он может принимать, и по-другому (не так, как вы) отвечать на мириады других ключевых вопросов, связанных с этой ролью. Если вы устраиваетесь на должность стафф-разработчика, то лучше прояснить все это заранее.

Мой друг Циан Синнотт (Cian Synnott) научил меня одной технике: запишите на бумаге, в чем, по вашему мнению, заключается ваша работа, и покажите эти записи начальнику. Возможно, вам будет немного страшно отвечать на вопрос, что вы делаете в компании. А что, если люди думают, что ваша работа бесполезна или что вы с ней не справляетесь? Но записывая, вы устраняете неопределенность своего положения. Вы быстро (даже быстрее, чем на перформанс ревью) поймете, совпадают ли ваши взгляды на собственную роль в компании с мнением остальных сотрудников.

Вот пример подобного описания роли для стафф-разработчика по имени Али. Его архетип – «архитектор», он выбирает подход «в ширину», и он назначен (не в качестве руководителя) на крупный проект, затрагивающий несколько команд.

В чем заключается моя работа?

Обзор

В этом документе изложен план моей работы на следующий год. Моя главная цель – улучшить результаты группы розничных продаж технического отдела. Примерно половину своего времени я собираюсь посвятить техническим вопросам, приблизительно 30 % времени – развитию проекта NewMerchandising, а остальное время хочу распределить между работой с людьми (собеседования, инструктирование сеньор-разработчиков) и инициативами, касающимися работы всей организации (группа разработки API, обзоры архитектуры). Я ожидаю, что в рамках ротации руководителей на случай инцидента я буду дежурить на телефоне 1 неделю из 10.

Цели

1. Улучшить результаты группы розничных продаж путем урегулирования технических вопросов, учитывая цели компании и контролируя риски.

2. Способствовать продвижению проекта NewMerchandising, выступая в роли помощника и консультанта. Выявлять угрожающие целям проекта риски и пробелы в технических методиках.

3. Вести обзоры архитектуры для команд в группе розничных продаж технического отдела.

4. Улучшать планирование технического отдела, участвуя в обзорах архитектуры для других продающих команд.

5. Оказывать дополнительную лидерскую поддержку, когда это необходимо, например, во время инцидентов и конфликтов.

Примеры деятельности

1. Предложить цели и ключевые результаты (Objectives and key results, OKR), которые учитывают риски и возможности группы розничных продаж.

2. Достичь общего понимания целей и результатов проекта NewMerchandising, обеспечить слаженность действий команд.

3. Консультировать по архитектуре все команды организации. Рекомендовать архитектурные подходы, быть контрибьютором (но не основным автором) рабочих предложений (Request for Comments, RFC).

4. Инструктировать/обучать сеньор-разработчиков.

5. Проводить собеседования кандидатов на должность сеньор– или стафф-разработчика.

Критерии успеха

1. Группа розничных продаж разрабатывает системы, которые будут масштабироваться следующие пять лет.

2. Проект NewMerchandising стабильно развивается, все его четыре команды одинаково понимают цели проекта.

Не зацикливайтесь на том, чтобы сделать все идеально; сделайте достаточно хорошо. Если вы записали свои цели на бумаге, это не значит, что вам нельзя отклониться от плана. Тем не менее записи напомнят вам, что вы собирались сделать, и помогут контролировать, делаете ли вы то, что должны.

Фокус вашего внимания может сместиться раньше, чем вы ожидали. Если изменилась ситуация в мире или поменялись ваши приоритеты, то перепишите свои цели с учетом новой информации. Четко сформулируйте собственные ожидания от своей работы, и тогда недопонимания в команде удастся избежать.

Это моя работа?

Вы должны делать то, что приведет вашу компанию к успеху. Вы можете быть экспертом в области технологий, программирования или тесно работать с командой, перед которой поставлены нетривиальные задачи, но в конечном счете вы должны помогать организации достигать ее целей. Старшие сотрудники делают много работы, которая не прописана в их должностной инструкции. Они даже могут делать то, что не написано вообще ни в одной инструкции! Но если это даст положительный результат, значит, это надо сделать.

Мои коллеги из Squarespace часто рассказывают историю, как в 2012 году в их дата-центре отключили электричество, и чтобы поддерживать оборудование в рабочем состоянии, они носили топливо на 17 этажей вверх (https://oreil.ly/6TZ2Q). «Таскание бочек с соляркой» не прописано нигде, но это было необходимо для поддержания работы сайта (и он действительно работал!). Год назад я работала в ISP, там затопило серверную, и чтобы вода не поднялась слишком высоко, мне пришлось построить дамбу из мусорных баков. В 2005 году задерживался один из проектов Google, нам не хватало системных администраторов, и я пару дней устанавливала серверы в дата-центре в Сан-Хосе. Вы делаете то, что нужно, чтобы проект состоялся.

Конечно, под выражением «это не моя работа» обычно подразумевают менее драматичные события. Например, провести десятки обсуждений, чтобы разблокировать проект, от которого зависит ваша команда, или помочь новому разработчику, который совсем запутался в своей задаче. Но я повторю: в конечном итоге ваша работа – сделать то, что нужно вашей компании или организации. Как понять, что именно нужно, я расскажу в следующей главе.

Итоги

• Роль стафф-разработчика неоднозначна по определению. Вам предстоит самим разобраться, в чем она заключается и что она для вас значит.

• Может, вы и не менеджер, но вы точно лидер.

• Кроме этого, вы должны обладать обширными техническими знаниями и большим профессиональным опытом.

• Четко определите сферу своей ответственности: за что вы отвечаете и какие вопросы решаете.

• Ресурсы времени не безграничны. Осознанно выбирайте главную цель; она должна быть важной, а вы не должны растрачивать свое мастерство впустую.

• Согласуйте свои действия с руководителем. Расскажите ему, в чем, по вашему мнению, заключается ваша работа, узнайте, чего он от вас ожидает, поймите, что ценно и по-настоящему полезно, четко сформулируйте свои ожидания. Помните, что не всем компаниям требуется полный перечень функций, которые может взять на себя стафф-разработчик.

• Иногда вы будете делать несвойственную для вашей должности работу, и это нормально.

Глава 2. Три карты

Стафф-разработчик должен обладать панорамным мышлением. Если вы урегулируете инцидент, проводите совещание или консультируете коллегу, то вам нужна дополнительная информация о том, с кем вы работаете и как высоки ставки. Когда вы предлагаете решение или продвигаете проект, вы должны понимать бизнес-процессы вашей организации и предвидеть возможные трудности. К тому же, чтобы правильно выбирать задачи, над которыми вы будете работать, вы должны выйти за пределы ежедневной рутины и понять, куда движется компания в целом.

В главе 1 мы в общих чертах рассмотрели, кто такие стафф-разработчики и почему они нужны компаниям. Мы определили несколько аксиом, которые помогли понять специфику должностей уровня стафф, а затем я предложила вам выяснить особенности вашей собственной роли: место в структуре должностей, сферу ответственности, предпочтения в работе и текущую главную цель. Если раньше у вас не было понимания, в чем заключаются ваши обязанности, то, надеюсь, теперь оно появилось. Но если вы когда-нибудь ездили в незнакомый город и пытались сориентироваться в нем, то вы понимаете, что узнать свое местоположение – это только первый этап. Чтобы не заблудиться, вам нужно также понять, что вас окружает.

Хм… У кого-нибудь есть карта?

В этой главе мы нарисуем несколько карт, чтобы получить панорамную картину вашей работы и организации в целом. Обычно для разных целей люди используют разные карты: скорее всего, вы не станете отмечать высоты, избирательные округа и станции метро на одном листе. Мы тоже не будем перегружать одну карту всей имеющейся информацией, иначе она станет нечитаемой. Вместо одной мы составим три. Они не дадут вам ответов на все вопросы, но помогут понять, как работает ваша компания и каковы ваши цели.

Вы можете просто представить эти карты в уме как метафору, чтобы поразмышлять о вашей организации, или действительно нарисовать их на бумаге. Будет полезно (и весело) объединиться с коллегами и сравнить ваши рисунки: посмотреть, какие достопримечательности и формы ландшафта не совпали.

Вот три карты, которые мы получим в итоге:

Карта местоположения: где вы находитесь

Для начала давайте определим, образно говоря, ваше местоположение на карте компании. В предыдущей главе мы немного поговорили о сфере ответственности, но чтобы по-настоящему ее осмыслить, вам нужно сравнить ее с другими. Что расположено вдоль границ зоны вашего влияния? Уменьшите масштаб и посмотрите, насколько велика ваша часть на карте по сравнению с остальным окружением. Это похоже на карту, которую новостные каналы помещают позади диктора, чтобы напомнить вам, где находится то или иное место, и вписать его в контекст новостей.

Вам будет сложно объективно оценить значимость своей работы для бизнеса в целом, пока вы глубоко в нее погружены. Если вы не научитесь рассматривать свою работу в контексте целей всей компании, то решения и возражения вашей локальной группы будут казаться вам более важными, чем они есть на самом деле. Мы попробуем несколько техник, которые помогут сохранить необходимую беспристрастность. Таким образом вы сможете честно рассудить, какие из проектов, находящихся в вашем ведении, действительно значимы для всей организации, а какие легко затеряются на ее огромной карте.

Топографическая карта: обозначаем препятствия

Вторая карта поможет подготовиться к трудностям предстоящего путешествия. Если, отправляясь в поход по какой-то местности, вы будете точно знать, что там впереди, то вы затратите меньше времени и сил, чтобы достичь пункта назначения. В этом разделе мы рассмотрим опасности, которые могут вам встретиться: каньоны глубоких разногласий и бездонные пропасти между разными мнениями, неожиданные политические препятствия, о которых никто и подумать не мог, и люди с трудным характером, которых все стараются избегать. Если впереди зыбучие пески, логова гигантских чудовищ или непреодолимые пустыни, заваленные выгоревшими на солнце скелетами других путешественников, то, отправляясь в дорогу, вы, скорее всего, захотите отметить все это на карте.

На местности могут быть и проторенные дорожки, позволяющие избежать трудностей и препятствий предстоящего пути. Чтобы обнаружить эти тропинки, вам нужно постичь «индивидуальность» вашей организации: как предпочитают работать ее ключевые фигуры, как принимаются решения и как выглядит ее официальная и «теневая» структура.

Карта сокровищ: место X

На третьей карте мы отметим пункт назначения и несколько ориентиров, чтобы добраться до цели, укажем направление движения и места привалов. Путешествие может быть опасным, но если у вас есть карта, то вам будет понятно, приближаетесь ли вы к точке, обозначенной жирной красной меткой Х.

Чтобы составить такую карту, нужно заглянуть далеко вперед и определить цели вашей работы. Является ли каждый проект ценным сам по себе или это просто очередной шаг на пути к долгосрочной цели? Вы можете вдруг обнаружить, что у вашего путешествия нет конечного пункта или что их несколько и они на разных континентах. Если никто не объяснил, где спрятан заветный клад, или у всех разное мнение о том, как до него добраться, то стафф-разработчик может сильно повлиять на ход экспедиции: он может создать новую концепцию или стратегию, принять необходимые решения или даже нарисовать для компании совершенно новую карту сокровищ. Но я забегаю вперед. Пока мы хотим увидеть реально существующую картину. Создание новой карты мы рассмотрим в главе 3.

Разведываем обстановку

Карты, перечисленные выше, уже есть у компании, они просто скрыты от ваших глаз. Когда вы приходите в новую организацию, большая часть специфики ее работы вам абсолютно неизвестна. Осваиваться на новом месте вы начнете с определения контекста, то есть изучите, как работает бизнес, и проясните задачи каждого сотрудника. Это похоже на разведку обстановки на поле боя в видеоигре (https://oreil.ly/P6S9K): вы не можете знать, что ждет вас там, где вы еще не были. Как только вы изучите местность, обстановка прояснится, и вы поймете, что вас окружает и есть ли рядом волки, которые досаждают местным жителям. Вы можете использовать все три карты для успешной разведки, а потом донести полученную информацию до остальных сотрудников. Например:

• Карта местоположения поможет разобраться, действительно ли команды, с которыми вы работаете, понимают, что они должны делать, кто их клиенты и как их работа влияет на других людей.

• Топографическая карта поможет выявить разногласия и недопонимания между командами и наладить коммуникацию.

• Карта сокровищ поможет понять, знают ли участники процесса, чего они пытаются достичь и зачем это нужно.

Какие-то обстоятельства вам откроются в ходе ежедневного наблюдения, а какие-то придется выяснять. Ключевая мысль этой главы состоит в том, что важно все знать: иметь исчерпывающий контекст и полное представление о том, что происходит вокруг. Познание требует исследовательских навыков и немного везения, и скорее всего, вам придется потрудиться, прежде чем вы научитесь видеть то, чего раньше не видели.

Давайте начнем с навыков. В пандемию я провела несколько месяцев в ирландской деревне и много гуляла на природе с друзьями, которые давно там живут. Сначала я думала, что вижу все, что можно увидеть: цветки наперстянки или дубы, то есть все яркое и красивое. Но мои друзья замечали больше. Однажды они остановились около лужи грязи, на которую я даже не взглянула, и показали мне след сосновой куницы. Они собирали листочки, которые я приняла за обычную траву, и объяснили, что они вкусные и островатые, – сокровище для любителей полакомиться дикоросами. Даже дети заметили цветочки и нырнули в заросли земляники, а я прошла мимо. Почему они видят все это, а я нет? Потому что они умеют обращать внимание на детали и знают, что они ищут.

Обращать внимание на детали – значит неустанно собирать сведения, которые затрагивают ваши проекты или организацию, постоянно отфильтровывать полезную информацию от окружающего шума. Тренируйте мозг давать вам сигнал «это интересно!» и запоминать факты, которые могут понадобиться в будущем, и вы научитесь дополнять общие представления важными деталями и создавать новые знания.

Какую информацию можно считать полезной? Ту, которая помогает вам или другим сотрудникам определять контекст вашей деятельности, управлять бизнес-процессами компании или продвигаться в сторону ее целей. Вот несколько примеров.

• Презентация предстоящей маркетинговой кампании может подсказать, что вас ждет огромный всплеск трафика, к которому вы не готовы.

• Директор просит вас взять проект, на который у вас нет времени, но вы знаете сеньор-разработчиков, которые будут рады возможности отточить на нем свои навыки.

• Если корпоративные приоритеты поменялись, то, возможно, платформа, которую вы рассматривали ранее, но отклонили, теперь станет отличным вариантом.

• Соединение с базой данных внезапно оборвалось, но вы вспомнили, что недавно получили электронное письмо о техническом обслуживании сети.

Через некоторое время вы разберетесь в том, какова система информирования в вашей организации и на что стоит обращать внимание. Вы поймете, какие электронные письма нужно читать и на какие совещания нужно ходить. Если вы по своей природе плохо запоминаете подобную информацию, постарайтесь выработать привычку обращать на нее внимание и просто начните записывать факты, которые могут быть полезны в будущем. Представьте себе, что определение контекста – это еще один навык, который вам нужно развить для успешной работы.

Но научиться замечать детали – это только первый шаг. Внимательность не поможет, если вы не вправе принимать решения и вас не приглашают на обсуждения проблем, которые касаются вашей работы. Даже если на вас каждый день льется целый поток совещаний, электронных писем и досадных сообщений с меткой @here в Slack,²³ есть много другой информации, которую вы не сможете запросить, если не знаете, что она у организации имеется. В этой главе я поделюсь некоторыми способами попасть «в комнату, где происходит все самое интересное».

Карта местоположения: всестороннее осмысление

Чем выше ваше положение в компании, тем сильнее ваш успех зависит от умения рассматривать свою деятельность как часть бизнес-процессов всей компании и от осознания того, что на ваше мнение сильно влияет занимаемая вами должность. (Кажется, на рис. 2.1 выбрана слишком удаленная точка для снимка.)

Конечно, у людей, с которыми вы работаете, тоже есть своя точка зрения: их отметка «я здесь» расположена в другом месте воображаемой карты. Чтобы принимать взвешенные решения, нужно научиться анализировать проблему с разных сторон.

Рис. 2.1. Карта местоположения галактики Млечный Путь (настоящая фотография Млечного Пути, автор Жан Бофор (Jean Beaufort, СС0))¹

Чем дольше вы увлечены какой-то областью знаний, тем лучше разбираетесь во всех ее нюансах и тем разнообразнее и сложнее вам кажутся ее проблемы. Чем больше узнаете людей, которые в ней работают, и цели, к которым они идут, тем сильнее вы фокусируетесь на своей специальности. Такая концентрация приносит глубину понимания предмета, но также сопровождается некоторыми рисками, особенно для стафф-разработчика.

Давайте разберем некоторые из них.

Неверные приоритеты

Если все вокруг вас занимаются одним делом, то его значимость легко преувеличить. Задачи, которые находятся вне вашей группы, могут показаться простыми и незначительными. Вот почему команды часто принимают решения по принципу локального максимума, о котором я говорила в главе 1: приоритет собственной работы представляется им более высоким. Чем дольше вы занимаетесь проблемами, которые поставлены перед вашей группой, тем больше вам кажется, что они особенны и уникальны, а также достойны особенных и уникальных решений. Иногда так и есть! Но проблемы, с которыми еще никто ни разу не сталкивался, встречаются крайне редко. Проверьте, может быть, решение уже найдено, и вы не потратите время на изобретение велосипеда.

Потеря эмпатии

Очень легко перестараться и забыть, что существуют другие науки и дисциплины, и прийти к мысли, будто остальные технологические области слишком тривиальны по сравнению с вашей, так богато раскрашенной нюансами. Это все равно что смотреть на мир через объектив «рыбий глаз», который увеличивает все, что находится рядом с вами, и уменьшает то, что находится на периферии. Вы можете потерять уважение к работе, которую делают другие команды: «Их задача слишком простая. Я бы решил ее за выходные».

Слова, которые вы используете, и тезисы, которые вы решили разъяснить, а не оставить при себе, и мотивация, которую вы приписываете другим людям, – все они зависят от вашей профессиональной деятельности. Вот почему разработчикам иногда так трудно общаться с «не технарями». На рис. 2.2 показана знакомая ситуация: как легко приписать другим людям, далеким от вашей профессии, больше знаний о вашей работе, чем у них объективно может быть.

Потеря эмпатии к другим людям также отражается на урегулировании инцидентов, например, команда увлеклась интересными техническими деталями проблемы и забыла, что пользователи ждут, когда система снова заработает.

Рис. 2.2. Очень просто потерять представление о том, что знают другие люди (источник: https://xkcd.com/2501, автор: Рэндалл Манро (Randall Munroe))

Отключение фонового шума

Мы только что рассмотрели случай, когда интересы вашей команды кажутся важнее, чем какие-либо еще, но есть и другая, абсолютно противоположная ситуация: вы вообще перестаете замечать проблемы! Представьте, что вы несколько месяцев работаете над запутанным конфигурационным файлом или сломанным процессом развертывания системы, и за это время вы так привыкаете к своей задаче, что перестаете воспринимать ее как проблему. Аналогично, вы можете не заметить, как то, что поначалу требовало лишь небольшой корректировки, постепенно стало намного хуже. Может быть, проблема вот-вот станет критической, но вы ее больше не замечаете, а значит, не можете объективно оценить, как быстро нужно действовать.²⁴

Утрата цели

Находясь в замкнутом пространстве своих узкопрофессиональных интересов, вы можете потерять связь с тем, что происходит в компании. Ваша группа может взять на себя проект, который служит какой-то общей цели, и продолжать над ним работать, даже если цель потеряла свою актуальность или была достигнута другим способом. Если вы работаете над одной маленькой частью масштабного проекта, то вы легко можете забыть о том, для чего вообще он создавался. Вы можете оказаться в ситуации, когда каждый делает свою небольшую часть общей работы, но никто не чувствует себя ответственным за конечный результат. Также вы можете разочароваться в своей работе, потому что, взглянув на нее со стороны, вдруг обнаружите, что занимаетесь совсем не тем, чем надо.

Панорамный взгляд

Откройте перед собой схему подразделений компании и посмотрите, как ваша группа и другие, с которыми вы сотрудничаете, связаны с остальной организацией. Уменьшая масштаб этой схемы, вы можете обнаружить, что ваша группа выглядит намного меньше, чем вам казалось, а отметка «я здесь» находится дальше от эпицентра событий. Вы не сможете влиять на политику компании, не имея всестороннего представления о происходящем. В этом разделе я покажу еще несколько техник, которые помогут вам увидеть панорамную картину.

Смотрим со стороны

Несколько лет назад я присоединилась к одной инфраструктурной команде в качестве нового сотрудника, и через несколько недель совместной работы мой коллега Марк сказал: «Когда я рассказываю про наши системы, ты делаешь такое лицо…» Я, конечно, думала о том, что пора бы заменить устаревшие системы, но не осознавала, что мое мнение так явственно (и грубо!) читается на моем лице. Прошло два года напряженной работы в этой команде, и архитектура значительно улучшилась. Мы гордились своими результатами. Мне казалось, что мы очень хорошо потрудились! Пока к нам не присоединился новый сотрудник, и… его мнение так же отчетливо прочиталось на его лице. К тому времени я хорошо внедрилась в команду. И понадобился новый «новый сотрудник», который помог взглянуть на проблемы свежим взглядом.

Когда новый сотрудник смотрит на путаницу в архитектуре и вереницу технического долга, у него отсутствует информация о том, почему все так сложилось. Как говорит мой коллега Дан На (Dan Na) (https://oreil.ly/GD8Gz): «Новый сотрудник всегда видит проблемы». Он не присутствовал ни при постепенных изменениях в архитектуре, ни при процессе варки лягушки: он просто увидел результат как есть. Он может посмотреть на проделанную работу непредвзято и спросить: «Что здесь вообще происходит? Это все хотя бы работает?»

Предупреждение

Быть новым сотрудником не значит относиться к другим пренебрежительно. Легко сказать задним числом: «Как это ужасно! Почему нельзя просто…» Будьте скромнее и предположите, что на все есть свои причины. Группа главных разработчиков компании Amazon сделала эту мысль одним из принципов своего сообщества: «Уважайте то, что было до вас» (https://oreil.ly/ 2R4ET).

Посмотреть на ситуацию со стороны легко, пока вы новичок в команде, но стафф-разработчик должен всегда иметь объективную картину процессов в компании. Вы должны уметь смотреть на свою группу, как будто вы не являетесь ее участником, и честно принимать то, что вы видите. Ваши технические решения имеют смысл только для тех, кто забыл, что за пределами офиса существует целый мир? Представьте, что вы и ваши коллеги перестали делать свою работу. Сколько времени пройдет, прежде чем окружающие это заметят? Вы когда-нибудь увлекались технической частью настолько, что забывали об исходной цели? Как обстоят дела? В следующих четырех разделах я покажу вам техники, которые помогут сохранить беспристрастность при оценке результатов собственной команды.

Покидаем эхо-камеру

Если вы столкнулись с эффектом эхо-камеры, когда каждый, кто находится рядом, имеет такое же мнение, как у вас, то скорее всего, вы сильно удивитесь, когда узнаете, что мнения у остальных коллег просто… другие.

Я проработала более десяти лет на невысоких инфраструктурных должностях и была потрясена, когда начала работать с командами разработчиков продукта. Они все делали быстро, брали на себя риски и считали, что программы должны не только стабильно работать, но и нравиться пользователям. Наши споры поколебали мои самые твердые убеждения и добавили в них новые нюансы.

Поиск товарищей в других группах – важная часть вашей работы. Постройте дружеские отношения с другими стафф-разработчиками. Пусть эти отношения станут настолько доброжелательными, чтобы вы могли сказать человеку правду и он не подумал, что вы к нему придираетесь. Анализируйте любое негативное мнение, которое другие команды высказывают о вашей группе: если вы поймете, что их комментарии обоснованны, то сможете работать лучше. Представьте, что другие стафф-разработчики – это ваша команда, такая же, как и любая другая, в которой вы состоите.

Тот же принцип применим и для организаций. На рис. 2.3 и 2.4 я изобразила каждого стафф-разработчика участником одной группы, а каждого принципал-разработчика – участником организации. Структура компании может варьироваться. Ваша цель – стать участником сообщества, которое будет больше, чем ваша команда или группа. Так у вас появится более объективное понимание того, что делают другие люди.

Выйдите за рамки разработки ПО: постройте отношения с людьми, которые занимаются продуктом, техподдержкой, системным администрированием и т. д. Если ваша работа влияет на них или они влияют на вашу работу, будьте дружелюбны и постарайтесь понять их точку зрения. Это кардинально изменит ваше понимание того, что важно для вашего отдела или бизнеса в целом.

Рис. 2.3. Пример компании по разработке ПО. Каждая группа содержит несколько команд. Каждый стафф-разработчик занимается отдельной группой и является частью этой группы, но кроме этого он является частью большой виртуальной «команды» стафф-разработчиков

Рис. 2.4. Несколько технических организаций внутри компании, в каждой из которых есть свой стафф-разработчик. Каждый принципал-разработчик принадлежит своей организации, но также он принадлежит виртуальной команде принципал-разработчиков

Что действительно важно?

Дружеская поддержка «не технарей» важна для достижения объективности в оценке деятельности своей команды еще по одной причине: разработчики легко увлекаются техническими задачами. Но технология – это только способ достижения результата. А ваша задача – помочь работодателю достичь его цели. Вы должны знать, что это за цель. Вы должны знать, что действительно важно.

У стартапа совсем иные задачи, чем у технологического гиганта или местной некоммерческой организации. Потребности зрелого и нового продукта различны. Некоторые цели, а следовательно и проекты, могут быть более значимы, чем другие. На рис. 2.5 показано, что проект, который воспринимается вами как центр Вселенной, может оказаться менее значительным, если посмотреть на панорамную картину. Приоритеты постоянно меняются, поэтому выясните, что важно прямо сейчас. Если клиенты уходят, потому что в продукте отсутствует важная функциональность, которая есть у конкурентов, то, вероятно, сейчас не стоит заниматься техническим долгом. А если ваш бизнес стабильно растет и развивается, значит, сейчас самое время проверить прочность фундамента, на котором он построен.

Рис. 2.5. Смотрим на панорамную картину. Обновление, над которым вы работаете, может казаться самой важной задачей, но у людей, которые в курсе всех бизнес-процессов компании, может быть иное мнение

Цели компании шире поставленных задач и метрик и, как правило, включают в себя следующее: «продолжить существовать на рынке», «иметь достаточно средств, чтобы платить зарплату» и «заботиться о репутации». Моя коллега Триш Крэйн (Trish Craine), руководитель технического отдела компании Squarespace, говорит, что такие цели «неизменно актуальны». Они настолько очевидны, что про них говорят, только когда дела совсем плохи. Продукт или сервис, который производит компания, должен работать. Клиенты должны хотеть им пользоваться. Развертывание системы не должно быть мучительно медленным. Помните о неявных целях организации так же хорошо, как и о явных.

СОВЕТ

Со временем приоритеты компании изменятся и актуальные цели снова окажутся скрыты за туманом. Чтобы оставаться в курсе того, что важно, принимайте участие в совещаниях, проводимых совместно с другими группами, запрашивайте личные встречи с начальником вашего начальника, уделяйте время живому общению с клиентами и представителями других команд, с которыми сотрудничаете. Если вы не понимаете, почему ваша работа важна для бизнеса (и важна ли она на самом деле), спросите об этом.

Следите за тем, не изменились ли цели бизнеса, потому что если это произойдет, поменяется и ваша сфера ответственности, и поставленные перед вами задачи. Нестрашно, если ваша работа не самая значимая для компании, главное, чтобы вы не тратили время впустую. Если вы не можете объяснить, почему здесь требуется мастерство стафф-разработчика, то, возможно, вы занимаетесь не тем, чем нужно.

Что волнует ваших пользователей?

Чарити Мэджорс (Charity Majors), CTO компании Honeycomb, постоянно раздает наклейки с надписью (https://oreil.ly/2pxrj): «Девятки не имеют значения, если пользователи недовольны». «Девятки» – это отсылка к целям уровня обслуживания (service level objective, SLO) (https://oreil.ly/9LeCI), общепринятому механизму измерения доступности системы. «Три с половиной девятки доступности» означает, что сервис работал 99,95 % времени. SLO полезны, но Мэджорс отмечает, что они не дают полной картины. Кто определяет, «доступный» или нет?

Мохит Сули (Mohit Suley), технический менеджер и бывший принципал-разработчик компании Microsoft, рассказал о том, как его команда выявляла и восстанавливала связь с нестабильными интернет-провайдерами (https://oreil.ly/Fsj4k), из-за которых поисковая система Bing отключалась. Проблема была не на стороне Bing, но Сули говорит: «Пользователям без разницы, что сломалось: DNS-сервисы, интернет-провайдеры, CDN или ваш компьютер, им все равно. В конце дня половина веб-сайтов работала, а половина – нет». Оценивайте свой успех с точки зрения пользователей. (Даже если они – другие команды вашей компании!) Если вы не понимаете своих клиентов, то вы не сможете определить, что именно важно для вашего предприятия.

Решались ли раньше похожие задачи?

Принцип компании Amazon «уважайте то, что было до вас» (https://oreil.ly/2R4ET) также напоминает нам о том, что «похожие задачи уже решались раньше». Вы найдете более удачные решения, если, прежде чем создавать что-то новое, изучите то, что люди сделали до вас. Помните, что ваша цель – решить проблему, а для этого не всегда нужно писать код. Дайте себе время разобраться, что уже есть по данной теме (у вашей компании или другой), прежде чем что-то изобретать.²⁵

Перспективы отрасли

Изучайте, как другие люди в отрасли решали задачи, над которыми вы сейчас работаете. Ваши предпочтения в публикациях и ресурсах зависят от ваших интересов. Я перечислю ресурсы в области архитектуры, инженерного лидерства и надежности программного обеспечения, которые сама считаю полезными. Мне нравятся конференции LeadDev (https://oreil.ly/P3SYi) и SREcon (https://oreil.ly/S6OYy), я стараюсь посещать их как можно чаще. На конференции LeadDev появилось новое (на момент написания книги) направление, которое называется StaffPlus (https://leaddev.com/staffplus-new-york). Я могу быть необъективной, потому что провожу некоторые из этих мероприятий, но думаю, что они потрясающие!

Из онлайн-чатов мне нравится Rands Leadership Slack (https://oreil.ly/ZheFA): каналы #architecture и #staff-principal-engineering просто золото, а канал #staffplus очень активен во время событий на конференции LeadDev.

Я подписана на ежемесячную рассылку InfoQ Software Architects’ Newsletter (https://oreil.ly/ReBFX), а также на VOID report (https://oreil.ly/wx82Q) и SRE Weekly (https://sreweekly.com). Раз в неделю я читаю Raw Signal newsletter (https://oreil.ly/CwcQp), чтобы узнать, как оценивают ситуацию менеджеры. А также с нетерпением жду ежеквартальные выпуски Thoughtworks Radar (https://oreil.ly/iu0Sy).

В любой технической области есть свои рассылки. Читайте их, чтобы узнавать о перспективных направлениях и находить новые идеи, которые вы можете детально рассмотреть, если они вам понадобятся. Так вы многому научитесь.

Топографическая карта: сложности рельефа

Карта местоположения дает общее представление о ситуации, но по ней нельзя ориентироваться. Вам нужна карта, которая покажет местность.

Геологи изучают тектонику плит, согласно которой огромные куски литосферы Земли постоянно движутся относительно друг друга (рис. 2.6), они образуют горы и впадины, вызывают землетрясения и вулканическую активность. Тектоника команд обладает похожими свойствами. Зоны ответственности сталкиваются друг с другом и формируют ландшафт организации, где множество хребтов и оврагов, накладок и конфликтов.

Реорганизация в компании может нарушить коммуникацию между группами, которые должны тесно сотрудничать друг с другом. Сильно загруженные команды могут возводить и укреплять баррикады. Новый начальник может вызвать землетрясение, которое в одночасье изменит весь ландшафт. Чтобы ориентироваться в организации, вам нужна топографическая карта (рис. 2.7).

Рис. 2.6. Упрощенная карта основных тектонических плит Земли (взято из материалов Скотта Нэша (Scott Nash), общественное достояние, https://oreil.ly/UdeNz)

Рис. 2.7. Стафф-разработчик ориентируется на местности, полной неприятных сюрпризов

Пересеченная местность

Давайте рассмотрим некоторые трудности, с которыми вы можете столкнуться, если отправились в поход без детальной карты местности.

Ваши идеи прекрасны, но их никто не поддерживает

Ваша правота в вопросе о необходимости перемен – это лишь полдела. Вы должны не только убедить других в своей правоте, но и (что еще сложнее) склонить их отстаивать вашу позицию. Вы должны уметь «зажечь» людей своей идеей: выясните, кто может поддержать вас или рассказать другим о ваших планах, а также найдите способы довести их до конца и сделать реальностью.

Вы узнаете о трудностях, только когда с ними сталкиваетесь

Во многих на первый взгляд банальных путешествиях к поставленной цели есть какое-нибудь значительное препятствие, которое никто не знает, как преодолеть. Возможно, вам придется взобраться на скалу, не покорившуюся многим другим. Стафф-разработчики умеют преодолевать преграды, непосильные для менее опытных инженеров, и, возможно, вы достигнете успеха там, где другие не справились. Но если вы заранее знаете, где тупик, то сможете выбрать обходной маршрут; или же сначала решить самую сложную задачу, и тогда другие сотрудники убедятся, что проект стоит их усилий.

Путешествие затягивается

Если вы не знаете специфики работы вашей компании, то даже самые простые решения могут занимать месяцы или кварталы. Циклы планирования организации влияют и на вас. Вы должны знать, когда легче обосновать необходимость укомплектования штата для нового проекта или сплотить всех вокруг какой-то цели. Если вы объявите новую инициативу сразу после утверждения квартальных технических OKR, то вы столкнетесь с жестким противодействием и, возможно, вам придется ждать целый квартал, прежде чем ваше дело сдвинется с места.

Особенности организации

Иногда программисты рассматривают организационные навыки как «политику» и не придают им значения, но эти навыки играют важную роль в процессе разработки. Вы должны учитывать мнения людей, которые имеют отношение к вашему продукту, уметь ясно излагать задачу, которую вы решаете, понимать долгосрочные последствия ваших действий и находить компромисс в отношении приоритетов. Если вы не разберетесь в особенностях своей организации, то любые изменения будут даваться вам гораздо труднее.

В этом разделе я расскажу, как выяснить эти особенности и изучить ландшафт компании. Мы начнем с оценки некоторых аспектов корпоративной культуры: какие процессы принято документировать, есть ли доверие между сотрудниками, стремятся ли люди к изменениям или откладывают их, от кого исходит инициатива. Благодаря этим знаниям вы сможете приблизительно оценить продолжительность путешествия: насколько легко вам будет продвигаться к цели? Затем мы рассмотрим некоторые препятствия и обходные тропы, которые нанесем на вашу топографическую карту.

Корпоративная культура

На собеседованиях кандидаты часто просят меня рассказать о корпоративной культуре компании. Раньше мне было трудно им ответить; я даже не понимала с чего начать. О корпоративной культуре написаны целые тома. Но думаю, на самом деле людей интересуют следующие вопросы:

• Я смогу принимать самостоятельные решения?

• Буду ли я частью сплоченной команды?

• Что, если я ошибусь?

• С моим мнением будут считаться?

• Проекты легко реализуются или подолгу стоят на одном месте?

• А коллектив… хороший?

Ответы на эти вопросы определяет не только организационная культура компании, но и отдельные люди и руководство. Каждая организация обладает собственной «индивидуальностью», поэтому мы поговорим о культуре.

Если вы прочитаете положение о ценностях и принципах компании, то сможете понять, что важнее всего для ее руководства. Но эти ценности предназначены для мотивации сотрудников, настоящие же отражаются в том, что каждый день происходит в реальной работе организации.

Далее я приведу несколько вопросов, которые помогут лучше понять инженерную культуру компании. Вы можете обдумать их сами или обсудить с коллегами. У большинства этих вопросов нет правильного или неправильного ответа. В компании, которая постоянно мечется из стороны в сторону, впадая в крайности, работать непросто, но зато между этими крайними точками больше пространства для успешных маневров.

Секретно или в открытом доступе? Много ли знает каждый сотрудник? В закрытых организациях информация – это валюта, которой никто не делится просто так. Календари сотрудников скрыты. В каналы Slack можно войти только по приглашению. Возможно, если вы попросите, то вам дадут доступ к необходимым документам, но чтобы попросить, вы должны знать, что они существуют! Если сотрудникам информация предоставляется в строго регламентированном объеме, то придумать нестандартное решение или по-настоящему разобраться в проблеме будет нелегко.

В открытых организациях у вас есть доступ к любой информации (даже к запутанным первым наброскам!). Не исключено, что вы устанете отсортировывать важное от второстепенного. Вы можете не понимать, какие документы уже согласованы и требуют исполнения, а какие находятся на уровне сырых идей. Чрезмерная открытость информации может вызвать еще больше напряжения: плохие проекты сложнее прикрыть втихую.

Понимать правила распространения информации в компании крайне важно. Если организация хранит знания под замком, а вы раскроете конфиденциальные сведения, то вы потеряете доверие своего босса. В более открытых компаниях, если вы утаите информацию или не позаботитесь о ее распространении, вас сочтут недостойным доверия интриганом.

Устно или письменно? Какие задачи решаются устно, а для каких нужна письменная документация? Как много письменной работы и ревью требуется для принятия решений? В некоторых компаниях важное решение могут принять во время разговора в коридоре, или вы можете узнать о том, что ваш коллега разработал сложную функциональность, уже после запуска проекта (или когда вас вызовут, чтобы показать ее). В других организациях каждое изменение в ПО сопровождается официальной спецификацией, требованиями, подписями и листами согласования. В такой организации изменение в одной строке кода может занять целый квартал.

К счастью, большинство компаний избегают крайностей. Если ваша компания предпочитает короткие обсуждения, то скорее всего, вам не дадут тратить время на запись решения, а дизайн-документ длиною больше одной страницы никто не станет читать. Крупные и зрелые компании, как правило, более обдуманно подходят к принятию решений. Если вы работаете в такой организации и не создали дизайн-документ или заявку на внесение изменений, то вас сочтут небрежным и безответственным. Мне довелось работать в команде, у которой была традиция класть ковбойскую шляпу на стол сотрудника, который сделал что-то «в духе Дикого Запада». Конечно, это была шутливая традиция, но она все же служила хорошим напоминанием.

«Снизу вверх» или «сверху вниз»? Откуда исходят инициативы? Модель «снизу вверх» подразумевает, что сотрудники и команды уполномочены делать выбор самостоятельно и защищать идеи, которые они считают важными. Однако если инициативы требуют более широкой поддержки, их продвижение замедляется. Команда может быть не согласна с решением или расставленными приоритетами; в таком случае без человека, ответственного за все дело, инициатива может вообще заблокироваться.

Если модель – «сверху вниз», то намного проще выбирать идеи и предпринимать решительные действия. Однако решения будут не самыми лучшими, потому что они упускают локальную специфику. Разработчики, скорее всего, почувствуют, что их контролируют, и у них не будет полномочий реагировать на проблемы сразу после их возникновения.

Стафф+ разработчики должны иметь достаточно самостоятельности и свободы в расстановке приоритетов, но убедитесь, что организация одобряет такой стиль: если менеджер ожидает, что вы будете согласовывать с ним свои задачи, то вы можете спровоцировать конфликт, если не отчитаетесь перед ним. Если вы привыкли спрашивать разрешения или получать указания, то в компании с моделью «снизу вверх» вы можете показаться малоинициативным, и возможно, вам будет трудно доводить дела до конца.

Если вы поймете, как работает организация, то сможете решить, стоит ли сначала донести свои идеи до коллег-практиков и заручиться их поддержкой или же надо пойти к своему директору.

Быстро или медленно? Молодые компании склонны быстро принимать решения и делать крутые повороты, чтобы попробовать новые возможности. Чем крупнее и старше становится компания, тем больше времени у нее уходит на изменение курса. «Быстрые» организации могут отказаться от долгосрочных проектов, например двухлетнего перехода на новую платформу, «медленные» же могут упустить хорошие возможности для совершенствования.

Преподносить свои инициативы нужно по-разному в зависимости от типа компании. Если решения принимаются молниеносно, то скорее всего, достаточно просто продемонстрировать ценность идеи. В компаниях, в которых принято дольше обдумывать решения, вам придется показать, что вы детально проработали весь план. Два этих стиля принятия решений тесно связаны с объемом письменной работы.

Неформально или официально? Как люди из разных групп общаются друг с другом? Может быть, сложившаяся в компании социальная культура добавляет к официальным способам получения информации и отправки запросов какие-то неформальные каналы. В дружной команде люди задают вопросы в личных сообщениях и делятся идеями за кофе.²⁶

В некоторых компаниях разработчик может запросто переписываться с коллегой из другой группы, поэтому решения, которые затрагивают обе команды, будут приниматься быстрее. В других компаниях выполнить свою работу можно, только если вы неформально общаетесь с кем-то из команды. В третьих компаниях принято создавать запрос в системе управления задачами и ждать, когда на него ответят, или отправлять предложение о сотрудничестве вверх по цепочке подчинения, пока оно не дойдет до менеджера, который отвечает за обе команды; в таких случаях решения будут приниматься дольше, но также эти решения будут более прозрачными и предсказуемыми.

Разберитесь, как это принято в вашей организации. Если все строго следят за тем, чтобы пользоваться только официальными каналами, то будет невежливо задавать вопросы вне очереди, и люди могут плохо о вас отзываться из-за того, что вы нарушаете порядок. Если для решения задач обычно используются неофициальные каналы, то вы можете месяц ждать официального ответа, хотя могли бы просто написать человеку, который любовался фотографиями ваших кошек в рассылке о домашних животных.

Загружены или свободны? Насколько загружены сотрудники? Если команды недоукомплектованы и люди перерабатывают, то вы не сможете найти поддержку для новых идей, которые не входят в дорожную карту существующего продукта, – всегда проще и быстрее ответить «нет», даже не взглянув на вопрос. Однако любая инициатива, которая поможет освободить время, получит хороший отклик без всяких усилий. Вы, скорее всего, добьетесь успеха, если сможете работать самостоятельно или с небольшой поддержкой, чтобы вам не приходилось упрашивать уйму занятых людей взяться за что-то новое.

Может показаться, что работать с не сильно загруженными командами намного проще, но у них есть своя специфика: если у разработчика мало задач, то это, скорее всего, ненадолго. Если у команды выдалось много свободного времени, то вероятно, скоро произойдет кембрийский взрыв новых инициатив, конкурирующих друг с другом и имеющих небольшое число приверженцев. Вы получите больше пользы, если найдете зарождающийся проект, поможете ему выйти на финишную прямую и убедите других сотрудников сплотиться вокруг него.

Мягко или твердо? Откуда берется власть, статус и репутация? Как вы завоевываете доверие? Некоторые компании, особенно большие и старые, или научные организации имеют четкую иерархию: одна и та же группа людей, в той же конфигурации, поднимается по карьерной лестнице и имеет довольно жесткую структуру коммуникаций, принятия решений и распределения «хороших» проектов. Каждый человек в таких компаниях похож на атом в кристаллической решетке твердого вещества: если люди вокруг вас движутся вверх, вы тоже движетесь вверх. Старшие сотрудники в таких организациях часто говорят, что они никогда не стремились к повышению: они работали на своем месте, им выдавали проект, они получали поддержку от группы, и когда подходила их очередь, их повышали.

Такой тип иерархии – проклятие для маленьких, молодых, амбициозных компаний, которые позиционируют себя как что-то похожее на меритократию. Давайте реалистично посмотрим на вещи (https://ru.wikipedia.org/wiki/Меритократия): успех все еще зависит от того, есть ли у вас покровитель и доступ к ресурсам, поэтому стереотипы, внутригрупповой фаворитизм и другие когнитивные искажения все еще сильно влияют на вашу работу. (См. подробнее на веб-сайте «Is Tech a Meritocracy?» (https://istechameritocracy.com)). В «мягких» компаниях проще подняться в должности, но чтобы продвинуться, вы, скорее всего, должны будете подсуетиться. Вы можете переходить из одной группы в другую, чтобы найти работу, которая принесет максимальную пользу, таким образом вы будет продвигаться по службе в своем собственном темпе. Если вы будете сидеть и ждать, что кто-то даст вам проект, то ждать вам придется долго.

В командах с твердой кристаллической решеткой жизненно важно понимать свое место в иерархии и знать, когда придет ваше время получить проект, который переведет вас на следующий уровень. Захотеть взять на себя проект, который предназначался для продвижения кого-то другого, все равно что покуситься на святая святых: один мой друг попробовал такой сценарий и сказал, что начальник посмотрел на него так, «как будто я вознамерился ограбить церковь».

Посмотрите на диаграмму-слайдер на рис. 2.8 и подумайте, как все семь признаков влияют на работу вашей организации. Если вы попытаетесь изменить корпоративную культуру, то у вас может получиться – с определенными усилиями – подвинуть слайдеры в одну или другую сторону. Если вы знаете, где находятся слайдеры на данный момент, то сможете адаптировать свой стиль работы к сложившимся нормам корпоративной культуры и не наломать дров.

Рис. 2.8. Большинство компаний находятся примерно по центру по каждому из этих признаков

Власть, правила или миссия?

Вот еще один вопрос, значимый для понимания конкретной корпоративной культуры: что руководство компании считает важным? Социолог Рон Веструм (Ron Westrum) в своей работе 2005 года «A Typology of Organisational Cultures» (https://oreil.ly/rtHz5) написал следующее:

Начальники сообщают, что для них важно с помощью таких символических действий, как поощрения и наказания. Далее предпочтения лидеров становятся предметом заботы сотрудников организации, поскольку из этих предпочтений вытекает вознаграждение, наказание и распределение ресурсов. Поощрять будут тех, кто ориентируется на предпочтения лидера, а тех, кто противостоит этим предпочтениям, будут наказывать. Люди, которые уже давно работают в организации, умеют инстинктивно считывать подаваемые сверху сигналы, а те, кто не умеет, скоро научатся, но заплатят за эти уроки высокую цену.

Веструм делит организации и их влияние на информационные потоки на три группы (табл. 2.1):

Патологические

Культура с низким уровнем сотрудничества; ее целью являются власть и статус, а информация хранится в тайне; по словам Веструма, «люди здесь думают только о власти, славе и личных интересах».

Бюрократические

Культура, ориентированная на правила; информация здесь движется по стандартным каналам, а изменения проходят тяжело; как пишет Веструм, «здесь думают только о правилах, положениях и административном делении».

Производительные

Культура, ориентированная на миссию, с высоким уровнем доверия и сотрудничества; информация здесь распространяется свободно; Веструм пишет, что в такой культуре «люди сосредоточены на миссии».

Таблица 2.1. Классификация организаций по Веструму: как организации обрабатывают информацию (Рон Веструм, «A typology of organisational cultures», BMJ Quality & Safety 13, no. 2 (2004), doi: 10.1136/qshc.2003.009522)²⁷

Группа DevOps Research and Assessment (DORA) (которая теперь стала частью сервиса Google Cloud) показала (https://oreil.ly/Epx4s), что компании, культура в которых основана на доверии и которые придают особое значение информационным потокам, чаще поставляют новые версии продукта. Неудивительно, что все больше компаний по разработке ПО стремятся к внедрению у себя принципов генеративной культуры. Они поощряют кооперацию кросс-функциональных команд и экспериментирование, извлекают уроки из разбирательств, никого не обвиняя, принимают просчитанные риски, преодолевают препятствия. Если ваша организация работает подобным образом, то вам будет легче делиться информацией и продвигаться вперед.

Если вы знаете, на что ориентирована ваша компания, будь то власть, правила или миссия, вам будет проще доводить дела до конца. Если вы понимаете, насколько люди готовы делиться информацией, сотрудничать, помогать друг другу, внедрять новые идеи, то во время своего путешествия к цели вы будете чувствовать себя увереннее и спокойнее. Если вы находитесь в бюрократии (https://oreil.ly/4zT4y), то скорее добьетесь успеха, планируя наперед, соблюдая правила и субординацию. Если вы находитесь в патологической организации, то берите на себя как можно меньше рисков и заранее продумайте прикрытие на случай, если ситуация выйдет из-под контроля. Толкать тачку по булыжникам намного сложнее, чем по асфальту. Если вы знаете, что дорога будет ухабистой, заложите больше времени, и скорее всего, вы не расстроитесь, если случится то, что вы не можете контролировать.

Особенности ландшафта

Давайте вернемся к нашей аналогии с топографической картой. Если вы понимаете культуру организации, то сможете примерно оценить, насколько легко или сложно в среднем пройдет путешествие к цели. Но чтобы успешно продвигаться вперед, вам нужно видеть препятствия, трудности и кратчайшие пути. Вот лишь некоторые особенности ландшафта организации.

Пропасти. Тектонические сдвиги в компании могут привести к образованию пропасти между командами. Например, на рис. 2.9 показан каньон, который появился между техническими командами разработчиков, ориентированными на продукт, и командами инфраструктуры, платформы и безопасности, предоставляющими сервисы для них. Культуры групп, их нормы и цели, а также ожидания развивались по-разному, вызывая тектонические разрывы, которые усложняли коммуникацию, принятие решений и урегулирование конфликтов.

Рис. 2.9. Пропасть между инфраструктурным подразделением и подразделением разработки продукта

Небольшие обрывы могут появиться даже внутри структурных подразделений организации. Границы ответственности команд редко идеально совпадают, а значит, часть информации о проекте может застрять в овраге.

Крепости. Крепость – это команда или человек, которые, кажется, намерены мешать всем и каждому на пути к завершению проекта. Может быть, вам нужно согласовать с ними что-то, но они постоянно заняты. Или, например, это «стражи у ворот», которые отметают любую идею без разбора. Несмотря на то что некоторые такие люди ведут себя как тираны, у большинства из них все же благие намерения. Они не распахивают ворота перед новой инициативой, потому что им не все равно. Они стараются сохранить качество кода и архитектуры на высоком уровне и уберечь всех от возможных проблем.

Чтобы пройти за ворота крепости, вам потребуется поручительство от того, кого уважают стражи, или пароль, который опускает подъемный мост. (Обычно в качестве пароля можно предоставить доказательство того, что вы минимизировали все риски предлагаемого изменения, закрыли длинные чек-листы или разумно ответили на огромное количество комментариев в документе.) Но есть еще один вариант – длительное кровопролитное сражение, когда вы бьетесь насмерть за каждое слово и втягиваете все новых людей в конфликт. Такая баталия может закончиться пирровой победой, и вы пожалеете, что вообще ввязались в противостояние. Или вы можете сдаться и обойти крепость длинной окружной дорогой, усложнив свое путешествие и лишив себя возможности выспросить у стражей какие-то секреты.

Спорные территории. Очень сложно разграничить ответственность так, чтобы каждая команда работала автономно. Даже если API, контракты или уставы команд четко прописаны, неизбежно появятся части проекта, на которые одновременно претендуют несколько команд, что вызывает опасные споры.

Однажды я работала на проекте, в котором нужно было перенести на новую платформу критически важную систему. Перенос этой системы составлял меньше 5 % моих задач, поэтому я не хотела тратить на него много времени, но в поисках того, кто может взять эту задачу на себя, я уперлась в стену. За эту систему отвечали сразу три команды – каждая за свой аспект. Никто не мог сказать, безопасно ли переносить систему на другую платформу. Каждая группа отвечала: «Насколько мы знаем, это безопасно, но вы должны еще спросить у них…» и указывала на другую команду. Не было человека, который отвечает за всю систему, и я ходила кругами, пытаясь собрать достаточно контекста, чтобы понять, сработает ли перенос. (Он так и не сработал. Согласовать действия трех команд, чтобы откатить изменения, тоже было затруднительно.)

Если две или более команды вынуждены тесно сотрудничать, то без единого четкого представления, какие именно результаты им нужны, они приведут свои проекты к хаосу. Обе стороны могут вступить в борьбу за то, чьи технические идеи лучше и какие из них надо реализовывать в первую очередь, и тогда недостаток согласованности может привести к серьезному противостоянию и усилия окажутся напрасными. Если зоны ответственности команд пересекаются, то все станет еще хуже: процесс принятия решений усложнится, и сотрудники будут тратить время впустую.

Непреодолимые пустыни. Иногда, пытаясь достичь поставленных целей, вы вступаете в схватку, которая, по мнению других людей, обречена на провал. Это может быть слишком большой проект или запутанная ситуация, связанная с выяснением отношений и переделом сфер влияния, которая всегда заканчивается наложением вето со стороны какого-нибудь очень большого начальника. Что бы то ни было, люди уже пытались преодолеть это раньше и любое предложение пройти это снова встречается с унынием и апатией.

Но это не означает, что не стоит пробовать! Хотя вы должны иметь достаточно доказательств, способных убедить в том, что в этот раз все будет иначе. Хорошо бы заранее знать, не затеваете ли вы заведомо проигрышную борьбу.

Асфальтовые дорожки, кратчайшие и длинные обходные пути. Компании, которые стараются сделать разработку эффективной, часто налаживают работу так, чтобы официальный способ сделать что-то был заведомо и самым простым. Например, чтобы проверить, что новый компонент безопасен и его можно вывести в продакшен, вам нужно отметить все пункты в чек-листе для самоконтроля. Если вам повезло и у вас есть такие простые и четко прописанные пути, узнайте, где они проходят, и пользуйтесь ими.

К несчастью, многие дороги не проторены. Бывает, что долгое время пытаемся решить проблему официальным путем, пока кто-то по секрету не откроет нам обходной путь к успеху: незадокументированную функцию поиска, системного администратора, который может создать вам аккаунт, или человека из ИТ-отдела, который отвечает за личные сообщения. Иногда официальным путем вообще никто не пользуется. На рис. 2.10 показана асфальтовая дорожка, которая не ведет туда, куда людям действительно нужно пройти, и все идут в обход. Если вы не знаете этих тайных троп, то любая задача будет занимать больше времени. Но если вы узнаете о них, команды могут попросить вас не документировать их: они будут настаивать, что люди обязаны пользоваться новой дорогой и что она вот-вот станет лучше.

Рис. 2.10. Новая асфальтовая дорожка великолепна, но к большинству мест, куда людям действительно нужно, приходится пробираться через болота

Интересные места на карте

Что еще должно быть на вашей топографической карте? Есть ли на местности крутые обрывы и можете ли вы их обойти? Есть ли на карте стили общения или поведения, которые кажутся невежливыми в вашей организации, но в другой компании или команде они совершенно нормальны? Есть ли перила и ограждения там, где вы думали их найти? Есть ли зоны вулканической активности или начальники, которые постоянно вызывают землетрясения (или внезапные кадровые перестановки), лишая сотрудников твердой почвы под ногами? Как насчет локальной политики? Какими командами управляют монархи, а какими – консулы? Где царит анархия? Кто с кем воюет?

Попробуйте нарисовать свою карту. Помните, что картография по своей сути политически ангажирована (https://oreil.ly/V5UbQ): то, что вы в нее включаете, говорит что-то и о вас. Обратите внимание на то, что вы поместили в центре и в каких моментах вы склонны принимать чью-то сторону.

Формы ландшафтов организаций могут искажаться в результате реформ, поглощений, действий отдельных людей, иногда просто недолюбливающих друг друга. Если вы столкнулись с препятствиями, подземными туннелями информации или другими особенностями рельефа, о которых я не сказала, я буду рада о них узнать.²⁸

Как принимаются решения?

Интересно наблюдать, как информация и мнения курсируют внутри компании и как в секунду они могут превратиться в грандиозные планы. Внезапно все начинают использовать новую аббревиатуру или придерживаться определенной точки зрения; порой даже сложно понять, откуда она взялась. Проект с огромным потенциалом начинает подавать надежды, но вдруг его отклоняют как вероятную неудачу. Сначала все воодушевлены микросервисами, а потом начинают интересоваться технологиями бессерверной обработки данных или считают разумным подходом только модульный монолит. Одной команде разрешили нанять в этом году больше людей, а другой – нет. Как принимаются все эти решения? Есть ли для этого какой-то служебный документ?

Некоторые решения, похоже, принимаются в процессе разговоров, при этом они даже не озвучиваются явно. Другие принимаются более формально, но в кабинетах, в которые вы не вхожи. Если у вас много идей, вы, скорее всего, расстроитесь, заметив, что предпочтение отдается чужим инициативам. Почему ваши предложения никто не слушает?²⁹ Многие из нас с трудом примиряются с истиной: быть технически грамотным в той или иной области недостаточно. Вы также должны уметь убеждать людей, причем правильных людей.

Вы не сможете предсказать решения вашей организации или повлиять на них, если не понимаете, как они принимаются. Вы также можете обнаружить, что думаете, будто придерживаетесь единого мнения с окружающими о том, что должно произойти дальше, а потом вдруг узнаете, что все выступают за другой путь. Если вы постоянно чувствуете себя не в своей тарелке, значит, вы не понимаете, как принимаются решения и кто на них влияет.

Где принимаются решения?

Решения, которые влияют на вас и вашу сферу ответственности, принимаются каждый день, и вам может быть очень некомфортно, если они каждый раз становятся для вас сюрпризом. Вы должны хотя бы представлять, откуда они исходят, и скорее всего, вы захотите как-то влиять на них. Давайте начнем с официальных каналов и совещаний, на которых обсуждаются важные проблемы.

Ваш доступ к принятию решений зависит от того, какое место в иерархии организации вы занимаете. Некоторые директивы неизбежно будут создаваться на более высоких уровнях. Вы сможете повлиять на них, если донесете важную информацию до правильных лиц по цепочке управления или по другим каналам. Но какие-то вопросы также рассматриваются непосредственно в вашей сфере ответственности, и вам нужно участвовать в этом, насколько это возможно. Если вы видели мюзикл «Гамильтон», то помните, что Аарон Берр хотел оказаться «в комнате, в которой все происходит». Как нам говорит Берр, у людей, не имеющих доступа в ту комнату, «нет права голоса» (https://oreil.ly/G1Csw). Иногда взгляд со стороны может помочь, но не сейчас. Если вы хотите задать технологическое направление или изменить принципы корпоративной культуры, вы должны находиться внутри группы, которая имеет право голоса.

Выясните, где принимаются решения. Возможно, есть еженедельные совещания менеджеров, предназначенные для выработки организационных постановлений, но они часто влияют на технологические процессы. Может быть, директор склонен строить планы на совещании с людьми, которые ему подчиняются. Может быть, у основной архитектурной группы есть канал в Slack, в котором они согласовывают дальнейшие действия. Если вы не знаете, как функционирует ваша организация, попросите того, кому вы доверяете, рассказать вам об этом. (Только уточните, что вы не собираетесь протестовать против приказа директора, а просто хотите изучить внутренние рабочие процессы.)

Имейте в виду, «секретной комнаты» может не быть вовсе. В самых крайних случаях важные директивы, касающиеся технической политики, принимаются на личных встречах с большими начальниками, или эти инициативы возникают в нижней части служебной иерархии и передаются наверх (и поэтому они часто вообще не принимаются).³⁰ Но если для каких-то решений, в которых вы заинтересованы, все же существует «комната, в которой все происходит», выясните, где она и кто в нее вхож.

Как войти в группу, принимающую решения?

Как только вы определили круг лиц, принимающих важные решения, вы, конечно же, захотите примкнуть к ним. Но вам понадобятся убедительные аргументы, зачем это нужно. Очевидно, что лучше ссылаться на пользу для организации, а не на свои личные интересы. Как бы вы ни нравились коллегам-менеджерам, если вы скажете им, что это вам надо для вашей собственной карьеры, то скорее всего, вы не завоюете их сердца и умы. Покажите, что если вас примут в группу «решателей», то организация быстрее достигнет своих целей. Покажите, что вы можете привнести что-то новое. Четко изложите, почему вам нужен доступ к принятию решений, отрепетируйте свою речь, а потом пойдите и попросите взять вас.

Возможно, вы столкнетесь с сопротивлением. Если в группу добавляют кого-то нового, то тем, кто уже в нее включен, это обычно не нравится. С каждым новым участником совещания проходят медленнее, дискуссии становятся более обширными, а стороны уже не могут позволить себе честно обсуждать трудности глаза в глаза. Если эти люди уже привыкли работать вместе, то с приходом нового человека им приходится с нуля налаживать взаимодействие; в некоторой степени им приходится заново учиться сотрудничать.

Если вас все-таки пригласили, то остальные не должны об этом пожалеть. Уилл Ларсон (Will Larson) в своей статье «Getting in the Room» (https://oreil.ly/us7eX) подчеркивает, что вы должны не только быть полезным группе, но и позаботиться о том, чтобы затраты времени и сил с вашим появлением сильно не выросли: подготовьтесь, говорите кратко, будьте открыты к сотрудничеству, не создавайте конфликтов. Если из-за вас утратится эффективность принятия решений или снизится скорость обмена информацией, то вас больше не позовут.

Если вдруг вас не возьмут в группу, не принимайте это на личный счет, особенно если вы работаете в компании, где сотрудники все еще выясняют, зачем нужны стафф+ разработчики, и пока не согласны с тем, что это руководящая должность. Пока они разбираются в ситуации, будьте дружелюбны, делайте свою работу хорошо и не ворчите, что вас не пригласили, и тогда к вам начнут прислушиваться (и вы действительно станете влиять на события). Войдите в положение других людей, будьте добры к ним и не ведите себя, как тот самый малоприятный тип, о котором я рассказала в главе 1.

К тому же есть решения, к принятию которых вы вообще не должны иметь никакого отношения. Если вы твердо настроены делать карьеру индивидуального контрибьютора, то вы не должны участвовать в обсуждении зарплат, управления производительностью и других задач, которые отслеживают менеджеры. Вы можете предоставить актуальную информацию своему начальнику или директору, но решать будут они. Если важные технические и управленческие директивы принимаются на одном и том же совещании, то вы можете предложить развести эти две темы на разные встречи.

Наконец, у решателей, к которым вы пытаетесь примкнуть, может оказаться меньше полномочий, чем вы думаете. Много лет назад я была поражена тем, что группа директоров считала, что их мнение ничего не значит; они не могли повлиять на решения настоящих движущих сил и инициаторов компании, находящихся на два уровня выше, и это их удручало. Оказалось, что была другая «комната», о которой я даже не догадывалась. Возможно, над ней были и еще другие «комнаты»! Реалистично оценивайте группу, в которую хотите войти.

Теневая структура организации

Так выглядит официальный процесс принятия решений. Если вы это понимаете, то вы уже многое знаете о том, как ваша организация формирует свою политику и выбирает, как развиваться. Неизбежно возникает и множество других факторов, часть из которых на первый взгляд кажется бессмысленными. Неформальный процесс принятия решений не следует правилам, основанным на иерархии или должностях. Они, конечно, имеют значение, но есть и нечто большее.

Важно знать, кто является официальным начальником по технологически вопросам, но так же важно понимать, к кому он прислушивается и как делает свой выбор. Почему Ян, директор вашего инфраструктурного подразделения, который, казалось, полностью поддерживал вашу идею, внезапно к ней охладел? Если вы будете внимательны, то заметите, что при принятии любого решения Ян прежде всего советуется с Сэмом, который пришел в команду десять лет назад. У Сэма не очень высокая должность, но если он думает, что идея плохая, вы никогда не склоните Яна на свою сторону. Такие нити влияния не всегда очевидны, если вы только-только присоединились к компании, так что на начальном этапе заведите друзей и спросите у них, как это работает.

Брайан В. Фицпатрик (Brian W. Fitzpatrick) и Бен Коллинз-Сассман (Ben Collins-Sussman) в своей книге «Debugging Teams: Better Productivity Through Collaboration» рассказали про «теневую структуру организации»: неписаные правила, по которым распространяется власть и оказывается влияние. Теневая структура помогает понять, кто лидер мнений в данной группе, и, возможно, его официальное положение в компании окажется не самым высоким. Пока вы не убедите в своей правоте таких людей, ваше дело не сдвинется с мертвой точки.

Авторы дают определение «связующим звеньям» – это люди, которые знают всех в организации, и «старожилам», которые независимо от должности и служебного положения обладают влиянием просто потому, что они всегда были рядом. Все они держат руку на пульсе и знают, что может сработать, а что нет, и большие начальники будут им доверять и полагаться на их здравый смысл при принятии решений. Заручитесь поддержкой «связующих звеньев» и «старожилов», и вы значительно продвинетесь вперед.

Регулярно обновляем свою топографическую карту

Я уже говорила о том, как важно поддерживать в актуальном состоянии карту местоположения. Для топографической карты это еще важнее. Рельеф компании меняется очень быстро, и ваши знания могут устаревать. В любой день вы можете узнать следующее:

• у команды, с которой вы работаете, появился новый начальник;

• проект, который вы ждали, так и не стартовал после всех мучений;

• скоро начнется квартальное планирование;

• подключается новая полезная платформа;

• ваш продакт-менеджер уходит в длительный отпуск.

Вам придется отслеживать большой объем информации. Но вы должны все это знать, поэтому важно понимать, на что обращать внимание. Вот несколько способов, которые помогут вам оставаться в курсе событий:

Автоматизированные списки и каналы объявлений

Специальные каналы для распространения новых дизайн-документов, объявлений об остановке работ или изменений в менеджменте делают высокоуровневое видение происходящего доступным для каждого сотрудника. Если таких каналов нет, но вам они кажутся полезными, задумайтесь над их созданием.

Прогулки по цеху

Специалисты по бережливому производству (https://oreil.ly/zfdHj) говорят, что полезно «выйти на гембу», то есть пройтись по производственному цеху и увидеть, как все работает на самом деле. Найдите несколько способов оставаться в курсе того, что делают команды вокруг вас. Например, поработайте с кем-нибудь в паре, если нужно внести небольшие программные изменения, урегулировать инцидент или развернуть систему, о которой вы хотите побольше узнать. Если вы слишком отдаляетесь от технологических проблем, то это не только искажает ваше понимание ситуации, но и снижает ваш инженерный авторитет. (Подробнее в главе 4.)

Следите за новостями

Я спросила в Rands Leadership Slack³¹ (https://oreil.ly/O4bad), кто и как получает информацию, и в основном все говорили, что они обращают внимание на открытую информацию, которая необязательна к прочтению. Например, вы можете просматривать календари старших сотрудников, пролистывать повестки дня или заметки с совещаний, на которых вас не было, и – что я никогда не делала – ознакомиться с полным списком каналов в Slack, отсортированным по дате создания, чтобы увидеть, какие новые проекты появились.

Время на чтение

В компаниях с высоким уровнем документационной культуры планы и изменения часто сопровождаются рабочими предложениями (Request for Comments, RFC), дизайн-документами, краткими описаниями продукта и т. д. Просмотрите основные пункты этих документов или выделите время в своем календаре, чтобы прочитать их более вдумчиво.

Свяжитесь с руководством

Вам нужны союзники и покровители, которые расскажут вам, что происходит. Связывайтесь с ними почаще, узнавайте, что происходит за кадром, и проверяйте, что ваши мысли совпадают с мыслями ваших начальников.

Поговорите с людьми

Выпить кофе или початиться – это не только приятный способ построить дружеские отношения, но и отличный источник информации. Если вам действительно нужно получить исчерпывающее представление о работе предприятия, поговорите с людьми, которые находятся вне разработки: из отделов продукта, продаж, маркетинга, юристов и т. д. Если вы создаете продукт, подружитесь с сотрудниками службы поддержки клиентов: они знают о том, что вы создали, больше, чем вы сами. Подружитесь с системными администраторами. Они умны, изобретательны и имеют хорошие связи. Они знают, что происходит вокруг, и часто это самые интересные люди в компании. Заведите друзей.

«Я не умею разговаривать с людьми»

У многих разработчиков аллергия на все, что касается «налаживания связей». Оно напоминает нам о распространенных в 80-х годах напыщенных деловых обедах с влиятельными персонами (или только я так думаю?). Но налаживание связей не обязательно циничное или грязное занятие. Если человек вам интересен и вы приветливы с ним, то он наверняка поделится с вами сведениями и поможет.

Если вам трудно начать разговор с кем-то, то самый легкий путь – это задать вопрос, поинтересоваться, над чем работает этот человек, или (искренне) похвалить его.³² Большинство людей хотят поговорить о своей работе или интересах, и они будут рады объяснить, как устроено то, чем они увлекаются. Короткий разговор – это навык, которым стоит овладеть, чтобы получать дивиденды на протяжении всей своей карьеры. (Если вы говорите с тем, кто младше вас по должности, то сделать беседу непринужденной вообще часть ваших обязанностей.)

Если местность все еще труднопроходима, наведите мосты

Работа в инженерных организациях замедляется в основном из-за человеческого фактора: команды не умеют взаимодействовать, люди боятся принимать решения или борются за влияние. Все эти проблемы сложны! По мере заполнения вашей топографической карты вам встретятся места, о которых захочется предупредить знаком «Внимание! Опасность!!!» и поклясться обходить их стороной. Но стафф-разработчики часто добиваются большего успеха, если идут туда, куда боятся пойти другие, и делают проходимыми опасные территории.

Веструм подчеркивает, как важно «наводить мосты» (рис. 2.11), то есть связывать отдельные части организации, между которыми не налажена должная коммуникация. Чем лучше вы знаете местность, тем проще будет построить мосты, например, отправить по электронной почте описание, которое никто раньше не отправлял, познакомить людей, которые должны были поговорить друг с другом месяц назад, или написать документ, который раскрывает взаимосвязь между проектами.

Рис. 2.11. Пока квартальное планирование еще далеко, стафф-разработчики могут строить мосты, чтобы преодолевать овраги между подразделениями организации

Сайт Google DevOps (https://oreil.ly/DU4Nc) предлагает наводить мосты в превентивных целях: «Если в организации есть люди, чью работу вы не понимаете (или чья деятельность вас разочаровывает, например, вам не нравится, как работает отдел закупок), то пригласите их на кофе или ланч».

Если это возможно, определите свою сферу ответственности так, чтобы она пересекала тектонические плиты и охватывала все системы и проблемы компании, а не только ту их часть, которая относится к отдельной команде. Таким образом вы сможете увидеть задачи, которые кто-то не довел до конца, урегулировать конфликты и помочь создать единую картину происходящего. Если вам предложат важные изменения, то у вас будет достаточно оснований, чтобы сказать: «Да, этот переход на новую платформу – хорошая идея» или: «Нет, у нас есть другая работа».

Карта сокровищ: напомните, куда мы идем?

На данный момент мы нарисовали две карты. Карта местоположения показывает, где мы находимся. Топографическая помогает нам ориентироваться в организации. Но куда мы идем? Для ответа на этот вопрос нам нужна третья карта (рис. 2.12).

Рис. 2.12. Знаком Х отмечено место, где спрятаны сокровища! Осталось только туда добраться

Карта сокровищ поведает нам захватывающую историю о том, куда мы идем и почему мы хотим туда добраться. Давайте отправимся навстречу приключениям!

Не увлекайтесь краткосрочными задачами

Я уже говорила в этой главе о том, что вам нужно не только решать локальные проблемы вашей собственной группы, но и не забывать об интересах всей организации. Также нужно учитывать временну́ю перспективу.

Вы легко можете увлечься краткосрочными задачами, например текущим релизом новой функциональности или последним негативным отзывом на App Store. Но попробуйте мыслить стратегически. Куда вы пытаетесь добраться? Зачем вы все это делаете? Уточню, что вы все же должны решать текущие вопросы, но если вы будете думать только о них, то ограничите свои возможности в достижении максимальной эффективности в работе:

Вам будет труднее добиваться слаженного движения к единой цели

Если у команды нет общего плана на будущее, то она придет не в то место или каждое решение будет приниматься с трудом, занимать много времени и вызывать большое количество споров. Иногда, чтобы обойти трудности, нужно сойти с прямой дороги. Каждый участник команды должен четко понимать, как вернуться на исходный маршрут, после того как препятствие пройдено.

Вы не доведете до конца крупные проекты

Если вы фокусируетесь на краткосрочных задачах команды, чтобы устранить локальные болевые точки, то не сможете решать большие долгосрочные проблемы, требующие нескольких шагов. Кроме того, ценность реализуемых вами проектов будет оставаться неясной для людей, не входящих в вашу команду.

Вы накопите программные «костыли»

Если команды не знают, куда они идут, то у них есть два варианта: либо проявить гибкость и предусмотреть все возможные проблемы в будущем, что приведет к созданию чрезмерно сложных программ, которые будет трудно обслуживать, либо принимать локальные решения и брать на себя риск, что выбранное направление окажется неверным и придется использовать «костыли», которые вынуждены будут обходить другие участники проекта.

У вас появятся разнонаправленные инициативы

Если в организации поддерживается выдвижение инициатив «снизу вверх» от рядовых сотрудников, то несколько человек могут объединиться для решения одной проблемы, но их инициативы могут оказаться разнонаправленными. Они пытаются делать хорошее дело и объединить людей, но в итоге у них ничего вразумительного не получится.

Разработчики перестают развиваться

Если вы сосредоточены только на краткосрочных целях, то ваше представление о работе и способах ее выполнения сужается и вы больше внимания уделяете мелким трудностям, которые появляются между крупными проблемами. Если команда выполняет большой проект, то она должна самостоятельно найти пробелы между назначенными задачами, выяснить, как их заполнить, и развить в этом процессе новые навыки. Команда, привыкшая к коротким итерациям и четко обозначенным целям, не тренирует мозг для больших и более сложных проектов и не сможет даже объяснить причины своих решений.

Ищите долгосрочную перспективу

Путешествовать проще, если все знают, куда идти. Уже не обязательно строго следить за всеми. Каждая команда может проявить больше творчества, выбирая собственный маршрут и генерируя идеи для урегулирования проблем, которые мешают им добраться в пункт назначения. Скорее всего, никто не заблудится и у всех будет достаточно информации для принятия решений, что уменьшит объем риска и технического долга, который им придется взять на себя. Они могут праздновать маленькие победы на пути, но при этом должны помнить, что у них есть долгосрочная цель и что настоящее торжество начнется только тогда, когда они до нее доберутся.

Каковы ваши мотивы?

Я часто привожу аналогию с деревом технологий, которое используется в таких стратегических играх, как Civilization («Цивилизация»).³³ Если вы… э-э-эм… не инвестировали свое время в эту прекрасную игру, то я объясню, в чем там суть. Вы играете за правителя цивилизации и пытаетесь построить империю. Чтобы стать великим правителем, вам нужно собирать научные знания, поэтому по мере продвижения вы можете исследовать различные технологии. Набор доступных технологий формирует направленный граф (рис. 2.13). Вначале вы можете исследовать, скажем, гончарное мастерство и охоту, но, продвигаясь по игре, вы строите новые навыки на основе уже полученных. В Civilization нельзя построить железную дорогу, не изучив мостостроение и паровые двигатели. А паровой двигатель нельзя построить, не изучив физику и инженерию. Поэтому в какой-то момент вы будете изучать физику, хотя вашей конечной целью будет строительство железной дороги. Вы не выиграете, пока не построите мосты, не изучите паровые двигатели и не закажете шапочки для кондукторов поездов. (Последнее не совсем правда, хотя жаль.) Пока вы не уясните себе свою конечную цель и не начнете работать над ее достижением, вы не прокатитесь по железной дороге.

Рис. 2.13. Секция графа технологий из игры Sid Meier’s Civilization II, разработанной компанией Microprose/Activision (источник: http://www.civfanatics.com)

Часто вы выбираете технологию, в которую будете инвестировать только потому, что ее необходимо изучить, прежде чем перейти к чему-то другому. Вы строите новую служебную сеть не для удовольствия; вы строите ее, чтобы упростить использование фреймворка для микросервисов, ведь вы хотите легко добавлять новые сервисы, чтобы команды могли быстрее поставлять новую функциональность. Истинная цель – ускорить выход обновлений. Когда вам известна истинная цель, вы можете мысленно сделать шаг назад и оценить, приблизитесь ли вы к ней, если выполните предложенную работу.

Поделитесь картой

Вам может потребоваться время, чтобы развеять туман неопределенности и узнать, в какой же конечный пункт вы идете на самом деле. Как только вы найдете его, не жадничайте, расскажите о нем другим людям и объясните им, почему он так важен. Из вашего рассказа люди должны понять, где вы находитесь, куда идете и почему вы предпринимаете те или иные шаги. Если есть морские чудища или кратчайшие тропы, о которых стоит знать, отметьте их на своей карте, но не перегружайте ее. На ней должно быть только то, что поможет понять суть происходящего. Также она должна содержать описание сокровищ, то есть давать четкое определение успеха, чтобы каждый знал, к чему вы все стремитесь.

Рис. 2.14. Расскажите о том, с чего вы начали и какой проделали путь

Видимый прогресс может вас мотивировать, но в то же время на удивление легко забыть, откуда вы начали, и даже почувствовать, что вы никуда не продвинулись. Поскольку у вас есть карта (рис. 2.14), то показать, что все приближаются к цели, можете именно вы (и конечно, скорректировать путь, если что-то пошло не так). Расскажите команде, с чего вы начали и куда направляетесь.

Если карта сокровищ все еще малопонятна, то пора нарисовать новую

Если все работают по единой карте сокровищ, то ваша миссия выполнена. Но если вы обнаружили, что на карте много пересекающихся путей или плана на будущее вовсе нет, то скорее всего, нужно помочь группе выбрать пункт назначения. Иногда от вас требуется только кратко описать, в чем, по-вашему, заключается затруднение или разногласие. Озвучьте факты, поделитесь ими, и, возможно, вы инициируете обсуждения (или даже споры). Может случиться так, что после того, как вы зададите все вопросы, проследите технологическое древо «Цивилизации», поможете договориться людям, которые не согласны друг с другом, и хорошо все обдумаете, вы придете к выводу, что группа еще не выбрала долгосрочную цель или существует нескольких целей, которые противоречат друг другу.

В таком случае вы уже достаточно развеяли неопределенность, и пришло время нарисовать новую карту. Этому посвящена вся следующая глава.