Waterfall — แบบน้ำตก เดิมพันครั้งเดียว#

ทำทีละขั้น ห้ามข้าม ห้ามย้อน Requirement → Design → Implement → Verify เหมือนการถ่ายทำภาพยนตร์ เขียนบทให้เสร็จ → ถ่ายทำให้จบ → ตัดต่อ → ฉายจริง ถ้าฉายแล้วคนดูไม่ชอบ แก้บทถ่ายใหม่ไม่ได้แล้ว เจ๊งก็เจ๊งเลย

ฟังแล้วเหมือนจะแย่ แต่จริงๆ Waterfall ยังมีที่ใช้อยู่ครับ สำหรับโปรเจ็คที่โจทย์ “นิ่งสนิท” และ “ห้ามพลาดเด็ดขาด” เช่น ซอฟต์แวร์ควบคุมเครื่องบิน ระบบธนาคาร ระบบเครื่องมือแพทย์ ระบบพวกนี้ต้องออกแบบให้จบก่อน พิสูจน์ให้ได้ว่าถูกต้อง แล้วค่อยสร้าง ไม่ใช่ปรุงไปชิมไปได้

แต่ถ้าเป็นแอปขายของ แอปส่งอาหาร หรือ product ที่ต้องสู้ในตลาดที่เปลี่ยนเร็ว Waterfall คือทางลัดสู่ความล้มเหลว

Agile & Scrum — แบบคล่องตัว ปรุงไปชิมไป#

Agile ซอยงานเป็นรอบสั้นๆ เรียกว่า Sprint ปกติรอบละ 2 สัปดาห์ ทำเสร็จรีบให้ลูกค้าดู แล้วปรับปรุงทันที เหมือนร้านอาหาร Omakase เชฟปั้นซูชิให้กินทีละคำ ถามลูกค้าว่า “วาซาบิพอไหมครับ?” ถ้าฉุนไป คำต่อไปเชฟลดทันที ไม่ใช่ทำทั้งคอร์ส 20 คำแล้วค่อยเสิร์ฟรวดเดียว

องค์ประกอบหลักที่เจ้าของกิจการควรรู้จัก:

• Sprint — รอบการทำงาน ปกติ 2 สัปดาห์
• Backlog — รายการสิ่งที่ต้องทำทั้งหมด เหมือนเมนูร้านอาหาร
• Scrum Master — คนคอยเคลียร์อุปสรรคให้ทีม ไม่ใช่หัวหน้าที่สั่งงาน
• Retrospective — ประชุมปิดรอบว่า “รอบหน้าจะทำให้ดีขึ้นยังไง”

ข้อดีคือปรับทิศได้ทุก 2 สัปดาห์ ข้อเสียคือถ้าเจ้าของกิจการไม่ชัดเจน เปลี่ยนใจทุกรอบ ทีมจะเหนื่อยและ product จะไม่มีทิศทาง Agile ไม่ได้แปลว่าไม่มีแผน แต่แปลว่าแผนยืดหยุ่นได้

MVP — Minimum Viable Product#

อันนี้สำคัญที่สุดสำหรับเจ้าของกิจการครับ MVP คือ “สินค้าขั้นต่ำที่วิ่งได้จริง” เพื่อทดสอบตลาดก่อนลงทุนเต็มสูบ

ปัญหาที่เจอบ่อย: อยากสร้าง Super App ใช้เวลา 3 ปี งบ 100 ล้าน ถ้าทำเสร็จแล้วไม่มีคนใช้ = ล้มละลาย ทางออกคือสร้างเวอร์ชันเล็กที่สุดที่ยังตอบโจทย์แก่นได้ แล้วปล่อยออกตลาดเร็วๆ

Analogy ที่ใช้กันทั่วโลกคือ Skateboard → Scooter → Bike → Car แทนที่จะสร้างล้อรถยนต์ (ที่วิ่งไม่ได้) เพื่อจะรอประกอบเป็นรถ ให้สร้างสเก็ตบอร์ดให้ลูกค้าลองไถก่อน ได้ feedback ว่าตลาดมีจริง แล้วค่อยยกระดับ

