Session นี้เป็นการพูดถึงการนำ ai มาใช้งานในองค์กรโดยคุณ Aditya Saxena, McKinsey
คุณ Aditya Saxena เป็นที่ปรึกษาด้านเทคโนโลยี เขาแชร์ว่า เขามักถูกผู้บริหารตั้งคำถามเสมอว่า
เราทุ่มงบซื้อลิขสิทธิ์ GitHub Copilot หรือ Cursor ให้ engineer ทั้งบริษัทแล้ว ทำไมภาพรวมการปล่อย product ของเราถึงยังช้าเหมือนเดิม?
มันคือ "ความจริงที่เจ็บปวด" ที่เขาได้ค้นพบจากการลงพื้นที่จริงของทีม Quantum Black จาก McKinsey
แม้องค์กรจะมี engineer ที่ทำงานไว้ขึ้น 10 เท่า เขียน code ได้รวดเร็วดั่งฟ้าผ่า แต่หากสภาพแวดล้มขององค์กรยังติดอยู่ในกับดักเดิมๆ เราจะไม่มีวันเป็น องค์กร 10 เท่าได้เลย
จริงอยู่ที่ว่า AI ในทุกวันนี้เข้ามาเพื่อช่วยให้เรา "ทำเรื่องเดิมให้เร็วขึ้น" แต่จริงๆ มันไม่ได้แค่นั้น AI มันกำลังบังคับให้เราต้อง "รื้อวิธีทำงานใหม่" ทั้งหมด
ซึ่งคุณ Aditya Saxena ได้แบ่งออกเป็น 3 ส่วน
1.ความเร็วรายบุคคล ไม่เท่ากับ ความเร็วของทีม (The Paradox of Individual Speed)
สถิติจากโลกความจริงยืนยันว่า AI ช่วยเพิ่มประสิทธิภาพในระดับบุคคลได้จริง โดยเฉพาะในจุดที่เคยเป็นคอขวด (Micro-tasks) แต่ความเร็วเหล่านี้ กลับถูกกลืนหายไปในกระบวนการทำงานระดับองค์กรที่ล่าช้า
- Code Review: ความเร็วเพิ่มขึ้นถึง 7 เท่าจากการใช้ GitHub Copilot
- Refactoring & Prototyping: เร็วขึ้น 2-5 เท่า (กรณีศึกษาจาก monday.com ที่ใช้ Cursor)
- Unit Tests: งานที่ engineer เคยเกลียดที่สุด กลับรวดเร็วและเป็นระบบมากขึ้นอย่างมหาศาล
ความย้อนแย้งที่เกิดขึ้น:
แม้ engineer จะส่งโค้ดได้เร็วขึ้นหลายเท่า แต่ Cycle Time ในภาพรวมขององค์กรขนาดใหญ่ ยังคงติดอยู่ที่การ "Launch ทุก 3 เดือน" เท่าเดิม
เพราะความเร็วที่เพิ่มขึ้นถูกนำไปทิ้งไว้ที่ "จุดรอคอย" (waiting) อื่นๆ ในระบบ
AI เป็นตัวขยาย (Amplify) ระบบการทำงานเดิมของเรา หาก Operating Model เดิมพังอยู่แล้ว AI มันจะยิ่งขยายความล้มเหลวนั้นให้ชัดเจน และ เร็วขึ้นกว่าเดิม
2.คอขวดที่มองไม่เห็น
เหตุผลที่ AI ไม่ช่วยให้องค์กรเร็วขึ้นหากไม่แก้ 5 คอขวด (bottlenecks) นี้ การซื้อ AI ก็เป็นเพียงการเสียเงินไปฟรีๆ
- Workflow Fragmentation (ความกระจัดกระจายของกระบวนการ): เรามี AI เขียนโค้ด แต่การเก็บ Requirement ยังอยู่ในไฟล์ PDF หรือ Presentation ที่แยกส่วนกัน ข้อมูลการตัดสินใจสำคัญกระจัดกระจายอยู่ในอีเมล ทำให้ขาด "Traceability" หรือการสืบย้อนข้อมูลที่ AI จะสามารถนำไปประมวลผลต่อได้
- Legacy Architecture & Tech Debt: ระบบที่ถูกเขียนขึ้นเมื่อ 10-15 ปีก่อนที่ไม่มีเอกสารประกอบ (Documentation) และอาศัย "ความรู้เฉพาะตัว" (Tribal Knowledge) ของพนักงานเพียงไม่กี่คน เป็นกำแพงที่ AI ข้ามไม่ได้ เพราะไม่มีคลังข้อมูลให้มันเรียนรู้
- Lack of Governance (ความประมาทภายใต้ความเร็ว): ตัวอย่างที่น่าตกใจ คือ มีบางองค์กรใช้ Cursor แต่สั่ง Disable ระบบ SonarQube (Static Analysis) เพียงเพราะไม่อยากเสียเวลาตรวจสอบคุณภาพ ผล คือ โค้ดที่ผลิตได้เร็ว แต่อาจมีช่องโหว่ด้านความปลอดภัย จนนำไปสู่การหลุดของข้อมูลทั้ง Codebase นี่ คือ วิกฤตจากการขาด Governance ที่เข้มงวดในยุค AI
- Role Ambiguity (ความคลุมเครือในบทบาทหน้าที่): ในทีม Agentic AI ยุคใหม่ Product Manager (PM) เริ่มใช้เครื่องมืออย่าง Lovable หรือ v0 สร้าง Prototype เองโดยข้ามขั้นตอนการ Validation กับทีม technical ผล คือ ได้ฟีเจอร์ที่ดูดีใน Demo แต่ใช้งานจริงไม่ได้ (Architectural failure) เพราะขาดการประสานงานกันที่ชัดเจน
- No Measurable Outcomes: หลายองค์กรวัดผลแค่ "จำนวน Token" หรือ "จำนวนคนที่ผ่านการอบรม" ซึ่งเป็น Input แต่ไม่ได้วัดผลที่ Economic Outcomes จริงๆ เช่น ต้นทุนต่อทีมที่ลดลง หรือรายได้ที่เพิ่มขึ้นจากการออกฟีเจอร์
3. จาก "Story-Driven" สู่ "Spec-Driven"
จุดเปลี่ยนสู่ AI-Native Development การก้าวข้ามขีดจำกัดเดิม องค์กรต้องเปลี่ยน Operating Model จาก Agile ยุคเก่า (ยุค 2000s) ไปสู่โลก AI-Native ที่เน้นความคล่องตัวในระดับ atom
ประเด็นการเปรียบเทียบ | โลกยุคเก่า (Pre-AI/Agile) | โลกยุคใหม่ (AI-Native) |
|---|---|---|
การวางแผนงาน | Story-Driven: เน้นเขียน User Stories | Spec-Driven: เน้นสร้าง Specification ที่ละเอียดเพื่อให้ AI และมนุษย์อ่านเข้าใจตรงกัน |
วงจรการทำงาน | Fixed Sprints: รอบ 2-4 สัปดาห์ (กำลังจะหายไป) | Small Experimentation Cycles: รอบการทดลองขนาดเล็กที่เกิดขึ้นตลอดเวลา |
ขนาดและทักษะทีม | ทีมละ 10 คน แยก FE, BE, QA | 4-5 คน (Multi-skilled): 1 คนทำได้หลายอย่างด้วยความช่วยเหลือของ AI |
บทบาทหน้าที่ | Manual Execution: เน้นการลงมือทำด้วยคน | Orchestrating Agents: เน้นการควบคุมและตรวจสอบ AI Agents ให้ทำงานแทน |
ใน model ใหม่นี้ PM จะเปลี่ยนจากการ "นิยามฟีเจอร์" ไปสู่การ "กำกับดูแลเชิงกลยุทธ์ (Strategic Oversight)" ส่วน engineer จะเปลี่ยนจากการ "เขียนโค้ดซ้ำๆ" ไปเป็นผู้ตรวจทานแผนงาน (Spec) ที่ AI สร้างขึ้น ก่อนสั่งการให้ Agent ลงมือทำ
4. ระบบการวัดผลที่ "เหนือกว่าแค่จำนวน Token"
เพื่อให้การลงทุน AI เห็นผลลัพธ์ทางธุรกิจ (Bottom line) ผู้บริหารต้องใช้ระบบวัดผลแบบองค์รวม (Holistic Measurement System)
ซึ่งประกอบด้วย 4 ระดับ:
- Input: งบประมาณเครื่องมือ, ค่า Token และที่สำคัญที่สุด คือ Change Management และ การ Coaching แบบประกบตัว (Embedded Coaching)
- Adoption: วัดอัตราการใช้งานจริงคู่กับ Developer NPS (ความพึงพอใจของนักพัฒนา) เพื่อดูว่าเครื่องมือช่วยให้ชีวิตเขาดีขึ้นจริงหรือไม่
- Technical Metrics: วัด Velocity, Capacity, Security และ Code Quality (ต้องไม่ลดลงเพื่อแลกกับความเร็ว)
- Economic Outcomes: การลดต้นทุนต่อทีม (Cost per team) และความเร็วในการสร้างรายได้ (Revenue Acceleration) จากการปรับขนาดทีมให้เล็กลงแต่ส่งมอบงานได้มากขึ้น
สรุป
ก้าวต่อไปสู่องค์กร AI-Native การนำ AI มาใช้ไม่ใช่โครงการ IT แต่มัน คือ การ "ออกแบบการบริหารจัดการใหม่ (Redesigning the Operating Model)"
ข้อมูลจาก McKinsey พบว่าองค์กรที่เป็น Top Performers มีโอกาสมากกว่ากลุ่มอื่น ถึง 7 เท่า ที่จะเปลี่ยน Workflow ทั้งหมดให้เป็น AI-Native และ มากกว่า 6 เท่า ที่จะกล้าสร้างบทบาทหน้าที่ใหม่ (AI-Native Roles) เพื่อรองรับเทคโนโลยีนี้
โดยเฉพาะคำแนะนำของคุณ Aditya Saxena คือ อย่าพยายามเปลี่ยนทั้งองค์กรในวันเดียว แต่ให้เริ่มด้วย "Front Runner Approach"
เลือกทีมหัวกะทิขนาดเล็กมาทดลองใช้กระบวนการ AI-Native PDLC (Product Development Life Cycle) เต็มรูปแบบ เพื่อพิสูจน์ผลลัพธ์ (Reap the benefits) ก่อนจึงค่อยขยายผล