บันทึกกฎธุรกิจสำหรับแอป AI ด้วยภาษาง่าย

ทำไมกฎไม่ชัดเจนถึงทำให้แอปไม่เชื่อถือได้

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

ถ้ากฎเหล่านั้นคลุมเครือ แอปก็ยังต้องเลือกเส้นทาง มันอาจแค่ไม่เลือกเส้นทางที่คุณคาดหวัง

ยกตัวอย่างกฎอย่าง "ค่าใช้จ่ายจำนวนมากต้องได้รับการอนุมัติจากผู้จัดการ" คนอาจคิดว่าเป็นข้อความชัดเจน แต่ผู้สร้างแอปไม่เห็นด้วย คำว่า "จำนวนมาก" คือ $500, $5,000 หรืออะไรก็ได้ที่เกินงบทีม? ใครคือผู้จัดการ: ผู้จัดการโดยตรง หัวหน้าฝ่าย หรือฝ่ายการเงิน? ถ้าไม่มีใครตอบภายในสองวัน คำขอนั้นรอ หมดอายุ หรือย้ายไปให้คนอื่น?

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

ปัญหาที่พบมักอยู่ในไม่กี่ด้าน:

• การคำนวณที่ขาดรายละเอียด เช่น การปัดเศษ ภาษี ส่วนลด หรือช่วงวันที่
• ข้อยกเว้นที่ทุกคนสมมติแต่ไม่มีใครเขียนไว้
• ขั้นตอนการอนุมัติที่ไม่มีเจ้าของ ลำดับ หรือแผนสำรองที่ชัดเจน

ตัวอย่างง่ายๆ แสดงปัญหา ผู้ก่อตั้งสร้างแอปค่าใช้จ่ายภายในใน Koder.ai แล้วเขียนว่า "คืนเงินค่าเดินทางยกเว้นเมื่อดูผิดปกติ" ฟังดูสมเหตุผล แต่แอปไม่มีวิธีที่เชื่อถือได้ในการตัดสินว่าอะไรคือผิดปกติ พนักงานคนหนึ่งแท็กซี่ผ่านการอนุมัติ อีกคนที่คล้ายกันถูกทำเครื่องหมาย และไม่มีใครรู้ว่าเพราะอะไร

พฤติกรรมที่เชื่อถือได้เริ่มจากกฎที่ทำตามได้แบบเดียวกันทุกครั้ง คำอย่าง "มาก" "เร่งด่วน" และ "กรณีพิเศษ" ต้องถูกแทนที่ด้วยขีดจำกัด เงื่อนไข และการกระทำที่ชัดเจน หากสองคนต่างกันจะใช้กฎเดียวกันได้ แอปก็มีแนวโน้มที่จะทำแบบเดียวกัน

รูปแบบกฎธุรกิจที่ชัดเจนเป็นอย่างไร

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

กฎที่ดีอ่านออกเสียงได้ง่าย คนที่อยู่นอกทีมควรเข้าใจโดยไม่ต้องใช้คำย่อภายในทีม เปลี่ยนคำว่า "fast-track" "standard case" หรือ "manager sign-off" เป็นภาษาง่ายที่บอกว่าทำอย่างไรอย่างชัดเจน

กฎที่ชัดส่วนใหญ่ตอบคำถามพื้นฐานสี่ข้อ:

• ใครเป็นผู้ตัดสินใจหรือทำการกระทำ?
• เมื่อไรที่กฎนี้ใช้ได้?
• อะไรเปลี่ยนแปลงในแอป?
• จะเกิดอะไรต่อไป?

โครงสร้างนี้ทำให้กฎเชื่อมโยงกับพฤติกรรมจริง แทนที่จะเขียนว่า "คำสั่งซื้อขนาดใหญ่ต้องทบทวน" ให้เขียนว่า "ถ้าคำสั่งซื้อเกิน $5,000 ผู้จัดการฝ่ายขายต้องอนุมัติก่อนส่งไปยังฝ่ายปฏิบัติการ" ประโยคเดียว การตัดสินใจหนึ่งอย่าง ผลลัพธ์หนึ่งอย่าง

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

