วาระประชุม Project Kickoff สำหรับทีมวิศวกรรม

คำถามที่ประชุม Kickoff มักข้ามไป

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

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

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

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

ระยะเวลา: 60–90 นาที ขึ้นอยู่กับความซับซ้อนของโปรเจกต์
รูปแบบ: มีผู้ดำเนินรายการ ผู้มีส่วนได้ส่วนเสียและผู้ร่วมงานหลักทุกคนเข้าร่วมหรือทบทวนแบบ async ก่อนเริ่ม

ส่วนที่ 1 — เป้าหมายและขอบเขตของโปรเจกต์ (20 นาที)

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

ส่วนที่ 2 — บทบาทและความรับผิดชอบ (15 นาที)

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

ส่วนที่ 3 — ข้อจำกัดและความเสี่ยง (15 นาที)

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

ส่วนที่ 4 — แผนการสื่อสาร (10 นาที)

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

ส่วนที่ 5 — คำถามที่ยังเปิดค้าง (15 นาที)

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

ส่วนที่ 6 — ขั้นตอนถัดไป (10 นาที)

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

อะไรที่เทมเพลต Kickoff ยอดนิยมทำผิด

เทมเพลต Kickoff ส่วนใหญ่ละเอียดถี่ถ้วนเรื่องแผนโปรเจกต์แต่บางเบาเรื่องสิ่งที่เกิดขึ้นเมื่อแผนไม่เป็นไปตามที่คิด มันผลิตเอกสารขอบเขตที่สะอาดและตาราง RACI ซึ่งมีประโยชน์ แต่มันไม่ผลิตคำตอบร่วมกันสำหรับ "เราจะทำอย่างไรเมื่อผู้ให้บริการฐานข้อมูลขึ้นราคาสามเท่ากลางโปรเจกต์?" หรือ "อะไรจะถูกตัดถ้าเราถึงกำหนดส่งที่ตายตัวตอนที่ฟีเจอร์เสร็จ 80%?"

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

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

สำหรับวิธีที่ช่องว่างเหล่านี้ทบต้นเป็นภาระตลอดโปรเจกต์หลายเดือน: ภาษีการประชุม

ทำไมบันทึก Kickoff จึงคุ้มค่าที่จะทำให้ถูกต้อง

เอกสาร Kickoff เป็นสิ่งที่ถูกอ้างอิงบ่อยที่สุดในทุกโปรเจกต์ มันคือสิ่งที่คนเปิดดูเมื่อขอบเขตถูกโต้แย้ง เมื่อสมาชิกใหม่เข้าทีม เมื่อผู้มีส่วนได้ส่วนเสียถามว่า "เราไม่ได้ตัดสินใจเรื่อง X ตอน Kickoff หรือ?" Kickoff ที่มีเอกสารครบถ้วนคือโปรเจกต์ที่จัดการได้ง่ายกว่า

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

หมายเหตุเรื่องการเข้าร่วม

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