FABLS
เปิด FABLS

SaaS

คุณส่งมอบซอฟต์แวร์ทุกสองสัปดาห์ แต่เขียนเกี่ยวกับมันปีละสองครั้ง

ทีมซอฟต์แวร์ไม่ได้ขาดเรื่องที่จะเล่า พวกเขาขาดคนที่จะเล่ามัน เพราะการเขียนคืองานที่ถูกเลื่อนออกไปทุกครั้งที่รีลีสล่าช้า และมันถูกเลื่อนทุกครั้ง จนกระทั่งโพสต์ล่าสุดของบล็อกอายุสิบเอ็ดเดือนและขึ้นต้นว่า "ขอแนะนำ"

ความล้มเหลวนี้เป็นเรื่องโครงสร้าง ไม่ใช่เรื่องการเขียน

ทุกทีมรู้ว่าควรเขียนมากขึ้น วิศวกรเขียนได้ ผู้ก่อตั้งเขียนได้ มักมีใครสักคนที่สนุกกับมัน ปัญหาคือการเขียนไม่มีกำหนดส่งของตัวเอง และสิ่งที่ไม่มีกำหนดส่งจะแพ้ให้กับสิ่งที่มีทุกครั้ง ทุกสองสัปดาห์ ตลอดไป

แผนช่วยเติมกำหนดส่งที่หายไป ช่องที่มีวันกำหนด พร้อมหัวข้อและผู้เขียนที่ระบุไว้ คือคำมั่นที่ให้ไว้ในสัปดาห์ที่สงบ และถูกบังคับใช้ในสัปดาห์ที่ไม่สงบ ร่างจะปรากฏขึ้นไม่ว่าใครจะจำได้หรือไม่ การอนุมัติใช้เวลาไม่กี่นาที แต่การเขียนจากศูนย์ต้องใช้บ่ายทั้งบ่ายที่ไม่เคยมาถึง

นั่นคือข้อโต้แย้งทั้งหมด ไม่ใช่ว่าโมเดลเขียนได้ดีกว่าทีมของคุณ มันไม่ได้ แต่ร่างที่คุณแก้ในวันอังคารมีอยู่จริง ส่วนโพสต์ที่คุณตั้งใจจะเขียนไม่มี

โรดแมปคือแผนที่คุณเขียนไว้แล้ว

ส่วนใหญ่ของหกเดือนนั้นถูกตัดสินใจไว้แล้ว คุณรู้คร่าว ๆ ว่าจะส่งมอบอะไรในสองไตรมาสข้างหน้า ส่วนไหนของผลิตภัณฑ์ถูกเข้าใจผิด อินทิเกรชันไหนที่คนขอบ่อย และคำถามไหนที่เข้ามาในฝ่ายสนับสนุนทุกสัปดาห์

แต่ละอย่างเหล่านี้คือหัวข้อเนื้อหา โรดแมปเป็นตัวกำหนดจังหวะ — การเปิดตัวหนึ่งครั้งกลายเป็นชุดของช่องเวลาหลายช่อง แทนที่จะเป็นรายการเดียวในบันทึกการเปลี่ยนแปลง — และฝ่ายสนับสนุนเป็นตัวกำหนดเนื้อหาครึ่งหลังที่ใช้ได้ตลอดไป เพราะคำถามที่ถูกถามยี่สิบครั้งต่อเดือนคือเนื้อหาที่ควรเขียนครั้งเดียวแล้วเชื่อมโยงไปใช้ตลอดไป

เว้นช่องว่างไว้ การเปิดตัวมักเลื่อนกำหนด และแผนที่ไม่มีช่องว่างเลยจะทำให้การเปิดตัวที่เลื่อนกลายเป็นบทความสามชิ้นเกี่ยวกับสิ่งที่ยังไม่มีอยู่จริง การเว้นช่องว่างไว้หนึ่งในสี่ไม่ใช่ความหลวม แต่เป็นส่วนของแผนที่จะยังอยู่ได้เมื่อปะทะกับตารางงานจริงของคุณ

ฤดูกาลและช่องว่างทำงานอย่างไร →

เปิดตัวหนึ่งครั้ง บทความสามชิ้นภาพประกอบ
  • 1บล็อกมีอะไรออกมาและทำไมจึงมีอยู่ เล่าปัญหาก่อน แล้วจึงเล่าฟีเจอร์
  • 2Facebook / Instagramเวอร์ชันสรุปหนึ่งประโยค สำหรับคนที่จะไม่เปิดบันทึกการเปลี่ยนแปลงเลย
  • 3บล็อกมีคนใช้งานจริงอย่างไร จับต้องได้ และเก็บส่วนที่ไม่ราบรื่นไว้ในเนื้อหาด้วย
  • ·หากเลื่อนกำหนดช่องเวลาทั้งหมดจะขยับตามการเปิดตัว ไม่มีการประกาศสิ่งที่ยังไม่มีอยู่จริง
  • 4บล็อกคำถามจากฝ่ายสนับสนุนที่การเปิดตัวครั้งนี้ตอบได้ในที่สุด เขียนครั้งเดียวจบ

โรดแมปเป็นตัวกำหนดจังหวะฝ่ายสนับสนุนเป็นตัวกำหนดหัวข้อ

บันทึกการเปลี่ยนแปลงของคุณไม่ใช่เนื้อหา มันคือใบเสร็จ

