Death March

project ที่แทบไม่มีหวังสำเร็จ แต่ทุกคนถูกบังคับให้เดินหน้าต่อ

ปัญหาคืออะไร

Death March คือ project ที่ แทบไม่มีความหวังจะสำเร็จตามเงื่อนไขที่ตั้งไว้ — เกินงบ เกินกำหนดเวลา ขอบเขตงานบวมเกินจริง หรือขาดคนที่มีฝีมือพอ จนแทบทุกคนที่เกี่ยวข้องรู้ดีว่ามันคือหายนะที่รอวันเกิดขึ้น แต่ผู้บริหารกลับปฏิเสธไม่ยอมรับความจริงนั้น

Edward Yourdon ผู้บัญญัติศัพท์นี้ในหนังสือ Death March (1997) ให้นิยามเชิงปริมาณไว้ว่า project จะถือเป็น death march เมื่อ “parameter ของ project” อย่างน้อยหนึ่งอย่าง — เวลา งบประมาณ กำลังคน หรือขอบเขต feature — เบี่ยงเบนไปจากค่าที่สมเหตุสมผลอย่างน้อย 50% เช่น ทีมที่ควรมี 10 คนกลับมีแค่ 5 คน หรือกำหนดที่ควรใช้เวลา 12 เดือนกลับถูกบีบให้เหลือ 6 เดือน

ผลที่ตามมาคือทีมพัฒนาถูกบังคับให้ทำงานต่อ มักถูกเรียกให้ทุ่มเทแบบวีรบุรุษ (heroic effort) เพื่อไล่ตามกำหนดที่มองโลกในแง่ดีเกินจริง เช่น ทำงาน 60-80 ชั่วโมงต่อสัปดาห์ ทำงานวันหยุดสุดสัปดาห์และวันหยุดยาวต่อเนื่องหลายเดือน ยิ่งทุกคนยอมรับความจริงว่ากำลังอยู่ใน death march เร็วเท่าไร ก็ยิ่งจัดการสถานการณ์ได้ดีเท่านั้น — เพราะทางเลือกที่แท้จริงมีแค่เจรจาลดขอบเขต/เลื่อนกำหนด หรือยอมรับว่า project นี้จะพังไม่ว่าจะพยายามแค่ไหน

ทำไมถึงดูน่าใช้

“เดี๋ยวก็ผ่านไป” — ผู้บริหารมองว่าการกดดันให้ทำงานหนักขึ้นเป็นทางออกชั่วคราวที่ราคาถูกที่สุด ไม่ต้องเจรจาลดขอบเขตหรือของบเพิ่ม
ความกลัวเสียหน้า — การยอมรับว่ากำหนดเดิมเป็นไปไม่ได้ หมายถึงต้องแจ้งลูกค้าหรือผู้บริหารระดับสูงกว่า ซึ่งดูเหมือนความล้มเหลวส่วนบุคคลของผู้จัดการ project
Sunk cost — ทีมลงทุนเวลาและเงินไปมากแล้ว การหยุดหรือรีสโคปดูเหมือนทำให้สิ่งที่ลงทุนไปสูญเปล่า ทั้งที่จริงคือ “ต้นทุนจม” ที่ไม่ควรมีผลต่อการตัดสินใจไปข้างหน้า
วัฒนธรรมฮีโร่ — องค์กรบางแห่งให้รางวัลคนที่ “กู้วิกฤต” ด้วยการทำงานหามรุ่งหามค่ำ ทำให้การทำงานเกินขีดจำกัดถูกมองเป็นความดีความชอบแทนที่จะเป็นสัญญาณเตือนของการวางแผนที่ผิดพลาด
ความเชื่อผิดๆ ว่าคนเพิ่ม = งานเร็วขึ้น — ตามกฎของ Brooks การโยนคนเข้าไปเพิ่มกลาง project ที่ล่าช้ามักทำให้ล่าช้ากว่าเดิม เพราะต้นทุนสื่อสาร/ onboarding แต่ผู้บริหารที่ไม่คุ้นงานพัฒนาซอฟต์แวร์มักคิดว่าเป็นทางแก้ที่ตรงไปตรงมา

ทำไมถึงเป็นปัญหา

