อีกมุมมองหนึ่งของ Software Product Quality

เชื่อหรือไม่ว่าอุตสาหกรรมซอร์ฟแวร์เป็นหนึ่งในอุตสาหกรรมไม่กี่ชนิดที่ผู้ซื้อไม่ค่อยพอใจกับคุณภาพที่ได้เท่าไหร่นัก แต่ก็ต้องยอมควักกระเป๋าจ่ายตังค์ แถมเวลาใช้งานจริงก็ไม่ค่อยได้ตอบโจทย์ของลูกค้าอย่างตรงประเด็น ความจริงอันนี้ได้บ่งชี้ว่าอุตสาหกรรมซอร์ฟแวร์ที่เราทำกันอยู่นั้นยังไม่มีการทำ Improving Software Quality ที่ดีเท่าที่ควร
เป็นเรื่องน่าแปลกที่การผลิตสินค้าหรือผลิตภัณฑ์สักตัว เรื่องของคุณภาพถือเป็นอีกหนึ่งปัจจัยหลักของการขายสินค้าด้วยซ้ำ แต่สำหรับการพัฒนาซอร์ฟแวร์ปัญหาเรื่องคุณภาพเรียกได้ว่าเป็นปัญหา Classic ที่ทุกองค์กรจะต้องเจออยู่ประจำ

งั้นทำไมไม่ทำให้มันดีไปเลยล่ะ

เพราะมันเป็นเรื่องยากครับ น่าแปลกที่อุตสาหกรรมด้านไอทีที่เราทำกันนั้น ดูเหมือนว่าจะเป็นอุตสาหกรรมที่ทันสมัย แต่กลับไม่มีองค์กรไหนเอาหุ่นยนต์มาช่วยเขียนโปรแกรมหรือส่งบอทไป Gathering Requirement แทนเราเลย เพราะอะไรผมคิดว่าทุกท่านก็คงรู้กันดี ดังนั้นเมื่อเป็นเช่นนี้ เราจึงต้องทำงานกันเป็นทีมครับและเมื่อดูจากการทำงานจริงตาม SDLC (Software Development Life Cycle) ที่เราใช้กันอยู่ทุกวันแล้วจะเห็นได้ว่าทุก Phrase สามารถก่อให้เกิดปัญหาด้านคุณภาพได้ทั้งนั้น ตั้งแต่ Gathering Requirement จนถึง Maintainance
ดังนั้นเพื่อเป็นการปรับความเข้าใจถึงจุดยืนของการพัฒนา Application ซักตัวผมอยากจะนำเสนอมุมมองอีกแบบเพื่อที่จะทำให้ทุกท่านเข้าใจ Software Product Quality ได้ดียิ่งขึ้นครับ





ผมมักจะเปรียบเทียบ Software Product Quality เป็นสามเหลี่ยมด้านเท่า โดยตั้งชื่อให้กับมันว่า Software Quality Triangle โดยรูปสามเหลี่ยมนี้จะมีคุณสมบัติว่า

• เป็นสามเหลี่ยมด้านเท่าที่มีด้านและมุมเท่ากัน
• มุมที่แรกคือ User Requirement หรือ มุมมองของผู้ใช้ Software
• มุมที่สองคือ Requirement Specification หรือ มุมมองของ System Analyst / Business Analyst
• มุมสุดท้ายคือ Software หรือมุมมองของ Software Developer
• ด้านแต่ละด้านคือเส้นตรงที่เชื่อมระหว่างมุมสองมุมชื่อว่า Gap ซึ่งก็คือปัจจัยที่จะทำให้มุมทั้งสามมุมห่างออกจากกัน
  

แนวคิดหลักของการใช้ Software Quality Triangle นี้คือ

"ทำอย่างไรที่จะทำให้สามเหลี่ยมด้านเท่านี้มีรูปร่างเล็กที่สุด
ในอัตตราส่วนที่เท่ากัน"

ในทางทฤษฏี นั่นแปลว่าเราจะทำอย่างไรให้ Software ออกมาใกล้เคียงกับทั้ง Requirement Specification และ User Requirement มากที่สุดนั่นเอง ซึ่งในทางปฏิบัติแล้วก็เป็นที่รู้กันอยู่ว่า "ยากมาก" เนื่องจากมีปัจจัยมากมายซึ่งส่งผลต่อการลดขนาด Software Quality Triangle อย่างที่กล่าวไว้ในแนวคิดหลัก ถ้าจะด้านแต่ละด้านมาวิเคราะห์อย่างละเอียด เราจะมองเห็นปัจจัยที่ส่งผลกระทบต่อ Software Product Quality ได้ดียิ่งขึ้นครับ