นักเขียนสองคน บางครั้งสามคน

คนที่อธิบายผลิตภัณฑ์ และคนที่พูดถึงบริษัท

นี่คือสองเสียงที่แตกต่างกันจริง ๆ และการรวมเข้าด้วยกันจะได้ความจืดชืดแบบเฉพาะที่บล็อกซอฟต์แวร์ขึ้นชื่อ — บทความที่ไม่ใช่คำอธิบายทางเทคนิค และก็ไม่ใช่การเล่าเรื่องด้วยมุมมองมนุษย์เรื่องใดเลย

นักเขียนสายเทคนิค

อธิบายว่าสิ่งนั้นทำอะไรได้อย่างแม่นยำ โดยไม่ใช้คำคุณศัพท์ รู้ว่าผลิตภัณฑ์ของคุณเหมาะกับอะไรและไม่เหมาะกับอะไร และได้รับอนุญาตให้พูดเช่นนั้นได้ นี่คือนักเขียนที่บทความของเขาถูกแนบลิงก์ไว้ในตั๋วงานสนับสนุน

เสียงของบริษัท

เขียนเกี่ยวกับการตัดสินใจ การแลกเปลี่ยนทางเลือก และสิ่งที่คุณกำลังมุ่งสร้าง เป็นประโยชน์ในแบบที่วัดยากแต่เห็นชัดในการสรรหาพนักงาน ในการประชุมการขาย และในเหตุผลที่ใครบางคนเลือกผู้ให้บริการรายเล็กแทนรายใหญ่

ผู้ตอบคำถาม

ดูแลความคิดเห็นตามนโยบายของคุณ ตอบในสิ่งที่ตอบได้ ระบุสิ่งที่ตอบไม่ได้ และไม่เดาเรื่องโรดแมปเด็ดขาด สิ่งใดที่ดูเหมือนเหตุการณ์สนับสนุนจะถูกส่งต่อให้คนดูแลทันที

ด่านการอนุมัติทำงานอย่างมีความหมายจริง ๆ ที่นี่

สำหรับร้านเบเกอรี่ การโพสต์ที่ยังไม่ได้อนุมัติเป็นเรื่องน่าอายเพียงเล็กน้อย แต่สำหรับบริษัทซอฟต์แวร์ มันคือภาระงานสนับสนุน ข้อโต้แย้งในการขาย หรือคำมั่นที่ไม่มีใครเห็นชอบ ร่างบทความที่อธิบายข้อจำกัดผิดเพียงเล็กน้อยจะถูกลูกค้ายกมาอ้างกลับหาคุณ และร่างที่ใบ้วันที่จะถูกตีความว่าเป็นคำสัญญา

ดังนั้นนี่คือกรณีที่ระบบอัตโนมัติควรได้รับความระมัดระวังมากที่สุด การจัดวางที่สมเหตุสมผลคือใช้ระบบอัตโนมัติกับช่องโซเชียลสั้น ๆ ที่เป็นเพียงการพูดซ้ำสิ่งที่เผยแพร่ไปแล้ว และใช้การอนุมัติกับทุกอย่างที่กล่าวอ้างเกี่ยวกับผลิตภัณฑ์ เรื่องราคา ความจุ หรือวันที่ ควรให้คนอ่านตรวจเสมอ และควรเขียนกฎนี้ไว้ในกฎของนักเขียน เพื่อให้ร่างลักษณะนี้ถูกเก็บไว้และแจ้งเตือน แทนที่จะถูกจัดเข้าคิว

รายงานบอกอะไรทีมเล็กได้บ้าง

ตัวเลขที่สำคัญที่สุดคือแผนไว้เทียบกับเผยแพร่แล้ว และสำหรับทีมซอฟต์แวร์ ตัวเลขนี้มักทำให้ไม่สบายใจในไตรมาสแรก แต่มันก็เป็นมาตรวัดเดียวที่ตรงไปตรงมาว่าการเขียนยังแพ้ให้กับการเปิดตัวอยู่หรือไม่

การตอบรับสำคัญน้อยกว่าที่ดูเหมือน บทความเชิงเทคนิคจะหาผู้อ่านของมันเจอในระยะเวลาเป็นเดือน ไม่ใช่เป็นวัน และการตัดสินมันในสัปดาห์ที่สองจะทำให้คุณเลิกใช้บทความที่แท้จริงแล้วจะได้ผล สมดุลของหัวข้อใช้ประโยชน์ได้มากกว่าในช่วงแรก: มันแสดงให้เห็นว่าคุณเขียนเกี่ยวกับสิ่งที่เปิดตัวเท่านั้นหรือเปล่า ซึ่งเป็นรูปแบบความล้มเหลวมาตรฐาน และเป็นเหตุผลที่บล็อกซอฟต์แวร์จำนวนมากอ่านเหมือนบันทึกการเปลี่ยนแปลงที่มีย่อหน้า

ส่วนที่ตรงไปตรงมา: หากผลิตภัณฑ์ของคุณเป็นเชิงเทคนิคอย่างแท้จริง บทความที่ลึกที่สุดก็ยังต้องใช้วิศวกรหนึ่งบ่าย สิ่งที่แผนช่วยเปลี่ยนคือทำให้บ่ายเหล่านั้นถูกจัดลงตาราง และการเขียนอีกแปดสิบเปอร์เซ็นต์ที่เหลือเลิกแย่งเวลากับมัน