ความเจ็บปวดเมื่อทีมปรับตัวใช้ AI-First Workflow

สวัสดีเพื่อนๆ เป็ดทุกคนนะครับ ผมเป็ด P

ปัจจุบันผมทำงานเป็น QA อยู่ในบริษัท Software House แห่งหนึ่งในไทย

วันนี้ผมอยากจะมาแชร์ประสบการณ์ตรงเกี่ยวกับความเจ็บปวดและความท้าทาย

เมื่อทีมต้องเปลี่ยนวิธีการทำงานแบบหน้ามือเป็นหลังมือ เพื่อต้อนรับยุคสมัยของ AI

ทีมของผมกำลังพัฒนาแพลตฟอร์มหนึ่งที่ค่อนข้างเฉพาะทางมากๆ โดยปกติเรา Adopt แนวคิด Agile มาใช้ มี Framework หลักคือ Scrum แบ่ง Squad และรันงานกันเป็น Sprint ตามสไตล์คลาสสิกทั่วไป แต่ความท้าทายของโปรเจกต์นี้คือ Requirement ที่เฉพาะทางสุดๆ บวกกับไทม์ไลน์ที่กระชั้นชิดมาก ด้วยเหตุนี้ ทางเบื้องบนจึงตัดสินใจนำ AI-First Workflow เข้ามาใช้ในการทำงาน

คอขวดของ Workflow เดิม

ก่อนจะไปพูดถึง AI ผมขอเล่าถึงลูปการทำงานแบบเดิมก่อน เริ่มจาก:

Business Team ไปเก็บ Requirements จากลูกค้า > วิเคราะห์หา Solution > นำเสนอลูกค้า > ลูกค้าเคาะ > ส่งต่อให้ Designer ทำ Wireframe/Figma > คอนเฟิร์มอีกรอบ > เตรียมการ์ด (Story) ใน Jira > นำมา Grooming กับทีม Dev & QA เพื่อลง Sprint

มองเผินๆ เหมือนจะราบรื่นใช่ไหมครับ? แต่ในความเป็นจริง คอขวด (Bottleneck) มักจะไปกองอยู่ตรงการคอนเฟิร์มกับลูกค้า ว่าสิ่งที่กำลังจะทำนั้นถูกต้องและตรงใจจริงๆ หรือเปล่า

สิ่งนี้ทำให้เกิดการตีกลับและแก้ใหม่ซ้ำแล้วซ้ำเล่า นำไปสู่ภัยพิบัติระดับหมอลำ:

• ต้องเริ่มทำของไปก่อน ทั้งที่ Requirement ยังไม่นิ่ง พอโดนเปลี่ยนก็กระทบระบบ ต้องมานั่งแก้ Dependencies หรือหนักสุดคือ "โละทิ้งแล้วทำใหม่"

• ทีม Business ไม่มีเวลามากพอที่จะเตรียมของนิ่งๆ ส่งให้ Designer

• เตรียมของไป Refine ไม่ทัน เกิดปัญหาการ์ดเปล่า หรือรายละเอียดเปลี่ยนแต่ไม่มีเวลาทำ Impact Analysis

• ไม่ได้อัปเดตเอกสาร ดีไซน์ หรือแม้แต่การ์ด ทำให้ QA ที่ออก Test Case ไปแล้ว หรือ Dev ที่เขียนโค้ดไปแล้ว ต้องเผชิญกับการเปลี่ยน Requirement กลาง Sprint

• ความรู้ความเข้าใจที่ไม่ตรงกัน (Knowledge Silos) ทำให้เคสหลุด และ Performance รวมของทีมแย่ลง

การมาถึงของยุคสมัย AI, SDD และ BMAD

ในยุคที่ AI บูม กูรูทั้งไทยและเทศเริ่มนำ AI มาประยุกต์ใช้มากกว่าแค่แชทถามตอบหรือ Gen โค้ด เกิดเป็นวิธีการทำงานใหม่ๆ มากมาย และสิ่งที่เราจะไม่พูดถึงไม่ได้เลยก็คือ Spec-Driven Development (SDD)

SDD คือวิธีการพัฒนาซอฟต์แวร์ที่เริ่มต้นจากการเขียน "ไฟล์ Spec" (Specification) ซึ่งเป็นไฟล์เอกสารที่ระบุข้อกำหนดของโปรดักต์อย่างละเอียด มันคือการรวมร่างข้อมูลตั้งแต่ Requirement ตั้งต้น, Solution ที่จะใช้ ไปจนถึงเอกสารย่อยอื่นๆ เพื่อเตรียมไว้ให้ AI เข้ามาอ่านและทำความเข้าใจ

และสำหรับโปรเจกต์ที่เฉพาะทางแบบนี้ ทีมเราได้นำหลายๆ Method มาผสมผสานกัน โดยอีกหนึ่งแรงบันดาลใจสำคัญที่เข้ามาจัดระเบียบให้ Workflow นี้เป็นรูปเป็นร่างขึ้นมาคือแนวคิดแบบ BMAD (Brief, Model, Architecture, Design) ซึ่งเป็นโครงสร้างที่ช่วยให้เราและ AI มองเห็นภาพเดียวกันตั้งแต่จุดเริ่มต้นไปจนถึงโครงสร้างเชิงลึก จนได้ภาพIdeally แบบนรี้:

