เมื่อ "ตำแหน่ง" ไม่สำคัญเท่า "สิ่งที่เราส่งมอบ" - Role Expectation

หลังจากที่เขียนบทความเรื่อง Vertical Slicing ไปเมื่อคราวก่อน (ใครยังไม่ได้อ่าน ลองแวะไปอ่านกันก่อนได้นะครับ จะได้เห็นภาพเดียวกัน) มีเพื่อนๆ พี่ๆ น้องๆ ทักเข้ามาแลกเปลี่ยนความเห็นกันหลายคน ขอบคุณทุกคอมเมนต์เลยนะครับ ช่วยกระตุ้นความคิดได้มาก 😊

มีประเด็นหนึ่งที่น่าสนใจ และผมเชื่อว่าเป็นสิ่งที่หลายคนสงสัย คือพอเราบอกว่าจะหั่นงานแนวตั้ง ทำฟีเจอร์หนึ่งให้จบตั้งแต่หน้าบ้านยันหลังบ้าน…

คำถามที่ตามมาคือ “แล้วใครจะทำได้!! ต้องเก่งเทพทำได้ทุกอย่างเลยเหรอ?”

มีพี่คนหนึ่งทักมาถามว่า

“ที่บอกให้ส่งมอบ Value ให้ได้ทั้งชิ้น แปลว่าต้องเขียน Front-end ให้สวย แล้วต้องไป Design Database ให้ Scalable แถมต้องทำ Config Server เองเป็นด้วยเหรอ? ศาสตร์แต่ละด้านมันลึกมากนะ จะให้คนคนเดียวรู้ลึกรู้จริงทุกเรื่อง มันเป็นไปไม่ได้หรอก”

ผมอ่านแล้วก็เห็นด้วย… “จริงครับ!!”

ถ้าเราคาดหวังความรู้ระดับ Expert ในทุกเรื่องจากคนคนเดียว นั่นคือสิ่งที่เป็นไปได้ยาก โดยเฉพาะน้องใหม่ มนุษย์เรามีเวลาจำกัด

แต่อย่าเพิ่งด่วนสรุปว่า “งั้น Vertical Slicing ก็ทำไม่ได้จริงสิ”

อยากให้ลองวิเคราะห์เรื่องนี้โดยแบ่งเป็น 3 ประเด็น คือ “ความเก่ง”, “ตำแหน่ง” และ “ต้นทุน”

1. กับดักคำว่า “ความเก่ง” ระหว่าง ขั้นเทพ vs ขั้นผ่าน (Mastery vs. Competence)

คำถามคือ… เพื่อที่จะส่งมอบฟีเจอร์หนึ่งฟีเจอร์ให้ลูกค้าใช้งานได้ (Deliver Value) เราจำเป็นต้องใช้ความรู้ระดับ “เทพเจ้า” (Mastery) ในทุกเลเยอร์จริงๆ เหรอ?

ลองมองดูงานที่เราทำกันจริงๆ ในแต่ละวันครับ:

80% ของงาน คือการดึงข้อมูลมาแสดงผล, รับค่าจาก User, บันทึกลง Database, และตรวจสอบเงื่อนไขทางธุรกิจ (CRUD)
20% ของงาน คือการจูน Performance รับคนล้านคน, การทำ Micro Animation ระดับเอาถ้วย Awwwards, หรือการวาง Architecture ที่ซับซ้อน

ตรง 80% นี่แหละครับ คือจุดที่ผมบอกว่า “ไม่ต้องเก่งเทพ ก็ส่งมอบ Value ได้”

เราไม่ได้ต้องการคนที่เป็น Master ในทุกเรื่อง แต่เราต้องการคนที่มี “ความสามารถในการทำให้ใช้งานได้” (Functional Competence) ในเรื่องที่จำเป็นครับ

คุณอาจจะเป็น Back-end ที่เขียน CSS ไม่เก่งเลย แต่คุณพอจะรู้ว่าใช้ Flexbox จัดหน้ายังไงให้ปุ่มมันไม่เบี้ยว พอให้ลูกค้ากดได้ (Value Delivered)
คุณอาจจะเป็น Front-end ที่ไม่แม่นเรื่อง SQL แต่คุณพอจะเขียน “SELECT * FROM ..” ง่ายๆ เพื่อดึงข้อมูลมาโชว์หน้าจอได้ โดยไม่ต้องรอเพื่อน (Value Delivered)

งานมันอาจจะไม่ใช่โค้ดที่สวยที่สุด (Perfect Code) แต่มันคือโค้ดที่ “ส่งมอบคุณค่าให้ลูกค้าได้จริง” 👍

และเมื่อถึงวันที่เราต้องเจอกับงานระดับ 20% ที่ยากและลึกซึ้งจริงๆ วันนั้นแหละครับที่เราค่อยหันไปขอความช่วยเหลือจากผู้เชี่ยวชาญเฉพาะด้าน (Specialist) หรือตอนทำ Code Review หรือจะตอนที่ Review PR ก็ได้ ถึงตอนนั้นมือใหม่ก็จะเก่งเทพขึ้นเรื่อยๆ

