SaaS
Пускате нова версия на всеки две седмици, а пишете за това два пъти годишно
Софтуерните екипи не страдат от липса на теми. Липсва им човекът, който да ги напише, защото писането е винаги задачата, която се отлага, когато релийзът закъснее — и се отлага всеки път, докато най-новата публикация в блога не стане на единайсет месеца и не започва с „представяме“.
Провалът е структурен, а не редакционен
Всеки екип знае, че трябва да пише повече. Инженерите могат да пишат; основателят може да пише; обикновено някому му харесва. Проблемът е, че писането няма собствен краен срок, а всичко без краен срок губи от всичко със срок — на всеки две седмици, завинаги.
Планът доставя липсващия срок. Слот с дата, тема и автор е ангажимент, поет в спокойна седмица и изпълнен в седмица, която не е спокойна, а черновата се появява независимо дали някой е помнил. Одобрението ѝ отнема минути; писането ѝ от нулата отнема следобед, който никога не настъпва.
Това е целият аргумент. Не е, че моделът пише по-добре от вашия екип — не пише. А е, че чернова, която редактирате във вторник, съществува, а публикация, която сте възнамерявали да напишете, не.
Пътната карта е план, който вече сте написали
Голямата част от шестте месеца вече е решена. Приблизително знаете какво излиза през следващите две тримесечия, кои части от продукта се разбират погрешно, кои интеграции постоянно искат и кои въпроси пристигат в поддръжката всяка седмица.
Всяко от тях е тема. Пътната карта дава ритъма — релийзът става поредица от слотове, а не един запис в списъка с промени — а поддръжката дава вечнозелената половина, защото въпрос, зададен двайсет пъти месечно, е текст, който си струва да се напише веднъж и да се сочее завинаги.
Оставяйте празни места. Релийзите се отлагат, а план без празни слотове превръща отложен релийз в три публикации за нещо, което още не съществува. Четвърт от слотовете, оставени отворени, не е разхищение; това е частта от плана, която оцелява при сблъсъка с реалния ви график.
- 1БлогКакво излезе и защо съществува. Първо проблемът, после функцията.
- 2Facebook / InstagramВерсията в едно изречение, за хората, които никога няма да отворят списък с промени.
- 3БлогКак някой наистина го е използвал. Конкретно, с оставените неловки части.
- ·Ако се забавиСлотовете се местят заедно с релийза. Нищо не обявява нещо, което не съществува.
- 4БлогВъпросът за поддръжката, който този релийз най-после отговаря, написан веднъж.
Пътната карта задава ритъмаПоддръжката задава темите
Вашият списък с промени не е съдържание. Той е разписка.
Двама автори, понякога трима
Този, който обяснява продукта, и този, който говори за компанията
Това наистина са различни гласове, а сливането им дава онази специфична безвкусица, известна от софтуерните блогове — публикация, която не е нито техническо обяснение, нито човешки разказ за нещо.
Техническият автор
Обяснява какво прави едно нещо, точно, без прилагателни. Знае за какво е и за какво не е Вашият продукт, и му е позволено да го каже. Това е авторът, чиито публикации се пращат като връзки от билетите на поддръжката.
Гласът на компанията
Пише за решения, компромиси и към какво строите. Полезен по начин, който е труден за измерване и очевиден при наемането, в продажбените разговори и в причината някой да избере малък доставчик вместо голям.
Този, който отговаря
Обработва коментарите под Вашата политика. Отговаря на това, което може, отбелязва това, което не може, и никога не спекулира за пътна карта. Всичко, приличащо на инцидент с поддръжката, веднага отива при човек.
Тук контролата за одобрение върши реална работа
За една пекарна неодобрена публикация е малко смущение. За софтуерна компания тя е товар за поддръжката, възражение в продажбите или ангажимент, с който никой не е съгласен. Чернова, описваща едно ограничение леко погрешно, ще Ви бъде цитирана обратно от клиент, а чернова, загатваща за дата, ще бъде приемана за обещание.
Затова това е случаят, в който автопилотът заслужава най-много внимание. Разумен уред е автопилот върху кратките слотове в социалните мрежи, които повтарят нещо вече публикувано, и одобрение върху всичко, което прави твърдение за продукта. Всичко за цени, капацитет или дати трябва постоянно да се чете от човек, и си струва да запишете това в правилата на автора, така че чернови от този вид да се задържат и отбелязват, а не да се нареждат на опашка.
Какво докладът казва на малък екип
Планирано спрямо публикувано е числото, което има значение, и за софтуерен екип то обикновено е неприятна в първото тримесечие. То е и единствената честна мярка дали писането е престанало отново да губи от релийза.
Приемът има по-малко значение, отколкото изглежда. Техническа статия намира аудиторията си за месеци, не за дни, и ако я съдите във втората седмица, ще спрете статиите, които щяха да проработят. Балансът на темите е по-полезен в началото: той показва дали пишете само за това, което е излязло, а това е стандартният провал и причината толкова много софтуерни блогове да четат като списък с промени с абзаци.
Честната част: ако Вашият продукт наистина е технически, най-дълбоките статии все още се нуждаят от инженер за един следобед. Това, което променя един план, е, че тези следобеди се планират, а останалите осемдесет процента от писането спират да се съревновават с тях.