Из разработки в менеджмент. Вопросы, которые стоит задать себе перед переходом

Меня зовут Саша Козяровский, я работаю менеджером проектов в Customertimes. А начинал я в IT с позиции Junior-разработчика. За последние 9 лет успел попрограммировать на 1С, поучаствовать в создании аутсорсинговой IT-компании, повнедрять Microsoft Dynamics, поуправлять проектами по созданию мобильных приложений и социальных сетей, поработать с Salesforce CRM и снова вернуться к проектам по мобильной разработке. Путь был тернистым, порой болезненным, но точно интересным. Прямо как у Фродо Бэггинса с его кольцом, только не факт, что орлы заберут обратно :)

Иллюстрация Алины Самолюк

Примерно три года назад я написал последнюю строчку кода и больше к разработке не возвращался. Мне пришлось начинать практически с нуля. Конечно, перед тем как уйти в менеджмент, я взвесил за и против, проанализировал свои навыки и таланты. Гениального разработчика я в себе не видел, но общий язык с клиентами и коллегами всегда находил легко. То есть soft skills явно превышали по уровню hard skills. К тому же подходящая для меня позиция на тот момент была вакантна.

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

Начнем.

Готов ли я постоянно отвлекаться?

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

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

Люблю ли я людей?

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

Готов ли я балансировать между перфекционизмом и практичностью?

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

Продуктовый стартап обычно начинается с PoC/MVP. На одном из таких проектов мы с командой сознательно копили технический долг и отсекали десятки второстепенных бизнес-кейсов, чтобы успеть в срок. Тогда это было вполне здравое решение, которое помогло быстрее привлечь инвестиции для дальнейшего развития продукта. Главное не переступить черту, когда проще все переписать заново. Хоть и это не конец света.

Хочу ли я видеть сны о работе?

Слово «стрессоустойчивость» традиционно бездумно копируется из одного CV в другое. Мотивация проста: «А почему нет? Звучит круто, да и раздел о soft skills нужно чем-то заполнять».

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

Да, в идеальном мире проектный менеджер такого допустить не должен. Он все риски просчитает, ответы на них сформулирует и будет следить за их статусом регулярно. Но на то они и риски, чтобы в реальном мире срабатывать. Главное в стрессовом режиме работы — не допустить профессионального выгорания. Если же есть признаки, пора в отпуск.

Готов ли я постоянно учиться?

Этот вопрос, конечно же, актуален и для технических специалистов, так как технологии идут вперед и нужно не отставать. Менеджеру же стоит понимать, что любой новый проект — это зачастую новый технологический стек и новые сервисы, особенности работы окружения, другой подход к архитектуре, домен, изменение методологии и так далее. И в этом всем придется разбираться. Как минимум — на достаточном уровне для того, чтобы говорить с командой и клиентом на одном языке.

Готов ли я принимать непопулярные решения?

Мало кому доставляет удовольствие увольнять человека, особенно если это хороший парень. Но, как говорится, хороший парень — не профессия. В эту же копилку непопулярных решений: просить команду овертаймить или работать в выходные, поскольку дедлайн был вчера. Неприятно, но порой это выход.

В одной из предыдущих компаний у меня на проекте был очень крутой разработчик: задачи любой сложности просто уничтожал. Но был у него минус: он мог раз в месяц на 3–4 дня уйти в запой, без связи с реальностью и проектом. И это никак нельзя было спрогнозировать. Постоянно терпеть такие выходки было невозможно, разговоры не помогали, и я инициировал вывод этого специалиста из проекта. По-человечески мне было жаль его, но я задал себе вопрос: «Хочу ли я в каком-либо другом проекте еще раз работать с Х?», и ответил: «Ни в коем случае». Больше мы с ним не пересекались.

Готов ли я нести ответственность за «чужие» ошибки?

Строго говоря, с тех пор как менеджер назначен на проект, в команде больше нет чужих ошибок. Все они отчасти менеджерские. Да, ответственность за них можно разделить с тем, кто напортачил, но спрос все равно в итоге с менеджера, поскольку контроль за прогрессом и качеством — одна из его задач. Оправдания в духе «Так это бизнес-аналитик/разработчик все запорол. Я тут при чем?» для руководителя неприемлемы. Проект идет хорошо — команда молодцы, проект идет плохо — виноват менеджер.

Достаточный ли у меня уровень английского?

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

В некоторых компаниях должности Project Coordinator или Junior Project Manager не предусматривают общения с клиентом напрямую. На таких позициях можно отлично подтянуть свой английский, наблюдая за работой ментора, читая документацию и так далее. Но в большинстве вакансий на украинском IT-рынке уровень Upper-Intermediate для проектных менеджеров — must have. И это логично, ведь плохая коммуникация в проекте — одна из основных причин провала.

Готов ли я терять технические навыки?

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

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

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

В чем сила?

На этот вопрос каждый ответит по-своему. В контексте менеджмента я бы сказал, что сила в широком мышлении, в умении видеть картину проекта в целом. В английском языке есть удачная идиома на эту тему — helicopter view. Что это значит? Иногда вместо того, чтобы заниматься микроменеджментом, стоит сделать паузу и задать себе вопросы: «Насколько фича, которую мы обсуждаем уже третий час, важна для бизнеса?» или «Перекроет ли выгода от соответствия определенному стандарту стоимость времени, потраченного на то, чтобы этому стандарту соответствовать?».

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU