Кажется, что при создании сложных инженерных систем разработка создает технологию, а продукт упаковывает ее для заказчика. У каждой команды своя зона ответственности. На самом деле всё не так просто.
Мы в «Фалькон Тех» уже 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 хотя бы для крупных задач, чтобы было понятно, кто отвечает за решение, а кого достаточно проинформировать;
ввести короткую еженедельную синхронизацию между продуктом и разработкой — для быстрой сверки по текущим задачам и рискам;
раз в квартал устраивать совместные воркшопы: разработка рассказывает о технических ограничениях и возможностях, продукт объясняет, куда движется компания.
Мы в «Фалькон Тех» прошли этот путь на своих проектах, но не останавливаемся и постоянно улучшаем процессы. Даже при отлаженной модели среда сложных инженерных систем часто подкидывает новые вызовы, которые нельзя предугадать заранее.
А как у вас устроено взаимодействие между продуктом и разработкой?
