เทมเพลตวาระประชุม Daily Standup (ที่วิศวกรใช้งานได้จริง)

ปัญหาของเทมเพลต Standup ส่วนใหญ่

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

วาระการประชุม (คัดลอกไปใช้ได้เลย)

ระยะเวลา: ไม่เกิน 10 นาที
รูปแบบ: พร้อมกันแบบ Synchronous แต่ละคนพูดหนึ่งครั้ง

สำหรับสมาชิกทีมแต่ละคน (90 วินาทีต่อคน):

ทำเสร็จตั้งแต่ Standup ครั้งก่อน — ที่ปล่อยหรือ merge แล้ว ไม่ใช่งานที่ยังทำอยู่
แผนวันนี้ — สิ่งที่คุณตั้งใจจะปิดให้จบ ไม่ใช่งาน Sprint แบบเพ้อฝัน
อุปสรรค — ระบุผู้รับผิดชอบ คำว่า "รอ design review" นับได้ก็ต่อเมื่อมีคนรับผิดชอบในการปลดล็อกมัน

หลังจากวนตอบครบ (เวลาที่เหลือ):

การตัดสินใจที่ต้องการ — อะไรก็ตามที่ต้องตัดสินใจเดี๋ยวนี้ ถ้าใช้เวลาเกิน 2 นาที ให้นัดประชุมแยกต่างหาก
ประกาศ — หนึ่งประโยคต่อหนึ่งเรื่อง ไม่ต้องถกเถียงระหว่าง Standup

ที่พักหัวข้อ (Parking lot): เมื่อมีเรื่องหนึ่งโผล่ขึ้นมากลางวงที่ไม่จำเป็นต้องคุยกับทุกคน ให้จดไว้แล้วจัดการหลังจากนั้นหรือแบบ async การพูดคุยในที่พักหัวข้อ — ซึ่งมักจะมีแค่ 2-3 คนแทนที่จะเป็นทั้งทีม — มักมีประโยชน์มากกว่าตัว Standup เสียอีก

สิ่งที่เทมเพลต Standup ส่วนใหญ่พลาดไป

เทมเพลต Standup ที่ติดอันดับต้นๆ มักตกลงไปในสองรูปแบบความล้มเหลว

โครงสร้างพื้นฐานสุด ("คุณทำอะไรไปแล้ว? คุณจะทำอะไรต่อ? มีอุปสรรคไหม?") ใช้ได้ดีจนกระทั่งทีมเริ่มมองอุปสรรคเป็นเรื่องไม่จำเป็น ไม่มีใครเขียนว่า "รอ security review" เพราะเมื่อเขียนไปแล้วก็ไม่มีอะไรเกิดขึ้น สิ่งที่ต้องพึ่งพากันก็หายไป และถูกปลดล็อกโดยใครก็ตามที่บังเอิญถามขึ้นมาในสัปดาห์ถัดไป

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

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

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

ทำไมสรุป Standup ถึงล่มสลาย

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

Standup แบบ async ก่อน — โพสต์อัปเดตของคุณใน Slack ก่อนเข้าคุย — แก้ปัญหาเรื่องการเข้าร่วมได้ แต่กลับสูญเสียความรับผิดชอบที่มาจากการวนตอบสด ผู้คนก็ยังคงถามว่า "เราตกลงเรื่อง X ว่าอย่างไรนะ?" ในภายหลังของวันอยู่ดี

ต้นทุนแฝงสะสมเร็วมาก หากอยากเห็นว่าการสูญเสียบริบทของ Standup ทำให้ทีมต้องจ่ายเท่าไรตลอดหนึ่งไตรมาส ลองอ่าน ภาษีการประชุม

Pavleur จัดการสรุปการประชุมอย่างไร

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

ส่วนที่เครื่องมือแบบเสียงอย่างเดียวพลาดไป คือถ้ามีใครเปิดแดชบอร์ด PR, บอร์ด Jira หรือกราฟการดีพลอยขึ้นมากลาง Standup แล้ว Pavleur จะเก็บภาพนั้นไว้และรวมเข้าไปในรายงานพร้อมบริบท เครื่องมืออย่าง Otter หรือ Fireflies ให้คุณแค่คำพูด ส่วนบันทึกภาพของสิ่งที่อยู่บนหน้าจอนั้นไม่มีเลย ใครก็ตามที่พลาด Standup สามารถอ่านรายงานฉบับเต็มได้โดยไม่ต้องถามว่าเกิดอะไรขึ้น หากคุณกำลังเปรียบเทียบเครื่องมือในแง่มุมนี้ หน้าเปรียบเทียบ ครอบคลุมความแตกต่างเหล่านี้ไว้

การบังคับใช้กรอบเวลา

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

ถ้า Standup ใช้เวลาเกิน 10 นาทีอย่างต่อเนื่อง สาเหตุมักเป็นหนึ่งในสิ่งเหล่านี้ คนเยอะเกินไป (แยก Standup ออกเป็นหลายวง), หัวข้อวาระที่แทรกเข้ามาจากการวางแผน Sprint, หรือหัวข้อสนทนาที่วนซ้ำเป็นประจำซึ่งควรมีการประชุมประจำของตัวเอง จงแก้ที่สาเหตุเชิงโครงสร้าง ไม่ใช่แค่แก้ที่อาการ