ความต่างเห็นได้ชัด:

"ลูกค้าพรีเมียมได้รับการจัดการลำดับความสำคัญ" คลุมเครือ

"ถ้าลูกค้ามีแผนพรีเมียม คำขอซัพพอร์ตจะถูกตั้งเป็นความสำคัญสูงเมื่อสร้างตั๋ว" ชัดเจน

เวอร์ชันที่สองบอกทริกเกอร์ เงื่อนไข และการเปลี่ยนแปลงในแอป มันบอกผู้สร้างว่าพฤติกรรมที่เชื่อถือได้ควรเป็นอย่างไร

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

การเขียนการคำนวณด้วยภาษาง่าย

การคำนวณมักดูเรียบง่ายจนกว่าจะมีคนพยายามสร้างมัน วิธีที่ปลอดภัยที่สุดคือเริ่มด้วยประโยคภาษาง่ายที่บอกชัดเจนว่าแอปต้องทำอะไร

กฎที่ดีฟังดูแบบนี้: "จำนวนเงินคืนเท่ากับจำนวนไมล์ที่อนุมัติคูณด้วยอัตราไมล์" นั่นชัดกว่าการเขียนว่า "คำนวณค่าจ้างการเดินทาง" หรือ "ใช้การชดเชยมาตรฐาน"

หลังประโยคแรก ให้กำหนดทุกอินพุตที่แอปต้องใช้ ระบุให้ชัดเจนพอที่ผู้สร้างจะไม่ต้องเดา

สิ่งที่ต้องกำหนดสำหรับการคำนวณแต่ละครั้ง

สำหรับการคำนวณแต่ละครั้ง ให้ระบุ:

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

รายละเอียดเล็ก ๆ มีผล "ปัดเศษจำนวนสุดท้ายเป็นทศนิยม 2 ตำแหน่ง" ให้ผลลัพธ์ต่างจากการปัดแต่ละบรรทัดก่อน หากมีเพดาน ให้บอกว่าแอปควรหยุดที่เพดานนั้นหรือแสดงคำเตือน

กฎตัวอย่างเป็นภาษาง่ายอาจดูแบบนี้: "เงินคืนการเดินทางเท่ากับ ไมล์ที่อนุมัติ x $0.67 ปัดเศษจำนวนสุดท้ายเป็นทศนิยม 2 ตำแหน่ง ค่าสูงสุดคือ $300 ต่อการเดินทาง ถ้าไมล์ที่อนุมัติว่าง ให้ไม่คำนวณจำนวนเงิน ทำเครื่องหมายคำขอเป็นไม่สมบูรณ์และขอให้ผู้ใช้ป้อนไมล์"

จากนั้นเพิ่มตัวอย่างหนึ่งหรือสองตัวอย่างด้วยตัวเลขจริง ตัวอย่างช่วยเปิดเผยช่องว่างได้เร็วกว่าแบบฟอร์มทั่วไป

Example 1: "If approved miles is 120, reimbursement is 120 x $0.67 = $80.40. Because this is below the $300 cap, the final amount is $80.40."

Example 2: "If approved miles is 500, reimbursement is 500 x $0.67 = $335.00. Because the maximum is $300, the final amount is $300.00."

รูปแบบนี้อ่านง่ายสำหรับการตรวจสอบและง่ายสำหรับผู้สร้างที่จะแปลงเป็นพฤติกรรมของแอป

จับข้อยกเว้นโดยไม่ให้สับสน

แอปส่วนใหญ่ไม่ล้มเหลวทางเส้นทางหลัก แต่ล้มเหลวที่กรณีขอบ

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

วิธีง่าย ๆ ในการเขียนข้อยกเว้นคือใช้กฎสั้นๆ แบบถ้า-แล้ว ให้แต่ละข้อมุ่งไปที่เงื่อนไขเดียวและผลลัพธ์เดียว

