FDE คืออะไร? เจาะลึกเส้นทางอาชีพ AI Forward Deployed Engineer

ในช่วงสองปีที่ผ่านมา คนที่เป็นที่ต้องการตัวมากที่สุดในวงการ AI คือคนที่เทรนโมเดลและคนที่สร้างโปรดักต์ AI

พอมาถึงปี 2026 ก็มีอีกตำแหน่งหนึ่งที่พุ่งทะยานขึ้นมาทันที: FDE

ชื่อเต็มของมันคือ Forward Deployed Engineer พูดตามตรง ถึงจะได้ยินชื่อ แต่หลายคนก็ยังไม่รู้ว่าจริงๆ แล้วตำแหน่งนี้ทำอะไร

ก่อนอื่น มาดูตัวเลขสองสามชุดกัน:

รายงานของ LinkedIn ระบุว่าตำแหน่งที่เกี่ยวข้องกับ FDE เติบโตขึ้น 42 เท่า ระหว่างปี 2023 ถึง 2025;
OpenAI ตั้งบริษัท Deployment Company ขึ้นในเดือนพฤษภาคม 2026 ด้วยเงินลงทุนเริ่มต้นกว่า 4 พันล้านดอลลาร์ พร้อมดึงวิศวกรและผู้เชี่ยวชาญด้าน deployment เข้ามาประมาณ 150 คนผ่านการซื้อกิจการ;
AWS ตามมาติดๆ ด้วยการลงทุน 1 พันล้านดอลลาร์ เพื่อส่งวิศวกรนับพันคนเข้าไปนั่งทำงานในทีมลูกค้า

การที่ยักษ์ใหญ่เทคฯ พร้อมใจกันแย่งตัวคนกลุ่มนี้ บอกได้เลยว่าลมได้เปลี่ยนทิศแล้ว ผลต่าง 0.1 แต้มบนลีดเดอร์บอร์ดโมเดล ลูกค้าอาจไม่รู้สึก แต่ระบบ AI ที่ผสานเข้ากับระบบเดิม วิ่งอยู่ในเวิร์กโฟลว์ได้จริง และช่วยประหยัดเงินจริง ลูกค้ายินดีจ่ายต่อเนื่อง

วงการ AI ย้ายจาก "การเปรียบเทียบโมเดล" ไปสู่ "การเปรียบเทียบการใช้งานจริง"

ถ้าคุณกำลังพิจารณาจะเปลี่ยนผ่านสู่สาย AI หรือมองหาเส้นทางอาชีพถัดไป บทความนี้จะทำให้เข้าใจ 3 เรื่อง: FDE คืออะไร พวกเขาทำอะไรในแต่ละวัน และคนที่ไม่มีพื้นฐานการเขียนโค้ดจะเปลี่ยนผ่านทีละขั้นได้อย่างไร

1. จริงๆ แล้ว FDE คืออะไร?

เราชอบอธิบายแบบนี้:

FDE คือคนที่เข้าไปในธุรกิจจริงของลูกค้า และพา AI จากขั้น Demo ไปจนถึงระบบ production จริง

สมมติลูกค้าพูดว่า: "เราอยากสร้าง AI บริการลูกค้า" ลิสต์ความต้องการทั่วไปอาจเริ่มที่การเขียนฟีเจอร์ แต่ FDE ต้องขุดให้ลึกกว่านั้น:

ตอนนี้ฝ่ายบริการลูกค้าจัดการกี่ tickets ต่อวัน;
คำถามแบบไหนที่ AI ตอบได้;
คำตอบแบบไหนที่ต้องให้คนยืนยันอีกที;
ข้อมูลลูกค้าเก็บอยู่ที่ไหน;
ถ้า AI ตอบผิด จะแก้คืนยังไง;
หลังปล่อยจริง เราวัดความเร็วในการตอบ อัตราการแก้ปัญหา หรือต้นทุนแรงงาน

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

เวิร์กโฟลว์ทั้งหมดย่อเหลือหกขั้นตอน:

text

1ค้นหาปัญหา
2→ ย่อยกระบวนการ
3→ สร้างโซลูชัน
4→ สร้างระบบ
5→ ปล่อยสู่ Production
6→ ติดตามผลลัพธ์

ความต้องการเป็นแค่จุดเริ่มต้น ผลลัพธ์ต่างหากคือสิ่งที่ต้องส่งมอบ

เพราะงั้น FDE คนหนึ่งจึงต้องจัดการสามอย่างพร้อมกัน:

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

