Я часто ошибаюсь: метод шести шагов Бориса Черного для работы над продуктом

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

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

Шесть шагов

Свой подход практически к любой проблеме Черни описывает так:

1. Понять доступную информацию. Прежде чем что-либо решать, разберитесь с тем, что уже известно: данные, ограничения, предыдущие попытки.
2. Собрать недостающую информацию. Явно перечислите пробелы и закройте их, пока они не превратились в сюрпризы посреди реализации.
3. Определить проблему. Сформулируйте, что именно вы решаете. Не «нам нужно улучшить онбординг», а конкретный вопрос, на который нужен ответ.
4. Определить ясный и простой подход к решению. Если план сложно объяснить коллеге за пару минут — это обычно сигнал, что что-то не так.
5. Определить цель. Зафиксируйте критерий, по которому вы поймёте, что задача решена.
6. Действовать с максимальной скоростью, чтобы достичь цели.

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

Ошибаться — часть плана

Ключевой момент методологии: по ходу работы почти всегда появляется новая информация. И тогда нужно вернуться назад и заново определить шаги 3–5 — проблему, подход и цель, — а затем повторить цикл.

Для сложных проблем может потребоваться немало итераций, прежде чем всё «встанет на место». Со стороны — да и изнутри — это выглядит как суета и постоянные переделки. Но, подчёркивает автор, если вы понимаете, что это неотъемлемая часть процесса, такая «тряска» — здоровое явление:

Единственный способ по-настоящему решить проблему — корректировать курс, когда появляются новые данные. Когда есть новые данные, нужно обновлять свои priors.

Формулировка про priors — отсылка к байесовскому мышлению. У каждого из нас есть априорные представления о том, как устроен мир: какие пользователи поведут себя так, а не иначе, какой подход сработает. Новое наблюдение не должно эти представления разрушать — оно должно их уточнять. На практике это означает: если эксперимент показал, что гипотеза была неверна, это не провал, а именно тот результат, ради которого затевалась работа.

Как это выглядит на практике

Проиллюстрируем цикл условным примером. Команда получила задачу «сделать поиск умнее».

• Шаги 1–2: анализируем существующие логи запросов и выясняем, что 40% запросов вообще не находят релевантных результатов. Собираем недостающие данные: как поиск используют разные сегменты пользователей.
• Шаг 3: после анализа проблема переформулируется — дело не в «умности», а в том, что треть запросов содержит термины, которых нет в описаниях товаров.
• Шаги 4–5: простой подход — расширить индексацию синонимами; цель — снизить долю «пустых» результатов вдвое.
• Шаг 6: реализуем быстро и смотрим на метрику.

Если метрика вдруг покажет, что проблема была не в синонимах, а в опечатках, — это не крах плана, а новые данные: возвращаемся к шагу 3 и уточняем проблему. Именно так цикл и должен работать.

Обратная связь в реальном времени

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

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

Две самые частые ошибки

Какой сбой автор наблюдает чаще всего? Два режима отказа:

• Шаг 3: нечётко определена проблема. Команда бросается решать то, что толком не сформулировано.
• Шаг 4: подход неясен или переусложнён. Нет простого и понятного способа достичь цели.

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

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

Мета-процесс тоже можно оспаривать

Финальный штрих, который делает методологию цельной: сам фреймворк — не догма. «Если какая-то часть этого мета-процесса мета-неправильна, я открыт к её изменению», — пишет Черни. Иными словами, к самой схеме из шести шагов применим тот же принцип, что и к любой гипотезе: появились данные, которые ей противоречат, — обновляй её.

«Я люблю ошибаться»

Заметка заканчивается фразой, вынесенной в заголовок:

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

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

Что это значит в эпоху AI

Автор адресует заметку тем, кто строит продукты в эпоху AI, и это не случайный контекст. Когда AI-инструменты радикально удешевили исполнение — генерацию кода, документов, прототипов, — узким местом всё чаще становится не скорость реализации, а качество постановки проблемы. Сгенерировать «решение» можно за минуты; вот только решает ли оно правильную задачу, зависит целиком от шагов 1–5.

Шесть шагов Черни в этом смысле — простое напоминание: скорость сама по себе ничего не решает. Решает правильно определённая проблема и готовность команды быстро корректировать курс, когда реальные данные расходятся с ожиданиями.

Что взять на заметку

• Начинайте с информации, а не с решения. Шаги 1–2 существуют именно для того, чтобы шаги 3–5 не были фантазией.
• Простота подхода — критерий качества плана. Если план сложно объяснить, чаще всего проблема в постановке задачи.
• Считайте переделки нормой. Много итераций над сложной проблемой — признак работающего процесса, а не хаоса.
• Давайте и просите обратную связь сразу. Отложенное замечание обходится всем дороже.
• Относитесь к своей методологии как к гипотезе. В том числе к той, по которой вы работаете прямо сейчас.