Почему я после запуска продукта веду журнал решений, а не ещё один список задач
После запуска продукта команда обычно видит одну и ту же картину: список задач растёт быстрее, чем закрывается. Кажется, что надо лучше вести бэклог, нанять ещё людей или жёстче расставить приоритеты. Всё это бывает полезно. Но я сначала смотрю не на очередь задач, а на очередь решений.
Если вопрос «зачем мы это делаем и по какому правилу выбираем вариант» остаётся без ответа, задача всё равно появится снова. Только уже под новым названием, с другим исполнителем и потерянным контекстом. Так продукт незаметно начинает жить не выбранным курсом, а последним громким запросом.
Задача и решение — не одно и то же
Представьте обычную ситуацию. Клиент просит добавить выгрузку. В бэклоге появляется карточка «сделать выгрузку в Excel». Разработчик уточняет поля, дизайнер рисует кнопку, задача уходит в спринт.
Но до этого стоило бы решить другое: это разовая просьба одного клиента, повторяющаяся потребность сегмента или признак того, что в продукте не хватает отчёта? Нужно ли отдавать данные файлом, открывать API или исправлять сам экран? Кто будет отвечать за поддержку формата через полгода?
Карточка в трекере отвечает на вопрос «что сделать». Решение отвечает на вопросы «какую проблему мы признали важной», «какие варианты рассмотрели» и «почему выбрали именно этот». Когда второго нет, работа выглядит быстрой только до следующего похожего запроса.
Почему после запуска это становится заметно
До первого релиза команда часто держит общий замысел в голове: людей немного, обсуждения происходят рядом, а продукт ещё не оброс исключениями. После запуска появляется реальная жизнь. Приходят обращения, меняются процессы у клиентов, возникают ограничения интеграций, поддержка видит свои повторяющиеся вопросы.
На этом этапе полезно не путать движение с развитием. Настоящий запуск — это не момент, когда кнопка стала доступна, а начало регулярной проверки гипотез в работе. Об этом я уже писал в материале «Запустить сервис — половина дела. Вторая половина начинается после релиза».
Чем больше реальных сигналов, тем легче спорить о частностях. Продажи говорят: «Клиент уйдёт без этой функции». Поддержка просит убрать источник обращений. Разработка предупреждает о хрупком месте. Каждый прав со своей стороны. Но продукту нужен один ответ: какое правило поможет принять похожее решение и в следующий раз?
Что я называю журналом решений
Это не толстый документ и не попытка оформить каждую мелочь. Журнал решений — короткая запись о важных развилках. Её можно вести в базе знаний, в проектной системе или рядом с архитектурными схемами. Важнее не инструмент, а привычка возвращать обсуждение к смыслу.
Для одной записи обычно достаточно пяти пунктов:
- Контекст. Что происходит и для кого это важно.
- Решаемый вопрос. Не «сделать экран», а «как клиент будет получать нужные данные».
- Варианты. Два-три реальных пути, включая вариант ничего не менять сейчас.
- Выбор и причина. Что выбрали и какой компромисс приняли осознанно.
- Дата пересмотра или сигнал. Когда решение надо проверить снова: после десяти запросов, подключения нового сегмента или следующего квартала.
Такой формат занимает двадцать минут, а экономит гораздо больше. Новый сотрудник не пытается угадать, почему в системе есть странное ограничение. Поддержка знает, что обещать нельзя. Руководитель видит не только сделанные функции, но и логику продукта.
Какие решения точно стоит фиксировать
Я не записываю в журнал замену цвета кнопки или понятную правку текста. Зато туда почти всегда попадают решения, которые потом дорого отменять.
Например, граница между стандартной функцией продукта и индивидуальной доработкой для одного клиента. Или правило, по которому мы подключаем внешнюю систему. Или выбор владельца данных. Или причина, по которой пока не берём определённый сегмент пользователей.
Хороший ориентир простой: если через три месяца команда может спросить «а почему мы сделали именно так?», решение нужно оставить в памяти продукта. Особенно если на него опираются деньги, безопасность, сроки или ожидания клиента.
Пример без героизма
Допустим, в сервисе для управления заявками несколько клиентов просят добавить разные статусы: одному нужен «на согласовании», другому — «ожидает поставку», третьему — «в работе у партнёра». Самый быстрый путь — разрешить каждому создавать свои статусы.
Но тогда через пару месяцев отчёты перестанут сравниваться, интеграция начнёт получать десятки вариантов одного состояния, а новый менеджер не поймёт, что означает «почти готово». Вопрос не в том, как быстро добавить поле. Вопрос в том, должен ли статус описывать единый этап процесса или свободный комментарий клиента.
После обсуждения команда может выбрать общий набор этапов, а особые обстоятельства вынести в отдельное поле. Это не делает всех счастливыми в первую минуту. Зато сохраняет язык, на котором система, отчёты и люди понимают друг друга. В журнале останется причина: единые статусы нужны для сопоставимых данных и надёжной интеграции; исключения живут отдельно.
Журнал не заменяет roadmap
Roadmap показывает последовательность выбранных ставок: что команда собирается проверить или изменить. Журнал объясняет, почему эти ставки появились и на каких условиях они перестанут быть верными. Вместе они работают лучше, чем по отдельности.
Roadmap без решений быстро превращается в обещание функций. Журнал без roadmap становится кладовкой разумных, но неисполненных мыслей. Для меня roadmap — это список решений в движении, а не витрина на год вперёд. Этот принцип подробно разобран в статье «Почему roadmap — это список решений, а не обещаний на год вперед».
Как не превратить это в бюрократию
Опасность понятна: люди начнут заполнять форму ради формы. Чтобы этого не случилось, не нужно вводить журнал для всего подряд. Начните с одного еженедельного разбора: какие решения на этой неделе поменяли правила продукта, архитектуры или работы с клиентом?
Второе правило — писать обычным языком. Фраза «выбрали единый статусный справочник, потому что отчёты и обмен данными должны быть сопоставимы» полезнее страницы формальных согласований.
Третье — у каждой записи должен быть владелец решения. Не обязательно самый высокий по должности. Но кто-то должен иметь право сказать: «условия изменились, давайте вернёмся к этому выбору». Когда владельца нет, спор может жить дольше самой задачи.
Четыре вопроса перед тем, как поставить задачу в очередь
Чтобы журнал не оставался красивой идеей, я использую короткую проверку прямо на обсуждении. Она не замедляет команду: наоборот, помогает не тратить спринт на плохо сформулированную просьбу.
Первый вопрос: что изменится в реальной работе человека? Не «клиент просит интеграцию», а «оператор перестанет переносить номер заказа из одного окна в другое». Если изменение невозможно описать через действие и результат, скорее всего, запрос ещё сырой.
Второй: какое правило мы вводим или меняем? У любого важного изменения есть правило, даже если его не называют. Например: «цена подтверждается до передачи заказа на склад» или «в продукте есть один источник статуса, а не три независимых». Когда правило сформулировано, легче увидеть, не создаёт ли новая функция исключение, которое потом разъест процесс.
Третий: чем мы жертвуем? У решения почти всегда есть цена. Быстрота может уменьшить гибкость, универсальность — усложнить интерфейс, индивидуальная настройка — усложнить поддержку. Не нужно искать идеальный вариант. Достаточно честно назвать компромисс, чтобы он не всплыл сюрпризом на следующем созвоне.
Четвёртый: по какому сигналу мы поймём, что пора вернуться? В продукте полезно пересматривать не только ошибки. Появился новый сегмент клиентов, вырос объём операций, подключили ещё одну систему — старое разумное решение может перестать подходить. Заранее записанный сигнал избавляет от спора «кто обещал, что так будет всегда».
Эти вопросы особенно нужны собственнику или руководителю без отдельного product-менеджера. Они дают возможность обсуждать работу с командой не через контроль каждой карточки, а через понятные основания для выбора.
Связь с пилотом и ежедневной работой
Пилот часто даёт много хороших сигналов и столько же соблазна срочно всё переделать. Его задача — не превратить каждое замечание в функцию, а понять, какие правила выдерживают реальную работу. Поэтому при переходе от тестового запуска к ежедневному режиму особенно важно собрать решения, которые больше нельзя держать «на словах».
Если вы как раз проходите этот этап, посмотрите и материал «Как перевести IT-продукт из пилота в ежедневную работу». Там речь о признаках, что эксперимент уже стал частью процесса. Журнал решений помогает не потерять смысл этого перехода.
Когда одной записи недостаточно
Иногда решение упирается не в продукт, а в устройство бизнеса. Например, отдел продаж обещает клиенту срок, который зависит от склада и подрядчика; или финансовая модель требует другого правила скидок. В этом случае журнал не должен подменять разговор с владельцами процессов. Его роль скромнее и полезнее: он делает видимым вопрос, который раньше растворялся между отделами.
Тогда я выношу решение из продуктовой встречи в более широкий разбор: кто несёт последствия, какие данные нужны для выбора, что можно проверить на ограниченной группе и кто даст финальное «да». Важно не заставлять разработку угадывать бизнес-правило. Хорошая техническая реализация начинается после того, как это правило появилось и у него появился владелец.
Такой подход защищает и от другой крайности — бесконечных согласований. Не каждый вопрос требует совета директоров. Но вопрос, который меняет деньги, ответственность или обещание клиенту, не стоит маскировать под обычную задачу в спринте.
Есть ещё один практический эффект. Когда решения записаны, команда может отличать осознанный долг от случайного беспорядка. Бывает разумно временно сделать обходной путь, чтобы проверить спрос или не задерживать запуск. Но тогда в записи видно: это временный компромисс, его цена известна, а условия пересмотра определены. Хуже всего не временное решение, а временное решение, которое все забыли признать временным.
Для собственника такой список — простой способ видеть качество управления без погружения в технические детали. Не нужно читать каждую задачу. Достаточно время от времени спросить: какие важные решения появились, какие из них ждут проверки и где команда пока не договорилась о правиле? Ответ обычно показывает состояние продукта точнее, чем количество закрытых карточек.
Почему переписки для этого не хватает
Иногда кажется, что всё уже зафиксировано в чате: там есть голосовые сообщения, ссылки, несколько вариантов и финальное «ок». Но переписка хранит ход разговора, а не решение. Через месяц в ней трудно найти итог, ещё труднее понять, какие аргументы были важны, а какие просто относились к старой версии задачи.
Журнал не требует переписывать обсуждение. Он берёт из него одну ясную мысль. Например: «До конца квартала не добавляем отдельные статусы под каждого клиента. Проверяем, хватает ли общего набора этапов и поля причины. Пересматриваем решение, если больше пяти клиентов не могут пройти процесс без отдельного статуса». Так запись можно прочитать за минуту и использовать в следующем разговоре.
Это особенно ценно, когда меняется состав команды. Новый разработчик, аналитик или руководитель не обязан восстанавливать историю по фрагментам. Он может уточнить детали, но начинает уже с точки, где компания договорилась, а не с нуля. В итоге память продукта перестаёт зависеть от того, кто лучше всех помнит старые созвоны.
С чего начать на этой неделе
Не надо восстанавливать всю историю продукта. Выберите три темы, вокруг которых сейчас больше всего повторяющихся разговоров: цены, интеграции, права доступа, отчёты, правила приоритизации. По каждой ответьте: что мы уже решили, почему и когда готовы пересмотреть?
Если ответа нет — это не провал. Это и есть полезный сигнал. Значит, перед вами не просто задача в очереди, а решение, которое продукт давно просит принять.
После запуска зрелость продукта проявляется не в длине списка функций. Она проявляется в том, умеет ли команда объяснить свои важные выборы и вовремя их пересматривать. Когда такая память есть, очередь задач перестаёт управлять продуктом. Продукт снова начинает управлять очередью.
Обсудим?