2. FDE ทำอะไรในแต่ละวัน?

สมมติห้างค้าปลีกแห่งหนึ่งไปหา vendor AI แล้วบอกว่าอยากได้ "Agent เติมสต็อกอัจฉริยะ" ฟังดูเคลียร์ แต่พอ FDE ลงพื้นที่จริง คำถามก็ผุดขึ้นทุกจุด:

สาขาไหนบ้างที่ของขาดสต็อกบ่อย;
การเติมสต็อกดูจากยอดขาย สภาพอากาศ วันหยุด หรือแผนโปรโมชัน;
Agent แค่แนะนำ หรือสั่งซื้อให้เลย;
ยอดที่เกินวงเงินต้องมีคนอนุมัติไหม;
การอัปเดตสต็อกวันละครั้งพอไหม;
ถ้าแนะนำผิด ของค้าง ของเสีย ใครรับผิดชอบ

สัปดาห์แรก พวกเขาอาจไม่ได้เขียนโค้ดแม้แต่บรรทัดเดียว เริ่มจากคุยกับผู้จัดการสาขาว่าตอนนี้เติมสต็อกกันยังไง ไปยืนยันกติกากับฝ่ายซัพพลายเชน เช็คอินเทอร์เฟซกับฝ่าย IT คุยเรื่องสิทธิ์การเข้าถึงกับฝ่าย security พอกระบวนการชัดเจน ก็เข้าสู่เฟสวิศวกรรม:

เชื่อมระบบสต็อก ยอดขาย และระบบสั่งซื้อ;
ล้างข้อมูลย้อนหลัง;
เขียนโมเดล call และ Agent workflow;
สร้างหน้าจอที่พนักงานยอมเปิดใช้จริง;
เพิ่ม login สิทธิ์การเข้าถึง log และการมอนิเตอร์;
เตรียมชุดข้อมูลทดสอบ;
ตั้งค่าระบบตรวจทานโดยคนและระบบสำรองเมื่อล้มเหลว

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

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

FDE ส่งมอบกระบวนการธุรกิจที่กำลังรันจริงอยู่ การทำ Demo สวยๆ เป็นแค่ครึ่งทางของภูเขาเท่านั้น

3. FDE กับโปรแกรมเมอร์ Product Manager และ Pre-sales ต่างกันยังไง?

ตำแหน่งเหล่านี้ทำงานด้วยกันบ่อย และเส้นแบ่งก็คาบเกี่ยวกัน วิธีแยกที่ง่ายที่สุดคือดูว่าแต่ละตำแหน่งรับผิดชอบอะไร

ขอบเขตของ FDE กว้างกว่า เช้านั่งประชุมเรื่องธุรกิจกับลูกค้า ตอนบ่ายไปเช็ค database ตอนเย็นแก้ interface ก็เป็นเรื่องที่เกิดขึ้นได้ในวันเดียว

แต่อย่าเข้าใจผิด: E ใน FDE ยังคงแปลว่า Engineer

ประกาศรับสมัคร FDE ของ OpenAI ในตอนนี้ระบุชัดเจนว่าผู้สมัครต้องเขียนและรีวิวโค้ดระดับ production ทั้ง front-end และ back-end ได้ ตำแหน่งระดับ entry ของ Palantir ก็ยังกำหนดให้คล่องอย่างน้อยหนึ่งภาษาโปรแกรมมิ่ง ดังนั้น ถึงจะเปลี่ยนสายได้โดยไม่จำเป็นต้องมีพื้นฐานวิทยาการคอมพิวเตอร์ แต่การข้ามการเขียนโค้ดไปเลยไม่ใช่ทางเลือก

ถ้าคุณชอบด้านธุรกิจและลูกค้า และไม่อยากเขียนโค้ดระดับ production ในระยะยาว ลองมองหา Deployment Strategist, AI Product Manager, Industry Solution Consultant, Customer Success หรือ AI Consulting ตำแหน่งเหล่านี้ก็อยู่ในสายงาน implementation ของ AI เหมือนกัน แต่ภาระด้านวิศวกรรมเบากว่า

4. ทำไม FDE ถึงมาแรงตอนนี้?

เหตุผลง่ายๆ: ยิ่ง AI แกร่งขึ้น ปัญหาการนำไปใช้งานจริงก็ยิ่งเด่นชัดขึ้น

ทำ Demo ได้ในวันเดียว แต่ Production ไม่ใจดีขนาดนั้น