1. System Initialization: เริ่มจากการกำหนด Roles, Rules, Skills และ Workflow เพื่อตกลงกันว่าแต่ละบทบาท (Role) ต้องทำอะไร ได้ผลลัพธ์เป็นอะไร มีกฎเกณฑ์อย่างไร และจะส่งต่องานกันแบบไหน

2. Business & Requirements (Brief & Model): ทีม PO/PM เข้ามาทำ BRD (Business Requirements Docs) > ส่งต่อให้ BSA แตกย่อยเป็น PRD ของแต่ละ Module และย่อยเป็น Epic

3. Technical Design (Architecture): ส่งต่อให้ Tech Lead เข้ามาทำ Tech-Spec กำหนด Schema และ API ต่างๆ

4. Prototyping & Feedback (Design): Designer นำข้อมูลมาทำ Front-end-spec และสร้าง Clickable Prototype > ทีม Business นำไปคุยกับลูกค้าเพื่อทำ Feedback Loop จนกว่าจะคอนเฟิร์มผ่าน

5. Testing Preparation: เมื่อยืนยันแล้ว QA จะนำมาออกแบบ Test-spec (Test cases, Test Data)

6. Development & TDD: Dev เข้ามารับช่วงต่อ พัฒนาระบบโดยอิงจาก Test cases ตามหลักการของ TDD (Test-Driven Development) และ Shift-Left Testing

7. Automation: เมื่อทำเสร็จและผ่าน Manual Test ซ่อมบั๊กเรียบร้อย QA จะใช้เอกสารทั้งหมดเป็นบริบทให้ AI ช่วยสร้าง Automate Test Scripts สำหรับ Flow ที่มี High Impact ต่อไป >> ยำว่า Ideally นะจัฟ 5555

(จริงๆ แล้วในมุมของการทำงานส่วนตัว ก่อนที่ทีมจะเปลี่ยนมาใช้ Workflow นี้ ผมในฐานะ QA ก็มีการใช้งาน AI เพื่อช่วยรีวิวและเสริม Test case ไม่ให้หลุด Edge cases สำคัญๆ อยู่แล้ว AI จึงไม่ใช่เรื่องใหม่ซะทีเดียวสำหรับตัวผมเอง)

ทีมเริ่ม Adopt การทำงานท่านี้มาได้ประมาณ 1 เดือน เพิ่งจบช่วง Develop ของ Epic แรกไป สิ่งที่เห็นชัดเจนคือ Clickable Prototype ช่วยให้ Feedback Loop ไวขึ้นมาก และภาพรวมของงานเดินหน้าได้เร็วขึ้นซึ่งค่อนข้างดูดีเลยแหละ แต่ว่าาาาาาา

เปลือกนอกที่ดูดี กับ Struggle ที่ซ่อนอยู่

ถึงแม้ภาพข้างบนจะดูสวยงามและเป็น Ideally แค่ไหน แต่นั่นไม่ใช่เจตนาหลักที่ผมเขียนบทความนี้ครับ ผมอยากมาแชร์ Struggles ที่ทีมต้องเจอตั้งแต่เริ่ม Introduce คอนเซปต์นี้จนถึงปัจจุบัน ซึ่งน่าสนใจมากว่ามันไปสอดคล้องกับบทความ Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl ของคุณ Birgitta Böckeler ในหลายๆ เรื่องเลยครับ แนะนำให้ทุกท่านตามไปอ่านนะครับ link:

1. ไม่ใช่ทุกคนที่จะใช้ AI เป็น: หลายคนรู้จัก AI แค่ในฐานะแชทบอท ไม่เข้าใจการผนวกแชทเข้ากับ IDE หรือการทำเอกสาร ช่วงแรกหลายคนไม่กล้าใช้เพราะกลัวเปลือง Cost แต่พอพ้นระยะกลัว ก็กลายเป็นระยะ "ผลาญ Token" โดยไม่รู้วิธีทำ Optimization ทั้งในแง่ของ Token Cost และ Time Consumption ไปกันแบบเบิ้มๆเลยทีเดียว

2. ยึดติดกับความสมบูรณ์แบบ (Perfectionism): หลายคนคาดหวังให้ AI ทำงานออกมาเพอร์เฟกต์ 100% ไร้ข้อผิดพลาดตั้งแต่ Zero-shot ซึ่งสะท้อนให้เห็นถึงความยังไม่เข้าใจธรรมชาติในการทำงานของ Generative AI

3. ตามหา Master Prompt แบบครอบจักรวาล: สมาชิกหลายคนไม่อยากเรียนรู้ทักษะการสั่งงาน AI แต่อยากได้ "Master Prompt" คำสั่งเดียวจบ ซึ่งบทความก็ชี้ให้เห็นว่า การจะใช้ AI ให้ได้ผลในกระบวนการ SDD นั้น "การจัดการ Context (บริบท)" สำคัญกว่าการพึ่งพา Prompt สำเร็จรูป เพราะในแต่ละโปรเจกต์ โค้ดหรือ Spec ย่อมมี Local Context ที่แตกต่างกัน สไตล์การสั่งงานหรือความละเอียดต่างๆล้วนแล้วแต่มีผลกับผลลัพธ์ที่น้อง(AI) จะสร้างออกมาให้

