Smoke and Mirrors

โชว์ลูกค้าสิ่งที่ยังไม่มีจริง แล้วหวังว่าทีมจะสร้างมันขึ้นมาทัน

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

Smoke and Mirrors คือแอนตี้แพทเทิร์นระดับการจัดการ project (project management antipattern) ที่ William J. Brown และคณะบันทึกไว้ในหนังสือ AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (1998) โดยนิยามสั้น ๆ ว่าคือการ “demonstrating how unimplemented functions will appear” — สาธิตให้ลูกค้าหรือผู้บริหารดูว่า feature ที่ ยังไม่ถูกสร้างขึ้นจริง จะมีหน้าตาและทำงานอย่างไร โดยไม่ได้บอกตรง ๆ ว่ามันคือของปลอม

รูปแบบทั่วไปคือ demo ที่ดูสมบูรณ์แบบ ปุ่มกดได้ หน้าจอเปลี่ยนลื่นไหล แต่เบื้องหลังกลับเป็นแค่ wireframe, mockup, หรือแอนิเมชันที่ hardcode ค่าไว้ล่วงหน้า ไม่มี business logic จริง ไม่มีการเชื่อมต่อฐานข้อมูลจริง ทีมขายหรือฝ่ายการตลาดจึงมักเรียกแนวทางนี้ว่า Marketing Driven Development — พัฒนาสิ่งที่ “ขายได้” ก่อน แล้วค่อยหาทางทำให้มันทำงานได้จริงทีหลัง

คำว่า “smoke and mirrors” (ควันกับกระจก) มาจากศัพท์ของนักมายากล ที่ใช้ควันและกระจกบดบังกลไกที่แท้จริงของกลลวงตา — เปรียบเทียบได้ตรงตัวกับการสาธิตซอฟต์แวร์ที่สร้างภาพลวงตาว่าระบบพร้อมใช้งานแล้ว

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

ปิดดีลได้เร็ว — demo ที่ดูสมบูรณ์สร้างความประทับใจและความมั่นใจให้ลูกค้าหรือนักลงทุนได้ทันที โดยไม่ต้องรอให้ทีมพัฒนาสร้างของจริงก่อน
สร้างอุปสงค์ (demand) ล่วงหน้า — ตราบใดที่สิ่งที่โชว์ยังพอส่งมอบได้จริงในภายหลัง มันก็ช่วยกระตุ้นตลาดและระดมความสนใจได้ดี
บีบให้ทีมทำงานเร็วขึ้น — ผู้บริหารบางคนเชื่อว่าการตั้ง deadline จาก demo ที่ “ดูใกล้เสร็จแล้ว” จะกดดันให้ทีมโฟกัสและส่งมอบเร็วขึ้น
เข้าใจผิดโดยไม่ตั้งใจ — บางครั้งคนที่ไม่มีพื้นฐานด้านซอฟต์แวร์ (เช่นผู้บริหารหรือนักขาย) เห็น prototype ที่ทำงานได้บางส่วนแล้วเข้าใจไปเองว่ามันคือระบบที่เสร็จสมบูรณ์ ทั้งที่ในความเป็นจริงเบื้องหลังยังต้องทำอีกมาก โดยเฉพาะงานที่มองไม่เห็นอย่างการออกแบบฐานข้อมูลหรือ business logic

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