ต่อ API โมเดล ยัดเอกสารเข้าไปสักหน่อย ทำหน้าแชทสักหน้า ก็ทำให้เจ้านายประทับใจได้ในวันเดียว แต่พอจะปล่อยจริง ข้อมูลสกปรก สิทธิ์การเข้าถึงที่รก ระบบเก่าที่ไม่มี interface ผลลัพธ์โมเดลที่ลอยไปเรื่อย การตรวจสอบความปลอดภัย และพฤติกรรมพนักงาน ทุกอย่างผุดขึ้นมาพร้อมกัน

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

Agent เริ่ม "ลงมือทำ" จริงแล้ว

ถ้าแชทบอทตอบผิด ผู้ใช้เลือกไม่ทำตามก็จบ แต่พอ Agent ส่งอีเมล แก้ไขออเดอร์ ยื่นอนุมัติได้ ข้อผิดพลาดก็พุ่งเข้าไปในธุรกิจโดยตรง

ตัวตน สิทธิ์ การประเมินผล log การตรวจทานโดยคน และการกู้คืนเมื่อระบบผิดปกติ เป็นสิ่งที่ขาดไม่ได้ และเพราะระบบของแต่ละบริษัทไม่เหมือนกัน งานนี้เลยทำเป็นคู่มือกลางไม่ได้

บริษัท AI ต้องการให้ลูกค้าใช้ผลิตภัณฑ์จริง

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

FDE อยู่ใกล้ผลลัพธ์ของลูกค้ามากที่สุด และอยู่ใกล้รายได้ของบริษัท AI มากที่สุด นี่คือเหตุผลเชิงธุรกิจที่ OpenAI และ AWS ยอมทุ่มเงินมหาศาล

AI เขียนโค้ด ขยายผลงานของคนเก่งรอบด้าน

เมื่อก่อนการสร้างชุดแอปพลิเคชันระดับองค์กรต้องรอทีม product, front-end, back-end, data และ O&M ตอนนี้คนเก่งรอบด้านที่มีพื้นฐานวิศวกรรมแข็งแรง ใช้ AI เขียนโค้ด ก็ทำต้นแบบ ผสานระบบ ทดสอบ และปรับแก้ได้เร็วกว่า

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

ช่วงที่แล้วเป็นการแข่งขันว่าโมเดลใครแรงกว่า ช่วงนี้คือใครเอาตัวโมเดลไปฝังในธุรกิจได้จริง FDE ยืนอยู่ตรงช่องว่างนั้น

5. โอกาสของคนธรรมดาอยู่ตรงไหน?

คุณอาจคิด: "นี่ก็ยังเป็นเรื่องของโปรแกรมเมอร์อาวุโสไม่ใช่เหรอ?"

วิศวกรอาวุโสได้เปรียบจริง แต่ความสามารถของ FDE มาจากหลายทาง คนธรรมดาไม่จำเป็นต้องรีเซ็ตเป็นศูนย์ ดูสิ่งที่คุณมีอยู่แล้ว แล้วเติมครึ่งที่ขาดเข้าไป

Software Engineer: ใกล้ที่สุดแล้ว

คุณเขียนโค้ดระดับ production ได้และรู้ว่าระบบล่มเพราะอะไร ขั้นต่อไปคือโฟกัสที่การสัมภาษณ์ผู้ใช้ กระบวนการธุรกิจ ขอบเขตความต้องการ ROI และอัตราการนำไปใช้

วิธีฝึกที่ตรงที่สุดคืออาสาเข้าร่วมประชุมลูกค้า ช่วยงาน pre-sales หรือโครงการ internal AI implementation อย่ารอให้คนอื่นย่อย requirement ลงเป็นการ์ดใน Jira ให้

Data Analyst: เหมาะกับการเปลี่ยนสายมาก

Data analyst ปกติใช้ SQL เป็น อ่านเมตริกเก่ง และคุ้นเคยกับการคุยกับฝ่ายธุรกิจ จุดที่ขาดมักเป็นด้านวิศวกรรม:

จะเปลี่ยน Notebook ให้กลายเป็น service ได้ยังไง;
จะต่อ API ยังไง;
จะจัดการ login และสิทธิ์การเข้าถึงยังไง;
จะ deploy และมอนิเตอร์ยังไง;
จะกู้ระบบหลังเกิด error ยังไง

