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

Share
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

The Five Ideals

The Five Ideals

จากหนังสือ The Unicorn Project ในนั้นจะมีที่ปรึกษาเก่ง ๆ คนหนึ่งชื่อ Erik เป็นเหมือนเซ็นเซหาตัวยาก เดี๋ยวก็มา เดี๋ยวก็ไป ถ้าโชคดีก็จะเจอเค้าว่าง แล้วเค้าก็จะสอนอะไรที่สำคัญ ๆ แต่ฟังดูล้ำ ๆ และลึกซึ้ง

By Chokchai Phatharamalai
Communication, Reliability and Modern concepts - System Design, Simply Explained

Communication, Reliability and Modern concepts - System Design, Simply Explained

บทความนี้จะอธิบายพื้นฐานของ System Design โดยต่อยอดจากตัวอย่าง Gym Application เพื่อให้เห็นภาพว่า เมื่อระบบเริ่มเติบโตและถูกแยกออกเป็นหลาย Service แต่ละ Service จะสื่อสารและทำงานร่วมกันอย่างไร งานแบบไหนควรสื่อสารแบบ Synchronous งานแบบไหนควรประมวลผลแบบ Asynchronous รวมถึงอธิบาย Concept พื้นฐานต่าง ๆ ที่ควรรู้ เช่น API

By Boonsong Srithong
Race condition

Race condition

ผมกำลังอ่านหนังสือ The Unicorn Project ซึ่งเป็นนิยายเกี่ยวกับ developer สาวคนหนึ่งที่ใช้ชีวิตในองค์กรท่ามกลางกระแส digital disruption อ่านแล้วสนุกมาก เป็นเรื่องที่ตื่นเต้น และหลาย ๆ dynamic ที่เกิดขึ้นก็คล้ายกับที่ผมพบเจอในบริษัทซอฟต์แวร์ เลยทำให้

By Chokchai Phatharamalai
Distributed Systems Concepts - System Design, Simply Explained

Distributed Systems Concepts - System Design, Simply Explained

ในช่วงแรก Product เราสามารถออกแบบระบบให้อยู่ใน Server และ Database เดียวกันได้ แต่เมื่อระบบโตขึ้น มีผู้ใช้งานเพิ่มขึ้น ข้อมูลเยอะขึ้น ระบบเริ่มทำงานช้าลดเรื่อยๆ สิ่งที่หนีไม่ได้คือการ Decomposition Service ไปเป็น Distributed System เช่น Member Service, Booking Service, Payment

By Boonsong Srithong