สัญญาเกินจริงในกรอบเวลาที่ไม่สมจริง — เมื่อลูกค้าถูกบอกให้คาดหวัง “ทุกอย่างที่เห็นใน demo” ภายในเวลาสั้น ๆ นั่นคือสูตรของหายนะ ทีมพัฒนาจะต้องรับภาระสร้างของจริงให้ทันทั้งที่ demo นั้นไม่เคยผ่านการประเมินความเป็นไปได้ทางเทคนิคมาก่อน
ผลักภาระและความผิดไปที่ทีมพัฒนา — เมื่อผู้ใช้ปลายทางพบว่าของจริงไม่ตรงกับที่เห็นใน demo ฝ่ายขาย/การตลาดมักโยนความผิดให้ทีม dev ว่า “ทำไม่ทันตามที่สัญญาไว้” ทั้งที่ทีม dev อาจไม่เคยรู้เรื่อง demo นั้นมาก่อนด้วยซ้ำ
บั่นทอนความไว้วางใจ — เมื่อลูกค้าหรือผู้ใช้ค้นพบว่า feature ที่เคยเห็นทำงานได้ลื่นไหลจริง ๆ แล้วเป็นแค่ animation ที่ไม่มีอะไรอยู่ข้างหลัง ความเชื่อมั่นในทีมและองค์กรจะเสียหายอย่างถาวร ทั้งกับลูกค้าและกับทีมงานภายในเอง
เป็นสัญญาณของวัฒนธรรมที่มีความกลัว — ในองค์กรที่ผู้บริหารดุร้ายหรือไม่ยอมรับข่าวร้าย ไม่มีใครกล้าบอกความจริงว่างานยังไม่เสร็จ ทีมจึงเห็นทางออกทางเดียวคือ “ปลอม demo ให้ผ่านไปก่อน” ซึ่งซ้ำเติมปัญหาแทนที่จะแก้
นำไปสู่แอนตี้แพทเทิร์นอื่นต่อเนื่องกัน — เมื่อสัญญาไว้เกินจริงแล้ว ทีมมักถูกบีบให้เข้าสู่ Death March เพื่อไล่ตาม deadline ที่ไม่สมจริง หรือใช้ทางลัดแบบ Fast Beats Right จนคุณภาพ code พัง
vaporware ทำลายกระบวนการตัดสินใจ — ในบริบทการจัดซื้อซอฟต์แวร์ (vendor evaluation) คำสัญญาจาก demo ที่ยังไม่มีจริงสามารถทำให้ทีมประเมินและตัดสินใจเลือกผลิตภัณฑ์ผิดพลาด เพราะ feature ที่เห็นในการนำเสนออาจไม่มีอยู่จริงใน version ที่จะซื้อ

ตัวอย่าง

สมมติทีมขายต้องปิดดีลกับลูกค้ารายใหญ่ จึงสร้างหน้าจอ dashboard ที่ดูสวยงามและ “คลิกได้” ทุกปุ่ม แต่ข้อมูลทั้งหมดถูก hardcode ไว้ ไม่มีการต่อ API หรือฐานข้อมูลจริงเลย แล้วสัญญากับลูกค้าว่า “ระบบเต็มรูปแบบจะพร้อมใช้งานใน 6 สัปดาห์”

// ตัวอย่างแอนตี้แพทเทิร์น: หน้าจอ demo ที่ hardcode ข้อมูลไว้ล่วงหน้า
// เพื่อให้ดูเหมือนระบบ Order Management ทำงานได้ครบวงจรแล้ว
public class OrderDashboardDemoController
{
    // ข้อมูลปลอมถูกฝังไว้ตรง ๆ ไม่มี service หรือ repository จริงรองรับ
    private readonly List<OrderSummary> _fakeOrders = new()
    {
        new OrderSummary { Id = 1001, Customer = "Acme Co.", Status = "Shipped", Total = 4599.00m },
        new OrderSummary { Id = 1002, Customer = "Globex", Status = "Processing", Total = 1250.00m },
    };

    // ปุ่ม "Approve" ใน demo แค่เปลี่ยนสถานะในหน่วยความจำ
    // ไม่มี business rule, ไม่มีการตรวจสอบสต็อกจริง, ไม่มีการเชื่อมต่อระบบชำระเงิน
    public void ApproveOrder(int orderId)
    {
        var order = _fakeOrders.Find(o => o.Id == orderId);
        if (order != null)
        {
            order.Status = "Approved"; // แค่ทำให้ดูเหมือนใช้งานได้จริงตอน demo เท่านั้น
        }
    }
}

