บันทึก 002 ของอนรรฆ: 01 พฤศจิกายน 2026
ช่วงนี้เดินทางบ่อย มีเวลาฟุ้งซ้าน ผมเลยมีเรื่องสงสัยอยู่เรื่องหนึ่งว่า ถ้า AI ทำให้แต่ละคนในทีมทำงานเร็วขึ้นเรื่อยๆ แล้ว SDLC ของเราควรเปลี่ยนไปยังไงบ้าง?
เวลาพูดถึง SDLC เรามักนึกถึงภาพประมาณว่า Product คิด feature และเขียน PRD, Designer ทำ UI, Developer (FE, BE) ลงมือสร้าง, QA ตรวจ แล้วก็ปล่อยแอปออกไป แต่ในงานจริง feature หนึ่งไม่ได้เดินทางผ่านแค่คนกลุ่มนี้ถูกไหม มันยังมีอีกหลายมิติที่ต้องเจอ เช่น
- Data ต้องช่วยคิดว่าจะวัดผลอะไร
- Marketing ต้องคิดว่าจะสื่อสารหรือเปิดตัวยังไง
- Support ต้องรู้ว่า feature ทำงานยังไงเพื่อเตรียมตอบลูกค้า
- Security อาจต้องเข้ามาดูเรื่องความเสี่ยงว่ามีจุดไหนน่ากลัวบ้างไหม
รวมถึงทีมอื่นๆ ที่อาจต้องใช้ข้อมูลจาก feature นี้ต่อ
พอยิ่งลองมองลงไปในแต่ละช่วง ผมรู้สึกว่าปัญหาที่น่าสนใจอาจไม่ได้อยู่ที่ว่าเรามีกี่ขั้นตอน แต่อยู่ที่ว่า Context ของ feature เดินทางผ่านขั้นตอนเหล่านั้นได้ดีแค่ไหน
คนกำลังเป็นตัวกลางคอยแปล Context อยู่หรือเปล่า
ตัวอย่างหนึ่งที่ผมเจอบ่อยคือตอนปั้น UI นึกภาพเวลาทำ feature ใหม่ หลักๆฝั่ง Dev ก็จะเปิด Figma ดูหน้าตาและ flow ของหน้าจอ แต่ในขณะเดียวกัน Designer เองก็อาจมีเอกสารอีกชุดที่อธิบายรายละเอียดเพิ่มเติม เช่น behavior บางจุด เงื่อนไขของ UI หรือข้อมูลบางอย่างที่ไม่ได้ใส่ไว้ใน Figma และปัญหาที่จะเล่าก็คือสองจุดนี้บางครั้งไม่ได้ตรงกันทั้งหมด ฮ่าๆๆ
บางรายละเอียดมีอยู่ในเอกสาร แต่ไม่มีอยู่ใน Figma บางจุดใน Figma อาจเปลี่ยนไปแล้วแต่เอกสารยังเป็นข้อมูลเดิม หรือบางครั้งเราเองก็ไม่รู้ด้วยซ้ำว่ามีรายละเอียดอีกส่วนอยู่ในเอกสารอีกชุด
สุดท้าย Dev ต้องคอยเปิดดูทั้งสองที่ แล้วพยายามประกอบข้อมูลหรือเดาเองว่าอันไหนคือสิ่งที่ควรทำจริงๆ บางครั้งก็ต้องย้อนกลับไปถามว่า “ตรงนี้เอาตาม Figma หรือเอกสาร?” หรือบางครั้งทำไปแล้วถึงเพิ่งรู้ว่ามี requirement อีกจุดที่ไม่ได้เห็นใน Figma ก็กลายเป็นว่า “ขอโทษครับ ตรงนี้ผมบ่เห็นว่ามีระบุไว้”
แม้แต่ interaction ที่ดูเหมือนเป็นรายละเอียดเล็กๆ ก็ยังมีผล เช่น หน้านี้ตอนเปิดควรเป็น navigation แบบไหน? push ที่ slide จากขวาไปซ้ายไหม? หรือควรเป็น modal presentation ที่ขึ้นมาจากด้านล่าง
ซึ่งถ้าไม่ได้ระบุไว้ชัด Dev ก็ต้องเดา ถาม หรืออาศัย pattern จากหน้าที่มีอยู่แล้ว ตรงนี้ทำให้ผมรู้สึกว่า บางทีปัญหาอาจไม่ใช่ว่าเราไม่มีข้อมูล แต่เป็นเพราะ ข้อมูลเรื่องเดียวกันกระจายอยู่หลาย artifact และบางครั้งแต่ละ artifact ก็ไม่ sync กัน และเคส UI ก็เป็นเพียงตัวอย่างหนึ่งเท่านั้น
แล้วถามมองในมุมกว้างๆที่อาจจะเกิดขึ้นได้ใน feature เดียวกันหละ API contract อาจอยู่ในเอกสารของทีม Backend เป้าหมายของ feature อยู่ใน PRD, decision บางอย่างอยู่ใน Slack thread รายละเอียดเรื่อง analytics อยู่ในอีกเอกสารหนึ่ง ส่วนเหตุผลว่าทำไมถึงออกแบบแบบนี้ อาจอยู่ในบท chat ตอนประชุมเมื่อสองสัปดาห์ก่อนก็ได้
Dev ต้องเปิดข้อมูลหลายที่ พยายามประกอบเรื่องราวทั้งหมดเข้าด้วยกัน แล้วค่อยเริ่มลงมือทำ บางครั้งก็ต้องย้อนกลับไปถามว่า
- ตรงนี้ใน design ตั้งใจให้ทำงานแบบไหน?
- API รองรับ case นี้หรือยัง?
- ถ้า user ทำแบบนี้ เราควร track analytics อะไร?
ผมเลยเริ่มสงสัยว่า ใน SDLC ปัจจุบัน คนจำนวนมากกำลังใช้เวลาไปกับการเป็นตัวกลางคอยหา รวม แปล และส่งต่อ context หรือเปล่า คือพอมี AI agent เข้ามา เราอาจรู้สึกว่าปัญหานี้จะหายไป เพราะ agent สามารถช่วยเขียน code หรือทำงานแทนเราได้เร็วมาก แต่ถ้า agent ได้เห็นแค่ ticket หนึ่งใบ, doc สักชุด หรือ prompt ที่อาจถูกตัดออกมาจากบริบททั้งหมด ปัญหาก็ยังเหมือนเดิม
เพียงแต่จากเดิมที่คนต้องรวบรวม context ให้ Dev ตอนนี้ Dev ก็ต้องรวบรวม context ให้ AI อีกที เช่น ถ้า agent เข้าถึง Figma เพื่อดู UI และ interaction ได้ หรือสามารถอ่าน API spec แล้วนำไปใช้ตอน implement ได้โดยตรง ก็น่าจะช่วยลดงานส่วนนี้ลงได้เยอะ
แต่กลับมาที่ตัวอย่าง UI ก่อนหน้า ถ้า agent อ่านได้แค่ Figma มันก็อาจพลาดรายละเอียดที่อยู่ในเอกสาร แต่ถ้าให้มันอ่านทั้ง Figma และเอกสารพร้อมกัน แล้วข้อมูลสองชุดไม่ตรงกัน คำถามใหม่ก็กลายเป็น Agent ควรจะเชื่ออันไหน? ตรงนี้ทำให้ผมคิดว่าสิ่งที่สำคัญกว่าคำว่า “เชื่อมต่อได้” ก็คือ Agent รู้ไหมว่าข้อมูลไหนที่เกี่ยวข้องกัน ข้อมูลไหนล่าสุด และ decision ไหนคือสิ่งที่ทีมตกลงกันแล้วจริงๆ เพราะต่อให้ AI อ่านข้อมูลได้ทุกระบบ แต่ถ้ามี PRD สามเวอร์ชัน API spec สองชุด และ discussion กระจายอยู่สิบ thread เราอาจแค่ทำให้ AI ค้นข้อมูลที่สับสนได้เร็วขึ้นเท่านั้นเอง
Analytics เป็นอีกตัวอย่างที่ผมว่าน่าสนใจ
Analytics เป็นอีกจุดหนึ่งที่ทำให้ผมเห็นเรื่อง context ค่อนข้างชัด สมมติ Dev กำลังสร้างหน้าจอใหม่ขึ้นมา คำถามที่มักเกิดขึ้นคือ
- หน้านี้ต้องยิง event อะไรบ้าง?
- ปุ่มนี้ถ้ากดแล้วควรตั้งชื่อ event ว่าอะไร?
- ตรงนี้ต้องส่ง property อะไรเพิ่มไหม?
แต่จริงๆ แล้วผมคิดว่าคำถามเหล่านี้อาจมาช้าไปสัก step เพราะคำถามแรกน่าจะเป็น เราอยากเรียนรู้อะไรจาก behavior ของ user ใน feature นี้? มากกว่า
Product อาจเริ่มจากสมมติฐาน เช่น เราคิดว่าถ้า user เห็นข้อมูลนี้แล้วจะตัดสินใจง่ายขึ้น จากนั้น Data ช่วยคิดว่า ถ้าอยากพิสูจน์สมมติฐานนี้ เราต้องเก็บข้อมูลอะไร ซึ่งของพวกนี้พอมันชัดขึ้น มันก็จะออกมาเป็น event, properties หรือ metric บางอย่าง
Dev ไม่จำเป็นต้องเดาชื่อ event จาก UI ที่อยู่ตรงหน้า แต่สามารถ implement จาก measurement plan ที่มีเหตุผลรองรับอยู่แล้วได้เลย ส่วนทีม Product เองก็สามารถตรวจต่อได้ว่า behavior จริงที่เกิดขึ้น ตรงกับสิ่งที่เราตั้งใจวัดหรือไม่
สิ่งที่ผมสนใจตรงนี้คือ ถ้า คำถาม → สมมติฐาน → วิธีวัดผล → implementation เชื่อมต่อกันตั้งแต่ต้น งาน analytics อาจไม่ใช่งานที่ค่อยมานั่งเติม event ตอน feature ใกล้เสร็จอีกต่อไป และ AI ก็อาจเข้ามาช่วยตรงนี้ได้มากกว่าการ generate ชื่อ event เช่น อ่าน goal จาก PRD แล้วช่วยร่าง measurement plan ให้ Data review หรือดู implementation แล้วตรวจว่ามี tracking point ไหนที่ตกหล่นจาก plan หรือไม่
ถ้าลองมอง SDLC เป็นวงจรของ Context และ Artifact
ผมลองเปลี่ยนมุมมองจาก SDLC ที่เป็นขั้นตอน มาเป็น flow แบบนี้
ปัญหาของลูกค้า
→ เป้าหมายและสมมติฐาน
→ PRD
→ Design / API / Analytics Spec
→ Implementation
→ QA / Security
→ Launch
→ Usage Data / Feedback / Support
→ กลับไปสู่ปัญหาและโอกาสรอบถัดไป
แต่ละช่วงจะสร้างสิ่งของบางอย่างออกมา เช่น
PRD
Design
API contract
Analytics plan
Code
Test case
Release note
Support guide
Dashboard
Customer feedback
ผมมองสิ่งเหล่านี้เป็น Artifact ของ feature ปัญหาคือทุกวันนี้ artifact เหล่านี้มักถูกเก็บแยกกันตามเครื่องมือและตามแต่ละทีม ซึ่งเอาจริงๆ ก็ไม่ได้ผิดอะไรนะ แต่ผมแค่รู้สึกว่าความสัมพันธ์ระหว่างมันมักหายไป
- เราอาจเห็น design แต่ไม่รู้ว่ามันตอบ hypothesis ไหน
- เห็น event
xxx_completedแต่ไม่รู้ว่า metric ไหนกำลังใช้ event นี้ - เห็น test case แต่ไม่รู้ว่ามันกำลัง protect requirement หรือ edge case ตัวไหน
- เห็น support ticket แต่ไม่รู้ว่าเกี่ยวข้องกับ decision ตอนออกแบบ feature ตรงไหน
ตรงนี้ทำให้ผมสงสัยว่า สิ่งที่เราควรพยายามเก็บให้ดีขึ้นอาจไม่ใช่แค่ Artifact แต่คือความสัมพันธ์ระหว่าง Artifact เหล่านั้นมากกว่า
แล้ว Agent ควรอยู่ตรงไหนในภาพนี้
ถ้ามองแบบนี้ AI agent อาจไม่ได้มีบทบาทแค่
รับ ticket → เขียน code
แต่สามารถทำงานต่อจาก context ที่ทีมสร้างไว้ได้ เช่น
- อ่าน PRD แล้วช่วยเตรียมคำถามที่ requirement ยังไม่ชัด
- อ่าน Design เทียบกับ API contract แล้วหาจุดที่อาจไม่ตรงกัน
ตอน implement ก็ใช้ Design + API + Analytics spec เป็น context พร้อมกัน ช่วยสร้าง test case จาก acceptance criteria และ edge case ก่อน release ช่วยตรวจว่า implementation, analytics และ documentation ครบหรือยัง หรือหลัง release ช่วยรวม usage data, support issue และ feedback กลับมาให้ทีมเห็นภาพเดียวกัน
ผมคิดว่าส่วนที่น่าสนใจที่สุดไม่ใช่ว่า AI ทำแต่ละงานได้หรือไม่ได้ เพราะถ้ามันมี context ต่อเนื่องตั้งแต่ต้นน้ำถึงปลายน้ำ มันจะสามารถช่วยงานคนละแบบกับ AI ที่เราใช้ผ่าน prompt เป็นครั้งๆ ได้ดีขึ้นกว่าเดิมแน่ๆ
ในมุมนี้ ผมคิดว่า AI อาจมีประโยชน์ในฐานะตัวช่วยรักษาความต่อเนื่องของ context มากพอ ๆ กับการเป็นตัวช่วยลงมือทำงาน แต่ก็นั่นแหละ ผมว่าการเชื่อมทุก tool เข้าหา AI ไม่ได้แปลว่าปัญหานี้จะหายไปเอง
ผมว่าเรายังต้องรู้ว่าอะไรคือ source of truth ข้อมูลอะไรยังเป็น draft, decision ไหนถูกยกเลิกแล้ว ข้อมูลไหนเป็นเพียง discussion และข้อมูลไหนคือสิ่งที่ทีมตกลงกันจริงๆ รวมถึงจุดไหนที่ AI สามารถตัดสินใจต่อได้ และจุดไหนควรหยุดแล้วกลับมาถามคนที่รับผิดชอบ
สิ่งที่ผมคิดว่าน่าจะต้อง “ไหลต่อกัน”
ถ้าจะทดลองทำให้วงจรนี้ลื่นขึ้น ผมคิดว่าอาจเริ่มจากหลักง่าย ๆ ก่อน
- เก็บ “Why” ไว้กับ “What” — งานหนึ่งไม่ควรบอกแค่ว่าต้องสร้างอะไร แต่ควรพอรู้ด้วยว่ากำลังแก้ปัญหาอะไร และคาดหวังผลลัพธ์แบบไหน
- เชื่อม Artifact เข้ากับ Feature เดียวกัน — PRD, Design, API, Analytics, Test และ Release ควรมีวิธีตามย้อนกลับหากันได้
- เก็บ Decision ไว้ด้วย — บางครั้งสิ่งที่มีค่าที่สุดไม่ใช่คำตอบสุดท้าย แต่คือเหตุผลว่าทำไมทีมถึงเลือกทางนี้และไม่เลือกอีกทาง
- ทำข้อมูลให้ทั้งคนและ Agent ใช้ต่อได้ — ข้อมูลที่อ่านง่ายสำหรับคนอย่างเดียวอาจยังไม่พอ ในขณะเดียวกันข้อมูลที่ structured มากแต่คนอ่านไม่รู้เรื่องก็ไม่ดีเหมือนกัน
- มี Source of Truth ที่ชัดเจน — Agent และเราต้องรู้ว่าควรเชื่อข้อมูลจากไหน และถ้าข้อมูลสองแหล่ง conflict กันก็ควรมีวิธีรู้ว่าต้องถามใคร (ก็คงถามเราหนะแหละ) ไม่อย่างนั้นการมี context เยอะอาจกลายเป็น noise
- ให้ผลลัพธ์หลัง Launch ไหลย้อนกลับมา — Analytics, Support ticket, Feedback และปัญหาที่เกิดจริงควรย้อนกลับมาเป็น context ของการตัดสินใจรอบถัดไป
- ยังมี Human Decision อยู่ในวงจร — Agent ช่วยหา ช่วยเตรียม ช่วยตรวจและช่วยเชื่อมข้อมูลได้ แต่ decision ที่มีผลต่อ Product, Design, Data, Engineering หรือ Security ยังควรมีคนมารับผิดชอบให้ชัดเจน
บางทีเป้าหมายอาจไม่ใช่แค่ทำแต่ละขั้นให้เร็วขึ้น
สิ่งที่ผมกำลังสงสัยคือ ในช่วงแรกที่ AI มา เราอาจโฟกัสตรงที่ว่า จะทำให้ Developer เขียน code เร็วขึ้นยังไง? แต่เมื่อแต่ละขั้นตอนเริ่มเร็วขึ้น bottleneck อาจย้ายไปอยู่ที่อื่น
- Developer สร้าง feature ได้เร็วขึ้น แต่ยังต้องรอ requirement
- Design ทำ prototype ได้เร็วขึ้น แต่ยังต้องรอ decision
- Data วิเคราะห์ได้เร็วขึ้น แต่ไม่รู้ว่า feature ถูกสร้างขึ้นจาก hypothesis อะไร
- AI เขียน code ได้เร็วมาก แต่ต้องรอคนมาอธิบาย context ให้ครบก่อนทุกครั้ง
สุดท้ายความเร็วของระบบอาจไม่ได้ขึ้นอยู่กับว่าขั้นตอนไหนเร็วที่สุด มันอาจไปอยู่ตรงที่ข้อมูลสามารถไหลไปแต่ละขั้นตอนได้ดีแค่ไหน
ผมเลยเริ่มคิดว่า SDLC ในยุค AI อาจไม่ได้เปลี่ยนเพราะเรามี Agent มาแทน Developer, Designer หรือ QA แต่อาจเปลี่ยนเพราะ Agent ทำให้เราสามารถรักษาและส่งต่อ Context ระหว่างคน เครื่องมือ และแต่ละช่วงของการพัฒนาได้ดีขึ้น
ถ้า Product, Design, Engineering, Data, QA, Marketing, Support และ Security สามารถทำงานต่อจาก ความเข้าใจชุดเดียวกัน ได้มากขึ้น สิ่งที่เราเรียกว่า “การส่งต่องาน” อาจจะค่อยๆ ลดลง แล้วกลายเป็นทุกคน รวมถึง AI agent กำลังทำงานต่อกันอยู่บนวงจรเดียวกัน
จริงๆ ผมยังไม่แน่ใจว่ารูปแบบสุดท้ายของมันควรหน้าตาเป็นแบบไหนหรอกนะ แต่ผมคิดว่านี่อาจเป็นโจทย์ที่น่าสนใจกว่าการถามเพียงว่า “เราจะให้ AI ทำอะไรแทนเราได้อีกบ้าง? (ฟังดูเหมือนช่วงนี้มันทำได้แทบทุกอย่างแล้วนะ 555)”
สุดท้ายบางทีคำถามอาจเป็น “เราจะออกแบบ Context ยังไง ออกแบบการทำงานแบบไหน เพื่อให้ทั้งคนและ AI สามารถทำงานต่อจากกันได้ โดยไม่ต้องเริ่มทำความเข้าใจใหม่ทุกครั้ง?” ตรงนี้อาจเป็นหนึ่งในโจทย์สำคัญที่เราต้องมาทดลองกันกับ SDLC ในยุค AI จริงๆ
GLHF ครับ