วิธีสร้าง Proof of Concept สำหรับแอปพลิเคชันซอฟต์แวร์ทีละขั้นตอน

การสร้าง Proof of Concept (PoC) ส่วนใหญ่มักไม่ได้ล้มเหลวเพราะทีมงานไม่สามารถสร้างมันขึ้นมาได้ แต่เป็นเพราะไม่มีใครระบุให้ชัดเจนตั้งแต่แรกว่ามันถูกสร้างขึ้นมาเพื่อพิสูจน์อะไรกันแน่ แนวทางจาก AWS Prescriptive Guidance ระบุไว้สรุปได้ว่า บ่อยครั้งที่ PoC มักถูกปฏิบัติเหมือนเป็นการโชว์เดโมทางเทคนิคเพื่อให้เกิดความประทับใจ มากกว่าที่จะเป็นการทดลองอย่างจริงจังเพื่อมุ่งเน้นการเรียนรู้ เดโมถูกสร้างขึ้นมาเพื่อให้คนชอบ แต่การทดลองถูกสร้างขึ้นมาเพื่อให้เราสามารถล้มเหลวได้

นี่คือกระบวนการ 7 ขั้นตอนในการสร้าง PoC สำหรับแอปพลิเคชันซอฟต์แวร์ ซึ่งใช้งานได้จริงไม่ว่าความเสี่ยงของคุณจะเป็นระบบบูรณาการใหม่ โมเดลแมชชีนเลิร์นนิง หรือสถาปัตยกรรมที่ไม่เคยลองมาก่อน ผู้เขียนซึ่งทำงานอยู่ที่ Entalogics บริษัทที่สร้าง PoC และต้นแบบสำหรับสตาร์ทอัพ ได้สรุปแนวทางนี้ขึ้นมาเพื่อให้ทีมงานสามารถตรวจสอบความเสี่ยงสูงสุดได้ก่อนที่จะลงทุนลงแรงไปกับทั้งโปรเจกต์

Proof of Concept ทำหน้าที่ตอบคำถามเพียงข้อเดียวเท่านั้น นั่นคือ สิ่งเสี่ยงเฉพาะเจาะจงนี้สามารถสร้างขึ้นและทำให้ใช้งานได้จริงในสภาพแวดล้อมของเราหรือไม่ มันไม่ใช่ผลิตภัณฑ์ ไม่ใช่งานเดโมสำหรับนักลงทุน และไม่ใช่การปล่อยเวอร์ชันแรกออกมา หากต้องการแยกระหว่าง PoC ต้นแบบ และ MVP ให้ชัดเจน PoC ทดสอบว่าสร้างได้ไหม ต้นแบบทดสอบว่าคนเข้าใจไหม และ MVP ทดสอบว่าคนจะยอมจ่ายเงินซื้อไหม บทความนี้จะพูดถึงเฉพาะข้อแรกเท่านั้น

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

ขั้นตอนแรกคือการเริ่มต้นจากสิ่งท้าทายที่สุด แทนที่จะเริ่มต้นด้วยการลิสต์รายการฟีเจอร์ทั้งหมด ให้เริ่มด้วยการลิสต์สิ่งที่อาจทำให้โปรเจกต์ทั้งหมดกลายเป็น 0 แล้วเลือกตัวที่น่ากลัวที่สุด แนวคิดนี้เรียกว่า risk-first thinking ซึ่งเป็นแนวคิดดั้งเดิม โดยในเอกสารปี 1988 ของ Barry Boehm เกี่ยวกับโมเดลแบบเกลียว ได้อธิบายถึงแนวทางที่ขับเคลื่อนด้วยความเสี่ยงสำหรับกระบวนการซอฟต์แวร์

ขั้นตอนที่สองคือการเขียนเกณฑ์ความสำเร็จและเกณฑ์การยุติงานก่อนที่จะลงมือสร้าง ซึ่งเป็นขั้นตอนที่หลายทีมมักมองข้ามแต่เป็นสิ่งที่ทำให้กระบวนการทั้งหมดมีความตรงไปตรงมา โดยต้องกำหนดเงื่อนไขผ่าน รหัสผ่าน หรือสถานะใช่/ไม่ใช่ รวมถึงเงื่อนไขการหยุดทำงานเมื่อผลลัพธ์ไม่เป็นไปตามเป้าหมาย และข้อจำกัดด้านคุณภาพ ความเร็ว และต้นทุน ไม่ใช่แค่ดูว่าระบบทำงานได้หรือไม่เท่านั้น