Chapterpiece.Meeting.4: Risk Management for IT Projects ผ่านไปได้ด้วยดีในสถานการณ์บ้านเมืองที่ไม่ค่อยปกติเท่าไร มีสมาชิกร่วมกิจกรรมทั้งหมด 8 คนครับ ขอบคุณทุกคนมากๆ โดยเฉพาะกอล์ฟ … มาจากชลบุรี แมนสุดๆ ฮ่าๆ

ก็เหมือนทุกครั้งที่เราจะมีของฝากมาให้เพื่อนๆที่ไม่ได้มาร่วมกิจกรรม สิ่งนั้นคือ CM4.Risk.Management.Result … Download ได้ที่นี่ครับ

กรณีศึกษา — ระบบเช่าหนังสือออนไลน์

ด้วยความตั้งใจว่าจะมี Workshop เพื่อให้ทุกคนได้ลองมีส่วนร่วมกับกระบวนการ Risk Management จริงๆ ผมเลยสมมติกรณีศึกษาขึ้นมาอันหนึ่งครับ “ระบบเช่าหนังสือออนไลน์ (Online Book Rental System – OBRS)” สำหรับไฟล์แรกที่ชื่อ Case_Information.docx นี้จะอธิบายให้ทุกคนเข้าใจถึงที่มาที่ไป วัตถุประสงค์ สมมติฐาน ข้อจำกัด และความต้องการทางธุรกิจกับทางเทคนิค หรือจากอ่านข้อมูลตรงนี้แล้วเพื่อนๆจะเห็นภาพว่า เอ๊ะ ลูกค้าเค้าต้องการอะไร ทำไม เมื่อไร และเราต้องทำอะไรบ้างนะ

เนื่องจากเรามีกัน 8 คน ผมเลยแบ่งสมาชิกเป็น 2 กลุ่ม กลุ่มละ 4 คนครับ ความสนุกอยู่ตรงนี้แหละ แต่ละคนจะได้รับมอบหมายตำแหน่งในโปรเจกต์ที่ไม่เหมือนกัน ได้แก่ Business Analyst, Development Team Leader, Quality Assurance Team Leader และ Project Manager ซึ่งแต่ละตำแหน่งก็จะมีเรื่องราวเบื้องหลัง ที่มาที่ไป และแนวคิดเกี่ยวกับโปรเจกต์นี้ที่ไม่เหมือนกันครับ ลองอ่านดูครับ ไฟล์ที่ชื่อ Role_xxx.docx ครับ

หลังจากอ่านกันแล้วยังไงต่อ … ก็เริ่มกระบวกการ Risk Management เลยครับ จาก Risk Identification ซึ่งต่างคนก็จะมีมุมมอง มี Risk ที่ต่างกันออกไปตามหน้าที่และเนื้อหาที่ผมกำหนดให้ จากนั้นก็เป็นตามลำดับขั้นตอน Risk Assessment เพื่อวิเคราะห์ถึงความเป็นไปได้ที่จะเกิดปัญหา (Probability) และความรุนแรงของปัญหา (Impact) และปิดท้ายด้วย Risk Response เพื่อหาแนวทางป้องกัน (Mitigation Plan) และแนวทางแก้ไขปัญหา (Contingency Plan) ครับ ลองดูรายละเอียดได้จากไฟล์?CM4_Risk_Management.pdf และบทความนี้ครับ

สุดท้ายเราก็ได้ Risk List ของ OBRS Project ออกมา ผมสรุปข้อมูลทั้งหมด (เท่าที่จำได้) จากทั้ง 2 กลุ่มมาใส่ไฟล์?OBRS_Risk_List.xlsx ไว้ พยายามเตรียม Mitigation Plan เอาไว้สำหรับ Risk ทุกตัวเพื่อป้องกันเหตุการณ์เลวร้ายที่จะเกิดขึ้น แต่สำหรับ Contingency Plan ที่บอกว่าจะทำอย่างไรต่อไปเพื่อแก้ไขหรือลดความรุนแรงของปัญหาที่เกิดขึ้นแล้วนั้น บางข้อผมหาไม่ได้จริงๆครับ (คิดไม่ออก ฮ่าๆ) … อ้อ แล้วก็สำหรับ Probability และ Impact กำหนดกันเองได้เลยนะครับว่าจะ Low, Medium หรือ High

การนำไปใช้งาน

ตอนผมเขียนกรณีศึกษานี้ ผมพยายามจะคิดถึง Risk ที่เจอกันบ่อยๆใน IT หรือ Software Development Project ซึ่งผมหวังว่าการอ่าน OBRS_Risk_List.xlsx จะช่วยให้เพื่อนๆมองเห็นถึงเจ้า Common Risks เหล่านั้น เช่น งานเยอะไป, Requirement ไม่ชัดเจน, คนไม่พอ, และลูกค้าไม่ให้ความร่วมมือ รวมถึงแนวทางป้องกันและแนวทางแก้ไข เบื้องต้นบ้างครับ

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

สุดท้ายนี้ขอให้ทุกคนปลอดภัย บ้านแห้ง (เร็วๆ) กันทุกคนครับ อวยพรตัวเองด้วย ตอนเขียนนี่น้ำก็ใกล้บ้านเข้ามาล่ะ

ห่างหายไป 3 เดือนเพื่อจัดการภารกิจส่วนตัวมากมาย ตอนนี้ว่างขึ้นแล้วฮะ ได้โอกาสก็ขอนัดเจอเพื่อนๆอีกรอบเลยละกัน ครั้งที่ 4 แล้วสำหรับ Chapterpiece Meeting … ครั้งนี้ขอนำเสนอ Risk Management for IT Projects ครับ

ในบรรดาเรื่อง Project Management ส่วนตัวแล้วผมชอบเรื่องนี้มากที่สุดครับ รู้สึกว่ามันสร้างโอกาสในการคิด สังเกต จินตนาการ คาดเดาอนาคตเพื่อมองหาความเสี่ยง และใช้ความคิดสร้างสรรค์ในการค้นหาวิธีการใหม่ๆมาจัดการกับความเสี่ยงที่มีใน Project ของเรา

 

