Кто такой технический менеджер проектов?

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

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

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

Однако, чтобы квалифицироваться как TPM, они должны иметь дополнительный уровень опыта помимо управления процессами Agile и сотрудничества с разработчиками: они должны сами быть разработчиками.

Ценная комбинация

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

Даже в тех случаях, когда клиенту специально не требуется менеджер проекта с техническим образованием, установление флажка «разработчик» является основным аргументом в пользу продажи. Кто-то, кто может планировать и выполнять программный проект, внедрять и оптимизировать Agile-процессы и код? Это огромное благо.

В действительности, однако, не ожидается, что TPM будут кодировать — многие не кодировали годами. Зачем тогда нужен опыт программирования?

По словам Блэквелла, TPM необходимы для принятия технических решений: «Если у вас нет хотя бы относительно недавнего практического опыта работы с современным техническим стеком, SDK (комплектом для разработки программного обеспечения), архитектурой или платформой автоматизации тестирования, потенциально не собирается принимать правильные решения. У вас не будет доверия со стороны клиента, потому что вы не использовали эти вещи раньше».

Работа с командами

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

Майкл Пойтресс начал программировать еще подростком. В 16 лет он создал коммерческий веб-сайт для рекламного бизнеса в сфере недвижимости, который начал вместе со своим отцом. С тех пор он был генеральным директором и основателем нескольких стартапов. В 2018 году он присоединился к сети Toptal в качестве TPM и теперь тесно сотрудничает с инженерными командами. «Если бы у меня не было опыта программирования, программисты это заметили бы», — говорит он. «Они не стали стрелять прямо в меня. Но если я бросаю им вызов и говорю с ними как с равными, это уважение и взаимопонимание».

И именно технологический опыт значит больше, чем название, говорит Аллен Такацука, TPM Toptal из округа Ориндж, Калифорния: «Из того, что я видел, буква «T» в TPM на самом деле не имеет никакого значения для инженеров. Они думают, что это просто еще один менеджер проекта, который собирается организовать их встречи и попросить заполнить электронные таблицы».

Однако, как только общая основа установлена, «вкус взаимодействия становится совсем другим. Это скорее партнерство с инженерами», — говорит он.

Такацука десятилетиями руководил инженерными командами в начале своей профессиональной жизни. Он считает, что этот опыт повысил уровень его мягких навыков. «Это немного другой навык эмпатии, — говорит он. «Вы должны показать, что можете говорить на языке. Вы можете сказать: «Я понимаю, почему у вас есть эти проблемы, связанные с техническими вещами, которые происходят».

Дэн Аллен, консультант по технологиям из Вены, штат Вирджиния, описывает свой карьерный рост как «от рядового программиста до технического руководителя, архитектора, директора, вице-президента, технического директора, ИТ-директора». С момента присоединения к сети Toptal в качестве TPM в 2019 году он был занят, работая над 14 проектами клиентов.

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

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

Эффект мультипликатора

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

«У вас есть способность быть технически самоуверенным», — говорит Такацука. «И это повышает ценность организации, потому что теперь вы получаете больший эффект мультипликатора, а не просто организуете и сотрудничаете».

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

«Вы можете намного эффективнее справляться с рисками», — говорит Оана Чихерин, TPM из Токио. «И эти риски могут исходить из очень многих мест. Они могут исходить из неправильных оценок команды. Таким образом, вы можете сказать: «Хорошо, я уверен, что этот фрагмент кода не займет неделю, чтобы написать его», потому что на самом деле это два дня. Таким образом, вы действительно можете разблокировать людей. Потому что вы поняли, что они застряли, и именно поэтому у них уходит пять дней. Ты знаешь это, потому что ты был там и сам застрял».

Поиск баланса

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

Пойтресс тоже считает, что нашел свое место. «Я переводчик или связующее звено между провидцами, у которых есть идея, и техническим талантом, который знает, как ее воплотить и воплотить», — говорит он. «Я свободно говорю на обоих языках. Я говорю «обычный человек» и говорю на «техническом языке».

Мини-технический директор

