[Перевод] Что входит в обязанности ведущего разработчика
Вот эта большая статья Джона Олспау называется «Быть ведущим инженером». В первый раз я прочитала её примерно четыре года назад, когда только перешла на нынешнюю работу, и она действительно повлияла на представления об этом направлении моей карьеры.
Перечитав её сейчас, действительно интересной там кажется одна вещь, что эмпатия и помощь команде — важная часть работы сеньора. Что, конечно, является правдой!
Но сейчас я вижу, что большинство или все ведущие инженеры, которых я знаю, берут на себя значительную помощь другим сотрудникам вдобавок к своей личной работе по программированию. Сейчас мне кажется, что я и мои коллеги сталкиваются не столько с проблемой «Что? Нужно РАЗГОВАРИВАТЬ С ЛЮДЬМИ? НЕВЕРОЯТНО», сколько с другой проблемой: «Как сбалансировать всю эту руководящую работу со своим индивидуальным вкладом / программированием? Сколько и какой работы я должен делать?». Поэтому вместо того, чтобы говорить о признаках сеньора из статьи Олспау (с которыми я полностью согласна), хочу поговорить о работе, которую мы делаем.
«Чем занимается ведущий инженер» — огромная тема, а здесь лишь небольшая статья, так что следует иметь в виду:
- Тут лишь одно возможное описание того, чем может заниматься ведущий инженер. Есть много подходов к работе, и это не должно стать догмой.
- Я в основном работала только в одной компании, поэтому мой опыт и взгляды, очевидно, довольно ограничены.
- Очевидно, есть много уровней «сеньора». Речь идёт примерно об уровне P3/P4 в иерархии Mozilla (senior engineer / staff engineer), может быть, немного ближе к уровню «staff».
Это вещи, которые я рассматриваю больше как работу ведущего инженера и меньше как работу менеджера (хотя менеджеры определённо делают кое-что из перечисленного, особенно создание новых проектов и связывание проектов с бизнес-приоритетами).
Почти вся эта работа по сути техническая: помочь кому-то справиться со сложным проектом — это явно человеческое взаимодействие, но проблемы, над которыми мы будем работать вместе, как правило, будут техническими! («Может, если упростить дизайн, то мы сможем быстрее справиться!»).
- Писать код (очевидно).
- Делать код-ревью (очевидно).
- Писать и рассматривать документацию по дизайну. Как и в случае с другими ревью, сторонний взгляд, вероятно, поможет улучшить дизайн.
- Помогать коллегам, если они застряли. Иногда люди застревают на проекте, и важно им помочь! Я думаю об этом не столько о «парашюте с неба и доставке людям ваших магических знаний», сколько о «совместной работе, чтобы понять проблему и посмотреть, справятся ли два мозга быстрее, чем один» :). Это также означает совместную работу, а не решение проблемы вместо другого человека.
- Поддерживать коллег на высоком уровне. Для разных людей «уровень» имеет разное значение (для моей команды это означает надёжность/безопасность/удобство продукта). Если кто-то принимает решение, которое мне не нравится, значит, либо я знаю что-то, чего не знает он, или он знает что-то, чего не знаю я! Поэтому не нужно говорить: «Эй, ты сделал это неправильно, нужно сделать X вместо этого», а лучше просто дать им дополнительную информацию, которой у них не было, и часто это решает вопрос. И довольно часто оказывается, что мне чего-то не хватало, и на самом деле их решение было вполне разумным! В прошлом я иногда видела, как ведущие инженеры пытаются обеспечить соблюдение стандартов качества, всё громче повторяя своё мнение, потому что они думают, что их мнение верно. Лично я не нашла полезным такой подход.
- Создавать новые проекты. Команда разработчиков программного обеспечения — это не место с нулевой суммой! Лучшие инженеры, которых я знаю, не оставляют себе самую интересную работу, они создают новые интересные/важные проекты и создают пространство, чтобы другие делали эту работу. Например, кто-то из моей команды начал переписывать нашу систему деплоя. Проект оказался суперуспешным, и теперь целая команда работает над новыми функциями, которые стало легче реализовать!
- Планировать работу своих проектов. Речь о том, чтобы записать/сообщить дорожную карту для проектов, над которыми вы работаете, и убедиться, что люди понимают план.
- Заранее сообщать о рисках проекта. Очень важно распознать, когда что-то идёт не очень хорошо, сообщить об этом другим инженерам/менеджерам и решить, что делать.
- Сообщать об успехах!
- Делать сторонние проекты, которые приносят пользу команде/компании. Я вижу, что многие сеньоры иногда делают небольшие, но важные проекты (например, создают инструменты разработки / помогают устанавливать политики), которые в конечном итоге помогают многим людям выполнять свою работу намного лучше.
- Быть в курсе, как проекты соотносятся с приоритетами бизнеса.
- Решать, когда прекратить проект. Оказывается, на удивление сложно понять, когда нужно остановиться / не начинать работу над чем-то. :)
На первое месте я поставила «писать код», потому что в реальности эта задача легко скатывается вниз в списке приоритетов. :)
В списке отсутствует пункт «делать оценки/прогнозы». Здесь я ещё не очень хороша, но я думаю, что когда-нибудь стоит потратить на это больше времени.
Список кажется большим. Кажется, что если заниматься всеми этими вещами, то они поглотят все ваши интеллектуальные ресурсы. Думаю, что в целом имеет смысл выделить какую-то часть и решить: «Прямо сейчас я собираюсь сосредоточиться на X, Y и Z, я думаю, что мой мозг взорвётся, если я попытаюсь сделать B и C».
Тут немного сложнее. Я не говорю, что такими вещами категорически нельзя заниматься. Большинство ведущих инженеров, которых я знаю, тратят огромное количество времени, думая об этих проблемах, и немного работают в этом направлении.
Но мне кажется, что полезно провести некоторую границу, потому что у некоторых людей высокое чувство ответственности за команду и компанию — и они готовы взяться за всё подряд, в результате чего будут перегружены работой и не смогут вносить технический вклад, который на самом деле является их основным делом. Поэтому установление некоторых границ помогает определить, по каким вопросам есть смысл попросить о помощи, когда ситуация становится неспокойной. Ваши реальные границы зависят от вас / вашей команды. :)
Большинство из перечисленного ниже — работа менеджера. Оговорка: менеджеры делают намного больше, чем перечисленное здесь (например, «создают новые проекты»), а в некоторых компаниях некоторое из перечисленного может фактически быть работой ведущего инженера (например, спринт-менеджмент).
- Убедиться, что каждый сотрудник вознаграждается по заслугам за свою работу.
- Убедиться, что работа справедливо распределена.
- Убедиться, что люди хорошо работают вместе.
- Обеспечить сплочённость команды.
- Поговорить наедине с каждым сотрудником.
- Обучать новых менеджеров, помогать им понять, что от них ждут (хотя я думаю, что ведущие программисты часто действительно приходят к такой деятельности?).
- Управлять сторонними проектами (у меня на работе это дело любого инженера, ведущего тот проект).
- Быть менеджером по продукту.
- Вести спринт-менеджмент спринтом / определять этапы работы для каждого / проводить еженедельные митинги.
Недавно я столкнулась с интересной ситуацией, когда обсуждала с менеджером свои обязанности — и мы поняли, что очень по-разному на них смотрим! Мы прояснили ситуацию, и теперь всё в порядке, но это заставило меня понять, что очень важно договориться об ожиданиях. :)
Когда я начинала как инженер, работа была довольно простой — я писала код, пыталась придумать проекты, которые имели смысл, и всё было прекрасно. У моего менеджера всегда было чёткое представление о моей работе, ничего слишком сложного. Теперь ситуация изменилась! Поэтому теперь я считаю, что обязана определить работу, которую:
- Я могу делать / долговременно подходит для меня.
- Я хочу сделать / которая в целом приятна и соответствует моим личным целям.
- Представляет ценность для команды / организации.
Точная формулировка будет отличаться для разных людей (не у всех одинаковые интересы и сильные стороны, например, я ещё не слишком хороша в код-ревью!). Думаю, по этой причине ещё важнее обсудить эту тему и согласовать ожидания.
Думаю, очень важно отказаться от работы, которую я не могу сделать или которая в долгосрочной перспективе не доставит радости! Кажется заманчивым взять на себя много работы, даже если она вам не очень нравится («О, это хорошо для команды!», «Ну кто-то же должен это сделать!»). Конечно, иногда я беру на себя задачи только потому, что они должны быть выполнены, но думаю, что для здоровья команды на самом деле очень важно, чтобы сотрудники делали то, что им в целом нравится и чем они могут заниматься в долгосрочной перспективе.
Поэтому я возьму небольшие задачи, которые просто нужно сделать, но важно не говорить при этом: «О, конечно, я потрачу большую часть своего времени на то, что у меня плохо получается и что мне не нравится, нет проблем» :). И если «кто-то» должен это сделать, возможно, это просто означает, что нам нужно нанять/обучить кого-то нового, чтобы заполнить пробел. :)
Хотя я чувствую, что начинаю понимать, что такое «ведущий инженер» (уже 7 лет в моей карьере), но я по-прежнему чувствую, что нужно ещё многое узнать об этом, и мне было бы интересно услышать, как другие люди определяют границы своей работы!