ในครั้งนี้ก็จะเหมือนครั้งที่แล้วครับ นอกจากได้มาคุยกันเรื่องทฤษฏี Risk Management แล้ว เราจะได้ลองทำ Workshop กันด้วย … งานกลุ่มครับผม

 

ใครสนใจลงทะเบียนที่นี่ได้เลยครับ ครั้งนี้ขอผู้ร่วมกิจกรรม 12 คนฮะ ขอบคุณผู้อุปการะให้ใช้สถานที่ฟรีเช่นเคย Art Element: School of Art ห้องแอร์ บอร์ด โปรเจกเตอร์ และกาแฟอร่อยๆ เพียบพร้อม

6. Risk Management

ไปทะเลกันดีกว่า

หลังจากที่ทำงานหนักติดต่อกันมานานหลายเดือน เด็กชาย ก. (โปรแกรมเมอร์มือฉมังของบริษัทแห่งหนึ่ง) ก็บอกกับตัวเองว่า “ถึงเวลาต้องพักผ่อนบ้างแล้วหละ” หันซ้ายหันขวาก็เจอโฆษณาไทยเที่ยวไทยในทีวี เห็นแล้วก็ให้เกิดความรู้สึกอยากไปเที่ยวทะเลขึ้นมาทันที จะต้องคิดอะไรมากอีกหละ จัดทริปโลด

วางแผนเรียบร้อย ชวนเพื่อนสนิทๆซัก 4-5 คนไปด้วยกัน ที่พักก็จองแล้ว หรูหราเชียว ตั๋วเครื่องบินหละ? แพงหน่อยแต่ก็ยอมจ่ายหละ เสื้อผ้าเครื่องใช้? ก็นี่ไง กำลังเตรียมอยู่ … ครบถ้วนแล้วเนอะ

แต่ระหว่างที่เตรียมข้าวของอยู่นั้น เด็กชาย ก. ก็นึกย้อนไปถึงการท่องเที่ยวทริปล่าสุด … มันช่างเป็นความทรงจำนี่ไม่น่าจดจำเลย คิดดูซิ กะว่าจะไปเดินเขาชมนกชมไม้ ถ่ายรูป สูดอากาศสดชื่น แต่นี่มันบ้าอะไรวะเนี่ยะ

• ฝนตกมันทั้งวัน เฉอะแฉะไปหมด
• เสื้อกันฝนก็ไม่ได้เอามา
• นอนอยู่ในเต้นท์ เต้นท์รั่วอีก
• ไม่รู้นี่หว่าว่ายากันยุงมันจะหมดขวดแล้ว ใช้ได้หน่อยเดียวก็เกลี้ยง โดนยุงหามทั้งคืน ดีนะไม่เป็นไข้ป่าตาย —– 1

เฮ้อ เศร้าใจจริงๆ … ไปเที่ยวครั้งนี้จะเจออะไรแบบนี้อีกมั้ยนะ “ม่ายยยยยยย” เด็กชาย ก. ตะโกนออกมาสุดเสียงด้วยความรู้สึกที่เหมือนเพิ่งตื่นจากฝันร้าย “ไม่ ประวัติศาสตร์ต้องไม่ซ้ำรอย เราต้องเตรียมตัวให้พร้อมกว่าเดิม”

เด็กชาย ก.ก็เริ่มปรึกษากับตัวเอง “ไอ้การไปเที่ยวเกาะเนี่ยะ มันจะมีเรื่องอะไรไม่คาดคิดให้ปวดหัวได้บ้างน้า” ว่าแล้วเขาก็หยิบกระดาษ ปากกามาจดความคิดที่พรั่งพรูออกมา ยิกๆ

• เมาเรือ
• เป็นลมแดด
• ฉลามบุก … (เอ่อ ก็ไม่แน่นะ)
• แดดเผาจนตัวเกรียม
• เรือล่ม … (น่ากลัว)
• โจรสลัด … (โอ้ววว คิดไปได้)
• เรือน้ำมันหมด
• กล้องตกน้ำ
• ซึนามิ
  
• อาหารเป็นพิษ/ท้องเสีย —– 2
  

“มีสิบเรื่องเลยหรอเนี่ยะ เยอะจัง” เด็กชาย ก.บ่นกับตัวเองเบาๆ “จะให้เตรียมรับมือทุกเรื่องไม่ไหวแน่ๆ อย่างถ้าฉลามบุกมาเนี่ยะจะทำยังไงได้วะ ฮ่าๆ … เราคงต้องจัดลำดับความสำคัญของความเสี่ยงพวกนี้แล้วหละ”

เด็กชาย ก. หยิบกระดาษแผ่นเดิมมาตีเป็นตารางแล้วกรอกข้อมูลเพิ่มเติมลงไปให้กับความเสี่ยงแต่ละข้อ เริ่มจากข้อแรก “เมาเรือ” … “ก็ไม่ค่อยได้นั่งเรือเท่าไรอะนะ แต่ก็มีบ้างที่เมารถ คิดไปก็น่าจะมีโอกาสจะเมาเรือได้เหมือนกันเนอะ”

“แล้วความรุนแรงหละ … แหะๆ ก็คงอ้วกแตกหละมั้ง แต่ดื่มน้ำอุ่นแล้วไปนอนพักที่เกาะก็น่าจะดีขึ้นนะ … ความรุนแรงปานกลางละกัน” เด็กชาย ก. ใช้วิธีการนี้กับการวิเคราะห์ความเสี่ยงที่เหลือ จนผ่านไป 15 นาทีงานนี้ก็เสร็จ (เร็วดีจัง) —– 3

ความเสี่ยง (Risk)	โอกาสที่จะเกิด (Likelihood)	ความรุนแรง (Severity)	เลือก?
เมาเรือ	Medium	Medium	Yes
เป็นลมแดด	Low	High	Yes
ฉลามบุก	Very Very Low	Extremely High
แดดเผาจนตัวเกรียม	High	Low	Yes
เรือล่ม	Very Low	High
โจรสลัด	Very Very Very Low	Extremely High
เรือน้ำมันหมด	Low	Medium
กล้องตกน้ำ	High	Medium	Yes
ซึนามิ	Very Very Very Low	Extremely High
อาหารเป็นพิษ/ท้องเสีย	Medium	Medium	Yes

