Most managers only measure outputs, not inputs, …

ผมรู้สึกว่ามันก็เป็นแบบนั้นจริงๆ สังเกตได้จากการตั้งเป้าหมายที่เกี่ยวข้องกับเรื่องที่เป็นผลลัพธ์ทั้งสิ้น เช่น ปีนี้จะได้รายได้เท่าไร กำไรเท่าไร ผู้ถือหุ้นจะได้เงินปันผลเท่าไร และอื่นๆ เอาใกล้ตัวเข้ามาหน่อยอย่าง Project Management … Metrics ที่ว่าก็คงไม่พ้น (1) ทำ Project เสร็จตาม Scope มั้ย? (2) ตรงตาม Schedule ที่กำหนดรึเปล่า? (Schedule Variance) (3) แล้วงบประมาณหละเกินมั้ย? (Cost Variance) ซึ่งทั้งหมดนี้มันเป็นผลลัพธ์ปลายทางทั้งสิ้นครับ เปรียบไปก็คล้ายกับการไปกำหนดให้ทีมฟุตบอลยิงประตูให้ได้มากกว่านี้โดยไม่ใส่ใจดูว่าเราจะปรับปรุงพัฒนากระบวนการฝึกซ้อม กระบวนการเก็บรวบรวมข้อมูลและวิเคราะห์คู่แข่ง กระบวนการเฟ้นหาตัวผู้เล่นที่เหมาะสมกับทีม และกระบวนการอื่นๆครับ

ด้วยความคิดแบบนี้ก็เลยเป็นที่มาของชื่อบทความ “คงจะไม่ใช่แค่ Scope – Schedule – Resources อีกต่อไป” ครับ ต่อไปนี้ในสำหรับ Project Management เราคงจะต้องมองหาตัววัดประสิทธิภาพและความสำเร็จของงานในมุมมองที่กว้างออกไป และต้องให้ความสนใจมากขึ้นที่ Input และ Process แล้ว Metrics แบบใหม่ๆที่ว่ามีอะไรบ้าง?

Metric 1: Flow State Percentage

พูดภาษาบ้านๆก็คือ คุณมีเวลาทำงานอย่างมีสมาธิและไม่มีคนรบกวนนานแค่ไหนต่อวัน เรื่องนี้สำคัญมากสำหรับตำแหน่งงานที่ต้องใช้สมาธิมากๆ เช่น Software Engineer ทั้งหลาย ลองดูได้จากหนังเรื่อง Social Network ในฉากที่มาร์ค ซักเกอร์เบิร์ก ใส่หูฟังใหญ่ๆนั่งทำงานอยู่แบบไม่สนใจโลกภายนอกนั่นแหละครับ น่าเสียดายที่พวกเราส่วนใหญ่มักจะโดนขัดจังหวะการเข้าฌาน (In Zone) ของเราอยู่ตลอดวัน อีเมล์ ประชุม (นี่ตัวดีเลย) Instance Messaging โทรศัพท์ และคำถามจากเพื่อนร่วมงาน เค้าศึกษากันมาแล้วครับว่าเอาอย่างหรูเลยนะ พวกเราจะมีเวลาทำงานแบบมีสมาธิจริงๆต่อวันเนี่ยประมาณ 30-50% ของเวลาทั้งหมด แต่ … แต่ ถ้านั่งอยู่ที่ออฟฟิศตัวเลขนี้จะต่ำลงมาอีกอย่างมาก ฮ่าๆๆ ก็รู้ๆกันอยู่

คราวนี้ทำยังไงกันดีหละ? ถ้าคุณเป็นหัวหน้าทีม ลองให้น้องๆในทีมเก็บสถิติมาครับว่าน้องมีเวลาทำงานแบบเข้าฌานคิดเป็นกี่เปอร์เซ็นต์ต่อวัน พยายามหาทางทำให้ตัวเลขนั้นสูงขึ้นเรื่อยๆ เพราะผมเชื่อว่ามันจะมีผลต่อประสิทธิภาพและคุณภาพของงานอย่างมาก แล้วทำยังไงดีให้เพิ่มตัวเลขนี้ได้ ก็มีคำแนะนำนิดหน่อยครับ เช่น กำหนดให้มีหนึ่งวันในสัปดาห์ที่ห้ามมีประชุม หรือเข้าให้โหดกว่านั้นก็คือมีหนึ่งวันในแต่ละเดือนที่ห้ามคุยกันให้ทำงานอย่างเดียว (แบบที่ Jason Fried แนะนำไว้) หรืออนุญาตให้น้องๆเอากระดาษที่เขียนว่า “ทำงานอยู่ อย่าเพิ่งกวน” มาแปะไว้ที่โต๊ะครับ

