ก่อนพัฒนา Web App ต้องเตรียม Requirement อะไร? เริ่มจากงานจริงก่อน Feature List

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

ประโยคอย่าง “อยากได้ระบบหลังบ้าน”, “ต้องมี Dashboard”, “ให้หัวหน้าอนุมัติได้”, “ดึงข้อมูลจาก Excel” หรือ “อยากให้ใช้ง่าย” เป็นจุดเริ่มต้นที่ดี แต่ยังไม่ใช่ Requirement ที่ทีมพัฒนาควรนำไปตี Scope โดยตรง เพราะแต่ละคนสามารถตีความคำเดียวกันต่างกันได้ บทความนี้จึงชวนทำ Requirement Discovery Pack แบบใช้งานจริงก่อน เพื่อให้ความต้องการค่อย ๆ เปลี่ยนจากคำกว้างเป็น Workflow, Data, Rule และ Acceptance ที่ตรวจได้

แนวคิดนี้สอดคล้องกับ GOV.UK Service Manual เรื่อง User research in discovery ที่แนะนำให้ทำความเข้าใจว่าใครคือผู้ใช้ เขากำลังพยายามทำอะไร ปัจจุบันทำอย่างไร เจอปัญหาอะไร และต้องการอะไรจากบริการ ก่อนเริ่มวางแผน ออกแบบ หรือสร้างระบบ จุดสำคัญไม่ใช่การเลียนแบบกระบวนการของหน่วยงานรัฐ แต่คือหลักคิดว่า เข้าใจงานและปัญหาก่อนล็อก Solution

เริ่มจาก “งานหนึ่งชิ้นเดินอย่างไร” ก่อนถามว่าระบบต้องมีหน้าอะไร

ถ้าทีมกำลังจะทำระบบติดตามใบเสนอราคา ลองยังไม่พูดถึง Dashboard หรือเมนูครับ ให้เริ่มจากงานหนึ่งรายการแทน เช่น ลูกค้าขอราคาเข้ามาทางไหน ใครรับเรื่อง ใครเตรียมข้อมูล ใครตรวจราคา ใครอนุมัติ ใครส่งให้ลูกค้า แล้วถ้าลูกค้าขอแก้ราคาเกิดอะไรขึ้นต่อ

การเดินตามงานจริงแบบนี้ช่วยเปิดรายละเอียดที่ Feature List มักซ่อนอยู่ เช่น พนักงานขายบางคนสร้างใบเสนอราคาได้แต่อนุมัติไม่ได้, รายการบางประเภทต้องผ่านผู้จัดการอีกคน, ลูกค้าคนเดิมอาจมีหลายบริษัท, ราคาบางรายการมาจากตารางกลาง, เอกสารที่ส่งแล้วห้ามแก้โดยไม่สร้าง Revision หรือกรณีเร่งด่วนมีเส้นทางอนุมัติไม่เหมือนงานทั่วไป

นี่คือเหตุผลที่บทความ ระบบหลังบ้าน SME ควรเริ่มจากฟังก์ชันไหน แนะนำให้มอง Record, Status, Owner และเวลาเป็นแกนพื้นฐาน แต่ก่อนจะแตกสิ่งเหล่านั้นเป็นฟังก์ชัน เราควรเห็น Workflow ที่มันกำลังรองรับก่อน ไม่อย่างนั้นทีมอาจสร้างสถานะสิบค่าโดยยังไม่รู้ว่าแต่ละสถานะเกิดจากเหตุการณ์อะไรและใครมีสิทธิ์เปลี่ยน

Requirement Discovery Pack 8 ช่องที่ควรตอบให้ได้ก่อนสรุป Scope

กรอบต่อไปนี้ไม่ใช่มาตรฐานสากลและไม่ได้บังคับว่าทุกโครงการต้องใช้เอกสารหน้าตาเดียวกัน แต่เป็น Worksheet ที่กองบรรณาธิการ Social Plus System สังเคราะห์ขึ้นเพื่อช่วยให้ทีมธุรกิจรวบรวมข้อมูลที่มักกระจัดกระจายอยู่ในแชต ไฟล์ Excel และความจำของคนทำงาน ให้มาอยู่ในภาพเดียวกัน

