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