Metric 2: Meeting Promoter Score

การประชุมส่วนใหญ่ลงเอยด้วยความว่างเปล่า เสียเวลา และเสียตังค์อย่างมาก บางคนว่าจะเสียเท่าไรกันเชียวประชุมชั่วโมงเดียว … ก็จริงครับ ถ้าพี่นั่งอยู่ในห้องคนเดียวมันก็ชั่วโมงเดียวแหละ แต่นี่พี่เรียกคนอีก 20 คนเข้าห้องด้วยเนี่ยะ มันคือ 1 x 20 = 20 ชั่วโมงทำงานนะครับผม บางครั้งรู้ทั้งรู้ว่าไม่ได้อะไรแต่ที่น่าแปลกคือพวกเราก็ยังต้องเข้าประชุมกันทุกวี่ทุกวัน (ฮ่าๆ)

ปัญหามันอยู่ที่กระบวนการอีกเหมือนเดิมครับ บางครั้งก็มีการเรียกประชุมแบบที่ไม่มีวาระ ไม่มี Agenda เข้าไปก็ไม่รู้จะคุยอะไรกัน เรื่อยเปื่อย เลื่อนลอย บางครั้งคุยเรื่องไม่เป็นเรื่องจนหมดเวลา ส่วนเรื่องสำคัญจริงๆ … ไม่ได้คุยเพราะลืม บางครั้ง (ต้องบอกว่าส่วนใหญ่) มีคนแค่ 20% ในห้องประชุมที่พกปากเข้าไปด้วยครับ อีก 80% นั่งเงียบกริ๊บๆ (ตามกฎ 80/20 เลย) ก็ไม่เข้าใจว่าจะเรียกคนที่ไม่มีบทพูดเข้าไปทำไม ให้เค้านั่งทำงานไม่ดีกว่าหรอ? บางครั้งประชุมเสร็จแล้วก็เสร็จกันไป ผลลัพธ์คืออะไรไม่มีใครจด ใครต้องไปทำอะไรต่อจากนั้นก็ไม่รู้ ครั้งหน้ามาประชุมก็คุยกันเรื่องเดิมๆไม่ได้ไปไหนซักที

ถ้าอยากจะปรับปรุงให้การประชุมมีประสิทธิภาพมากขึ้นแบบวัดผลได้ ส่วนตัวผมเองนะครับ ผมคงจะทำแบบสอบถามแล้วสุ่มให้สมาชิกในห้องประชุมเป็นคนให้คะแนนกับการประชุมแต่ละครั้งว่าเป็นอย่างไรบ้าง แบบสอบถามก็น่าจะมีคำถามประมาณว่า (1) คุณคิดว่าคุ้มมั้ยที่มีการประชุมเพราะเรื่องนี้ (2) คุณคิดว่าเวลาที่ใช้ในการประชุมเหมาะสมมั้ย (3) คุณคิดว่าประธานในที่ประชุมทำหน้าที่ได้ดีหรือไม่ (4) คุณคิดว่าคนเข้าร่วมประชุมมีส่วนร่วมในการแสดงความคิดเห็นมากน้อยแค่ไหน (5) คุณคิดว่าผลลัพธ์ที่ได้จากการประชุมจับต้องได้แค่ไหน (6) เป็นต้นครับ

พอได้ผลสำรวจมาแล้วเราคงพอจะมองเห็นว่าปัญหาที่แท้จริงของการประชุมอยู่ที่ไหนแล้วก็ค่อยปรับปรุงกันไปครับ เช่น จะใช้ Six Thinking Hats มาช่วยในระหว่างการประชุมมั้ย? หรือจะเป็นกำหนดหรือขอความร่วมมือให้นัดประชุมก่อนวันจริงล่วงหน้าอย่างน้อย 1 วันเพื่อให้คนเข้าประชุมมีโอกาสเตรียมตัว เตรียมข้อมูลที่จะใช้ในการประชุม อะไรแบบนี้ครับ

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

Metric 3: Compound Weekly Learning Rate

คนที่เคยศึกษาหรือทำงานกับ Agile Development จะรู้จัก Retrospective meeting ดีนะครับ โดยย่อมันเป็นการประชุมเพื่อระดมสมองของคนในทีมเพื่อหาแนวทางปรับปรุงพัฒนากระบวนการทำงานสำหรับ Iteration ถัดไป ส่วนมากแล้วก็จะทำกันหลังจบ Iteration ถ้า Iteration เรายาว 2 สัปดาห์ เราก็จะได้แนวทางการทำงานใหม่ๆ (ซึ่งหวังว่าจะช่วยให้งานดีขึ้น) ทุกๆ 2 สัปดาห์

