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

Перечитав её сейчас, действительно интересной там кажется одна вещь, что эмпатия и помощь команде — важная часть работы сеньора. Что, конечно, является правдой!

Но сейчас я вижу, что большинство или все ведущие инженеры, которых я знаю, берут на себя значительную помощь другим сотрудникам вдобавок к своей личной работе по программированию. Сейчас мне кажется, что я и мои коллеги сталкиваются не столько с проблемой «Что?? Нужно РАЗГОВАРИВАТЬ С ЛЮДЬМИ?? НЕВЕРОЯТНО», сколько с другой проблемой: «Как сбалансировать всю эту руководящую работу со своим индивидуальным вкладом / программированием? Сколько и какой работы я должен делать?». Поэтому вместо того, чтобы говорить о признаках сеньора из статьи Олспау (с которыми я полностью согласна), хочу поговорить о работе, которую мы делаем.

О чём эта статья

«Чем занимается ведущий инженер» — огромная тема, а здесь лишь небольшая статья, так что следует иметь в виду:

• Тут лишь одно возможное описание того, чем может заниматься ведущий инженер. Есть много подходов к работе, и это не должно стать догмой.
• Я в основном работала только в одной компании, поэтому мой опыт и взгляды, очевидно, довольно ограничены.
• Очевидно, есть много уровней «сеньора». Речь идёт примерно об уровне P3/P4 в иерархии Mozilla (senior engineer / staff engineer), может быть, немного ближе к уровню "staff".

Что входит в обязанности

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

Почти вся эта работа по сути техническая: помочь кому-то справиться со сложным проектом — это явно человеческое взаимодействие, но проблемы, над которыми мы будем работать вместе, как правило, будут техническими! («Может, если упростить дизайн, то мы сможем быстрее справиться!»).

• Писать код (очевидно).
• Делать код-ревью (очевидно).
• Писать и рассматривать документацию по дизайну. Как и в случае с другими ревью, сторонний взгляд, вероятно, поможет улучшить дизайн.
• Помогать коллегам, если они застряли. Иногда люди застревают на проекте, и важно им помочь! Я думаю об этом не столько о «парашюте с неба и доставке людям ваших магических знаний», сколько о «совместной работе, чтобы понять проблему и посмотреть, справятся ли два мозга быстрее, чем один» :). Это также означает совместную работу, а не решение проблемы вместо другого человека.
• Поддерживать коллег на высоком уровне. Для разных людей «уровень» имеет разное значение (для моей команды это означает надёжность/безопасность/удобство продукта). Если кто-то принимает решение, которое мне не нравится, значит, либо я знаю что-то, чего не знает он, или он знает что-то, чего не знаю я! Поэтому не нужно говорить: «Эй, ты сделал это неправильно, нужно сделать X вместо этого», а лучше просто дать им дополнительную информацию, которой у них не было, и часто это решает вопрос. И довольно часто оказывается, что мне чего-то не хватало, и на самом деле их решение было вполне разумным! В прошлом я иногда видела, как ведущие инженеры пытаются обеспечить соблюдение стандартов качества, всё громче повторяя своё мнение, потому что они думают, что их мнение верно. Лично я не нашла полезным такой подход.
• Создавать новые проекты. Команда разработчиков программного обеспечения — это не место с нулевой суммой! Лучшие инженеры, которых я знаю, не оставляют себе самую интересную работу, они создают новые интересные/важные проекты и создают пространство, чтобы другие делали эту работу. Например, кто-то из моей команды начал переписывать нашу систему деплоя. Проект оказался суперуспешным, и теперь целая команда работает над новыми функциями, которые стало легче реализовать!
• Планировать работу своих проектов. Речь о том, чтобы записать/сообщить дорожную карту для проектов, над которыми вы работаете, и убедиться, что люди понимают план.
• Заранее сообщать о рисках проекта. Очень важно распознать, когда что-то идёт не очень хорошо, сообщить об этом другим инженерам/менеджерам и решить, что делать.
• Сообщать об успехах!
• Делать сторонние проекты, которые приносят пользу команде/компании. Я вижу, что многие сеньоры иногда делают небольшие, но важные проекты (например, создают инструменты разработки / помогают устанавливать политики), которые в конечном итоге помогают многим людям выполнять свою работу намного лучше.
• Быть в курсе, как проекты соотносятся с приоритетами бизнеса.
• Решать, когда прекратить проект. Оказывается, на удивление сложно понять, когда нужно остановиться / не начинать работу над чем-то. :)

На первое месте я поставила «писать код», потому что в реальности эта задача легко скатывается вниз в списке приоритетов. :)

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

Список кажется большим. Кажется, что если заниматься всеми этими вещами, то они поглотят все ваши интеллектуальные ресурсы. Думаю, что в целом имеет смысл выделить какую-то часть и решить: «Прямо сейчас я собираюсь сосредоточиться на X, Y и Z, я думаю, что мой мозг взорвётся, если я попытаюсь сделать B и C».

Что не входит в обязанности

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

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

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

• Убедиться, что каждый сотрудник вознаграждается по заслугам за свою работу.
• Убедиться, что работа справедливо распределена.
• Убедиться, что люди хорошо работают вместе.
• Обеспечить сплочённость команды.
• Поговорить наедине с каждым сотрудником.
• Обучать новых менеджеров, помогать им понять, что от них ждут (хотя я думаю, что ведущие программисты часто действительно приходят к такой деятельности?).
• Управлять сторонними проектами (у меня на работе это дело любого инженера, ведущего тот проект).
• Быть менеджером по продукту.
• Вести спринт-менеджмент спринтом / определять этапы работы для каждого / проводить еженедельные митинги.

Полезно явно задавать границы

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

Когда я начинала как инженер, работа была довольно простой — я писала код, пыталась придумать проекты, которые имели смысл, и всё было прекрасно. У моего менеджера всегда было чёткое представление о моей работе, ничего слишком сложного. Теперь ситуация изменилась! Поэтому теперь я считаю, что обязана определить работу, которую:

• Я могу делать / долговременно подходит для меня.
• Я хочу сделать / которая в целом приятна и соответствует моим личным целям.
• Представляет ценность для команды / организации.

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

Не соглашайтесь на работу, которую не можете / не хотите делать

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

Поэтому я возьму небольшие задачи, которые просто нужно сделать, но важно не говорить при этом: «О, конечно, я потрачу большую часть своего времени на то, что у меня плохо получается и что мне не нравится, нет проблем» :). И если «кто-то» должен это сделать, возможно, это просто означает, что нам нужно нанять/обучить кого-то нового, чтобы заполнить пробел. :)

Мне ещё многому нужно научиться!

Хотя я чувствую, что начинаю понимать, что такое «ведущий инженер» (уже 7 лет в моей карьере), но я по-прежнему чувствую, что нужно ещё многое узнать об этом, и мне было бы интересно услышать, как другие люди определяют границы своей работы!