การประชุมที่ทุกคนพยักหน้า: รายงานที่ไม่มีใครใช้
ผมจำการประชุมนั้นได้ชัดเจน ผู้มีส่วนได้ส่วนเสียแปดคน ห้องประชุมหนึ่งห้อง เก้าสิบนาที หัวหน้าฝ่ายปฏิบัติการอธิบายว่ารายงานควรแสดงอะไร ฝ่ายการเงินเพิ่ม KPI สองตัว IT ยืนยันว่าทำได้ ทุกคนพยักหน้าในช่วงเวลาที่เหมาะสม BA กรอกบันทึกหกหน้า ผมออกจากการประชุมคิดว่าเราได้ความต้องการที่ชัดเจน
หกเดือนต่อมา รายงานมีอัตราการ adoption 12%
คุณเคยอยู่ในการประชุมนี้ การประชุมที่เลิกตรงเวลา ผลิตรายงานการประชุมที่สะอาด และส่งโครงการต่อไปด้วยการจัดแนวที่ดูเหมือนชัดเจน ไม่มีใครคัดค้าน ไม่มีใครถามคำถามยาก BA บันทึกความเห็นพ้องของห้องประชุมและเรียกมันว่าสเปค
จากนั้นคุณส่งมอบรายงาน มันนั่งอยู่ใน workspace คนที่อนุมัติมันเปิดดูสองครั้งแล้วก็เดินหน้าต่อ ผู้ใช้ภาคสนามที่มันควรจะรับใช้ไม่เคยได้ยินเรื่องมัน นักวิเคราะห์ที่สามารถบอกคุณได้ว่าอะไรที่จำเป็นจริงๆ ไม่ได้อยู่ในห้อง
ผมใช้เวลานานกว่าที่ควรในการเข้าใจสิ่งที่เกิดขึ้น หลายปีที่ผมจัด workshop แบบเดิมและโทษผลลัพธ์ต่อผู้มีส่วนได้ส่วนเสียที่ไม่รู้ว่าตัวเองต้องการอะไร พวกเขารู้ แค่ไม่ได้พูดมันในห้องนั้น
สิ่งที่ผมเรียนรู้ โครงการแล้วโครงการเล่า คือการประชุมไม่ได้ล้มเหลว การประชุมทำสิ่งที่การประชุมทำ อย่างชัดเจน: มันผลิตความเห็นพ้องในหมู่คนที่อยู่ร่วม ภายใต้เงื่อนไขทางสังคมที่มีอยู่
เงื่อนไขมักจะเหมือนกันเสมอ ผู้มีส่วนได้ส่วนเสียอาวุโสกำหนดทิศทาง คนอื่นทุกคนปรับตัวตามทิศทางนั้น BA บันทึกการปรับตัวและเรียกมันว่าสเปค ไม่มีใครโกหก ไม่มีใครไม่สามารถ รูปแบบนั้นเลือกผลลัพธ์ประเภทหนึ่ง ผลลัพธ์นั้นไม่ใช่ความจริง
เราเรียกการประชุมเหล่านี้ว่า "การเก็บรวบรวมความต้องการ" แต่ไม่ใช่ มันคือพิธีกรรมฉันทามติ ผลลัพธ์สะท้อนว่าใครอยู่ในห้อง ใครพูดก่อน และใครรู้สึกปลอดภัยพอที่จะไม่เห็นด้วย
และสเปคที่สร้างบนความเงียบนั้นจะผลิตรายงานที่อธิบายสิ่งที่ผู้มีส่วนได้ส่วนเสียอาวุโสต้องการเห็น ไม่ใช่สิ่งที่องค์กรจำเป็นต้องรู้
ข้อมูลที่ซื่อสัตย์ที่สุดที่ผมเคยได้รับในโครงการ BI ไม่เคยมาในห้องประชุม มันมาหลังจากนั้น ในทางเดิน ในอีเมล follow-up ที่ส่งมาดึกดื่น ในบทสนทนาด้านข้างที่คนพูดสิ่งที่พวกเขาคิดจริงๆ เพราะแรงกดดันของผู้ฟังหมดไปแล้ว
รูปแบบนั้นซ้ำกันอย่างสม่ำเสมอจนกลายเป็นบทเรียนที่ชัดเจนที่สุดในอาชีพของผม: การประชุมไม่ใช่ที่ที่คุณเรียนรู้ว่าผู้มีส่วนได้ส่วนเสียต้องการอะไร การประชุมคือที่ที่คุณเรียนรู้ว่าพวกเขายินดีพูดอะไรต่อหน้าสาธารณะ
รายงานที่รอดคือรายงานที่สร้างบนข้อมูลจากทุก persona ที่สัมผัสผลลัพธ์สุดท้าย ผู้บริหารที่จ้าง นักวิเคราะห์ที่สร้าง ผู้ใช้ภาคสนามที่อ่านรายงานทุกเช้า คนที่จะรับช่วงต่อในอีกหนึ่งปี เมื่อทุกคนมีส่วนร่วมก่อนที่สเปคจะถูกเขียน และเมื่อไม่มีใครเห็นว่าคนอื่นพูดอะไร การ adoption ก็ตามมาเองตามธรรมชาติ
เมื่อมีแค่ห้องประชุมตัดสิน รายงานก็ตายเงียบๆ ไม่มีใครร้องเรียน ไม่มีใครส่งอีเมลโกรธ รายงานแค่หยุดถูกเปิด หกเดือนต่อมา มีคนขอรายงานใหม่ วัฏจักรเริ่มต้นใหม่
หากรายงาน BI สุดท้ายของคุณมีอัตราการ adoption ที่คุณไม่อยากวัด ให้ดูว่าความต้องการถูกเก็บรวบรวมอย่างไร นับว่ามีกี่เสียงที่กำหนดสเปคเทียบกับกี่คนที่ใช้รายงานทุกวัน ช่องว่างระหว่างตัวเลขสองตัวนั้นคือช่องว่างระหว่างสิ่งที่ถูกพูดในห้องประชุมและสิ่งที่จำเป็นในภาคปฏิบัติ
ทุกการประชุมผู้มีส่วนได้ส่วนเสียที่ผลิตฉันทามติสุภาพแทนความต้องการจริงเพิ่มสัปดาห์ของงานแก้ไขหลังการส่งมอบ องค์กรที่หลีกเลี่ยงสิ่งนี้ดำเนินการการค้นพบแบบไม่ระบุตัวตนที่มีโครงสร้างก่อนที่สเปคจะถูกเขียน ไม่ใช่ workshop ที่ลำดับชั้นกำหนดว่าอะไรที่ถูกพูด หากโครงการ BI ถัดไปของคุณเริ่มต้นด้วยการประชุมที่เสียงดังที่สุดกำหนดสเปค มันเริ่มต้นผิดตั้งแต่แรก
ถามพวกเขาแยกกัน ถามพวกเขาแบบไม่ระบุตัวตน
ช่องว่างระหว่างสิ่งที่คนพูดในการประชุมกับสิ่งที่พวกเขาพูดเมื่อไม่มีใครดูอยู่คือจุดที่การ adoption ของรายงานถูกตัดสิน เราเก็บข้อมูลทั้งสองส่วนก่อนที่สเปคจะถูกเขียน
พูดคุยกับเราคำถามที่พบบ่อย
ทำไม workshop ผู้มีส่วนได้ส่วนเสียจึงผลิตความต้องการที่นำไปสู่รายงานที่ไม่ถูกใช้?
Workshop เก็บรวบรวมสิ่งที่คนยินดีพูดต่อสาธารณะ ซึ่งถูกกำหนดโดยว่าใครอยู่ในห้อง เสียงที่อาวุโสที่สุดกำหนดทิศทาง คนอื่นทุกคนปรับตาม ผลลัพธ์ผ่านไปในฐานะความเห็นพ้อง แต่สะท้อนลำดับชั้น ไม่ใช่ความต้องการ รายงานที่สร้างบนข้อมูลแบบลำดับชั้นรับใช้ mental model ของผู้จ้าง ไม่ใช่ความเป็นจริงประจำวันของคนที่ควรจะใช้มัน
อะไรคือความแตกต่างระหว่างฉันทามติของผู้มีส่วนได้ส่วนเสียกับความต้องการที่แท้จริง?
ฉันทามติคือตำแหน่งที่ก่อให้เกิดข้อโต้แย้งน้อยที่สุดที่กลุ่มจะยอมรับในสภาพแวดล้อมร่วม ความต้องการที่แท้จริงปรากฏขึ้นเมื่อผู้มีส่วนได้ส่วนเสียแต่ละคนแสดงความต้องการของตนอย่างอิสระ โดยไม่เห็นว่าคนอื่นพูดอะไร ช่องว่างนั้นสามารถวัดได้ เปรียบเทียบสเปคที่ออกมาจาก workshop กับสิ่งที่คนกลุ่มเดียวกันพูดเมื่อถูกถามเป็นรายบุคคลและแบบไม่ระบุตัวตน ไม่ค่อยเป็นเอกสารเดียวกัน
คุณรู้ได้อย่างไรว่าการ adoption รายงานต่ำเป็นความล้มเหลวด้านความต้องการ?
ติดตามว่าใครกำหนดสเปคและใครใช้รายงาน หากสเปคถูกเขียนโดยผู้มีส่วนได้ส่วนเสียอาวุโสสี่คนและรายงานมีไว้สำหรับผู้ใช้รายวันสี่สิบคน ฐานข้อมูลมีขนาดแคบเกินไป การ adoption ต่ำหลังการส่งมอบที่ถูกต้องทางเทคนิคมักเป็นสัญญาณว่าการพัฒนาตอบคำถามที่ถูกต้องสำหรับผู้ฟังที่ผิด
ทีม BI สามารถฟื้นฟูการ adoption บนรายงานที่สร้างจากฉันทามติเท็จได้หรือไม่?
การฟื้นฟูเริ่มต้นด้วยการเก็บรวบรวมข้อมูลที่ขาดหายไป: ผู้ใช้รายวันจริงๆ ต้องการให้รายงานนี้แสดงอะไร? การค้นพบแบบไม่ระบุตัวตนที่มีโครงสร้างหนึ่งรอบจากคนที่หยุดเปิดรายงานจะค้นพบช่องว่างระหว่างสิ่งที่ถูกระบุและสิ่งที่จำเป็น การ rebuild จากตรงนั้นเป็นการกำหนดเป้าหมาย ไม่ใช่การเริ่มใหม่ทั้งหมด