ต่อไปก็เป็นการเลือกว่าความเสี่ยงไหนคุ้มค่าที่จะเตรียมการป้องกันดี เด็กชาย ก. รู้ได้ด้วยสัญชาตญานว่าความเสี่ยงไหนก็ตามที่ถึงแม้จะรุนแรงมาก (มากๆ) แต่โอกาสเกิดน้อย (มากๆ) ก็ไม่คุ้มค่าที่จะไปเตรียมการรับมือเมื่อเทียบกับความเสี่ยงที่มีความรุนแรงและโอกาสเกิดปานกลาง เช่น ฉลามบุกงี๊ รู้ทั้งรู้นะว่าถ้ามันบุกจริงก็ตายชัวร์ แต่โอกาสเกิดก็น้อยมากๆใช่มั้ยหละ งั้นก็เอาเป็นแค่คอยสายตามองหากระโดงฉลามตอนเล่นน้ำแล้วกัน ถ้าเห็นก็ตัวใครตัวมันเนอะ แต่กับเรื่องลมแดดเนี่ยะ ถึงแม้จะไม่ถึงกับตายชัวร์ๆแบบ 100% แต่โอกาสเกิดมันก็มีมากกว่าฉลามบุกนะ … เตรียมการไว้ซักหน่อยดีกว่า

ระหว่างที่เด็กชาย ก. นั่งนึกไปว่าจะเตรียมการรับมือกับลมแดดอย่างไรดี เค้าก็ฉุกคิดขึ้นมาได้ว่า “ความเสี่ยงก็คือความเสี่ยงแหละนะ ต่อให้เรามีการเตรียมการดียังไง มันก็อาจจะเกิดความผิดพลาดจนทำให้เกิดเป็นปัญหากับเราได้อยู่ดี”

“ไม่ได้การล่ะ แค่เตรียมตัวป้องกันอย่างเดียวไม่พอซะแล้ว เราต้องคิดไปถึงการแก้ปัญหาถ้าการป้องกันไม่ได้ผลด้วย … เอาหละ ลงมือกันเล้ย”

เด็กชาย ก. ใช้เวลาเป็นชั่วโมงง่วนอยู่กับการเตรียมข้อมูลเหล่านี้ แต่เค้ามั่นใจว่าหนึ่งชั่วโมงที่เสียไปต้องคุ้มค่าอย่างแน่นอน —– 4

ความเสี่ยง (Risk)	ป้องกัน (Mitigation)	แก้ไข (Contingency)
เมาเรือ	กินยากันไว้ก่อน เค้าว่ายี่ห้อนี้ดีนะ Dramamine (ยังไม่ได้ซื้อเลย)	ถ้าจะอ้วกก็อ้วกไปโลด ส่วนใหญ่อ้วกแล้วอาการจะดีขึ้น ฮ่าๆ
	หาเรือข้ามเกาะลำใหญ่ๆหน่อย จะได้ไม่โคลงมากนัก	ถ้าเริ่มรู้สึกเวียนหัวให้สูดหายใจลึกๆ รับลมเย็นๆจากทะเลพร้อมกับยาอม ยาดม ยาหม่อง ประเคนเข้าไปก่อน
	อย่าอ่านหนังสือหรือเล่นไอโฟนนะ การเพ่งสายตาไปที่จุดใดจุดหนึ่งนานๆมันจะทำให้เมาเรือได้ง่าย	ถ้าไม่ไหวจริงๆก็ให้หลับตาเพื่อลดสิ่งเร้าต่อสมองเรา นอนหลับไปจริงๆได้ก็ดีนะ
เป็นลมแดด	อยากอยู่กลางแดดนานๆ ทั้งตอนนั่งเรือไปและตอนเล่นน้ำ	ปฐมพยาบาลโดยด่วนที่สุด ... (ทำยังไงหละ?)
	จิบน้ำบ่อยๆ อย่าปล่อยให้ร่างกายขาดน้ำ	เมื่อคืนสติแล้วให้รีบนำส่งโรงพยาบาล ... (เอ๊ะ เกาะที่จะไปเที่ยวมีโรงพยาบาลใช่มั้ย?)
	คอยตรวจสังเกตอาการตัวเองอยู่เสมอ ถ้ามีความรู้สึกร้อนในอก หายใจสั้นและลำบาก ปากแห้ง สายตาพร่ามัว ... นั่นคืออาการเบื้องต้นของลมแดด
แดดเผาจนตัวเกรียม	...	...
กล้องตกน้ำ	...	...
อาหารเป็นพิษ/ท้องเสีย	...	...

หลังจากกินข้าวเที่ยงเสร็จแล้ว เด็กชาย ก. มานั่งคิดต่อว่า “อืม มีอีกตั้งหลายเรื่องที่ยังไม่ได้เตรียมเลยนะ อย่างยาแก้เมาเรือก็ยังไม่ได้ซื้อ เอ้อ เดี๋ยวขอเช็กก่อนด้วยว่าเกาะที่จะไปมีโรงพยาบาลอยู่มั้ย แล้วการเดินทางจากที่พักไปโรงพยาบาลต้องไปยังไง … เรื่องวิธีปฐมพยาบาลคนเป็นลมแดดอีกหละ” เด็กชาย ก. ใช้เวลาทั้งบ่ายนั้นเตรียมการเพิ่มเติมกับเรื่องทั้งหมด ด้วยความมั่นใจว่าเวลาที่เสียไปมันคุ้มค่าแน่นอน —– 5

และแล้วก็ถึงวันเดินทาง

