สวัสดีครับ เปลี่ยนบรรยากาศกันซักนิดนะครับ ข้างล่างนี้เป็นบทความที่ผมอ่านแล้วชอบใจในรอบเดือนที่ผ่านมาครับ มีมากมายหลายเรื่องราว (ส่วนใหญ่ไม่เกี่ยวกับ Project Management ฮ่าๆๆ) เห็นว่าน่าจะมีประโยชน์กับเพื่อนๆก็เลยลองเอามาฝากให้อ่านกันดูครับ

Estimating the Unknown: Dates or Budgets, Part 1-5

บทความแรกเห็นชื่อก็รีบคลิ๊กเข้าไปอ่านเลยครับ เพราะเป็นเรื่องที่ผมเองก็สงสัยมานานว่าเราควรจะตอบคำถามนี้ของหัวหน้ายังไง

คุณคิดว่างานนี้ใช้เวลาเท่าไร … เอ้อ แล้วราคามันซักประมาณเท่าไร?

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

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

บทความนี้ดีมากครับ ไม่ได้ดีมากในมุมที่จะมีสูตรการคำนวณสำเร็จรูปให้เราเอาปัจจัยต่างๆของ Project มาเข้าสมการแล้วก็ กริ๊ก กริ๊ก ได้ออกมาเป็นตัวเลขจำนวนวันและจำนวนเงิน แต่มันดีในแง่ของกระบวนการซึ่งทำให้ได้มาซึ่งตัวเลขที่มีความใกล้เคียงความจริงและอัพเดทให้ทันสถานการณ์ได้มากที่สุดต่างหาก มันเป็นการสร้างมาตรฐานการทำงานใหม่ๆ ออกแนวให้ความรู้กับหัวหน้างานของเราด้วยว่าคำถามนี้ไม่ได้มีคำตอบเดียวหรอกนะครับ ตัวเลขมันเปลี่ยนแปลงไปได้ตามสถานการณ์ที่เปลี่ยนไป (จริงๆแล้ว หัวหน้าควรจะรู้ความจริงข้อนี้ตั้งแต่แรกแล้ว)

ใบให้สนุกๆ … ผู้เขียนซึ่งมีความเชี่ยวชาญในเรื่อง Agile Development มากแนะนำว่า “อย่าเด็ดขาดที่จะตอบหัวหน้าด้วยตัวเลขเพียงตัวเลขเดียวโดยไม่ระบุขอบเขตความน่าจะเป็นและระดับความมั่นใจของเราไปพร้อมกันด้วย” เช่น “อ๋อ งานนี้ใช้เงิน 1 ล้านบาทครับ ผมว่าวันที่ 15 พ.ค. ปีหน้าก็เสร็จครับ” … ฆ่าตัวตายชัดๆครับ ฮ่าๆๆ แล้วเราควรจะตอบหัวหน้ายังไงหละ? ลองอ่านดูฮะ Estimating the Unknown: Dates or Budgets, Part 1

Never Ask ‘Does That Make Sense?’

อ่านชื่อบทความแล้วก็เดาไม่ออกเหมือนกันว่าผู้เขียนเค้ากำลังพูดถึงเรื่องอะไร แต่พอคลิ๊กเข้าไปอ่านแล้วก็ อืม เป็นประโยชน์มากทีเดียวครับ บทความนี้พูดถึงเราในฐานะคนที่นำเสนองาน ในฐานะผู้นำ ในฐานะหัวหน้าทีม ในฐานะ Project Manager หรือจะอะไรก็ตามแต่ที่ต้องติดต่อสื่อสารกับผู้คน ผู้เขียนให้คำแนะนำที่ดีมากๆว่าเราไม่ควรพูดอะไรออกมาในระหว่างบทสนทนาเหล่านั้น เช่น จากชื่อบทความแหละครับ “Does that make sense?”, “Does it make sense?”, หรือ “Make sense?” เป็นประโยคที่ติดปากฝรั่งหลายๆคน คนฟังบางคนก็ไม่ได้ใส่ใจ ไม่ได้คิดลึกเกินไปกว่าความหมายของมันที่ว่า “สมเหตุสมผลมั้ยครับ?”, หรือ “ความคิดผมเข้าท่ามั้ย?” อะไรแบบนี้ แต่ผู้เขียน (คิดมากไปหน่อย) เค้าบอกว่า ประโยคนี้ไม่ควรพูดออกมาเพราะ (1) มันเป็นการแสดงออกถึงความไม่มั่นใจในตัวเองของคนพูด … เลยต้องมาถามคนฟังว่า แหะๆ เข้าท่ามั้ยครับ? และ (2) แสดงให้เห็นว่าคนพูดความสงสัยในคนฟังว่าจะมีความสามารถพอที่จะเข้าใจในสิ่งที่ตัวเองพูดอยู่มั้ย เป็นต้น

