WSJF คืออะไร: วิธีคำนวณและตัวอย่างการจัดลำดับงานให้คุ้มค่าที่สุด

เวลาที่ development team มีงานรออยู่ใน backlog เต็มไปหมด แล้วต้องเลือกว่าจะทำอะไรก่อน คำถามที่ตามมาเสมอ คือ "จะเอาอะไรเป็นเกณฑ์" ถ้าใช้ความรู้สึกหรือเสียงของคนที่ดังที่สุด สุดท้ายงานใหญ่ที่ดูหรูหราจะเบียดงานเล็กที่คุ้มค่ากว่าออกไป

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

WSJF คืออะไร

WSJF ย่อมาจาก Weighted Shortest Job First แปลตรงตัวว่า "งานสั้นที่มีน้ำหนักสูงให้ทำก่อน" เป็นวิธีจัดลำดับความสำคัญของงานที่มาจากกรอบ SAFe (Scaled Agile Framework) โดยมีเป้าหมายเพื่อเรียงงานให้เกิด ผลตอบแทนเชิงเศรษฐกิจสูงสุดต่อหน่วยเวลา (maximizing economic benefit per unit of time) อธิบายภาษาคนอีกที คือ การเพิ่มประสิทธิภาพการผลิตและการทำกำไรให้ได้มากที่สุดในกรอบเวลาที่จำกัด

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

แนวคิดนี้ตั้งอยู่บนหลักเศรษฐศาสตร์ที่เรียกว่า Cost of Delay หรือ ต้นทุนของการล่าช้า — ทุกงานที่ยังไม่ได้ทำ ล้วนมี "ราคา" ของการปล่อยให้มันรอ ยิ่งงานที่มีต้นทุนการรอสูงถูกดองไว้นาน องค์กรยิ่งเสียโอกาสมาก WSJF จึงพยายามหยิบงานที่มีต้นทุนการรอสูงและใช้เวลาน้อยขึ้นมาทำก่อน

สูตรการคำนวณ

สูตรของ WSJF เรียบง่ายกว่าที่คิด

WSJF = Cost of Delay ÷ Job Size

ตัวเศษ คือ ต้นทุนของการล่าช้า และตัวส่วน คือ ขนาดของงาน (ใช้เป็นตัวแทนของระยะเวลาที่ต้องใช้) ยิ่งค่า WSJF สูง ยิ่งควรทำก่อน

ความละเอียดอยู่ที่ตัวเศษ เพราะ Cost of Delay ไม่ได้มาจากตัวเลขเดียว

แต่ประกอบจาก 3 องค์ประกอบบวกกัน

Cost of Delay = User-Business Value + Time Criticality + Risk Reduction / Opportunity Enablement

User-Business Value (คุณค่าต่อผู้ใช้และธุรกิจ): ถามว่างานนี้มี value ต่อลูกค้าหรือธุรกิจแค่ไหน สร้างรายได้ ลดต้นทุน หรือ ถ้าไม่ทำจะเสียรายได้ไปเท่าไหร่

Time Criticality (ความเร่งด่วนตามเวลา): ถามว่า value ของงานนี้ลดลงตามเวลาหรือไม่ มี deadline ตายตัวไหม ถ้าทำช้าลูกค้าจะรอหรือหนีไปหาทางเลือกอื่น มีหน้าต่างโอกาสที่จะปิดลงหรือเปล่า

Risk Reduction / Opportunity Enablement (การลดความเสี่ยงและการเปิดโอกาส): ถามว่างานนี้ช่วยลดความเสี่ยงในการส่งมอบงานอนาคต หรือ เปิดทางให้โอกาสทางธุรกิจใหม่ๆ ไหม แม้บางงานจะยังไม่ให้คุณค่าตรงๆ กับผู้ใช้ตอนนี้ แต่ถ้าไม่ทำ งานอื่นในอนาคตจะเสี่ยงหรือติดขัด

การให้คะแนนแบบเปรียบเทียบ

จุดที่หลายคนทำพลาด คือ พยายามให้คะแนนเป็นตัวเลขสัมบูรณ์ (Absolute Value = ค่าที่เป็นบวก หรือ 0 เสมอ) เช่น การตี value ออกมาเป็นบาท ซึ่งยากและมักเถียงกันไม่จบ

วิธีที่ SAFe แนะนำ คือ ให้คะแนนแบบเปรียบเทียบกันเอง โดยใช้สเกลแบบ Fibonacci (1, 2, 3, 5, 8, 13, 20)

หลักปฏิบัติ คือ ในแต่ละคอลัมน์ ให้หางานที่มี value น้อยที่สุดแล้วให้เป็น 1 ก่อน จากนั้นประเมินงานอื่นเทียบกับตัวนั้น

เช่น ถ้างาน A มี value เป็น 2 เท่าของงานที่เล็กที่สุด ก็ให้ราว 2 หรือ 3

วิธีนี้ทำให้ทีมไม่ต้องเถียงเรื่องตัวเลขสัมบูรณ์ และป้องกันโรคยอดฮิตที่ทุกงานถูกตีว่า "สำคัญสูง" เหมือนกันหมดจนจัดลำดับไม่ได้

ส่วน Job Size ก็ประเมินแบบเดียวกัน เป็นตัวแทนของความพยายามหรือระยะเวลา โดยถือว่ากำลังคนคงที่พอสมควร งานที่ Size สูง คือ งานใหญ่ที่กินเวลานาน