1. User / Role — ใครเกี่ยวข้องกับงานนี้จริง

อย่าเริ่มด้วยคำว่า Admin กับ Staff เพียงสองคำ ให้เขียนตามบทบาทในงาน เช่น Sales, Sales Manager, Finance, Warehouse, Customer Service หรือ Customer แล้วถามต่อว่าแต่ละ Role เข้ามาใน Workflow ตอนไหน ต้องเห็นข้อมูลอะไร และมีการตัดสินใจอะไรที่คนอื่นทำแทนไม่ได้

ช่วง Discovery ยังไม่จำเป็นต้องทำ Permission Matrix เต็มรูปแบบ แต่ควรเห็นความแตกต่างของบทบาทก่อน เมื่อ Scope เริ่มนิ่งจึงค่อยลงรายละเอียดว่าใคร View, Create, Edit, Approve, Export หรือลบอะไรได้ด้วย Permission Matrix สำหรับระบบหลังบ้าน

2. Trigger — อะไรทำให้งานเริ่ม

Trigger อาจเป็นลูกค้ากรอกฟอร์ม มีอีเมลเข้า พนักงานสร้างรายการ ระบบภายนอกส่งข้อมูล หรือถึงเวลาที่กำหนดไว้ หาก Trigger ไม่ชัด ทีมมักเริ่มออกแบบหน้าจอจากกลาง Workflow และภายหลังค่อยพบว่ายังไม่มีคำตอบว่าใครเป็นคนสร้าง Record แรกหรือข้อมูลชุดแรกมาจากไหน

3. Current Workflow — วันนี้ทีมทำอย่างไรอยู่จริง

เขียนขั้นตอนปัจจุบันตามที่เกิดจริง แม้มันจะดูไม่สวย เช่น รับเรื่องจาก LINE → คัดลอกลง Excel → ส่งรูปในกลุ่ม → หัวหน้าพิมพ์ “โอเค” → พนักงานแก้สถานะ → ส่งไฟล์ให้บัญชี การเห็นความจริงแบบนี้มีค่ากว่าการเขียน Flow ในอุดมคติ เพราะมันเปิดให้เห็นจุดคัดลอกซ้ำ จุดรอ จุดที่ข้อมูลหาย และจุดที่ไม่มีเจ้าของชัด

GOV.UK Service Standard เน้นการเข้าใจบริบททั้งหมดและปัญหาที่ผู้ใช้กำลังพยายามแก้ แทนการเริ่มจาก Solution ที่เลือกไว้แล้ว หลักนี้ใช้กับระบบธุรกิจได้ดีมาก เพราะ “ทำ Web App” ควรเป็นวิธีหนึ่งในการแก้ Workflow ไม่ใช่เป้าหมายที่บังคับให้ทุกอย่างต้องกลายเป็นฟังก์ชัน

4. Data — ข้อมูลอะไรจำเป็น และ Source of Truth อยู่ที่ไหน

ระบุข้อมูลหลักที่งานต้องใช้ เช่น Customer, Order, Product, Price, Attachment, Status, Approval, Payment หรือ Note แล้วตอบว่าแต่ละข้อมูลมาจากไหน ใครเป็นเจ้าของ และระบบใดควรเป็น Source of Truth หากข้อมูลลูกค้าชุดเดียวมีทั้งใน Excel, LINE, CRM และสมุดของพนักงาน การพัฒนา Web App โดยยังไม่ตกลงเรื่อง Source มักย้ายความสับสนจากเครื่องมือเดิมเข้าระบบใหม่แทน

ไม่จำเป็นต้องออกแบบ Database Schema ในขั้นนี้ คนฝั่งธุรกิจควรอธิบาย “ความหมายของข้อมูล” ให้ถูกก่อน เช่น วันที่นี้คือวันที่ลูกค้าสั่ง วันที่ส่งของ หรือวันที่ปิดงาน เพราะ Field ชื่อ Date เหมือนกันแต่ความหมายต่างกันสามารถทำให้รายงานและ Automation ผิดได้

5. Business Rule — กติกาอะไรที่ระบบต้องเคารพ