• ถ้าค่าใช้จ่ายต่ำกว่า $100 ให้อนุมัติอัตโนมัติ
• ถ้าค่าใช้จ่ายต่ำกว่า $100 แต่ส่งหลัง 30 วัน ให้ส่งไปตรวจสอบด้วยตนเอง
• ถ้าพนักงานอยู่ในทีมผู้บริหาร ให้ข้ามขีดจำกัด $100 และส่งไปฝ่ายการเงิน
• ถ้าแอดมินการเงินทำเครื่องหมายคำขอว่าเร่งด่วน ให้ใช้การยกเว้นด้วยตนเองและเลื่อนคำขอไปด้านบนของคิว

ฟอร์แมตนี้ทำให้ตรรกะที่ซ่อนอยู่มองเห็นได้ ช่วยให้คุณเห็นการทับซ้อนก่อนที่จะเป็นบั๊ก

สำคัญไม่แพ้กันคือบอกว่าเมื่อกฎสองข้อขัดแย้งกัน ใครชนะ ลูกค้าอาจมีสิทธิ์ส่วนลด แต่การสั่งซื้ออาจเข้าเขตห้ามในวันหยุด ให้เขียนความสำคัญเป็นภาษาง่าย: "ถ้ากฎห้ามวันหยุดขัดแย้งกับกฎส่วนลดลูกค้า ให้กฎห้ามวันหยุดชนะ"

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

บอกด้วยว่าแอปจะแสดงอะไรให้ผู้ใช้ในแต่ละข้อยกเว้น กฎที่ดีไม่หยุดแค่การตัดสินใจ แต่ยังกำหนดข้อความ เช่น "ส่งหลัง 14 วัน จำเป็นต้องได้รับการอนุมัติจากผู้จัดการ" หรือ "การยกเว้นด้วยตนเองโดยแอดมินการเงิน"

เมื่อเขียนข้อยกเว้นแบบนี้ กรณีที่ผิดปกติจะหยุดรู้สึกว่าผิดปกติ พวกมันกลายเป็นพฤติกรรมปกติที่ทดสอบได้

อธิบายตรรกะการอนุมัติเป็นขั้นตอน

ตรรกะการอนุมัติทำงานได้ดีที่สุดเมื่อเขียนเป็นลำดับการตัดสินใจ ไม่ใช่นโยบายคลุมเครือ แต่ละขั้นควรตอบห้าคำถาม: кто act, อะไรเป็นทริกเกอร์ การจำกัดใดใช้ ระยะเวลาที่มี และสถานะของคำขอหลังการตัดสิน

เริ่มจากการระบุบทบาท ไม่ใช่แค่ทีม แทนที่จะเขียนว่า "ฝ่ายการเงินตรวจสอบคำขอขนาดใหญ่" ให้เขียนว่า "Finance Manager สามารถอนุมัติ ปฏิเสธ หรือส่งกลับคำขอใด ๆ ที่เกิน $5,000" นั่นลดการเดาและทำให้พฤติกรรมสร้างได้ง่ายขึ้น

จากนั้นกำหนดทริกเกอร์สำหรับแต่ละขั้น ทริกเกอร์คือเงื่อนไขที่ส่งคำขอไปยังคนถัดไป มันอาจขึ้นกับจำนวน แผนก ระดับความเสี่ยง ประเภทคำขอ หรือผสมระหว่างเหล่านี้

ตัวอย่าง:

• ถ้าคำขอไม่เกิน $500 หัวหน้าทีมตรวจสอบ
• ถ้าคำขอ $500 ถึง $5,000 ผู้จัดการแผนกตรวจสอบหลังหัวหน้าทีมอนุมัติ
• ถ้าคำขอเกิน $5,000 ฝ่ายการเงินตรวจสอบหลังผู้จัดการแผนกอนุมัติ
• ถ้าคำขอถูกทำเครื่องหมายว่ามีความเสี่ยงสูง ฝ่ายกำกับดูแลต้องตรวจก่อนการอนุมัติขั้นสุดท้าย