การเปลี่ยนจากการวิเคราะห์ที่มีแค่คุณคนเดียวที่รันได้ ไปเป็นเครื่องมือที่เพื่อนร่วมงานเปิดใช้ได้ทุกวัน คือก้าวสำคัญของการเป็น FDE

Product, Consulting, Industry Operations: ประสบการณ์ในอุตสาหกรรมมีค่ามาก

ถ้าคุณเคยทำงานโรงงาน คุณจะรู้เรื่องการจัดตารางการผลิตและ yield ถ้าอยู่ไฟแนนซ์ คุณจะรู้เรื่องการตรวจสอบบัญชีและ compliance ถ้าอยู่ค้าปลีก คุณจะรู้เรื่องสต็อกและการบริหารหน้าร้าน ประสบการณ์แบบนี้เรียนจากคลาสไม่กี่คลาสไม่ได้

สิ่งที่ต้องเพิ่มคือการเขียนโปรแกรม ฐานข้อมูล API และการ deploy แล้วก็ลงมือสร้างระบบที่รันจริงด้วยตัวเอง ตำแหน่งเปลี่ยนผ่านที่เป็นไปได้:

Deployment Strategist;
AI Product Manager;
AI Solution Consultant;
Solutions Engineer;
Technical Implementation

เข้าไปในสนาม implementation ของ AI ก่อน แล้วค่อยๆ เพิ่มภาระด้านวิศวกรรม

Pre-sales, Implementation, Solution Architect: คุณอาจมาแล้วครึ่งทาง

คุณคุ้นเคยกับลูกค้า และรู้ดีว่าสิทธิ์การเข้าถึง การจัดซื้อ และระบบเก่าในองค์กรนั้นปวดหัวแค่ไหน ขั้นต่อไปคือข้ามกำแพงการเขียนโค้ด—จากที่เคยทำ Demo และคอนฟิกโปรดักต์ ไปสู่การพัฒนา ทดสอบ deploy และดูแลระบบ

เส้นทางนี้ปกติสั้นกว่าการเปลี่ยนสายอาชีพแบบถอนรากถอนโคน

มือใหม่สุดๆ: ฝึกทักษะจริงสักหนึ่งอย่างก่อน

ถ้าไม่มีพื้นฐานเทคนิคหรือประสบการณ์ในอุตสาหกรรม การรีบวิ่งเข้าไปเป็น FDE จะยากมาก เริ่มจาก data analysis, AI operations, technical support, implementation consulting, junior development หรือผู้ช่วยโซลูชันประจำอุตสาหกรรมก่อน

FDE แทบไม่เคยเป็นจุดแวะแรกของอาชีพ แต่เป็นเหมือนจุดบรรจบของเส้นทางประสบการณ์หลายสายมากกว่า

6. โรดแมป 6 เดือนสำหรับคนธรรมดา

อ่าน job description จบ สิ่งที่ง่ายที่สุดคือบุ๊กมาร์กคอร์สไว้ 6 เดือนผ่านไป บุ๊กมาร์กเต็ม แต่เรซูเม่ยังว่างเปล่า

ใน 6 เดือน คุณสามารถสร้างพอร์ตโฟลิโอ FDE ได้ จะได้งานหรือไม่ ขึ้นอยู่กับประสบการณ์เดิม ระดับวิศวกรรม และความต้องการของบริษัทเป้าหมาย

เดือน 1-2: ปูพื้นฐานวิศวกรรม

เรียนสิ่งที่ใช้บ่อยที่สุดก่อน:

Python หรือ TypeScript;
SQL และฐานข้อมูล;
HTTP, JSON และ API;
Git;
การจัดการ error และการทดสอบ;
Docker และการ deploy ขั้นพื้นฐาน

เกณฑ์รับผ่านของช่วงนี้มีอย่างเดียว: สร้างแอปพลิเคชันเล็กๆ ที่มีฐานข้อมูลและ API ด้วยตัวเอง แล้ว deploy ให้คนอื่นเปิดใช้ได้จริง

ทำให้ input, การประมวลผล, การบันทึก, การแจ้ง error และการ deploy ทำงานครบ เฟรมเวิร์กจะใหม่หรือเก่าไม่สำคัญตอนนี้

เดือน 3-4: สร้างแอปพลิเคชัน AI ที่สมบูรณ์

เพิ่มโมเดล API, RAG, Tool Calling, structured output, log, Evals, การลองใหม่เมื่อล้มเหลว และการตรวจทานโดยคน เข้าไปในแอปเวอร์ชันแรกของคุณ

