เวลาเราถาม Product Owner ว่า เลือกยังไงว่าทีมจะโฟกัส project ไหนก่อน คำตอบที่เจอบ่อยๆ คือ… การไม่มีเทคนิคอะไรเป็นชิ้นเป็นอันเลย ส่วนใหญ่ใช้ความรู้สึกหรือใครเสียงดังกว่ากัน ทั้งที่จริงๆ แล้วมีแนวคิดหนึ่งที่หลายองค์กรใช้กันมานานและได้ผลดี นั่น คือ Cost of Delay

ปัญหา คือ พอพูดถึง Cost of Delay คนก็จะงงกับตัวแนวคิดนี้ตลอด

บทความนี้เลยอยากอธิบายให้เข้าใจง่ายๆ ว่ามันคืออะไร และทำไมมันถึงช่วยเราตัดสินใจได้ว่า ถ้ามีงาน 2 อย่างหรือมากกว่านั้นรออยู่ เราควรทำอันไหนก่อน

Cost of Delay แปลว่าอะไรกันแน่?

ถ้าจะแปลตรงตัว Cost of Delay ก็คือ "ต้นทุนของความล่าช้า" ซึ่งฟังแล้วก็เหมือนไม่ได้อธิบายอะไรเพิ่มเลยใช่ไหมละ เพราะมัน คือ การนิยามคำด้วยตัวคำนั้นเอง (อ่ะงงเข้าไปใหญ่)

งั้นลองมองแบบใช้งานได้จริงกันดีกว่า Cost of Delay หมายถึง การสูญเสียหรือการถูกเลื่อนคุณค่า (value)/ผลประโยชน์ออกไป ที่เกิดจากความล่าช้า และ/หรือ การต้องแบกรับบทลงโทษบางอย่าง เพิ่มเข้ามา

ตัวอย่าง ที่เราเจอกันในชีวิตประจำวันของ "ต้นทุนของความล่าช้า" เช่น ตอนออกจากบ้านไปทำงานสาย อย่างในกรุงเทพ แค่ออกจากบ้านช้าไป 15 นาที การเดินทางที่ปกติใช้เวลา 30 นาที อาจกลายเป็น 1 ชั่วโมงได้เลย และถ้าเอาความสายนี้ไปรวมกับ "บทลงโทษ" อย่างการพลาดประชุมสำคัญเข้าไปด้วย เราก็จะเห็นภาพ Cost of Delay ชัดขึ้นทันที

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

และถ้าเราพลาดหน้าต่างโอกาสทางการตลาด (market window) ที่ควรจะเข้าถึง Cost of Delay ก็จะยิ่งมาพร้อมบทลงโทษที่หนักขึ้นไปอีก

มอง Project เป็นสี่เหลี่ยม

ในหนังสือ The Principles of Product Development Flow – Don Reinertsen พูดถึง Cost of Delay ไว้อย่างละเอียดว่า เขาใช้โมเดลที่มองแต่ละ project เป็นรูปสี่เหลี่ยมผืนผ้า โดยแกนตั้ง คือ Cost of Delay และแกนนอน คือ เวลาที่ต้องใช้ในการทำ project นั้นให้เสร็จ

พอมองแบบนี้ เราก็จะเริ่มเห็นว่าควรจัดลำดับทำ project ในแบบไหนถึงจะเสีย Cost of Delay น้อยที่สุด วิธีเห็นภาพง่าย ๆ คือ การวาง project แบบ waterfall diagram

project แรก (A/C) จะมี Cost of Delay เป็นศูนย์ เพราะเราเริ่มทำมันทันที ส่วน project ที่สองจะเริ่มสะสม Cost of Delay ระหว่างที่มันรอคิว และ project ที่สามก็ยิ่งสะสมมากขึ้นไปอีกระหว่างรอสองอันแรกเสร็จ

ดังนั้น การเรียงลำดับแบบหนึ่งจะทำให้ Cost of Delay สะสมรวมน้อยกว่าอีกแบบหนึ่งอย่างชัดเจน หลักการง่ายๆ คือ:

อย่าจัดลำดับ project ที่เริ่มจากช้าๆ แล้วค่อยไปเร่งตอนท้าย แต่ให้จัดแบบที่พุ่งแรงตั้งแต่ต้นแล้วค่อยๆ เบาลงตอนหลัง เพื่อให้ Cost of Delay ต่ำที่สุด

ลองมองอีกมุมหนึ่ง ถ้าเราเปลี่ยนจากการพล็อต Cost of Delay มาเป็นการพล็อต "คุณค่า (Value)" ที่ได้รับแทน — เราคงอยากได้เงินเข้ากระเป๋าไปแล้ว 83% ตั้งแต่ผ่านไปครึ่งทางของช่วงเวลา มากกว่าที่จะได้แค่ 12.5% ใช่ไหมละ? นี่แหละ คือ เหตุผลว่าทำไมลำดับการทำงานถึงสำคัญ

Cost of Delay ประกอบด้วยอะไร

Don Reinertsen แตก Cost of Delay (CoD) ออกเป็น 3 องค์ประกอบ (ซึ่งภายหลัง SAFe เอาไปใช้ต่อ) ได้แก่

  • User-Business Value: คุณค่าต่อผู้ใช้/ธุรกิจ
  • Time Criticality: ความไวต่อเวลา (คุณค่ามันลงลงเร็วแค่ไหน ถ้าช้า)
  • Risk Reduction / Opportunity Enablement: ช่วยลดความเสี่ยงหรือเปิดโอกาสใหม่ได้ไหม
รวมสามอย่างนี้เข้าด้วยกัน = Cost of Delay

แล้วเอาไปจัดลำดับยังไง — WSJF