Business Rule คือเงื่อนไขที่ทำให้ Workflow ไม่ได้เดินเป็นเส้นตรง เช่น ยอดเกินจำนวนหนึ่งต้องอนุมัติอีกระดับ, ลูกค้าบางประเภทใช้เครดิตเทอมต่างกัน, สินค้าบางหมวดห้ามคืน, เอกสารที่ปิดแล้วแก้ไม่ได้ หรือ Staff เห็นเฉพาะข้อมูลของสาขาตัวเอง

Requirement ที่เขียนว่า “มีระบบอนุมัติ” จึงยังไม่พอ ควรตอบต่อว่า อะไรต้องอนุมัติ ใครอนุมัติ เมื่อไร ข้อมูลอะไรต้องพร้อมก่อนอนุมัติ และถ้าไม่อนุมัติงานย้อนกลับไปไหน คำถามเหล่านี้เปลี่ยนคำกว้างให้เป็น Logic ที่ทีมสามารถออกแบบและทดสอบได้

6. Exception — ถ้างานไม่เดินตาม Happy Path จะเกิดอะไรขึ้น

โครงการจำนวนมากคุยเฉพาะกรณีที่ทุกอย่างถูกต้อง แต่ระบบจริงต้องอยู่กับกรณีข้อมูลไม่ครบ ลูกค้ายกเลิก ผู้อนุมัติลา สินค้าหมด API ไม่ตอบ ไฟล์ผิดประเภท หรือมีรายการซ้ำ การเขียน Exception ตั้งแต่ Discovery ไม่ได้หมายความว่าต้องพัฒนาทุก Edge Case ในเวอร์ชันแรก แต่ช่วยให้ทีมรู้ว่าความเสี่ยงอยู่ตรงไหนและกรณีใดต้องอยู่ใน Minimum Scope

7. Expected Outcome — เมื่อจบ Workflow แล้วอะไรต้องเป็นจริง

อย่าจบ Requirement ที่ “กดบันทึกได้” ให้ถามว่าหลังงานสำเร็จแล้วใครควรเห็นอะไร สถานะต้องเป็นอะไร ต้องมีเอกสารหรือเลขอ้างอิงหรือไม่ ต้องส่งข้อมูลต่อที่ไหน และมีใครต้องได้รับแจ้ง การเขียน Outcome ทำให้ทีมไม่หลงกับการนับจำนวนหน้าจอ แต่กลับมาดูว่าระบบช่วยให้งานหนึ่งชิ้นไปถึงปลายทางได้จริงหรือยัง

8. Acceptance Question — เราจะรู้ได้อย่างไรว่าสิ่งที่ตกลงไว้ทำงานจริง

ก่อนสร้าง Test Case แบบเต็ม ลองเปลี่ยน Requirement เป็นคำถามตรวจรับ เช่น “Sales สาขา A สามารถเห็นใบเสนอราคาของสาขา B ได้หรือไม่?”, “ถ้ายอดเกินเงื่อนไข ระบบยอมให้ส่งเอกสารก่อน Manager อนุมัติหรือไม่?”, “เมื่อยกเลิกรายการ เลขอ้างอิงเดิมยังค้นย้อนหลังได้หรือไม่?” คำถามเหล่านี้ช่วยบังคับให้ Requirement ชัดขึ้นโดยธรรมชาติ

เมื่อระบบพัฒนาไปถึงช่วงตรวจรับ จึงค่อยแตกคำถามเหล่านี้เป็น Test Case, Expected Result และเกณฑ์ Go/No-Go ตามแนวทางใน UAT Web App ก่อนขึ้น Production

แยก “Problem / Requirement / Solution” ออกจากกันให้ได้

ความสับสนที่ทำให้ Scope บานบ่อยครั้งคือสามชั้นนี้ถูกเขียนรวมเป็นประโยคเดียว ตัวอย่างเช่น “ต้องทำ Notification ทาง LINE เพราะเซลส์ชอบลืมตามงาน” ประโยคนี้มีทั้งปัญหาและ Solution อยู่แล้ว หากรีบล็อก LINE ตั้งแต่ต้น ทีมอาจพลาดทางเลือกอื่นที่ง่ายกว่าหรือเหมาะกับระบบมากกว่า

