การเก็บ วิเคราะห์ และ บริหารความต้องการ

การเก็บรวบรวมความต้องการ (Requirement Gathering & Discovering) คือ การเก็บรวบรวมความต้องการ รวมถึงรวบรวมปัญหา มีหลายวิธีการ อาทิ สัมภาษณ์ ทำแบบสำรวจหรือแบบสอบถาม

เทคนิคการเก็บรวบรวมความต้องการ คือ เริ่มต้นจากกำหนดกรอบเวลาให้ชัดเจน เช่น 2 ชั่วโมง แล้วก็เน้นเก็บความต้องการให้มากที่สุดเท่าที่จะมากได้ อธิบายแต่ละความต้องการสั้นๆ สัก 1-3 บรรทัดพอ ไม่เน้นทำความเข้าใจความต้องการ แต่เน้นปริมาณ อันไหนไม่เข้าใจช่างมันจดบันทึกไว้ก่อน สิ่งที่บันทึกควรเป็นประเด็นหลัก ซึ่งตรงนี้ล่ะที่ใช้วัดความสามารถคนเก็บ requirement เลย ว่าจับประเด็นเก่งไหม เช่น หากเป็น functional requirement (หรือ use case หรือ user story) ก็ควรระบุ who, what, why เป็นอย่างน้อย who คือ บทบาทของไคลเอ็นต์ what คือ สิ่งที่ไคลเอ็นต์จะทำกับระบบ ในอีกทางหนึ่งคือไคลเอ็นต์คาดหวังจะให้ระบบทำอะไรให้ ส่วน why เป็นการอธิบายว่าทำไมไคลเอ็นต์อยากให้ระบบทำสิ่งนี้หรือทำไมอยากใช้ระบบ เพื่ออะไร ทำไม ได้ประโยชน์อะไร คาดหวังอะไร เป็นต้น

การวิเคราะห์ความต้องการ (Requirement Analysis) คือ การวิเคราะห์เพื่อทำความเข้าใจความต้องการ แล้วอธิบายความเข้าใจออกมาด้วยการบรรยายด้วยข้อความหรือวาดรูปประกอบ หากยาวมากก็จัดหัวข้อให้อ่านเข้าใจง่าย เช่น ถ้าเป็น functional requirement ก็อาจแบ่งเป็นหัวข้อ pre-condition, post-condition, basic flow, alternative flow, business rule เป็นต้น การวิเคราะห์ความต้องการอาจทำที่บ้าน ที่โต๊ะทำงาน ทำคนเดียว หรือจะจัดเป็นเวิร์กช็อปช่วยกันวิเคราะห์ร่วมกันหลายๆ คนก็ได้ พอวิเคราะห์เสร็จก็จะได้ความต้องการที่อธิบายเป็นข้อความบรรยายและอาจมีรูปภาพประกอบ ส่งให้ user หรือ stakeholder คนอื่นๆ ช่วยกันรีวิว เมื่อทุกคนเข้าใจตรงกันแล้วก็เอาไปวิเคราะห์และออกแบบระบบได้ แต่หากเข้าใจไม่ตรงกันหรือมีข้อผิดพลาดตรงไหนก็ปรับแก้ก่อน

การบริหารความต้องการ (Requirement Management) คือ บริหารประคับประคองความต้องการตั้งแต่ต้นโครงการไปจนจบโครงการ ให้ความต้องการถูก ‘transform’ ไปสู่กระบวนการต่างๆ อาทิ วิเคราะห์และออกแบบระบบ เขียนโปรแกรม ทดสอบระบบ เป็นต้น เพราะการบริหารความต้องการถือเป็นศูนย์กลางของการบริหารที่สำคัญที่ต้องเคียงคู่ไปกับการบริหารโครงการเลยทีเดียว เพราะทุกกิจกรรมในกระบวนการพัฒนาซอฟต์แวร์ต้องอิงกับความต้องการทั้งสิ้น ผมมักแนะนำผู้เรียนหรือลูกค้าให้แยกการบริหารความต้องการออกมาเป็นหน่วยงานหรือทีมงานเฉพาะเลย บางองค์กรมีหน่วยงาน PMO (Program Management Office) ก็เอาทีมนี้ไปไว้ใน PMO เลยยิ่งดี เพราะผมชอบสนับสนุนให้แยกทีมบริหารความต้องการ, ทีม test, ทีม architect, ทีมบริหารโครงการ ออกมาจากทีมหรือหน่วยงานพัฒนาซอฟต์แวร์ เพื่อให้มีอำนาจและอิสระในการทำงาน

การบริหารความต้องการมีกิจกรรมต่างๆ มากมาย อาทิ การจัดการ traceability, การจัดการ change request, การวิเคราะห์ผลกระทบ, การร่วมทำ defect management ฯลฯ หลักๆ ผมอยากให้ฝึกบริหารการเปลี่ยนแปลงเมื่อมี change request เกิดขึ้น เพราะเป็นเรื่องปกติธรรมชาติของงานพัฒนาซอฟต์แวร์เลย ที่มักมีโน่นนี่นั่นเปลี่ยนแปลงได้ตลอดทั้งโครงการ user เองก็ชอบขอโน่นเปลี่ยนนี่เพิ่มนั่นอยู่เรื่อยๆ ซึ่งประเด็นนี้เอาไว้จะมาเล่าสู่กันต่อโดยเขียนแยกเป็นบทความต่างหากละกันครับ

 

Process

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

หากเก็บรวบรวมความต้องการได้มาเยอะ ควรนำมาจัดกลุ่ม จัดประเภท จัดลำดับความสำคัญ ส่วนการวิเคราะห์ความต้องการก็เลือกจากความต้องการที่สำคัญมากๆ ไปวิเคราะห์ก่อน

Advertisements

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s