Loading ...Requirements
สัปดาห์ที่แล้วผมมีโอกาสได้แสดงความคิดเห็นต่อคำถามของคุณ siam2advance เกี่ยวกับกระบวนการหลังจากได้รับ requirement จากลูกค้ามาแล้ว ซึ่งผมอยากจะขยายความต่อในบทความนี้ครับ
ผมเชื่อว่าพวกเราทุกคนในวงการ software development คงจะเคยเจอปัญหาที่เกี่ยวข้องกับ requirement อยู่บ่อยๆโดยเฉพาะอย่างยิ่งปัญหาที่เกิดจาก requirement ที่ได้มาไม่มีความสมบูรณ์หรือละเอียดเพียงพอที่จะทำงานต่อ ทั้งในส่วนของ software development ซึ่งต้องทำการออกแบบระบบสำหรับแต่ละ requirement และในส่วนของ project management ซึ่งต้องทำ estimation and planning
ความไม่สมบูรณ์ของ requirement ที่ผมพบบ่อยๆก็เช่น
Completeness: requirement ไม่สมบูรณ์ในตัวเอง อธิบายเรื่องราวหรือความต้องการได้ไม่ครบถ้วนครับ เช่น “เพื่อเพิ่มความสามารถของระบบในการสนับสนุนการตัดสินใจของผู้บริหาร รายงานประจำปีรูปแบบใหม่จึงควรถูกสร้างขึ้น” สำหรับผม ถ้าได้ requirement มาแค่นี้จริงๆคงเศร้าหละครับเพราะว่าจะทำอะไรต่อก็ลำบากไปหมด ที่มึนมากๆก็คือ “รูปแบบใหม่” นี้มันแบบไหนหละ?
Ambiguity: ข้อมูลที่ระบุใน requirement มีความกำกวมไม่ชัดเจน เช่น “การสร้้้้างรายงานประจำปีต้องดึงข้อมูลจากตารางที่เกี่ยวข้องในฐานข้อมูล” คำว่า “ที่เกี่ยวข้อง” นั้นไม่ชัดเจนเพียงพอที่จะลงมือ design ระบบได้ทันทีหรอกครับ ยิ่งสำหรับคนที่ไม่มีประสบการณ์ในงานด้วยแล้ว ยิ่งยากใหญ่
Validity: requirement ไม่ได้ผ่านการตรวจสอบและอนุมัติจากผู้ที่เกี่ยวข้อง(ที่มีอำนาจ)ทุกคน ซึ่งจะทำให้เิกิดปัญหาขัดแย้งกันได้ในภายหลัง เช่น “การสร้างรายงานประจำปี…” เป็นความคิดริเริ่มของ Product Manager ที่คิดว่าจะเป็นการเพิ่มค่าให้กับระบบ แต่ System Architect คิดว่าการเพิ่ม feature นี้เข้าไปจะมีผลกระทบต่อ performance โดยรวมของระบบ ถ้าตอนแรกเค้าไม่คุยกันก่อนจะส่งงานมาให้ development team หละก็วุ่นแน่ๆครับ จากประสบการณ์ของผมเค้าไม่ค่อยคุยกันจริงๆซะด้วย สมมติเราเชื่อ Product Manager เริ่มลงมือทำไปได้ซักพัก ก่อนที่ System Architect จะมาบอกว่าห้ามทำทีหลัง … แล้วเราจะเอายังไงหละทีนี้
ปัญหาเพียบ…
Operational Concept
ผมเจอปัญหานี้มาพอสมควรก็เลยลองหาทางแก้ดู อ่านบทความเรื่อยๆก็มาสะดุดกับคำว่า Operational Concept ครับ อ่านรายละเอียดแล้วยิ่งสนใจ ความหมายของมันก็คือ “ตัวแทนของระบบหรือ requirement ในมุมมองที่ว่าลูกค้าจะได้อะไรและใช้งานอย่างไร (Customer View) และความสัมพันธ์กับระบบและกระบวนการทำงานเิดิม (Development View)”
ผมมองว่าแนวคิดนี้น่าจะช่วยแก้ปัญหาที่ผมเจออยู่ได้ครับ เพราะ Operational Concept ก็คือแนวคิดที่ช่วยเพิ่มคุณภาพให้กับการทำ Requirement Gathering และ Requirement Analyst โดยแบ่งระดับมุมมองออกเป็นสองระดับ
High Level: การทำ Operational Concept ระดับสูงจะเน้นไปที่มุมมองของคนที่ร้องขอ requirement นั้นๆเป็นหลัก รายละเอียดก็มีดังนี้ครับ
Who — ระบุว่าใครเป็นคนที่ร้องขอ requirement นี้ อาจจะเป็นลูกค้าโดยตรง Product Manager, System Architect หรือคนอื่นๆที่มีส่วนเกี่ยวข้อง ผมมองเห็นความสำคัญของ Who ตรงที่ว่าข้อมูลส่วนนี้น่าจะช่วยลดปัญหา Requirement Validity ได้ อีกทั้งยังอาจจะช่วยในส่วนของ Requirement Prioritization ได้ด้วยนะครับ ง่ายๆก็คือถ้า requirement มาจากลูกค้าโดยตรงก็ควรจะได้รับความสำัคัญมากกว่า requirement ที่มาจาก development team เองนะ
Why — ระบุข้อมูลเพิ่มเติมว่าทำไม requirement นี้ถึงจำเป็น มุมมองก็จะออกมาในรูปของ business objective ครับ ประโยชน์ก็คือ development team จะเข้าใจความสัมพันธ์ของ requirement นี้กับประโยชน์ทางธุรกิจมากขึ้น ซึ่งจะเิปิดโอกาสให้ development team นำเสนอแนวคิดเพื่อต่อยอด business objective นั้นๆได้ครับ
How — ระบุข้อมูลเพิ่มเติมว่า requirement นั้นๆจะถูกนำไปใช้อย่างไร มีกระบวนการทำงาน (workflow) เป็นอย่างไร ง่ายๆก็คือการระบุ Use Case ให้กับ requirement นั่นแหละครับ
Low Level: ส่วนนี้จะเป็นมุมมองของ development team ล้วนๆเลยครับ หลักการสำคัญคือเราต้องมอง requirement แต่ละตัวให้รอบด้าน ทั้งในด้าน programing, testing, installation, และ training and support ดังนั้นความคิดเห็นของทุกส่วนใน development team จึงจำเป็นอย่างมาก รายละเอียดก็มีดังนี้ครับ
Development — เป็นการทำ Requirement Analysis โดย developer เพื่อ developer จุดสำัคัญที่ต้องพิจารณาก็จะมี Interface, Error Handling, Interoperability, Performance, Security และ Compatibility เมื่อได้ข้อมูลเพิ่มเติมตรงนี้แล้ว System Analyst หรือบางทีเป็น Developer เองก็จะเริ่มการ Design และสร้าง Prototype อะไรต่อไปครับ
Quality Assurance — requirement แต่ละตัวจะเสร็จสมบูรณ์ได้ไม่ใช่แค่ programming เสร็จแต่ต้องผ่านกระบวนการ quality assurance ด้วย ดังนั้นในมุมมองของ Tester ต่อ requirement จึงเป็นสิ่งสำคัญครับ แล้วอะไรหละที่ Tester ควรจะพิจารณาเมื่อต้องทำ Requirement Analysis คำตอบคือ Installation and Configuration, Functionality, Resiliency, Interoperability, Usability, Data, Performance, Security และ Compatibility ครับ หลังจากการวิเคราะ์ห์ตามมุมมองเหล่านี้แล้ว Tester ก็จะเริ่มงานการเขียน Test Specification ต่อไปครับ
Training and Support — ในมุมมองของ Product Training, and Support team บาง requirement มีความพิเศษในตัวซึ่งต้องการ User Training กับ User Support ที่ต่างออกไปจากปกติ ดังนั้น Requirement Analysis ก็ควรจะได้รับความคิดเห็นจากทีมที่ดูแลรับผิดชอบกระบวนการตรงนี้ด้วยครับ
Operational Concept นั้นสามารถประยุกต์ใช้ได้กับทั้ง Requirement Gathering (ใช้ High Level View) และ Requirement Analysis (Low Level View) ครับ ตรงนี้จะช่วยปรับปรุงประสิทธิภาพของ Requirement Management โดยรวมได้มากแถมยังช่วยแก้ปัญหาเรื่องความไม่สมบูรณ์ของ requirement ได้ด้วยครับ
เพื่อความสะดวกของเพื่อนๆ ผมทำ Operational Concept Template มาให้ลองใช้กันครับ Operational-Concept-Template (367)
Operational Concept vs. Agile
ผมได้ลองใช้แนวคิดที่ผมนำเสนอมาในบทความนี้กับ project ที่ใช้ Development Life CycleIteration ซึ่งมีการทำ Requirement Analysis อย่างเข้มข้นในตอนต้นของแต่ละ Iteration ผลลัพธ์ที่ได้ถือว่าดีมากครับ
แต่ถ้าเป็น Agile Development หละ ผมไม่แน่ใจว่า Operational Concept จะใช้ได้แบบ 100% รึเปล่านะครับ ผมเองเพิ่งเริ่มศึกษา Agile Development ยังไงก็ขอคำแนะนำจากเพื่อนๆที่มีประสบการณ์กับ Agile ด้วยนะครับว่า Operational Concept จะไปกันได้กับ Agile มั้ย
ขอบคุณครับผม 
Related posts:
ติดตามบทความดี ๆ จากเว็บนี้มาสักพักแล้วครับ ขอบคุณครับ สำหรับข้อมูลดี ๆ ที่นำเสนอ จะคอยติดตามต่อไปครับ
ขอบคุณครับ
[...] ปัญหาตรงนี้ประกอบด้วยหนึ่งความต้องการไม่สมบูรณ์ (Incomplete Requirement) และสองมีการเปลี่ยนแปลงความต้องการอยู่เรื่อยๆ (Requirement Change) ผมมองว่าข้อแรกน่าจะแก้ไขได้ด้วยการปรับปรุงกระบวนการการเก็บข้อมูลจาก ลูกค้าให้มีประสิทธิภาพมากขึ้น หลักการที่น่าจะช่วยได้ก็คือ Operational Concept ที่จะช่วยให้เรามองขอบเขตของ Requirement ได้อย่างครอบคลุมมากยึ่งขึ้น เช่น ใครอยากได้ เอาไปทำอะไร ทำไมต้องมี Requirement แบบนี้ (ทำแบบอื่นได้มั้ย) ลองอ่านเพิ่มเติมจากบทความนี้ดูครับ [...]
[...] (valid) ระหว่างการพูดคุยลองประยุกต์ใช้ operational concept [...]
[...] ลองหาข้อมูลเพิ่มเติมดูครับ อ้อ…ผมมี?Operational-Concept-Template (284) [...]
ขอบคุณคร้าาา