ชั้น	ตัวอย่าง	คำถามที่ควรถาม
Problem	งานค้างเพราะผู้รับผิดชอบไม่รู้ว่าถึงคิวตัวเอง	งานค้างตรงไหน บ่อยเมื่อไร ใครได้รับผลกระทบ
Requirement	เมื่อสถานะเปลี่ยน ผู้รับผิดชอบถัดไปต้องรับรู้และเห็นงานที่ต้องทำ	ใคร ต้องรู้เมื่อไร ต้องมีข้อมูลอะไรเพื่อทำต่อ
Solution	Notification ในระบบ, Email, LINE หรือ Queue หน้า Dashboard	ช่องทางไหนเหมาะกับบริบทและข้อจำกัดจริง

อีกตัวอย่างคือ “ต้องมี Audit Log” หากย้อนกลับไปถาม Problem อาจพบว่าธุรกิจต้องการรู้ว่าใครเปลี่ยนสถานะสำคัญล่าสุดและสามารถตรวจประวัติเมื่อเกิดข้อโต้แย้งได้ Audit Log เป็น Solution ที่เป็นไปได้ แต่เมื่อเขียน Requirement แยกไว้ เราจะออกแบบได้ว่าต้องเก็บ Event อะไร นานแค่ไหน ใครเห็นได้ และข้อมูลไหนไม่ควรถูกบันทึกโดยไม่จำเป็น

ทำ Current-to-Target Workflow Map เพื่อเห็นว่า Web App ต้องเปลี่ยนอะไรจริง

เมื่อมีข้อมูล 8 ช่องแล้ว ให้ทำแผนที่ง่าย ๆ สองแถว แถวแรกคือ Current — วันนี้งานเดินอย่างไร แถวที่สองคือ Target — หลังมีระบบ เราต้องการให้เส้นทางไหนถูกลด ย้าย รวม หรือควบคุมให้ดีขึ้น

อย่าใช้ Target Map เพื่อวาดระบบในฝันที่ทุกขั้นตอนเป็น Automation ครับ บาง Decision ยังควรเป็นของคน บางข้อมูลยังควรตรวจด้วยสายตา และบางขั้นตอนอาจไม่คุ้มที่จะทำในเวอร์ชันแรก เป้าหมายคือเห็น “การเปลี่ยนแปลงที่ต้องเกิด” ไม่ใช่ทำให้แผนภาพดูทันสมัยที่สุด

ถ้าพบว่าปัญหาหลักคือหลายคนแก้ไฟล์เดียวกันและไม่รู้ข้อมูลล่าสุด อาจกลับไปทบทวนก่อนว่าถึงเวลาจริงหรือยังด้วยบทความ ใช้ Excel อยู่ เมื่อไรควรเปลี่ยนเป็น Web App แต่ถ้าทีมตัดสินใจแล้วว่าจะทำระบบ Current-to-Target Map จะช่วยให้การคุยกับทีมพัฒนามีขอบเขตมากขึ้น

ใช้ Requirement Quality Test 5 คำถาม ก่อนส่งให้ทีมพัฒนา

1. เห็นผู้ใช้จริงหรือยัง? — รู้หรือไม่ว่า Role ใดเป็นคนทำขั้นตอนนั้น และใครเป็นคนตัดสินกติกา
2. เห็นเหตุการณ์จริงหรือยัง? — Requirement บอกหรือไม่ว่า Trigger อะไรทำให้ขั้นตอนเริ่ม และ Outcome อะไรทำให้ขั้นตอนจบ
3. เห็นข้อมูลและกติกาหรือยัง? — รู้ว่าต้องใช้ข้อมูลอะไร มาจากไหน และ Rule ใดมีผลต่อเส้นทาง
4. เห็นกรณีผิดปกติหรือยัง? — มี Exception สำคัญที่ถ้าไม่คิดตอนนี้จะทำให้ Workflow หยุดหรือข้อมูลผิดหรือไม่
5. ตรวจรับได้หรือยัง? — เปลี่ยน Requirement เป็นคำถามหรือ Expected Result ที่ตอบ PASS/FAIL ได้หรือไม่

