Know Where You Are Going

อย่าเขียน code โดยปิดตา — เข้าใจว่าสิ่งที่สร้างจะถูกใช้แก้ปัญหาอะไร

คืออะไร

“Know Where You Are Going” คือแนวปฏิบัติที่เตือนนักพัฒนาไม่ให้เขียน code โดยสวมที่บังตา (blinders) — จงเข้าใจก่อนลงมือว่าสิ่งที่กำลังสร้างจะถูกใช้อย่างไร และมันมีไว้แก้ปัญหาอะไรให้ใคร แนวคิดนี้ไม่ใช่เรื่องใหม่ นักวิชาการด้าน requirements engineering อย่าง Barry Boehm เคยแยกงานสองแบบไว้ตั้งแต่ปี 1981 ว่า requirements engineering คือการ “ออกแบบสิ่งที่ถูกต้อง” (designing the right thing) ในขณะที่ software engineering คือการ “ออกแบบให้ถูกวิธี” (designing the thing right) — สองอย่างนี้เป็นคนละทักษะ คนละความเสี่ยง และล้มเหลวได้คนละแบบ

ปัญหาคือนักพัฒนามักถูกดึงดูดเข้าสู่ tunnel vision โดยธรรมชาติของอาชีพเอง โจทย์เชิงเทคนิคที่ท้าทายหรือน่าตื่นเต้น (เช่น ลอง pattern ใหม่ เขียน abstraction ที่สวยงาม หรือ optimize ส่วนที่ไม่มีใครวัด) ดึงความสนใจไปจากคำถามที่สำคัญกว่า: งานนี้เพิ่มคุณค่าให้ผู้ใช้จริงหรือไม่? ผลลัพธ์ที่พบบ่อยเมื่อหลงทางคือ over-engineering — สร้างสิ่งที่ซับซ้อนเกินความจำเป็น หรือแย่ยิ่งกว่านั้นคือสร้าง ของผิดตัว ไปเลย ทำงานถูกต้องตาม spec ทุกกระเบียดนิ้ว แต่ไม่มีใครต้องการมัน

Steve Smith (ผู้เขียนต้นฉบับของแนวปฏิบัตินี้ใน DevIQ) ขยายความเรื่องนี้ใน block ส่วนตัวของเขาว่าองค์กรมักตกอยู่ใน false dichotomy ระหว่าง “Build The Right Thing” (การค้นหาว่าลูกค้าต้องการอะไรจริง ๆ ผ่าน lean product development) กับ “Build The Thing Right” (การส่งมอบอย่างมีประสิทธิภาพผ่าน continuous delivery) — ทีมที่ประสบความสำเร็จต้องพัฒนาทั้งสองความสามารถไปพร้อมกัน เพราะทีมที่ส่งมอบเก่งแต่ไม่รู้ว่าจะสร้างอะไรก็สูญเสียความได้เปรียบในตลาดพอ ๆ กับทีมที่รู้ว่าควรสร้างอะไรแต่ส่งมอบไม่ทัน

ทำอย่างไร

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

ในทางปฏิบัติ มีกลไกหลายแบบที่ช่วยให้ทีมพัฒนา “รู้ว่ากำลังไปทางไหน” อย่างต่อเนื่อง แทนที่จะพึ่งพา Big Design Up Front (BDUF) ที่ตั้งใจให้สมบูรณ์แบบตั้งแต่ต้น:

สร้าง Minimum Viable Product (MVP) — ตามแนวคิด Lean Startup ของ Eric Ries คือสร้าง version ที่เล็กที่สุดเท่าที่จะเก็บ validated learning เกี่ยวกับผู้ใช้ได้มากที่สุดด้วยความพยายามน้อยที่สุด แล้ววน loop Build–Measure–Learn ซ้ำ ๆ
ทำ backlog refinement อย่างสม่ำเสมอ — ตาม Azure DevOps ของ Microsoft การรักษาความชัดเจนของ user story ที่อยู่หัว backlog ล่วงหน้า 2–3 sprint ช่วยให้ทีมมั่นใจว่ากำลังทำงานที่ตรงกับความต้องการลูกค้าจริง ไม่ใช่แค่ตรงตาม spec ที่เขียนไว้นานแล้ว
ใช้ dual-track agile — แยกงาน discovery (ควรสร้างอะไร และสร้างแบบไหน) ออกจากงาน delivery (สร้างอย่างไรให้มีคุณภาพ) ให้ทำงานคู่ขนานกันตลอดเวลา ไม่ใช่ทำ discovery ครั้งเดียวจบก่อนเริ่ม delivery
จัดลำดับงานด้วย Cost of Delay — เมื่อไม่แน่ใจว่าอะไรคือ “ของถูกต้อง” ให้วัดคุณค่าเชิงเศรษฐศาสตร์ของแต่ละตัวเลือกเทียบกับต้นทุนที่เสียไปหากล่าช้า แทนที่จะเดาใจเอาเอง
ผูก task กับ acceptance criteria ที่มาจากผู้ใช้ ไม่ใช่จากรายละเอียดทางเทคนิคเพียงอย่างเดียว เพื่อให้ทุกคนในทีมเห็นภาพเดียวกันว่า “เสร็จ” หมายถึงอะไรจากมุมมองของคนที่จะใช้งานจริง

ต่อไปนี้คือลำดับความคิดแบบสั้น ๆ ที่ช่วยเช็คตัวเองก่อนเริ่มงานแต่ละชิ้น:

