เว็บแอปรุ่นแรกไม่จำเป็นต้องทำทุกอย่างที่ธุรกิจอาจใช้ในอนาคต แต่ควรทำงานสำคัญอย่างน้อยหนึ่งเส้นทางให้จบได้จริง การมีหน้าจอหลายหน้าแต่ต้องกลับไปจัดการส่วนสำคัญนอกระบบโดยไม่มีแผน อาจยังไม่ช่วยให้ทีมทำงานดีขึ้น
เริ่มจากผลที่ต้องการ เช่น ให้คำขอมีผู้รับผิดชอบและติดตามจนปิดงานได้ แล้วค่อยถามว่าต้องมีข้อมูล การตัดสินใจ และหน้าจอใดเพื่อให้ผลนั้นเกิดขึ้น
เลือกงานหนึ่งเส้นทางที่มีจุดเริ่มและจุดจบ
สมมติทีมต้องการระบบรับคำขอภายใน เส้นทางแรกอาจเริ่มที่พนักงานส่งเรื่อง ผู้ดูแลจัดผู้รับผิดชอบ คนทำงานแจ้งผล และผู้แจ้งเห็นว่าจบหรือยัง แต่ละขั้นต้องมีข้อมูลพอให้คนถัดไปทำงานต่อได้
เขียนด้วยภาษาของทีมว่ารุ่นแรกช่วยใคร ทำงานอะไร และจะถือว่าสำเร็จเมื่อใด ถ้าคำอธิบายยังเป็นเพียง “ระบบรวมทุกอย่าง” จะจัดลำดับฟังก์ชันได้ยาก เพราะทุกคนตีความขอบเขตต่างกัน
เลือกกลุ่มเริ่มต้นที่มีงานจริงและดูแลระหว่างทดลองได้ ขอบเขตเล็กหมายถึงจำกัดชนิดงานหรือกลุ่มผู้ใช้ให้ชัด ไม่ใช่ปล่อยให้กระบวนการขาดช่วงจนไม่มีใครใช้จนจบได้
แยกสิ่งที่ต้องมี สิ่งที่ใช้วิธีชั่วคราวได้ และสิ่งที่รอได้
สำหรับตัวอย่างรับคำขอ การสร้างรายการ มอบหมาย ติดตามสถานะ และเปิดดูผลอาจเป็นส่วนหลัก ส่วนรายงานหลายรูปแบบหรือการปรับหน้าตารายคนอาจยังไม่จำเป็นต่อการพิสูจน์งานนั้น
บางงานใช้คนช่วยช่วงเริ่มต้นได้ เช่น ให้ผู้ดูแลจัดหมวดคำขอแทนการจัดอัตโนมัติ แต่ต้องระบุว่าใครทำ ใช้ข้อมูลจากไหน และเมื่อปริมาณเพิ่มจะทบทวนอย่างไร ไม่ซ่อนภาระนี้ไว้เป็นงานนอกขอบเขตที่ไม่มีผู้รับผิดชอบ
สิทธิ์ดูข้อมูล การบันทึกที่เชื่อถือได้ และการแก้ปัญหาที่กระทบผู้ใช้ไม่ควรถูกตัดเพียงเพื่อลดจำนวนฟังก์ชัน ระดับที่จำเป็นต้องพิจารณาจากข้อมูลและงานที่ระบบจะรับผิดชอบจริง
เก็บรายการที่รอไว้พร้อมเหตุผลและเงื่อนไขกลับมาพิจารณา เช่น เพิ่มรายงานอีกแบบเมื่อผู้ดูแลเริ่มต้องใช้ตัดสินใจ ไม่ถือว่าทุกไอเดียที่จดไว้กลายเป็นคำสัญญาส่งมอบทันที
ทดลองข้อสมมติที่อาจทำให้โครงการไปต่อไม่ได้ก่อน
หากระบบต้องดึงข้อมูลจากโปรแกรมเดิม แต่ยังไม่รู้ว่าเข้าถึงข้อมูลนั้นได้หรือไม่ ควรพิสูจน์จุดนี้ก่อนทำหน้าจอครบ หากคนใช้ต้องกรอกข้อมูลจำนวนมาก ให้ลองด้วยต้นแบบเพื่อดูว่างานนั้นทำได้จริงในเวลาทำงานปกติหรือไม่
แนวทางช่วง Alpha ของ GOV.UK ใช้ต้นแบบเพื่อทดสอบแนวคิดและข้อสมมติที่เสี่ยง โดยไม่จำเป็นต้องสร้างทั้งเส้นทางทั้งหมดให้สมบูรณ์ หลักนี้ช่วยให้แยกการเรียนรู้ก่อนลงทุนออกจากการสร้างระบบพร้อมใช้
ต้นแบบกับรุ่นที่ให้คนทำงานจริงเป็นคนละระดับ อย่าใช้หน้าจอที่จำลองผลลัพธ์เป็นหลักฐานว่าการเชื่อมต่อ สิทธิ์ หรือการเก็บข้อมูลทำงานแล้ว ระบุให้ชัดว่าส่วนไหนยังจำลองและส่วนไหนพิสูจน์แล้ว
บันทึกด้วยว่าหลักฐานแบบใดจะทำให้เปลี่ยนทางเลือก หากแหล่งข้อมูลจำเป็นให้ข้อมูลที่เชื่อถือไม่ได้ อาจต้องปรับกระบวนการหรือลดขอบเขต แทนการทำหน้าจอเพิ่มครอบจุดที่ยังไม่แก้
เปลี่ยนฟังก์ชันเป็นเกณฑ์รับงานที่สังเกตได้
แทนคำว่า “มีแจ้งเตือน” ให้ระบุว่าเมื่อมีการมอบหมาย ผู้รับที่ถูกต้องเห็นคำขอใด และหากส่งไม่สำเร็จใครพบปัญหา แทนคำว่า “มีค้นหา” ให้เตรียมตัวอย่างรายการที่ทีมต้องหาและข้อมูลที่ใช้ค้น
เขียนกรณีปกติควบคู่กับกรณีผิดพลาด เช่น ส่งข้อมูลซ้ำ ไม่มีสิทธิ์ หรือยกเลิกงานกลางทาง กำหนดผลที่ต้องการโดยไม่ผูกกับรายละเอียดหน้าจอเกินจำเป็น เพื่อให้ทีมออกแบบทางที่ใช้ง่ายได้
ตกลงข้อมูลเริ่มต้นที่จะนำเข้าและวิธีตรวจ ไม่ใช่รอถึงวันเปิดระบบแล้วพบว่ารายชื่อหรือรหัสงานเดิมยังไม่พร้อม
เปิดใช้เพื่อเรียนรู้ แล้วเลือกงานถัดไปจากหลักฐาน
ก่อนทดลอง กำหนดผู้ช่วยตอบปัญหา วิธีรับข้อเสนอแนะ และวิธีทำงานเมื่อระบบใช้ไม่ได้ บอกทีมว่าช่วงทดลองครอบคลุมอะไรและยังใช้วิธีเดิมในส่วนใด
เก็บทั้งงานที่ทำสำเร็จ จุดที่ต้องย้อนกลับไปแก้ และเวลาที่ทีมต้องช่วยกันนอกระบบ อย่าดูเพียงจำนวนบัญชีที่สร้างหรือจำนวนคนเปิดหน้า เพราะอาจยังไม่มีใครทำงานครบเส้นทาง
หลังทดลอง ให้จัดลำดับสิ่งที่แก้ปัญหาซ้ำหรือขยายงานที่พิสูจน์แล้วก่อนเพิ่มฟังก์ชันใหม่ทั้งหมด อ่านวิธีเขียนโจทย์และเกณฑ์ตรวจรับเว็บแอป และเลือกซื้อซอฟต์แวร์หรือพัฒนาเอง เพื่อใช้เปรียบเทียบทางเลือกด้วยขอบเขตเดียวกัน
มีรายการฟังก์ชันยาว แต่ยังไม่รู้ควรเริ่มตรงไหน?
Talvyn Labs ช่วยเปลี่ยนโจทย์ธุรกิจเป็นขอบเขตรุ่นแรกที่ทดลองและตรวจรับได้ พร้อมแยกสิ่งที่จำเป็นออกจากสิ่งที่เพิ่มภายหลัง
กำหนดขอบเขตเว็บแอปรุ่นแรก