สำหรับผมเอง บทความนี้มีประโยชน์มากครับ ด้วยหน้าที่การงานที่ต้องติดต่อพูดคุยกับคนอื่นเยอะแยะมากมาย … ผมได้คำแนะนำจากหัวหน้ามาว่าระหว่างการประชุมให้พูดคำว่า “I think …” ให้น้อยลงหน่อย เพราะว่าคำนี้มันสื่อให้เห็นถึงความไม่แน่ใจของตัวเราครับ เช่น ผมคิดว่างานนี้น่าจะเสร็จวันนี้นะครับ ผมคิดว่าคุณทอมทำงานนี้อยู่นะครับ อะไรประมาณนี้ครับ … คำแนะนำเพิ่มเติมครับ ถ้าเราไม่แน่ใจอะไรก็บอกไปเลยว่า … “I will confirm the progress with Tom and get back to you soon.”

บทความสั้นๆ อ่านแป๊บเดียวจบครับ Never Ask ‘Does That Make Sense?’

Daniel Pink on How the 21st Century Brain Affects Creativity

Daniel Pink on How the 21st Century Brain Affects Creativity บทความนี้เป็นวิดีโอครับ พูดถึงว่าในศตวรรษที่ 21 นี้สมองข้างไหนมีความสำคัญมากกว่ากัน ทุกคนคงรู้อยู่แล้วครับว่า สมองซ้ายสั่งการร่างกายด้านขวา สมองขวาสั่งการร่างกายด้านซ้าย แต่มีอีกความลับหนึ่งที่น่าสนใจคือ สมองซ้ายเอาไว้ใช้คิดเรื่องที่เป็นหลักเป็นการ เรื่องวิทยาศาสตร์ และเรื่องตรรกะต่างๆ ในขณะที่สมองขวาใช้สำหรับอะไรที่เป็นศิลปะ จินตนาการ และความคิดสร้างสรรค์ ถึงตรงนี้เพื่อนๆคงสงสัยว่า อ่าว แล้วไง มันเกี่ยวอะไรกับชีวิตชั้น ฮ่าๆ

ความเกี่ยวข้องที่ Daniel Pink พูดในวิดีโอของเค้าก็คือ ในศตวรรษที่ 21 นี้บริษัท องค์กร และหน่วยงานต่างๆจะให้ความสำคัญกับสมองขวามากขึ้น ตำแหน่งหน้าที่การงานที่ใช้แต่สมองซ้าย เช่น นักวิเคราะห์ และ เอ่อ ไม่แน่ใจรวมโปรแกรมเมอร์ด้วยป่าว (ฮ่าๆ) ก็ยังสำคัญอยู่นะครับแต่ความสำคัญจะน้อยลง หลังจากฟังวิดีโอนี้แล้วก็ให้นึกไปถึงอีกหนึ่งบทความที่กล่าวไว้โดยสรุปว่า “ในอนาคตอันใกล้ การที่บริษัทใดๆจะเจริญรุ่งเรืองได้นั้น แค่เป็นเลิศด้านเทคโนโลยีหรือกระบวนการผลิตอาจจะไม่เพียงพอที่จะสร้างความได้เปรียบทางธุรกิจ (Competitive Advantage) แล้ว แต่สิ่งที่จะเข้ามามีบทบาทอย่างมากคือความสามารถในการสร้างและปรับเปลี่ยนโครงสร้างทางธุรกิจ (Business Model) ให้ได้รวดเร็ว ทันต่อสถานการณ์และทันต่อความต้องการของลูกค้าด้วย” ผมรู้สึกเลยว่าการจะปรับเปลี่ยนบริษัทไปให้ถึงจุดนั้นสมองขวาสำคัญมากครับ

ดูวิดีโอนี้แล้วได้อะไร ก็ได้ความตระหนักถึงความเปลี่ยนแปลงที่จะเข้ามา แล้วเราก็ต้องเตรียมตัวฝึกฝนและพัฒนาสมองขวาของเราให้มากขึ้นครับ ถ้าใครสนใจเรื่องนี้ผมแนะนำหนังสือเล่มนี้เลยครับ Think Better: An Innovator’s Guide to Productive Thinking เจ๋งสุดๆ

สำหรับเดือนนี้ผมเอามาฝากสามบทความนะครับ หวังว่าจะถูกใจกันบ้าง … เดือนต่อๆไป ถ้าผมอ่านเจออะไรดีๆก็จะเอามาฝากอีกเรื่อยครับ

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

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 จำเป็น” ผมยังมีข้อมูลเหลืออีกเพียบเลย ต่อภาคหน้านะครับ