ตัวอย่างการคำนวณจริง

สมมติว่า domain team หนึ่งมีงาน 4 ชิ้นรออยู่ใน backlog แล้วต้องตัดสินใจว่าจะทำอันไหนก่อน ทีมนั่งประเมินคะแนนแต่ละองค์ประกอบร่วมกันได้ผลดังตาราง

วิธีอ่านตาราง เอา 3 คอลัมน์แรกบวกกันเป็น Cost of Delay แล้วหารด้วย Job Size จะได้ค่า WSJF เช่นงาน A คือ (8 + 5 + 2) ÷ 3 = 15 ÷ 3 = 5.0

เมื่อเรียงตามค่า WSJF จากมากไปน้อย ลำดับที่ควรทำคือ A → C → B → D

สิ่งที่ตัวอย่างนี้สอนเรา

จุดที่น่าสนใจที่สุดอยู่ที่งาน D กับงาน A ลองสังเกตว่างาน D "ยกเครื่องระบบค้นหา" มี Business Value สูงที่สุดในกลุ่มถึง 13 และมี Cost of Delay รวมสูงที่สุดคือ 18 ด้วย ถ้าตัดสินด้วย value อย่างเดียว งานนี้ต้องได้ทำก่อนเพื่อน

แต่พอหารด้วย Job Size ที่สูงถึง 13 ค่า WSJF กลับตกลงมาอยู่ท้ายสุดที่ 1.38 ในทางกลับกัน งาน A "เชื่อมระบบชำระเงิน" มี value ปานกลาง แต่ทำเสร็จเร็ว (Size แค่ 3) ค่า WSJF จึงพุ่งขึ้นเป็น 5.0 และคว้าอันดับหนึ่ง

นี่ คือ หัวใจของ WSJF — มันลงโทษงานใหญ่และให้รางวัลงานเล็กที่คุ้มค่า เพราะในเวลาที่ใช้ทำงาน D หนึ่งชิ้น เราอาจทำงาน A ที่ให้ value ดีได้หลายชิ้น ส่งมอบ value รวมให้ธุรกิจได้เร็วและมากกว่า

อีกจุดที่เห็นได้ คือ งาน C "ย้ายก่อน API เก่าถูกปิด" ที่ Business Value ต่ำแค่ 3 แต่ขึ้นมาอยู่อันดับ 2 เพราะ Time Criticality สูงถึง 8 (มี deadline จากภายนอกที่พลาดไม่ได้) และช่วยลดความเสี่ยงสูง องค์ประกอบ 2 ตัวนี้ดันให้ Cost of Delay รวมสูงพอจะแซงงานที่มี value ตรงต่อผู้ใช้มากกว่า

สะท้อนว่า WSJF ไม่ได้มองแค่คุณค่าเฉพาะหน้า แต่รวมความเร่งด่วนและความเสี่ยงเข้าไปด้วย

ข้อควรรู้ก่อนนำไปใช้

WSJF ทรงพลังแต่ไม่ใช่ค้อนที่ตอกได้ทุกตะปู มีข้อควรระวังอยู่ไม่กี่ข้อ

WSJF เหมาะกับงานที่ตัดสินด้วย value เทียบเวลา เช่น feature และ งาน improvement ที่วัด value ได้ แต่ไม่ได้เหมาะกับงานทุกประเภท

งานอย่าง technical debt ที่ผู้ใช้ไม่เห็นผลตรงๆ หรือ bug รุนแรงที่ต้องแก้ทันที มักจัดลำดับด้วยเกณฑ์อื่นที่ตรงกว่า การพยายามยัดทุกงานเข้าสูตรเดียว คือ ความผิดพลาดที่พบบ่อย

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

และเพราะเป็นการประเมินร่วมกัน value ที่แท้จริงของ WSJF ส่วนหนึ่งอยู่ที่กระบวนการคุยกันในทีม ไม่ใช่แค่ตัวเลขปลายทาง การที่ PO Engineer และผู้เกี่ยวข้องนั่งถกว่าทำไมงานนี้ Time Criticality สูง หรือทำไม Size ถึงใหญ่ ทำให้ทุกคนเข้าใจงานตรงกันและการจัดลำดับโปร่งใส เปลี่ยนการต่อรองด้วยเสียงดังให้กลายเป็นการตัดสินใจบนข้อมูลเดียวกัน

สรุป

WSJF คือ วิธีจัดลำดับงานที่หยิบเอาต้นทุนของการล่าช้ามาหารด้วยขนาดของงาน เพื่อหางานที่ให้คุณค่าสูงที่สุดต่อหน่วยเวลา สูตรคือ Cost of Delay หารด้วย Job Size โดย Cost of Delay ประกอบจากคุณค่าต่อธุรกิจ ความเร่งด่วนตามเวลา และการลดความเสี่ยงหรือเปิดโอกาส ทั้งหมดประเมินแบบเปรียบเทียบด้วยสเกล Fibonacci

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

นี่คือ เหตุผลที่ WSJF ช่วยให้ทีมส่งมอบ value ให้ธุรกิจได้เร็วและมากขึ้น ตราบใดที่ใช้มันกับงานประเภทที่เหมาะ และไม่ลืมว่ามันเป็นเครื่องมือช่วยคิด ไม่ใช่ตัวแทนของการตัดสินใจ