Как я стал техническим менеджером после 18 лет в разработке

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

Роман Ржевский

Технический менеджер проектов по разработке, КРОК

Как всё начиналось

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

Как известно, в обязанности технического менеджера проектов входит планирование задач команды, управление сроками и бюджетом проекта, а также контроль качества выполняемой работы. Нельзя сказать, что я очень стремился перейти в эту должность. Это гармонично случилось само собой. В КРОК есть внутренний фреймворк для разработки веб-приложений — XFW3. За первые пару лет работы в компании я оказался одним из основных хранителей компетенций по нему. В итоге мне предложили новую роль технического менеджера для развития внутреннего продукта, а позже и для внешних проектов. К тому времени мне и самому уже порядком надоело кодить, захотелось расширить кругозор, научиться новому.

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

Я учился общаться и искать компромиссы

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

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

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

Ещё лучше — организовать встречу с потенциальным заказчиком и задать уточняющие вопросы. Если встретиться не получается, то можно написать КП с допущениями, предположениями и ограничениями. И с учётом этого рассчитать трудозатраты, стоимость и сроки.

Планировать рабочие встречи и свои задачи

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

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

• сгруппировать вопросы,
• проработать варианты ответов,
• продумать возможные решения для разных вариантов.

Причём в процессе подготовки часть вопросов обычно решаются сами собой.

Мне помогли курсы и семинары по тайм-менеджменту. Навык управления своим временем здорово уменьшает процент суеты и нервозности и одновременно с этим добавляет структурности и предсказуемости в работе над проектом.

Оценивать будущий проект и не поддаваться давлению

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

Будучи на должности разработчика, я всегда оценивал сроки выполнения задачи по себе. Но как быть, когда неизвестно, какой именно разработчик будет выполнять задачу? А если их много? Если занизить сроки, то сделать мы ничего не успеем и понесём финансовые потери. В то же время заложить слишком большой запас тоже тревожно, так как заказчик может решить, что мы пользуемся его ресурсами, и уйти к другой команде.

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

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

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

Доверять команде и позволять ей выполнять свою работу

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

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

Работа с людьми стала для меня самым непривычным опытом

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

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

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

Не «Ты допустил ошибку», а: «Здесь допущена ошибка» — почувствуйте разницу.

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

• внимательно слушать;
• игнорировать намёки на грубость и попытки уйти от темы;
• переводить разговор в конструктивное русло.

То есть ставить акцент не та том, кто виноват, а на том, что делать; концентрировать внимание собеседника на общей задаче и способе её решения.

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

Как мне работается сейчас

За годы работы я уже привык к постоянному общению с людьми, набил руку оценивать проекты, научился планировать время на встречи и личные задачи.

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

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

Я считаю, что принял верное решение, перейдя из разработчиков в технические менеджеры. Меня увлекает выстраивать работу команды перед стартом проекта, планировать задачи, погружаться в новую предметную область. На начальных этапах интересно знакомиться с командой, узнавать людей, организовывать их взаимодействие, наблюдать, как «машина разработки ПО» начинает разгоняться. В финале проекта приятно видеть сплочённую команду, которая выдаёт качественный программный продукт, и осознавать, что в общем успешном результате есть и моя заслуга.

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

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