ทำงานให้สนุกขึ้น ด้วยการแบ่งงานตาม Value ไม่ได้แบ่งตาม Tech Stack

ช่วงนี้ทำงานเป็นตัวกลางระหว่าง UX, Business และ Dev บ่อยมากขึ้นเลยอยากยกเรื่องการแบ่งงานขึ้นมาเล่า โดยเฉพาะในยุคนี้การแบ่งงานแบบตาม Value มันยิ่งสะดวกขึ้นไปอีก

อยากเริ่มต้นจากตัวอย่างที่คุ้นเคย พวกเราหลายคนจะเจอเหตุการณ์แบบนี้ใน Daily Scrum โดยเฉพาะวันสุดท้ายที่ทุกคนบอกว่า “งานเสร็จแล้ว”

• Frontend บอก: “หน้า UI เสร็จแล้วครับพี่ สวยกริบ” ✨
• Backend บอก: “API ยิงได้แล้วครับ Deploy ขึ้น Dev แล้ว”
• Database บอก: “Table structure เตรียมไว้รองรับ Scale แล้วครับ”

แต่พอ PO เราจะลองเล่นดูจริงๆ กลับพบว่า… “มันยังใช้งานไม่ได้จริง”

ส่วนที่ไม่ได้ทีม Frontend อาจบอกว่าหน้าจอเสร็จแล้ว แต่รอ API หรือทีม API ก็ทำเส้นเสร็จแล้วแต่ UI เปลี่ยนก็เลยแก้ไม่ทัน หรือ Database บอกว่าเสร็จแล้ว แต่ต้องเขียน Store procedure เพิ่มเพราะโครงสร้าง DB ไม่ตรงกับสิ่งที่หน้าบ้านแสดงผล และข้ออ้างอีกมากมาย

สรุปคือ “Task เสร็จ (Done)” แต่ “ของยังใช้ไม่ได้ (Zero Value)”

การทำงานแบบนี้มักจะทำให้เราเครียดช่วงท้าย เพราะต้องมานั่งแก้บั๊กตอนรวมร่าง (Integration) แถมยังไม่เห็นผลงานที่เป็นชิ้นเป็นอันสักที

วันนี้ผมเลยอยากชวนเปลี่ยนวิธีคิดครับ ลองเลิกแบ่งงานตามความถนัด (Tech Stack) แล้วมาแบ่งตาม “คุณค่าที่ส่งมอบ” (Value) กันดูครับ

กับดักของการทำ Horizontal Slicing 🧑‍🔧 🧑‍💼 🧑‍🎨

สมมติเราจะทำฟีเจอร์ “ลูกค้าสั่งซื้ออาหารหมา” ให้กับเว็บขายอาหารสัตว์ 🐶

ถ้าเราแบ่งงานแบบเดิม (Horizontal) เรามักจะแบ่งงานกันแบบนี้ครับ:

• UI Layer: สร้างหน้าจอรายการสินค้า, ตะกร้าสินค้า, หน้า Checkout (ทำแต่หน้าบ้าน รอข้อมูล)
• Logic/API Layer: เขียน API รับออเดอร์, คำนวณราคา, ตัดสต็อก (เขียนแต่โค้ด รอต่อหน้าบ้าน)
• Data Layer: ออกแบบตาราง Users, Orders, Products, Payments (เตรียมถังเก็บข้อมูล)

ผ่านไป 1 สัปดาห์ ทุกคนทำงานหนักมาก แต่เราจะยังไม่มี “ร้านค้า” ให้ลูกค้ากดซื้อเลยแม้แต่ชิ้นเดียว ของที่เสร็จในแต่ละเลเยอร์มันยังแยกขาดจากกัน หรือของที่แต่ละทีมเสร็จมันไม่ใช่ของที่อีกทีมนึงต้องการ