ทีมขายนำ code นี้ไปฉาย demo ให้ลูกค้าดู ลูกค้าพอใจมากและเซ็นสัญญาโดยเข้าใจว่าระบบพร้อมใช้งานเกือบทั้งหมดแล้ว เหลือแค่ “ปรับแต่งเล็กน้อย” — ทั้งที่ในความเป็นจริงยังไม่มี database schema, ไม่มี integration กับระบบคลังสินค้า, ไม่มีการจัดการ concurrency หรือ error handling ใด ๆ เลย เมื่อทีม dev ได้รับ requirement พร้อม deadline 6 สัปดาห์ที่ตั้งมาจาก demo ที่ไม่เคยผ่านการประเมินทางเทคนิค ทีมจึงตกอยู่ในสถานการณ์ที่ต้องเร่งรีบสร้างระบบจริงทั้งหมดในเวลาที่ไม่พอ

flowchart LR
    Sales[ทีมขายสร้าง Demo ปลอม]
    Promise[สัญญา Deadline ที่ไม่สมจริง]
    Dev[ทีม Dev ต้องสร้างของจริงให้ทัน]
    Gap[ช่องว่างระหว่างของจริงกับที่สัญญาไว้]
    DeathMarch[ทีมเข้าสู่ Death March]
    Trust[ลูกค้าเสียความไว้วางใจ]

    Sales --> Promise
    Promise --> Dev
    Dev --> Gap
    Gap --> DeathMarch
    Gap --> Trust

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

Underpromise, overdeliver — สัญญาน้อยกว่าที่ทำได้จริงเสมอ อย่าตั้งกรอบเวลาหรือขอบเขต feature จาก demo ที่ยังไม่ผ่านการประเมินทางเทคนิคจากทีมพัฒนา
ให้ทีมพัฒนามีส่วนร่วมก่อนสัญญา — ฝ่ายขายหรือการตลาดต้องปรึกษาทีม dev ก่อนตั้งความคาดหวังใด ๆ กับลูกค้า เพื่อประเมิน effort และความเป็นไปได้จริงก่อนพูดออกไป
ทำงานใกล้ชิดกับลูกค้าตลอดกระบวนการ — ให้ลูกค้าเห็นผลิตภัณฑ์ ค่อย ๆ เติบโต จากไอเดียสู่ของจริงทีละขั้น (เช่นผ่าน iterative delivery หรือ MVP) แทนที่จะเซอร์ไพรส์ด้วย demo ที่ดูสมบูรณ์ในทีเดียวแล้วพบภายหลังว่ามันคือแค่ wireframe
บันทึกสถานะของระบบเป็นลายลักษณ์อักษร — ระบุชัดเจนว่า feature ไหน “ใช้งานได้จริง” กับ “แค่ต้นแบบ” เพื่อป้องกันความเข้าใจผิดโดยไม่ตั้งใจ ทั้งจากผู้บริหารและจากลูกค้า
ระบุ demo เป็น prototype อย่างชัดเจน — หากจำเป็นต้องสาธิตของที่ยังไม่เสร็จ ต้องบอกตรง ๆ ว่านี่คือ prototype/mockup ไม่ใช่ version ที่พร้อม production พร้อมระบุด้วยว่าส่วนไหนยัง hardcode อยู่
ใช้ Shipping Is A Feature เป็นแนวทาง — ให้ความสำคัญกับการส่งมอบของจริงที่ทำงานได้ (แม้ขอบเขตเล็กกว่า) มากกว่าการสร้างภาพลวงตาว่าเสร็จแล้วทั้งระบบ
สร้างวัฒนธรรมที่กล้าบอกความจริง — ผู้บริหารต้องเปิดทางให้ทีมรายงานสถานะจริงได้โดยไม่ถูกลงโทษ เพื่อไม่ให้ใครรู้สึกว่าต้อง “ปลอม demo” เป็นทางออกสุดท้าย

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

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

ที่มา · deviq.com/antipatterns/smoke-and-mirrors
Introduction to Software Engineering/Architecture/Anti-Patterns – Wikibooks
Anti Pattern for November: Smoke & Mirrors — Peter Lu’s Blog
Tips to Avoid Smoke-and-Mirror Software Demonstrations — business-software.com
AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, William J. Brown et al. (Wiley, 1998) — Software Project Management Antipatterns, บทที่ 7

Smoke and Mirrors

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

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

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