7 เทคนิคจัดลำดับความสำคัญของงาน สำหรับคนสายไอที / โปรแกรมเมอร์

สรุปสั้น ๆ

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

โดยในบทความนี้เราจะพาไปรู้จักกับ Eisenhower Matrix, Value vs. Effort Analysis, การทำ Timeboxing, Scrum Methodology, MoSCoW Method, Pareto Analysis และ Kano Analysis ที่จะเป็นเครื่องมือทำให้เราสามารถจัดการกับปัญหา หรือ งานที่เข้ามาในรูปแบบต่าง ๆ ได้ง่าย โดยแต่ละตัวก็จะมีจุดเด่น และ ลักษณะที่ใช้แตกต่างกัน แต่มีจุดประสงค์หลักเดียวสกันคือการเพิ่มประสิทธิภาพในการทำงานให้เรานั่นเอง

เริ่มต้นจาก Eisenhower Matrix

เทคนิคนี้มาจาก Dwight D. Eisenhower ที่เป็นอดีตประธานาธิบดีคนที่ 34 ของสหรัฐอเมริกา มีไว้เพื่อจัดการกับงานที่มีปริมาณมากที่ไหลเข้ามา แต่เราไม่รู้ว่าจะดำเนินการลำดับความสำคัญต่าง ๆ ยังไงนั่นเอง

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

สำหรับตัวอย่างการนำไปใช้ในงานด้านไอทีแบบเรา ๆ ก็อย่างเช่น ในกรณีที่มีงานเข้ามาหลายตัว ได้แก่ Critical Bug เข้ามาในระบบ, การพัฒนาในฟีเจอร์ใหม่ ๆ และ การ Review Code ก็สามารถนำเทคนิคนี้ไปใช้ได้เช่นกัน โดยเราจะแบ่งงานเหล่านี้ลงไปใน Matrix ดังนี้

งานที่เร่งด่วน และ มีความสำคัญ : Critical Bug ที่เข้ามาในระบบ

งานที่ไม่เร่งด่วน แต่มีความสำคัญ : การ Review Code

งานเร่งด่วน แต่ไม่สำคัญ : (ในที่นี้ไม่มี)

งานที่ไม่สำคัญ และ ไม่เร่งด่วน : การพัฒนาในฟีเจอร์ใหม่ ๆ 

โดยทั้งนี้ขึ้นกับสถานการณ์ หากเราเน้นไปที่คุณภาพงาน อาจจะจัดในรูปแบบด้านบน แต่หากเราเน้นไปที่การพัฒนา MVP ทำ Startup ที่อยากเติบดตไว ๆ ตัวการทำฟีเจอร์ใหม่ อาจลำดับไปอยู่ในช่องต่าง ๆ แทน

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

ต่อมาที่ Value vs. Effort Analysis

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

ตัวนี้จะดูคล้ายกับตัวแรก แต่จะแตกต่างกันตรงที่เน้นไปที่คุณค่า กับ แรงที่เราลงไป เป็น Matrix ที่มี 2 แกนหลักคือ แรงที่ลง (Effort) กับ ผลลัพธ์ที่เกิดขึ้น (Impact) โดย Effort ในที่นี้ไม่จำเป็นต้องเป็นแรงงาน กำลังกาย กำลังใจอย่างเดียว แต่อาจจะเป็น กำลังเงิน ก็ได้เช่นกัน 555

ซึ่งจากภาพเราจะเห็นได้ว่า หากเราพบงานที่ใช้ Effort น้อย แต่เกิด High Impact ตรงส่วนนี้เราจะเรียกว่า Easy Wins อารมณ์เหมือนเจอเกมง่ายที่เล่นผ่านแล้วได้แต้มเยอะ แต่ถ้าหาก Effort ไม่เยอะ และ ผลที่ได้กลับมาก็ไม่เยอะเท่าไหร่ ตรงนี้เราจะตกในช่อง Incremental ซึ่งแปลความได้ว่า เป็นการลงแรงไม่เยอะมาก แต่ตัว Product / Service ของเราก็ถูกพัฒนาถึงเล็กน้อยนั่นเอง

แต่งานบางตัวที่เมื่อเราพยายามไปถึงจุดหนึ่ง แล้ว Impact ยังไม่ได้มากเท่าที่ควร จะอยู่ในจุดที่เรียกว่า Money Pit (หลุมดูดเงิน) แต่ถ้าใช้ Effort เยอะ แต่มี Impact มาก จะเรียกว่า “Big Bets” หรือ เป็นการเดิมพันครั้งใหญ่นั่นเอง

