SaaS
Bạn phát hành hai tuần một lần nhưng chỉ viết về nó hai lần một năm
Các nhóm phần mềm không thiếu điều để nói. Họ thiếu người nói ra, vì viết luôn là việc bị đẩy lại khi bản phát hành bị trễ — và nó bị đẩy lại mỗi lần, cho đến khi bài viết mới nhất trên blog đã cũ mười một tháng và ghi "giới thiệu".
Lỗi là do cấu trúc, không phải do biên tập
Mọi nhóm đều biết mình nên viết nhiều hơn. Kỹ sư biết viết; nhà sáng lập biết viết; thường cũng có ai đó thích viết. Vấn đề là việc viết không có hạn chót riêng, và thứ gì không có hạn chót sẽ thua thứ gì có hạn chót, hai tuần một lần, mãi mãi.
Kế hoạch cung cấp hạn chót còn thiếu. Một khe có ngày, có chủ đề và người viết là một cam kết được đưa ra trong một tuần bình yên, được áp dụng trong một tuần không bình yên, và bản nháp sẽ xuất hiện dù có ai nhớ hay không. Duyệt nó chỉ mất vài phút; viết nó từ con số không thì mất một buổi chiều không bao giờ đến.
Đó là toàn bộ lập luận. Không phải mô hình viết hay hơn nhóm của bạn — nó không. Mà là bản nháp bạn chỉnh sửa vào thứ Ba thì tồn tại, còn bài viết bạn định viết thì không.
Lộ trình là một kế hoạch bạn đã viết rồi
Phần lớn sáu tháng đã được quyết định rồi. Bạn biết đại khái những gì sẽ phát hành trong hai quý tới, những phần nào của sản phẩm bị hiểu lầm, những tích hợp nào người ta cứ hỏi mãi, và những câu hỏi nào xuất hiện ở bộ phận hỗ trợ mỗi tuần.
Mỗi cái đó là một chủ đề. Lộ trình cung cấp nhịp độ — một bản phát hành trở thành chuỗi các ô thay vì một mục nhật ký thay đổi — và hỗ trợ khách hàng cung cấp nửa còn lại bền vững, vì một câu hỏi được hỏi hai mươi lần mỗi tháng là một bài đáng viết một lần và liên kết đến mãi mãi.
Hãy để lại khoảng trống. Bản phát hành hay bị trễ, và một kế hoạch không có ô trống nào sẽ biến một bản phát hành trễ thành ba bài viết về một thứ chưa tồn tại. Để mở một phần tư số ô không phải là lười biếng; đó chính là phần của kế hoạch sống sót khi va chạm với lịch trình thực tế của bạn.
- 1BlogĐã phát hành gì và tại sao nó tồn tại. Vấn đề trước, tính năng sau.
- 2Facebook / InstagramPhiên bản một câu, dành cho những người sẽ không bao giờ mở nhật ký thay đổi.
- 3BlogAi đó thực sự đã dùng nó thế nào. Cụ thể, giữ nguyên cả những phần lúng túng.
- ·Nếu bị trễCác ô di chuyển theo bản phát hành. Không có gì được công bố về một thứ chưa tồn tại.
- 4BlogCâu hỏi hỗ trợ mà bản phát hành này cuối cùng đã trả lời, viết một lần duy nhất.
Lộ trình đặt nhịp độHỗ trợ khách hàng đặt chủ đề
Nhật ký thay đổi của bạn không phải nội dung. Đó là một biên lai.
Hai người viết, đôi khi là ba
Người giải thích sản phẩm, và người nói về công ty
Đó thực sự là hai giọng điệu khác nhau, và việc gộp chúng lại tạo ra sự nhạt nhẽo đặc trưng mà các blog phần mềm vẫn nổi tiếng — một bài viết không phải là giải thích kỹ thuật cũng không phải là lời kể của con người về bất cứ điều gì.
Người viết kỹ thuật
Giải thích một thứ làm gì, chính xác, không dùng tính từ. Biết sản phẩm của bạn dùng để làm gì và không dùng để làm gì, và được phép nói điều đó. Đây là người viết mà bài của họ được liên kết từ các phiếu hỗ trợ.
Giọng điệu công ty
Viết về các quyết định, sự đánh đổi và những gì bạn đang hướng tới. Hữu ích theo cách khó đo lường nhưng rõ ràng trong tuyển dụng, trong các cuộc gọi bán hàng, và trong lý do bất kỳ ai chọn một nhà cung cấp nhỏ thay vì một nhà cung cấp lớn.
Người trả lời
Xử lý bình luận theo chính sách của bạn. Trả lời những gì có thể, gắn cờ những gì không thể, và không bao giờ suy đoán về lộ trình. Bất cứ thứ gì giống như một sự cố hỗ trợ đều được chuyển ngay lập tức cho một con người.
Cổng phê duyệt đang làm việc thực sự ở đây
Với một tiệm bánh, một bài chưa được phê duyệt chỉ là một sự bối rối nhỏ. Với một công ty phần mềm, đó là một gánh nặng hỗ trợ, một phản đối bán hàng, hoặc một cam kết không ai đồng ý. Một bản nháp mô tả sai nhẹ một giới hạn sẽ bị khách hàng trích dẫn lại cho bạn, và một bản nháp hé lộ ngày tháng sẽ bị coi là lời hứa.
Vì vậy đây là trường hợp autopilot cần được thận trọng nhất. Một cách sắp xếp hợp lý là autopilot cho các ô mạng xã hội ngắn chỉ nhắc lại điều đã công bố, và phê duyệt cho mọi thứ đưa ra tuyên bố về sản phẩm. Bất cứ điều gì về giá, năng lực hay ngày tháng nên được một con người đọc vĩnh viễn, và đáng để ghi điều đó vào quy tắc của người viết để các bản nháp loại đó được giữ lại và gắn cờ thay vì được xếp vào hàng đợi.
Báo cáo nói gì với một đội nhỏ
Đã lên kế hoạch so với đã công bố là con số quan trọng, và với một đội phần mềm, nó thường gây khó chịu trong quý đầu tiên. Nó cũng là thước đo trung thực duy nhất cho việc viết có còn thua bản phát hành hay không.
Sự đón nhận ít quan trọng hơn vẻ ngoài của nó. Một bài kỹ thuật tìm được độc giả của nó sau nhiều tháng, không phải nhiều ngày, và đánh giá nó vào tuần thứ hai sẽ khiến bạn loại bỏ những bài vốn sẽ hiệu quả. Cân bằng chủ đề hữu ích hơn trong giai đoạn đầu: nó cho thấy bạn có chỉ viết về những gì đã phát hành hay không, đây là chế độ thất bại tiêu chuẩn và là lý do rất nhiều blog phần mềm đọc giống như một nhật ký thay đổi có đoạn văn.
Phần trung thực: nếu sản phẩm của bạn thực sự mang tính kỹ thuật, những bài sâu nhất vẫn cần một kỹ sư trong một buổi chiều. Điều mà một kế hoạch thay đổi là những buổi chiều đó được xếp lịch, và 80% phần còn lại của việc viết không còn cạnh tranh với chúng.