ถ้าข้อไหนยังตอบไม่ได้ ไม่ได้แปลว่าโครงการต้องหยุดทั้งหมด ให้ใส่ไว้ใน Assumption Log เช่น “ยังไม่ยืนยันว่า Finance ต้องอนุมัติทุกใบหรือเฉพาะยอดเกินเกณฑ์ — Owner: Finance Manager — ต้องตัดสินก่อน Sprint ที่มี Approval” วิธีนี้ดีกว่าปล่อยสมมติฐานเงียบ ๆ แล้วให้ Developer ตัดสินใจแทนกลางงาน

อย่ารีบล็อกเทคโนโลยีมากเกินไปในช่วงที่ปัญหายังเปลี่ยน

GOV.UK Service Manual เรื่องการเลือกเทคโนโลยี เสนอหลักคิดที่มีประโยชน์ว่าเทคโนโลยีควรเปิดทางให้ปรับเปลี่ยนได้เมื่อความเข้าใจความต้องการผู้ใช้พัฒนาขึ้น และควรมองระบบ/ข้อมูลเดิมที่บริการต้องทำงานร่วมด้วยด้วย สำหรับธุรกิจทั่วไป ความหมายเชิงปฏิบัติคืออย่าให้ Requirement Discovery กลายเป็นการเถียง Framework หรือ Database ก่อนรู้ Workflow

แน่นอน บางข้อจำกัดทางเทคนิคต้องรู้ตั้งแต่ต้น เช่น ระบบเดิมมี API หรือไม่, ข้อมูลอยู่ที่ไหน, มีข้อกำหนดด้านความปลอดภัยอะไร, ต้องรองรับอุปกรณ์หรือ Browser ใด แต่การมี Constraint ต่างจากการล็อก Solution ทุกจุด คุณสามารถบันทึกว่า “ต้องเชื่อม ERP เดิมและไม่แก้ ERP” ได้โดยยังไม่จำเป็นต้องสรุป Implementation ทั้งหมดในวันแรก

ถ้า Requirement มี Integration เป็นแกนหลัก หลัง Workflow และ Data ชัดแล้วให้แยกไปทำ API Integration Readiness Checklist ต่อ เพราะเรื่อง Field Mapping, Authentication, Retry, Duplicate และ Error Handling ต้องการรายละเอียดเฉพาะของตัวเอง

จาก Requirement Discovery ไป Minimum Scope อย่างไรไม่ให้ระบบรอบแรกใหญ่เกินไป

หลัง Discovery มักได้ Requirement มากกว่าที่ควรสร้างในรอบแรก นี่เป็นเรื่องปกติ อย่าพยายามบีบทุกอย่างเข้า Version 1 ให้ถามแทนว่า “Workflow ขั้นต่ำที่ต้องเดินได้ครบตั้งแต่ Trigger ถึง Outcome คืออะไร?”

สมมติระบบมีงานรับคำขอ → ตรวจข้อมูล → มอบหมาย → ดำเนินการ → อนุมัติ → ปิดงาน ถ้าขาดขั้นอนุมัติแล้วธุรกิจใช้งานไม่ได้ ขั้นนั้นคือ Core Scope แต่ Dashboard 12 กราฟอาจไม่ใช่ แม้มันอยู่ใน Feature List ตั้งแต่วันแรก การจัดลำดับด้วย Workflow ทำให้คำว่า MVP หรือ Minimum Scope มีเหตุผลมากกว่าการตัดฟังก์ชันแบบสุ่ม

เมื่อ Minimum Workflow ชัด ให้ถามอีกสามเรื่อง: อะไรต้องมีเพื่อให้ข้อมูลถูก, อะไรต้องมีเพื่อให้สิทธิ์ไม่ผิด, และอะไรต้องมีเพื่อให้คนทำงานต่อได้เมื่อเกิด Exception จากนั้นค่อยดู Enhancement เช่น Report เพิ่ม, Notification หลายช่องทาง, Automation, AI หรือ Dashboard ขั้นสูง

สิ่งที่ควรส่งให้ทีมพัฒนาไม่จำเป็นต้องเป็นเอกสาร 100 หน้า

Requirement ที่ใช้งานได้อาจเป็นเอกสาร 5–10 หน้าที่มีข้อมูลชัด ดีกว่าไฟล์ 100 หน้าที่เต็มไปด้วยชื่อเมนูแต่ไม่มี Rule สิ่งที่มีประโยชน์มากกว่าความยาวคือ ความสามารถในการตามรอยจากปัญหา → Workflow → Requirement → Acceptance

