นักพัฒนาสามรายที่เสนอราคาสำหรับบรีฟเดียวกันที่ 40,000, 90,000 และ 250,000 โดยทั่วไปไม่ได้เห็นต่างกันเรื่องอัตราค่าบริการ แต่กำลังเสนอราคาสำหรับผลิตภัณฑ์คนละแบบ เพราะบรีฟเปิดให้ตีความได้หลายแนวทาง
เหตุใดราคาจึงแตกต่างกันมาก
บรีฟที่ระบุเพียงว่า "ผู้ใช้สามารถอัปโหลดเอกสารได้" ปล่อยให้การตัดสินใจที่มีต้นทุนสูงทุกอย่างยังไม่มีข้อสรุป ต้องรองรับไฟล์ขนาดเท่าไร รูปแบบไฟล์ใดบ้าง มีการสแกนไวรัสหรือไม่ แสดงตัวอย่างในเบราว์เซอร์หรือให้ดาวน์โหลดเท่านั้น ต้องมีการจัดการเวอร์ชันหรือไม่ ใครสามารถเห็นไฟล์ของใครได้บ้าง ต้องเก็บรักษาและลบข้อมูลอย่างไร
นักพัฒนาที่เสนอราคาอย่างรอบคอบจะสมมติว่าเป็นกรณีใช้งานแบบง่าย ส่วนผู้ที่เสนอราคาอย่างป้องกันความเสี่ยงจะสมมติว่าเป็นกรณีซับซ้อนและคิดราคาเผื่อไว้ ทั้งสองฝ่ายต่างก็มีเหตุผล ผู้ซื้อจึงสรุปว่าฝ่ายที่เสนอราคาแพงกำลังคิดราคาเกินจริง เลือกผู้เสนอราคาถูก และพบช่องว่างดังกล่าวระหว่างการพัฒนา ซึ่งในจุดนั้นจะกลายเป็นคำขอเปลี่ยนแปลง
ห้าเรื่องที่ต้องระบุให้ชัดเจน
- บทบาทของผู้ใช้และสิ่งที่แต่ละบทบาททำได้ ไม่ใช่เพียง "ผู้ดูแลระบบและผู้ใช้" แต่ต้องระบุรายการการดำเนินการของแต่ละบทบาท ตรรกะด้านสิทธิ์เป็นสัดส่วนงานที่มากในแอปพลิเคชันธุรกิจส่วนใหญ่ และมักมองไม่เห็นจากรายการฟีเจอร์
- กระบวนการทำงานหลักทีละขั้นตอน เขียนลำดับที่ผู้ใช้ดำเนินการจริง รวมถึงสิ่งที่เกิดขึ้นเมื่อมีข้อผิดพลาด เช่น การชำระเงินถูกปฏิเสธ เซสชันหมดอายุ หรือการส่งข้อมูลซ้ำ
- ข้อมูล ต้องจัดเก็บอะไร อะไรเป็นข้อมูลบังคับ ใช้การตรวจสอบแบบใด และเก็บไว้นานเท่าไร รายการฟิลด์มีประโยชน์มากกว่าคำอธิบายหน้าจอ เพราะหน้าจอเปลี่ยนแปลงได้ แต่ข้อมูลไม่เปลี่ยนตาม
- การพึ่งพาระบบภายนอก เช่น การชำระเงิน การส่งข้อความ แผนที่ และระบบเดิมที่ต้องเชื่อมต่อ แต่ละรายการมีเวลาสำหรับการอนุมัติและการจัดการกรณีล้มเหลว ซึ่งต้องนำไปคำนวณในงบประมาณ
- เกณฑ์การยอมรับงาน คุณจะตัดสินอย่างไรว่าโครงการเสร็จสมบูรณ์ ส่วนนี้มักถูกละเลยมากที่สุด และเป็นส่วนที่ช่วยป้องกันข้อโต้แย้งได้มากที่สุด
ระบุปริมาณและประสิทธิภาพเป็นตัวเลข
คำว่า "ควรทำงานได้รวดเร็ว" และ "ควรรองรับผู้ใช้จำนวนมาก" ไม่สามารถใช้เสนอราคาหรือทดสอบได้ แต่ตัวเลขทำได้:
- จำนวนผู้ใช้ที่คาดว่าจะมีในปีแรก และจำนวนผู้ใช้พร้อมกันในช่วงสูงสุด
- จำนวนระเบียนที่คาดว่าจะมีในตารางที่ใหญ่ที่สุดหลังผ่านไปหนึ่งปี
- เวลาตอบสนองที่ยอมรับได้สำหรับการดำเนินการทั่วไปที่ช้าที่สุด
- ขนาดไฟล์และพื้นที่จัดเก็บรวม
ข้อมูลเหล่านี้ส่งผลต่อสถาปัตยกรรม ระบบที่ออกแบบสำหรับผู้ใช้ 200 รายกับระบบที่ออกแบบสำหรับผู้ใช้ 200,000 รายแตกต่างกันทั้งในด้านการออกแบบฐานข้อมูล แคช และค่าโฮสติ้ง อีกทั้งการสร้างระบบแบบที่สองทั้งที่คุณต้องการเพียงแบบแรกยังทำให้งบประมาณที่อาจนำไปใช้กับฟีเจอร์ได้สูญเปล่า
สิ่งที่ไม่ควรใส่ไว้ในข้อกำหนด
มีสองเรื่องที่ทำให้ข้อกำหนดแย่ลง:
การเลือกเทคโนโลยี เว้นแต่จะมีข้อจำกัดที่แท้จริง การระบุเฟรมเวิร์กเพียงเพราะมีผู้แนะนำจะลดความสามารถของนักพัฒนาในการเสนอสิ่งที่เหมาะสมกว่า หากมีข้อจำกัดจริง เช่น ระบบเดิมหรือทีมภายในที่ต้องดูแลรักษาระบบ ให้ระบุข้อจำกัดนั้นแทนการระบุข้อสรุป
การออกแบบระดับพิกเซลในข้อกำหนดด้านฟังก์ชัน ควรแยกการออกแบบออกจากฟังก์ชัน ข้อกำหนดที่ผสมทั้งสองเรื่องเข้าด้วยกันทำให้ตรวจสอบได้ยากขึ้นทั้งคู่ และทำให้ทุกความชอบด้านภาพกลายเป็นการเปลี่ยนแปลงด้านฟังก์ชัน
ส่วนที่มักทำให้เกิดข้อโต้แย้งภายหลัง
โดยพบอย่างสม่ำเสมอและเรียงตามลำดับดังนี้:
- รายงาน คำว่า "รายงาน" ในบรีฟอาจกลายเป็นงานหนึ่งสัปดาห์ต่อรายงานหนึ่งรายการ เมื่อทราบฟิลด์ ตัวกรอง การจัดกลุ่ม และรูปแบบการส่งออกแล้ว
- การแจ้งเตือน อีเมล SMS พุช และการแจ้งเตือนในแอปเป็นการพัฒนาที่แตกต่างกันสี่แบบและมีต้นทุนสี่แบบที่แตกต่างกัน คำว่า "ระบบแจ้งเตือนผู้ใช้" ไม่ได้ระบุรายละเอียดของสิ่งเหล่านี้เลย
- การค้นหา การค้นหาในฟิลด์เดียวเป็นเรื่องง่าย แต่การค้นหาข้ามระเบียนที่เกี่ยวข้องพร้อมการจัดอันดับผลลัพธ์เป็นโครงการแยกต่างหาก
- การย้ายข้อมูล การนำข้อมูลเดิมเข้าระบบมักยากกว่าที่คาดไว้เกือบเสมอ เพราะข้อมูลเดิมไม่สอดคล้องกันในหลายจุดที่ไม่มีใครจัดทำเอกสารไว้
การระบุสี่เรื่องนี้อย่างชัดเจนในข้อกำหนด แม้จะระบุเพียงสั้น ๆ ก็ช่วยเปลี่ยนเรื่องเหล่านี้จากสมมติฐานให้กลายเป็นขอบเขตงาน
แนวทางที่ใช้ได้จริง
ข้อกำหนดที่มีประโยชน์สำหรับโครงการขนาดเล็กมักมีความยาวห้าถึงสิบห้าหน้า ประกอบด้วยรายการบทบาท คำอธิบายกระบวนการทำงาน ฟิลด์ข้อมูล รายการการเชื่อมต่อ ตัวเลขด้านข้อกำหนดที่ไม่ใช่ฟังก์ชัน เกณฑ์การยอมรับงาน และส่วนที่ระบุอย่างชัดเจนว่านอกขอบเขต
ส่วนสุดท้ายมีประโยชน์มากกว่าความยาวของมัน การเขียนว่า "การทำรายงานนอกเหนือจากสามหน้าจอที่ระบุไว้ไม่อยู่ในขอบเขตของระยะนี้" ใช้พื้นที่เพียงหนึ่งบรรทัด และช่วยขจัดข้อโต้แย้งภายหลังได้ทั้งหมวดหมู่
บริการของ Manboo ที่เกี่ยวข้อง
- การพัฒนาแอป Flutter สำหรับ MVP บน iOS และ Android
- การพัฒนาซอฟต์แวร์ธุรกิจ สำหรับระบบ CRM การจอง สินค้าคงคลัง และกระบวนการทำงาน
- การพัฒนาแผงผู้ดูแลระบบ สำหรับแดชบอร์ดการปฏิบัติงานและการจัดการแบ็กเอนด์
- การเชื่อมต่อ AI API เมื่อผลิตภัณฑ์ของคุณพร้อมสำหรับการค้นหาอัจฉริยะ แชต หรือระบบอัตโนมัติ
- ขอให้ตรวจสอบขอบเขตงานและประเมินโครงการ เมื่อคุณพร้อมวางแผนเวอร์ชันแรก