SaaS
Nagpapadala kayo tuwing dalawang linggo at nagsusulat tungkol dito nang dalawang beses kada taon
Hindi kulang sa masasabi ang mga software team. Kulang sila sa taong magsasabi nito, dahil ang pagsusulat ang laging gawaing inililipat kapag late ang release — at inililipat ito sa bawat pagkakataon, hanggang ang pinakabagong post ng blog ay labing-isang buwan na ang edad at nagsasabing "introducing".
Struktural ang pagkabigo, hindi editorial
Alam ng bawat team na dapat silang magsulat nang mas madalas. Marunong magsulat ang mga engineer; marunong ang founder; may kadalasang nasiyahan dito. Ang problema, walang sariling deadline ang pagsusulat, at ang anumang walang deadline ay natatalo ng anumang mayroon, tuwing dalawang linggo, magpakailanman.
Ang plano ang nagbibigay sa nawawalang deadline. Ang may petsang slot na may tema at nakatalagang manunulat ay isang pangako na ginawa sa isang kalmadong linggo, isinasagawa sa linggong hindi kalmado, at lalabas ang draft kahit na walang nakatanda. Ang pag-apruba nito ay matatapos sa ilang minuto; ang pagsulat nito mula sa wala ay isang hapon na hindi kailanman dumarating.
Iyon ang buong argumento. Hindi ito dahil mas mabuti magsulat ang isang model kaysa sa iyong team — hindi naman. Kundi dahil mayroon kang draft na ie-edit mo sa Martes, at walang post na sinabi mong isusulat mo.
Ang roadmap ay isang planong naisulat mo na
Karamihan sa anim na buwan ay napagpasyahan na. Alam mo nang humigit-kumulang kung ano ang ilalabas sa susunod na dalawang quarter, kung aling bahagi ng produkto ang hindi nauunawaan, kung aling mga integration ang paulit-ulit na hinihingi sa iyo, at kung aling mga tanong ang dumating sa support tuwing linggo.
Bawat isa sa mga iyon ay isang tema. Ang roadmap ang nagbibigay ng cadence — ang isang release ay nagiging sunod-sunod na slot sa halip na isang changelog entry — at ang support ang nagbibigay ng evergreen na kalahati, dahil ang tanong na tinatanong dalawampung beses sa isang buwan ay isang piraso na sulit isang beses isulat at i-link magpakailanman.
Mag-iwan ng mga puwang. Nagkakaroon ng delay ang mga release, at ang planong walang bakanteng slot ay ginagawang tatlong post tungkol sa bagay na wala pa ang isang naantalang release. Ang isang kapat na bakanteng slot ay hindi kaluwagan; ito ang bahagi ng planong nakaliligtas sa pakikipagtagpo sa iyong tunay na iskedyul.
- 1BlogAno ang inilabas at bakit ito umiiral. Muna ang problema, pangalawa ang feature.
- 2Facebook / InstagramAng bersyon na isang pangungusap, para sa mga taong hindi kailanman magbubukas ng changelog.
- 3BlogKung paano talaga ito ginamit ng isang tao. Kongkreto, kasama ang mga hindi kanais-nais na bahagi.
- ·Kung made-delayGumagalaw ang mga slot kasama ng release. Walang iaanunsyo tungkol sa bagay na wala pa.
- 4BlogAng tanong sa support na sa wakas sinasagot ng release na ito, isang beses isulat.
Ang roadmap ang nagtatakda ng cadenceAng support ang nagtatakda ng mga tema
Ang changelog mo ay hindi content. Ito ay isang resibo.
Dalawang manunulat, minsan tatlo
Ang nagpapaliwanag ng produkto, at ang nagsasalita tungkol sa kompanya
Talagang magkaiba ang mga boses na iyon, at ang pagsasanib nila ay lumilikha ng partikular na kalimitan na kilala sa mga software blog — isang post na hindi teknikal na paliwanag at hindi rin makataong salaysay ng anumang bagay.
Ang teknikal na manunulat
Ipinaliliwanag kung ano ang ginagawa ng isang bagay, nang tumpak, nang walang mga pang-uri. Alam kung para saan ang iyong produkto at kung hindi para saan, at pinapayagan siyang sabihin ito. Ito ang manunulat na ang mga post ay nililink mula sa mga support ticket.
Ang boses ng kompanya
Nagsusulat tungkol sa mga desisyon, trade-off at kung ano ang tinatayuan ninyo. Kapaki-pakinabang sa paraang mahirap sukatin at halata sa pag-hire, sa mga sales call, at sa dahilan kung bakit pipiliin ng sinuman ang maliit na vendor kaysa sa malaki.
Ang sumasagot
Humahawak ng mga komento sa ilalim ng iyong patakaran. Sinasagot ang kaya nitong sagutin, minamarkahan ang hindi nito kaya, at hindi kailanman nagsasabi ng haka-haka tungkol sa roadmap. Anumang kahawig ng support incident ay agad naipapasa sa isang tao.
Ang approval gate ay gumagawa ng tunay na trabaho dito
Para sa isang bakery, ang hindi naaprubahang post ay maliit na kahihiyan. Para sa isang software company, ito ay load sa support, isang sales objection, o isang pangakong walang pumayag. Ang draft na bahagyang mali ang paglalarawan sa isang limitasyon ay ibabalik sa iyo ng isang customer, at ang draft na nagpapahiwatig ng petsa ay ituturing na pangako.
Kaya ito ang kaso kung saan pinakamaraming pag-iingat ang nararapat sa autopilot. Ang makatwirang ayos ay autopilot sa mga maikling social slot na nag-uulit ng bagay na nai-publish na, at approval sa lahat ng gumagawa ng pahayag tungkol sa produkto. Anumang tungkol sa presyo, kapasidad o mga petsa ay dapat basahin ng isang tao magpakailanman, at sulit isulat ito sa mga patakaran ng manunulat upang ang mga ganoong draft ay hawak at markahan sa halip na i-queue.
Ang sinasabi ng report sa maliit na team
Ang planned versus published ang bilang na mahalaga, at para sa software team, karaniwang hindi komportable ito sa unang quarter. Ito rin ang tanging tapat na sukatan kung tumigil na ba ang pagsulat sa pagkatalo sa release muli.
Mas mababa ang halaga ng reception kaysa sa itsura nito. Ang teknikal na piraso ay natatagpuan ang audience nito sa loob ng mga buwan, hindi mga araw, at ang paghatol dito sa ikalawang linggo ay magpapabitiw sa iyo sa mga pirasong gagana sana. Mas kapaki-pakinabang ang balanse ng tema sa simula: ipinapakita nito kung puro tungkol sa nai-release lang ang sinusulat mo, na ang karaniwang pagkabigo at ang dahilan kung bakit maraming software blog ang parang changelog na may mga talata.
Ang tapat na bahagi: kung tunay na teknikal ang iyong produkto, ang pinakamalalim na mga piraso ay nangangailangan pa rin ng isang engineer sa loob ng isang hapon. Ang binabago ng plano ay ang mga hapon na iyon ay naisaskedule na, at ang ibang walumpung porsyento ng pagsusulat ay tumitigil sa pakikipagkumpitensya sa kanila.