4. Cost มหาศาลจากการทดลองใช้: ในช่วงที่ทุกคนกำลังลองผิดลองถูก ต้นทุนในการเรียกใช้งาน AI ก็พุ่งสูงขึ้นอย่างหลีกเลี่ยงไม่ได้

5. ความเครียดและกำแพงทางเทคโนโลยี: สมาชิกทีมที่ไม่ใช่ฝั่ง Tech (Non-Dev) ต้องช็อกหลายยก เพราะต้องมาเรียนรู้วิธีการทำงานใน IDE หรือการใช้ Git ซึ่งได้สร้างความกดดันมหาศาล แถมยังเป็นภาคบังคับ เพราะการทำ SDD Spec ต้องถูกจัดการเป็นเวอร์ชันและอยู่ภายใต้ Version Control เหมือนกับโค้ดครับ

6. เชื่อใจ AI แบบหลับหูหลับตา: นี่คือเรื่องที่น่ากลัวที่สุด สมาชิกบางคนเชื่อผลลัพธ์ที่ AI สร้างออกมาโดยไม่ได้ทำการ Crosscheck เลย ซึ่งเรื่องนี้ผมพยายามเน้นย้ำและแสดงความกังวลกับทีมมาตลอดว่า เราขาด Human in the loop ไม่ได้เด็ดขาด หน้าที่ของ AI คือการตีความ Spec ออกมา แต่ผู้ที่จะตรวจทานและยืนยันความถูกต้องว่าสิ่งที่ AI สร้างนั้นตรงตามหลักการและใช้งานได้จริง ก็ยังต้องเป็น "มนุษย์" เสมอ จำไว้นะครับ อย่าไว้ใจมัน เดี๋ยวก็ได้เกิด Cybernatic Revolution กัน(มุกเนิร์ด 40K ครับ ไม่ต้องใส่ใจ)

7. ผลลัพธ์หลอนจี๊ด ที่ถึงจะระวังแค่ไหน ก็ยากที่จะไม่หลอน: ต่อให้คุณ Optimize skills ดีแค่ไหน หรือ prompt ระวังยังไง ความหลอนก็ยังสถิตย์กับ AI เป็นธรรมดา จนเหมือนในบทความที่ได้เล่าไว้ว่ายิ่งพยายามทำให้มันออกมาดี มันกลับแย่ลง ไม่ว่าจะเป็นการต้องแลกความหลอนโดยสูบ Token และเวลามหาศาล บอกได้เลยครับ ต้องลอง (สวดอ้อนวอนต่อ Machine Spirit ว่าขอดีๆ อย่าหลอนนะ อย่าหลอนนนน)

เริ่มออกเป็นการบ่นไปซะเยอะแล้วครับ แต่ท้ายที่สุด การเปลี่ยนผ่านไปสู่ AI-First Workflow มันไม่ใช่แค่การเปลี่ยนเครื่องมือ แต่มันคือการเปลี่ยน Mindset และทักษะของคนทั้งทีม เราไม่สามารถกระโดดข้ามพื้นฐานแล้วไปคาดหวังผลลัพธ์วิเศษจาก AI ได้หรอกครับ ตอนนี้ การทำงานกับ AI ยังต้องการความรู้และความชำนาญของคนใน Function นั้นๆ อยู่ เพื่อทำหน้าที่ตรวจสอบและควบคุมการทำงานของมัน หากไม่ได้มีความรู้ เราจะไปตัดสินได้ไงว่าสิ่งที่ AI มันทำออกมานั้นมันถูกต้องหรือไม่

ซึ่งดูจากทรงแล้ว Gap ในส่วนนี้ อาจจะโดนปิดไปไวกว่าที่เราๆ คิดก็ได้ครับ

นั่นทำให้ผมเริ่มพิจารณาการขายก๋วยเตี๋ยวเป็นอาชีพทางเลือกแล้วแหละ อาาาา เนื้อเปื่อยยยยย

สุดท้ายแล้วจริงๆ ผมออกตัวว่าผมยังคงเชื่อมั่นในศักยภาพของมนุษย์ และสนับสนุนแนวคิดมอง AI ให้เป็นเครื่องมือ และใช้มันในฐานะของเครื่องมือทุ่นแรง อย่าให้ถึงขั้นที่ถ้าเกิด Cloudflare Incident แบบรอบล่าสุดละทำงานไม่ได้เลยนะครับ 555555555555 (ขำๆ นะครับ)

คิดเห็นยังไง หรือใครเจออะไรโดนใจจอร์จ คอมเมนท์พูดคุยแลกเปลี่ยนได้นะครับ

คุณไม่ได้กำลังเจอเรื่องนี้คนเดียว เราจะผ่านมันไปด้วยกันครับ

อย่าลืมดื่มน้ำให้เพียงพอด้วยนะครับ สวัสดีครับ