จุดที่คนเข้าใจผิดบ่อย: MVP ไม่ใช่ “สินค้าห่วย” หรือ “สินค้าบั๊กเยอะ” แต่คือสินค้าที่มีเฉพาะ “แก่น” จริงๆ ตัดน้ำจิ้มออกหมด ตัวที่เหลือต้องทำงานได้ดี แค่ feature น้อยเท่านั้น

Scope Control — คุมขอบเขตไม่ให้งอก#

Scope Creep คือฆาตกรโปรเจ็คอันดับหนึ่ง ลูกค้าหรือแม้แต่ตัวเจ้าของเองขอเพิ่มฟีเจอร์นิดๆ หน่อยๆ ทุกสัปดาห์ พอครบปีโปรเจ็คบานไปสามเท่า เสร็จช้ากว่ากำหนดเท่าตัว

เครื่องมือที่ใช้คุมคือ MoSCoW Method:

• Must have — ของต้องมี ไม่มีคือพัง
• Should have — ควรมี แต่รอรอบหน้าได้
• Could have — มีก็ดี ถ้าเวลาเหลือ
• Won’t have — ไม่ทำตอนนี้ จบ

ผมแนะนำว่าทุกครั้งที่มี feature ใหม่โผล่มากลางโปรเจ็ค ให้ถามตัวเองสามคำถาม: จำเป็นต่อการ launch ไหม? ยอมเลื่อน launch เพื่อสิ่งนี้ไหม? ยอมตัดอะไรเพื่อใส่สิ่งนี้ไหม? ถ้าตอบไม่ได้ชัด ใส่ Won’t have ไว้ก่อน

1. Idea Validation — เช็คโจทย์#

ปัญหาคลาสสิก: สร้างสิ่งที่ “เราอยากได้” แต่ “ลูกค้าไม่อยากได้” เครื่องมือที่ใช้เช็ค:

• User Stories — เขียนความต้องการในรูปแบบ “As a [user], I want [feature], so that [benefit]” เช่น “ในฐานะลูกค้า ผมอยากดูสถานะออเดอร์ได้ตลอดเวลา เพื่อจะได้ไม่ต้องโทรถาม”
• Stakeholder Interviews — คุยกับคนที่จะใช้จริง ไม่ใช่แค่คนจ่ายเงิน
• Feasibility Analysis — เช็คว่าทำได้จริงไหม แพงเกินไปไหม ใช้เวลากี่เดือน

ถ้าข้ามช่วงนี้ไปรีบเขียนโค้ดเลย มีสิทธิ์สร้างของที่ไม่มีคนอยากได้สูงมาก

2. Design Phase — เขียนแบบ#

• Wireframing — ภาพร่างลายเส้น เหมือนแปลนบ้าน 2D เน้นดูโครงสร้าง
• UI/UX Design — ลงสี ใส่รูป เหมือนภาพ render 3D ใช้เครื่องมือเช่น Figma
• Architecture Planning — วางผังระบบ ใช้ UML หรือแผนผังง่ายๆ ก็ได้
• Database Schema — ออกแบบผังข้อมูลและความสัมพันธ์

กฎทองของ design phase ที่เจ้าของกิจการต้องจำ: แก้บน “กระดาษ” ใช้เงิน 10 บาท แก้ตอน “เขียนโค้ด” ใช้เงิน 1,000 บาท แก้ตอน “ของเสร็จแล้ว” ใช้เงิน 100,000 บาท ให้เวลากับ design เยอะๆ อย่ารีบ

3. Development Phase — ก่อสร้าง#

• Environment Setup — เตรียมเครื่องมือและ config ทั้งหลาย (Docker, Git, config files)
• Coding Frontend/Backend — เริ่มก่ออิฐฉาบปูนตามแบบ
• Integration — เชื่อมหน้าบ้านเข้ากับหลังบ้าน เหมือนเดินสายไฟเข้าสวิตช์

ช่วงนี้เจ้าของกิจการไม่ต้องเข้าไปยุ่งทุกวัน แต่ต้องมี check-in ทุก 2 สัปดาห์ (end of sprint) เพื่อดูของและปรับทิศ

4. Testing & Launch — ตรวจสอบและส่งมอบ#