TPM, работающие для стартапов и малого бизнеса, занимают особое место на стыке бизнеса и технологий. В таких случаях TPM часто является первым, кого нанимают в самом начале проекта. Затем он или она отвечает за оценку жизнеспособности продукта, определение технического объема и требований, а также помощь клиенту (иногда одному основателю с зародышем идеи) в выборе технологического стека, оценке поставщиков для предоставления услуг, внедрении лучших практик DevOps, и собрать правильную команду.

Такацука считает эти обязательства ролями «мини-CTO», в которых TPM соединяет деловую и техническую сферы, чтобы сдвинуться с мертвой точки. Некоторые клиенты почти ничего не знают о разработке программного обеспечения, говорит он: «Как мне открыть магазин? Я читал об Agile. Как это сделать?"

Пойтресс считает, что эти две роли пересекаются, а в некоторых случаях даже неотличимы друг от друга. «Существует много перекрестного опыления», — говорит он. «Технический директор в небольшой организации может очень легко перейти на должность старшего технического менеджера по проектам в более крупной организации и чувствовать себя как дома».

Включение гибкости

В то время как механика Agile находится в ведении практически любого руководителя проекта с опытом разработки программного обеспечения, человек с техническими способностями может привнести более тонкий взгляд на управление процессами.

Ciherean считает, что методологии Agile никогда не применяются строго по книге; они должны быть настроены, смешаны и адаптированы к конкретным потребностям команды и проекта.

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

Экспертиза TPM также может использоваться для определенных артефактов и методов Agile, таких как невыполненная работа по продукту и оценки относительного размера.

«Если вы разбираетесь в технической части, вы понимаете всю сложность вещей в бэклоге», — говорит Такацука. «В противном случае все, что у вас есть, это этот список, и вам было бы трудно понять, является ли номер один размером футболки Large по сравнению с номером два. У вас может быть представление о том, что один из них сложнее, но вы действительно не знаете, что за кулисами. «Экстремальный» TPM, по его словам, «может сам оценивать вещи, с оговоркой, что, когда команда приступит к работе, они будут иметь свою собственную скорость».

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

TPM также помогают информировать клиентов о нефункциональных требованиях. Как вы справляетесь с высокой доступностью? Как вы справляетесь с аварийным восстановлением? «Без технического понимания я не знаю, как вы ведете эту дискуссию, — говорит Такацука. «Вы, вероятно, остановитесь на уровне требований Scrum и закончите работу, пока не придут технические специалисты. Ну, тогда у вас есть эта огромная пропасть.

Сохранение актуальности

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

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

Сегодня он тратит до 10 процентов своего времени на чтение документации, просмотр YouTube и работу в песочнице, «чтобы узнать о последних и лучших вещах».

«Я почти всегда балуюсь новым языком или технологией, просто чтобы оставаться в форме», — говорит он. «Потому что, если я этого не сделаю, индустрия будет двигаться дальше. У меня такое уже было. И зубрить намного сложнее, чем оставаться в курсе».

Такацука также активно восполняет пробелы в своих знаниях: «В наши дни Google великолепен. Ютуб классный. Вы должны сделать свою домашнюю работу. Но эта работа строится сама на себе».

Он также полагается на широкую сеть коллег-консультантов для поддержки и обмена знаниями. «У меня были ситуации, когда клиент хотел использовать Google, но я лучше знаю платформу AWS», — говорит он. «Я могу позвонить друзьям и сказать: «Привет, мы собираемся использовать Firebase. Были ли у вас клиенты, которые этим занимались? Как насчет масштабируемости?»

Даже после более чем 30 лет работы в бизнесе и нескольких должностей на руководящем уровне Дэн Аллен не боится замарать руки. За последние три года он научился самостоятельно развертывать приложения на Amazon и Google Cloud. «Я сделал это, чтобы понять и помочь клиенту Toptal», — говорит он. «У них не было технологической команды. Все, что у них было, это я. Так что я пошел в Университет YouTube, и я сделал это».

Так много изменилось с тех пор, как Аллен начал работать разработчиком в 1985 году. Но он наслаждается вызовами, возникающими с каждой новой возможностью. «Это часть того, что мне нравится в этой работе, — говорит он. «Всегда есть что-то, что вы еще не сделали, что-то новое. И вы всегда уходите с дополнительным пером в шляпе, которое вы можете использовать в следующем сражении».