เริ่มจากการเก็บ requirements

พี่หนุ่มแชร์เรื่อง: software requirement engineering

เมื่อก่อนเราเอา test scenarios + test case แยกออกจากกัน แต่จริงๆ แล้วควรที่จะรวมกัน ปัจจุบันทางพี่หนุ่มได้เอาสิ่งเหล่านี้ออกมาเป็น skill file

ทำออกมาเป็น markdown file และให้ human in the loop ในการ verify requirements

คำถาม

ให้ AI ตั้งคำถามได้ดีแค่ไหน - domain ทั่วๆ ไปจะตอบได้ แต่ถ้า domain เฉพาะอาจจะยังตั้งคำถามไม่ได้ ในส่วนของ requirement elicitation หยิบบางเทคนิคออกมา และสร้างเป็น workflow ได้

AI จะ generate เป็น As...a, i want..., so..that เป็น frame สำหรับมือใหม่ใช้งาน แต่เมื่อเอามาใช้งานกับที่มีความเฉพาะสูงการใช้งานแบบนี้ มันไม่ละเอียดพอ

หลายๆ domain ถ้านิ่งแล้ว เราสามารถให้ ai เก็บได้ แต่ถ้าเป็น domain เฉพาะยังไงก็ใช้คนในการเก็บอยู่ดี

use case หนึ่งที่เราสามารถสร้าง feedback loop โดยการสร้าง ui คุยกับลูกค้าดูได้เลย

การใช้ ai ในการสร้าง ai generate ทำงานให้ เราจำเป็นต้องมี domain expert ในการตรวจด้วย เพราะคนที่รู้ว่าที่ถูกเป็นอย่างไร

ในการใช้งานสรุปงาน เราต้องรู้บริบทและมีความรู้บางอย่างด้วย

Human อยู่ตรงไหน

เราควรแบ่งความเสี่ยง ความงานไหนเสี่ยง งานไหนไม่เสี่ยง ดังนั้นเราควรทำ ai risk management ถ้าเสี่ยงมากเราต้องลงไปอยู่ในลูปการสร้าง แต่ถ้าไม่เสี่ยงมากค่อยให้ ai ทำเลย

Analysis

คำถาม
ถ้า ai สามารถแยกความกำกวมและความขัดแย้งระหว่าง requirements ได้ไหม?

มุมพี่บอม: ถ้าเราใส่ขั้นตอนให้ ai มันอาจจะสามารถดูได้ ถ้าเราให้ข้อมูลมากพอ ถ้าเราใส่ information มากไปมันอาจจะทำไม่ได้

มันมองหาความแตกต่างบางอย่างให้ได้ แต่ตัดสินใจให้เราไม่ได้

สำหรับพี่หนุ่มการโยน TOR ภาครัฐ เข้าไปมันทำไม่ได้ เพราะมันไม่ใช่ Requirements แต่จะช่วยให้เราสามารถวางแผนได้

เราใช้ model ถูกงานหรือเปล่า เพราะถ้าใช้งานผิด model อาจจะไม่ได้อย่างที่ต้องการ เช่น opus ช่วยแพลนนิ่ง แล้วให้ model อื่นทำงาน และให้ opus review อีกที

เทคนิคในการบริหาร context ไม่ให้เยอะเกินไป อาจจะย่อยให้เล็กลง และทำ index ให้มันได้

Trust ในการนำ AI มาใช้

หลายๆ ท่านใช้วิธีของการให้คนในทีมใช้ แต่ resposibility ต้องเป็นต้องคนที่ใช้ AI

เรื่องหนึ่งที่หน้าสนใจ คือ ตอนนี้เรายังไม่มีเรื่องกำกับดูแลการใช้ ai และเรายังเลี่ยงเรื่องการกำกับดูแล (AI Governance)

ใครรับผิดชอบ

  • ข้อมูลหลุด
  • เกินความเสียหาย

ใครรับผิดชอบ

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

เราควรมี domain knowledge เป็นคนดูอีกที

ในมุมของคนทำงานถ้าไม่จำเป็นต้องสร้าง production grade เขาสามารถทำขึ้นมาใช้เองได้เลย

ตอนสร้าง vibe code แล้วต้องส่งไปถึงงาน product support ที่โดน SLA มาคุมจะสร้างปัญหามากขึ้น เพราะคนที่ดูแลไม่ได้สร้างมันเอง

ถ้าเอา ai มาสร้างเอกสารต่างๆ เราไว้ใจได้แค่ไหน?

สร้าง technical design โอเคเลย แต่ถ้าเป็น diagram คำถามคือ เราอ่านกันหรือเปล่า?

เอา ai มาสร้างเอกสาร design ได้ไหม? - ในภาพใหญ่ยังไม่ได้ ถ้าให้สร้างเบื้องต้น และเรามาปรับตามที่เราคิดไว้แบบนี้พอได้อยู่

พวกเรา generate เอกสารมาเยอะ แต่เราไม่คุยกัน ทั่งๆ ที่เอกสารถูกทำเพื่อให้คนสื่อสารกัน

living document จะต้องทำเอกสารก่อนเริ่มทำ... แต่ถ้าเป็น documents สำหรับส่งอาจจะทำทีหลังได้ แต่จะกิน token เยอะมาก

ในการจัดการเอกสารเก่ากับ source code ปัจจุบัน เราสามารถให้ ai ไปเช็คดูได้ ว่ามีส่วนไหนที่ไม่ตรงกัน ถ้าเราทำเองอาจจะใช้เวลานาน ซึ่งช่วยลดเวลาได้เยอะมาก

AI สำหรับ Coding

ในการที่เราจะใช้ ai ในการ vibe code เราควรที่จะต้องให้มี test ขึ้นมาก่อน ซึ่งมันจะไปเข้าเรื่องของ shift-left testing, tdd

เวลา ai เริ่มต้นมันก็จะเข้าไป scan ก่อน ไม่ต่างกับเวลาที่ dev เข้าไปอ่านโค๊ด ซึ่งใช้เวลาน้อยกว่า

เคสแก้ระบบเก่า...​เอา manual ให้ ai อ่านเพื่อให้เข้าใจ business แล้วค่อยเข้าไปอ่าน code เพื่อให้ ai เข้าไปอ่าน source code เพื่ออัพเดท

ปัญหาที่เจอ คือ context มันใหญ่มากๆ เราควรสรุปและทำแผนออกมาก่อน แต่ก็ไม่สามารถปล่อย ai ทำทั้งหมดอยู่ดี เราจำเป็นต้องคอยเช็คแต่ละส่วน

output ของงานที่ดี มาจาก input ที่ดี ในการ coding ความรู้เชิงลึกใน software engineer จึงสำคัญมาก

clean code คือ การทำให้ code ที่มีอ่านได้ง่าย ไม่ว่าจะเป็นเรา หรือ ai ก็ตาม

ถ้าเราไปรับงานต่อจากอีกบริษัทหนึ่งที่หมดสัญญา เราจะต้องทำอะไร

ในมุมภาพรัฐ เจอปัญหานี้บ่อย ซึ่งยังไม่มีคำตอบว่าจะทำยังไง เพราะถ้าเราไปรับช่วงต่อ คงต้องใช้ ai ในการเข้าไปเรียนรู้