2. กับดักของ “ตำแหน่ง” ระหว่าง หน้าที่ กับความคาดหวัง (Role & Responsibility vs Role Expectations)

ทีนี้ ถ้าความเก่งไม่ใช่ปัญหาหลัก แล้วทำไมเราถึงไม่ค่อยกล้าข้ามสายไปช่วยกันทำ? สาเหตุหนึ่งคือเราโดนตั้งชื่อไปแล้ว เช่น คุณเป็น Front End คุณเป็น Back End พอเราโดนตั้งชื่อด้วย “ตำแหน่ง” (Title) ครับ เราก็จะเชื่อว่าเราต้องทำสิ่งนั้น และถ้าเราอยากได้คนที่ทำได้ทั้งหน้าบ้านและหลังบ้าน เราก็จะตั้งชื่อตำแหน่งให้ว่า “Full Stack” ไม่งั้นเราหรือเค้าก็อาจจะไม่สบายใจ เพราะจะวาง Role & Responsibility ไม่ได้

ปัญหาคือตำแหน่ง “Full Stack” มันก็ไม่ได้ตรง เพราะมันเป็นการบอกสิ่งที่ต้องทำให้ได้ ไม่ใช่สิ่งที่ต้องส่งมอบ

แต่อยากชวนลองวางการตั้งชื่อตำแหน่งลงก่อน แต่ให้เรามองด้วยความคาดหวังแทนว่าเค้าต้องส่งมอบอะไร (Expectation) เพราะ 2 คำนี้มีความหมายโดยนัยที่ต่างกันมากครับ โดยเฉพาะในบริบทของ Classic HR:

Responsibility (ความรับผิดชอบ) -> เน้นที่ “ทำอะไร” (Activity)
Expectation (ความคาดหวัง) -> เน้นที่ “ส่งมอบอะไร” (Outcome)

Responsibility คือการ “ทำตามหน้าที่”

ในโลกของการทำงานแบบดั้งเดิม เรามักจะถูกสอนให้โฟกัสที่ Responsibility ซึ่งมักจะถูกตีความออกมาเป็น Checklist ของสิ่งที่ต้องทำ

Front-end Dev: “ความรับผิดชอบของผมคือ รับ API มาแสดงผล ทำให้ตรง Design System… (etc.) จบแค่นี้”
Back-end Dev: “ความรับผิดชอบของผมคือ เตรียม API ให้ถูกต้องตาม Spec ส่ง JSON ออกไป… (etc.) จบแค่นี้”

พอมันเป็น “หน้าที่” (Activity) เมื่อเรา ทำ ส่วนของเราเสร็จ เราก็มักจะรู้สึกว่า “จบงานของฉันแล้วนะ” ที่เหลือถ้ามันยังใช้งานไม่ได้ หรือ User ยังงงอยู่… ก็อาจจะไม่ใช่เรื่องของฉันแล้ว เพราะฉันรับผิดชอบส่วนของฉันครบถ้วนแล้ว

เห็นปัญหาไหมครับ? งานเสร็จตามหน้าที่ แต่ของไม่ถึงมือลูกค้า (งานเสร็จจริง vs ใช้ได้จริง) 😅

Expectation คือการ “ส่งมอบคุณค่า”

ถ้าเราเปลี่ยนโจทย์ใหม่ เลิกสนว่าเขาชื่อตำแหน่งอะไร หรือต้อง ทำ ท่าไหน แต่ตั้ง Role Expectations แทน:

แทนที่จะบอก Responsibility: “คุณมีหน้าที่เขียน API ให้เสร็จ” (สั่งให้ทำอะไร)

ลองเปลี่ยนเป็น Expectation: “เราคาดหวังให้คุณทำให้ User กดสั่งซื้อของได้สำเร็จ โดยข้อมูลต้องถูกต้อง” (คาดหวังให้ส่งมอบอะไร)

พอเป้าหมายอยู่ที่ “ส่งมอบอะไร” วิธีคิดจะเปลี่ยนทันทีครับ

คุณจะไม่สนใจแล้วว่านี่คืองาน Front หรือ Back หรือชื่อตำแหน่งคุณคืออะไร แต่คุณจะสนใจว่า “ทำยังไงให้มันเวิร์ก”

ถ้าติดที่ Database คุณจะกล้า Google เพื่อทำความเข้าใจ ORM
ถ้าติดที่ UI คุณจะกล้าลองศึกษา Tailwind หรือ design system ดู

คุณไม่จำเป็นต้องเป็น Full Stack ที่รู้ทุกอย่าง แต่คุณต้องเป็น “Value Deliverer” ที่ไม่ยอมให้เส้นแบ่งทางเทคนิค หรือชื่อตำแหน่ง มาขวางกั้นการส่งมอบงาน แล้วถ้าไม่แน่ใจก็แค่ขอความช่วยเหลือ และคอยช่วยเหลือคนอื่นในทีม จะช่วยผ่านการร้องขอ หรือช่วยผ่าน Code Review หรือช่วยผ่าน Comment PR ก็ได้ครับ

3. ต้นทุนที่สูงกว่าการเรียนรู้เทคโนโลยี คือ การเข้าใจ Business Context