ชุดส่งต่อที่ผมแนะนำให้มีอย่างน้อยคือ:

• Problem / Goal หนึ่งย่อหน้าที่บอกว่ากำลังแก้อะไร
• User / Role ที่อยู่ใน Scope รอบนี้
• Current Workflow และ Target Workflow
• Data หลัก + Source of Truth ที่รู้แล้ว
• Business Rule และ Exception สำคัญ
• Minimum Workflow ที่ต้องเดินได้ครบ
• Assumption Log ของเรื่องที่ยังไม่ยืนยัน
• Acceptance Questions สำหรับ Requirement สำคัญ

เมื่อชุดนี้พร้อม ทีมสามารถคุยเรื่อง Screen, Feature, Estimate และ Technical Approach บนฐานเดียวกันได้ง่ายขึ้น และถ้าระหว่าง Discovery พบว่าบาง Requirement ยังขัดกัน ก็แก้ความเข้าใจก่อนเขียนโค้ด ซึ่งโดยธรรมชาติย่อมง่ายกว่าการแก้หลังทุกฝ่ายคิดว่าตกลงกันแล้ว

Checklist ก่อนนัดคุย Scope Web App

• อธิบายได้ว่างานหนึ่งชิ้นเริ่มตรงไหนและจบตรงไหน
• รู้ Role หลักและคนที่มีอำนาจตัดสินกติกา
• มี Current Workflow จากงานจริง ไม่ใช่เฉพาะ Flow ในอุดมคติ
• รู้ข้อมูลหลักและ Source of Truth เท่าที่พิสูจน์ได้
• เขียน Business Rule สำคัญเป็นประโยคที่ตีความได้ตรงกัน
• มี Exception ที่กระทบงาน/ข้อมูล/สิทธิ์อยู่ในรายการ
• แยก Problem, Requirement และ Solution ออกจากกัน
• ระบุเรื่องที่ยังไม่รู้ใน Assumption Log แทนการเดา
• กำหนด Minimum Workflow ที่ต้องเดินได้ครบ
• มี Acceptance Question สำหรับ Requirement ที่สำคัญ

ถ้าครบประมาณนี้ คุณไม่จำเป็นต้องรู้คำตอบทางเทคนิคทั้งหมดก่อนคุยทีมพัฒนาครับ หน้าที่ของ Discovery คือทำให้สิ่งที่ธุรกิจรู้และยังไม่รู้ “มองเห็นได้” แล้วค่อยตัดสินร่วมกันว่าส่วนไหนควรอยู่ใน Scope แรก ส่วนไหนต้อง Research/Prototype เพิ่ม และส่วนไหนควรเลื่อนไปหลังจากมีข้อมูลใช้งานจริง

จุดจบของ Requirement ที่ดีคือทีมรู้ว่าจะสร้างอะไร และรู้ด้วยว่ายังไม่รู้อะไร

ถ้าต้องจำหลักเดียวจากบทความนี้ ผมจะเลือกข้อนี้ครับ: อย่าให้ Feature List มาแทนความเข้าใจ Workflow ระบบที่มีเมนูครบไม่ได้รับประกันว่างานจริงจะเดินได้ แต่ Requirement ที่เริ่มจาก User, Trigger, Workflow, Data, Rule, Exception และ Outcome ทำให้ทีมมีโอกาสเห็นปัญหาก่อนแปลงเป็นหน้าจอและโค้ด

เมื่อ Requirement Discovery Pack พร้อมแล้ว ขั้นถัดไปคือเลือก Minimum Scope และประเมินวิธีพัฒนาที่เหมาะกับระบบจริง หากคุณกำลังอยู่จุดนี้ สามารถดูขอบเขต บริการพัฒนา Web App และระบบหลังบ้านสำหรับธุรกิจ เพื่อใช้เป็นบริบทในการคุย Scope ต่อได้ โดยยังคงรักษา Requirement ที่พิสูจน์แล้วเป็นแกน ไม่ปล่อยให้เทคโนโลยีหรือรายการ Feature พาโครงการออกจากปัญหาที่ตั้งใจแก้ตั้งแต่แรก