คุณภาพร่วงลงเรื่อยๆ — เมื่อคนเหนื่อยล้าสะสม bug เพิ่มขึ้น การทดสอบถูกข้าม ทางลัดสกปรก (shortcuts) ถูกใช้แทนวิธีที่ถูกต้อง หนี้ทางเทคนิคพอกพูนเร็วกว่าที่ทีมจะจัดการไหว
Productivity ไม่ได้เพิ่มตามชั่วโมง — งานวิจัยด้าน software engineering ชี้ซ้ำแล้วซ้ำเล่าว่าการทำงานเกิน ~40-45 ชั่วโมง/สัปดาห์ต่อเนื่องทำให้ผลผลิตต่อชั่วโมงลดลง จนสุดท้ายทำงานได้ผลลัพธ์น้อยกว่าทีมที่ทำงานตามเวลาปกติ
คนเก่งลาออกก่อน — คนที่มีตัวเลือกในตลาดแรงงานมักลาออกจาก death march ก่อนใคร เหลือแต่คนที่ไม่มีทางเลือก ทำให้ทีมยิ่งอ่อนแอลงในจังหวะที่ต้องการฝีมือมากที่สุด
สื่อสารพัง — เมื่อเป้าหมายเปลี่ยนไปเรื่อยๆ และไม่มีใครกล้ารายงานสถานะที่แท้จริง (เพราะกลัวถูกตำหนิ) ผู้บริหารก็ยิ่งตัดสินใจผิดพลาดต่อเนื่องด้วยข้อมูลที่ไม่ตรงความจริง
สุขภาพและความสัมพันธ์พัง — ผลกระทบไม่ได้จำกัดแค่ project แต่ลามไปถึงสุขภาพกาย สุขภาพจิต และความสัมพันธ์ในครอบครัวของสมาชิกทีม
แม้ “สำเร็จ” ก็ยังแพ้ — ต่อให้ทีมฝ่าฟันจนส่งงานได้ทันเวลา สิ่งที่ส่งมอบมักเต็มไปด้วยหนี้ทางเทคนิคและ bug ซ่อนอยู่ ต้นทุนที่แท้จริงเพิ่งจะเริ่มในเฟสถัดไป และทีมก็หมดแรงเกินกว่าจะรับมือ

ตัวอย่าง

code ด้านล่างไม่ใช่ “pattern code” ในความหมายปกติ แต่จำลองอาการของ death march ที่ฝังอยู่ในระดับกระบวนการ: การประเมินงานถูกเมินเพื่อ “เอาให้ทัน” และทางลัดถูกฝังลงใน code จนกลายเป็นหนี้เทคนิคถาวร

// แอนตี้ pattern: จัดการชั่วโมงงานแบบ death march ด้วยการฝืนไล่ตาม deadline
// พร้อมข้ามการตรวจสอบเพื่อ "ประหยัดเวลา"
public class ReleaseManager
{
    public ReleaseResult ShipFeature(Feature feature, DateTime hardDeadline)
    {
        // ผู้บริหารบอกว่า deadline "เลื่อนไม่ได้" ทั้งที่ทีมประเมินไว้ว่าต้องใช้เวลาอีก 3 สัปดาห์
        if (DateTime.Now > hardDeadline.AddDays(-2))
        {
            // ข้าม code review และ automated test เพื่อเร่งให้ทัน
            SkipCodeReview(feature);
            SkipAutomatedTests(feature);

            // บังคับทีมทำงานล่วงเวลาแบบไม่มีกำหนดสิ้นสุด
            foreach (var developer in feature.AssignedTeam)
            {
                developer.MandatoryOvertimeHoursPerWeek = 80;
            }
        }

        // ส่งมอบโดยไม่มีใครรายงานว่าจริงๆ แล้วงานยังไม่เสร็จสมบูรณ์
        return new ReleaseResult { Shipped = true, Feature = feature };
    }
}

// ทางแก้: ทำให้ต้นทุนที่แท้จริงของขอบเขต/กำหนดเวลา "มองเห็นได้" แต่เนิ่นๆ
// แล้วเจรจา ไม่ใช่ปิดบังด้วยการทำงานหนักเกินขีดจำกัด
public class ReleasePlanner
{
    private readonly ICycleTimeTracker _cycleTime;