Role and Expectation

อีกประเด็นที่ผมอยากพูดถึง และคิดว่าเป็นเหตุผลที่สำคัญมากๆ ที่ทำให้ Vertical Slicing คุ้มค่ามากกว่าที่คิด นั่นคือ…

ค่าใช้จ่ายที่แท้จริงของการพัฒนาซอฟต์แวร์ ไม่ได้อยู่ที่การเรียนรู้เทคนิค แต่อยู่ที่การเข้าใจบริบททางธุรกิจ (Business Context)

ลองคิดดูนะครับ:

เรียน React ใหม่ อาจจะใช้เวลา 2-3 สัปดาห์ก็เริ่มงานได้
เรียน SQL ใหม่ อาจจะใช้เวลาสัปดาห์เดียว-สองสัปดาห์ ก็เขียน Query พื้นฐานได้
แต่การเข้าใจว่า “ทำไมลูกค้าถึงต้องการฟีเจอร์นี้” “มันแก้ปัญหาอะไรให้เขา” หรือ “ทำไมถึงต้องทำแบบนี้ไม่ใช่แบบนั้น” นี่อาจจะใช้เวลาหลายเดือน หรือหลายปีกว่าจะเข้าใจลึกซึ้งจริงๆ

เวลาที่เราแบ่งงานแบบ Horizontal (แบ่งตาม Tech Stack) สิ่งที่เกิดขึ้นคือ:

Front-end Dev จะเห็นแค่หน้าจอและปุ่ม แต่ไม่รู้ว่าข้อมูลมาจากไหน ทำไมต้องมีฟิลด์นี้
Back-end Dev จะเห็นแค่ API กับ Database แต่ไม่รู้ว่าลูกค้าจะเอาไปใช้ยังไง จะกดปุ่มไหนเมื่อไหร่
ผลลัพธ์คือ ทั้งสองคนเก็บความรู้ทางเทคนิคได้ แต่ไม่มีใครได้ Business Context เต็มๆ และโยนหน้าที่ในการเข้าใจ Business Context ให้กับ PM, PO, BA, SA แทน พอเป็นแบบนี้แล้ว Dev ก็กลายเป็นหุ่นยนต์ ทำตามคำสั่งเอา อยากได้อะไรก็บอกมา 😓

แต่พอเราแบ่งงานแบบ Vertical (แบ่งตาม Value):

คนที่ทำจะได้เห็นฟีเจอร์ทั้งหมดตั้งแต่หน้าบ้านจนถึงหลังบ้าน
จะได้เข้าใจว่า “ลูกค้ากดปุ่มนี้ → ระบบเช็กเงื่อนไขอะไร → บันทึกข้อมูลอะไร → แสดงผลยังไง”
ความรู้นี้จะติดตัวไปนาน และนำไปใช้ซ้ำได้ในหลายโปรเจกต์ (Business Domain Knowledge)

ความรู้ทางเทคนิคมันมีอายุสั้นครับ React วันนี้ อีก 5 ปีอาจจะมีอย่างอื่นมาแทน แต่ความเข้าใจว่า “ทำไมระบบ E-commerce ต้องมีตะกร้าสินค้า” หรือ “ทำไม CRM ต้องติดตามประวัติลูกค้า” ความรู้นี้จะติดตัวคุณไปตลอด

และนี่คือเหตุผลว่าทำไม Vertical Slicing ถึงคุ้มค่ามากกว่าที่คิด เพราะมันไม่ได้แค่ช่วยให้งานส่งมอบเร็วขึ้น แต่มันยังช่วยให้ทีมเรา สะสม Business Context ที่มีค่ากว่าเทคนิคเยอะ

แต่เรื่องนี้คงต้องมาคุยกันอีกทีนะครับ เพราะมันเป็นเรื่องใหญ่ที่น่าสนใจมากๆ 😊

บทสรุป: เป็นผู้ใหญ่ที่รู้ว่ามันลึก และเป็นเด็กที่กล้าเรียนโดยไม่มีเส้นแบ่ง

สิ่งที่ผมอยากสื่อสารมากคือ อยากให้กำลังใจทุกคนครับ ไม่ว่าคุณจะแปะป้ายตัวเองว่าเป็นตำแหน่งอะไร

อย่ากลัวที่จะ “ไม่เก่ง” ในบางเรื่องครับ

การที่เรายอมไปจับงานที่เราไม่ถนัด (เช่น Backend เขียน Frontend) ไม่ได้แปลว่าเราลดมาตรฐานตัวเอง แต่มันแปลว่าเรา “แคร์” ว่าของจะถึงมือลูกค้าไหม มากกว่าความคิดว่าว่าโค้ดในโปรแกรมต้องสวยที่สุด

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

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

ใครเคยเจอกำแพงที่ชื่อว่า Expert (ความเก่ง) หรือ Title (ตำแหน่ง) หรือเปล่า? แล้วก้าวข้ามมันยังไง? มาแชร์กันได้นะครับ โดยเฉพาะคนที่ข้ามมาไกลมากๆ เช่น ข้ามสายอาชีพไปเลย พวกคุณเท่สุดๆ 😊💡