อุตส่าห์เตรียมตัวมาดีขนาดนี้ แน่นอนว่าเด็กชาย ก. ไม่ลืมที่จะกินยาแก้เมาเรือและเช็คให้แน่ใจอีกทีว่ามีน้ำเต็มกระติก … พร้อมที่จะเดินทาง ระหว่างที่นั่งเรืออยู่ เพื่อนก็จับกลุ่มพูดคุยกันอย่างออกรสออกชาติ เด็กชาย ก.ก็ทั้งคุยไปถ่ายรูปเก็บบรรยากาศการเดินทางไป ระหว่างนั้นเองเค้าสังเกตเห็นสิ่งผิดปกติบางอย่างเกิดขึ้นกับเพื่อนเค้าคนหนึ่ง —– 6

“เฮ้ย เด็กชาย ข. เป็นอะไรป่าววะ ทำไมหน้าซีดจัง” เด็กชาย ก.ถามด้วยความเป็นห่วง

“เออ ไม่รู้หวะ เวียนหัวเหมือนจะเป็นลม หายใจไม่ค่อยออกด้วยหวะ” เด็กชาย ข. ตอบคำถามพร้อมกับทิ้งตัวลงนั่งอย่างคนหมดแรง

“แกเหงื่อออกเยอะด้วยหวะ เป็นลมแดดแหงเลย … เฮ้ย มาช่วยกันหน่อยเว้ย” เด็กชาย ก. ตะโกนเรียกเพื่อนคนอื่นมาช่วยกันหิ้วเด็กชาย ข. เข้าร่ม

แล้วเด็กชาย ก. ก็เริ่มปฐมพยาบาลเพื่อนด้วยความรู้ที่ศึกษามา เริ่มจากให้เพื่อนนอนราบ ยกเท้าสูงทั้งสองข้างเพื่อเพิ่มการไหลเวียนของเลือด ถอดเสื้อผ้าออก (เด็กชาย ก. เสียดายเล็กน้อยที่เพื่อนเป็นผู้ชาย ฮ่าๆ) แล้วใช้ผ้าชุบน้ำเย็นประคบตามซอกตัวพร้อมกับให้เพื่อนอีกคนคอยช่วยพัดตามตัวเพื่อระบายความร้อนและลดอุณหภูมิของร่างกาย

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

ส่วนเด็กชาย ก. … เค้ารู้สึกภูมิใจมากที่ได้ช่วยชีวิตเพื่อนรักของเค้าไว้ … เวลาที่เสียไปกับการเตรียมการทั้งหมดนี้มันช่างคุ้มค่าจริงๆ

บทสรุป

หลักการของ Risk Management ถูกอธิบายไว้หมดแล้วด้วยเรื่องของเด็กชาย ก. ข้างบน (เชื่อปะ? ฮ่าๆ) ผมขอสรุปให้ฟังสั้นๆนะครับ

1. เห็นถึงความสำคัญของ Risk Management ด้วยการมองย้อนกลับไปที่งานเก่าๆที่เราทำ … มีอะไรที่ผิดพลาดไปบ้าง มีเรื่องเลวร้ายอะไรที่เราจะป้องกันได้บ้าง
2. มองหาว่างานที่กำลังทำอยู่หรือกำลังจะทำเนี่ยะ มันมีความเสี่ยงอะไรอยู่บ้าง กระบวนการนี้เรียกว่า Risk Identification ครับ
3. หลังจากนั้นก็มาวิเคราะห์และประเมินโอกาสที่ความเสี่ยงนี้จะเกิดขึ้น (Likelihood) และความรุนแรงถ้าความเสี่ยงนี้เกิดขึ้นจริง (Severity) แล้วเลือกเฉพาะความเสี่ยงที่สำคัญจริงๆกับงาน กระบวนการนี้เรียกว่า Risk Assessment ครับ
4. เมื่อเลือกได้แล้ว เราก็มาเตรียมหาทางป้องกันไม่ให้ความเสี่ยงนั้นเป็นจริงขึ้นมา เรากำลังพูดถึง Mitigation Plan แค่นั้นไม่พอครับเพราะเราป้องกันความเสี่ยงพวกนี้ได้ไม่ 100% หรอก มันต้องมีโอกาสที่ความเสี่ยงนั้นจะเกิดเป็นปัญหาขึ้นมาได้อยู่ดี แล้วถ้ามันเป็นปัญหาเราจะทำอย่างไรเพื่อแก้ไขปัญหานั้นหรือเราจะทำยังไงให้มันมีผลกระทบต่องานให้น้อยที่สุด เรามาหา Contingency Plan กันครับ ถ้ามีครบทั้งสองข้อแล้วถือว่ากระบวนการ Risk Response เสร็จแล้วหละ
5. พอรู้ทางหนีทีไล่แล้ว หันกลับมาดูที่งานปัจจุบันด้วยว่า เราวางแผนรับมือความเสี่ยงไว้ดีแล้วรึยัง มีงานไหนที่ต้องทำเพิ่มเพื่อจัดการป้องกันความเสี่ยงเหล่านี้มั้ย ถ้ามีก็จับใส่ Project Plan ไปด้วยครับ ไม่งั้นรับรองได้เลยว่างานนี้จะไม่มีคนทำจนสุดท้ายความเสี่ยงเกิดขึ้นจริง ทุกอย่างที่คิดมาก็เปล่าประโยชน์
6. เตรียมการแล้ว เตรียมตัวแล้ว ถึงเวลาต้องใส่ใจติดตามด้วยว่ามีความเสี่ยงตัวไหนมั้ยที่มีแนวโน้มจะกลายเป็นจริงขึ้นมา ไม่ใช่เอาแต่นั่งทำงานปัจจุบันไปวันๆไม่เงยหน้าขึ้นมาดูสถานการณ์รอบตัวเลยว่าอะไรเกิดขึ้นบ้าง ถ้าเป็นแบบนี้ต่อให้เตรียมแผนมาดียังไงก็ช่วยไม่ได้ครับเพราะว่าความเสี่ยงมันจะกลายเป็นปัญหาไปก่อนแล้ว ไม่ทันได้ป้องกันอะไรเลย กระบวนการนี้เรียกว่า Risk Tracking and Control

