Руководитель технической команды должен понимать два языка — «айтишный» и «клиентский». Это помогает улаживать конфликты, создавать качественные продукты и оценивать решения в техническом и бизнес-контексте.
Development Manager в Oracle Александр Гриценко 10 лет управляет техническими командами, которые создают продукты в сферах финансов, производства, телекома и безопасности. Director Of Engineering в GlobalLogic Александр Свиденюк за 12 лет в техническом менеджменте также сменил несколько доменов и может руководить командами без привязки к технологиям.
Накануне старта их курса «Управление техническими проектами» в Laba мы узнали, в чем специфика работы с техкомандами, как объединять специалистов с разным опытом и сохранять их мотивацию при сложных компромиссах с клиентами.
— Чтобы управлять командой технарей, руководителю нужен опыт программирования?
Александр Свиденюк: Опыт разработки встраиваемых систем помог мне перейти на роль project-менеджера в том же домене. Я понимал, что нужно клиенту, какие вопросы задавать команде, как ставить задачи и контролировать их выполнение. Но вскоре пришел к выводу, что технический бэкграунд — это еще и ограничение. Я разбираюсь в одном домене — но буду ли эффективным в другом? Поэтому сфокусировался на развитии менеджерских скилов.
За 10 лет в техническом менеджменте я сменил четыре домена. Моего опыта было бы недостаточно, чтобы стать архитектором в каждом из них, но я могу предметно общаться со специалистами. А главное — управлять командами без привязки к технологии (если есть технический эксперт, на которого можно положиться).
Когда клиент спрашивает: «Почему вы задержали релиз?», РМ должен ответить аргументированно. Моя стратегия — садиться рядом с разработчиками и «вкапываться» в суть проблемы вместе с ними. Это полезно и специалистам — когда что-то объясняешь, сам находишь лучшие решения. А я погружаюсь в техническую часть, архитектуру, логику, проблемы команды — и могу объяснить их клиенту.
Александр Гриценко: Как и Саша, я начинал с разработки. Перейти от кодинга к менеджменту 12 лет назад мне помог хороший английский: тогда существовало меньше специалистов, которые им владели, а для клиента это было критично. Последний код написал в 2017 году.
Но технический бэкграунд необходим. Например, в Oracle без него даже не собеседуют кандидатов на позиции project-менеджеров. Сложно представить, как вести IT-проекты, не зная ни строчки кода. Руководитель — это со-архитектор: он отвечает за выбранное командой техническое решение. Еще опыт программиста помогает мне автоматизировать рутинные менеджерские операции — например, написать простой PHP-скрипт и быстро обработать проектные данные.
Я считаю, что отсутствие технического опыта можно компенсировать обучением. Например, мы часто слышали от студентов курсов по project-менеджменту: «Окей, я прочитал PMBoK. А как применить это на практике?». На нашем курсе технического менеджмента в Laba мы научим ориентироваться в архитектуре и технике, разговаривать с технарями на одном языке и валидировать командные решения.
— Какие soft- и hard-скилы критичны в техническом менеджменте?
Александр Свиденюк: В IT нечасто применяется директивный менеджмент (за редким исключением — например, когда жесткие дедлайны или команда запуталась). Зачастую лидер помогает специалистам решать проблемы и стать единой силой на пути к цели.
Среди технарей дефицит экспертизы встречается реже, чем нехватка навыков коммуникации и эмпатии. Хороший РМ помогает наладить каналы связи, построить отношения, создает комфортные условия, инструменты и правила, чтобы люди не отвлекались от технических задач. Например, когда команда проходит через стадию шторминга — координирует распределение ролей и обязанностей, решение конфликтов, прояснение взаимных ожиданий.
Клиент и команда часто говорят на разных языках — бизнеса и программирования. РМ должен понимать оба и быть неким «переводчиком». С одной стороны — объяснить команде потребности заказчика, например, почему он сейчас не готов вкладываться в технический долг, но хочет реализовать новую фичу. С другой — защитить перед клиентом позицию команды, почему она настаивает на развитии архитектуры и каких проблем хочет избежать.
Александр Гриценко: Правильный РМ не занимается микроменеджментом, но создает ограничения в пределах всего проекта, которые помогают работать эффективнее.
Project-менеджеру не нужен большой опыт кодинга на каком-то языке. Технологии быстро устаревают. И если он программировал на PHP, а команда пишет на Java, — его навыки нерелевантны. Развивайте общую техническую компетентность (technical competence) и обогащайте технический лексикон (technical language) — на уровне понимания терминов и принципов работы систем.
Например, когда программист говорит: «Здесь нужен логин, а там в этом сервисе надо сделать тройную репликацию» — менеджер должен быстро понять, необходимо это делать или нет, когда и как встроить такие задачи в работу над проектом.
Изучите архитектуру предприятия (enterprise architecture) — это помогает разложить большой проект на «технические кубики».
Одна из важных задач РМ — создание «бэкапа» экспертизы в команде. Нужно разделять зоны ответственности — и нельзя, чтобы каждую область покрывал единственный специалист: если он уйдет, проект потеряет устойчивость. Необходимо учить команду быть кросс-функциональной, чтобы по максимальному перекрывать сценарии зависимости от одного человека.
Также РМ`у полезно уметь работать с графическими нотациями (например, UML, BPMN). Это удобно: построили диаграмму, посмотрели на нее с командой и быстро выяснили: проблема — на шаге №18, «нужна дополнительная защита». Умение рисовать и читать схемы помогает быть на одной волне с технарями.
Проблемы, с которыми сталкивается project manager
Подписаться на подкаст «Умных любят»
— Нужна ли РМ`ам сертификация?
Александр Свиденюк: Это как погоны. Позволяет «открыть двери» — впервые заявить о себе. Но только работа проявит квалификацию РМ`а и его способность «вытащить» проект.
Например, мне сертификация помогла систематизировать разрозненные знания по менеджменту. Но работодатели ни разу не попросили показать сертификат — до начала сотрудничества работают рекомендации, во время — результаты.
— Как РМ помогает техкоманде находить правильные решения? И оценивать их — ведь он не знает техническую часть глубоко.
Александр Гриценко: Если менеджер навязывает решения команде, то часто это приводит к проблемам: сотрудники вешают всю ответственность за фейл задачи на РМ`а («ну ты ж нам сказал так делать, ты начальник, мы сделали»). Поэтому команда должна генерировать предложения сама. А роль менеджера — помогать людям взаимодействовать и валидировать готовые решения.
Например, в одном из проектов возникла техническая проблема: не удалось вовремя пофиксить отдельный элемент продукта (платформы). Я предложил девелоперам и старшему архитектору пройти по моему обычному алгоритму для данной ситуации: сгенерировать несколько решений, выписать для каждого из них pros and cons, вернуться ко мне с результатами.
Мы вместе взвесили три решения: сложно ли имплементировать каждое в систему, есть ли у команды нужные скилы и технологии. Оказалось, в первом случае придется пройти бюрократическую проволочку (много времени). Во втором — получить ряд апрувов на использование технологий (время и человеческие ресурсы).
Третье решение позволяло справиться с задачей оперативно, избежать сложностей — нужно просто изменить код продукта, чтобы не приходилось чистить кэши. С учетом дефицита времени и срочности выбрали последнее.
Составляйте чек-листы проблем, с которыми сталкивается команда. Например, продукт не выдерживает нагрузку в несколько тысяч пользователей или не работает с мобильными девайсами. Тогда при разработке нового решения уже известны пункты, которые нужно проверить и «поставить галочки».
— Как помочь технической команде и клиенту найти общий язык, когда их позиции отличаются?
Александр Свиденюк: Хороший РМ должен понимать мотивы и аргументы сторон.
Например, команда предлагает использовать в разработке последний стандарт технологии. Вписывается ли это в бизнес-контекст? Если дело в личном интересе специалистов, их стремлении к развитию — отлично, но актуально ли сейчас для клиента? Есть ли ресурсы на эксперименты ради качества? Или приоритетны стабильность и сроки?
Рациональное предложение команды РМ презентует заказчику. Какие бенефиты даст переход на эту технологию? Причем разным представителям клиента интересны свои аспекты. Архитектору можно «продать» поддерживаемость новых языков. А СЕО — сколько денег реально сэкономить на поддержке продукта и как он поможет развивать бизнес.
Нельзя сообщить команде «в лоб»: «Ребята, “улучшалки” архитектуры, над которыми вы долго работали, больше не нужны клиенту. Теперь он хочет через два месяца “выкатить” готовый продукт — поэтому забываем все и работаем в овертайме над этим». Мотивация скатится до нуля.
Но можно объяснить команде бизнес-контекст клиента: стартап должен показать результат, чтобы достичь следующего уровня инвестиций. Есть два варианта: продавливать свое решение или помочь заказчику сохранить проект, а затем — вернуться к переговорам.
Александр Гриценко: Почти всегда можно найти компромисс между ожиданиями клиента и возможностями команды.
В одном из проектов заказчик поставил задачу — за два месяца «запилить» новый продукт, но вписаться в такие сроки было нереально. Нам нельзя было просто сказать — «Мы не можем это сделать». Нужно оценить свои ресурсы, составить список и говорить с позиции того, что команда способна выполнить к сроку.
Если РМ разговаривает с клиентом на языке бизнес-показателей — обычно аргументация работает. Когда заказчик говорит, что ему все равно, — он берет риски на себя, и это тревожный знак: скорее всего, виноватой все-таки останется команда, а проект «прогорит».
— Как помочь сработаться новой технической команде?
Александр Свиденюк: Все коллективы проходят через одинаковые сложности — люди не понимают свои роли, кто в чем силен, а где потребуется помощь. Но в технических командах процессы усложняют еще и споры в части технологий — особенно если есть два сильных эксперта. Некоторым компаниям проще избежать столкновения авторитетов — нанять одного топового специалиста и много джунов ему в помощь. Но по моему опыту, продукты усложняются, а значит, и команды нужны более «синьорные».
Например, мы в GlobalLogic запускали большой проект в автомотиве с польскими коллегами. В удаленной кросскультурной команде были сильные эксперты с разным опытом, они не могли договориться о выборе архитектурного решения. Мы сплотили коллектив не только вокруг общей цели, но и против внешней проблемы: если не определимся с архитектурой за 2–3 недели — то сорвем дедлайны и проект провалится. Собрали общее онлайн-совещание, включили камеры, пошерили экраны. Каждая команда презентовала свой подход и дала высказаться коллегам.
Мы попросили привести максимум аргументов и примеров — как решения работали в прошлых проектах. И произошла метаморфоза: непонятные люди «с той стороны» превратились в специалистов с полезным опытом, решавших задачи, с которыми другие пока не сталкивались.
Мы поощряли детальные вопросы сторон: «А что случится с вашей архитектурой, если у продукта будет 5 тыс. пользователей?», «А если связь прервется?». И приняли решение команды, у которой было больше ответов (с доработкой): оно оказалось устойчивее к нашим челленджам.
РМ должен понимать людей не только как специалистов, но и как личностей: кто эффективно работает вместе, а кого лучше «развести». Конфликт рождается, когда есть много мнений и не очевидно, какое правильное, — выслушайте всех и помогите найти консенсус. Если кто-то победит, а кто-то останется неуслышанным, это не исчерпает конфликт, а просто отсрочит его.
Александр Гриценко: Но иногда менеджеру приходится сознательно исключать кого-то из дискуссии — когда деструкция слишком сильная, нет аргументов, но есть риск потерять качество или команду.
Александр Свиденюк: Согласен. РМ — как врач: что-то можно вылечить, а если нет — приходится удалить. Мастерство в том, чтобы отличить одно от другого.
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
— Какие функции следует автоматизировать руководителю техкоманды, чтобы освободиться от рутины?
Александр Гриценко: В первую очередь — все процессы, касающиеся кода. Обязательно установить static code analysis — это помогает находить чреватые «крашами» ошибки, которые люди могут упускать. Нужна страховка: покрытие юнит-тестами позволяет создавать более стабильный продукт. Поддерживать качество кода помогает автоматизация мержирования — простые механизмы типа невозможности добавить изменение в общую ветку, если в части кода есть ошибка.
Но автоматизировать нужно с умом. Для некоторых задач необходим и минимальный ручной контроль. Например, если система аллертинга (оповещений) аккумулирует все ошибки в одну — специалист должен убедиться, что исправил проблему на всех участках.
Александр Свиденюк: Автоматизируйте все действия, которые часто повторяются и не требуют интеллектуальных усилий — такие как сбор, анализ и отправка отчетов.
Например, по правилам проекта руководитель должен апрувить все решения, но когда все замыкается на одном человеке, это часто приводит к задержкам. Я подготовил нескольких людей в команде, которые способны выполнять часть этих функций и на которых я могу положиться, а также написал скрипт для автоматического апрува их решений. Процедуры важны, но руководитель не должен становиться «бутылочным горлышком» и замедлять команду из-за своей загрузки.
Менеджер не всегда физически способен пропустить через себя все задачи. Например, на одном из моих проектов было 200 специалистов, количество тасков в неделю — 1000+. Я создал ключевые метрики качества работы, настроил фильтры и оповещения — система сообщает, если происходит сбой (например, просрочены задачи в JIRA).
— Чем отличается технический менеджмент на ремоуте?
Александр Гриценко: Я давно работаю с удаленными командами из Украины и Индии. А теперь это стало новой нормой — в Oracle, как и во многих IT-компаниях, решили перейти на гибридный формат работы.
На ремоуте нужно уделять больше времени фиксации планов и задач в общем доступе — например, я хочу знать графики коллег не для микроменеджмента, а чтобы не отвлекать их от встреч.
Стараюсь чаще проводить 1-на-1: удаленно сложнее заметить, что человек начал выгорать, и предупредить увольнение/выгорание. В целом IT-индустрия привычнее к распределенной работе — зачастую людям не нужен контроль, они взрослые, несут ответственность за свои результаты, не пытаются отлынивать и делать меньше за те же деньги.
Александр Свиденюк: Даже наоборот — по моим наблюдениям, с переходом на «удаленку» многие стали работать больше. Поэтому одна из задач менеджера на ремоуте — отправить спать тех, кто засиделся в ночи.
На удаленке важно настроить правильные каналы связи онлайн. Чтобы люди, привыкшие работать рядом, не теряли контакта. Но в технической команде встречи не должны «выдергивать» из потока, столь важного в работе программистов.
