30 ต.ค. เวลา 12:19 • วิทยาศาสตร์ & เทคโนโลยี

“Forward Deployed Engineer (FDE)”

เมื่อ AI เขียนโค้ดได้เร็วขึ้น ทำไม Forward Deployed Engineer (FDE) ถึงยิ่งสำคัญ?
ทุกวันนี้ AI ช่วยให้เราสร้าง Software หรือ Prototype ได้เร็วขึ้นมากครับ งานบางอย่างที่เคยใช้เวลาหลายสัปดาห์ อาจทำเสร็จได้ในไม่กี่วัน
แต่สิ่งที่น่าสนใจคือ “การสร้างระบบให้ทำงานได้ กับการทำให้ระบบนั้นถูกนำไปใช้งานจริง กลับเป็นคนละเรื่องกัน”
หลายองค์กรสามารถสร้าง AI Demo ที่ดูดีมากวาดฝันผู้บริหารในห้องประชุม ทำให้ผู้บริหารเห็นแล้วก็ชอบ ทุกคนเชื่อว่าน่าจะช่วยเพิ่ม Productivity ได้มากๆ แล้วละ…
แต่พอจะนำไปใช้งานจริง กลับพบว่า “ข้อมูลอยู่คนละระบบ, มีข้อจำกัดด้าน Security, กระบวนการทำงานซับซ้อนกว่าที่คิด และสิ่งที่ผู้ใช้งานต้องการก็อาจไม่ตรงกับ Requirement ที่ได้รับมาตั้งแต่แรก”
สุดท้าย AI ที่ดูดีตอน Demo อาจไปไม่ถึง Production หรือขึ้น Production แล้วแต่ไม่มีใครใช้งานต่อ? 🤔
ผมคิดว่านี่เป็นหนึ่งในความท้าทายสำคัญของ “AI Transformation” วันนี้ครับ เพราะต่อให้เทคโนโลยีเก่งขึ้นแค่ไหน หากไม่สามารถนำไปแก้ปัญหาธุรกิจได้จริง คุณค่าที่ควรจะเกิดขึ้นก็อาจไม่เกิด
และนี่เป็นเหตุผลที่ผมสนใจบทบาทหนึ่งซึ่งกำลังได้รับความสำคัญมากขึ้นในบริษัทเทคโนโลยี นั่นคือ “Forward Deployed Engineer หรือ FDE”
1. แล้ว FDE คือใคร และต่างจาก Software Engineer ทั่วไปอย่างไร?
อธิบายง่ายๆ FDE คือ Software Engineer ที่เข้าไปทำงานใกล้ชิดกับลูกค้าหรือ Business User เพื่อทำความเข้าใจปัญหาที่แท้จริง แล้วร่วมออกแบบ พัฒนา และเชื่อมต่อระบบต่างๆ จนสามารถนำ Solution ไปใช้งานได้จริง
ถ้าจะเปรียบเทียบก็คล้ายกับการผสมความสามารถของ “Developer + Consultant + Product/Project Manager” เข้าด้วยกันในบางส่วน
แต่ FDE ไม่ใช่แค่ Developer ที่ถูกส่งไปนั่งประจำบริษัทลูกค้านะครับ
ความแตกต่างสำคัญคือ ไม่ได้รอรับ Requirement แล้วเขียนโค้ดตามที่ได้รับมาเพียงอย่างเดียว แต่ต้องเข้าไปทำความเข้าใจปัญหา ตั้งคำถามกับความต้องการของลูกค้า และช่วยหาวิธีแก้ไขที่เหมาะสมตั้งแต่ต้น
เพราะบางครั้งสิ่งที่ลูกค้าขอ อาจไม่ใช่สิ่งที่ช่วยแก้ปัญหาของเขาได้ดีที่สุด
จริงๆ แล้ว FDE ไม่ใช่ตำแหน่งใหม่
* บริษัทอย่าง Palantir ใช้แนวทางนี้มานานแล้ว
* ขณะที่ OpenAI และบริษัท Enterprise AI อีกหลายแห่งก็ให้ความสำคัญกับบทบาทลักษณะนี้มากขึ้น
คนที่จะทำหน้าที่นี้ได้ดีต้องมีพื้นฐาน Software Engineering ที่แข็งแรง สามารถพัฒนาและเชื่อมต่อระบบให้ใช้งานจริงได้ ขณะเดียวกันก็ต้องเข้าใจ Business สื่อสารกับผู้ใช้งาน และรับมือกับปัญหาที่ไม่ได้มี Requirement ชัดเจนตั้งแต่แรก
แน่นอนว่า FDE ไม่จำเป็นต้องเก่งทุกอย่าง หรือทำงานแทนผู้เชี่ยวชาญด้าน Architecture, Security, Data และ Product ได้ทั้งหมด แต่ต้องสามารถทำงานร่วมกับคนเหล่านี้เพื่อให้ Solution เกิดขึ้นได้จริง
2. สิ่งที่ผมว่าน่าสนใจกว่าตำแหน่ง FDE คือแนวคิดนี้อาจกลายเป็นมาตรฐานใหม่ของการทำงานในทีม Technology
ที่ผ่านมาเราคุ้นเคยกับการทำงานที่ Business ส่ง Requirement ให้ Product Team นำไปออกแบบ และ Engineering รับไปพัฒนาต่อประมาณนี้ใช่ไหม? 🤔
วิธีนี้ไม่ได้ผิดครับ แต่หากแต่ละทีมทำงานแยกกันมากเกินไป เราอาจพบว่าทุกฝ่ายส่งมอบงานของตัวเองได้ครบ แต่ธุรกิจกลับไม่ได้ผลลัพธ์ตามที่ต้องการ
แนวคิดแบบ FDE จึงพยายามทำให้คนที่เข้าใจ Business คนที่ออกแบบ Product และคนที่สร้าง Technology ทำงานร่วมกันใกล้ชิดขึ้นตั้งแต่ต้น
เช่น Engineer อาจเข้ามาร่วมทำ Discovery กับ UXUI และ Product Team ตั้งแต่ยังไม่ได้สรุป PRD เพื่อช่วยมองทั้งปัญหาธุรกิจ ความเป็นไปได้ทางเทคโนโลยี และข้อจำกัดของระบบจริงไปพร้อมกัน
แต่ละทีมยังมีหน้าที่และความรับผิดชอบของตัวเอง เพียงแต่ไม่ได้ทำงานแบบส่งเอกสารต่อกันเป็นทอดๆ โดยแทบไม่ได้เรียนรู้ปัญหาร่วมกัน
และเมื่อวิธีทำงานเปลี่ยน วิธีวัดความสำเร็จก็ควรเปลี่ยนตามด้วย
จากเดิมที่อาจมองเพียงว่าระบบพัฒนาเสร็จตามแผน หรือขึ้น Production ได้แล้วหรือยัง เราต้องมองให้ครบอีก 3 ระดับ คือ
1. Delivery — ระบบถูกพัฒนาและส่งมอบได้จริง
2. Adoption — ผู้ใช้งานนำระบบไปใช้ในกระบวนการทำงานจริง
3. Business Outcome — การใช้งานนั้นช่วยให้ธุรกิจดีขึ้นอย่างไร เช่น ลดเวลา ลดต้นทุน หรือเพิ่มคุณภาพงาน
เพราะ “Delivery ไม่ได้เท่ากับ Adoption และการมีคนใช้งานก็ไม่ได้รับประกันว่าจะเกิด Business Outcome เสมอไป”
ผมคิดว่าแนวโน้มนี้จะส่งผลต่อการพัฒนาคนในองค์กรด้วยครับ
“Software Engineer อาจต้องเข้าใจ Business และ Product Thinking มากขึ้น”
“ขณะที่ Product Team ก็ควรเข้าใจ Technology มากพอที่จะร่วมออกแบบและตัดสินใจกับ Engineering ได้อย่างมีคุณภาพ?”
แต่ไม่ได้หมายความว่า Engineer ทุกคนต้องเปลี่ยนมาเป็น FDE 😅
เพราะองค์กรยังต้องการผู้เชี่ยวชาญเฉพาะทางที่มีความรู้ลึกเช่นเดิม เพียงแต่ควรสร้างความสามารถลักษณะนี้ให้เป็นอีกหนึ่งเส้นทางการเติบโตของคนทำงาน Technology
สำหรับผม การเติบโตของ FDE จึงไม่ใช่แค่เรื่องของ Job Title ที่กำลังมาแรง แต่สะท้อนให้เห็นว่าความคาดหวังต่อคนทำงาน Technology กำลังเปลี่ยนไป
ในวันที่ AI ช่วยให้เราเขียนโค้ดและสร้าง Prototype ได้เร็วขึ้น ความสามารถในการเข้าใจปัญหาที่แท้จริง เลือกสิ่งที่ควรสร้าง และทำให้เทคโนโลยีถูกนำไปใช้จนเกิดผลลัพธ์ อาจยิ่งมีคุณค่ามากขึ้น
“อนาคตของ Software Engineer อาจไม่ได้วัดกันแค่เขียนโค้ดได้เก่งหรือเร็วแค่ไหน แต่รวมถึงความสามารถในการเปลี่ยน Technology ให้เป็น Business Value ได้จริง”
ผมไม่คิดว่าทุกองค์กรจำเป็นต้องมีตำแหน่งชื่อ FDE เหมือนกันทั้งหมด แต่เชื่อว่าความสามารถและรูปแบบการทำงานลักษณะนี้ จะค่อยๆ กลายเป็นสิ่งที่ทีม Technology จำนวนมากต้องมี
เพราะสุดท้ายแล้ว ธุรกิจไม่ได้ต้องการแค่ Software ที่สร้างเสร็จ แต่ต้องการ Solution ที่ช่วยแก้ปัญหาและทำให้งานดีขึ้นจริงครับ 🙂
#วันละเรื่องสองเรื่อง
โฆษณา