สำหรับการใช้งานเราอาจจะประยุกต์กับงานบางอย่างในทีมของเรา เช่น การปล่อยฟีเจอร์ใหม่เล็ก ๆ อย่างการส่งแจ้งเตือนไปยัง User เมื่อเพื่อน ๆ เขามา Comment อาจทำให้ผู้ใช้งานติด App ของเรามาก ๆ อาจอยู่ในรุปแบบของ High Impact / Low Effort ก็ได้ หรือ การเปลี่ยน Business Model ไปเลย อาจจะไปตกในช่อง Big Bets ได้เช่นกัน

ตัวที่สาม กับ Timeboxing

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

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

Scrum Methodology ที่เราคุ้นเคย

หากใครคุ้นเคยอยู่แล้ว สบายใจได้เลยครับ เพราะงานบางอย่างคุณได้แบ่งมันเป็นระบบอยู่แล้ว เช่น การทำ Product backlog ที่จะมีขั้นตอนในการลำดับความสำคัญของ Requirement และ ฟีเจอร์ต่าง ๆ ที่เข้ามาหาเรา, การแบ่งงานส่งเป็นรูปแบบ Sprint หรือ ตามรอบสั้น ๆ เพื่อให้ได้ Product ที่ใช้งานได้จริง ๆ ตลอดจนไปถึงการทำ Sprint Review, Sprint Retrospective ที่จะให้เราได้พัฒนากระบวนการ และ ตัว Product เราให้ดียิ่งขึ้น

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

ซึ่งหากใครยังไม่ได้นำแนวคิดตรงนี้ไปใช้ ก็ลองไปอ่าน ไปตามกันได้ในหนังสืออย่าง Scrum : The Art of Doing Twice the Work in Half the Time, Essential Scrum: A Practical Guide to the Most Popular Agile Process และ Scrum Mastery: From Good To Great Servant-Leadership ได้เลย

MoSCoW Method

วิธีการจัดลำดับความสำคัญที่ชื่อเหมือนอยู่รัสเซีย แต่จริง ๆ มันมาจาก Must, Should, Could และ Won’t หรือ “ขาดไม่ได้ ต้องมีเท่านั้น, ควรจะมี, มีก็ดี ไม่มีก็ได้ และสุดท้าย ไม่ต้องมี” ซึ่งทำให้เราสามารถแยกงานต่าง ๆ รวมถึงเจ้าตัวที่อยู่ใน Backlog ออกมาทำได้ง่ายมาก ๆ

โดยเมื่อเราทราบลำดับความสำคัญแล้ว เราก็นำมาจัดเรียง แต่สิ่งที่เราจะต้องรู้ไว้คือ วิธีการจัดการกับงานเหล่านี้โดยเราจะมีสูตรให้เป็นแง่คิดสั้น ๆ ไว้ตามนี้

• M (Must have) สิ่งที่ต้องมี และ ไม่สามารถที่จะต่อรองให้ไม่ทำได้
• S (Should have) สิ่งที่สำคัญ ไม่ถึงกับที่สุด แต่ควรจะมีเพื่อเพิ่มมูลค่า
• C (Could have) สิ่งที่มีแล้วจะดี จะละเลยก็ได้ แต่ก็จะมีผลกระทบบ้างเล็กน้อย
• W (Will not have) ของที่เราจะไม่ทำในกรอบระยะเวลาทั้งหมดที่มีของเรา

เช่น ระบบของเราจะต้องมีการแสดง Feed แบบ Real-time, ควรมี User Profile, ถ้าต่อกับ Social Media อื่นได้จะดีมาก แต่จะไม่มี Gamification ในระบบแน่นอน

Pareto Analysis

ว่าด้วยเรื่องของ “ถ้าหากเรามีงานอยู่ 100% ให้เราวิเคราะห์ และ ระบุงาน 20% ที่ User จะใช้จริง ๆ / ที่ทำแล้วจะมี Impact เยอะ เท่างาน 80% ที่เหลืออยู่”

เพราะหลายครั้ง Requirement, Ticket, Cases ต่าง ๆ ที่เข้ามาไม่หยุดหย่อนทำให้เราโฟกัสอะไรยากไปหมด แต่การใช้ Pareto Analysis จะช่วยตรงนี้ได้ เช่น เราเลือกที่จะค้นหา Critical Issue หรือ ปัญหาที่หนัก ๆ ที่เกิดขึ้นก่อน เช่น User รอหน้าเว็บช้า จนทำให้คนส่วนใหญ่เข้าเว็บอื่น ก่อนการแก้อีก 80% ของจำนวนงานที่เหลือ เช่น สีของปุ่ม ข้อความที่พิมพ์ตก หรือ อะไรเล็ก ๆ น้อย ๆ (ที่มีจำนวนเยอะ)