เกณฑ์ต้องมีขอบเขตชัดเจน อย่าพูดว่า "ใหญ่" หรือ "ละเอียดอ่อน" ให้พูดว่า "เกิน $5,000" "จากแผนกขาย" หรือ "คะแนนความเสี่ยง 8 ขึ้นไป" ถ้าสองเกณฑ์อาจใช้พร้อมกัน ให้บอกว่าอันไหนชนะ เช่น: "ความเสี่ยงสูงต้องไปฝ่ายกำกับดูแลก่อนเสมอ แม้ว่าจำนวนจะต่ำ"

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

สุดท้าย กำหนดสถานะหลังการตัดสินแต่ละครั้ง ให้ป้ายสั้นและสม่ำเสมอ:

• Approved: คำขอเดินหน้าหรือเสร็จสิ้น
• Rejected: คำขอปิดและไม่มีการดำเนินการต่อ
• Sent back: ผู้ขอต้องแก้ไขและส่งใหม่
• Escalated: คำขอไปยังผู้อนุมัติสำรองหรือผู้บังคับบัญชาขึ้นไป

เมื่อเขียนตรรกะการอนุมัติแบบนี้ ผู้สร้างมีช่องทางเดาน้อยลงและเวิร์กโฟลว์จะเชื่อถือได้มากขึ้น

แม่แบบกฎง่าย ๆ ที่คุณใช้ซ้ำได้

ถ้าต้องการพฤติกรรมที่สม่ำเสมอ ให้ทุกกฎมีรูปทรงเดียวกัน สไตล์การเขียนผสมมักสร้างผลลัพธ์ที่ผสมกัน

ฟอร์แมตง่าย ๆ ใช้งานได้ดีสำหรับหลายกรณี: ทริกเกอร์ เงื่อนไข การกระทำ ผลลัพธ์ สั้นพอที่จะเขียนเร็วและชัดพอให้คนอื่นตรวจ

ใช้กฎหนึ่งข้อ หน่วยเดียว

เก็บแต่ละกฎในบรรทัด การ์ด หรือบล็อกของตัวเอง อย่าบรรจุหลายไอเดียในย่อหน้าเดียว ถ้ากฎครอบคลุมการตั้งราคา การอนุมัติ และข้อยกเว้นพร้อมกัน จะทดสอบยากและอ่านผิดง่าย

แม่แบบปฏิบัติได้จริงดูแบบนี้:

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

คุณไม่จำเป็นต้องใช้ทุกช่องทุกครั้ง แต่การรักษาลำดับเดียวกันช่วยให้คนสแกนกฎได้เร็วขึ้น

ตัวอย่าง:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

สังเกตว่าตัวอย่างอยู่ใต้กฎ ไม่ใช่ภายในกฎ สิ่งนี้เก็บกฎให้สะอาด ตัวอย่างเพียงพิสูจน์ว่ากฎควรทำงานอย่างไร

ทำเครื่องหมายสมมติฐานอย่างชัดเจนแทนที่จะซ่อนในประโยค โน้ตสั้น ๆ เช่น "Assumption" หรือ "Needs confirmation" ทำให้คำถามเปิดตรวจได้ก่อนเวลาสร้าง

ยังช่วยให้รักษาคำศัพท์ให้สม่ำเสมอ เริ่มทริกเกอร์ด้วย "When" เงื่อนไขด้วย "If" และการกระทำด้วย "Then" รูปแบบเล็กๆ แบบนี้ลดความสับสน โดยเฉพาะเมื่อกฎถูกแปลงเป็นตรรกะแอป

ทดสอบด่วน: ใครบางคนสามารถทดสอบกฎนี้ได้ไหม และมีโอกาสที่ใครบางคนจะอ่านผิดหรือไม่? ถ้าคำตอบข้อแรกคือไม่ หรือข้อสองคือใช่ ให้กระชับถ้อยคำ

ตัวอย่าง: แอปอนุมัติค่าใช้จ่าย

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

นโยบายตัวอย่าง

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

ถ้าพนักงานใช้จ่าย $12 สำหรับมื้อเช้าและ $22 สำหรับมื้อกลางวันในวันอังคาร ยอดรวมคือ $34 ดังนั้นคำขอผ่าน ถ้าเพิ่มมื้อเย็น $15 ในวันเดียวกัน ยอดรวมกลายเป็น $49 แอปควรทำเครื่องหมายคำขอว่าเกินขีดจำกัด

