ระหว่างการค้นพบความต้องการกับโค้ดบรรทัดแรก มีเอกสารที่ไม่มีใครเขียน

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

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

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

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

ท่านไม่ได้ล่าช้าเพราะทำงานช้า ท่านล่าช้าเพราะได้รับเพียงข้อค้นพบ แล้วถูกขอให้แปลงมันเป็นข้อกำหนดด้วยตัวคนเดียว ในขณะที่กำลังเขียนโค้ดไปด้วย

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

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

การค้นพบความต้องการสร้างข้อตกลงร่วมกัน โค้ดต้องการความแม่นยำ Build Specification คือจุดที่ข้อตกลงกลายเป็นความแม่นยำ หากข้ามมันไป นักพัฒนาก็ต้องกลายเป็นผู้แปลความเอง อย่างเงียบ ๆ ในจังหวะที่เลวร้ายที่สุด

ที่ WizEmp ขั้นตอนนี้เป็นสิ่งที่เราตั้งใจ การค้นพบความต้องการผ่าน Wit กระบวนการค้นหาข้อมูลเชิงลึกอัจฉริยะที่ขับเคลื่อนด้วย AI ของ WizEmp จะสร้างข้อตกลงร่วมกันว่า ตัวเลขแต่ละตัวหมายถึงอะไร ใครเป็นเจ้าของ และความขัดแย้งของนิยามใดได้รับการคลี่คลายแล้ว จากนั้น The Breeze Blueprint จะเปลี่ยนข้อตกลงนั้นเป็นข้อกำหนดที่นักพัฒนาสร้างต่อได้โดยไม่ต้องเดา ประเด็นไม่ใช่การเพิ่มเอกสาร แต่คือการย้ายการเดาออกจากสัปดาห์ที่สามของการสร้าง มาไว้ก่อนเริ่มสร้าง จุดที่การเดาผิดใช้เวลาแก้เพียงบ่ายเดียว ไม่ใช่ทั้งสปรินต์

หากโครงการล่าสุดของท่านเริ่มจากการค้นพบความต้องการที่ดี แล้วจบลงด้วยกระแส change request ที่ไม่จบสิ้น ลองย้อนดูว่านักพัฒนาได้รับอะไรไปจริง ๆ ได้รับข้อค้นพบ หรือได้รับข้อกำหนด รายงานการค้นพบตอบคำถามว่า "ธุรกิจต้องการอะไร" ส่วน Build Specification ตอบว่า "ต้องสร้างอะไร วัดผลอย่างไร จากแหล่งใด ที่ระดับความละเอียดใด" สองสิ่งนี้เป็นเอกสารคนละฉบับ โครงการส่วนใหญ่สร้างฉบับแรก แล้วก็เช่นเดียวกับตอนที่เขียนข้อกำหนดโดยไม่มีนักพัฒนา คาดหวังให้เขาเนรมิตฉบับที่สองขึ้นเองระหว่างที่เวลาเดินไปเรื่อย ๆ

หากท่านคือนักพัฒนา ท่านเขียนเอกสารนี้ไปครึ่งหนึ่งแล้วในหัวก่อนแตะข้อมูลด้วยซ้ำ เขียนมันลงบนกระดาษเสียก่อน แล้วส่งกลับไปให้ยืนยันก่อนเริ่มสปรินต์แรก หนึ่งชั่วโมงที่ใช้ยืนยันนิยามของตัวชี้วัด คือหนึ่งชั่วโมงที่ตัด change request ทั้งสัปดาห์ออกไปในภายหลัง

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