Запуск проекта в маленькой команде: не пишите требования, сначала составьте список предположений

Начните с одного вопроса: почему вы считаете, что этот проект сработает?

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

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

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

Категоризация предположений: не только технические

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

1. Пользовательские предположения: Действительно ли пользователям нужна эта функция? Готовы ли они платить? Существует ли сценарий использования?
2. Технические предположения: Будут ли библиотеки, API или алгоритмы работать как ожидалось? Каковы узкие места производительности?
3. Бизнес-предположения: Разумна ли структура затрат? Будет ли принята цена? Смогут ли каналы охватить целевых пользователей?
4. Ресурсные предположения: Будут ли ключевые люди доступны вовремя? Смогут ли внешние зависимости (например, сторонние сервисы) выполнить в срок?

У каждого типа разные профили риска. Пользовательские предположения проверять дешевле всего — интервью или прототип, но их часто игнорируют. Технические предположения могут быть дорогими (нужен демо-прототип или POC). Бизнес-предположения следует проверять рано, но многие команды ждут запуска.

Фреймворк принятия решений: матрица приоритетов предположений

Невозможно проверить все предположения, только самые критичные. Как выбрать? Два измерения: неопределённость и влияние.

• Неопределённость: насколько вероятно, что предположение неверно? Ниже 50% считается высокой неопределённостью.
• Влияние: если предположение ошибочно, провалится ли проект или потребует серьёзной переделки?

Нанесите предположения на матрицу 2x2:

• Высокая неопределённость x Высокое влияние: Фатальные предположения — проверять в первую очередь.
• Высокая неопределённость x Низкое влияние: Можно быстро проверить или отложить.
• Низкая неопределённость x Высокое влияние: Если ошибочно, влияние велико, но вероятность мала — подготовьте запасной план, но не вкладывайте много в проверку.
• Низкая неопределённость x Низкое влияние: Игнорировать.

На практике маленькой команде обычно нужно выявить 3-5 фатальных предположений и потратить 1-2 недели на их проверку. Если проверка не удалась, проект следует приостановить или изменить направление, а не продолжать.

Как проверять предположения? Минимальный дизайн проверки

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

Пример: Предположение, что пользователи будут открывать приложение три раза в день

• Проверочный вопрос: Действительно ли у пользователей есть потребность проверять несколько раз в день?
• Метод проверки: Создайте простую лендинговую страницу с описанием основной функции и наблюдайте за конверсией в регистрацию или предзаказ. Или проведите личные интервью, где пользователи опишут сценарии использования.
• Критерий успеха: 80% опрошенных говорят «я бы использовал ежедневно» или конверсия лендинга > 5%.

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

Шаблон журнала предположений

При запуске проекта команда может провести 30-минутное совещание по выявлению предположений. Каждый записывает свои предположения, затем они категоризируются и ранжируются. Итог — журнал предположений:

Этот журнал должен быть частью проекта и регулярно обновляться.

Риски проверки предположений

Но сама проверка тоже несёт риски.

1. Чрезмерная проверка: Если каждое предположение требует точного эксперимента, проект никогда не начнётся. Проверяйте только фатальные.
2. Склонность к подтверждению: Команда может искать только положительные доказательства и игнорировать негативные сигналы. Решение: до проверки запишите «что заставило бы нас считать предположение недействительным» и строго следуйте критериям.
3. Устаревшие предположения: Внешние условия или потребности пользователей могут измениться в ходе проекта. Пересматривайте журнал предположений регулярно (например, каждые две недели или на вехах).

Когда остановиться?

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

Итог

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

PaxLee