flowchart TD
    Start[เริ่มงานใหม่] --> Ask{รู้หรือไม่ว่าใครใช้และทำไม}
    Ask -->|ไม่รู้| Talk[ไปคุยกับผู้ใช้หรือ product owner]
    Talk --> Ask
    Ask -->|รู้| Build[สร้างส่วนที่เล็กที่สุดที่พิสูจน์ประโยชน์ได้]
    Build --> Ship[ส่งให้ผู้ใช้จริงได้ลองเร็วที่สุด]
    Ship --> Feedback{ตรงกับที่ผู้ใช้ต้องการหรือไม่}
    Feedback -->|ไม่ตรง| Adjust[ปรับทิศทางตอนที่ต้นทุนยังต่ำ]
    Adjust --> Build
    Feedback -->|ตรง| Continue[ทำซ้ำรอบถัดไป]

ตัวอย่าง

สมมติทีมได้รับ requirement คลุมเครือว่า “ทำระบบแจ้งเตือนลูกค้าเมื่อสินค้าใกล้หมด” นักพัฒนาที่ทำงานแบบปิดตาอาจรีบกระโดดไปออกแบบ generic notification engine ที่รองรับทุก channel (email, SMS, push, webhook) พร้อม template engine และ retry policy ที่ซับซ้อน — เพราะมันเป็นโจทย์ที่ท้าทายทางเทคนิค แต่ยังไม่มีใครถามผู้ใช้เลยว่าจริง ๆ แล้วพวกเขาต้องการรู้ล่วงหน้ากี่วัน หรือแค่ต้องการเห็นตัวเลขบนหน้า dashboard ที่เปิดอยู่แล้วทุกวันก็พอ

แนวทางที่สอดคล้องกับ “Know Where You Are Going” คือเริ่มจากคำถามง่าย ๆ ก่อนออกแบบ แล้วปล่อย version เล็กที่สุดที่พิสูจน์คุณค่าได้ก่อน:

// version แรก: ตอบคำถามของผู้ใช้ให้ตรงจุดที่สุดเท่าที่จำเป็น
// ไม่สร้าง abstraction สำหรับ channel ที่ยังไม่มีใครขอใช้
public sealed class LowStockDashboardBadge
{
    private readonly IInventoryReadModel _inventory;

    public LowStockDashboardBadge(IInventoryReadModel inventory)
    {
        _inventory = inventory;
    }

    // แสดงบนหน้า dashboard ที่ลูกค้าเปิดอยู่แล้วทุกวัน
    // เพราะจากการนั่งคุยกับผู้ใช้ พบว่าพวกเขาไม่ได้อยากได้อีเมลเพิ่ม
    public IReadOnlyList<LowStockItem> GetItemsBelowThreshold(StoreId storeId)
    {
        return _inventory
            .GetCurrentStock(storeId)
            .Where(item => item.QuantityOnHand <= item.ReorderThreshold)
            .Select(item => new LowStockItem(item.Sku, item.QuantityOnHand, item.ReorderThreshold))
            .ToList();
    }
}

public sealed record LowStockItem(string Sku, int QuantityOnHand, int ReorderThreshold);

ถ้าหลังจากปล่อย version นี้แล้วผู้ใช้จริงบอกว่าอยากได้แจ้งเตือนผ่านอีเมลด้วยเมื่อไม่ได้เปิด dashboard ทีมจึงค่อยขยาย abstraction ให้รองรับ channel ที่สอง — ต้นทุนของการเปลี่ยนทิศทางตอนนี้ต่ำกว่าการรื้อ generic notification engine ที่สร้างไว้ล่วงหน้าโดยไม่มีใครใช้จริงมาก

ประโยชน์และข้อควรระวัง

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

ข้อควรระวังคือ:

อย่าตีความเป็นข้ออ้างสำหรับ BDUF — เป้าหมายไม่ใช่การวางแผนทุกอย่างให้สมบูรณ์ก่อนเริ่ม แต่คือการมี วิสัยทัศน์รวม (overall vision) ที่ชัดพอจะเริ่มงาน แล้วปรับปรุงต่อเนื่องเมื่อเรียนรู้มากขึ้น
การพบผู้ใช้ต้องมีโครงสร้าง ไม่ใช่แค่คุยเล่น — ถ้าไม่มีคำถามหรือสมมติฐานที่ชัดเจนก่อนไปคุย อาจได้ข้อมูลที่ตีความผิดหรือ noise มากกว่า signal
ระวัง survivorship bias จากผู้ใช้กลุ่มเดียว — ผู้ใช้ที่เข้าถึงง่ายที่สุดอาจไม่ใช่ตัวแทนของฐานผู้ใช้ทั้งหมด
ต้องมีทั้ง Build The Right Thing และ Build The Thing Right — ทีมที่รู้ทิศทางถูกต้องแต่ส่งมอบช้าหรือคุณภาพต่ำ ก็เสียโอกาสในตลาดไม่ต่างจากทีมที่หลงทาง
สมมติฐานตั้งต้นจะผิดเสมอบางส่วน — นี่เป็นเรื่องปกติของกระบวนการเรียนรู้ ไม่ใช่สัญญาณว่าทีมล้มเหลว ตราบใดที่รู้ตัวเร็วและปรับทิศทางได้ทัน

“ในฐานะนักพัฒนา เรามีทางล้มเหลวอยู่สองทาง: เราสร้างของถูกวิธีแต่ผิดตัว หรือเราสร้างของผิดตั้งแต่แรก”

— Steve Smith

Know Where You Are Going

คืออะไร

ทำอย่างไร

ตัวอย่าง

ประโยชน์และข้อควรระวัง

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

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

Know Where You Are Going

คือ​อะไร

ทำ​อย่างไร

ตัวอย่าง

ประโยชน์​และ​ข้อ​ควร​ระวัง

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

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

คืออะไร

ทำอย่างไร

ประโยชน์และข้อควรระวัง

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

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