Удивительные уроки, которые я усвоил, работая техническим руководителем

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

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

Люди прежде всего — важность гибких навыков

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

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

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

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

Граница между младшим и старшим (нет, не средним уровнем).

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

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

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

Мой первый опыт руководства проектом

Когда я взялся за свой первый проект, мой босс знал, что я ранее не руководил никаким другим проектом. Я просто участвовал в разработке и прорабатывал некоторые вещи, которые бы облегчили разработку с точки зрения общения с руководством. Первый вопрос, который он мне задал, был: «Сколько людей и какого рода будет достаточно, чтобы дополнить проект». Я не сразу узнал ответ, это был очень сложный вопрос. Поскольку проект был только в общих чертах, мы не имели представления о стеке, сколько времени потребуется для выполнения каждой задачи и других показателях, представляющих интерес для людей выше. Я провел полное исследование, чтобы иметь возможность предоставить на следующий день несколько методологий управления проектами: Pert, Planning Poker. Мы совместно выбрали ту, которая лучше всего подходила, и началась задача. для каждого члена команды, какая лучшая платформа разработки, какой лучший стек для использования, как будет работать архитектура системы, изучение других решений на рынке, мониторинг уровня каждого разработчика, встречи, встречи и еще больше встреч с руководством .

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

Заключение и взгляд в прошлое - мастеру с любовью

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

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

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

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