หยุดทำ "อัปโหลด PDF แล้วคุย" ได้แล้ว เลือกงานที่เฉพาะเจาะจงสักอย่าง:

ช่วยทีมขายจัดระเบียบ lead และให้คำแนะนำในการติดตาม;
ช่วยฝ่ายบริการลูกค้าค้นหาความรู้และร่างคำตอบ;
ช่วยฝ่ายการเงินตรวจเอกสารเบิกจ่าย;
ช่วยฝ่ายปฏิบัติการจัดระเบียบข้อมูลและแจ้งเตือนความผิดปกติ;
ช่วยทีมโรงงานค้นหาข้อมูลการเสียของอุปกรณ์และประวัติการซ่อมบำรุง

ช่วงที่สองโฟกัสสี่เมตริก:

เดือน 5-6: หาผู้ใช้จริง

หาคนยินดีทดลองใช้ 3-5 คน ให้ใช้ต่อเนื่องสองสัปดาห์ติดกัน บันทึกว่าโพรเซสเดิมกับใหม่ใช้เวลาต่างกันเท่าไร ใช้ไปกี่ครั้ง คำแนะนำไหนถูกทำตาม error แบบไหนที่ต้องจัดการด้วยคน และทำไมผู้ใช้ถึงยอมแพ้กลางทาง

ผู้ใช้จริงจะโผล่ปัญหาที่ซ่อนอยู่ทั้งหมด: ข้อมูลสกปรก สิทธิ์ไม่พอ หน้าจอไม่ดี กระบวนการเปลี่ยนตลอด และค่าใช้จ่ายโมเดลที่สูง การแก้ปัญหาเหล่านี้จะทำให้โปรเจกต์ของคุณดูเหมือนโปรเจกต์ FDE จริง

สุดท้าย จัดทำเป็น case study:

text

1ความเป็นมาทางธุรกิจ
2→ กระบวนการเดิม
3→ ทำไมถึงเลือกปัญหานี้
4→ สถาปัตยกรรมระบบ
5→ ข้อมูลและสิทธิ์การเข้าถึง
6→ วิธีการประเมินผล
7→ ผลการใช้งาน
8→ ความล้มเหลวและการปรับแก้
9→ ส่วนที่นำกลับมาใช้ซ้ำได้

เขียนชื่อเฟรมเวิร์กลงเรซูเม่ให้น้อยลง แล้วทำให้ชัดเจนสามอย่าง: ใครใช้ ใช้นานแค่ไหน และเมตริกเปลี่ยนไปอย่างไร

7. หางาน อย่าค้นหาแค่คำว่า "FDE"

ชื่อตำแหน่งนี้ยังไม่ได้รวมเป็นหนึ่งเดียวกัน นอกจาก Forward Deployed Engineer คุณลองค้นเพิ่มได้:

Forward Deployed AI Engineer;
Applied AI Engineer;
AI Deployment Engineer;
Solutions Engineer;
AI Solutions Architect;
Deployment Strategist;
AI Application Delivery Engineer;
AI Solution Engineer;
Agent Engineer

พอเห็นตำแหน่งหนึ่ง ให้เช็คสี่อย่าง:

คุณต้องติดต่อลูกค้าและผู้ใช้หน้างานโดยตรงไหม?
คุณต้องเขียนโค้ด production ด้วยตัวเองไหม?
คุณรับผิดชอบตั้งแต่การค้นหาปัญหาไปจนถึงการปล่อยจริงไหม?
คุณต้องติดตามอัตราการใช้งานและผลลัพธ์ทางธุรกิจหลังปล่อยไหม?

ถ้าครบทั้งสี่ข้อ แสดงว่างานนั้นใกล้เคียง FDE จริง

เตรียมตัวสัมภาษณ์ยังไง

การสัมภาษณ์ FDE มักให้โจทย์คลุมเครือ เช่น: "โรงพยาบาลอยากใช้ AI ลดเวลารอคนไข้ คุณจะทำยังไง?"

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

พอโจทย์ชัดแล้ว ค่อยพูดถึงระบบ สิทธิ์ และขอบเขตการปล่อยจริง สิ่งที่คนสัมภาษณ์อยากเห็นคือคุณเปลี่ยนปัญหาคลุมเครือให้เป็นปัญหาที่ชัดเจนได้ไหม ท่องชื่อโมเดลสิบตัวก็ไม่ช่วยให้ผ่านขั้นนี้

8. ระวัง "งานส่งมอบหน้างานในชื่อใหม่"

