สเปคผิดตั้งแต่ก่อนที่แถวแรกจะถูกโหลด
ผมใช้เวลาสิบปีแรกของอาชีพ BI ในการรับสเปคที่ไม่ได้มีส่วนร่วมในการเขียน สเปคเหล่านั้นมาถึงในรูปแบบเอกสารที่เสร็จสมบูรณ์แล้ว งานของผมคือสร้างสิ่งที่เอกสารระบุไว้ ผมทำ และบ่อยครั้งเกินไป สิ่งที่ผมสร้างนั้นผิด
ไม่ใช่ผิดเพราะผมอ่านสเปคไม่ถูกต้อง แต่ผิดเพราะสเปคนั้นผิดตั้งแต่แรก
หากคุณเป็นนักพัฒนา BI คุณรู้จักช่วงเวลานี้ สเปควางอยู่บนโต๊ะ มาจาก Business Analyst หรือหัวหน้าแผนก มันบอกว่ารายงานควรมีอะไร งานของคุณคือทำให้เป็นจริง
คุณอ่านมัน คุณมีคำถาม KPI บางตัวถูกนิยามไว้อย่างคลุมเครือ แหล่งข้อมูลบางส่วนไม่มีสิ่งที่สเปคสันนิษฐานว่ามี ตรรกะทางธุรกิจในส่วนที่สามขัดแย้งกับส่วนที่เจ็ด
คุณหยิบยกคำถามเหล่านี้ขึ้นมา บางคำถามได้รับคำตอบ ส่วนใหญ่ได้รับคำตอบแบบ: "สร้างตามที่อยู่ในสเปค เดี๋ยวค่อยปรับทีหลัง"
คุณจึงสร้าง และคุณรู้อยู่แล้วตั้งแต่ data model แรก ว่ารายงานจะไม่ทำสิ่งที่ผู้ร้องขอจินตนาการไว้ คุณรู้เพราะคุณเป็นคนเดียวในกระบวนการที่ได้ดูข้อมูลจริง
หากคุณเป็นที่ปรึกษา BI อิสระ คุณมองเห็นสิ่งนี้จากภายนอก ลูกค้าส่งสเปคที่เขียนโดยคนที่ไม่เคยเปิด data model มาก่อน งานของคุณคือทำให้วิสัยทัศน์ของพวกเขาเข้ากับความเป็นจริงของข้อมูลช่องว่างระหว่างสองสิ่งนั้นคือค่าล่วงเวลาที่คุณไม่ได้รับ
มุมมองทั่วไปคือ งานของนักพัฒนาเริ่มต้นเมื่อสเปคเสร็จสมบูรณ์ ความต้องการถูกเก็บรวบรวมโดย Analyst อนุมัติโดยผู้มีส่วนได้ส่วนเสีย และส่งต่อให้ทีมพัฒนา นักพัฒนาสร้าง
การแบ่งแยกนี้ฟังดูสมเหตุสมผล แต่ในทางปฏิบัติ มันรับประกันว่าสเปคจะมีข้อสันนิษฐานที่ไม่มีใครทดสอบกับความเป็นจริง
Business Analyst เก็บรวบรวมสิ่งที่ผู้มีส่วนได้ส่วนเสียต้องการ นักพัฒนารู้ว่าข้อมูลสามารถส่งมอบอะไรได้ มุมมองทั้งสองนี้พบกันเป็นครั้งแรกในช่วงพัฒนา ในเวลานั้นสเปคถูกเซ็นไปแล้ว งบประมาณถูกผูกมัดแล้ว การเปลี่ยนสเปคหมายถึง change request ผลกระทบต่อเส้นเวลา และบทสนทนาที่ไม่มีใครอยากมี
นักพัฒนาจึงสร้างตามสเปค รายงานถูกส่งมอบ และ feedback รอบแรกเผยให้เห็นสิ่งที่ทุกคนอาจรู้ได้ตั้งแต่สัปดาห์แรก: สเปคอธิบายจินตนาการของผู้ร้องขอ ไม่ใช่ความเป็นจริงของข้อมูล
นักพัฒนาเห็นช่องว่างก่อน พวกเขาเห็นว่า field ที่สเปคอ้างอิงนั้นไม่มีอยู่ใน source system พวกเขาเห็นว่านิยาม KPI ในสเปคผลิตตัวเลขที่ขัดแย้งกับสิ่งที่ฝ่ายการเงินรายงานรายไตรมาส พวกเขาเห็นทั้งหมดนี้ก่อนแถวแรกจะถูกโหลด
ในองค์กรส่วนใหญ่ ความรู้นั้นอยู่กับนักพัฒนา มันปรากฏเป็นเชิงอรรถในรายงานสถานะ หรือปรากฏหลังการส่งมอบในรูป change request ที่นักพัฒนาเห็นมาตั้งแต่วันแรก
นี่ไม่ใช่การบ่นของนักพัฒนา มันคือการวินิจฉัย เมื่อคนที่จะสร้างรายงานถูกกีดกันออกจากการกำหนดว่ารายงานควรมีอะไร สเปคก็จะขาดความสมบูรณ์เชิงโครงสร้าง ทุกโครงการ BI ที่แยกส่วนความต้องการออกจากการพัฒนาจะสร้างช่องว่างนี้ ช่องว่างนั้นไม่ได้เกิดจากความไม่สามารถของฝ่ายใดฝ่ายหนึ่ง แต่เกิดจากกระบวนการที่แยกสองมุมมองสำคัญออกจากกันจนกว่าการปรองดองจะมีค่าใช้จ่ายสูง
ที่ปรึกษาอิสระที่รับมรดกสเปคที่ไม่ดีต้องแบกรับงานแก้ไขในชั่วโมงที่ไม่ได้รับค่าจ้าง นักพัฒนาภายในองค์กรแบกรับมันในรูปความหงุดสีดและค่าล่วงเวลาที่ไม่มีใครติดตาม ทั้งคู่แบกรับความล้มเหลวเชิงโครงสร้างเดียวกัน ทั้งคู่เห็นมันมาก่อน
หากคุณจ้างสร้างรายงาน BI ถามคำถามหนึ่งข้อก่อนเริ่มการพัฒนาครั้งต่อไป: นักพัฒนาได้ตรวจสอบสเปคก่อนที่จะเซ็นหรือไม่? ไม่ใช่หลังจาก ไม่ใช่ระหว่างการพัฒนา แต่ก่อน
หากการพบกันครั้งแรกของนักพัฒนากับสเปคคือวันที่พวกเขาเริ่มสร้าง สเปคก็จะมีข้อสันนิษฐานเกี่ยวกับข้อมูลที่ไม่มีใครยืนยัน ข้อสันนิษฐานเหล่านั้นกลายเป็น change request ที่คุณจะจัดการในสามเดือนข้างหน้า
หากคุณเป็นนักพัฒนาที่รับสเปคบันทึกสิ่งที่คุณเห็น ช่องว่างที่คุณพบในสัปดาห์แรกคือช่องว่างที่องค์กรจะจ่ายเงินเพื่อค้นพบหลังการส่งมอบ การทำให้มันมองเห็นได้แต่เนิ่นๆ คือการกระทำที่มีคุณค่าสูงสุดในโครงการทั้งหมด
สเปคที่สร้างจากเอกสารสั้นที่ส่งมาโดยไม่มีข้อมูลจากนักพัฒนาจะผิดก่อนที่แถวแรกจะถูกโหลด งานแก้ไขสะสมกับทุก sprint ที่สร้างบนข้อสันนิษฐานเหล่านั้น ก่อนที่ช่วงการพัฒนาจะเริ่มต้นเซสชันที่มีโครงสร้างหนึ่งครั้งจะค้นพบว่าข้อสันนิษฐานใดในสเปคจะสร้าง change request ที่รบกวนมากที่สุด
ให้นักพัฒนาอ่านสเปคก่อน
หนึ่งชั่วโมงกับ data model จะค้นพบสิ่งที่ change request สามเดือนจะค้นพบในท้ายที่สุด เราจัดให้คนที่ใช่อยู่ในห้องก่อนที่จะมีการเซ็นอะไรทั้งนั้น
พูดคุยกับเราคำถามที่พบบ่อย
ทำไมนักพัฒนา BI จึงมักถูกกีดกันออกจากช่วงการกำหนดความต้องการ?
เป็นนิสัยขององค์กร การเก็บรวบรวมความต้องการถูกจัดประเภทเป็นกิจกรรมทางธุรกิจ การสร้างถูกจัดประเภทเป็นกิจกรรมทางเทคนิค นักพัฒนาถูกมอบหมายให้ด้านเทคนิค และไม่มีใครตั้งคำถามว่าขอบเขตนั้นสมเหตุสมผลหรือไม่ มันสมเหตุสมผลเมื่อรายงานเป็นการดึงข้อมูลง่ายๆ จากแหล่งเดียว มันหยุดสมเหตุสมผลเมื่อรายงาน BI กลายเป็นเครื่องมือวิเคราะห์ข้ามระบบ หลายแผนก ที่มีตรรกะทางธุรกิจฝังอยู่ในทุก measure
นักพัฒนาควรทำอย่างไรเมื่อได้รับสเปคที่รู้ว่ามีข้อสันนิษฐานผิด?
บันทึกช่องว่างทุกอย่างก่อน sprint แรก เขียนว่าข้อมูลสามารถและไม่สามารถรองรับอะไรได้ นิยาม KPI ใดที่จะผลิตตัวเลขขัดแย้ง และแหล่งข้อมูลใดที่สเปคสันนิษฐานว่ามีแต่ไม่มี ส่งให้เจ้าของโครงการเป็นลายลักษณ์อักษร ไม่ใช่แบบปากเปล่า เอกสารนั้นคือหลักฐานว่าช่องว่างการค้นพบมีอยู่ก่อนการพัฒนาจะเริ่ม หากปราศจากมัน change request จะถูกโยนให้เป็นความผิดของการพัฒนา ไม่ใช่สเปค
เป็นความผิดของ Business Analyst หรือเมื่อสเปคพลาดความเป็นจริงของข้อมูล?
ไม่ใช่ งานของ BA คือการบันทึกเจตนาของผู้มีส่วนได้ส่วนเสีย งานของนักพัฒนาคือการรู้ภูมิทัศน์ของข้อมูล ไม่มีบทบาทใดที่ถูกออกแบบมาเพื่อทำทั้งสอง ความล้มเหลวของกระบวนการเป็นเชิงโครงสร้าง มันมอบหมายบทบาทเหล่านี้ให้กับช่วงแยกกันและไม่เคยสร้างช่วงเวลาที่มุมมองทั้งสองได้พบกันก่อนสเปคจะถูกเซ็น BA ผลิตบันทึกที่ถูกต้องของสิ่งที่ผู้มีส่วนได้ส่วนเสียพูด นักพัฒนารู้ว่าข้อมูลส่งมอบอะไรได้ สเปคต้องการทั้งสอง และกระบวนการส่วนใหญ่ให้แค่อย่างเดียว
ช่องว่างของสเปคส่งผลต่อการ adoption รายงานระยะยาวอย่างไร?
รายงานที่สร้างบนสเปคที่พลาดความเป็นจริงของข้อมูลจะถูกแก้ไขผ่าน change request แต่การแก้ไขนั้นจัดการกับอาการ ไม่ใช่สาเหตุหลัก รายงานสะสม workaround ตรรกะของมันยิ่งยากต่อการบำรุงรักษา ภายในหนึ่งปี นักพัฒนาที่สร้างมันเป็นคนเดียวที่เข้าใจว่าทำไม measure บางตัวถึงคำนวณในแบบที่เป็น เมื่อนักพัฒนานั้นลาออก รายงานก็เสื่อมหรือถูกแทนที่ ช่องว่างของสเปคไม่เพียงแค่ผลิตงานแก้ไขซ้ำ แต่ยังย่นอายุการใช้งานของรายงานด้วย