SaaS
Вы выпускаете обновления каждые две недели, а пишете о них дважды в год
У софтверных команд нет недостатка в темах. Им не хватает человека, который о них пишет, потому что написание — всегда та задача, которую сдвигают, когда релиз задерживается, — и её сдвигают каждый раз, пока в блоге не окажется пост одиннадцатимесячной давности со словом «представляем».
Сбой структурный, а не редакционный
Каждая команда знает, что писать надо больше. Инженеры умеют писать; основатель умеет писать; кому-то это обычно даже нравится. Проблема в том, что у написания нет собственного дедлайна, а всё, у чего дедлайна нет, проигрывает всему, у которого он есть, — каждые две недели, всегда.
План восполняет недостающий дедлайн. Слот с датой, темой и назначенным автором — это обязательство, взятое в спокойную неделю и действующее в неделю неспокойную, и черновик появляется независимо от того, помнил ли кто-то о нём. Согласовать его — дело минут; написать с нуля — дело целого дня, который так и не наступает.
Это и есть весь аргумент. Дело не в том, что модель пишет лучше вашей команды — она не пишет. Дело в том, что черновик, который вы правите во вторник, существует, а пост, который вы собирались написать, — нет.
Роадмап — это план, который вы уже написали
Большая часть ближайших шести месяцев уже решена. Вы примерно знаете, что выйдет в следующие два квартала, какие части продукта понимают неправильно, какие интеграции у вас постоянно просят и какие вопросы приходят в поддержку каждую неделю.
Каждый из них — это тема. Дорожная карта задаёт ритм — релиз превращается в серию публикаций, а не в одну запись в changelog, — а поддержка задаёт вечнозелёную половину: вопрос, который задают двадцать раз в месяц, — это материал, который стоит написать один раз и ссылаться на него вечно.
Оставляйте промежутки. Релизы сдвигаются, и план без пустых слотов превращает сдвинувшийся релиз в три статьи о том, чего ещё не существует. Четверть незаполненных слотов — это не халтура; это та часть плана, которая переживёт столкновение с вашим реальным графиком.
- 1БлогЧто вышло и зачем это существует. Сначала проблема, потом функция.
- 2Facebook / InstagramВерсия в одно предложение — для тех, кто никогда не откроет changelog.
- 3БлогКак кто-то реально этим воспользовался. Конкретно, с сохранением всех неловких моментов.
- ·Если релиз сдвигаетсяСлоты сдвигаются вместе с релизом. Ничего не анонсируется раньше, чем это существует.
- 4БлогВопрос из поддержки, который этот релиз наконец закрывает, — написанный один раз.
Ритм задаёт дорожная картаТемы задаёт поддержка
Ваш changelog — это не контент. Это квитанция.
Два автора, иногда три
Тот, кто объясняет продукт, и тот, кто рассказывает о компании
Это действительно разные голоса, и их слияние порождает ту особую пресность, которой славятся блоги о софте, — статью, которая не является ни техническим объяснением, ни человеческим рассказом о чём-либо.
Технический автор
Объясняет, что делает та или иная функция, точно и без прилагательных. Знает, для чего ваш продукт предназначен и для чего нет, и ему разрешено это говорить. Это тот автор, чьи статьи цитируют в тикетах поддержки.
Голос компании
Пишет о решениях, компромиссах и о том, к чему вы идёте. Это полезность, которую трудно измерить, но она очевидна при найме, на продажах и в причинах, по которым кто-то выбирает небольшого поставщика вместо крупного.
Тот, кто отвечает
Работает с комментариями по вашей политике. Отвечает на то, что может, помечает то, что не может, и никогда не строит догадок о дорожной карте. Всё, что похоже на инцидент поддержки, немедленно передаётся человеку.
Здесь шлюз одобрения выполняет настоящую работу
Для пекарни не одобренная публикация — небольшое смущение. Для софтверной компании это нагрузка на поддержку, возражение в продажах или обязательство, на которое никто не соглашался. Черновик, слегка неверно описывающий ограничение, клиент процитирует вам обратно, а черновик, намекающий на дату, будет воспринят как обещание.
Так что это тот случай, когда автопилот требует наибольшей осторожности. Разумная схема: автопилот на коротких слотах в соцсетях, которые пересказывают уже опубликованное, и одобрение на всём, что делает заявления о продукте. Всё, что касается цен, мощности или дат, должен читать человек — постоянно, и стоит записать это в правила автора, чтобы такие черновики задерживались и помечались, а не ставились в очередь.
Что отчёт говорит небольшой команде
«Запланировано против опубликовано» — вот число, которое имеет значение, и для софтверной команды в первом квартале оно обычно некомфортно. Это также единственная честная мера того, перестала ли письменная работа снова проигрывать релизу.
Отклик важен меньше, чем кажется. Техническая статья находит свою аудиторию за месяцы, а не дни, и судить её на второй неделе — значит снять с публикации те материалы, которые могли бы сработать. Баланс тем полезнее на раннем этапе: он показывает, пишете ли вы только о том, что вышло, — это стандартный провал и причина, по которой столько блогов о софте читаются как changelog с абзацами.
Честная часть: если ваш продукт действительно технический, самые глубокие материалы всё равно требуют инженера на полдня. Что меняет план, так это то, что эти полдня попадают в расписание, а остальные восемьдесят процентов письменной работы перестают с ними конкурировать.