ก่อนอื่นขอแจ้งก่อนว่า บทความต่างๆ ที่เกี่ยวกับการบริหารความต้องการใน blog ของผม เป็นการนำเสนอในแนวทาง Requirement Engineering ที่มุ่งเน้นการบริหารความต้องการเพื่อสนับสนุนการพัฒนาซอฟต์แวร์เป็นหลัก หนักไปทางด้านเทคนิคพอสมควรและเสริมด้าน soft skill ที่จำเป็น โดยที่ผมไม่เน้นทางด้านการบริหารจัดการนัก สืบเนื่องจากความไม่ชอบเป็นการส่วนตัว 🙂 เนื่องจากเห็นหลายองค์กรทั้งน้อยใหญ่ ทั้งภาครัฐและเอกชน ที่ไปเรียนหรือศึกษาด้านการบริหารจัดการความต้องการ และ มุ่งเน้นไปที่การ ‘บริหารจัดการ’ ความต้องการ มากกว่าเน้นไปที่การทำอะไรที่มัน ‘ได้เนื้อได้หนัง’ และเกิดประโยชน์โดยตรงต่อการพัฒนาซอฟต์แวร์ หลายองค์กรให้น้ำหนักไปที่การเก็บความต้องการมาก และมัวแต่ทำเอกสารที่มีแต่น้ำมากกว่าเนื้อ คิดเอง เออเอง เขียนเอง เข้าใจเอง แต่ทีมงานไม่เข้าใจ เป็นเอกสาร requirement specification ที่ ‘useless’ มากๆ
ดังนั้นผมจึงขอนำเสนอในแนวทางตามที่แจ้ง และคิดว่าหากคุณได้อ่านบทความต่างๆ ที่เกี่ยวกับการบริหารความต้องการใน blog ของผมจนครบ ผมเชื่อว่าแค่นี้ก็เพียงพอสุดๆ แล้ว สำหรับการนำไปใช้ในโครงการพัฒนาซอฟต์แวร์จริงๆ เรียกได้ว่า ทำตามได้แค่นี้ก็สุดยอดมากแล้ว แล้วขอเถอะ อย่าบ้าทำเอกสารมากนักเลย หันมาเน้นการสื่อสารภายในทีมและระหว่างทีมดีกว่า ได้ประโยชน์โดยตรงกว่า ^_^
วัตถุประสงค์การบริหารความต้องการ คือ
- รวบรวมปัญหาและความต้องการ – เพื่อรวบรวมและค้นหาปัญหาและความต้องการ จาก stakeholder (ผู้มีส่วนเกี่ยวข้อง) ทุกคนหรือทุกกลุ่ม
- วิเคราะห์ปัญหาและความต้องการ – เพื่อทำความเข้าใจกับปัญหาและความต้องการของ stakeholder
- กำหนดระบบที่จะพัฒนาหรือปรับปรุง – เพื่อกำหนดระบบว่าจะมีระบบอะไรบ้าง ที่จะพัฒนาหรือปรับปรุง ภายหลังจากเข้าใจความต้องการของ stakeholder แล้ว
- จัดการกับขอบเขตของงาน – เพื่อกำหนดและจัดการกับขอบเขตของงานหรือโครงการที่จะดำเนินการต่อไป
- ปรับปรุงข้อกำหนดของระบบ – เพื่อปรับปรุงข้อกำหนด (specification) ซึ่งรวมถึงประเด็นอื่นๆ อาทิ วัตถุประสงค์โครงการ เป้าหมายโครงการ งบประมาณ ระยะเวลา ข้อกำหนดทางเทคนิค ฯลฯ เพราะระหว่างการดำเนินโครงการอาจมีความต้องการเปลี่ยนแปลง จนกระทบต่อข้อกำหนดโครงการที่อาจต้องปรับเปลี่ยนตามให้สอดคล้อง
- สร้างระบบที่ถูกต้องตรงตามความต้องการ – เพื่อให้สามารถสร้างและติดตั้งระบบที่มีความสามารถครอบคลุมความต้องการของ stakeholder และโดยเฉพาะผู้ใช้งาน
ผู้รับผิดชอบด้าน requirement ต้องทำให้ทุกฝ่ายไม่ว่าฝ่ายลูกค้า หรือ ทีมพัฒนาระบบ ได้เข้าใจทุกมิติของระบบที่จะพัฒนา เพราะให้ท้ายที่สุดสามารถพัฒนาระบบได้ครอบคลุมความต้องการ
สิ่งใดๆ ล้วนมีหลายมิติหลายด้านเสมอ สำหรับซอฟต์แวร์หรือระบบไอทีก็เช่นกัน ส่วนจะมีกี่ด้านขึ้นกับ requirement ของโครงการที่ก่อให้เกิดการพัฒนาหรือจัดหาซอฟต์แวร์นั้นๆ ซึ่งเป็นปัจจัยขับเคลื่อนที่ส่งผลต่อความสามารถและคุณภาพด้านต่างๆ ของซอฟต์แวร์ จึงเป็นเรื่องยากที่ใครสักคนจะมองเห็นและเข้าใจในซอฟต์แวร์นั้นๆ ไปทุกด้าน analyst จึงควรเข้าใจในจุดแข็งและจุดอ่อนของตนเป็นอย่างดี ว่าชำนาญอะไร ไม่ชำนาญอะไร เพราะธรรมชาติของคนเรา สิ่งใดที่ชำนาญก็จะจับประเด็นนั้นได้เร็ว หากเป็นสิ่งที่ไม่ชำนาญก็จะจับประเด็นไม่ได้หรือไม่ครอบคลุม ดังนั้น หากไม่ชำนาญด้านใดควรหา domain expert (หรือ subject matter expert) ซึ่งเป็นผู้เชี่ยวชาญในด้านนั้นมาช่วยเรา ซึ่งอาจเป็นเพื่อน เป็นคนในทีม เป็นคนในองค์กร เป็นที่ปรึกษาภายนอก เป็นต้น
มิติของซอฟต์แวร์
ซอฟต์แวร์จริงๆ ไม่ได้มีแค่ 6 ด้าน เหมือนรูปกล่องสี่เหลี่ยมลูกบาศก์ด้านบน แต่อาจเป็นทรงกลมที่มีผิวสัมผัสมากมาย มีทั้งด้านที่เห็นได้ง่าย เห็นได้ยาก และ ด้านที่ไม่เห็น
สมัยนี้อาจแบ่งซอฟต์แวร์หรือระบบไอทีออกเป็น 3 ด้านใหญ่ๆ คือ
- ความสามารถ หรือ ฟังก์ชั่น
- กลไกการทำงานภายใน หรือ (กลไกทางสถาปัตยกรรม: architectural mechanism)
- คุณภาพ
ด้วยพื้นฐานของนักไอทีและนักพัฒนาซอฟต์แวร์ รวมถึงคนส่วนใหญ่มักคุ้นเคยกับแนวทาง ‘Function-Driven’ ที่มักคิดอะไรเป็นฟังก์ชั่น มองซอฟต์แวร์เป็นสิ่งที่ประกอบด้วยฟังก์ชั่นต่างๆ ที่ตอบสนองความต้องการผู้ใช้ แต่ไหนแต่ไรมาเวลาเก็บความต้องการจึงนิยมเก็บแต่ ‘functional requirement’ ลูกค้าหรือผู้ใช้ก็สนใจแต่ฟังก์ชั่น (นอกเหนือจากหน้าจอ) analyst และ ทีมพัฒนาก็สนใจแต่ฟังก์ชั่น เพราะเป็นมิติที่คนส่วนใหญ่คุ้นเคย และ ‘เข้าถึง’ ได้ง่าย โดยเฉพาะระบบที่มีไคลเอ็นต์เป็น ‘คน’ เพราะคนก็จะติดต่อกับระบบผ่านหน้าจอ (user interface) เป็นหลัก แต่จริงๆ แล้วในสมัยนี้ควรคำนึงถึงมิติอื่นๆ ด้วย โดยเฉพาะมิติด้านคุณภาพของระบบ และ ด้านกลไกการทำงานภายใน
Function-Mechanism-Quality Attribute
การบริหารความต้องการจึงต้องช่วยให้ทีมงานสามารถพัฒนาทั้ง 3 ด้านของซอฟต์แวร์ให้ออกมาดีที่สุดและครอบคลุมความต้องการ หาก analyst เก็บแต่ functional requirement ก็อาจทำให้:
- architect ไม่สามารถออกแบบส่วนกลไกการทำงานได้ดี
- tester ไม่สามารถสร้าง non-functional test case และทำ non-functional test ได้ดี
- programmer ไม่สามารถเขียนโปรแกรมจัดการส่วนคุณภาพได้ดี
- user ไม่สามารถรับรู้เรื่องคุณภาพระบบ จนกว่าจะได้ใช้งาน (แล้วอาจค่อยมารู้ว่าระบบมีคุณภาพแย่)
- software quality assurance ไม่สามารถเข้ามาประเมินด้านคุณภาพระบบได้ระเอียดลึกซึ้งดีพอ
- project manager ไม่สามารถบริการผลกระทบและความเสี่ยงได้ดี เวลามี change request แล้วกระทบส่วนสำคัญ เช่น กลไกภายในและคุณภาพที่จัดการยาก
- ฯลฯ
ดังนั้นจึงเห็นได้ว่างาน requirement เป็นงานต้นน้ำของกิจกรรมต่างๆ ในกระบวนการพัฒนาซอฟต์แวร์ หากงาน requirement ทำไม่ดี จะส่งผลกระทบต่อกิจกรรมอื่นๆ มากมายตามมา
ปัจจุบันในบ้านเรามีโครงการไอทีจำนวนมาที่ดำเนินการแล้วมีปัญหา ไม่ว่าจะเรื่องการออกแบบ การทดสอบ การบริหารโครงการ การเขียนโปรแกรม ล้วนแล้วแต่เกิดมาจากงาน requirement ทั้งนั้น ในบ้านเราบริหารจัดการความต้องการไม่ค่อยมีประสิทธิภาพนัก ทำกันแบบลวกๆ สุกเอาเผากิน ผลิตแต่เอกสารที่ไม่ค่อยมีประโยชน์แท้จริงต่อทีมพัฒนาและลูกค้า
นอกจากนี้งานบริหารความต้องการไม่ใช่ทำแค่ช่วงเริ่มต้นโครงการเท่านั้น แต่ต้องทำไปตลอดโครงการ บางโครงการจบแล้วยังต้องบริหารความต้องการต่อ เช่น ไปสำรวจวัดความพึงพอใจจากการใช้งานระบบของผู้ใช้ ไปเก็บรวบรวมพฤติกรรมการทำงานของระบบและพฤติกรรมการใช้ทรัพยากรของระบบ เพื่อส่งต่อให้ทีมไปวิเคราะห์เพื่อประเมินการทำ tuning หรือ fix bug
งานบริหารจัดการความต้องการจึงถือเป็นงานที่สำคัญมากๆ ที่จะต้องประคองโครงการตั้งแต่เริ่มต้นยันจบให้ได้ภายใต้ขอบเขตโครงการที่กำหนดไว้
สรุป
การบริหารความต้องการช่วยให้ ผู้ใช้ได้ในสิ่งที่อยากได้ และทีมพัฒนาได้ทำในสิ่งที่ผู้ใช้อยากได้… เท่านั้นเอง
minimalLIFE 