คุณจัดการกับข้อกำหนดทางธุรกิจที่ไม่ชัดเจนหรือกำกวมอย่างไรก่อนที่จะเริ่มเขียนโค้ด?

Question

Accepted Answer

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

## ผมขจัดหมอกอย่างไร

- **ถามว่าทำไม ไม่ใช่แค่ถามว่าอะไร** เรากำลังพยายามสร้างผลลัพธ์อะไร? เหตุผลเบื้องหลังคำขอมักเผยทางออกที่ง่ายกว่าหรือแตกต่างจากที่ระบุมา
- **หาผู้ใช้จริงและตัวชี้วัดความสำเร็จ** ใครเจ็บปวด และเราจะรู้ได้อย่างไรว่าแก้แล้ว? คำว่า "เสร็จ" ต้องมีนิยามที่คุณชี้ให้ดูได้
- **กล่าวทวนความเข้าใจของคุณกลับไป** การถอดความด้วยคำพูดของคุณเองจะทำให้ความไม่ตรงกันโผล่ขึ้นมาทันที ซึ่งถูกกว่าการมาเจอตอน demo มาก
- **ใช้ตัวอย่าง, mockups และ acceptance criteria** ชิ้นงานที่เป็นรูปธรรมบังคับให้ไอเดียที่ฟุ้งต้องลงตัวเสียที "Given X, when Y, then Z" เปลี่ยนความคิดเห็นให้กลายเป็นข้อความที่ทดสอบได้
- **ดึง edge case ขึ้นมาตั้งแต่เนิ่นๆ** แล้วถ้า empty state, error, input ขนาดใหญ่ หรือ permission ล่ะ? ถามตอนนี้ราคาถูก แต่มาค้นพบตอนขึ้น production ไม่ถูกเลย
- **จดบันทึกและยืนยัน** สรุปสั้นๆ เป็นลายลักษณ์อักษรที่ผู้มีส่วนได้ส่วนเสียเห็นพ้อง จะกลายเป็นแหล่งความจริงร่วมและเป็นสิ่งที่คุณยึดไว้สร้าง

## จากนั้นตรวจสอบทีละเล็ก

- สร้าง **ชิ้นเล็กที่สุด** ที่พิสูจน์ความเข้าใจ ไม่ว่าจะเป็นเส้นทาง end-to-end แบบบางๆ หรือ prototype ด่วน แล้วรับ feedback ก่อนจะลงทุนกับการสร้างเต็มรูปแบบ ซอฟต์แวร์จริงที่อยู่ตรงหน้าผู้มีส่วนได้ส่วนเสียทำให้กระจ่างได้มากกว่าเอกสารใดๆ

## ทำไมจึงสำคัญ

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