User Requirements vs Requirements Specification Gap

เป็นปัจจัยพื้นฐานแต่สำคัญที่สุดในสามเส้นเกิดขึ้นจากเหตุผลที่สุด Classic ที่เราเจอกันอยู่ทุกวันนั่นก็คือ

"System Analyst / Business Analyst ไม่เข้าใจ Requirement อย่างลึกซึ้งเพียงพอ"

เช่น

• System Analyst / Business Analyst เข้าใจ Requirement ไปคนละอย่างกับ Users
• Requirement ไม่ชัดเจนเพียงพอที่จะพัฒนา Application
• ปัญหาด้านการสื่อสาร เช่น เมื่อ System Analyst เข้าไปเก็บ Requirement จาก Users ดันไปใช้ภาษาเชิง Technical มากเกินไป ทำให้สื่อสารกันไม่ค่อยจะรู้เรื่อง ตีความโจทย์ไม่ออก

ดังนั้นวิธีที่จะลด User Requirements vs Requirements Specification Gap นั้นควรจะเลือกใช้วิธีสื่อสารที่เหมาะสมและชัดเจนเพื่อความเข้าใจที่ตรงกันของทั้งสองฝ่าย รวมไปถึงจากหมั่น Update Requirements Specification ให้เป็น Version ใหม่อยู่เสมอเพื่อป้องกันการเข้าใจผิด

Requirements Specification vs Software Gap

เกิดจากเหตุผลเดียวคือ

"Software Developer ไม่ Coding ตาม Requirement Specification
หรือ Technical Specification ที่ System Analyst ออกแบบมา"

ซึ่งเกิดจากหลายปัจจัย (ถ้าไม่รวม Bugs หรือ Defects) ดังนี้

• Technical Specification ไม่ชัดเจน
• มีการ Change Request หรือ เปลี่ยนแปลง Requirement แต่ไม่ได้แก้ไข Technical Specification ตาม ทำให้เอกสารไม่ใช่ตัวที่ใหม่ล่าสุด
• Software Developer เพิ่มหรือแก้ไข Feature ส่วนตัวเข้าไปเอง
• Software Developer ละเลย Requirement บางข้อไป เนื่องจาก หา Solution ไม่ได้

ดังนั้นการควบคุมและตรวจสอบทีมอย่างเข้มงวดถือเป็นอีกหนึ่งวิธีแก้ปัญหาที่จะสามารถลด Requirements Specification vs Software Gap ได้อย่างมีประสิทธิภาพ

Software vs User Requirements Gap

เส้นนี้ถ้าให้อธิบายแล้ว Software vs User Requirements Gap คือเส้นที่แปรผันตามสองเส้นแรก

• ยิ่ง User Requirements vs Requirements Specification Gap และ Requirements Specification vs Software Gap สั้นเท่าไหร่ Software ที่ถูกพัฒนาออกมาก็จะใกล้เคียงกับความต้องการและความคาดหวังของ Users มากเท่านั้น
• ยิ่ง User Requirements vs Requirements Specification Gap และ Requirements Specification vs Software Gap ยาวเท่าไหร่ ทีม Development งานเข้าอย่างแน่นอนเนื่องจากจะต้องทำการแก้ไข Software นั้นจนกว่า Users จะพอใจและยอมรับ ซึ่งจะก่อให้เกิดผลเสียต่อองค์กรในอีกหลายด้าน
  

Software Quality Triangle ในความเป็นจริง

แต่ในความเป็นจริงแล้ว Software Quality Triangle ที่เราทำกันอยู่ปัจจุบันไม่ได้เป็นรูปสามเหลี่ยมด้านเท่าอย่างที่วาดฝันไว้ หลายองค์กรไม่ได้ใส่ใจกับ Software Product Quality เท่าที่ควร ซึ่งนั่นส่งผลให้ Software Quality Triangle เปลี่ยนแปลงรูปร่างไปเป็น 4 รูปแบบหลักดังนี้

รูปแบบที่ 1

• System Analyst เก็บ Requirement ไม่ดีพอ
• Software Developer พัฒนาซอร์ฟแวร์ตาม Requirements Specification
  

รูปแบบที่ 2

• System Analyst เก็บ Requirement ไม่ดีพอ
• Software Developer พัฒนาซอร์ฟแวร์ไม่ตรงตาม Requirements Specification แต่ดันไปถูกใจ User Requirement

รูปแบบที่ 3

• System Analyst มีความเข้าใจ User Requirement อย่างลึกซึ้ง
• Software Developer โดนสลายการชุมนุมแน่นอน

รูปแบบที่ 4

• มั่วทุกอย่าง