พอ FDE มาแรง ตำแหน่งชื่อเดียวกันแต่หน้าที่ต่างกันจะมากขึ้น บางตำแหน่งให้คุณเขียนโค้ดหลัก ขับเคลื่อนการใช้งาน และเอาประสบการณ์หน้างานกลับไปที่ product บางตำแหน่งให้คุณดับไฟหน้างานทุกวัน โค้ดไม่เคยเข้าหลัก repository และวัดผลด้วยจำนวนคน-วันกับแค่การรับงาน

ทั้งคู่เรียกว่า FDE แต่คุณค่าทางอาชีพต่างกันมาก ตอนสัมภาษณ์ถามตรงๆ ได้เลย:

โค้ดที่ FDE เขียนจะเข้า repository ไหน?
ทีมนี้สังกัด product, engineering หรือฝ่ายส่งมอบโปรเจกต์?
โปรเจกต์ดูที่อัตราการใช้งานและเมตริกธุรกิจ หรือแค่รับงานตรงตามเวลา?
ปัญหาหน้างานเข้าไปสู่ product roadmap ได้ยังไง?
หลังโปรเจกต์จบ ใครรับผิดชอบการดูแลระยะยาว?
สามโปรเจกต์ที่ผ่านมาสะสม component ที่ใช้ซ้ำได้อะไรไว้บ้าง?
เวลาส่วนใหญ่ใช้ไปกับการเดินทาง ทำงานหน้างาน และ on-call เท่าไร?

เกณฑ์ตัดสินง่ายๆ:

FDE จริง: เขียนโค้ด production รับผิดชอบผลลัพธ์ และประสบการณ์กลับเข้าสู่ product;
On-site Support เปลือกใหม่: คิดเงินเป็นคน-วัน หมุนรอบการรับงาน และเริ่มจากศูนย์ทุกโปรเจกต์

ถ้าบริษัทให้คุณรับผิดชอบผลลัพธ์ แต่ไม่ให้สิทธิ์เข้าถึงข้อมูล อำนาจตัดสินใจด้านเทคนิค หรือการสนับสนุนจาก product งานนี้มีสิทธิ์เหนื่อยมาก ชื่อตำแหน่งใหม่อาจเป็นแค่ชื่อใหม่ แต่วิธีทำงานอาจไม่ได้เปลี่ยนเลยสักนิด

สุดท้าย

การระเบิดตัวของ FDE บอกว่า AI ก้าวไปอีกขั้นแล้ว โมเดลจะแข็งแกร่งขึ้นเรื่อยๆ แต่ช่องว่างระหว่างโมเดลกับธุรกิจจริงกลับกว้างขึ้น

ลูกค้าต้องการคนที่ลงพื้นที่จริง เชื่อมข้อมูลรกๆ ระบบเก่า กฎธุรกิจ และผู้ใช้จริงเข้าด้วยกัน งานนี้มีเกณฑ์สูง ต้องเขียนโค้ดเป็น เข้าใจธุรกิจ เจอลูกค้า และรับผลลัพธ์หลังปล่อยจริง

โอกาสของคนธรรมดาซ่อนอยู่ในทักษะครึ่งชุดที่มีอยู่แล้ว ถ้าเขียนโค้ดเป็น ก็เติมทักษะธุรกิจและลูกค้า ถ้ารู้จักอุตสาหกรรม ก็เติมวิศวกรรมและการ deploy ถ้าทำ data, pre-sales หรือ implementation มาก็ต่อยอดทักษะปัจจุบัน ถ้าเป็นมือใหม่จริงๆ ก็ฝึกทักษะแข็งๆ ที่พิสูจน์ได้สักหนึ่งอย่างก่อน

ถ้าตอนนี้ให้ทำแค่สิ่งเดียว:

หาปัญหาจริงสักหนึ่งปัญหา สร้างเครื่องมือที่ปล่อยจริงได้ และให้คนสามคนใช้ต่อเนื่องสองสัปดาห์

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

ลิงก์อ้างอิง

เกี่ยวกับผู้เขียน

AI Prompts	ทำเงิน 8 หลักใน 3 เดือน	เรียนรู้แบบเปิดเผย

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

1. จริงๆ แล้ว FDE คืออะไร?

2. FDE ทำอะไรในแต่ละวัน?

3. FDE กับโปรแกรมเมอร์ Product Manager และ Pre-sales ต่างกันยังไง?

4. ทำไม FDE ถึงมาแรงตอนนี้?