SaaS
你每兩個禮拜出一次版本,但一年先寫兩次關於佢嘅嘢
軟件團隊唔係冇嘢好講。佢哋係冇嗰個講嘢嘅人,因為寫嘢永遠係出版本延遲嗰陣第一個被擺低嘅任務——而且次次都係咁,直到個blog最新嗰篇已經十一個月咁舊,仲係嗰句「隆重推出」。
問題係結構性嘅,唔係編輯層面嘅
個個團隊都知應該寫多啲。啲工程師識寫;個創辦人識寫;通常仲有人係鍾意寫。問題係寫嘢冇自己嘅死線,而冇死線嘅嘢永遠輸畀有死線嘅嘢,每兩個禮拜都係咁,永遠都係咁。
一個計劃就係補返嗰個冇咗嘅死線。一個有日期、有主題、有指定寫手嘅時段,係喺一個清閒嘅禮拜作出嘅承諾,喺一個唔清閒嘅禮拜執行,無論有冇人記得,草稿都會出現。批核佢要幾分鐘;由零開始寫佢,就要一個永遠都唔會嚟到嘅下午。
成個論點就係咁多。唔係話個模型寫得好過你個團隊——佢冇。係話一份你禮拜二執嘅草稿係存在嘅,而一篇你話過要寫嘅post係唔存在嘅。
Roadmap本身就係你已經寫咗嘅計劃
嗰六個月大部分其實已經決定咗。你大概知道之後兩季會出咩、產品邊部分俾人誤解、邊啲整合成日俾人要求、同埋支援嗰邊每個禮拜都收到邊啲問題。
呢啲每一樣都係一個主題。路線圖提供節奏——一次發佈變成一連串時段，而唔係單一條更新日誌；支援就提供長青嗰一半，因為一條一個月問二十次嘅問題，就係一篇寫一次然後永遠連結過去嘅內容。
留啲空位。發佈會延遲，一個冇空位嘅計劃會令一次延遲嘅發佈變成三篇講緊一樣未存在嘅嘢嘅文章。留低四分之一空位唔係偷懶；呢個正係計劃入面能夠捱得住你真實時間表嗰部分。
- 1網誌出咗咩同點解要有佢。先講問題，再講功能。
- 2Facebook / Instagram一句講晒嘅版本，畀啲永遠唔會打開更新日誌嘅人睇。
- 3網誌有人實際點樣用佢。具體，連嗰啲尷尬位都照寫。
- ·如果延遲咗時段會跟住發佈一齊郁。冇嘢會宣佈一樣未存在嘅嘢。
- 4網誌今次發佈終於解答到嘅支援問題，一次過寫好。
路線圖定咗節奏支援定咗主題
你嘅更新日誌唔係內容。佢係一張收據。
兩個寫手，有時三個
一個解釋產品，一個講公司
呢啲真係兩種唔同嘅聲音，將佢哋合埋一齊就會產生軟件網誌出名嗰種平淡——一篇唔係技術解釋、又唔係任何人嘅真實經歷嘅文章。
技術寫手
精確咁解釋一樣嘢做咩，唔用形容詞。知道你嘅產品啱咩用、唔啱咩用，而且可以講出口。呢個就係嗰啲文章會被支援工單引用嘅寫手。
公司聲音
寫決定、取捨，同你哋正在建立嘅嘢。佢嘅用處好難量化，但喺招聘、銷售電話，同埋人哋點解揀一個小供應商而唔揀大嗰個嘅原因入面，就好明顯。
解答嘅嗰個
按你嘅政策處理留言。答到嘅就答，答唔到嘅就標記，永遠唔會猜測路線圖。任何似支援事故嘅嘢即刻交畀真人。
審批關卡喺度真係發揮緊作用
對一間餅店嚟講，一篇未經批准嘅文章只係少少尷尬。對一間軟件公司嚟講，佢係支援負擔、係銷售時被反對嘅理由，或者係一個冇人同意過嘅承諾。一篇將某個限制寫得稍有出入嘅草稿，會被客戶原句引返畀你；一篇暗示咗日期嘅草稿，會被當成承諾。
所以呢個正係自動駕駛最需要小心嘅情況。一個合理嘅安排係：自動處理嗰啲重複講已發佈內容嘅短社交時段，而所有對產品作出宣稱嘅嘢就要審批。任何關於價錢、容量或者日期嘅嘢，應該永遠由真人閱讀，而且值得將呢條規則寫入寫手守則，令呢類草稿被扣起同標記，而唔係排隊發佈。
報告對一個小團隊講咩
計劃咩對比實際發佈咩先係最重要嘅數字，而對軟件團隊嚟講，第一季通常會好唔好受。佢亦都係唯一誠實嘅量度，話畀你知寫作係咪又再輸畀發佈。
反應冇表面咁重要。一篇技術文章係用幾個月而唔係幾日嚟搵到佢嘅讀者，喺第二個禮拜就評判佢，會令你放棄嗰啲本來會成功嘅文章。主題平衡喺早期更加有用：佢顯示你係咪淨係寫啲啱啱出咗嘅嘢——呢個係最常見嘅失敗模式，亦係咁多軟件網誌讀落似有段落嘅更新日誌嘅原因。
老實嗰部分：如果你嘅產品真係好技術性，最深嘅文章仍然需要一位工程師用一個下午。計劃改變到嘅，係嗰啲下午會被編入時間表，而其餘八成嘅寫作唔會再同佢哋爭時間。