- วิศวกรรมซอฟต์แวร์ ในความหมายดั้งเดิมกำลังสิ้นสุดลง และเกิดพาราไดม์ของ วิศวกรรมผลิตภัณฑ์ ที่มี AI เป็นฐาน
- โปรดักต์เอนจิเนียร์คือ บทบาทลูกผสมระหว่างผู้จัดการผลิตภัณฑ์กับนักพัฒนา full-stack เป็น ผู้สร้างที่ทำงานอย่างอิสระและมุ่งผลลัพธ์ ซึ่งรับผิดชอบทั้งวงจรตั้งแต่การวางแผนจนถึงการปล่อยใช้งาน
- บุคคลเหล่านี้มีพื้นฐานจาก AI-native, ความสามารถแบบ T-shaped และแนวคิดที่ยึด KPI เป็นศูนย์กลาง โดยจะถูกจัดโครงสร้างตามฟีเจอร์ ไม่ใช่ตามทีม ทำให้รับผิดชอบแบบ end-to-end เช่น onboarding, การชำระเงิน, การแจ้งเตือน
- ในขั้นของผลิตภัณฑ์ จะทำงานด้าน ideation, การวิเคราะห์ตลาด, การวิจัยผู้ใช้ และการออกแบบผลิตภัณฑ์ ส่วนในขั้นวิศวกรรมจะรับผิดชอบ architecture, การออกแบบระบบ, การพัฒนา frontend และ backend
- AI เป็นเครื่องมือที่ทรงพลังอย่างยิ่งโดยเฉพาะในงานที่นิยามได้และเป็นแบบกำหนดแน่นอน (D&D) และในอนาคตองค์กรมีแนวโน้มจะพัฒนาไปสู่ โครงสร้างการทำงานร่วมกันระหว่างโปรดักต์เอนจิเนียร์กับ AI แทน สามเหลี่ยม PM-ดีไซเนอร์-เอนจิเนียร์ แบบเดิม
Background
- วิศวกรรมซอฟต์แวร์ แบบดั้งเดิมใช้งานไม่ได้อีกต่อไป
- การประกาศภาษา C โดย Dennis Ritchie ในปี 1972 คือการเปลี่ยนพาราไดม์ขั้นพื้นฐานครั้งสุดท้าย
- การพัฒนาหลังจากนั้นเป็นเพียง การเพิ่มประสิทธิภาพและการยกระดับนามธรรม เพื่อให้การเขียนและแปลง machine code ง่ายขึ้น
- การวัดผลิตภาพถูกประเมินมายาวนานจากประสิทธิภาพด้านเวลาและพื้นที่ของโค้ด ความยาว และความสามารถในการตีความ
- ตอนนี้เราได้เข้าสู่ พาราไดม์ใหม่อย่างสิ้นเชิง แล้ว และมีโอกาสน้อยที่จะย้อนกลับไปสู่ยุค “raw coding” แบบเดิม
- เมื่อไม่นานมานี้ John Carmack กล่าวไว้ว่า เครื่องมือสร้างสิ่งต่างๆ ที่ดีที่สุดในอนาคตจะ เปลี่ยนจากการเขียนโค้ดด้วยมือไปเป็นการให้ AI ช่วยนำทาง
- ดังนั้นสิ่งสำคัญสำหรับเอนจิเนียร์คือการพัฒนา “product skills” และใช้เครื่องมือที่เหมาะสมที่สุด
- วิศวกรรมซอฟต์แวร์จะค่อยๆ วิวัฒน์ไปเป็น Product Engineering
โปรดักต์เอนจิเนียร์ (Product Engineer, PE) คืออะไร?
- เป็นบทบาทผสมระหว่าง Product Manager และวิศวกรซอฟต์แวร์ full-stack
- รับผิดชอบวงจรชีวิตผลิตภัณฑ์ทั้งหมด และเชื่อมโยงโดยตรงกับความสำเร็จหรือความล้มเหลวของผลิตภัณฑ์
- คุณลักษณะสำคัญของโปรดักต์เอนจิเนียร์:
- AI-native: ใช้ LLM เป็นเครื่องมือหลัก ไม่ใช่ฟังก์ชันเสริม
- ความสามารถแบบ T-shaped: มีทักษะวิศวกรรมเชิงลึก พร้อมความเข้าใจที่กว้างในด้านผลิตภัณฑ์ ข้อมูล และดีไซน์
- ยึดผลลัพธ์เป็นหลัก: รับผิดชอบ KPI เช่น retention, conversion rate, activation rate
- ความสามารถในการลงมือทำอย่างอิสระ: ทำได้ตั้งแต่ไอเดีย → เอกสารวางแผน → ดีไซน์ → deploy โดยแทบไม่ต้องมีการกำกับ
- การเปลี่ยนแปลงโครงสร้างทีม
- โปรดักต์เอนจิเนียร์จะรวมตัวกันเป็น lean team ขนาดเล็กแต่มีทักษะสูง
- แทนที่การแยก frontend/backend/infrastructure แบบเดิม จะจัดองค์กรโดยยึด ผลิตภัณฑ์และฟีเจอร์ (feature squad) เป็นศูนย์กลาง
- ไม่แบ่งตามสแตก แต่จัดตาม ผลลัพธ์ (outcome)
- ตัวอย่าง: คนหนึ่งรับผิดชอบ onboarding อีกคนดูแลการชำระเงิน และอีกคนดูแลฟีเจอร์การแจ้งเตือน
- แต่ละคนรับผิดชอบ ทั้งฟีเจอร์ตั้งแต่ UX ไปจนถึงชั้นข้อมูลแบบ end-to-end
- กล่าวคือ โครงสร้างจาก “ทีม frontend/backend/infrastructure” แบบเดิม จะเปลี่ยนเป็น “สควอดอิสระตามฟีเจอร์”
- โปรดักต์เอนจิเนียร์มี สองมิติ:
- มิติด้านผลิตภัณฑ์ (ก่อนการพัฒนา, pre-development)
- มิติด้านวิศวกรรม (ระหว่างและหลังการพัฒนา, in/post-development)
The Product
- บทบาทด้านผลิตภัณฑ์ ของโปรดักต์เอนจิเนียร์มีส่วนทับซ้อนกับงานของ Product Manager แบบดั้งเดิม และเป็นส่วนที่รับผิดชอบการวางแผนและทิศทางของผลิตภัณฑ์
- Product Ideation (การสร้างแนวคิดผลิตภัณฑ์)
- เป็นกระบวนการกำหนดและทำให้ชัดเจนขึ้นถึงฟังก์ชันหลัก คุณค่าที่นำเสนอ (Value Proposition) และกลุ่มผู้ใช้เป้าหมายของผลิตภัณฑ์
- ช่วยกำหนดเหตุผลของการมีอยู่ของผลิตภัณฑ์และลูกค้าเป้าหมายอย่างชัดเจน เพื่อวางรากฐานให้กับทิศทางการพัฒนาต่อไป
- Mind-mapping (การทำแผนที่ความคิด)
- ทำความเข้าใจภาพรวมด้วยการจัดทำและแสดงภาพไอเดียหรือโจทย์ที่แตกแขนงจากแนวคิดหลัก
- ใช้เป็นเครื่องมือช่วยแบ่งปันและต่อยอดไอเดียภายในทีม
- Brainstorming (การระดมความคิด)
- เป็นกระบวนการจดบันทึกไอเดียด้วยตนเอง แล้วนำไปแบ่งปันกับผู้อื่นเพื่อปรับปรุง เติมเต็ม และตรวจสอบ
- ช่วยขยายความหลากหลายและความสร้างสรรค์ของไอเดียผ่านการทำงานร่วมกัน
- Discovery
- เป็นกระบวนการสำรวจความต้องการของลูกค้า และค้นคว้าโอกาสทางการตลาดเพื่อค้นหา ผลิตภัณฑ์ที่สอดคล้องทั้งเป้าหมายทางธุรกิจกับคุณค่าของผู้ใช้
- รวมถึงการสัมภาษณ์ผู้ใช้ การวิเคราะห์คู่แข่ง และการวิจัยตลาด
- Selection (การจัดลำดับความสำคัญ)
- ตัดสินใจว่าควรดำเนินฟีเจอร์หรือโปรเจกต์ใดก่อน โดยอิงจากทิศทางเชิงกลยุทธ์ เป้าหมายธุรกิจ ความต้องการลูกค้า และแนวโน้มตลาด
- ช่วยคัดเลือกแนวทางดำเนินการที่มีประสิทธิภาพที่สุดภายใต้ทรัพยากรที่จำกัด
- Market Analysis (การวิเคราะห์ตลาด)
- วิเคราะห์สภาพแวดล้อมของตลาดที่ผลิตภัณฑ์จะเข้าไปอยู่ และทำความเข้าใจการแข่งขัน ขนาดตลาด โอกาส และความเสี่ยง
- ใช้ในการกำหนดตำแหน่งผลิตภัณฑ์และกลยุทธ์การเติบโต
- User Research (การวิจัยผู้ใช้)
- เป็นกระบวนการทำความเข้าใจพฤติกรรม ความต้องการ และปัญหาของผู้ใช้อย่างลึกซึ้ง
- เพื่อให้ได้หลักฐานสำหรับปรับปรุงประสบการณ์ผู้ใช้บนฐานข้อมูล
- Product Design (การออกแบบผลิตภัณฑ์)
- รวมถึง การออกแบบ UI/UX, service design, interaction design และการทดสอบกับผู้ใช้
- รับประกันประสบการณ์ที่เป็นมิตรต่อผู้ใช้ผ่านการสร้างต้นแบบและการทดสอบซ้ำอย่างต่อเนื่อง
- แม้งานเหล่านี้จะเป็นสิ่งที่ Product Manager แบบดั้งเดิมทำมาโดยตลอด แต่โปรดักต์เอนจิเนียร์จะ ใช้เครื่องมือ AI เพื่อทำงานได้คล่องตัวกว่าเดิม
- AI มี ข้อจำกัดในการสร้างไอเดียใหม่ แต่มีพลังอย่างมากในการตรวจทานรูปแบบที่มีอยู่แล้ว หรือช่วยเติมเต็มการคิดซ้ำๆ
- ประเด็นสำคัญคือ วิสัยทัศน์ของผลิตภัณฑ์ต้องนำโดยมนุษย์ และควรใช้ AI เป็น soundboard สำหรับขัดเกลาและปรับแต่งไอเดีย
The Engineer
- บทบาทด้านวิศวกรรม ของโปรดักต์เอนจิเนียร์คือขั้นตอนที่นำสเปกที่วางแผนไว้ไปสู่การลงมือทำและการพัฒนาให้เกิดขึ้นจริง
- ครอบคลุม 4 ด้านหลัก:
- Software Architecture: การตัดสินใจเชิงโครงสร้าง
- System Design: การนิยามและทำให้ระบบมีรายละเอียดชัดเจน
- Frontend Development: การนำดีไซน์เชิงภาพและส่วนติดต่อผู้ใช้ไปสร้างจริง
- Backend Development: การเพิ่มประสิทธิภาพ business logic และการออกแบบฐานข้อมูล
- แน่นอนว่าหัวข้อวิศวกรรมเพิ่มเติมอย่างการทดสอบ การมอนิเตอร์ และการผสาน AI ก็สำคัญเช่นกัน แต่สำหรับโปรเจกต์ส่วนใหญ่ สิ่งสำคัญอันดับแรกคือ การสร้างและปล่อยผลิตภัณฑ์แบบ SLC (Simple, Lovable, Complete) ให้ได้อย่างรวดเร็ว
- เนื่องจาก coding LLM ทำงานได้โดดเด่นเป็นพิเศษในสภาพแวดล้อมที่นิยามได้และเป็นแบบกำหนดแน่นอน (D&D) จึงทำให้ AI มีส่วนช่วยในด้านวิศวกรรมได้มากกว่า
-
Planning
- ขั้นตอนสำคัญที่สุดในการใช้ AI ให้มีประสิทธิภาพคือการวางแผน
- หากป้อนเจตนาของโปรเจกต์ให้ AI ในรูปของข้อกำหนดที่มีโครงสร้างดี คุณภาพของโค้ดในระยะยาวจะดีขึ้นอย่างมาก
- เมื่อกำหนด Rules (ชุดกฎ) แล้ว AI coder จะสามารถอ้างอิงแนวทางระดับระบบได้อย่างต่อเนื่อง
- ตัวอย่าง: กฎการอัปเดตเอกสาร การบันทึกการเปลี่ยนแปลงสถาปัตยกรรม สไตล์โค้ด มาตรฐานการทดสอบ
- ตัวอย่างโครงสร้างกฎ:
- ซิงก์เอกสารใน
/docs รวมถึง README และ CHANGELOG
- เมื่อมีการเปลี่ยน dependency หรือ architecture ที่สำคัญ ให้เขียน ADR (Architecture Decision Record)
- สร้าง API client ด้วย OpenAPI Generator และใช้เทมเพลต TypeScript axios
- การเข้าถึงข้อมูลให้ใช้ repository pattern และทำ error handling ให้เป็นมาตรฐาน
- กำหนดเกณฑ์ของการทดสอบ unit, integration และ E2E ให้ชัดเจน
- ใน IDE ส่วนใหญ่สามารถสร้างได้อัตโนมัติด้วย
/Generate Cursor Rules
-
Software Architecture
- architecture คือชุดการตัดสินใจที่เป็นโครงกระดูกของ codebase และ เพราะมีต้นทุนการเปลี่ยนแปลงสูง จึงต้องระมัดระวังตั้งแต่ระยะแรก
- สิ่งที่ต้องพิจารณา:
- monolithic vs microservices, serverless vs containerized
- การจัดการ dependency และการกำหนดขอบเขตของการผสานระบบ
- modularity และการแยก concerns
- โปรโตคอลการสื่อสาร เช่น REST, GraphQL, gRPC, event bus
- กลยุทธ์ด้าน scalability (เช่น horizontal scaling)
- บทบาทของ AI:
- เปรียบเทียบข้อดีข้อเสียของรูปแบบ architecture ทางเลือก
- สร้างไดอะแกรมด้วย Mermaid.js
- ร่าง ADR ฉบับแรก
- แต่การตัดสินใจสุดท้ายยังต้องอาศัย วิจารณญาณของมนุษย์และความเชี่ยวชาญในโดเมน
-
System Design
- system design คือกระบวนการทำให้ architecture เป็นรูปธรรม โดยนิยามให้ชัดเจนเป็น บริการจริง การไหลของข้อมูล state machine และ interface
- งานหลักได้แก่:
- กำหนดขอบเขตของ API และบริการ
- ทำ data modeling และออกแบบการไหลของข้อมูลระหว่างแต่ละชั้น
- วางกลยุทธ์การจัดการข้อผิดพลาดและการกู้คืนเมื่อระบบล้มเหลว
- จำลอง state transition และ asynchronous workflow
- เขียนเอกสารการออกแบบและทบทวน edge case
- ความเป็นไปได้ในการใช้ AI:
- สร้างร่างการออกแบบเบื้องต้น
- จำลองปัญหาการทำงานพร้อมกันและ edge case
- เขียน API interface, schema และ state machine
- เปรียบเทียบ design pattern และให้ feedback
- ช่วยตรวจสอบการออกแบบราวกับเป็น “วิศวกรระดับจูเนียร์”
-
Frontend Engineering
- frontend รับผิดชอบ การออกแบบเชิงภาพและการพัฒนาความสามารถฝั่งไคลเอนต์
- AI ทำงานได้ดีมากใน ecosystem ของ JS โดยเฉพาะเฟรมเวิร์กที่ใช้แพร่หลายอย่าง React
- เคล็ดลับเพื่อเพิ่มประสิทธิภาพของ AI:
- ให้ AI เห็น brand guideline (ฟอนต์ สี ระยะห่าง กฎ responsive) ในรูปแบบสกรีนช็อตหรือเอกสาร
- ใช้ Tailwind config, CSS variables ฯลฯ เพื่อสร้างโค้ด UI ที่สม่ำเสมอ
- ยังสามารถลองใช้เครื่องมือ Figma-to-code (เช่น Tempo) เพื่อแปลงเป็นโค้ดได้
- หากป้อนนิยามคอมโพเนนต์ที่ทำซ้ำและกฎ responsive ให้ AI ก็จะเขียน UI ที่คงความสอดคล้องของแบรนด์ได้ง่ายขึ้น
-
Backend Engineering
- backend รับผิดชอบ การพัฒนา business logic, การออกแบบฐานข้อมูล, การสร้างและเพิ่มประสิทธิภาพ API
- AI มีประสิทธิภาพอย่างยิ่งในงานที่นิยามได้และเป็นแบบกำหนดแน่นอน (D&D)
- เทคนิคที่ได้ผล:
- การนำเข้าเอกสาร: โหลด API spec และเอกสารเทคนิคเข้า IDE โดยตรงเพื่อให้ AI ใช้อ้างอิง ช่วยลด hallucination
- การใช้ workspace: ในโปรเจกต์ที่แยก frontend กับ backend ให้นำโฟลเดอร์มารวมกันเพื่อให้บริบท ช่วยให้ AI เข้าใจโครงสร้างของทั้งโปรเจกต์ได้ดีขึ้น
General Tips for the Product Engineer
-
Always work at the frontier
- การใช้โมเดลล่าสุดอยู่เสมอเป็นเรื่องสำคัญ
- โมเดลล่าสุดเข้าใจโปรเจกต์ขนาดใหญ่ได้ดีขึ้นจาก context window ที่ใหญ่ขึ้น
- มีการปรับปรุงด้าน ความสามารถในการให้เหตุผล, ลด hallucination และ เพิ่มเสถียรภาพ
-
Use thinking mode
- การเปิด Thinking mode ช่วยยกระดับคุณภาพคำตอบของโมเดลได้อย่างมาก
- ถ้ามีตัวเลือก ควรเปิดไว้เสมอ
- หากไม่รองรับ สามารถใส่คำว่า “ultrathink” ลงในพรอมป์ต์เพื่อให้ได้ผลคล้ายกัน
-
Be hyper-specific
- เมื่อขอให้ AI ช่วย ควรเขียนคำสั่งให้ เฉพาะเจาะจงและชัดเจน
- ต้องใส่เป้าหมาย เงื่อนไขจำกัด การตัดสินใจด้านดีไซน์ โค้ด snippet ที่เกี่ยวข้อง path ของไฟล์ และชื่อคอมโพเนนต์ให้ครบ
- ตัวอย่างพรอมป์ต์ที่ดี:
- เพิ่มฟังก์ชันติดตาม analytics ลงในฟอร์ม
/src/pages/SignUp.tsx
- เมื่อผู้ใช้คลิก ‘Submit’ ให้ส่งอีเวนต์
sign_up_started ผ่านฟังก์ชัน trackEvent()
- อีเวนต์นี้ต้องมี การทำ debounce
- ใส่โดเมนอีเมลของผู้ใช้ (เช่น
gmail.com) เป็นพร็อพเพอร์ตี
-
Provide visual context
- ในงาน frontend การให้ บริบทเชิงภาพ สำคัญเป็นพิเศษ
- coding LLM เข้าใจภาพได้อยู่แล้ว ดังนั้นถ้าแนบ ภาพหน้าจอดีไซน์ หรือ ภาพจับข้อความผิดพลาดจากบั๊ก AI จะช่วยแก้ปัญหาได้เร็วขึ้น
-
Work in small iterations
- แทนที่จะมอบงานใหญ่ให้ AI ทีเดียว ควร แบ่งเป็นหน่วยเล็กๆ แล้วทำแบบเป็นรอบ (iteration)
- วิธีที่ได้ผลคือสร้างความสามารถพื้นฐานก่อน แล้วค่อยปรับปรุงเพิ่มเติมทีละขั้น
- ควรแยกพรอมป์ต์ออกเป็นหลายคำสั่งที่นิยามชัดเจน
-
Stay curious
- บนอินเทอร์เน็ตมี เคล็ดลับและกรณีตัวอย่างด้าน prompt engineering จำนวนมาก
- หากเข้าร่วมชุมชนหรือเครือข่ายที่เกี่ยวข้อง ก็จะได้เห็น เทคนิคใหม่ล่าสุด และเรียนรู้ วิธีใช้งานที่ยอดเยี่ยม ได้รวดเร็ว
Closing thoughts
- แม้จะเกิดการปฏิวัติ AI แต่ก็ยังมีทักษะบางอย่างที่ในอนาคตอันใกล้จะไม่ถูกแทนที่ หรืออาจยิ่งมีคุณค่ามากขึ้น
- ความชำนาญเครื่องมือ CLI (เช่น git)
- Git เป็นเครื่องมือที่มีประสิทธิภาพที่สุดในการจัดการเวอร์ชันของโค้ดและติดตามประวัติการเปลี่ยนแปลง
- เนื่องจากโค้ดที่ AI สร้างขึ้นยังมีความน่าเชื่อถือต่ำ ความสามารถในการย้อนกลับไปยังสถานะก่อนหน้า หรือเริ่มใหม่ จึงเป็นสิ่งจำเป็น
- เพราะฉะนั้น ความสามารถในการใช้เครื่องมือ CLI อย่าง Git จะยิ่งสำคัญมากขึ้น
- ทักษะพื้นฐานด้านวิศวกรรม
- ความสามารถในการจัดการ technical debt และรักษา modularity กับ encapsulation ของโค้ด
- AI อาจไม่สามารถรับประกันความสม่ำเสมอของสไตล์โค้ดได้ (เช่น naming convention, หลักการ DRY, modularity)
- ดังนั้น ความสามารถของเอนจิเนียร์ในการรักษาหลักการพื้นฐานด้วยตนเองจึงมีมูลค่าสูงขึ้น
- อย่างไรก็ตาม ในระยะยาวก็ยังมีความเป็นไปได้ที่สิ่งนี้จะเปลี่ยนไป เมื่อ AI เขียนโค้ดได้มากขึ้น
- ทักษะการสื่อสารที่แข็งแรง
- ความสามารถในการเขียนเอกสาร พรอมป์ต์ และสเปกที่ชัดเจนและมีโครงสร้าง มีผลแบบทวีคูณ
- AI ไม่ได้อนุมานเจตนาเหมือนมนุษย์ แต่ ทำตามสิ่งที่สั่งเท่านั้น ดังนั้นความชัดเจนจึงจำเป็นอย่างยิ่ง
- สเปกที่ดี พรอมป์ต์ที่นิยามดี และการทำเอกสารอย่างเป็นระบบ จะนำไปสู่การเพิ่มทั้งผลิตภาพและคุณภาพของผลลัพธ์
- การเปลี่ยนย้ายอำนาจภายในองค์กร
- งานเชิงเทคนิคจะค่อยๆ ถูก AI รับไปมากขึ้น ซึ่งเหมาะกับลักษณะงานแบบ D&D (Definable & Deterministic)
- ยิ่งการลงมือทำมีต้นทุนต่ำและกลายเป็นของทั่วไปมากขึ้นเท่าไร ความสามารถในการบริหาร AI และแพ็กเกจผลลัพธ์เพื่อนำเสนอแก่ผู้บริหารและผู้ถือหุ้น ก็ยิ่งมีมูลค่ามากขึ้นเท่านั้น
- ในองค์กรขนาดใหญ่ มักมองไม่เห็นกระบวนการลงมือทำจริง และเห็นเพียงผลลัพธ์ที่ถูกส่งต่อ ดังนั้น ความสามารถในการนำเสนอเชิงกลยุทธ์และการแพ็กเกจผลงาน จะเป็นตัวกำหนดอิทธิพล
- มีความเป็นไปได้สูงว่า ผู้จัดการที่สามารถจัดแนวและสื่อสารสิ่งเหล่านี้ได้ จะมีอำนาจมากกว่าคนที่ลงมือสร้างเทคโนโลยีด้วยตนเอง
- แนวโน้มการเปลี่ยนแปลงโครงสร้างองค์กร
- ยิ่งเป็นบริษัทใหม่ (สตาร์ตอัป) บทบาทของโปรดักต์เอนจิเนียร์ก็ยิ่งสะท้อนออกมาได้เร็ว
- เมื่อบริษัทเติบโตและ AI มีความเป็นอิสระมากขึ้น โครงสร้าง สามเหลี่ยม PM–ดีไซเนอร์–เอนจิเนียร์ แบบดั้งเดิมอาจอ่อนแรงลง
- แทนที่ด้วยโทโพโลยีทีมแบบใหม่ ที่มี pod ขนาดเล็กซึ่งนำโดยโปรดักต์เอนจิเนียร์ที่มี product sense และมี AI copilot คอยช่วยเสริมในทุกสแตก
References
ยังไม่มีความคิดเห็น