Product Team Shape ขององค์กรจะเป็นอย่างไรในยุค AI?🤔
“AI อาจกำลังทำให้ Product Team เล็กลง แต่ไม่ได้หมายความว่าองค์กรจะต้องการคน IT น้อยลงเสมอไปนะครับ”
ช่วงนี้ผมติดตามเรื่องการเปลี่ยนแปลงของ Product และ Engineering Team ในยุค AI อยู่พอสมควรครับ เพราะรู้สึกว่าเป็นช่วงหัวเลี้ยวหัวต่อสำคัญของวงการนี้ รวมถึงอาชีพของหลายๆ คนด้วยว่าจะปรับตัวกันอย่างไรต่อไป 🙂
ยิ่งได้ฟังประสบการณ์จากเพื่อนๆ ในวงการ รวมถึงอ่านกรณีศึกษาขององค์กรที่เริ่มทดลองทำงานแบบ AI-native ก็ยิ่งรู้สึกว่า
“AI อาจไม่ได้เปลี่ยนแค่เครื่องมือที่เราใช้ทำงาน แต่กำลังทำให้เราต้องกลับมาคิดเรื่องโครงสร้างทีมและวิธีสร้าง Software กันใหม่ด้วย” 🤔
เมื่อ AI ทำให้ทีมเล็กลงได้มากกว่าที่เคย?
มีเพื่อนในวงการท่านหนึ่งเล่าว่า หลังจากทดลองปรับวิธีทำงานของทีมพัฒนาซอฟต์แวร์อยู่ประมาณหนึ่งปี เขาพบว่าทีมเล็กเพียง 3–4 คนกลับทำงานได้ดีในบริบทของเขา จากเดิมที่ Squad หนึ่งมีประมาณ 7–10 คน
โดยทีมหนึ่งประกอบด้วย Product Manager 1 คน, Product Engineer 2 คน และอาจมี Designer อีก 1 คนตามความจำเป็น
แน่นอนว่าไม่ได้หมายความว่าทุกองค์กรควรเหลือทีมละ 3–4 คนนะครับ เพราะบริบทของแต่ละที่ไม่เหมือนกัน
แต่ที่น่าสนใจคือ บางองค์กรเริ่มทดลองไปไกลกว่านั้นแล้ว
อย่าง “Agoda” ที่ผมเคยเขียนถึงจาก AI Developer Report 2026 มีการพัฒนา CodeMaster เพื่อให้ AI Coding Agents เข้าไปช่วยทำงานในกระบวนการพัฒนาซอฟต์แวร์จริง และตั้งเป้าให้ Agents สร้าง 10% ของ Merge Requests ในปี 2026
นี่ไม่ใช่การแทนที่ Developer ทั้งทีม แต่เป็นการขยับจาก AI ที่คอยช่วยเขียนโค้ด ไปสู่ AI ที่เริ่มรับงานบางส่วนในกระบวนการพัฒนาได้เอง
หรืออีกกรณีที่น่าสนใจมากจากธนาคาร “Itaú Unibanco” ในบราซิล ซึ่งมีงานวิจัยชื่อ One Developer Is All You Need
เขาทดลองให้ Staff Engineer ที่มีประสบการณ์เพียง 1 คน ทำงานร่วมกับ AI Agents อีก 4 ตัว ตั้งแต่การแตก Requirement จัดทำ Specification ไปจนถึงพัฒนาและทดสอบโค้ด
ผลที่รายงานคือ “งานที่เดิมวางแผนให้ทีม 4 คนทำ สามารถส่งมอบได้ภายในเวลาประมาณครึ่งหนึ่งของแผนเดิม”
ฟังดูเหมือนอนาคตของ Software Development เลยนะครับ 😅
แต่ก็ต้องระวังการตีความ เพราะนี่เป็นกรณีศึกษาเพียงโครงการเดียว และ Engineer ที่ทำหน้าที่หลักก็เป็นคนที่มีประสบการณ์สูงและเข้าใจระบบขององค์กรอยู่แล้ว
ผมว่าบทเรียนที่น่าสนใจจึงไม่ใช่แค่การลดจำนวนคน แต่เป็นการที่ “AI สามารถขยายความสามารถของคนที่มีความเชี่ยวชาญอยู่แล้วให้ทำงานได้กว้างขึ้นมาก” และเมื่อการเขียนโค้ดเร็วขึ้น สิ่งที่เริ่มกลายเป็นคอขวดอาจไม่ใช่การพัฒนาเหมือนเดิม แต่เป็นการตัดสินใจว่าจะสร้างอะไร ตรวจสอบความถูกต้องอย่างไร และใครจะรับผิดชอบเมื่อระบบขึ้น Production แล้ว
“การสร้าง Software ได้เร็วขึ้น ไม่ได้แปลว่าเรากำลังสร้าง Product ที่ถูกต้องได้เร็วขึ้นเสมอไป?” 🤔
แต่การเปลี่ยนแปลงอาจไม่ได้เกิดแค่ในทีม Developer 😅
อีกเรื่องที่ผมว่าน่าสนใจไม่แพ้กัน คือการที่ Business User เริ่มสร้าง Application เองได้ด้วยเครื่องมือ AI แบบ Vibe Coding
วันนี้เราเริ่มเห็นคนที่ไม่ได้มีพื้นฐาน Programming มาก่อน สามารถสร้างระบบติดตามงาน Dashboard เครื่องมือจัดการข้อมูล หรือ Application ภายในทีมได้เอง
เมื่อก่อนถ้า Business อยากได้ระบบอะไรสักอย่าง อาจต้องเขียน Requirement ส่งให้ IT ประเมิน รอคิวพัฒนา แล้วกลับมาทดสอบกันหลายรอบ
แต่วันนี้บางงานสามารถเริ่มจากอธิบายปัญหาให้ AI ช่วยสร้าง Prototype ได้ภายในเวลาไม่นาน
ผมว่าตรงนี้เป็นโอกาสที่ใหญ่มากครับ โดยเฉพาะ Startup หรือ SME ที่มีข้อจำกัดเรื่องคนและงบประมาณ
แทนที่จะต้องลงทุนสร้างทีมพัฒนาขนาดใหญ่ตั้งแต่ต้น ธุรกิจอาจเริ่มทดลองด้วยเครื่องมือเล็กๆ ที่ช่วยแก้ปัญหาเฉพาะหน้าได้ก่อน
จึงไม่แปลกที่เริ่มมีคำถามตามมาว่า
“ถ้า Business สร้าง Software เองได้แล้ว องค์กรยังจำเป็นต้องมีทีม IT ขนาดเท่าเดิมอยู่หรือเปล่า?”
ผมว่าเป็นคำถามที่มีเหตุผล และบางงานก็อาจไม่จำเป็นต้องให้ Professional Developer เข้ามาทำตั้งแต่ต้นจริงๆ
แต่มีอีกด้านหนึ่งที่ผมคิดว่าเราต้องระวังเหมือนกันครับ
“การสร้าง Application ให้ใช้งานได้ กับการสร้าง Software ที่องค์กรพึ่งพาได้ในระยะยาว อาจเป็นคนละเรื่องกัน”
ตอนเป็น Demo หรือ Prototype ทุกอย่างอาจดูง่ายมาก
แต่พอเริ่มมีผู้ใช้จริง เชื่อมต่อข้อมูลลูกค้า มีการกำหนดสิทธิ์ หรือกลายเป็นระบบที่ธุรกิจต้องใช้ทุกวัน ความซับซ้อนก็ตามมา
ลองนึกภาพ Application ที่พนักงานคนหนึ่งสร้างขึ้นมาใช้ในทีม ตอนแรกมีคนใช้เพียงไม่กี่คน แต่ต่อมาขยายไปทั้งแผนก และเริ่มเชื่อมต่อกับระบบสำคัญของบริษัท
วันหนึ่งคนสร้างลาออก ระบบเกิดปัญหา ไม่มีเอกสาร ไม่มีคนเข้าใจโค้ด และไม่มีใครรับผิดชอบดูแลต่อ
จากเครื่องมือเล็กๆ ที่เคยช่วยเพิ่ม Productivity ก็อาจกลายเป็นภาระขององค์กรได้เหมือนกัน
ยิ่ง Software สร้างได้ง่ายขึ้น เราอาจมี Application และ AI Agents กระจายอยู่ทั่วองค์กร โดยไม่มีใครรู้ทั้งหมดว่าระบบไหนใช้ข้อมูลอะไร ใครเป็นเจ้าของ และมีความเสี่ยงแค่ไหน
จากเดิมที่เรากังวลเรื่อง Shadow IT (พนักงานแอบไปใช้เครื่องมือ หรือ AI นอกที่องค์กรไม่อนุญาต) วันหนึ่งเราอาจต้องเจอปัญหานี้ในรูปแบบที่ขยายตัวเร็วกว่าเดิมมาก
“AI ช่วยลดต้นทุนการสร้าง Software ได้ แต่ไม่ได้หมายความว่าจะลดต้นทุนในการดูแลและรับผิดชอบระบบได้ในสัดส่วนเดียวกัน”
ผมเลยคิดว่าเราไม่ควรมองเรื่องนี้เป็นเพียงคำถามว่าจะลดคน IT ได้กี่คน แต่ควรมองว่าเราจะออกแบบการทำงานระหว่าง Business กับ IT ใหม่อย่างไร
แล้วโครงสร้างทีมแบบไหนถึงจะเหมาะกับยุค AI? 🤔
ส่วนตัวผมยังไม่คิดว่าจะมีสูตรสำเร็จ เช่นว่าทีมหนึ่งต้องมี 3 คน 4 คน หรือ Engineer 1 คนกับ AI Agents อีกหลายตัว
แต่ผมมองว่าองค์กรควรมีรูปแบบการทำงานที่ยืดหยุ่นตามความซับซ้อนและความเสี่ยงของงาน โดยอาจแบ่งออกเป็น 3 แนวทางครับ
1. Business-led Development — “งานเล็ก ความเสี่ยงต่ำ ให้ Business สร้างเองได้”
* สำหรับ Application ภายในทีมที่ไม่เกี่ยวข้องกับข้อมูลอ่อนไหวหรือระบบสำคัญ เราอาจเปิดให้ Business User ใช้ AI, Low-code หรือ Vibe Coding สร้างเองได้ภายใต้เครื่องมือและกติกาที่องค์กรกำหนด
* IT ไม่จำเป็นต้องเข้ามาพัฒนาทุกอย่าง แต่ควรจัดเตรียมเครื่องมือและขอบเขตการใช้งานที่เหมาะสม เพื่อให้ Business เริ่มต้นได้เร็วและปลอดภัย
2. Business + Product/Engineering — “งานเริ่มซับซ้อน ให้ทำร่วมกัน”
* เมื่อ Application เริ่มมีผู้ใช้หลายทีม ต้องเชื่อมต่อข้อมูล หรือมีแนวโน้มจะใช้งานต่อเนื่อง ก็ควรให้ Product Engineer หรือทีม IT เข้ามาช่วยยกระดับ
* Business ยังเป็นเจ้าของปัญหาและผลลัพธ์ ส่วน Engineer ช่วยเรื่องการออกแบบระบบ คุณภาพ และความพร้อมในการใช้งานจริง โดยมี AI Agents ช่วยเพิ่มความเร็วในกระบวนการ
* ผมว่าโมเดลนี้น่าสนใจมาก เพราะไม่ใช่การส่ง Requirement ให้ IT ไปทำทั้งหมดเหมือนเดิม แต่เป็นการทำงานร่วมกันตั้งแต่ต้น
3. Professional Engineering — “ระบบสำคัญยังต้องมีคนรับผิดชอบอย่างมืออาชีพ”
* สำหรับระบบหลักของธุรกิจ งานธุรกรรม ข้อมูลสำคัญ หรือระบบที่มีข้อกำหนดด้าน Security และ Compliance สูง ยังจำเป็นต้องมี Professional Engineer รับผิดชอบอย่างชัดเจน
* แม้ AI จะช่วยเขียนโค้ด ทดสอบ และทำงานหลายขั้นตอนได้ แต่เรื่อง Architecture, Integration, ความปลอดภัย และการดูแล Production ก็ยังต้องอาศัยความเชี่ยวชาญและการตรวจสอบที่เหมาะสม
“ทั้งสามแนวทางนี้ไม่จำเป็นต้องแยกเป็นสามแผนกนะครับ แต่ควรเป็นทางเลือกในการทำงานที่องค์กรสามารถปรับใช้ตามลักษณะของงานได้”
โดยมีทีมกลางด้าน Platform, Security และ Engineering Standards ช่วยเตรียมเครื่องมือ มาตรฐาน และระบบควบคุมที่ใช้ร่วมกัน
สิ่งสำคัญคือ “Application ควรสามารถขยับจากรูปแบบหนึ่งไปสู่อีกรูปแบบหนึ่งได้ เมื่อความสำคัญหรือความเสี่ยงเปลี่ยนไป”
วันนี้ Business อาจสร้างเครื่องมือเล็กๆ ใช้เอง
พอมีคนใช้มากขึ้น ก็ให้ Engineer เข้ามาช่วย
และเมื่อกลายเป็นระบบสำคัญขององค์กร ก็ต้องมีเจ้าของระบบและกระบวนการดูแลระยะยาวที่ชัดเจน
ไม่ใช่ว่าเริ่มจาก Business แล้วต้องอยู่กับ Business ตลอด หรือถ้าเป็นระบบที่ IT ดูแลแล้ว ทุกอย่างต้องกลับไปเข้าคิว IT เหมือนเดิม
บทบาทของ IT เองก็คงต้องเปลี่ยนไปด้วย? 🤔
จากเดิมที่หลายองค์กรมี IT เป็นหน่วยงานรับ Requirement และผลิต Software ให้ Business
เราอาจต้องเห็น IT ขยับไปทำหน้าที่สร้าง Platform เครื่องมือ มาตรฐาน และช่วยให้ Business สามารถพัฒนาสิ่งที่เหมาะสมได้ด้วยตัวเองมากขึ้น
ส่วนคนทำ Engineering ก็อาจต้องให้ความสำคัญกับ Architecture, Security, Integration และการดูแลระบบ มากกว่าการแข่งขันกันว่าใครเขียนโค้ดได้เร็วกว่า AI
แต่ในอีกด้านหนึ่ง เราก็ต้องคิดเรื่องการพัฒนา Engineer รุ่นใหม่และ Career Path ให้ดีครับ
เพราะถ้าเรามองแต่ประสิทธิภาพระยะสั้น แล้วลดโอกาสให้คนรุ่นใหม่ได้เรียนรู้และฝึกฝน วันหนึ่งองค์กรอาจขาดคนที่มีประสบการณ์เพียงพอจะตรวจสอบและรับผิดชอบระบบที่ AI ช่วยสร้างขึ้นมาเองก็ได้
⸻
สำหรับผม สิ่งที่น่าสนใจจากการเปลี่ยนแปลงครั้งนี้ ไม่ใช่ว่าในอนาคตเราจะเหลือ Developer กี่คน หรือ Business User จะสร้าง Application เองได้มากแค่ไหน 🙂
แต่คือ “ขอบเขตระหว่าง Business, Product และ Engineering กำลังเปลี่ยนไป”
บางขั้นตอนที่เคยต้องแยกคน แยกทีม หรือส่งงานข้ามฝ่าย อาจไม่จำเป็นต้องทำแบบเดิมทั้งหมดแล้ว
ขณะเดียวกัน ความรับผิดชอบเรื่องคุณภาพ ความปลอดภัย และการดูแลระบบก็ไม่ได้หายไป เพียงเพราะ AI เขียนโค้ดแทนเราได้
ผมว่าโจทย์ขององค์กรยุค AI จึงไม่ควรเริ่มจากคำถามว่าจะลดทีม IT ได้กี่คน
แต่ควรถามว่า” เราจะจัดคน เทคโนโลยี และความรับผิดชอบอย่างไร ให้ Business สร้างสิ่งใหม่ได้เร็วขึ้น โดยไม่สร้างความเสี่ยงที่องค์กรควบคุมไม่ได้?”
เพราะสุดท้ายแล้ว การสร้าง Software ได้มากขึ้น ไม่ได้หมายความว่าองค์กรจะสร้างคุณค่าได้มากขึ้นเสมอไป
“ความสามารถในการสร้าง Software อาจไม่ใช่ข้อจำกัดใหญ่ที่สุดอีกต่อไป แต่ความสามารถในการเลือกว่าจะสร้างอะไร ทำให้มันใช้ได้จริง และรับผิดชอบมันในระยะยาวต่างหาก ที่อาจเป็นตัววัดความสามารถขององค์กรยุค AI ครับ”
#วันละเรื่องสองเรื่อง
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2026 Blockdit