เพิ่มข้อยกเว้น: ถ้ามื้อเกิดขึ้นระหว่างการเดินทางธุรกิจที่อนุมัติหรือประชุมลูกค้า ขีดจำกัดมื้อประจำวันจะเพิ่มเป็น $75 ข้อยกเว้นนี้ใช้ได้เฉพาะเมื่อพนักงานเลือก Travel day = Yes หรือ Client meeting = Yes และใส่บันทึกสั้น ๆ ระบุชื่อลูกค้าหรือจุดประสงค์การเดินทาง

นี่เชื่อถือได้มากกว่าคำคลุมเครืออย่าง "กรณีพิเศษอาจได้รับอนุญาต" เพราะข้อยกเว้นผูกกับเงื่อนไขที่ชัดเจน

ขั้นตอนการอนุมัติ

ตรรกะการอนุมัติยังคงเป็นภาษาง่าย:

• คำขอที่ต่ำกว่า $100 อนุมัติโดยผู้จัดการของพนักงาน
• คำขอ $100 ถึง $500 ต้องได้รับการอนุมัติจากผู้จัดการ แล้วจากฝ่ายการเงิน
• คำขอเกิน $500 ต้องได้รับการอนุมัติจากผู้จัดการ ฝ่ายการเงิน และหัวหน้าแผนก
• คำขอที่ทำเครื่องหมายว่า "travel" ต้องได้รับการตรวจสอบโดยฝ่ายการเงินด้วย แม้ว่ายอดจะต่ำกว่า $100

คุณสามารถทดสอบกฎด้วยตัวอย่างไม่กี่กรณี คำขอค่าอาหาร $36 ในวันทำงานปกติควรได้รับการอนุมัติถ้าแนบใบเสร็จ คำขอ $60 บนวันเดินทางควรผ่านถ้าเลือก travel และกรอกบันทึก คำขอ $60 ในวันปกติควรถูกปฏิเสธหรือส่งกลับเพื่อแก้ไข ค่าที่พัก $650 ควรผ่านขั้นตอนอนุมัติทั้งสามขั้น

เป้าหมายคือ: กฎควรให้ผลลัพธ์เดิมทุกครั้งเมื่อทดสอบด้วยเคสจริง

ความผิดพลาดทั่วไปที่นำไปสู่ผลลัพธ์ไม่ดี

กฎอาจฟังดูชัดเจนต่อคน แต่ยังทำให้ผู้สร้างสับสน นั่นมักเกิดเมื่อเอกสารคลุมเครือ บรรจุหลายไอเดีย หรือไม่สอดคล้องกัน

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

ปัญหาอีกอย่างคือภาษาฟุซซี คำอย่าง ปกติ มาก เร่งด่วน หรือ ล่าสุด ทำงานได้ก็ต่อเมื่อถูกนิยาม ถ้า "ค่าใช้จ่ายมาก" หมายถึงมากกว่า $2,000 ให้บอก ถ้า "เร่งด่วน" หมายถึงต้องการภายใน 24 ชั่วโมง ให้เขียนเงื่อนไขนั้น

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

ข้อผิดพลาดที่สร้างปัญหามากที่สุดมักเป็น:

• ผสมกฎหลายข้อในย่อหน้าเดียว
• ใช้คำไม่กำหนดขนาด เวลา หรือความสำคัญ
• ลืมกรณีข้อผิดพลาดและฟิลด์ที่หายไป
• ปล่อยให้ไม่ชัดว่าใครมีอำนาจอนุมัติขั้นสุดท้าย
• เปลี่ยนชื่อเรียกสิ่งเดียวกันกลางเอกสาร

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

การเปลี่ยนคำเรียกทำให้เกิดข้อผิดพลาดเงียบ ถ้าเริ่มใช้คำว่า "request" แล้วกลางเอกสารเปลี่ยนเป็น "submission" หรือ "ticket" ผู้อ่านอาจคิดว่าเป็นสิ่งต่างกัน ให้เลือกคำเดียวและใช้ตลอดเอกสาร