จบแล้วครับ ง่ายปะ? Risk Management ในการเดินทางไปเที่ยวกับใน Project เหมือนกันเลยครับ ต่างก็แค่ตัวความเสี่ยงเอง ไปเที่ยวเราพูดถึง เมาเรือ, ลมแดด, ตากแดดจนตัวดำ, … กับ Project เราพูดถึง Requirement Changes, เวลาน้อยไปจนทำไม่ทัน, ลูกค้าอาจจะไม่ให้ความร่วมมือ, สมาชิกในทีมอาจจะลาออกกันไป, Technology ที่ใช้อาจจะใหม่เกินไปและยังไม่เสถียร, และอื่นๆ

ขอบคุณที่ติดตามผลงานฮะ

ต่อจากภาคสามครับ บทความนี้จะกลับมาที่ทฤษฎีที่สำคัญที่ Project Manager ควรรู้และเข้าใจ ทั้งหมดนี้ก็เพื่อให้งานเราเดินไปด้วยความเรียบร้อยตามที่มันควรจะเป็น

5. รู้จักความสัมพันธ์ของสามเหลี่ยมทองคำ

ไม่ว่า Project ไหนก็หนีเรื่องนี้ไม่พ้น Project Manager เค้าจ้างมาก็เพื่อจัดการสร้างความสมดุลให้เกิดขึ้นระหว่าง Scope, Schedule, และ Resources ครับ โดยความหมายแล้ว Scope คือสิ่งที่เราต้องทำใน Project เรียกง่ายๆว่า Requirement นั่นแหละ มันจะเป็นอะไรบ้างก็แตกต่างกันไปตามลักษณะงาน เช่น เขียน Software, จัดซื้อและติดตั้ง Hardware/Network, เขียนเอกสารต่างๆ, จัดเทรนนิ่งให้ลูกค้าก่อนส่งมอบงาน และอื่นๆ?ส่วน Schedule ก็คือเวลาที่เรามีในการทำให้ Scope นั้นเป็นไปตามที่ได้ตกลงกันไว้ สุดท้าย Resources แปลตรงตัวก็คือทรัพยากรที่เรามีซึ่งประกอบด้วย คน, เงิน, และเครื่องไม้เครื่องมือ

ตามทฤษฎีนั้นเราจะให้คำจำกัดความของ Project ที่ประสบความสำเร็จว่า “ส่งมอบงานได้ตาม Scope ภายใน Schedule และ Resources ที่กำหนดไว้” ดังนั้นการสร้างความสมดุลนั้นมีความสำคัญเพราะถ้าขาดสิ่งใดสิ่งหนึ่งไปมันจะกลายเป็นว่า Project เราล้มเหลวไป เมื่อรู้แบบนี้แล้วเราลองมาดูกันครับว่าความสัมพันธ์ของปัจจัยทั้งสามนั้นเป็นอย่างไร

ด้วยสามัญสำนึกนะครับ ทุกคนคงคิดเหมือนกันว่า Scope ยิ่งน้อยยิ่งดี … Schedule ยิ่งยาวยิ่งดี … Resources ยิ่งมากยิ่งดี จริงปะ? เพราะถ้างานน้อยมีเวลาทำมากและช่วยกันหลายคนความเสี่ยงมันก็จะลดลงและโอกาสที่ Project นี้จะประสบความสำเร็จก็มากขึ้น … แต่ช้าก่อน โลกนี้ช่างโหดร้ายยิ่งนัก ความจริงแล้วสิ่งที่ Project Manager ต้องเจอมันจะตรงข้ามกับสิ่งที่หวังไว้หมดเลยครับ เพราะเมื่อทำงานไป Scope จะเพิ่มขึ้นเรื่อยๆ … Schedule อาจจะโดนตัดเพื่อเร่งให้ Project เสร็จเร็วขึ้น … แล้วปิดท้ายด้วย Resources หายไป ทั้งคนลาออกและโดนตัดงบประมาณ ฮ่าๆ แล้วจะทำยังไงกันหละเนี่ยะ

ตอบง่ายๆก็ด้วยสามัญสำนึกอีกเหมือนเดิมครับ

• ถ้า Scope เพิ่มขึ้น เราก็ต้องยืด Schedule ออกไปหรือไม่ก็เพิ่ม Resources เข้ามา หรือทั้งสองอย่าง — ระดับความเครียด 5/10
• ถ้า Schedule ถูกตัดออก เราก็ต้องลด Scope ลงหรือไม่ก็เพิ่ม Resources เข้ามา หรือทั้งสองอย่าง — ระดับความเครียด 5/10
• ถ้า Resources หายไป เราก็ต้องลด Scope ลงหรือไม่ก็ยืด Schedule ออกไป หรือทั้งสองอย่าง?– ระดับความเครียด 5/10
• ถ้า Scope เพิ่มขึ้นและ Schedule ลดลง เราก็ต้องเพิ่ม Resources เข้ามา??– ระดับความเครียด 8/10
• ถ้า Scope เพิ่มขึ้นและ Resources ลดลง เราก็ต้องขอยืด Schedule ออกไป??– ระดับความเครียด 8/10
• ถ้า Schedule และ Resources ลดลง เราก็ต้องขอลด Scope ตามเช่นกัน??– ระดับความเครียด 8/10
• ถ้า Scope เพิ่มขึ้น บวกกับ Schedule ลดลง ปิดท้ายด้วย Resources หายไป เราก็ต้องขอลาป่วยหละครับเพราะระดับความเครียดจะพุ่งสูงถึงระดับ Infinity เฮ้อ

แต่ถ้าพิจารณาให้ลึกลงไปอีกนิดเราจะเห็นว่า … มันไม่ง่ายแบบนั้นหรอก


การเพิ่มคนเข้ามาใน Project