โมเดล Weighted Shortest Job First (WSJF) นำมาใช้ในการคิดเรื่องนี้ – ผมเคยเขียนบทความเรื่องนี้ไว้แล้วด้วย

WSJF = Cost of Delay ÷ Job Duration

หลัก คือ ทำงานที่มี CoD สูงต่อระยะเวลาสั้น ก่อน (ค่าอัตราส่วนสูงสุดขึ้นก่อน) นี่คือลำดับที่ทำให้ CoD สะสมรวมต่ำที่สุดตามคิว และเป็นเหตุผลว่าทำไมในระบบแบบ flow การจัดลำดับงาน (sequencing) ให้ผลดีกว่าการจัดตาม ROI รายชิ้นแบบเดี่ยวๆ และมันยังตัด sunk cost ทิ้งโดยอัตโนมัติด้วย

💡
A sunk cost is any money, time, or effort already spent that cannot be recovered.

จุดที่คนมักพลาด – สิ่งที่มักถูกมองข้าม

  1. รูปร่างของ CoD ไม่ได้เป็นเส้นตรงเสมอ: บางงานเป็นเส้นลาดสม่ำเสมอ บางงานเป็น step function (มี deadline ตายตัว พอเลยเส้นตายคุณค่าจะหล่นวูบไปเลย) การเข้าใจ "รูปทรง" ของ curve สำคัญพอๆ กับตัวเลข
  2. ประมาณคร่าวๆ ก็ยังดีกว่าไม่ประมาณ: การเดา CoD แบบหยาบๆ ที่ผิดสัก 30% ก็ยังให้ลำดับงานที่ดีกว่าการให้ story point ที่แม่นเป๊ะ แต่ไม่บอกอะไรเรื่อง value เลย

Cost of Delay ใช้ได้ในระดับอื่นๆ

จากที่เล่ามาดูเหมือน CoD นั้นจะใช้กับการจัดลำดับในระดับ project แต่จริงๆ แล้ว เราสามารถนำมาใช้ในระดับของการจัดลำดับในระดับการทำงานได้เหมือนกัน

ตัวอย่าง

ถ้าหากเรามีงานที่ต้องทำ 10 อย่าง แทนที่เราจะเรียงลำดับโดยการเริ่มทำงานชิ้นที่หนึ่งแล้วต่อด้วยชิ้นที่ 2,3,4,5 ไปเรื่อยๆ แล้วไปเจอว่า งานชิ้นที่ 6 ทำให้งานชิ้นนั้นไปต่อไปไม่ได้แล้ว

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

เช่น แทนที่เราจะทำหน้า config ค่าเริ่มต้นให้เสร็จ แล้วไปทำหน้ากรอกฟอร์มข้อมูล (โดยมีการดึงข้อมูลจากค่าเริ่มต้นมาแสดง)

เราก็มองว่าการกรอกฟอร์ม คือ สิ่งที่มี value มากกว่าการทำหน้า config เพราะถ้าหากเรามีแค่หน้า config แต่ไม่มีฟอร์มให้กรอก มันก็สร้าง value อะไรไม่ได้

กลับกัน ถ้าเรามีหน้ากรอกฟอร์ม แต่ยังไม่มีหน้า config (ใช้การ hard code/default) ก็ไม่ได้กระทบอะไรกับผู้ใช้หลักเท่าไหร่

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

ข้อคิดทิ้งท้ายเรื่อง Cost of Delay

สิ่งหนึ่งที่ต้องจำไว้เลย เวลาจัดลำดับ project คือ คุณค่าโดยรวมไม่ได้มีแค่ เงิน และต้นทุนก็ไม่ได้จ่ายเป็นตัวเงินเสมอไป แน่นอนว่าเรามองหา return on investment แต่เราก็ต้องคิดด้วยว่าการตัดสินใจแลก (trade-off) เพื่อทำหรือเลื่อน deadline นั้น จะส่งผลอย่างไรต่อส่วนแบ่งตลาด ความภักดีของลูกค้า และความน่าเชื่อถือของแบรนด์

ยกตัวอย่าง เช่น...

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

ในทางกลับกัน ถ้าเรารีบเร่งออกสู่ตลาดแล้วปล่อย software ที่เต็มไปด้วย bugs ออกไป มันจะกระทบความภักดีของลูกค้า ยอดขายโดยรวม และความน่าเชื่อถือของแบรนด์ขนาดไหน?

รายละเอียดพวกนี้อาจต้องเก็บไว้เล่ากันยาวๆ ในอีกบทความ แต่ก็อยากชี้ให้เห็นว่ามันมีต้นทุนที่แฝงอยู่ ซึ่งมันไม่ได้แสดงให้เห็นอย่างชัดเจน แต่มันจับต้องได้จริง

อีกอย่างที่ต้องไม่ลืม คือ คุณค่าที่เราตั้งไว้ให้กับ project เป็นเพียงคุณค่าที่ คาดการณ์ หรือ คาดหวัง ไว้เท่านั้น

บริษัททำ project บนพื้นฐานของ สมมติฐาน ว่ามันจะให้ผลประโยชน์ตามที่คิด แล้วถ้าสมมติฐานนั้นผิดล่ะ?

เราคงอยากมีเวลาปรับตัวมากกว่า (เพื่อจะยังไปถึงเป้าหมายรวมได้) มากกว่ามีเวลาน้อยลง จริงไหม?

มีกี่ครั้งแล้วที่เราหรือผู้บริหารถอนหายใจว่า "รู้งี้น่าจะรู้เร็วกว่านี้!" — สิ่งนี้ก็ คือ "ต้นทุน" ที่เกิดจากการได้ feedback ช้าเกินไปนั่นเอง

References