จัดการข้อยกเว้นในโลกจริงเมื่อสร้างแอป

ทำไมการไหลงานที่ดูสะอาดจึงล้มเหลวในชีวิตจริง

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

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

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

ความล้มเหลวที่พบบ่อยมักเป็นเรื่องง่าย:

• คำขอเดินหน้าแล้วติดเพราะผู้อนุมัติไม่อยู่
• บันทึกบันทึกไม่ได้เพราะรายละเอียดจำเป็นยังไม่ทราบ
• กรณีพิเศษถูกปฏิบัติเหมือนกรณีปกติและต้องแก้ด้วยมือทีหลัง

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

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

ข้อยกเว้นประเภทใดที่ควรหาก่อน

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

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

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

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

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

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

หากคุณพบข้อยกเว้นเหล่านี้ตั้งแต่ต้น เวอร์ชันแรกจะรู้สึกสมจริงมากขึ้นและเปราะบางน้อยลง

จะเก็บตัวอย่างจริงได้จากที่ไหน

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

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

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

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

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

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

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

วิธีเปลี่ยนเรื่องราวรกๆ ให้เป็นตรรกะแอป

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

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

จากเรื่องสู่กฎ

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

นั่นช่วยให้โฟกัสที่พฤติกรรม ไม่ใช่แค่หน้าจอ เป้าหมายไม่ใช่ครอบคลุมทุกกรณีแปลกในวันแรก แต่คือการจับรูปแบบที่เกิดซ้ำได้

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

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

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

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

ทดสอบกับเคสจริง

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

ถ้าคำตอบคือไม่ อย่าเพิ่มความซับซ้อนทันที เขียนกฎใหม่ด้วยคำที่ง่ายกว่า กฎที่ชัดมักนำไปสู่เวิร์กโฟลว์ที่ดีกว่ากฎฉลาดๆ ที่ไม่มีใครอธิบายได้

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

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

ทางเดินนี้ง่ายจะโมเดล แต่ไม่ใช่งานทั้งหมด

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

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

นั่นหมายความว่าแอปต้องเก็บมากกว่าหนึ่งวันที่ ควรติดตามทั้งวันที่ส่ง วันที่อนุมัติ และรอบที่พลาด

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

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

ฟลอว์แบบนี้อาจผ่านสถานะเรียบง่ายไม่กี่อย่าง: ส่งแล้ว, รออนุมัติผู้จัดการ, อนุมัติหลังตัดรอบ, ถือรอใบเสร็จ, และเปิดใหม่เพื่อให้การเงินตรวจ

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

วิธีจัดการข้อมูลขาดหายโดยไม่ทำให้กระบวนการพัง

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

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

ทำให้งานที่ไม่ครบเห็นได้ชัด

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

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

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

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

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

เมื่อไหร่ควรอัตโนมัติและเมื่อไหร่ควรให้คน

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

การแบ่งนี้สำคัญ แอปที่ดีควรเดินเร็วในกรณีปกติและชะลอเมื่อไม่ชัด การตัดสินอัตโนมัติผิดอาจสร้างงานมากกว่าการตรวจด้วยมือสั้นๆ

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

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

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

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

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

ข้อผิดพลาดที่พบบ่อยควรหลีกเลี่ยง

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

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

อีกความผิดพลาดคือซ่อนหลายสถานการณ์ไว้ในกฎกว้างๆ เช่น "ส่งให้แอดมินถ้าดูผิด" ฟังดูยืดหยุ่น แต่สร้างปัญหาใหม่ ใครคือแอดมิน? อะไรคือ "ผิด"? ถ้าไม่มีใครตอบภายในสองวันจะเกิดอะไร?

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

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

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

ตรวจสอบอย่างรวดเร็วก่อนจะสร้างตรรกะ

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

การทบทวนสั้นๆ ช่วยได้:

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

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

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

ขั้นตอนต่อไปเพื่อเวอร์ชันแรกที่ปลอดภัยกว่า

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

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

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

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

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

จากนั้นปรับกฎทีละน้อย เอาขั้นตอนที่สร้างความสับสนออก เพิ่มฟิลด์เฉพาะเมื่อมันป้องกันปัญหาที่เกิดซ้ำ เปลี่ยนเวลาการเตือนหากเตือนเร็วหรือช้าเกินไป การแก้เล็กๆ หลังการทดสอบจริงมักดีกว่าการเพิ่มตรรกะกรณีพิเศษซับซ้อนเร็วเกินไป

หากต้องการพัฒนาต้นแบบอย่างรวดเร็ว ตัวสร้างแบบแชทเช่น Koder.ai ช่วยแปลงตัวอย่างจริงเป็นแอปที่ใช้งานได้ทีละขั้นตอนได้ ตัวสำคัญยังเหมือนเดิม: เริ่มจากเรื่องราวรกก่อน แล้วสร้างกฎรอบเรื่องเหล่านั้น