ถ้าจะแก้ปัญหานี้ก็ต้องให้แต่ละทีมคุยกันก่อน แต่เนื่องจากเค้าอยู่คนละทีม Overhead ในการคุยกันมันก็สูงขึ้น การเปลี่ยนแปลงที่เกิดขึ้นก็จะไม่ได้สื่อสารไปยังอีกทีม หรือเลวร้ายกว่านั้นคือแต่ละทีมไม่กล้าแก้ให้มันดีขึ้น เพราะกลัวว่าอีกทีมนึงจะทำไปแล้ว หรือกลัวว่าจะส่งต่อข้อมูลกันไม่ได้

แล้วถ้าเปลี่ยนเป็น Vertical Slicing ล่ะ 🍰

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

วิธีการคือ เราจะ “Slide” งานจากบนลงล่าง ลากผ่านตั้งแต่ UI -> Business Logic -> Database ให้ครบจบเป็นหนึ่งเรื่อง (One Story)

ด้านขวาคือการแบ่งงานแบบ Vertical ที่เจาะทะลุทุก Layer เพื่อให้ได้ของที่ใช้งานได้ 1 ชิ้น ส่วนด้านซ้ายคือแบบ Horizontal ที่ทำทีละชั้นจะให้ใช้งานได้ต้องคุยข้ามทีมให้ดี

ลองมาดูกันครับว่า ถ้าเรา Slice งานเว็บขายอาหารสัตว์แบบ Vertical หน้าตามันจะเป็นยังไง:

🥖 Slice ที่ 1: “แสดงรายการอาหารหมา” (Show Product)

• Goal: ลูกค้าเห็นสินค้าและราคา (ยังซื้อไม่ได้ ไม่เป็นไร)
• สิ่งที่ต้องทำ (ในงานชิ้นเดียว):
  • (UI) สร้าง Card ง่ายๆ แสดงรูปถุงอาหาร + ราคา
  • (Logic) สร้าง API GET /products ดึงข้อมูล
  • (DB) สร้างตาราง Products แล้วใส่ข้อมูลจริงลงไป
• ผลลัพธ์: จบ Slice นี้ หน้าเว็บขึ้นโชว์สินค้าจริงทันที! ลูกค้าเห็นของแล้ว (Value เกิดแล้ว 1 อย่าง)

🥖 Slice ที่ 2: “กดสั่งซื้อแบบ Guest” (Buy Now)

• Goal: ลูกค้ากดปุ่มแล้วออเดอร์ถูกบันทึก (ยังไม่ต้องมีตะกร้าซับซ้อน เอาแค่ซื้อทีละชิ้น)
• สิ่งที่ต้องทำ (ในงานชิ้นเดียว):
  • (UI) เพิ่มปุ่ม “Buy Now” บนการ์ดสินค้า
  • (Logic) รับ request แล้วคำนวณราคาง่ายๆ
  • (DB) สร้างตาราง Orders บันทึกว่ามีการซื้อเกิดขึ้น
• ผลลัพธ์: จบ Slice นี้ ลูกค้ากดซื้อได้จริง! ร้านขายของได้แล้ว! 💰

ภาพที่ออกมาจะทำให้ทีมสนใจที่ ผลลัพธ์ หรือ Value ของงานมากกว่าสิ่งที่ต้องทำ เพราะเราไม่ได้วัดที่งานเสร็จ แต่วัดกันที่ผลลัพธ์ได้แล้ว การทำแบบนี้ทำให้เรามี “Working Software” ในทุกๆ สเต็ปที่เดินไปข้างหน้า

---

แต่ผมเป็น Frontend จะให้ไปทำ DB ผมไม่ถนัดนะ 😨

ความกลัวนี้เป็นเรื่องปกติมากครับ เพราะเมื่อก่อนเราถูกสอนให้เป็น Specialist (รู้ลึกเรื่องเดียว) เพื่อความรวดเร็ว และก่อนหน้านี้เราก็ยังเรียก Cross Functional Team ซึ่งแปลว่าทีมนึงมีหลายหน้าที่ เราก็อาจจะเบาใจว่าไม่ต้องไปรู้เรื่องที่ไกลตัวมากก็ได้

