SaaS
شما هر دو هفته یک‌بار انتشار می‌دهید و سالی دو بار درباره‌اش می‌نویسید
تیم‌های نرم‌افزاری کمبود موضوع برای گفتن ندارند. کمبودِ کسی که بگوید را دارند، چون نوشتن همیشه کاری است که وقتی انتشار عقب می‌افتد جابه‌جا می‌شود — و هر بار جابه‌جا می‌شود، تا وقتی که جدیدترین پست وبلاگ یازده ماه قدمت داشته باشد و با «معرفی» شروع شود.
این شکست ساختاری است، نه تحریری
هر تیمی می‌داند که باید بیشتر بنویسد. مهندسان می‌توانند بنویسند؛ بنیان‌گذار می‌تواند بنویسد؛ معمولاً کسی هم از آن لذت می‌برد. مشکل این است که نوشتن ضرب‌الاجل خودش را ندارد، و هر چیزی که ضرب‌الاجل ندارد، به هر چیزی که دارد می‌بازد — هر دو هفته، برای همیشه.
برنامه، ضرب‌الاجلِ جاافتاده را تأمین می‌کند. یک اسلات تاریخ‌دار با موضوع و نویسنده مشخص، تعهدی است که در هفته‌ای آرام گرفته می‌شود و در هفته‌ای که آرام نیست اعمال می‌شود، و پیش‌نویس ظاهر می‌شود چه کسی یادش باشد چه نباشد. تأییدش چند دقیقه طول می‌کشد؛ نوشتنش از صفر، بعدازظهری است که هرگز نمی‌رسد.
کل استدلال همین است. این نیست که یک مدل بهتر از تیم شما بنویسد — نمی‌نویسد. این است که پیش‌نویسی که سه‌شنبه ویرایش می‌کنید وجود دارد، و پستی که قصد داشتید بنویسید وجود ندارد.
نقشه راه، برنامه‌ای است که قبلاً نوشته‌اید
بیشترِ آن شش ماه از قبل مشخص است. تقریباً می‌دانید در دو فصل بعدی چه چیزی منتشر می‌شود، کدام بخش‌های محصول بد فهمیده شده‌اند، کدام یکپارچه‌سازی‌ها را مدام درخواست می‌کنند، و کدام سؤال‌ها هر هفته به پشتیبانی می‌رسند.
هر کدام از این‌ها یک موضوع است. نقشه راه ریتم را تأمین می‌کند — یک انتشار به‌جای یک ردیف تغییرات، به رشته‌ای از اسلات‌ها تبدیل می‌شود — و پشتیبانی نیمه همیشه‌سبز را تأمین می‌کند، چون سؤالی که ماهی بیست بار پرسیده می‌شود، مطلبی است که یک‌بار می‌نویسید و برای همیشه به آن لینک می‌دهید.
جا خالی بگذارید. انتشارها عقب می‌افتند، و برنامه‌ای بدون اسلات خالی، یک انتشار عقب‌افتاده را به سه پست درباره چیزی تبدیل می‌کند که هنوز وجود ندارد. باز گذاشتن یک‌چهارم اسلات‌ها تنبلی نیست؛ همان بخشی از برنامه است که در برخورد با برنامه واقعی شما دوام می‌آورد.
- 1وبلاگچه چیزی منتشر شد و چرا وجود دارد. اول مشکل، بعد قابلیت.
- 2فیس‌بوک / اینستاگرامنسخه یک‌جمله‌ای، برای کسانی که هرگز تغییرات را باز نمی‌کنند.
- 3وبلاگکسی واقعاً چطور از آن استفاده کرد. مشخص و عینی، با همان بخش‌های ناخوشایندش.
- ·اگر از برنامه عقب بیفتداسلات‌ها همراه با انتشار جابه‌جا می‌شوند. هیچ چیز چیزی را که وجود ندارد اعلام نمی‌کند.
- 4وبلاگپرسش پشتیبانی که این انتشار سرانجام به آن پاسخ می‌دهد، یک‌بار نوشته شده.
نقشه راه ریتم را تعیین می‌کندپشتیبانی محورها را تعیین می‌کند
تغییرات شما محتوا نیست. این یک رسید است.
دو نویسنده، گاهی سه نفر
کسی که محصول را توضیح می‌دهد، و کسی که از شرکت حرف می‌زند
این دو واقعاً صداهای متفاوتی هستند و ادغام‌شان همان بی‌روحی خاصی را تولید می‌کند که وبلاگ‌های نرم‌افزاری به آن معروف‌اند — نوشته‌ای که نه توضیح فنی است و نه روایتی انسانی از هیچ چیز.
نویسنده فنی
توضیح می‌دهد که یک چیز دقیقاً چه می‌کند، بدون صفت. می‌داند محصول شما برای چه است و برای چه نیست، و اجازه دارد این را بگوید. این همان نویسنده‌ای است که نوشته‌هایش از تیکت‌های پشتیبانی لینک می‌شوند.
صدای شرکت
درباره تصمیم‌ها، موازنه‌ها و آنچه به سمتش می‌سازید می‌نویسد. به شکلی مفید است که سنجیدنش سخت است، اما در استخدام، در جلسات فروش و در دلیل انتخاب یک فروشنده کوچک به جای بزرگ، آشکار می‌شود.
پاسخ‌دهنده
نظرات را طبق سیاست شما مدیریت می‌کند. به آنچه می‌تواند پاسخ می‌دهد، آنچه نمی‌تواند را علامت‌گذاری می‌کند و هرگز درباره نقشه راه گمانه‌زنی نمی‌کند. هر چیزی که شبیه یک حادثه پشتیبانی باشد بلافاصله به یک انسان ارجاع می‌شود.
ایستگاه تأیید اینجا واقعاً کار می‌کند
برای یک نانوایی، یک نوشته تأییدنشده فقط کمی خجالت‌آور است. برای یک شرکت نرم‌افزاری، بار پشتیبانی، یک اعتراض فروش، یا تعهدی است که هیچ‌کس با آن موافقت نکرده. پیش‌نویسی که یک محدودیت را کمی اشتباه توصیف کند، مشتری همان را به روی شما می‌آورد، و پیش‌نویسی که به تاریخی اشاره کند، به‌عنوان قول تلقی می‌شود.
پس این همان موردی است که خودکار بودن بیشترین احتیاط را می‌طلبد. یک چیدمان منطقی این است که خودکار فقط روی اسلات‌های کوتاه شبکه‌های اجتماعی باشد که چیز منتشرشده‌ای را تکرار می‌کنند، و تأیید روی هر چیزی که ادعایی درباره محصول دارد. هر چیزی درباره قیمت، ظرفیت یا تاریخ‌ها باید همیشه توسط یک انسان خوانده شود، و ارزش دارد این را در قوانین نویسنده بنویسید تا پیش‌نویس‌های از این دست به صف نروند، بلکه نگه داشته و علامت‌گذاری شوند.
گزارش به یک تیم کوچک چه می‌گوید
برنامه‌ریزی‌شده در برابر منتشرشده عددی است که اهمیت دارد، و برای یک تیم نرم‌افزاری معمولاً در فصل اول ناخوشایند است. این همچنین تنها معیار صادقانه برای این است که آیا نوشتن دوباره در برابر انتشار بازنده شده است یا نه.
استقبال کمتر از آنچه به نظر می‌رسد اهمیت دارد. یک متن فنی مخاطبش را در طول ماه‌ها پیدا می‌کند، نه روزها، و قضاوت درباره‌اش در هفته دوم باعث می‌شود همان متن‌هایی را کنار بگذارید که قرار بود جواب بدهند. توازن محورها در ابتدا مفیدتر است: نشان می‌دهد که آیا شما فقط درباره چیزهای منتشرشده می‌نویسید، که همان حالت شکست استاندارد است و دلیل اینکه چرا این‌همه وبلاگ نرم‌افزاری شبیه یک فهرست تغییرات با پاراگراف به نظر می‌رسد.
بخش صادقانه: اگر محصول شما واقعاً فنی است، عمیق‌ترین متن‌ها هنوز به یک مهندس برای یک بعدازظهر نیاز دارند. آنچه یک برنامه تغییر می‌دهد این است که این بعدازظهرها زمان‌بندی می‌شوند و هشتاد درصد دیگر نوشتن‌ها دیگر با آن‌ها رقابت نمی‌کنند.