ว่าด้วยเรื่องความกำกวมของ Requirement

จากหนังสือ Timeless Laws of Software Development นั้น ในส่วนแรกอธิบายถึงเรื่องการวางแผนก่อนที่จะเริ่มพัฒนาระบบงาน (Plan before implementing) เป็นสิ่งสำคัญมาก ๆ ถ้าไม่วางแผนแล้วจะไปกันอย่างไร แต่ปัญหาอย่างหนึ่งของการวางแผนคือ ความกำกวมหรือคลุมเครือของ requirement โดยในหนังสือมีบทสนทนาเรื่อง requirment ที่น่าสนใจ เลยแปลเก็บไว้นิดหน่อย ไม่แน่ใจว่าใครเคยเจอบ้าง คำถาม ช่วยบอกหน่อยว่าคุณอยากได้ระบบอย่างไร ? ลูกค้าตอบว่า ระบบงานเดิมนั้นพัฒนามาประมาณ 12 ปีแล้ว ซึ่งมันล้าสมัยมาก ๆ เราต้องการที่จะพัฒนาใหม่ ทั้งเรื่องของ software และ hardware คำถาม ดีเลย ช่วยอธิบาย requirement และเอกสารของระบบปัจจุบันให้หน่อย ? ลูกค้าตอบว่า เราไม่มีนะสิ ถึงมีก็ไม่น่าจะใช้ได้ เพราะว่าไม่ได้ update เลย แต่เราต้องการพัฒนาระบบใหม่ที่มีความสามารถเหมือนเดิม และเพิ่มความสามารถใหม่ ๆ เข้าไปด้วย ที่สำคัญเรามี source code ของระบบให้นะ คุณเอาไปดูได้เลย มาถึงตรงนี้ คุณจะพูดอย่างไรต่อดี ? ก่อนที่จะวางแผน ก่อนที่จะออกแบบระบบใหม่ ก่อนที่จะวาง architecture ของระบบใหม่ เราต้องเข้าใจระบบเดิมก่อน ซึ่งระบบมีอายุถึง 12 ปี น่าจะเป็นระบบที่ซับซ้อนมาก ๆ ดังนั้นเราของทำความเข้าใจระบบปัจจุบันก่อนนะครับ น่าจะใช้เวลาอย่างน้อง X สัปดาห์ หลังจากนั้นถึงจะบอกได้ว่าต้องใช้เวลา ค่าใช้จ่ายเท่าไรในการพัฒนาระบบใหม่ เมื่อลูกค้าได้ฟังแล้วก็พูดขึ้นมาว่า อะไร ? ทำไม ? เราให้ source code คุณไปนะ น่าจะคิดได้ วางแผนได้ ออกแบบได้ พัฒนาได้เลยนะ มันรีบ มันด่วนมากเลยนะ

มาถึงตรงนี้เห็นปัญหาอะไรกันบ้าง ?

เรื่องที่ตลกร้ายกว่าคือ มีหลาย ๆ บริษัทกลับประเมินให้อีกด้วย ทั้งเวลา ทั้งค่าใช้จ่าย ตลกร้ายกว่านั้น คนที่ประเมินไม่ใช่คนทำ ส่วนคนทำก็ ... ต่อไป ไม่พอนะ รู้ได้อย่างไรว่า source code ที่มีมันคือ สิ่งที่อยู่บน production ?

คำถามคือ แล้วเราทำการวางแผนได้อย่างไร ? ถ้าเจอ requirement แบบนี้ !!