แต่สำหรับบางคนเค้าคิดว่า 2 สัปดาห์มันนานไป ทำไมเราไม่ปรับปรุงมันทุกวันเลยหละ? ด้วยแนวคิดที่คล้ายกับ “มีสลึงพึงบรรจบให้ครบบาท” ครับ การพัฒนาเล็กๆแต่ต่อเนื่องมันจะสร้างความแตกต่างที่ยิ่งใหญ่ได้ในที่สุด มันดีตรงที่ว่าเราเริ่มทำได้เลย ทำได้ทุกวัน ทำแล้วเห็นผลทันที ถ้าไม่เวิร์คก็เลิก แล้วหาแนวทางอื่นๆต่อไป ถ้าเวิร์คมันก็เป็นกำลังใจอย่างดีให้เราทำต่อไปเรื่อยๆ (เหมือนที่ผมเขียนบล็อกนี่แหละฮะ ฮ่าๆ)

ผมอ่านหนังสือเล่มหนึ่งของ Tony Hsieh ซึ่งเป็น CEO ของ Zappos บริษัทขายรองเท้าออนไลน์ที่ใหญ่ที่สุดในโลก (ตอนนี้โดน Amazon.com ซื้อไปล่ะ) หนังสือชื่อ “Delivering Happiness” ครับ เนื้อหาเป็นการเล่าประวัติของ Tony เองตั้งแต่เรียนจบจนถึงขาย Zappos ให้ Amazon.com ในเล่มมีการกล่าวถึงปรัชญาการทำงานของ Zappos การผลักดันให้พนักงานทุกคนคิดอะไรใหม่ๆที่ช่วยพัฒนาการทำงานของตัวเองให้ได้ทุกวัน เค้าจริงจังเรื่องนี้มากถึงขนาดเขียนลงไปเป็นกฎของบริษัทซึ่งพนักงานทุกคนต้องรับรู้และพยายามทำตามเลยทีเดียว เค้าเรียกสิ่งนี้ว่า “Culture Book” และข้อแรกก็คือนี่เลย “Deliver WOW through service” หลักการคือสร้างความรู้สึกประทับใจ (ว้าว) ให้กับทุกคนที่คุณทำงานด้วยทุกวัน ไม่ว่าจะเป็น ลูกค้า และเพื่อนร่วมงาน … และผลที่ได้คือความสำเร็จของบริษัทครับ

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

หันกลับมาดูงานเราเองอีกรอบครับ ถ้าอยากให้ Project เราประสบความสำเร็จทั้งส่งงานตาม Scope ได้ตรง Schedule ภายใต้ Resources ที่มี … ก็ต้องถามตัวเองว่าวันนี้เราได้หันมามองกระบวนการทำงานภายในของเราเองแล้วหรือยัง?

ปล. บทความนี้เป็นส่วนนำเรื่องของบทความหน้าครับ … ผมจะเล่าให้ฟังว่าในอนาคตอันใกล้นี้ Metric ของ Project Management จะเปลี่ยนไปอย่างไรครับ

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

Related posts:

1. เมื่อ Project ต้อง Delay เพราะ Vendor ที่ไม่มีคุณภาพ
2. จัดการปัญหาอย่างมั่นใจด้วย Flexibility Matrix
3. กระบวนการพัฒนาซอฟท์แวร์อย่างมืออาชีพ — ภาค4

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 เจ๋งสุดๆ

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

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

Related posts:

1. Historical Data กับ Software Estimation

ก็เหมือนทุกครั้งที่เราจะมีของฝากมาให้เพื่อนๆที่ไม่ได้มาร่วมกิจกรรม สิ่งนั้นคือ 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 ต้องทำเป็นกลุ่ม … ใครเอาไปลองเล่นแล้วได้ผลอย่างไรช่วยบอกกันด้วยนะครับ

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

Related posts:

1. Stakeholder Management เรื่องที่ควรใส่ใจ
2. ฟรี Project Management Template
3. Murphy’s Law กับ Project Management

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

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

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

Related posts:

1. Chapterpiece.Meeting.2: Project Planning — How To
2. Chapterpiece.Meeting.2 is Coming.
3. Chapterpiece.Meeting.3: User Story for Agile Development

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

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

วางแผนเรียบร้อย ชวนเพื่อนสนิทๆซัก 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 ที่ใช้อาจจะใหม่เกินไปและยังไม่เสถียร, และอื่นๆ

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

Related posts:

1. คุณรู้หรือไม่ว่า Clint Eastwood เป็นสุดยอด Project Manager
2. Project Manager จำเป็น — ภาคหนึ่ง
3. Project Manager จำเป็น — ภาคสอง