• QA (Quality Assurance) — ทีมล่าบั๊กอย่างเป็นระบบ (ผมคุยเรื่องนี้ไว้แล้วใน EP.07)
• Beta Testing — เปิดให้ลูกค้ากลุ่มแรก (friendly users) ลองใช้ก่อน เก็บ feedback
• Production Deployment — วันดีเดย์ ปล่อยของจริง ผ่าน staging → production
• Post-Launch Monitoring — ติดตาม uptime, error rate, user behavior

พลาดบ่อย: เจ้าของกิจการชอบข้าม beta test เพราะรีบ launch ผลคือปล่อยแล้วเจอบั๊กแรงๆ หน้าลูกค้าทั่วไป ภาพลักษณ์เสียทันที

Tech Stack Selection — เลือกวัสดุก่อสร้าง#

การเลือกภาษาโปรแกรม framework และ database ส่งผลกับธุรกิจระยะยาวมาก ใช้ Evaluation Matrix ให้คะแนนตามหัวข้อ:

• Cost — ค่า license, ค่า cloud, ค่าคน
• Scalability — รองรับโตถึงขั้นไหน
• Talent — หาคนทำงานง่ายไหม ชุมชนใหญ่ไหม
• Vendor Lock-in — ถ้าอยากย้ายภายหลัง ย้ายได้ไหม
• Long-term Maintenance — 5 ปีข้างหน้ายังมีคนดูแลอยู่ไหม

อย่าเลือกเพราะ “เทคโนโลยีใหม่เท่ห์ดี” ให้เลือกเพราะเหมาะกับโจทย์ธุรกิจจริง

Tracking Software — Jira/Trello/Linear#

กระดานติดตามงานดิจิทัล ให้ทุกคนเห็นว่าใครทำอะไรอยู่ ติดตรงไหน โดยไม่ต้องเรียกประชุมบ่อย แนวคิดหลัก:

• Kanban Board — คอลัมน์ To-Do / In-Progress / Review / Done
• Epics — งานก้อนใหญ่ที่กินหลาย sprint
• Tasks — งานย่อยในแต่ละ sprint

Version Control & Code Review — Git#

ในมุมเทคนิค Git คือระบบเก็บประวัติการแก้โค้ด แต่ในมุมบริหาร Git คือเครื่องมือ Risk Management ที่สำคัญมาก

• ย้อนกลับได้ถ้างานพัง (rollback)
• Pull Request/Code Review — บังคับให้พนักงานตรวจงานเพื่อนก่อน merge เป็นระบบ quality control อัตโนมัติ
• Linters — โปรแกรมตรวจไวยากรณ์โค้ด ช่วยจับ error ก่อนคน

ถ้าทีม dev ของเจ้าของกิจการยังไม่ใช้ Git หรือไม่มีระบบ code review ให้รีบคุยเรื่องนี้ก่อนเรื่องอื่นเลย

Full Cycle#

1. Validate — เช็คโจทย์ด้วย MVP และ User Stories
2. Plan — เลือก Agile หรือ Waterfall ตามลักษณะโจทย์
3. Design — วาดแบบให้จบก่อนสร้าง
4. Build — เขียนโค้ดและเชื่อมต่อระบบ
5. Launch — เทสให้ดี (QA/Beta) แล้วค่อยปล่อยจริง
6. Monitor — ติดตามผลและปรับปรุงต่อเนื่อง

Management Takeaway ที่ต้องจำ#

• Fail Fast, Learn Faster — อย่ากลัวล้มเหลว แต่ให้ล้มด้วย MVP (เจ็บตัวน้อย) แล้วรีบเรียนรู้ ดีกว่าล้มตอนปล่อย product เต็มที่แล้ว
• Scope Creep Kills Projects — ใจแข็งเข้าไว้ ถ้าลูกค้า (หรือตัวเอง) ขอเพิ่มงาน ต้องแลกด้วยการตัดงานอื่นออก หรือเพิ่มเวลา/เงิน นี่คือกฎ Iron Triangle ระหว่าง Scope / Time / Cost เลือกได้แค่สองอย่างเสมอ
• Software is a Living Organism — ซอฟต์แวร์ไม่ใช่สิ่งก่อสร้างที่สร้างเสร็จแล้วจบ มันคือสิ่งมีชีวิตที่ต้องกินอาหาร (data) ต้องเติบโต (scale) และต้องมีภูมิคุ้มกัน (security) ปล่อย launch แล้วคือเพิ่งเริ่มต้น ไม่ใช่จบ