SaaS
Ви випускаєте релізи щодвотижнево, а пишете про це двічі на рік
У софтверних команд немає браку тем. Їм бракує людини, яка про них пише, бо написання — це завжди та задача, яку зсувають, коли реліз запізнюється, — і її зсувають щоразу, доки найсвіжіший пост у блозі не сягне одинадцяти місяців і слова «представляємо».
Проблема структурна, а не редакторська
Кожна команда знає, що варто писати більше. Інженери вміють писати; засновник уміє; комусь зазвичай це навіть подобається. Проблема в тому, що в написання немає власного дедлайну, а все, що без дедлайну, програє всьому, що з дедлайном, — щодвотижнево, вічно.
План дає бракуючий дедлайн. Слот із датою, темою та автором — це зобов'язання, взяте в спокійний тиждень і застосоване в тиждень неспокійний, і чернетка з'являється, навіть якщо ніхто не пам'ятав. Затвердити її — справа хвилин; написати з нуля — цілий післяобід, який ніколи не настає.
Це і є весь аргумент. Справа не в тому, що модель пише краще за вашу команду — вона не пише. Справа в тому, що чернетка, яку ви редагуєте у вівторок, існує, а пост, який ви збиралися написати, — ні.
Роадмап — це план, який ви вже написали
Більша частина цих шести місяців уже визначена. Ви приблизно знаєте, що вийде в наступні два квартали, які частини продукту розуміють неправильно, які інтеграції у вас постійно просять і які питання щотижня надходять у підтримку.
Кожен із них — це тема. Дорожня карта задає ритм — реліз стає серією слотів, а не одним записом у changelog, — а підтримка дає вічнозелену половину, бо питання, яке ставлять двадцять разів на місяць, варто написати один раз і посилатися на нього назавжди.
Залишайте прогалини. Релізи затримуються, і план без порожніх слотів перетворює затриманий реліз на три статті про те, чого ще не існує. Чверть слотів, залишених відкритими, — це не розхлябаність; це та частина плану, яка переживе зіткнення з вашим реальним графіком.
- 1БлогЩо вийшло і навіщо це існує. Спочатку проблема, потім функція.
- 2Facebook / InstagramВерсія в одне речення — для тих, хто ніколи не відкриє changelog.
- 3БлогЯк хтось насправді цим користувався. Конкретно, з незручними моментами, які не викинуто.
- ·Якщо реліз затримуєтьсяСлоти зсуваються разом із релізом. Ніщо не анонсує те, чого не існує.
- 4БлогПитання підтримки, яке цей реліз нарешті закриває, написане один раз.
Дорожня карта задає ритмПідтримка задає теми
Ваш changelog — це не контент. Це квитанція.
Два автори, іноді три
Той, хто пояснює продукт, і той, хто розповідає про компанію
Це справді різні голоси, і їхнє злиття дає ту саму прісну нудьгу, якою відомі блоги про програмне забезпечення, — статтю, яка не є ані технічним поясненням, ані людською розповіддю про що-небудь.
Технічний автор
Точно пояснює, що робить річ, без прикметників. Знає, для чого ваш продукт призначений, а для чого — ні, і йому дозволено це казати. Це той автор, чиї статті посилають у відповідь на запити підтримки.
Голос компанії
Пише про рішення, компроміси та те, до чого ви йдете. Корисно так, що важко виміряти, але очевидно в найманні, у продажах і в тому, чому хтось обирає малого постачальника замість великого.
Той, хто відповідає
Обробляє коментарі за вашою політикою. Відповідає на те, що може, позначає те, чого не може, і ніколи не будує припущень про дорожню карту. Все, що схоже на інцидент підтримки, негайно передається людині.
Тут шлюз погодження справді працює
Для пекарні неопублікована стаття — це невелика незручність. Для компанії-розробника це навантаження на підтримку, заперечення в продажах або зобов'язання, на яке ніхто не погоджувався. Чернетка, яка трохи неправильно описує обмеження, буде процитована вам клієнтом, а чернетка, яка натякає на дату, буде сприйнята як обіцянка.
Тому саме тут автопілот заслуговує на найбільшу обережність. Розумна домовленість — автопілот для коротких соціальних слотів, які повторюють уже опубліковане, і погодження для всього, що робить твердження про продукт. Все, що стосується цін, потужностей чи дат, має постійно читати людина, і варто записати це в правила автора, щоб такі чернетки утримувалися й позначалися, а не ставали в чергу.
Що звіт каже малій команді
Заплановане проти опублікованого — це число, яке має значення, і для команди розробників воно зазвичай неприємне в першому кварталі. Це також єдина чесна міра того, чи перестало письмо знову програвати релізу.
Сприйняття має менше значення, ніж здається. Технічна стаття знаходить свою аудиторію місяцями, а не днями, і оцінювати її на другому тижні — значить відкласти ті матеріали, які мали б спрацювати. Баланс тем корисніший на початку: він показує, чи пишете ви лише про те, що вийшло, — а це стандартний режим відмови і причина, чому стільки блогів про програмне забезпечення читаються як changelog з абзацами.
Чесна частина: якщо ваш продукт справді технічний, найглибші матеріали все одно потребують інженера на пів дня. Що змінює план — це те, що ці півдні потрапляють у розклад, а решта вісімдесяти відсотків письма перестає з ними конкурувати.