กับดัก Engineer EP.3: Done is better than Perfect... จงกล้าที่จะปล่อย Bug ลง Production

"ปุ่ม Deploy สีเขียวๆ นั้น... ทำไมกดแล้วมือมันสั่นจังครับ?"

ถ้าคุณเป็น Developer ที่ใส่ใจคุณภาพ (แบบที่ผมเป็น) การกด Deploy เอา Code ขึ้น Production ทั้งที่รู้ว่า *"ตรงนั้นยังไม่เนียน"* หรือ *"ตรงนี้ยังไม่ได้เขียน Test"* มันคือฝันร้ายชัดๆ เรามักจะมีเสียงในหัวบอกว่า:

*"ขอ Refactor ฟังก์ชันนี้อีกนิด"*

*"UI ตรงนี้ Padding เบี้ยวไป 2px"*

*"ระบบยังไม่รองรับ Concurrent 10,000 คนเลย (ทั้งที่ตอนนี้มี User 0 คน)"*

อาการนี้เรียกว่า "Just One More Fix Syndrome" ครับ และมันคือตัวการสำคัญที่ทำให้ Startup หรือโปรเจกต์ดีๆ "เจ๊งตั้งแต่ยังไม่เริ่ม"

ใน EP สุดท้ายของ Series นี้ ผมจะมาแชร์จุดเปลี่ยนที่ทำให้ผมกล้าปล่อย Duechat และ JongQ ออกสู่ตลาด ทั้งที่มันยังห่างไกลจากคำว่า Perfect ไปมาก

MVP ไม่ใช่ "งานเผา" แต่คือ "หัวใจ"

Dev หลายคน (รวมถึงผมในอดีต) เข้าใจผิดว่า MVP (Minimum Viable Product) คือการทำของห่วยๆ กากๆ ออกมาให้คนด่า... ซึ่งผิดถนัด

MVP คือการตัด "ไขมัน" ออก ให้เหลือแต่ "กล้ามเนื้อ" ที่จำเป็น

Wrong MVP: รถยนต์ที่มีล้อเดียว วิ่งไม่ได้ (ลูกค้าด่า)

Right MVP: สเก็ตบอร์ด (วิ่งได้ ถึงที่หมายได้ แม้จะไม่มีแอร์และหลังคา)

ตอนทำระบบจองคิว JongQ แรกๆ ผมอยากทำระบบ Notification ผ่าน LINE, SMS, Email และมี Dashboard กราฟ 3D สวยๆ แต่ถ้าทำหมดนั้น คงใช้เวลา 3 เดือน... ผมเลยตัดทุกอย่างทิ้ง เหลือแค่:

ลูกค้ากดจองได้

ร้านค้าเห็นชื่อคนจอง

แค่นั้นครับ ระบบแจ้งเตือนใช้ "ตะโกนบอก" เอาหน้างาน... ฟังดูตลก แต่มันทำให้ผมเปิดระบบให้ร้านใช้ได้ภายใน 1 อาทิตย์ และเริ่มเก็บ Feedback ได้ทันที

ยอมรับเถอะว่า "Bug" คือส่วนหนึ่งของชีวิต

สำหรับ Performance Freak อย่างผม การเห็น Error Log คือความพ่ายแพ้ แต่ในโลกธุรกิจ "ไม่มีใครแคร์ Code ของคุณเท่าตัวคุณเอง"

ลูกค้าส่วนใหญ่ยอมรับได้ครับถ้าเจอบั๊กเล็กๆ น้อยๆ ตราบใดที่ "Core Value" หรือสิ่งที่เขาได้รับมันคุ้มค่า

ถ้าแอพจองคิวล่ม 5 นาที แต่ช่วยให้เขาไม่ต้องยืนตากแดดรอ 2 ชั่วโมง... เขารอได้

แต่ถ้าแอพเขียนโค้ดมาเทพมาก ไม่ล่มเลย แต่ใช้งานยากจนจองไม่ได้... อันนี้จบ

ผมต้อง Unlearn เรื่อง Zero Bug Policy แล้วเปลี่ยนเป็น "Fast Fix Policy" แทน คือไม่ต้องกลัวบั๊กหลุด แต่ถ้าหลุดแล้วต้องแก้ให้ไว (Hotfix) นั่นคือสิ่งที่ลูกค้าต้องการมากกว่าความสมบูรณ์แบบที่จับต้องไม่ได้

กฎ 80/20 ของความสมบูรณ์แบบ

ในการทำ Software:

80% ของ Value มาจาก 20% ของ Features

แต่เรามักเสียเวลา 80% ไปกับการขัดเกลา 20% สุดท้าย ให้มัน Perfect

ตอนที่ผมทำ Duechat ผมเสียเวลาไปกับการจูน Performance ของ Database นานมาก เพื่อให้ Query เร็วระดับ Millisecond... ทั้งที่ตอนนั้นมีลูกค้าแค่ 5 เจ้า พอมองย้อนกลับไป เวลาตรงนั้นเอาไปทำฟีเจอร์ "แนบสลิปโอนเงิน" ยังจะมีประโยชน์กับลูกค้ามากกว่า

ดังนั้น ถ้า Code มันทำงานได้, Security ไม่รั่ว, และแก้ปัญหาลูกค้าได้... Ship it! ปล่อยมันออกไปครับ

บทสรุป Series: จาก Coder สู่ Creator

ตลอด 3 EP ที่ผ่านมา ผมเล่าถึงการเปลี่ยนแปลงจาก Engineer ที่มองแค่ Code มาเป็นคนที่มอง Business

EP.1: เลิก Over-Engineer (ทำเท่าที่จำเป็น)

EP.2: เลิกเก็บตัว (ออกไปขาย)

EP.3: เลิกกลัวไม่ Perfect (ปล่อยของเพื่อเรียนรู้)

ไม่ได้แปลว่าผมทิ้งจิตวิญญาณความเป็น Software Engineer นะครับ ผมยังรัก Next.js, ยังบ้าคลั่งความเร็วของ Bun, และยังเขียน Dockerfile ด้วยความประณีตเหมือนเดิม

เพียงแต่ตอนนี้ผมรู้แล้วว่า "เทคโนโลยีเป็นแค่พาหนะ (Vehicle)" ที่จะพาเราและลูกค้าไปถึงเป้าหมาย ไม่ใช่ "จุดหมายปลายทาง (Destination)" ในตัวมันเอง

ถ้าคุณมีโปรเจกต์ที่ดองไว้ในเครื่อง มีไอเดียที่ยังไม่กล้าปล่อย... คืนนี้กลับไปกด Deploy เถอะครับ โลกกำลังรอดูของดีจากคุณอยู่

const projectStatus = {
  codeQuality: "Good Enough",
  features: "Core Only",
  userFeedback: "Waiting...",
  deploy: true // Just do it!
};

if (projectStatus.deploy) {
  console.log("Welcome to the real world.");
}