Почему продукт и разработка не могут работать отдельно друг от друга

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

Мы в «Фалькон Тех» уже 9 лет разрабатываем цифровые решения для умного города на основе видеоаналитики и машинного зрения. В статье рассказываем, почему продукт и разработка должны работать в связке, а не передавать друг другу задачи по цепочке.

Почему конвейерная схема подходит не всем

Может показаться, что оптимальный процесс создания продукта проходит линейно:

Продуктовая команда выявила потребности заказчика и сформулировала требования → разработчики сделали технологию → продуктовая команда приняла ее → передала заказчику.

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

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

Разные реальности. Модель обучают и тестируют в контролируемых условиях: ровный свет, чистая оптика. В реальности всё иначе: освещение в течение дня меняется, добавляются дождь, снег, туман, конденсат на линзе. Объекты на камере перекрывают друг друга, стоят под неудобными ракурсами. В итоге модель с тестовой точностью около 90% в реальных условиях выдает 50% ложных срабатываний.

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

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

Как объединить разработку и продукт

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

На практике это выглядит так:

Шаг 1. Идея рождается у продуктовой команды. Любая новая функция начинается с бизнес-цели или проблемы пользователя. Продуктовые специалисты формируют видение, собирают данные для обоснования и описывают, как фича должна работать с точки зрения пользователя — пока без технической реализации.

Шаг 2. Разработка подключается как консультант. Специалисты оценивают, насколько идея реализуема, какие есть риски и альтернативы. Так продукт не тратит месяцы на нереалистичные или слишком дорогие задумки, а разработка не получает внезапные задачи в спринт в последний момент.

Шаг 3. Задача проходит фильтр готовности к разработке. Прежде чем идея попадет к разработчикам на подробное обсуждение, она должна соответствовать требованиям Definition of Ready — критериям готовности задачи к разработке:

• четкое описание ценности и ожидаемого эффекта;

• сценарии использования;

• понятный сегмент пользователей и их поведение;

• проработанные риски;

• критерии приемки. 

Если условия не соблюдены, задачу не берут в работу. Это экономит время всем командам и минимизирует споры вроде «мы сделали неправильно, потому что вы плохо объяснили требования».

Шаг 4. Груминг превращает задумку в план. Команды вместе декомпозируют идею, уточняют детали. Здесь же формируют Definition of Done — конкретный список условий, при которых задача считается завершенной.

Шаг 5. Задачу включают в общий бэклог. Приоритет определяют совместно:

• со стороны бизнеса — ценность, влияние на метрики, срочность;

• со стороны разработки — риски, зависимости, технический долг, сложность.

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

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

Сергей Сжёнов, руководитель управления продуктового развития в «Фалькон Тех»

Почему не стоит проводить строгую границу между разработкой и продуктом

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

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

Коммуникация с заказчиком становится честнее. Продуктовая команда учитывает технические и ресурсные ограничения и не обещает невозможное. 

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

Сергей Сжёнов, руководитель управления продуктового развития в «Фалькон Тех»

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

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

Как разделить принятие решений

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

Зона разработки — это всё, что связано с технической реализацией функций: например, архитектура, выбор технологий и фреймворков, устройство API, хранение данных. Сюда же входят оценка сложности и рисков (производительности, безопасности, масштабируемости), а также выбор инструментов и инфраструктуры, управление техническим долгом. Продукт может сформулировать требование: например, «нужна высокая доступность». Но как его реализовать — решает разработка. 

Зона продукта — ценность для пользователей, приоритеты, бизнес-требования. Команда формулирует ответы на вопросы «Зачем мы это делаем?» и «Что должно получиться в итоге?».

Есть и общая зона. Часть решений лежит на стыке между продуктом и разработкой: 

• объем MVP: продукт хочет получить максимум функций за короткий срок, разработка показывает, что именно реально сделать быстро и надежно;

• сроки: если реализация оказывается дороже ожидаемого, разработка предлагает альтернативы, а продукт оценивает, насколько они сохраняют ценность для заказчика;

• риски и допущения: продукт фиксирует их с точки зрения бизнеса, разработка — по технической части.

С чего начать, чтобы наладить совместную работу

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

• ввести Definition of Ready и Definition of Done как обязательные фильтры;

• закрепить роли по RACI хотя бы для крупных задач, чтобы было понятно, кто отвечает за решение, а кого достаточно проинформировать;

• ввести короткую еженедельную синхронизацию между продуктом и разработкой — для быстрой сверки по текущим задачам и рискам;

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

Мы в «Фалькон Тех» прошли этот путь на своих проектах, но не останавливаемся и постоянно улучшаем процессы. Даже при отлаженной модели среда сложных инженерных систем часто подкидывает новые вызовы, которые нельзя предугадать заранее.

А как у вас устроено взаимодействие между продуктом и разработкой?