เรื่องนี้สำคัญยิ่งกว่าในตัวสร้างที่อิงการแชท เพราะภาษาง่ายขับเคลื่อนพฤติกรรม กฎที่ชัดเจนไม่จำเป็นต้องเป็นทางการ แต่อยากให้เฉพาะเจาะจง สม่ำเสมอ และครบถ้วน

เช็คลิสต์ด่วนก่อนสร้าง

ก่อนแปลงความต้องการเป็นหน้าจอ โฟลว์ หรือพรอมต์ ตรวจทานสั้น ๆ อีกครั้ง การตรวจเล็ก ๆ ตอนนี้ช่วยประหยัดเวลาซ่อมพฤติกรรมแปลก ๆ ทีหลังได้

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

ระบุการคำนวณทุกอย่าง ตั้งชื่ออินพุต สูตร และเวลาในการคำนวณ เพิ่มการปัดเศษ สกุลเงิน การจัดการวันที่ และการกระทำเมื่อค่าหายหรือเป็นศูนย์

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

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

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

ตัวอย่างเล็ก ๆ แสดงว่าทำไมเรื่องนี้สำคัญ "ผู้จัดการอนุมัติค่าใช้จ่ายจำนวนมาก" ฟังดูชัดจนกว่าคนจะถามว่า $500 ถือเป็นจำนวนมากหรือไม่ "ผู้จัดการอนุมัติค่าใช้จ่ายที่เกิน $500 ผู้กำกับอนุมัติที่เกิน $2,000 ค่าใช้จ่าย $500 หรือต่ำกว่าอนุมัติอัตโนมัติ" ลดพื้นที่ผิดพลาดลงมาก

แปลงกฎให้เป็นแอปที่ใช้งานได้

เมื่อกฎชัดเจน ให้ทบทวนกับคนที่ใช้งานกระบวนการทุกวัน ผู้จัดการ ผู้ประสานงาน ฝ่ายการเงิน และผู้อนุมัติมักสังเกตรายละเอียดเล็ก ๆ ที่ไม่ได้เข้ามาในเอกสาร รายละเอียดเหล่านี้มักทำให้อุปกรณ์รู้สึกลื่นไหลหรือหงุดหงิด

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

ก่อนสร้างแอปเต็ม ให้ทดสอบด้วยสถานการณ์จริงจากงานเมื่อเร็ว ๆ นี้ ใช้ทั้งเคสสะอาดและเคสยุ่ง: คำขอมาตรฐานที่ควรผ่าน คำขอที่ขาดข้อมูล ข้อยกเว้นที่ต้องตรวจด้วยมือ และเคสที่ข้ามขีดจำกัดหรือเกณฑ์อนุมัติ

ขั้นตอนนี้จับช่องโหว่ได้เร็ว กฎอาจฟังดูชัดบนกระดาษแต่พังเมื่อคำขอจริงไม่เข้ากรอบที่คาดไว้

เมื่อสถานการณ์เหล่านั้นผ่าน ให้ย้ายเข้าไปในตัวสร้าง ถ้าคุณใช้แพลตฟอร์มแชทอย่าง Koder.ai ชุดกฎที่ชัดเจนทำให้การสร้างเร็วขึ้นมากเพราะคุณกำลังแปลงกระบวนการที่นิยามแล้วเป็นหน้าจอ การกระทำ และการอนุมัติ แทนที่จะตัดสินใจระหว่างสร้าง

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

นิสัยเล็ก ๆ ช่วยได้: ทบทวนกฎเมื่อกระบวนการเปลี่ยน ไม่ใช่เฉพาะเมื่อแอปพัง การอัปเดตเล็ก ๆ ทำตั้งแต่ต้นง่ายกว่าซ่อมพฤติกรรมที่สับสนทีหลัง

ถ้าเอกสารถูกอัปเดตอยู่เสมอ แอปจะทดสอบ ปรับปรุง และเชื่อถือได้มากขึ้นตามเวลา