    public ReleasePlanner(ICycleTimeTracker cycleTime) => _cycleTime = cycleTime;

    public ReleaseDecision PlanRelease(Feature feature, DateTime requestedDeadline)
    {
        // ใช้ cycle time จริงของทีม (ไม่ใช่ story point ที่ประเมินแบบมองโลกในแง่ดี)
        // เพื่อคาดการณ์วันที่งานจะเสร็จอย่างมีคุณภาพ
        var forecast = _cycleTime.ForecastCompletionDate(feature);

        if (forecast > requestedDeadline)
        {
            // เปิดเผยช่องว่างและทางเลือกที่แท้จริงให้ผู้มีอำนาจตัดสินใจ
            // แทนที่จะแอบข้ามขั้นตอนคุณภาพ
            return ReleaseDecision.NegotiateScopeOrDeadline(
                forecast,
                options: new[]
                {
                    "ตัดขอบเขตลงให้พอดีกับเวลาที่เหลือ",
                    "เลื่อนกำหนดให้ตรงกับ forecast",
                    "เพิ่มการทำงานร่วมกัน (pairing/mobbing) เพื่อลดเวลารอคอยระหว่างงาน",
                });
        }

        return ReleaseDecision.Proceed(feature, forecast);
    }
}

ทางแก้และการ refactor

ยอมรับความจริงให้เร็วที่สุด — ทั้งทีมและผู้บริหารต้องเรียกสถานการณ์ตามที่มันเป็น การปฏิเสธไม่ได้ทำให้ deadline เป็นไปได้จริงขึ้น มีแต่ทำให้เสียเวลาที่ควรใช้เจรจาไปฟรีๆ
วัดของจริง ไม่ใช่ประเมินแบบหวังดี — เปลี่ยนจาก story-point estimation ไปใช้ cycle time จริงของทีม เพื่อ forecast วันเสร็จที่แม่นยำ แล้วนำตัวเลขนั้นไปเจรจากับผู้มีส่วนได้ส่วนเสีย (ดู pc-updateplan)
เจรจาสามเหลี่ยมเวลา-ขอบเขต-ทรัพยากร — เมื่อ parameter ใดเบี่ยงเบนไปมาก ต้องยอมปรับอีก parameter หนึ่งเสมอ ตัด scope, เลื่อนวันส่ง, หรือเพิ่มทรัพยากรที่เหมาะสม (ไม่ใช่แค่ “เพิ่มคน” กลางทาง เพราะ กฎของ Brooks ชี้ว่าอาจยิ่งช้าลง)
ลดเวลารอคอยด้วยการทำงานร่วมกัน — สาเหตุหนึ่งที่ทำให้ project ดูช้ากว่าที่ควร มักมาจากเวลา “รอคิว” ระหว่างขั้นตอน ไม่ใช่เวลาทำงานจริง การ pairing/swarming/mobbing ช่วยลดคอขวดนี้ได้มากกว่าการเพิ่มชั่วโมงทำงานต่อคน
รักษาคุณภาพไว้เป็นเกราะสุดท้าย — อย่าข้าม code review หรือ automated test เพื่อ “ประหยัดเวลา” เพราะหนี้ทางเทคนิคที่สะสมจะทำให้เฟสถัดไปช้าลงกว่าเดิมหลายเท่า
ให้ทางเลือกออกอย่างมีศักดิ์ศรี — ถ้าสุดท้าย project ต้องพัง ควรทำให้ทีมมองเห็นตั้งแต่เนิ่นๆ ว่ามีทางเลือกอื่นที่ดีกว่าการ “ตายไปพร้อมกัน” เช่น ย้ายไปทำ project อื่นที่มีโอกาสสำเร็จจริง

Death March

ปัญหา​คือ​อะไร

ทำไม​ถึง​ดู​น่า​ใช้

ทำไม​ถึง​เป็น​ปัญหา

ตัวอย่าง

ทาง​แก้​และ​การ refactor

ที่​เกี่ยวข้อง

แหล่ง​อ้างอิง

ปัญหาคืออะไร

ทำไมถึงดูน่าใช้

ทำไมถึงเป็นปัญหา

ทางแก้และการ refactor

ที่เกี่ยวข้อง

แหล่งอ้างอิง