Ключевые уроки Райана Сингера по ускорению разработки продуктов – бизнес программного обеспечения

В БС Европа 2025, Райан Сингер, автор книги Shape Up, открыл конференцию, затронув одну из самых актуальных проблем в разработке продуктов: как мы используем свое время.

Его разговор, «Формирование и тяжелые разговоры» речь шла не о том, как повысить продуктивность или выжать больше часов из и без того утомленных команд. Речь шла о чем-то гораздо более фундаментальном: как использовать наше время и понять, что мы на самом деле пытаемся решить.

У Райана есть способ заставить вас осознать, что половина стресса, который мы испытываем при разработке продукта, возникает из-за погони за проблемами, которые мы не определили должным образом. Мы бросаемся в поиск решений, объем расширяется, инженеры остаются заблокированными, и вдруг все заняты… но на самом деле ничего не движется.

Он напомнил нам, что самое ценное, что мы можем сделать, — это замедлиться настолько, чтобы правильно сформулировать проблему.

1. Создание х формирование, проблема х решение

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

• Обрамление: Это восходящая работа, ориентированная на спрос. Формулирование означает сужение проблемы или возможности, понимание точки зрения клиента и выяснение «зуда, которое мы пытаемся унять». Это стратегический фокус.

• Формирование: Это следует за структурированием и находится на стороне решения. Формирование включает в себя создание плана или концепции здания, того, что вы на самом деле собираетесь построить. Четко определив структуру (проблему), вы получаете ясность относительно того, что важно делать дальше, что затем определяет решение (форму).

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

2. Соблюдайте время

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

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

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

“Этот двухнедельный спринт является деталью реализации машины по производству колбас. Знаете, это просто то, как работает машина. Это не стратегическая единица времени”.

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

3. Перейдите на сторону спроса (формирование), чтобы определить истинную проблему

Запросы часто поступают в виде предлагаемых решений (сторона предложения), например «нам нужны уведомления» или «нам нужен календарь».

Чтобы вести этот трудный разговор, Райан советует перевернуть взгляд на сторону спроса:

• Сторона спроса спрашивает: В чем проблема? С чем люди борются? Почему сейчас подходящее время?

• Сторона предложения относится к: Что мы строим? (Идея решения).

4. Пересечение реки для понимания мотивации клиентов

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

Человек, делающий запрос, находится на одной стороне (текущий контекст), пытаясь достичь другой (желаемый результат). Сам запрос (например, «Мне нужен календарь») — это всего лишь предлагаемый мост.

Цель фрейминга — привязать разговор к реальности:

• Контекст (текущая реальность): Что происходит? Что люди чувствуют сегодня? Что не работает?

• Результат (желаемый прогресс): Если бы все было по-другому, как бы мы узнали? Как бы мы могли определить, было ли все лучше?

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

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

5. Фрейм — это макромодульный тест

Четкая формулировка обеспечивает критерии успеха и завершения работы команды разработчиков. Без четкой структуры, когда возникают технические трудности, команды не могут пойти на компромисс и вместо этого часто прибегают к кипячению океана, что приводит к постоянному расширению масштабов.

Рамка действует как макро-юнит-тест для всего проектачто позволяет командам судить, когда подход к решению (форма) нуждается в корректировке.

Райан также приводит цитату (позаимствованную у Боба Моэсты), подчеркивающую важность контроля объема в отношении затрат времени: «Вы не можете положить 10 фунтов грязи в пятифунтовый мешок».

“Я хочу отметить, что когда мы сузили проблему, когда мы проделали эту работу по созданию структуры, это не только помогает нам прийти к более простой идее решения. Это не только помогает нам тратить меньше времени и при этом утолить зуд. Это также очень помогает, когда мы находимся внутри временных рамок, когда команда на самом деле должна работать над этим и строить”.

6. Стратегический фокус управления продуктом — создание структуры

На этапе сборки командам разработчиков необходима ясность на трех уровнях:

1. Рамка: Проблема/зуд при почесывании (самая большая высота).

2. Форма: Концепция того, что строится.

3. Выполнение: Код и детали конструкции (самые низкие, наиболее конкретные).

Такое возвышение позволяет строителям принимать творческие решения и идти на компромиссы.

В конце своего выступления Райан остановился на ролях внутри организации. Хотя менеджеры по продукту (PM) часто стремятся определить стратегию, общая стратегия принадлежит исполнительному уровню.

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

Выступление Райана стало напоминанием о том, что ясность — это не роскошь в разработке продукта, это основа. Когда мы правильно формулируем проблемы, трудные разговоры становятся легче, команды быстрее объединяются, и работа, наконец, снова начинает ощущаться значимой.

Это заставляет нас задаться важным вопросом: где мы путаем движение с прогрессом?

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