“ทำให้เราได้รู้ว่าเราควรจะทำอะไร”

และ วิธีการทำ Pareto Analysis เราก็ได้สรุปย่อ ๆ มาให้ทุกคนลองมาอ่าน มาทำความเข้าใจกันแล้วตามนี้ได้เลย

1. ระบุปัญหาที่ต้องการจะแก้ไข จะแก้ไขอะไร ให้ใคร
2. เก็บรวบรวมข้อมูลของปัญหา รวมถึงตัวเลขต่าง ๆ ที่เกิดขึ้น เพื่อที่จะดูทั้ง Impact และ ความถี่ของปัญหานั้น ๆ ตลอดจนถึงรวบรวมปัญหาอื่น ๆ ที่เกิดขึ้นในแต่ละรายการ แจกแจงจำนวนแต่ละปัญหาให้ชัดเจน
3. สร้าง Pareto chart ซึ่งเป็นแผนภูมิที่ทำให้เราทราบถึงความถี่ที่เกิดขึ้นของปัญหาต่าง ๆ โดยเรียงลำดับจากมากไปน้อย
4. ทำการระบุ 20% ของปัญหาที่มี Impact ต่อ 80% ที่เหลืออยู่
5. ลงมือแก้ไขปัญหาร่วมกัน และ ค้นหาในลักษณะนี้ต่อไป

ส่วนการนำไปใช้ เช่น การที่เราอยากปรับปรุงประสิทธิภาพใน Mobile App ของเรา เราสามารถรวบรวมข้อมูลฟีเจอร์ทั้งหมด และ หยิบ  20% ของฟีเจอร์หลักที่มีคนใช้เยอะที่สุดตามลำดับก็ได้เช่นกัน

สุดท้ายกับ Kano Analysis

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

โดยจะมีองค์ประกอบทั้งหมด 5 ประเภทหลัก ๆ แต่ละประเภทดังนี้

1. Must-be คือสิ่งที่เป็น Requirement ความต้องการพื้นฐานที่ถ้าหาก Product / Service เราไม่มีจะทำให้ลูกค้าไม่พึงพอใจในทันที
2. One-dimensional คือสิ่งที่ลูกค้ากำลังตามหาอยู่ และ ถ้าเรามีฟีเจอร์เหล่านี้จะทำให้ลูกค้าพึงพอใจในทันที
3. Attractive เป็น ฟีเจอร์ที่ลูกค้าไม่คาดหวัง แต่เมื่อมันปรากฎขึ้น จะทำให้ระดับความพึงพอใจสูงขึ้น
4. Indifferent คือ ฟีเจอร์ที่ไม่มีผลต่อความพึงพอใจของลูกค้า ไม่บวก และ ไม่ลบ
5. Reverse เป็นฟีเจอร์ที่ถ้าทำแล้วลูกค้าจะไม่พึงพอใจอย่างแน่นอน

ซึ่งพอเราทราบเรียบร้อยเกี่ยวกับสิ่งที่ทำให้คนใช้งาน / ลูกค้าพึงพอใจใน Product / Service ของเรา เราก็ทำตามขั้นตอนเหล่านี้ได้เลย

1. ทำการระบุปัญหา เช่น การทำแบบสำรวจ, การทำ Focus Group, การทำ Research เพื่อหาความต้องการของ User
2. ทำการแบ่งหมวดหมู่จากประเภทด้านบนว่าลงในหัวข้อไหนจากทั้งหมด 5 ข้อ
3. ดำเนินการจัดลำดับความสำคัญของแต่ละฟีเจอร์ใน Product / Service

มาถึงตรงนี้แล้ว ว่าแต่จะใช้ตัวไหนดี ?

ต้องบอกว่า “ถ้าใช้ทุกตัว คงไม่ต้องทำมาหากินกันแน่ ๆ 5555” ดังนั้นให้เราเลือกใช้ตัวที่แก้ปัญหาได้ตรงจุดมากกว่า หรือ มุมมองตอบโจทย์กับเรามากกว่า เช่น หากเราต้องการเทียบแรงที่มี กับ งานที่ได้ อาจจะใช้ Value vs. Effort Analysis ก็ได้

หรือ ถ้าเป็นหัวหน้าทีม สามารถกระจายงานให้คนอื่น ๆ ได้ Eisenhower Matrix ก็น่าสนใจ หรือ ถ้าจัดลำดับได้แล้ว อยากนำไปใช้งานจริงในชีวิตก็สามารถนำไปใส่ใน Timeboxing ก็ได้เช่นกัน

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