แต่ในยุคนี้ โลกเปลี่ยนไปแล้วครับ 🌍

• ทีมเล็กลง: ยิ่งทีมมีขนาดเล็ก การสื่อสารก็ทำได้คล่องตัวมากขึ้น งานหั่นชิ้นเล็กลง เห็น value ได้ง่าย และปรับเปลี่ยน โยกย้ายได้ง่าย และทำให้เราต้องเข้าใจกว้างขึ้นด้วย
• AI คือตัวช่วย: การข้าม Stack ไม่ใช่เรื่องยากเหมือนเมื่อก่อน ถ้าเราแม่น Logic ฝั่ง Frontend แต่เขียน SQL ไม่คล่อง เราสามารถให้ AI ช่วยสอน Query หรือ API ให้ได้ (แต่เราต้องเข้าใจของที่เขียนลงไปนะครับ!!! และเข้าใจได้สะดวกขึ้นมากๆ แล้ว)
• โฟกัสที่ Value: หน้าที่ของเราไม่ใช่ “คนเขียน React” หรือ “คนเขียน Go” แต่เราคือ “คนสร้างเว็บที่ขายอาหารสัตว์”
• สนุกกว่าเดิม: เชื่อผมเถอะครับ ความรู้สึกตอนที่เห็นงานของเรา “Run ได้จริง” ตั้งแต่หน้าบ้านยันหลังบ้าน ด้วยมือเรา (หรือทีมเราที่นั่งติดกัน) มันฟินกว่าการทำเสร็จแค่ส่วนเดียวเยอะเลย

---

ถ้าเราเป็น PM จะเริ่มต้นยังไงดี? 💡

ลองเริ่มจากฟีเจอร์เล็กๆ ถัดไปที่จะทำดูครับ

1. มองให้ออกว่า “อะไรคือสิ่งที่เล็กที่สุดที่ทำแล้ว User ใช้งานได้จริง?”
2. ซอยงานให้บาง (Thin Slicing) เล็กขนาดที่ทำให้เสร็จได้ใน 1–4 วัน
3. อย่ากลัวที่จะให้ Dev กระโดดข้าม Layer เพื่อทำให้งานชิ้นนั้นสมบูรณ์
4. คุยกับ HR ว่าเราจะเปลี่ยน Job Description แล้ว อาจจะมีคนที่ไม่อยากไปต่อ

พอเราเริ่มส่งมอบ “คุณค่า” ได้ถี่ขึ้น Feedback ก็จะมาไวขึ้น เราจะรู้ตัวเร็ว แก้ไขเร็ว และที่สำคัญ… เราจะทำงานสนุกขึ้นเพราะเห็นผลงานตัวเองใช้งานได้จริงตลอดเวลาครับ

---

ถ้ารู้สึกว่าอยากลองเปลี่ยนวิธีหั่นงานกันดูนะครับ! แนะนำว่าให้ลองเลยครับ ช่วงแรกงานอาจจะออกช้ากว่าเดิม เพราะทีมยังไม่ชินและมีของให้ต้องเรียนรู้เยอะมาก ก็อาจจะวางพี่ๆ ที่เชี่ยวชาญในแต่ละเรื่องเอาไว้สอนครับ

แต่ผมเชื่อว่าพอทีมคุ้นกับแบบนี้ ตัว PM เองจะสลับงานได้สนุกมากขึ้น อะไรที่มีคุณค่ากับบริษัทก็ใส่ทีมลงไปตรงนั้นได้เลย ไม่ต้องคอยห่วงว่า “ตอนนี้งานแน่นที่ Backend ทีม Frontend เลยว่าง ก็ให้ทำของอื่นๆ ไปก่อน”

ถ้าแบ่งแบบใหม่เราจะให้ทุกคนได้ทำของที่มีคุณค่าสูงสุดกับบริษัทอยู่เสมอ งานมันจะสนุกขึ้นจริงๆ

ลองดูนะครับ 👍