การซิงค์ที่เสนอมี 20 กล่อง กล่องเจ็ดคัดลอกสถานะลงสเปรดชีต กล่องแปดปรับรูปไฟล์ให้แพลตฟอร์มอีเมล กล่องเก้าส่งอีเมลขอผู้จัดการอนุมัติการนำเข้า แผนถามว่าเอเจนต์ตัวไหนควรทำกล่องเจ็ดถึงเก้า
คำถามแรกคือทำไมกล่องเหล่านั้นมีอยู่ นี่เป็นตัวอย่างสมมติ ไม่ใช่การตรวจทีมจริง
การอภิปรายการออกแบบเวิร์กโฟลว์ เสนอสี่ช่องสำหรับงาน: ลบขั้น ใช้โค้ดธรรมดา ใช้เอเจนต์ หรือให้คนตัดสิน ขั้นที่มีประโยชน์เกิดก่อนเลือกโมเดล การลบขั้นอาจตัดความจำเป็นของกลไกรอบมันทั้งหมด
เริ่มจากผลที่ลูกค้าเห็น
ตั้งชื่อผลที่เวิร์กโฟลว์ต้องสร้าง สำหรับเชื่อมร้านไปอีเมล อาจเป็น “ลูกค้าที่ซื้อแล้วไม่รับข้อความเตือนตะกร้าอีก” ผลนี้ต้องมีสถานะ เวลา และกฎกันออก ไม่ได้บังคับว่าต้องมีสเปรดชีต การส่งออกทั้งหมดทุกคืน หรือกล่องจดหมายผู้จัดการ
ภาพ Tajo ด้านล่างให้ตรวจแมปที่เสนอและขอบเขตก่อนเปิดใช้งาน ภาพไม่ได้ทำระบบหยุดแจ้งเตือนตะกร้าให้ใช้งานจริง ผลลัพธ์นั้นต้องกำหนดสัญญาณการซื้อและกฎหยุดส่งก่อน การเพิ่มฟิลด์แมปไม่แทนการตัดสินใจสองข้อนี้
ตรวจการซิงค์ก่อนทำงาน
ซิงค์ข้อมูลลูกค้าที่อัปเดตไปยังแพลตฟอร์มอีเมลของฉัน
ซิงค์ลูกค้า
| ฟิลด์ต้นทาง | ฟิลด์ปลายทาง | กฎ |
|---|---|---|
email | EMAIL | โดยตรง |
first_name | FIRSTNAME | โดยตรง |
last_name | LASTNAME | โดยตรง |
การดูตัวอย่างด้วยข้อมูลจำลองผ่านแล้ว
แมป 3 ฟิลด์ · ไม่มีการเขียนไปยังปลายทาง
เค้าโครงตัวอย่างอิงเครื่องมือแมปของ Tajo การดูตัวอย่างด้วยข้อมูลจำลองและฉบับร่างที่บันทึกไว้ยังไม่เปิดการซิงค์
เดินย้อนจากผลไปตามทางเดิม ทุกขั้นถามว่าอะไรจะเสียหากหายไป การควบคุมจริงมีคำตอบ: ความยินยอมจะหาย ข้อพิพาทการจ่ายถูกมองข้าม หรืออาจส่งโดยไม่มีสิทธิ์ การส่งต่อที่ทำตามเคยอาจมีเพียงคำตอบเชิงประวัติ: ระบบเก่าต้องใช้ไฟล์
ช่อง “ลบ” ไม่ใช่ใบอนุญาตลบการป้องกัน ตรวจจุดประสงค์แต่ละขั้นก่อนจัดช่อง
- ผลที่ต้องมีผลของลูกค้าเดินย้อน
- ตรวจขั้นจุดประสงค์และการควบคุมลบขั้นที่หมดเหตุผล
- งานที่เก็บมีเจ้าของและทดสอบได้
การตรวจระบุสิ่งที่ต้องส่งมอบและสิ่งพึ่งพาที่ปกป้องมันจริง หากสเปรดชีตถือวิจารณญาณธุรกิจที่ไม่มีที่อื่น ต้องรักษาวิจารณญาณนั้นแม้ไฟล์หาย
| ประเภทขั้น | คำถาม | ตัวอย่างในตะกร้าสมมติ |
|---|---|---|
| ลบ | ปกป้องหรือสร้างผลที่ต้องมีไหม | ไฟล์ส่งออกซ้ำที่ไม่มีใครอ่าน |
| โค้ดธรรมดา | กฎแม่นและเสถียรไหม | กันข้อความเตือนเมื่อยืนยันการซื้อแล้ว |
| วิจารณญาณโมเดล | ขั้นต้องตีความในขอบเขตไหม | จัดคำขอข้อความอิสระไปทีมที่ถูก |
| คนหรือนโยบายที่อนุมัติ | การเลือกให้อำนาจหรือมีผลสำคัญไหม | อนุมัติเข้าถึงข้อมูลลูกค้า |
ตารางเป็นเครื่องมือออกแบบ ไม่รายงานว่าขั้นจริงของบริษัทใดถูกจัดอย่างไร
ใส่กฎแน่นอนในโค้ด
การเรียก API การตรวจฟิลด์ การเทียบเวลา หรือการตรวจสิทธิ์ไม่ได้ดีขึ้นเพราะให้โมเดลด้นสด โค้ดเขียนสิ่งที่ต้องคงจริง ทำซ้ำเหมือนเดิม และให้ความล้มเหลวตรวจได้ ใช้เมื่อระบุกฎได้
สำหรับตะกร้า เหตุการณ์ซื้ออาจมาช้าหรือสองครั้ง โปรแกรมควรระบุคำสั่งซื้อ เทียบสถานะปัจจุบัน และไม่ส่งเตือนเมื่อรู้ว่าซื้อ หากระบบยืนยันไม่ได้ว่าซื้อหรือไม่ ต้องมีสถานะไม่แน่นอน โมเดลมอบสิทธิ์ให้ตัวเองเดาว่าลูกค้าไม่ได้ซื้อไม่ได้
งานบางอย่างไม่เข้ากฎแน่นอน คำขอซัพพอร์ตอาจว่า “ซื้อเมื่อวาน แต่ใบเสร็จแสดงที่อยู่เก่า” การส่งต่อข้อความนี้อาจใช้การตัดสินเชิงความหมายที่จำกัด ผลควรเป็นทีมที่รู้จักหรือ “ยังไม่แน่” ไม่ใช่คำสั่งเปิดกว้างให้แก้คำสั่งซื้อ แยกการตัดสินโมเดลจากโค้ดที่บังคับสิทธิ์และเขียนสถานะ
ทำไมเอเจนต์เดียวอาจซ่อนขั้น
“เอเจนต์หนึ่งตัวอ่านเวิร์กโฟลว์แล้วทำทุกอย่างได้” เดโมอาจทำให้ดูง่าย งานจริงยังต้องมีคนอธิบายว่าเอเจนต์ดูระเบียนได้เพราะอะไร ทำอะไรได้ และย้อนการกระทำผิดอย่างไร เอเจนต์กว้างมักซ่อนขั้นเดิมในพรอมป์ต์และลบป้ายที่ช่วยตรวจสอบ
ข้อโต้แย้งที่สองคือการตรวจสี่ช่องก็ใช้เวลา จริง ทำให้สั้น เลือกผลลูกค้าหนึ่งอย่าง ระบุขั้นที่ต้องใช้ แล้วถามแต่ละขั้นให้อะไร แบบฝึกคุ้มเมื่อทำงานเล็กลงหรือเจ้าของชัด การตรวจทุกระบบข้างเคียงอย่างพิถีพิถันจะเป็นอีกกล่อง
ทดสอบการจัดกับกรณีปกติและกรณีล้มเหลว หากขั้นที่ลบแอบเป็นการควบคุม การทดสอบควรเผย หากวิจารณญาณโมเดลประเมินกับตัวอย่างไม่ได้ ให้จำกัดหรือคืนการตัดสินให้คน หากโค้ดต้องเปลี่ยนทุกข้อยกเว้นลูกค้า ให้แยกกลไกเสถียรจากกฎธุรกิจท้องถิ่น
การตรวจยังต้องมีจุดหยุด ทีมอาจแตกงานย่อยไปเรื่อยจนค่าจัดประเภทสูงกว่างานที่ประหยัด หยุดเมื่อขั้นที่เก็บแต่ละขั้นมีเจ้าของ ตัวกระตุ้น และเหตุผลทดสอบได้ บันทึกความไม่แน่นอนหนึ่งอย่างที่อาจเปลี่ยนการออกแบบ แล้วทดสอบในชิ้นงานจริงเล็กสุด สำหรับการซิงค์ อาจเป็นเหตุการณ์ซื้อมาทันกันข้อความเตือนที่เข้าคิวไหม คู่มือการเชื่อมต่อ ให้ลำดับวางแผนกว้าง สี่ช่องช่วยไม่ให้ลำดับนั้นคงขั้นที่ไม่จำเป็น กลับมาจัดใหม่เมื่อเวิร์กโฟลว์หรือสิทธิ์เปลี่ยน
ขั้นที่ถูกที่สุดคือขั้นที่ผลลัพธ์ไม่เคยต้องการ
คำถามที่พบบ่อย
ก่อนทำอัตโนมัติควรลบอะไร?
ขั้นที่มีเพียงเพื่อชดเชยการส่งต่อที่ลบได้ ระเบียนซ้ำ หรือรายงานไม่มีใครใช้เป็นตัวเลือก ตรวจผู้ใช้ผลปลายทางและการควบคุมก่อนลบ
เมื่อใดขั้นต้องใช้โมเดล?
ใช้โมเดลกับการตีความเชิงความหมายที่แคบและเขียนเป็นกฎแน่นอนเสถียรไม่ได้ โดยมีข้อมูลเข้าที่สังเกตได้ ผลแบบมีชนิด และทางจัดการความไม่แน่นอน
การตัดสินใดควรอยู่กับคน?
การเลือกที่ต้องการความยินยอม มอบสิทธิ์ หรือมีผลเกินขอบเขตระบบที่ได้รับอนุญาตควรอยู่กับผู้รับผิดชอบหรือนโยบายที่อนุมัติชัด