การเพิ่มคนเข้ามาตอนกลางหรือท้าย Project ด้วยความหวังที่ว่าจะทำให้งานเสร็จเร็วขึ้นนั้นไม่สำเร็จเสมอไปนะครับ ในมุมมองส่วนตัวแล้ว Software Development Project ไม่เหมือน Project ประเภทอื่นๆ เช่น Construction Project (โครงการก่อสร้าง) ที่ทุกอย่างค่อนข้างตายตัว มีกระบวนการทำงานที่เชื่อถือได้และมีปัจจัยภายนอกที่มีผลกระทบกับงานน้อยกว่า ในขณะที่ Software Development Project นั้นมีลักษณะที่เฉพาะตัวมากๆครับ เช่น การทำ Web Application จะแตกต่างจาก Mobile Application พอสมควร นั่นหมายความว่าเราต้องการคนที่มีทักษะ ความรู้และประสบการณ์ที่เหมาะสมกับงานจริงๆ (ส่วนใหญ่หายากมาก ภายในเวลาที่กำหนดนะ) ตรงนี้แหละครับที่จะเป็นปัญหา

ถ้าเราต้องเอาเวลาที่มีอยู่น้อยนิดไปสอนงานสมาชิกใหม่มากๆเข้า จนบางครั้งหันกลับมามองแล้วรู้สึกว่า “เฮ้ย ทำเองเสร็จไปนานแล้วนะเนี่ยะ” หนำซ้ำ ถ้าสมาชิกใหม่ที่เข้ามาทำงานผิดพลาดมากเกินไป บ่อยเกินไป มันจะกลายเป็นว่าเราต้องมาใช้เวลาแก้ไขงานเก่าแทนที่จะได้ทำงานใหม่

ความเสี่ยงอีกอย่างที่มีก็คือการรีบรับสมาชิกใหม่เข้ามาในทีมโดยไม่พิจารณาถึงนิสัยใจคอและลักษณะการทำงานให้รอบคอบแล้ว มีอาจจะสร้างปัญหาเรื่องการทำงานเป็นทีมเพิ่มขึ้นมาภายหลังอีกด้วย เช่น เข้ากับคนอื่นไม่ได้ ติสต์แตกทำงานเป็นทีมไม่เป็น อยากป่วยก็ป่วยอยากลาก็ลา สารพัด …


การขยายเวลาของ Project ออกไป

ตัวเลือกถัดมาคือการขยายเวลาออกไปเพื่อทำงานให้เสร็จครบถ้วนก็อาจจะไม่เหมาะสมเหมือนกัน ผมพูดโดยอ้างอิงจากลักษณะธุรกิจแบบ Company C นะครับ ยุคนี้สมัยนี้ Time to Market สำคัญมาก สำคัญที่สุดด้วยซ้ำไป เคยอ่านหนังสือเล่มหนึ่งเค้าบอกไว้ว่า “ธุรกิจ Software นั้น ใคร Release ก่อนเป็นผู้ชนะ …” ประมาณว่าเอาเร็วเข้าว่า Feature ยังไม่ต้องครบ Quality เอาแค่รับได้ก็พอแล้วครับ บอกได้เลยครับว่าถ้าจะมัวมานั่งแก้บั๊กให้ครบทุกตัวก่อนถึงจะ Release ได้นั้นไม่ทันกินแน่นอน มันเป็นไปไมได้ในโลกปัจจุบันแล้วครับ

ทางออกที่ดีกว่าคือ

1. จัดลำดับความสำคัญของ Feature ต่างๆให้ดี ให้ตรงตามความต้องการของลูกค้าขณะนั้นให้มากที่สุด
2. เลือกทำเฉพาะสิ่งที่สำคัญที่สุดในแต่ละ Version
3. Release บ่อยๆ (บ่อยที่สุดเท่าที่จะทำได้) อย่าง Firefox เนี่ยะครับ เมื่อต้นปียัง Version 3 อยู่เลยมั้ง ถึงตอนนี้ Version 7 ใกล้คลอดแล้ว เร็วจริงๆ

การตัดลด Scope

จากประสบการณ์ที่ผ่านมานะครับ กับ Software Development Project เนี่ยะปัจจัยที่ยืดหยุ่นที่สุดจะเป็น Scope คือถึงเวลาจริงๆแล้วเราจะเลือกตัด Scope เพื่อคงไว้ซึ่ง Schedule เดิม (หรือลดลง) ด้วย Resources ที่มีเท่าเดิม (หรือลดลง) ความท้าทายอยู่ที่ว่าถ้าเรามีการเขียนและจัดการ Requirement (หรือ Scope) แบบเดิมๆแล้วหละก็ ยากครับที่การตัดลด Scope จะทำได้อย่างมีประสิทธิภาพ ลองดูตัวอย่างข้างล่างนี้ครับ

ถ้า Requirement เราใหญ่มากแล้วการตัดงานออกคือ … นู้น จัดเต็มไป ตัดระบบค้นหาหนังสือทิ้งทั้งก้อนมันจะทำให้ Software เราไม่สมประกอบอย่างน่าเกลียดไปเลยซึ่ง Product Manager และลูกค้าคงไม่ปลื้มแน่ๆ แต่ลองดู Project ที่สองครับ ถ้าเราแบ่งงานเป็นส่วนย่อยๆให้เหมาะสม เราจะสามารถเลือกตัดเฉพาะส่วนงานที่สำคัญน้อยกว่าออกไปโดยคงไว้ซึ่งสิ่งที่จำเป็นต่อ Software ของเราในเวลานั้นจริงๆ แบบนี้ Software ของเราจะดูดีขึ้นมาเยอะครับ อย่างน้อยก็มีระบบค้นหาด้วยชื่อหนังสือหละ … ทั้งหมดที่พูดมานี่มันเป็น Concept ของ Agile Development ชัดๆ

อย่างไรก็ตาม Project Manager ไม่มีอำนาจตัดสินใจตรงนี้หรอก มันเป็นเรื่องของ Project Sponsor เค้า สิ่งที่เราทำได้คือถามเค้าไว้ตั้งแต่เนิ่นๆว่าระดับความยืดหยุ่นของปัจจัยทั้งสามเป็นอย่างไร ตรงนี้เป็นที่มาของ Flexibility Matrix ครับ


