Хендофф в продажи и разработку: пакет артефактов вместо ручной сборки

По шагам

1. 1. Готовьте контекст, а не документ

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

2. 2. Переведите фичу на стадию релиза

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

3. 3. Знайте девять типов артефактов и адресата каждого

   Набор v1 — девять типов, и все они рождаются из одного и того же контекста, различаясь только аудиторией и шаблоном: release note для внешних пользователей, внутренний changelog для команды, battlecard для продавцов, письмо для клиентов (outbound), brief отделу продаж, FAQ для сейлов, демо-сценарий для продавцов и PMM, черновик задач для разработки и release announcement для внешней коммуникации. Внутренний changelog в набор входит, а публичный changelog как отдельная веб-сущность — нет. Разделение важно для ревью: проверка фактов и правка тона — разные работы, и если смешать их, теряются обе. Ожидаемый результат: по каждому из девяти типов вы можете назвать читателя и то, что должно быть внутри.

4. 4. Проверяйте пакет: факты с одной стороны, тон с другой

   Пакет всегда проходит гейт подтверждения, и публикация без подтверждения невозможна. Продакт проверяет факты, продакт-маркетолог правит тон. Каждое утверждение в артефакте помечено своим источником, а когда вы открываете battlecard, видно источник каждого факта, а также кто его подтвердил и когда. Если в контексте нет обоснования фичи, артефакт несёт явный пробел — например, «обоснование не зафиксировано», — и в пакете в любом случае не появляется выдуманная причина. Подтверждение попадает в журнал с указанием, кто и когда подтвердил. Ожидаемый результат: очередь разобрана, в журнале видно, кто и когда подтвердил пакет, а пробелы остались видны как пробелы.

5. 5. Выберите канал доставки

   Каналов доставки семь: внутри продукта, почта, Slack или Teams, Notion или Confluence, CRM вроде HubSpot, Google Docs и веб-страница с доступом по ссылке. Канал выбирается при доставке, и недоступный канал не блокирует остальные. Выбор фиксируется и в пакете, и в журнале доставки вместе с результатом доставки. Доставка происходит после подтверждения и происходит туда, где аудитория уже работает, — в этом весь смысл механики, построенной на триггерах. Ожидаемый результат: артефакты лежат в выбранном вами канале, а в журнале доставки видны канал и исход.

6. 6. Выберите формат черновика задач

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

7. 7. Делегируйте с явной границей

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

8. 8. Знайте, чего хендофф не делает

   Вне v1: автопубликация без подтверждения, автоматическая рассылка покупателям, генерация email-рассылок клиентам, публичный changelog как отдельная веб-сущность и локализация артефактов на несколько языков — это открытые решения в PRD, а не функции, которые тихо работают. Артефакты не додумывают то, чего в них нет: пакет несёт пробелы, и закрыть пробел — значит добавить решение или метрику в контекст и пересобрать пакет. У каждого артефакта хранятся версии и разница между версиями, поэтому на вопрос «что мы говорили продажам в прошлом квартале» есть ответ. Ожидаемый результат: вы называете, что не автоматизировано, и знаете, где закрывается пробел.

Если не работает

Battlecard сообщает, что обоснование не зафиксировано.

Это работает маркер пробела: в контексте нет зафиксированной причины фичи, и артефакт говорит об этом, а не придумывает. У продакт-маркетолога два пути: добавить решение, гипотезу или метрику в контекст и пересобрать пакет либо отправить пакет на доработку. В обоих случаях выдуманная причина в пакете не появляется. И учтите: пробел едет вместе с артефактом и остаётся видимым для аудитории, пока контекст не заполнен.

В артефакт попала цифра, предложенная ассистентом.

Рыночное число, предложенное ассистентом и не подтверждённое человеком, помечается как «оценка AI, источник не подтверждён», и для такого расчёта система требует подтверждения перед использованием в артефакте. Откройте допущение, приложите источник или отклоните значение, а затем проверьте артефакты, собранные из него. Правило общее: AI предлагает, человек подтверждает, код считает.

Команда получила девять артефактов, и никто не знает, какой читать.

У каждого типа своя аудитория, и она видна в списке типов: внутренний changelog — для команды, brief — отделу продаж, FAQ и battlecard — продавцам, демо-сценарий — продавцам и PMM, release note — внешним пользователям. Артефакты рождаются из одного и того же контекста и различаются только аудиторией и шаблоном, поэтому содержание не приходится сверять руками; сверять приходится тон, и это работа продакт-маркетолога до подтверждения.

Задача пришла в трекер без критериев приёмки.

Проверьте формат, выбранный при подготовке пакета: фича, спека, эпик или тикет. Критерии приёмки обязательны в каждом формате — для фичи и эпика они есть на своём уровне, — а формат выбирает продакт под каждый пакет, а не настраивает администратор один раз. Если критериев нет, отправьте черновик на доработку: неполный черновик в трекере — это точка, с которой начинается разговор об объёме.

Продажи спрашивают о том, чего в артефакте нет.

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