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

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

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

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


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

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

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


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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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


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

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

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


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

Комментарии (2)


  1. StanislavL
    22.10.2018 10:58

    У меня еще входит несколько пунктов.
    1. Поддержка BA. Review требований и консультации как лучше/правильнее описать.
    2. Оценки. От оценки текущих проектных задач на планировании до оценки входящих проектов.
    3. Knowledge sharing. Иногда мини лекции и/или mentoring кого-то из разработчиков.
    4. Помощь QA автоматизаторам. От разъяснений по API до проверок тестов (выборочно).


  1. VolCh
    23.10.2018 08:42

    С терминологией русской как-то теряется смысл. Ведущий инженер — это не senior engineer, a lead engineer. А по содержанию как-то вообще в голове то ли team leader, то ли technical leader. О какой позиции реально пост?