Как создать цифровой продукт с гибридной командой и не сойти с ума 

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

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

Что такое гибридная команда и почему это не просто аутсорс разработка

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

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

И вот вы должны всем этим управлять.

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

Включайте здоровое недоверие с первого дня

Есть хорошая новость: в IT-нише роли более-менее стандартизированы. Когда вы приходите на проект как проджект, вам не нужно объяснять разработчикам и тестировщикам, кто вы и почему они должны отвечать на ваши вопросы. Есть команда, есть PM — вот структура, с которой все знакомы. Примерно того же мы привыкли ожидать и в контексте остальных участников команды. 

Но есть нюанс.

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

Почему непросто с этим работать:

• Страх перед сторонним ресурсом: возникает ложное ощущение, что раз человека нанял клиент (который сам по себе IT-директор), значит, он точно эксперт и трогать его нельзя. Нет установки проверить человека, потому что он от клиента. Кажется, что сомневаться в его навыках — ставить под вопрос выбор самого заказчика.
• Иллюзия иерархии: штатные сотрудники заказчика часто считают, что их статус «инвестора» дает им право на автономные решения, даже если они идут вразрез с общим процессом.
• Скрытое управление: у людей из сторонних агентств есть свои руководители и свои KPI, которых вам не видно, но которые влияют на их работу.

Не у всех есть привычка сразу включать критическое мышление. А вдруг вы усомнитесь в людях, а окажется, что это вы чего‑то не понимаете? Да и к тому же все эти проверки будут занимать время, а мы тут в огне, вообще-то!

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

Как мягкость может стоить полугода разработки

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

И сначала все вроде было окей, работали потихонечку. Но потом начались странности. Он не отвечал в чатах, игнорировал тикеты в Jira, не реагировал на дедлайны. На созвонах появлялся с одним вопросом: «Есть ко мне вопросы? Озвучьте, пожалуйста. Если нет — я отключаюсь». Единственный человек, с которым он нормально общался — аналитик. Она работала над его функцией, писала документацию по его коду, и он ей доверился. Через нее приходилось ставить задачи и узнавать статус. Так получалось работать какое‑то время – не хотелось сразу рубить с плеча.

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

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

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

Как предлагать помощь в найме и почему это ваша страховка

Для всякой работы нужен подходящий исполнитель. Исполнители из примеров выше, очевидно, для наших задач не подошли. И здесь есть элемент найма в вакууме. Заказчик нанимает специалистов без участия команды, которая будет с ними работать.

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

Решение простое: предлагать помощь в найме.

Не заходите с ноги и фразы «мы знаем лучше». Нужно вкладывать смысл «давайте вместе». Если клиент планирует нанимать фронтендера — пусть ваш тимлид фронта посидит на собеседовании как фасилитатор. Нанимает бэкендера — подключите своего архитектора или сильного бэка. Пару часов их времени — это не космические деньги, но это резко снижает риск получить неадекватного сотрудника.

Иногда клиент откажет. Иногда у него позиция «я сам решууу». Ок. Но предлагать все равно нужно. Зафиксировать, что вы готовы помочь, объяснить риски на примерах.

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

Нестандартные решения и дизайнер в роли владельца продукта

Можно пойти глубже – искать внутренние ресурсы там, где их никто не ожидал увидеть. Особенно, когда ситуация на рынке не самая понятная. 

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

Решение пришло изнутри: роль владельца продукта занял дизайнер, который был на проекте с самого старта. Назовем его Леша. Вот вам и пример того, как проактивность агентства помогает заказчику выйти из наймовой ямы.

Почему внутренний ресурс сработал лучше классического найма:

• Не нужно было притираться к контексту.  Леша уже понимал продукт «от и до», знал бизнес-логику и то, как всё устроено внутри, пока человек со стороны тратил бы месяцы на адаптацию.
• Практическая польза победила пробелы в теории. Леша мог не знать всех академических терминов, но он понимал, как продукт должен зарабатывать и как, например, руками поправить макеты для достижения цели.
• Заказчик понимал, о ком идет речь. Удалось оторваться от привычки искать «человека-методичку» и довериться тому, кто уже показал себя в деле. Всем как‑то сразу стало ясно, что это эффективное решение.

Почему команда из агентства работает не так как штат клиента

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

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

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

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

Почему неумение хватать людей за горло на самом деле спасает проекты

Логичный возникает вопрос: как поженить друг с другом людей в этой всей неразберихе, где у всех своя мотивация (у кого‑то вовсе отсутствующая) и свои методы общения? 

Можно пойти по пути жесткости, как та самая Галина Ивановна, которая стучала указкой по доске, пока вы учились в 4«Б». По ее заветам вы начнете рыться в каждом конфликте, выяснять, кто виноват, раздавать предупреждения, требовать дисциплины. Звучит для кого‑то может и правильно, но чаще всего это способ угробить сначала команду, а потом и проект. Потому что если вы начнете биться за правду в каждой ситуации, у вас не останется времени вести разработку. А люди, которых вы пытаетесь утихомирить и дисциплинировать через жесткость, просто закроются. Или начнут саботировать. Или уйдут, и клиент найдет им замену, которая может оказаться еще хуже.

Другой подход — поиск альтернативных путей. Игнорировать чьи‑то выкрутасы, если результат есть. Искать посредников и компромиссы для тех, с кем по классическому пути не построить связь.

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

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

Короче, тут можно до бесконечности эти примеры приводить. Главное – усвоить, что тут гибкость всякого рода работать будет явно лучше, чем попытки всех построить.

PM — это коммуникатор, которому отчаянно нужны «свои»

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

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

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

Что делать, если вы PM в гибридной команде

Давайте зафиксируем, Работа в гибридной среде — это всегда игра с высокой степенью неопределенности. Никогда не знаешь, где бабахнет. Чтобы во всем этом выжить и принести пользу, стоит придерживаться нескольких принципов, выведенных «кровью» и сорванными сроками.

• Откажитесь от веры в «дано». Не воспринимайте компетенции людей со стороны как аксиому; проверяйте их в деле с первой недели, чтобы не обнаружить джуниора на позиции лида спустя три месяца.
• Транслируйте мягкую силу. В коллективе, где смешаны штатные сотрудники заказчика и несколько агентств, жесткое давление приведет лишь к саботажу. Становитесь медиатором, который объединяет интересы и сглаживает углы.
• Выходите за рамки таблиц и отчетов. В гибридном проекте PM — это прежде всего коммуникатор. Ваша работа — это ежедневный ручной мониторинг настроений, планов и реального прогресса каждого участника.
• Влияйте на найм. Если вы видите, что клиент раз за разом ошибается в людях, предлагайте помощь в фасилитации интервью или ищите ресурсы внутри. Так вы не посягательствуете на власть, а защищаете проект от потери времени.
• Берегите свой внутренний круг. Найдите команду, с которой можно быть собой и обсуждать стратегические моменты вашей совместной работы, чтобы всем было хорошо. Это единственный способ сохранить адекватность, когда в основном на проекте приходится постоянно держать лицо.

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