บริษัทมีกระบวนการวิธีในการดำเนินงานและบริหารโครงการ ที่ชื่อ CMMI (Capability Maturity Model Integration) ซึ่งได้ผ่านการประเมินมาตรฐานใน Level 3 ประกอบกับ Agile Method ซึ่งเป็นมาตรฐานในการบริหารโครงการของบริษัท โดย CMMI เริ่มตั้งแต่กระบวนการนำเสนอแผนงานระบบ Project Planning จนกระทั่งถึงการบำรุงรักษาระบบภายหลังส่งมอบงาน ดังนั้นมาตรฐาน CMMI 3 จะมีขอบเขตที่กว้างกว่า Software Development Life Cycle (SDLC) โดยทั่วไป เพื่อให้ครอบคลุมตลอดระยะเวลาโครงการ
กระบวนการดำเนินงานโครงการ (Project Process) ตาม CMMI ซึ่งแบ่งการดำเนินการออกเป็นกระบวนการ ดังนี้
1. กระบวนการนำเสนอระบบ (Contract)
2. กระบวนการวางแผน (Planning Process)
2.1 กระบวนการนำเสนอระบบ (Contract)
2.2 กระบวนการวางแผน (Planning Process)
3. กระบวนการกำหนดความต้องการ (Requirement Definition)
3.1 ขั้นตอนการกำหนดข้อมูลความต้องการของระบบ (System Requirement Specification : SRS)
3.2 ขั้นตอนการกำหนดข้อมูลการออกแบบระบบ (System Design Specification : SDS)
4. กระบวนการพัฒนาระบบ (Development Process)
4.1 ขั้นตอนการพัฒนาทางด้านฟังก์ชั่น (Source code และ Application)
4.2 ขั้นตอนการทดสอบฟังก์ชั่น (Functional test)
4.3 ขั้นตอนการทดสอบการเชื่อมโยงในแต่ละส่วนของระบบหลังประกอบกัน (Integration test)
5. กระบวนการทดสอบและนำระบบไปใช้งาน (Operational Test and Transition)
5.1 ขั้นตอนการวางแผนทำ User Acceptance Test (UAT test plan)
5.2 ขั้นตอนในการทำกรณีทดสอบระบบ ต้องทำการประเมินและสรุปผลการทดสอบ (UAT test case & result)
5.3 ขั้นตอนการอบรมผู้ที่กี่ยวข้องกับระบบ (Training)
5.4 คู่มือการใช้งานระบบ (User Manual)
5.5 คู่มือการตั้งค่าสำหรับระบบ (Administration & Configuration Manual)
6. กระบวนการบำรุงรักษาระบบ (Operation Maintenance)
6.1 Maintenance Agreement
6.2 Maintenance Issues List
Change Requirement Management
ขบวนการพัฒนา Application สิ่งที่ไม่สามารถหลีกได้คือ Change Requirement ซึ่งสาเหตุ และ สิ่งที่เป็นผลกระทบ จะมีผลต่อโครงการเป็นอย่างมาก ดังนั้น ขบวนการบริหารจัดการเรื่องนี้ต้องมีการตกลงกันให้ชัดเจน
ก่อนอื่นมาดูที่สาเหตุของการเกิด Change Requirement กันก่อน
- คนให้ข้อมูลไม่เชี่ยวชาญในเรื่องที่กำลังจะทำ
- เป็นระบบที่ Design ใหม่โดยที่ยังไม่เคยมีใครทำมาก่อน
- ส่วนของ Supplier ไม่เข้าใจ Business ของลูกค้า
ผลกระทบของ Change Requirement
- กรณีที่ CR ในช่วงก่อน Get Requirement
- ผลกระทบน้อยเนื่องจากยังไม่ได้เริ่มพัฒนาระบบจริง
- ถือว่าเป็นส่วนหนึ่งใน Requirement ได้
- กรณีที่ CR ในช่วง Design
- มีผลกระทบเนื่องจากปกติจะเข้าสู่ขั้นตอนพัฒนาไปแล้วบางส่วน เช่น Front , Design Layout
- ขึ้นกับประเภทของ CR ด้วยเช่น การเพิ่ม รายละเอียด Field , Validate Condition จะกระทบไม่มาก
- การทำ CR เช่น เพิ่ม Feature ต้อง Check กับ Requirement Spec ก่อน เพราะอาจจะเป็นเรื่อง out off scope
- กรณีที่ CR ช่วง Development
- มีผลกระทบกับ Time Line ของโครงการ เพราะต้องเข้าสู่ขั้นตอน Design ใหม่อีกรอบ
- ต้องดูว่าหัวข้อ CR นั้นมีความขัดแย้งกับสิ่งที่เคยแจ้งหรือไม่ หรืออาจจะขอให้เปลี่ยนขั้นตอนการทำงานไปเลย จะมีผลกระทบมาก
- กรณีที่ CR ช่วง UAT
- จะมีโอกาสเกิด CR มากเนื่องจาก User ผู้ใช้งานมาเกี่ยวข้องด้วย ซึ่งเป็นคนละทีมกับผู้ให้ Requirement และ User จำนวนมากไม่เคยเห็นระบบมาก่อน
- มีผลกระทบแน่นอนกับ Time Line และ Budget
การบริหารจัดการ Change Requirement
- ผู้พัฒนาต้องทำใจยอมรับว่า CR เป็นเรื่องธรรมชาติก่อน และใจเย็นๆ
- Project Manager ของ User ต้องวางแผนเรื่อง Budget ไว้ล่วงหน้า
- การเปิดโอกาสให้ End User มาเห็น Design และมีส่วนร่วมในการออกแบบในตอนต้นๆ ของโครงการ
- การเปิดเวที Kick Off และแจ้ง ขอบเขตงานในเบื้องต้นกับทีม UAT