Написать пост

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следите за новыми постами
Следите за новыми постами по любимым темам
730 открытий2К показов