Lois Lane Planning
สัญญาลูกค้าเกินจริง แล้วหวังให้นักพัฒนา “กลายเป็นซูเปอร์แมน” มากอบกู้
ปัญหาคืออะไร
หัวข้อที่มีชื่อว่า “ปัญหาคืออะไร”Lois Lane Planning เป็น antipattern ระดับองค์กรที่ฝ่ายขายหรือฝ่ายบริหาร รับปากส่งมอบ feature หรือกำหนดเวลาที่เกินจริง ทั้งที่รู้อยู่แล้วว่าทีมพัฒนายังไม่พร้อม โดยตั้งอยู่บนความเชื่อ (มักไม่ได้พูดออกมาตรงๆ) ว่าทีมวิศวกรจะ “ลุกขึ้นมากอบกู้สถานการณ์” ได้เสมอ ไม่ว่าคำสัญญาจะไร้เหตุผลแค่ไหน
ชื่อ antipattern นี้ล้อมาจากความสัมพันธ์ของ Superman กับ Lois Lane ใน DC Comics: Lois มักโยนตัวเองเข้าสถานการณ์อันตรายเกินตัวซ้ำแล้วซ้ำเล่า เพราะเธอมั่นใจลึกๆ ว่า Superman จะมาช่วยทันเวลาเสมอ ในองค์กร ฝ่ายขายก็ทำแบบเดียวกัน — เซ็นสัญญากับลูกค้าโดยอ้างอิงจาก roadmap ในฝัน ไม่ใช่สถานะจริงของ code แล้ววางใจว่านักพัฒนาจะเป็น “ซูเปอร์แมน” ที่เนรมิต feature ให้ทันเส้นตายเสมอ
เมื่อวันส่งมอบใกล้เข้ามาและระบบยังรองรับคำสัญญาไม่ได้ ผู้บริหารจึงเรียกทีมพัฒนามาช่วย “ดับไฟ” ทีมต้องทุ่มเทเกินขีดจำกัด (heroic effort) เพื่อรักษาชื่อเสียงองค์กรและปิดดีลที่ขายไปแล้ว งานที่สำคัญกว่าในระยะยาว — การจ่ายหนี้ทางเทคนิค การ refactor การวางสถาปัตยกรรมที่ยั่งยืน — มักตกรถไปเรื่อยๆ เพราะไฟฉุกเฉินจากฝ่ายขายมาก่อนเสมอ
ทำไมถึงดูน่าใช้
หัวข้อที่มีชื่อว่า “ทำไมถึงดูน่าใช้”- ปิดดีลได้เร็วกว่า — การพูดว่า “ได้ครับ ทำได้ทันกำหนด” ปิดการขายได้ทันที ในขณะที่การพูดความจริงว่า “ต้องใช้เวลาอีก 2 เดือน” อาจเสียลูกค้าให้คู่แข่งไปเลย
- ในอดีตมันเคยได้ผล — ถ้าทีมเคย “กู้สถานการณ์” สำเร็จมาแล้วสักครั้งสองครั้ง ฝ่ายขายก็ยิ่งมั่นใจว่าครั้งต่อไปก็จะรอดเหมือนเดิม ทั้งที่แต่ละครั้งอาจเป็นเพียงความบังเอิญหรือการเสียสละที่ไม่ยั่งยืนของทีม
- ไม่มีใครอยากเป็นคนพูดว่า “ไม่ได้” — ผู้บริหารระดับกลางกลัวว่าการปฏิเสธคำสัญญาจะทำให้ตัวเองดูไม่เก่งหรือไม่ทะเยอทะยานพอ จึงเลือกผลักภาระไปให้ทีมพัฒนารับผิดชอบแทน
- วัฒนธรรมฮีโร่ให้รางวัลผิดจุด — องค์กรมักยกย่องคนที่ “เข้ากะดึกกู้ระบบ” ต่อหน้าที่ประชุม มากกว่าคนที่วางแผนดีจนไม่มีวิกฤตให้ต้องกู้ตั้งแต่แรก ทำให้พฤติกรรมสัญญาเกินจริงถูกเสริมแรงซ้ำ (reinforced) แทนที่จะถูกแก้ที่ต้นเหตุ
- ระยะสั้นดูเหมือนไม่มีต้นทุน — ผลกระทบของการทุ่มเทเกินขีดจำกัด เช่น หนี้ทางเทคนิค คนลาออก ไม่ปรากฏทันทีในไตรมาสที่ปิดดีลได้ จึงดูเหมือนเป็นการตัดสินใจที่ “ฟรี” ในสายตาคนที่วัดผลรายไตรมาส
ทำไมถึงเป็นปัญหา
หัวข้อที่มีชื่อว่า “ทำไมถึงเป็นปัญหา”- วงจรอุบาทว์ที่ยิ่งเล่นยิ่งเสี่ยง — ทุกครั้งที่ทีมกอบกู้สถานการณ์สำเร็จ ฝ่ายขาย/ผู้บริหารยิ่งมั่นใจว่าครั้งหน้าก็จะเสี่ยงได้อีก จึงสัญญาโหดขึ้นเรื่อยๆ วนซ้ำแบบ Death March ที่ไม่มีจุดจบ เพราะพฤติกรรมที่ถูกให้รางวัลจะเกิดซ้ำเสมอ
- หนี้ทางเทคนิคพอกพูนแบบซ่อนเร้น — งานที่รีบทำใต้แรงกดดันมักข้ามการทดสอบ ข้ามการรีวิว code และใช้ทางลัดที่ไม่มีใครมีเวลาไปแก้ทีหลัง เพราะไฟฉุกเฉินลูกถัดไปมาถึงก่อนที่จะได้ย้อนกลับไปเก็บกวาด
- งานสำคัญระยะยาวถูกเบียดตกราง — เวลาและพลังงานของทีมที่ควรใช้กับสถาปัตยกรรม การจ่ายหนี้เทคนิค หรือ feature ที่วางแผนไว้ ถูกดึงไปอุดรูรั่วจากคำสัญญาที่คนอื่นให้ไว้แทน project หลักจึงล่าช้าซ้ำซ้อน
- คนเก่งเหนื่อยล้าและลาออก — นักพัฒนาที่ถูกเรียกให้เป็น “ฮีโร่” ซ้ำๆ จะหมดไฟเร็วกว่าคนอื่น และมักเป็นคนที่มีตัวเลือกในตลาดแรงงานมากที่สุด องค์กรจึงเสียคนเก่งไปในจังหวะที่ต้องการฝีมือมากที่สุด
- ทีมสูญเสียความไว้ใจต่อฝ่ายขาย — เมื่อรู้ตัวว่าตนเองถูกใช้เป็น “แผนสำรอง” ของคำสัญญาที่ไม่สมจริง ทีมพัฒนาจะเริ่มไม่เชื่อถือ roadmap ที่ฝ่ายขายวางไว้ และความร่วมมือข้ามทีมจะยิ่งแย่ลง
- ตัวชี้วัดที่ผิด — องค์กรจะไม่มีทางรู้ต้นทุนที่แท้จริงของ feature เพราะสิ่งที่วัดได้คือ “ปิดดีลทันเวลา” ไม่ใช่ “ทีมพัง” หรือ “หนี้เทคนิคเพิ่มขึ้นเท่าไร” การตัดสินใจครั้งต่อไปจึงยังตั้งอยู่บนข้อมูลที่บิดเบือน
ตัวอย่าง
หัวข้อที่มีชื่อว่า “ตัวอย่าง”สมมติฝ่ายขายปิดดีลลูกค้ารายใหญ่โดยสัญญาว่าระบบจัดส่งรองรับ “การส่งสินค้าระหว่างประเทศ” ได้ทันสัปดาห์หน้า ทั้งที่ทีมยังไม่ได้เชื่อมต่อกับผู้ให้บริการขนส่งรายใหม่เลย เมื่อใกล้ถึงกำหนด ผู้จัดการจึงสั่งให้ “เปิด feature ไปก่อน” โดยข้าม guard ที่ทีมตั้งใจกันไว้:
// AntiPattern: เปิด feature ที่ยังไม่พร้อม เพราะฝ่ายขายปิดดีลไปแล้วpublic class ShipmentService{ // เดิมคือ false รอ integration กับ carrier API ใหม่ให้เสร็จก่อน // แต่ผู้จัดการสั่งเปิดคืนนี้เพราะลูกค้าจะใช้งานพรุ่งนี้เช้า public bool IsInternationalShippingEnabled => true;
public ShipmentResult Ship(Order order) { if (order.Destination.IsInternational && IsInternationalShippingEnabled) { // ยังไม่มีตัวคำนวณค่าส่งจริง ใช้ค่าประมาณ hardcode ไปก่อน // และยังไม่มีระบบ tracking จริงจาก carrier ใหม่ return new ShipmentResult { Cost = 9.99m, TrackingNumber = "PENDING-MANUAL-FOLLOWUP" }; }
return _domesticCalculator.Calculate(order); }}ทีมพัฒนาถูกเรียกเข้าประชุมฉุกเฉินตอนสองทุ่ม ทำงานต่อเนื่องข้ามคืนเพื่อ “ทำให้มันพอใช้ได้” ก่อนที่ลูกค้าจะเข้าระบบตอนเช้า code ที่ได้จึงเต็มไปด้วยค่า hardcode และไม่มีการทดสอบ ผลคือคำสั่งซื้อระหว่างประเทศจำนวนหนึ่งคำนวณค่าส่งผิดและติดตามสถานะไม่ได้จริง ทีม support ต้องตามแก้ปัญหาด้วยมือไปอีกหลายสัปดาห์ ขณะที่งานอื่นที่วางแผนไว้ทั้งไตรมาสถูกเลื่อนออกไป
ทางแก้และการ refactor
หัวข้อที่มีชื่อว่า “ทางแก้และการ refactor”หัวใจของทางแก้คือ ผูกคำสัญญาที่ให้ลูกค้าเข้ากับสถานะความพร้อมจริงของระบบ ไม่ใช่ความหวังหรือความกล้าเสี่ยงของฝ่ายขาย ทีมพัฒนาควรมีช่องทางที่ฝ่ายขาย/ฝ่ายบริหารต้อง “ถาม” ก่อนสัญญาอะไรกับลูกค้า แทนที่จะสัญญาไปก่อนแล้วค่อยมาบอกทีมทีหลัง:
// ทางแก้: ผูกคำสัญญาเข้ากับสถานะความพร้อมจริง ผ่าน gate ที่ตรวจสอบได้public class FeatureReadinessGate{ private readonly IFeatureFlagService _flags; private readonly ICapacityPlanner _capacity;
public FeatureReadinessGate(IFeatureFlagService flags, ICapacityPlanner capacity) { _flags = flags; _capacity = capacity; }
// ฝ่ายขาย/ฝ่ายการตลาดต้องเรียก method นี้ก่อนสัญญาวันส่งมอบกับลูกค้า public CommitmentDecision CanPromise(string featureKey, DateTime requestedDate) { var isReady = _flags.PassedDefinitionOfReady(featureKey); var hasSlack = _capacity.HasSlackBefore(requestedDate);
if (!isReady || !hasSlack) { var reason = !isReady ? "feature นี้ยังไม่ผ่าน Definition of Ready เช่น ยังไม่มี integration test" : "ทีมไม่มี slack เพียงพอก่อนวันที่ขอ อาจกระทบงานที่วางแผนไว้แล้ว";
return CommitmentDecision.Decline(reason); }
return CommitmentDecision.Approve(); }}องค์ประกอบของการแก้ปัญหาที่ยั่งยืนกว่านี้:
- Definition of Ready ที่ตรวจสอบได้จริง — กำหนดเกณฑ์ชัดเจนว่า feature “พร้อมสัญญา” ต้องผ่านอะไรบ้าง (ทดสอบผ่าน, มี fallback, มี monitoring) แทนที่จะให้ใครคนหนึ่งเดาเอาเอง
- แยกบทบาทการประเมินความพร้อมออกจากฝ่ายขาย — ให้ทีมพัฒนาหรือ product owner เป็นผู้ยืนยันความพร้อมก่อนวันที่ถูกสื่อสารออกไปสู่ลูกค้า ไม่ใช่ฝ่ายขายประกาศแล้วค่อยแจ้งทีมทีหลัง
- Update the Plan อย่างต่อเนื่อง — เมื่อสถานะงานเปลี่ยน (ล่าช้า, blocked, ขอบเขตเพิ่ม) แผนและวันที่สื่อสารกับลูกค้าต้องอัปเดตทันที ไม่ใช่ปล่อยให้แผนเดิมค้างอยู่จนถึงวันสุดท้าย
- นับต้นทุนของ heroics ให้เห็นจริง — ติดตามชั่วโมงล่วงเวลา ความเหนื่อยล้าของทีม และหนี้ทางเทคนิคที่เกิดจากแต่ละครั้งที่ “กู้วิกฤต” แล้วนำตัวเลขนี้ไปคุยกับผู้บริหารตรงๆ เพื่อให้เห็นว่าการสัญญาเกินจริงมีต้นทุนจริง ไม่ใช่ของฟรี
- ให้รางวัลกับการป้องกัน ไม่ใช่การกู้ภัย — ปรับวัฒนธรรมองค์กรให้ยกย่องทีมที่วางแผนดีจนไม่มีวิกฤต มากกว่าทีมที่ต้องทำงานข้ามคืนเพื่อกอบกู้สถานการณ์ที่ป้องกันได้ตั้งแต่แรก
แผนภาพด้านล่างแสดงวงจรอุบาทว์ของ Lois Lane Planning และจุดที่ควรตัดวงจรด้วย gate ตรวจสอบความพร้อม:
flowchart TD
A[ฝ่ายขายสัญญา feature ที่ยังไม่พร้อม] --> B[ใกล้ถึงกำหนดระบบยังไม่รองรับ]
B --> C[ผู้บริหารเรียกทีมพัฒนามากอบกู้]
C --> D[ทีมทำงานหนักเกินขีดจำกัดจนส่งมอบได้]
D --> E[ผู้บริหารเห็นว่าการเสี่ยงได้ผล]
E --> A
D --> F[หนี้ทางเทคนิคสะสมงานระยะยาวล่าช้า]
G[Definition of Ready gate ก่อนสัญญา] -.-> A