ตารางนี้มีไว้เพื่อบอกว่าถ้าถึงคราวจำเป็นจริงๆแล้ว เราจะเลือกสร้างความสมดุลให้สามเหลี่ยมทองคำนี้อย่างไร จากรูปจะเห็นว่าสิ่งแรกที่เราจะเลือกทำคือลด Scope เพราะมีความยืดหยุ่นมากที่สุด และเราจะไม่ยอมเลื่อน Schedule ออกไปเพราะมันยืดหยุ่นน้อยสุด (อาจจะมีลูกค้ารอใช้ Software อยู่)

จบแล้วครับสำหรับข้อห้าของ “Project Manager จำเป็น” ผมยังมีข้อมูลเหลืออีกเพียบเลย ต่อภาคหน้านะครับ

ต่อจากภาคที่แล้วอีกทีครับ บทความนี้จะพูดถึงเรื่องทั่วไปที่ไม่ใช่ทฤษฎีแต่สำคัญกับงานของ Project Manager ครับ

2. รู้จัก Process ของบริษัทตัวเอง

ทุกบริษัทมีกฎระเบียบของตัวเองซึ่งพนักงานทุกคนควรจะรู้และปฏิบัติตาม Project Manager ก็เช่นกันครับ เราจำเป็นจะต้องรู้และเข้าใจกระบวนการทำงานภายในบริษัทตัวเองเพื่อที่จะได้รู้ว่าต้องทำอะไร/ไม่ทำอะไร เมื่อไร และอย่างไร สิ่งสำคัญที่เกี่ยวกับงานโดยตรงของเราคือบริษัทมีกระบวนการหาเงินอย่างไร บางคนอาจจะคิดว่าก็ง่ายๆไง หาลูกค้าได้ก็หาเงินได้ มันก็จริงครับ แต่สิ่งที่เราต้องเข้าใจคือที่มาของลูกค้านั้นคืออะไร มันต่างกันมากในแง่ของกระบวนการทำงานในรายละเอียด เช่น บริษัทที่มีรายได้มาจากการรับเป็น Outsource ให้กับบริษัทอื่น กระบวนการที่ Project Manager ต้องรับผิดชอบก็จะไม่เหมือนกับบริษัทที่ทำ Software เพื่อขายเอง … ต่างอย่างไร?

บริษัท A รับเป็น Outsource ดังนั้นบริษัท A ต้องมีการเขียน Request For Proposal (RFP) ที่ใช่ยื่นประมูลโครงการ ต้องมีการเขียน Contract ที่รัดกุมเมื่อจะทำสัญญากับผู้ว่าจ้าง ทีมงานที่ต้องใช้ก็จะต้องมีคนที่รู้กฎหมายอยู่ด้วยซึ่ง Project Manager ก็มีหน้าที่ต้องเข้าไปดูแลงานในส่วนนี้ เมื่อประมูลงานชนะ ได้เริ่มทำงานจริงแล้ว Project Manager ก็ต้องทำงานร่วมกับลูกค้าจริง ไม่ว่าจะระดับหัวหน้าหรือจะระดับลูกน้อง (End users) ความท้าทายก็จะมีรูปแบบเฉพาะของมันเอง คร่าวๆแค่นี้

บริษัท B หารายได้ด้วยการเข้าไปเสนอขายระบบ (Product/Solution) ให้กับบริษัทต่างๆ ที่เหมือนบริษัท A ก็คือต้องมี RFP/Contract แต่ที่ต่างอาจจะเป็นที่ต้องมีทีมขาย (Sales Team) เข้าไปขายของโดยมี Project Manager เข้าไปมีส่วนร่วมตรงนี้ด้วย ยังไง? ก็เข้าไปให้คำแนะนำกับ Sales Team ว่าอย่าโม้กับลูกค้าให้มากเกินไป ของจริงมันทำไม่ได้นะ (โว้ย) ฮ่าๆ เสร็จแล้วก็ต้องทำงานกับ Development Team เพื่อส่งมอบงานให้ลูกค้าตามตกลง

บริษัท C มีกลุ่มลูกค้าเป็นของตัวเอง ทำระบบมาก็เอาไปขายลูกค้าพวกนี้แหละ ณ จุดนี้ RFP ไม่จำเป็น แต่สิ่งที่จำเป็นคือการทำงานร่วมกับทีมอื่นๆในบริษัท ส่วนมากแล้วบริษัทประเภทนี้จะเป็นบริษัทใหญ่ที่มีลูกค้าอยู่ทั่วโลก ดังนั้นการจะทำ Project ขึ้นมาซัก Project หนึ่งจะมีเรื่องให้ต้องคิดเยอะแยะหลายมุม เช่น เรื่อง Marketing เรื่อง Support and Training เรื่อง Commercials และอื่นๆ ความท้าทายที่สำคัญมันอยู่ตรงนี้ครับ มีโอกาสน้อยที่ Project Manager บริษัท C จะได้เจอกับลูกค้าจริงๆที่ใช้ระบบเรา ดังนั้นการทำงานร่วมกับ Product Manager ซึ่งเป็นคนที่กำหนดและจัดลำดับความสำคัญของ Requirement เป็นเรื่องสำคัญยิ่ง

3. รู้จักคนที่มีส่วนร่วมกับงานของเรา (Stakeholders)

ผลพลอยได้อย่างหนึ่งของความเข้าใจในข้อที่แล้วก็คือเราจะรู้ว่า … อืม มีใครที่เราต้องติดต่อทำงานด้วยตลอดระยะเวลาของ Project ครับ เช่น สมมติผมเป็น Project Manager ของบริษัท B ผมต้องตีซี๊ไว้กับ Sales Team ให้มากเลยเพราะว่าจะได้รู้ความเคลื่อนไหวของกลุ่มลูกค้าและของที่เค้าจะเอาไปขาย ออกแนวเตรียมตัวเตรียมใจไว้ว่า Project หน้าของเราจะเป็นอะไร และเมื่อ Sales Team จะเข้าไปนำเสนองานให้กับลูกค้าผมก็จะขอไปด้วยนะ คือกลัวว่าพี่ๆเค้าจะไปให้คำมั่นสัญญาที่เกินจริงกับลูกค้า แบบนี้เราจะซวยเองทีหลัง

