Change Management ต้องทำไหมนะ แล้วทำตอนไหน

Change Management ต้องทำไหมนะ แล้วทำตอนไหน

เนื่องจากช่วงนี้ได้ทำงานกับลูกค้าที่มีการเปลี่ยนแปลงทาง scope ของงานเยอะมาก อารมณ์แบบตอน baseline เป็นแบบนึง พอจะเลือกงานมาทำจริงๆ เรียกว่าเปลี่ยนไปตาม strategy ขององค์กรเลยก็ว่าได้ ในฐานะที่เราเป็นกลุ่มนักพัฒนา ที่ยังจำเป็นต้องควบคุมงบประมาณ กำหนด scope และต้องตอบให้ได้ว่า งานที่ทำไป เป็นไปตาม priority และใช้งบประมาณได้อย่างคุ้มค่าหรือไม่ สิ่งเหล่านี้เป็นเรื่องของการสื่อสาร expectation ทั้งหมด เพราะจริงๆ ถามว่า ทางลูกค้าเค้าเข้าใจได้หมด หากความเปลี่ยนแปลงเกิดจากตลาดที่เปลี่ยนไป เลยทำให้ scope เดิมที่คิดว่าจะทำ อาจจะต้องปรับความสำคัญ เพิ่มลดของ

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

Change Management ใน PMBOK คืออะไร

PMBOK ไม่ได้มอง Change Management เป็น process แยกต่างหาก แต่ฝังอยู่ใน Knowledge Area ที่ชื่อว่า Project Integration Management โดยเฉพาะ process ที่ชื่อ "Perform Integrated Change Control" ซึ่งถือว่าเป็นหัวใจของเรื่องนี้

แนวคิดหลักคือ — โปรเจคทุกอย่างมี Baseline (scope, schedule, budget ที่ตกลงกันตั้งต้น) และ change ใดก็ตามที่กระทบ baseline ต้องผ่านกระบวนการอนุมัติก่อนจะนำไปทำจริง ห้ามทำเงียบๆ

5 ขั้นตอนหลักที่ PMBOK กำหนด

1. Identify the Change — ใครก็ได้ในโปรเจคสามารถยื่น Change Request ได้ ไม่จำเป็นต้องเป็น PM เสมอไป อาจมาจาก Stakeholder, ทีม Dev, หรือแม้แต่ข้อกำหนดกฎหมายที่เปลี่ยน

2. Log and Document — CR ต้องถูกบันทึกใน Change Log ทุกรายการ ตั้งแต่วันที่ยื่น ผู้ยื่น คำอธิบาย ไปจนถึงสถานะ — ห้ามมี verbal change ที่ไม่มีลายลักษณ์อักษร

3. Impact Assessment*** — ก่อนตัดสินใจ ต้องประเมินผลกระทบต่อ 3 constraints หลัก (Scope / Schedule / Cost) และอาจรวม Quality กับ Risk ด้วย นี่คือขั้นตอนที่ต้องการข้อมูลมากที่สุดและกินเวลามากที่สุด

4. CCB Review & Decision — Change Control Board ทบทวน Impact Assessment แล้วตัดสินใจ: Approve / Reject / Defer พร้อมบันทึกเหตุผล ใครมีอำนาจอนุมัติขึ้นอยู่กับ severity ของ change

5. Implement and Update Baselines — ถ้า Approve แล้ว baseline ต้องถูก update อย่างเป็นทางการ (Project Management Plan, Schedule Baseline, Cost Baseline) แล้วสื่อสารไปยังทุกคนที่เกี่ยวข้อง

สิ่งที่จำเป็นมากๆ สำหรับการทำ Change Management คือ การทำ Impact Asessment ว่ามีผลกระทบโดยรวมอย่างไรกับโปรเจค เพราะความเปลี่ยนแปลงต่างๆ มันคงไม่ได้เป๊ะอยู่ในงบหรือเวลาเดิมที่เราเคยคาดการณ์ ดังนั้นจึงต้องทำให้เห็นภาพชัดเจนว่าเปลี่ยนไปอย่างไร

ใดๆ ก็ตาม PMBOK เวอร์ชันใหม่ไม่ได้มอง Change Management เป็นขั้นตอน แต่เป็นความสามารถพื้นฐานของการบริหารโครงการที่ต้องมีตลอด lifecycle ดังนั้นตอนหาว่าจะทำยังไงให้ดูเป็นทางการ ก็ต้องไปย้อน version เก่าๆ เพราะเนื้อหาเน้นๆ มันจะไปอยู่แถวนั้นมากกว่า

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

Read more

Tuple: ปรัชญาของการปูเสื่อ และศิลปะแห่งการไม่ตั้งชื่อ

Tuple: ปรัชญาของการปูเสื่อ และศิลปะแห่งการไม่ตั้งชื่อ

ในโลกของการเขียนโปรแกรม เรามักถูกสอนให้เป็น “นักจัดระเบียบ” เราสร้างคลาส สร้าง Struct ตั้งชื่อตัวแปรให้สื่อความหมาย (Clean Code) แต่บางครั้ง ความเคร่งครัดที่มากเกินไปอาจกลายเป็นพันธนาการที่ทำให้ Code ของเราอุ้ยอ้ายโดยไม่จำเป็น 1. Naming Fatigue: ภาระของการมีตัวตน ลองนึกภาพคุณได้

By Santi
The Art of Early Return: วินัยแห่งการ “คัดออก” เพื่อสมองที่โล่งกว่าเดิม 10 เท่า

The Art of Early Return: วินัยแห่งการ “คัดออก” เพื่อสมองที่โล่งกว่าเดิม 10 เท่า

ในโลกของการพัฒนาซอฟต์แวร์ เรามักจะถูกสอนให้เป็นคนรอบคอบ ให้คิดถึงความเป็นไปได้ให้ครบทุกด้าน แต่บ่อยครั้งที่ “ความรอบคอบ” นั้นกลับกลายเป็นกับดักที่สร้างความซับซ้อนจนเราเองก็รับมือไม่ไหว วันนี้ผมอยากจะหยิบยกปรัชญาหนึ่งที่ผมพบจากการเขียนโปรแกรม โดยเฉพาะในภาษาอย่าง Rust ซึ่งมันไม่

By Santi
The Logic Trap: เมื่อ “ความถูกต้อง” กลายเป็นอาวุธที่ทำลายทีมซอฟต์แวร์

The Logic Trap: เมื่อ “ความถูกต้อง” กลายเป็นอาวุธที่ทำลายทีมซอฟต์แวร์

ในโลกของการพัฒนาซอฟต์แวร์ เราถูกสอนให้เทิดทูน Logic เป็นพระเจ้า เราใช้เหตุผลในการคัดเลือก Stack, ใช้ความถูกต้องในการทำ Code Review และใช้ตัวเลขในการวาง Roadmap แต่เคยสงสัยไหมครับ? ทั้งที่เราพูดเรื่องที่ “ถูกต้อง” และเป็น “ความจริง” ทุกประการ ทำไมผลลัพธ์ในห้องประชุ

By Santi
เวลาอู้

เวลาอู้

ผมกำลังอ่านหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco ซึ่งได้ให้มุมมองใหม่เกี่ยวกับ Slack time หรือเวลาอู้งานกับผม แต่ก่อนจะเล่าว่าผมเห็นอะไร ผมของแบ่งปันมุมมองเวลาผมดูองค์กรก่อนนะ สายการผลิต คนในองค์กรมารวมตัวกันเพราะเราต้องการบรรลุเป้าหมายที

By Chokchai Phatharamalai