Олег Скуратович пришёл в проектное управление после семи лет в разработке и примерно трёх лет на позиции тимлида. Теперь он работает как Technical Project Manager, а вне работы дирижирует церковным хором — и видит между этими ролями гораздо больше общего, чем принято думать. Для IT-команд это не романтическая метафора: сильные специалисты сами по себе не гарантируют ни предсказуемый релиз, ни устойчивый результат.
О своём переходе из разработки в управление Скуратович рассказал в интервью, сообщает Habr / Карьера. Его карьерная траектория выглядит вполне узнаваемо для технического менеджера: Junior, Senior SQL-разработчик, руководитель команды, затем работа со всем циклом проекта — от разговора с заказчиком и анализа задачи до вывода в production и сопровождения. Такой опыт помогает PM не сводить управление к контролю сроков: за диаграммой задач обычно стоят архитектурные ограничения, зависимости между командами и люди, которые по-разному понимают цель.
Музыкальная часть биографии здесь не случайная деталь для корпоративного интервью. Скуратович с детства занимался музыкой, учился в физмат-классе, получил диплом учёного-математика по специальности «научно-производственная деятельность» и параллельно завершил духовно-музыкальное образование по дирижированию церковным хором. Для него музыка — не противоположность инженерии, а система с правилами, структурой, повторяющимися паттернами и зависимостями. Разница лишь в том, что сбой в хоре можно услышать мгновенно, а в продуктовой разработке его часто приходится вычислять по косвенным сигналам.
Главная мысль интервью проста и неприятна для поклонников команды из одних «звёзд»: двадцать солистов не образуют хор. В проекте так же. Если каждый специалист отлично выполняет свой участок, но не понимает, что делают соседние команды, проект становится набором локально оптимальных решений. В результате аналитики передают требования, которые разработке трудно реализовать в срок, разработчики закрывают технически корректные задачи без нужного бизнес-эффекта, а тестирование получает изменения слишком поздно. Формально все заняты, фактически система не звучит.
Работа Technical Project Manager в этой логике — не роль главного знатока, который раздаёт указания, а настройка взаимодействия между уровнями. Менеджер должен одновременно слышать конкретного инженера, отдельное направление и проект целиком. Это означает замечать перегрузку одного участника, понимать, где потерялась зависимость между командами, и вовремя объяснять общее решение тем, кто видит лишь свой фрагмент. Команда становится устойчивой, когда люди способны подхватить работу коллеги, а отсутствие одного человека не останавливает весь процесс.
При этом синхронность не равна беспрекословному согласию. Скуратович подчёркивает, что руководитель может ошибаться, а аргументированное возражение должно менять решение, если оно сильнее исходной позиции. Но после обсуждения команде всё равно нужна единая договорённость. Нельзя выпускать релиз, в котором каждый участник реализует собственную трактовку требований, так же как невозможно исполнить одно произведение, если каждый голос держит собственный темп. Дискуссия нужна до точки принятия решения, а не вместо неё.
Особенно полезна его формула для планирования: правильная нота, взятая не вовремя, превращается в неправильную. В IT это относится не только к просроченным задачам. Даже качественно реализованная функция может оказаться бесполезной, если она пришла после маркетинговой кампании, без подготовленной инфраструктуры, без тестов или в момент, когда бизнес уже изменил приоритет. Поэтому управление сроками — не соревнование за красивый процент выполненных задач, а проверка готовности связанных частей системы к одному моменту.
В хоре дирижёр слышит сбившуюся партию сразу. В разработке нужны метрики, наблюдение за их динамикой и регулярные разговоры с командой. Одних цифр недостаточно: они не всегда покажут, что между аналитиками и инженерами накопилось напряжение или что одна команда перестала понимать контекст другой. Для этого и нужны ретроспективы — не как обязательный ритуал в календаре, а как способ найти сбой связи до того, как он станет срывом сроков или конфликтом на релизе.
Сравнение с партитурой также полезно для обсуждения ТЗ. Хорошее описание задачи не пытается заранее прописать каждый жест исполнителя. Оно фиксирует замысел, ограничения и критерии результата, но оставляет пространство для адаптации к реальной среде. В музыке на исполнение влияют состав хора и акустика зала; в продукте — существующая архитектура, доступные специалисты, интеграции и изменения у заказчика. Проверка среды до запуска похожа на pre-production verification: дешевле обнаружить проблему до выхода, чем объяснять её пользователям после.
Для российских разработчиков и руководителей эта история скорее напоминание о базовой, но часто игнорируемой вещи. Техническая экспертиза важна, однако проект начинает двигаться предсказуемо только тогда, когда команда договорилась о темпе, границах ответственности и способе поднимать проблемы. Чем сложнее продукт и больше зависимостей, тем ценнее менеджер, который умеет соединять эти голоса в общий результат — не подавляя сильных специалистов, а помогая им вовремя услышать друг друга.