เมื่อขายงานได้แล้ว ผมก็ต้องเข้าไปทำความรู้จักกับลูกค้าผมล่ะ ว่าแต่จะคนไหนดีหว่า? คนนี้เป็นคนใช้ระบบ คนนี้เป็นหัวหน้าที่ให้ Requirement ส่วนคนนี้เป็นรองประธานบริษัท คนที่ตัดสินใจสุดท้ายทุกอย่างเกี่ยวกับ Project (เรียกว่า Project Sponsor ละกัน) … ผมคงต้องคุยกับทุกคนแหละครับ แค่นี้พอมั้ย? อาจจะไม่หละ บ่อยครั้งที่เราจะเจอพวกมือไม่พายเอาเท้าราน้ำ กลุ่มคนที่ไม่อยากให้ Project นี้ประสบความสำเร็จเพราะเค้าอาจจะเสียผลประโยชน์อะไรบางอย่าง ผมต้องเก็บคนกลุ่มนี้เข้า Blacklist ด้วยเพื่อเตรียมการรับมือ

กลับมาที่บริษัทตัวเอง … คงไม่ขอพูดถึง Development Team แล้วกันนะครับ มันของตายอยู่แล้วที่ Project Manager ต้องคุยกับสมาชิกในทีมได้ … ถ้าไม่ได้ก็ตัวใครตัวมันแล้วกัน

ยอมรับตามตรง ผมห่วยแตกเรื่องความสัมพันธ์ประเภทนี้มากๆเลยครับ ไม่เก่งเรื่องเริ่มทักทายหรือพูดคุยกับคนที่ไม่รู้จัก ไม่เก่งเรื่องสร้าง Connection ไม่เก่งเรื่องหาเรื่องคุย ไม่เก่งเรื่อง … อีกมากมาย ด้วยความที่ผมเป็นคนเงียบๆ ไม่ค่อยสุงสิงกับใคร มันเป็นแบบนี้มาตั้งแต่เกิด ก็ไม่รู้จะทำยังไงเหมือนกันนะ พยายามจะแก้ไขปรับปรุงอยู่แต่มันยากเหลือเกิน

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

สอง … พยายามอย่าเอางานมาเป็นเครื่องมือในการสร้างความสัมพันธ์เพียงอย่างเดียว ประเภทที่เจอหน้ากันแล้วถามแต่เรื่องงาน เรื่องธุรกิจ … อย่าทำแบบนั้นเลย คนฟังเค้าจะเครียดแล้วไม่อยากจะเจอหน้าเราซะก่อน ประสบการณ์ส่วนตัวนะครับ สองเรื่องที่ช่วยได้มากเลยคือดนตรีและกีฬา หาโอกาสทำกิจกรรมพวกนี้กับ Stakeholder ของเราดู ผมว่าได้ผล ยิ่งกับกีฬานะ มันส์

4. รู้จัก Product ในบริษัทคุณให้มากที่สุด

ตามทฤษฎีแล้ว Project Manager จะไม่ยึดติดอยู่กับ Product ใด Product หนึ่ง แต่ต้องพร้อม (เต็มใจรึเปล่าอีกเรื่อง) ที่จะรับงานที่หลากหลายใน Product ที่แตกต่างกันออกไป เช่น ผมเป็น Project Manager ของ Microsoft เริ่มต้นด้วยการดูแล Project Microsoft Word 2010 ผ่านไปหนึ่งปี Project นี้เสร็จล่ะ หัวหน้าสั่งให้ไปช่วยทำ Project Microsoft Excel version 2012 (มีรึเปล่าไม่รู้นะ) … ผมตอบไปว่า “ไม่ได้หรอกครับ ผมไม่รู้เรื่อง Excel เลย ผมไม่ทำหรอกครับ” ถ้าเพื่อนๆเป็นหัวหน้าผมจะรู้สึกยังไง? …

มันเป็นหนึ่งในหน้าที่ที่สำคัญมากของ Project Manager ที่ต้องมีความรู้ในภาพกว้างของ Product ของบริษัทให้ได้มากที่สุด โอเคหละ ถ้าบริษัทมันใหญ่มาก มี Product เยอะมากการจะรู้ทั้งหมดคงเกินกำลัง เช่นจะให้ผมข้ามจาก Microsoft Word ไปดูแล Azure Cloud Services ก็เหมือนจะแกล้งกันไปหน่อย แต่กับ Microsoft Office ด้วยกัน ผมถือเป็นหน้าที่ที่ผมต้องรู้ภาพรวมของ Product ตระกูลนี้ … แล้วต้องรู้แค่ไหน?

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

• เมื่อมี Project เข้ามา เราจะทำความเข้าใจกับ Requirement ได้ง่ายและเร็วขึ้น
• เมื่อทำ Project Plan เราจะเข้าใจความสัมพันธ์ ความเชื่อมโยงของ Task ใน Work Breakdown Structure ได้อย่างชัดเจนซึ่งจะช่วยให้เราทำ Network Diagram ได้ถูกต้องมากขึ้น
• เมื่อทำ Project Plan เราจะมองเห็นถึงความขึ้นต่อกัน (Dependency) ของ Project เรากับ Project อื่นใน Product อื่นได้ชัดเจนขึ้น
• เมื่อได้ตัวเลข Estimation มา เราจะสามารถวิเคราะห์และตั้งคำถามกลับไปยังสมาชิกในทีมได้ว่า งานนี้มันใช้เวลาเยอะ/น้อยไปรึเปล่า? งานนี้ไม่ต้องทำก็ได้ไม่ใช่หรอ?
• เมื่อมี Change เข้ามา เราจะประเมินผลกระทบของมันได้อย่างรอบคอบและแม่นยำมากขึ้น ทั้งผลกระทบภายใน Project เองและผลกระทบกับ Project เพื่อนบ้านด้วย
• และอื่นๆ