Понедельник, созвон по росту. Команда горячо обсуждает, что попробовать: партнёрские рассылки, короткий онбординг, другую цену на пилот. Все кивают, кто-то записывает что-то в личный документ. Через неделю выясняется, что рассылку уже пробовали в прошлом квартале, результат лежит в чьём-то чате, а онбординг «вроде бы запускали, но не дождались цифр».
Эта статья о том, как превратить такие разговоры в процесс: сформулировать гипотезу так, чтобы её можно было проверить, завести для неё понятное место, назначить ответственных, записать вывод и не потерять его через месяц. В примерах используется Synqo, но сама логика не привязана к инструменту. Все примеры учебные: компании и цифры в них условные.
Почему гипотезы теряются без системы
Гипотезы редко пропадают сами. Их теряют по обычным причинам:
- одна живёт в заметке основателя, вторая в треде мессенджера, третья в таблице, которую открывали дважды;
- у каждой свой формат: у одной есть метрика, у другой только «кажется, должно сработать»;
- результат остаётся в голове того, кто проводил проверку, и уходит вместе с ним в отпуск или из компании.
Последствия предсказуемы. Команда повторяет эксперименты, которые уже закончились ничем. Спорит о выводах, потому что никто не помнит, какой был критерий успеха. Решения принимаются по ощущению, хотя проверка была проведена.
Лечится это двумя вещами: единым форматом гипотезы и единым местом, где видна её стадия. Сначала формат.
Как сформулировать гипотезу, которую можно проверить
Удобная рамка: если — то — потому что.
- Если мы сделаем конкретное изменение,
- то изменится конкретный показатель на конкретную величину,
- потому что у нас есть причина так думать (наблюдение, интервью, данные).
Сравните: «Улучшим онбординг» и «Если сократить онбординг с пяти шагов до трёх, то доля новых пользователей, создавших первый проект за сутки, вырастет с 30 до 40%, потому что в интервью трое из пяти бросили регистрацию на четвёртом шаге». Первое — идея или задача. Второе — гипотеза: её можно опровергнуть.
Критерий успеха и метрику фиксируйте до начала проверки. Если порог определяется после получения цифр, любой результат легко объявить победой. Заранее решите и то, при каком значении гипотеза отклоняется, и когда вы будете считать данные: срок проверки входит в формулировку.
Практическое правило: если нельзя назвать результат, при котором вы признаете гипотезу ошибочной, это ещё не гипотеза.
Отличие от задачи простое. Задача: «переписать текст письма». Гипотеза: «новое письмо поднимет долю открытий». Задача выполняется или нет, гипотеза подтверждается или опровергается. Их полезно хранить раздельно: задачи, которые возникнут из проверки, живут на своих досках.
Структура рабочего пространства для гипотез
Разберём учебный сценарий. Команда из четырёх человек: основатель, продакт, маркетолог и разработчик. Они заводят в Synqo проект «Гипотезы роста». В проекте можно создать несколько досок, но им хватит одной, и возможности Synqo позволяют настроить её под себя: колонки создаются, переименовываются и переставляются.
Колонки отражают стадии жизни гипотезы:
- Идея — записана, но ещё не оформлена по рамке «если — то — потому что».
- В проверке — есть метрика, срок и ответственный.
- Подтверждена и Отклонена — проверка закончена, вывод записан.
- Архив — старые гипотезы, которые не мешают текущему обзору, но остаются доступными для поиска.
Структура карточки гипотезы
- Название: коротко, например «Три шага онбординга вместо пяти».
- Описание: формулировка «если — то — потому что», исходные данные, порог успеха и порог отказа.
- Срок: дата, к которой нужно принять решение.
- Ответственный: назначенный участник.
- Приоритет и метки: приоритет для очереди проверки, метки для канала или типа результата.
- Чек-лист: шаги проверки.
Допустим, гипотеза о новом канале привлечения. Чек-лист в карточке: «Определить аудиторию и бюджет теста», «Запустить объявление», «Собрать данные через 14 дней», «Сравнить с порогом из описания», «Записать вывод комментарием». Срок стоит на дне сбора данных. На еженедельном созвоне команда открывает доску и смотрит не на разговоры, а на колонку «В проверке»: карточка с просроченным сроком и незакрытыми пунктами сразу показывает, что застряло и на каком шаге.
Колонку «В проверке» разумно ограничить договорённостью, например не больше трёх гипотез одновременно. Это практика команды, а не автоматическая функция: Synqo не заблокирует четвёртую карточку, поэтому правило нужно держать самим.
Кто за что отвечает при проверке гипотез
В Synqo права определяются проектом, и ролей четыре: владелец, администратор, участник, гость. Ролей «проверяющий» или «ответственный за результат» в системе нет. Это договорённости команды, и их стоит записать.
Рабочая схема для нашей команды:
- Ответственный — тот, кто назначен на карточку и доводит проверку до вывода.
- Проверяющий — другой человек, который читает вывод и решает, достаточно ли данных. Например, продакт проверяет выводы маркетолога. Так автор эксперимента не оценивает сам себя.
- Решение о переносе в «Подтверждена» или «Отклонена» принимает проверяющий, а не автор.
Для внешних консультантов и инвесторов подходит роль гостя. Гость видит доступные задачи и может комментировать, но не создаёт, не меняет и не перемещает задачи и колонки. Консультант оставит вопрос к методике, а статус карточки случайно не сдвинет.
Ограничение: гостевой доступ определяется проектом и не открывает остальные приватные проекты рабочего пространства. Обещать доступ к отдельным карточкам или части доски не стоит: если в «Гипотезах роста» лежит то, чего инвестору видеть не нужно, это решается составом проекта, а не выборочным доступом. Сколько гостей и участников можно добавить, зависит от тарифа.
Как фиксировать результаты и не терять выводы
Карточка полезна, только если в ней остаётся вывод. Три привычки.
Комментарий-вывод. Закончив проверку, ответственный пишет один структурный комментарий: что измерили, какое значение получили, как оно соотносится с порогом, что делаем дальше. История изменений в карточке сохраняет, кто и когда что менял, поэтому через полгода видно, не сдвигали ли срок или описание задним числом.
Метки результата. Колонки «Подтверждена» и «Отклонена» не покрывают третий случай: данных мало, результат неоднозначный. Для него заведите метку «неоднозначно» и добавьте к ней комментарий о том, чего не хватило. Метки подтверждения и отклонения можно дублировать на карточках в архиве, чтобы потом искать по ним.
Регулярный обзор. Доска без ритуала быстро превращается в кладбище. Выберите фиксированное время, например полчаса раз в неделю, и проходите колонки справа налево: что закрыто и записано, что просрочено, что можно взять в проверку из «Идей». Регулярность важнее красоты доски: Synqo показывает этапы, но сама по себе доска производительность не повышает.
Практическое правило: гипотеза не покидает «В проверке», пока в карточке нет комментария-вывода.
Перенос гипотез из других инструментов
Если гипотезы уже живут в другом сервисе, Synqo умеет импортировать данные из Trello, OTask и Kaiten. Важная особенность: импорт создаёт новый приватный проект с досками. С существующим проектом данные не объединяются.
Учебный пример. Команда вела гипотезы в Trello: по доске на каждый спринт. Порядок действий:
- Экспортирует данные Trello в JSON-файл и запускает импорт. Для скачивания вложений могут понадобиться API-данные.
- Получает отдельный приватный проект с досками по спринтам.
- Просматривает импортированные карточки и отбирает актуальные: гипотезы в проверке и те, чьи выводы пригодятся.
- Вручную переносит их в основной проект «Гипотезы роста», приводя к формату «если — то — потому что» и раскладывая по колонкам.
- Проверяет вложения в каждой перенесённой карточке: что подгрузилось, а что нужно приложить заново.
- Когда нужное перенесено, импортированный проект остаётся архивом или удаляется по решению команды.
Скачивание вложений при импорте зависит от тарифа и недоступно на бесплатном плане, поэтому полный перенос любых данных заранее обещать нельзя. Перед миграцией проверьте поддерживаемый формат и свои настройки, а условия сверьте на странице тарифов Synqo. Проверить результат просто: возьмите три-четыре важные гипотезы и сравните карточки с исходными по описанию, чек-листам, комментариям и файлам.
Частые ошибки при ведении гипотез в команде
Гипотезы и задачи на одной доске. «Обновить лендинг» стоит рядом с «Если сократить форму, конверсия вырастет». Обзор превращается в кашу. Гипотезы держите в своём проекте, а порождённые ими задачи ведите на отдельной доске.
Нет срока проверки. Гипотеза без даты висит в «В проверке» месяцами и создаёт иллюзию работы. Срок обязателен, а при его переносе причину записывают комментарием.
Нет финального статуса. Эксперимент закончился, все «вроде всё поняли», карточка осталась на середине. Через квартал идея вернётся как новая. Правило простое: каждая карточка заканчивается в «Подтверждена», «Отклонена» или с меткой «неоднозначно» и выводом.
Порог после результата. Критерий успеха придуманный задним числом обесценивает всю проверку.
Дальше можно выбрать одну живую гипотезу, оформить её по рамке и провести через доску до вывода. Другие материалы о командной работе собраны в блоге Synqo.
Итог
Система ведения гипотез держится на четырёх вещах: проверяемой формулировке, понятной стадии на доске, договорённостях о проверяющем и записанном выводе. Начните с одной доски и одной гипотезы, а остальное добавляйте, когда увидите, где процесс скрипит.
Как выбрать, какие гипотезы проверять первыми
Когда в «Идеях» накапливается десяток карточек, возникает вопрос очереди. Если выбирать по настроению, в проверку попадают гипотезы самого громкого участника. Нужен критерий, который команда договорилась применять одинаково.
Практичная схема: оценить каждую гипотезу по трём вопросам.
- Ожидаемый эффект. Насколько сдвинется метрика, если гипотеза верна? Оценка грубая, достаточно «мало / заметно / существенно».
- Уверенность. Есть ли за гипотезой данные или интервью, или это только предположение? Пункт «потому что» в формулировке подсказывает ответ: если он пустой, уверенность низкая.
- Стоимость проверки. Сколько дней и чьих усилий потребуется, чтобы получить вывод.
Результат фиксируется в поле приоритета карточки. Synqo поддерживает приоритеты, но сам их не рассчитывает: оценку команда проводит вручную, а в карточку записывает итог и кратко обосновывает его в описании.
Учебный пример: выбор из трёх гипотез
Условия. Команда из четырёх человек может вести не больше трёх проверок одновременно (договорённость по колонке «В проверке»). В «Идеях» лежат пять оформленных гипотез. Свободных слотов два: третий занят экспериментом с ценой, который закончится через неделю.
Действия команды:
- Продакт заранее выносит на созвон только гипотезы с заполненным «потому что». Две карточки без обоснования возвращаются на доработку, и ответственные дописывают наблюдения или данные.
- Оставшиеся три оцениваются по трём вопросам. Каждый участник ставит оценки отдельно, затем сравнивают расхождения. Если оценки сильно различаются, это сигнал, что у людей разное понимание гипотезы, и формулировку нужно уточнить.
- В проверку уходят две гипотезы с лучшим сочетанием эффекта и стоимости проверки. Третья остаётся в «Идеях» с комментарием, почему она отложена и при каких условиях к ней вернутся.
Критерий решения: в проверку попадает не самая интересная гипотеза, а та, которая быстрее всего даст вывод, способный изменить следующий шаг команды. Если результат не повлияет на решения, проверка бесполезна, даже когда гипотеза нравится всем.
Практическое правило: отложенная гипотеза должна получить комментарий с причиной. Иначе через месяц команда снова обсудит её с нуля.
Что делать с неоднозначными и сорвавшимися проверками
Не каждая проверка завершается чистым «да» или «нет». Заранее договоритесь, как действовать в трёх типовых ситуациях.
Данных недостаточно. Срок наступил, но выборка слишком мала для вывода. Не двигайте карточку в «Подтверждена» и не закрывайте её молча. Допустимы два решения: продлить срок один раз, записав в комментарии новую дату и причину, либо завершить проверку с меткой «неоднозначно» и описать, чего не хватило. Лимит на продление (например, один раз) защищает от бесконечного ожидания.
Условия изменились по ходу. Во время проверки поменялась цена, сайт или аудитория, и результат нельзя отнести к исходной гипотезе. Фиксируйте это комментарием с датой. Если изменение существенно, закройте карточку как неоднозначную и создайте новую гипотезу с обновлёнными условиями, указав в описании ссылку на прежнюю карточку. История изменений в карточке покажет, что именно менялось и когда, а комментарии объяснят почему.
Ответственный недоступен. Человек ушёл в отпуск или переключился на срочную задачу. Проверяющий на обзоре замечает просроченный срок и решает: передать карточку другому участнику или приостановить проверку. Смена ответственного сопровождается комментарием, где перечислено, что уже сделано по чек-листу, чтобы новый человек не начинал заново.
Общая логика: любое отклонение от плана оставляет след в карточке. Устное «договорились» через две недели никому не поможет, а запись с датой и причиной помогает.
Как проверить, что процесс работает
Через месяц после старта полезно провести короткий разбор самой системы, а не отдельных гипотез. Достаточно сверить доску с несколькими вопросами.
- Есть ли в «В проверке» карточки без срока или без ответственного? Если есть, формат не соблюдается.
- Сколько карточек закрыто выводом, а сколько просто исчезло из колонки? Вторые указывают на разрыв в правиле «без комментария-вывода карточка не уходит».
- Нашёл ли кто-нибудь в архиве прошлый результат и использовал его при новом решении? Это главный признак пользы: система нужна, чтобы повторно использовать знание.
- Не превратилась ли колонка «Идеи» в склад? Если карточки лежат без движения, раз в месяц просматривайте их и либо оформляйте, либо переносите в архив с пометкой.
Для разбора достаточно двадцати минут на обычном обзоре. Если вопросы вскрыли проблему, меняйте одно правило за раз: добавьте обязательное поле в шаблон описания, сократите лимит одновременных проверок или перенесите обзор на другое время. Когда меняется сразу всё, непонятно, что помогло.
Сам формат карточки тоже можно пересматривать. Если команда заметила, что порог отказа постоянно забывают указывать, поставьте эту строку в начало описания. Если никто не использует метки каналов, уберите их. Доска должна отражать то, что команда действительно проверяет, а не накапливать поля, которые никто не заполняет.
