Ghi chép quy tắc nghiệp vụ cho ứng dụng AI bằng ngôn ngữ đơn giản

Tại sao quy tắc không rõ ràng tạo ra ứng dụng không đáng tin cậy

Quy tắc nghiệp vụ cho ứng dụng biết phải làm gì trong các tình huống thực tế. Chúng trả lời các câu hỏi như ai được phép phê duyệt một yêu cầu, tổng số được tính như thế nào, và chuyện gì xảy ra khi một trường hợp nằm ngoài khuôn mẫu thông thường.

Nếu những quy tắc đó mơ hồ, ứng dụng vẫn phải chọn một đường đi. Chỉ là nó có thể không chọn kết quả bạn mong đợi.

Hãy xem quy tắc như “chi phí lớn cần phê duyệt của quản lý.” Một người có thể nghĩ câu đó rõ ràng. Người lập trình thì không. Chi phí lớn là bao nhiêu: $500, $5,000 hay bất cứ thứ gì vượt ngân sách nhóm? Quản lý nào: quản lý trực tiếp, trưởng bộ phận, hay tài chính? Nếu không ai phản hồi trong hai ngày, yêu cầu sẽ chờ, hết hạn, hay chuyển cho người khác?

Đó là lý do vì sao quy tắc mơ hồ dẫn đến ứng dụng không đáng tin cậy. Người xây dựng chỉ có thể nhất quán trong phạm vi hướng dẫn nhận được. Khi cách diễn đạt để lại chỗ cho đoán mò, ứng dụng có thể hành xử một cách hôm nay và khác đi vào ngày mai khi gặp một trường hợp hơi khác.

Các vấn đề lớn thường xuất hiện ở vài khu vực:

• các phép tính thiếu chi tiết, như làm tròn, thuế, chiết khấu hoặc khoảng ngày
• các ngoại lệ mà mọi người mặc định nhưng không ai ghi lại
• các bước phê duyệt không có chủ sở hữu rõ ràng, thứ tự hoặc phương án dự phòng

Một ví dụ đơn giản cho thấy vấn đề. Một nhà sáng lập xây ứng dụng chi tiêu nội bộ trong Koder.ai và viết: "Hoàn trả chi phí đi lại trừ khi có vẻ bất thường." Nghe có lý, nhưng ứng dụng không có cách đáng tin cậy để đánh giá "bất thường". Một nhân viên thì được duyệt taxi, nhân viên khác tương tự lại bị đánh dấu, và không ai biết vì sao.

Hành vi đáng tin cậy bắt đầu từ các quy tắc có thể được thực hiện cùng một cách mỗi lần. Những từ như "lớn", "khẩn cấp" và "trường hợp đặc biệt" cần được thay bằng giới hạn, điều kiện và hành động chính xác. Nếu hai người khác nhau áp dụng quy tắc theo cùng một cách, ứng dụng có nhiều khả năng làm như vậy hơn.

Một quy tắc nghiệp vụ rõ ràng trông như thế nào

Một quy tắc rõ ràng bao phủ một quyết định hoặc một hành động, không phải cả một quy trình. Điều này quan trọng hơn nhiều đội ngũ tưởng. Khi một quy tắc cố gắng bao gồm phê duyệt, định giá, ngoại lệ và thông báo cùng lúc, người xây dựng phải đoán phần nào là quan trọng nhất.

Một quy tắc tốt dễ đọc thành tiếng. Người ngoài nhóm của bạn nên hiểu mà không cần viết tắt nội bộ. Thay các thuật ngữ như "ưu tiên", "trường hợp tiêu chuẩn" hay "chữ ký của quản lý" bằng ngôn ngữ đơn giản nêu chính xác điều gì xảy ra.

Hầu hết quy tắc rõ ràng trả lời bốn câu hỏi cơ bản:

• Ai ra quyết định hoặc thực hiện hành động?
• Khi nào quy tắc áp dụng?
• Điều gì thay đổi trong ứng dụng?
• Tiếp theo xảy ra chuyện gì?

Cấu trúc đó khiến quy tắc gắn với hành vi thực tế. Thay vì viết "Đơn hàng lớn cần xem xét," hãy viết: "Nếu đơn hàng trên $5,000, quản lý bán hàng phải phê duyệt trước khi gửi đến thực hiện." Một câu, một quyết định, một kết quả.

Cũng nên giữ các quy tắc liên quan tách biệt. Quy tắc phê duyệt nên đứng riêng. Quy tắc gửi email nên tách ra. Quy tắc chặn vận chuyển cũng nên tách. Điều đó làm cho mỗi quy tắc dễ kiểm tra, cập nhật và sửa lỗi.

Sự khác biệt dễ thấy:

"Khách hàng cao cấp được xử lý ưu tiên" thì mơ hồ.

"Nếu khách hàng có gói cao cấp, yêu cầu hỗ trợ được đánh dấu Ưu tiên cao khi ticket được tạo" thì rõ ràng.

Phiên bản thứ hai nêu kích hoạt, điều kiện và thay đổi trong ứng dụng. Nó nói với người xây dựng hành vi đáng tin cậy trông như thế nào.

Nếu bạn dùng công cụ xây dựng dựa trên chat, cách diễn đạt này tạo khác biệt lớn. Quy tắc rõ ràng không cần ngôn ngữ pháp lý. Chúng cần từ ngữ đơn giản, một ý mỗi lần, và kết quả mong đợi gói gọn trong một câu.

Viết các phép tính bằng ngôn ngữ đơn giản

Các phép tính thường trông đơn giản cho đến khi ai đó cố xây chúng. Cách an toàn nhất là bắt đầu bằng một câu đơn giản nói chính xác ứng dụng phải làm gì.

Một quy tắc tốt nghe như: "Số tiền hoàn trả bằng số dặm được duyệt nhân với tỷ lệ dặm." Rõ ràng hơn nhiều so với "tính tiền đi lại" hay "áp dụng chính sách hoàn trả chuẩn."

Sau câu đầu, định nghĩa mọi đầu vào ứng dụng sẽ dùng. Cụ thể đủ để người xây dựng không phải đoán.

Cần định nghĩa gì cho mỗi phép tính

Với mỗi phép tính, hãy nêu rõ:

• các đầu vào, với tên đơn giản và đơn vị
• giá trị lấy từ đâu
• quy tắc làm tròn
• bất kỳ giá trị tối thiểu hoặc tối đa nào
• chuyện gì xảy ra nếu một giá trị bị thiếu

Các chi tiết nhỏ rất quan trọng. "Làm tròn số cuối cùng đến 2 chữ số thập phân" cho kết quả khác với làm tròn từng mục trước. Nếu có giới hạn tối đa, nói rõ ứng dụng dừng ở giới hạn đó hay chỉ hiển thị cảnh báo.

Một quy tắc viết bằng ngôn ngữ đơn giản có thể như sau: "Tiền hoàn trả bằng số dặm được duyệt x $0.67. Làm tròn số cuối cùng đến 2 chữ số thập phân. Mức hoàn trả tối đa là $300 cho mỗi chuyến. Nếu số dặm được duyệt để trống, không tính số tiền. Đánh dấu yêu cầu là không hoàn chỉnh và yêu cầu người dùng nhập dặm."

Rồi thêm một hai ví dụ có số thực. Ví dụ phơi bày lỗ hổng nhanh hơn công thức trừu tượng.

Ví dụ 1: "Nếu số dặm được duyệt là 120, tiền hoàn trả là 120 x $0.67 = $80.40. Vì thấp hơn giới hạn $300, số tiền cuối cùng là $80.40."

Ví dụ 2: "Nếu số dặm được duyệt là 500, tiền hoàn trả là 500 x $0.67 = $335.00. Vì mức tối đa là $300, số tiền cuối cùng là $300.00."

Phong cách này dễ cho người xem xét và dễ cho người xây dựng chuyển thành hành vi ứng dụng.

Ghi lại ngoại lệ mà không gây nhầm lẫn

Hầu hết ứng dụng không thất bại trên đường chính. Chúng thất bại ở các trường hợp biên.

Đường chính có thể đơn giản, nhưng công việc thực tế bao gồm hoàn tiền sau hạn, khách VIP, thiếu tài liệu và phê duyệt một lần. Nếu ngoại lệ bị bỏ qua, ứng dụng sẽ tự điền vào khoảng trống, và đó là nơi kết quả không nhất quán bắt đầu.

Cách đơn giản để viết ngoại lệ là dùng các quy tắc ngắn nếu-thì. Giữ mỗi quy tắc tập trung vào một điều kiện và một kết quả.

• Nếu chi tiêu dưới $100, thì tự động phê duyệt.
• Nếu chi tiêu dưới $100 nhưng gửi sau 30 ngày, thì gửi để xem xét thủ công.
• Nếu nhân viên thuộc đội điều hành, thì bỏ qua giới hạn $100 và chuyển đến tài chính.
• Nếu quản trị viên tài chính đánh dấu yêu cầu là khẩn cấp, thì ghi đè thủ công áp dụng và yêu cầu được đưa lên đầu hàng đợi.

Định dạng này làm lộ logic ẩn. Nó cũng giúp bạn phát hiện chồng lấn trước khi chúng thành lỗi.

Cũng quan trọng là nói quy tắc nào thắng khi hai quy tắc mâu thuẫn. Khách hàng có thể đủ điều kiện giảm giá, nhưng đơn hàng có thể nằm trong giai đoạn cấm giảm giá dịp lễ. Viết thứ tự ưu tiên bằng ngôn ngữ đơn giản: "Nếu quy tắc cấm dịp lễ mâu thuẫn với quy tắc giảm giá khách hàng, quy tắc cấm sẽ thắng."

Hãy cụ thể về giới hạn. Ngày, loại người dùng, vị trí, trạng thái tài khoản và ghi đè thủ công thường thay đổi kết quả. Thay vì viết "nộp muộn cần phê duyệt," hãy viết "Nếu một yêu cầu được gửi sau hơn 14 ngày lịch kể từ sự kiện, thì cần phê duyệt của quản lý."

Cũng hãy nói ứng dụng nên hiển thị gì cho người dùng ở mỗi ngoại lệ. Một quy tắc tốt không chỉ dừng ở quyết định. Nó còn xác định thông điệp, như "Đã nộp sau 14 ngày. Cần phê duyệt của quản lý" hoặc "Ghi đè thủ công được áp dụng bởi quản trị viên tài chính."

Khi ngoại lệ được viết theo cách này, các trường hợp bất thường ngừng cảm thấy bất thường. Chúng trở thành hành vi bình thường, có thể kiểm tra.

Mô tả logic phê duyệt theo từng bước

Logic phê duyệt hoạt động tốt nhất khi được viết như một chuỗi quyết định, không phải chính sách mơ hồ. Mỗi bước nên trả lời năm câu hỏi: ai hành động, điều gì kích hoạt họ xem xét, giới hạn nào áp dụng, họ có bao nhiêu thời gian, và trạng thái của yêu cầu sau khi họ quyết định là gì.

Bắt đầu bằng cách nêu rõ vai trò, không chỉ tên nhóm. Thay vì viết "tài chính xem xét các yêu cầu lớn," hãy viết "Quản lý Tài chính có thể phê duyệt, từ chối, hoặc trả lại bất kỳ yêu cầu nào trên $5,000." Điều đó loại bỏ đoán mò và làm cho hành vi dễ xây hơn.

Rồi định nghĩa kích hoạt cho từng bước. Một kích hoạt là điều kiện gửi yêu cầu tới người tiếp theo. Nó có thể dựa trên số tiền, phòng ban, mức rủi ro, loại yêu cầu, hoặc kết hợp các yếu tố đó.

Ví dụ:

• Nếu yêu cầu dưới $500, trưởng nhóm xem xét.
• Nếu yêu cầu từ $500 đến $5,000, trưởng bộ phận xem xét sau khi trưởng nhóm phê duyệt.
• Nếu yêu cầu trên $5,000, tài chính xem xét sau khi trưởng bộ phận phê duyệt.
• Nếu yêu cầu được đánh dấu rủi ro cao, bộ phận tuân thủ phải xem trước khi phê duyệt cuối cùng.

Ngưỡng cần ranh giới chính xác. Đừng nói "lớn" hay "nhạy cảm." Hãy nói "trên $5,000," "từ Phòng Bán hàng," hoặc "điểm rủi ro 8 trở lên." Nếu hai ngưỡng có thể đồng thời áp dụng, hãy nói quy tắc nào thắng. Ví dụ: "Rủi ro cao luôn được gửi đến bộ phận tuân thủ, ngay cả khi số tiền thấp."

Bạn cũng cần quy tắc timeout. Nếu không ai phản hồi, ứng dụng không nên treo mãi. Hãy nói chuyện gì xảy ra sau một khoảng thời gian nhất định, như 48 giờ hoặc 3 ngày làm việc. Yêu cầu có thể được leo thang tới quản lý của người duyệt, giao cho người duyệt dự phòng, hoặc tự động hủy.

Cuối cùng, định nghĩa trạng thái sau mỗi quyết định. Giữ nhãn ngắn và nhất quán:

• Approved: yêu cầu tiến hoặc hoàn tất.
• Rejected: yêu cầu đóng và không có hành động tiếp theo.
• Sent back: người gửi phải chỉnh sửa và nộp lại.
• Escalated: yêu cầu chuyển tới người duyệt dự phòng hoặc cấp cao hơn.

Khi logic phê duyệt được viết theo cách này, người xây dựng ít phải đoán hơn và luồng công việc trở nên đáng tin cậy hơn.

Mẫu quy tắc đơn giản bạn có thể tái sử dụng

Nếu bạn muốn hành vi nhất quán, hãy cho mọi quy tắc cùng một khuôn. Cách viết hỗn tạp thường tạo kết quả hỗn tạp.

Một định dạng đơn giản phù hợp cho hầu hết trường hợp: kích hoạt, điều kiện, hành động, kết quả. Nó đủ ngắn để viết nhanh và đủ rõ để người khác xem xét sau này.

Dùng một quy tắc, một đơn vị

Giữ mỗi quy tắc trên một dòng, thẻ hoặc khối riêng. Đừng nhồi nhiều ý vào một đoạn. Nếu một quy tắc bao gồm giá, phê duyệt và ngoại lệ cùng lúc, nó trở nên khó kiểm tra và dễ hiểu sai.

Một mẫu thực tế như sau:

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]

Bạn không cần mọi trường mỗi lần. Nhưng giữ cùng thứ tự giúp người đọc quét quy tắc nhanh.

Ví dụ:

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

Chú ý rằng ví dụ nằm dưới quy tắc, không nằm trong đó. Điều đó giữ quy tắc sạch. Ví dụ chỉ chứng minh cách quy tắc nên hành xử.

Đánh dấu giả định rõ ràng thay vì giấu chúng trong câu. Một ghi chú nhỏ như "Assumption" hoặc "Needs confirmation" làm các câu hỏi mở dễ xem xét trước khi vào giai đoạn xây.

Cũng giúp khi bạn giữ cách diễn đạt nhất quán. Luôn bắt đầu kích hoạt bằng "When", điều kiện bằng "If" và hành động bằng "Then." Các mẫu nhỏ như vậy giảm nhầm lẫn, nhất là khi quy tắc được chuyển thành logic ứng dụng.

Một bài kiểm tra nhanh hữu ích: có ai đó có thể kiểm tra quy tắc này không, và có ai đó có thể hiểu sai nó không? Nếu câu trả lời cho câu đầu là không, hoặc câu thứ hai là có, hãy sửa lại cho chặt chẽ.

Ví dụ: ứng dụng phê duyệt chi tiêu

Ứng dụng chi tiêu nhân viên là một trường hợp thử tốt vì chính sách quen thuộc và các ngoại lệ xuất hiện nhanh. Nhân viên có thể khai tiền ăn, taxi, khách sạn và chi phí nhỏ cho khách, nhưng mỗi yêu cầu có giới hạn, ngoại lệ và bước phê duyệt. Đây chính là loại quy trình mà ngôn ngữ đơn giản quan trọng.

Chính sách mẫu

Viết quy tắc cho bữa ăn như sau: nhân viên có thể yêu cầu đến $40 mỗi ngày cho bữa ăn trong các ngày làm việc bình thường. Ứng dụng nên cộng tất cả hóa đơn bữa ăn trong cùng một ngày và so sánh tổng đó với giới hạn hàng ngày, không phải kiểm tra từng hóa đơn riêng lẻ.

Nếu nhân viên tiêu $12 cho bữa sáng và $22 cho bữa trưa vào thứ Ba, tổng là $34, nên yêu cầu hợp lệ. Nếu họ thêm một bữa tối $15 cùng ngày, tổng thành $49, nên ứng dụng đánh dấu vượt giới hạn.

Bây giờ thêm ngoại lệ. Nếu bữa ăn diễn ra trong chuyến công tác đã được duyệt hoặc trong cuộc họp với khách hàng, giới hạn bữa ăn hàng ngày tăng lên $75. Ngoại lệ này chỉ áp dụng khi nhân viên chọn Travel day = Yes hoặc Client meeting = Yes và thêm một ghi chú ngắn với tên khách hàng hoặc mục đích chuyến đi.

Cách này đáng tin hơn so với cụm từ mơ hồ như "các trường hợp đặc biệt có thể được chấp nhận" vì ngoại lệ được liên kết với điều kiện rõ ràng.

Các bước phê duyệt

Logic phê duyệt có thể giữ nguyên sự đơn giản:

• Các yêu cầu dưới $100 được phê duyệt bởi quản lý trực tiếp.
• Các yêu cầu từ $100 đến $500 cần quản lý phê duyệt, sau đó tài chính phê duyệt.
• Các yêu cầu trên $500 cần quản lý, tài chính và trưởng phòng phê duyệt.
• Bất kỳ yêu cầu nào đánh dấu "travel" cũng cần tài chính xem xét, ngay cả khi số tiền dưới $100.

Bạn có thể kiểm thử quy tắc với vài trường hợp đơn giản. Một yêu cầu ăn $36 trong ngày làm việc bình thường nên được phê duyệt nếu kèm biên nhận. Một yêu cầu $60 cho bữa ăn trong ngày công tác nên được chấp nhận nếu đã đánh dấu travel và ghi chú đầy đủ. Một yêu cầu $60 cho bữa ăn trong ngày bình thường nên bị từ chối hoặc trả lại để chỉnh sửa. Một yêu cầu khách sạn $650 nên đi qua cả ba bước phê duyệt.

Mục tiêu là: quy tắc cho cùng kết quả mỗi lần ai đó kiểm thử với các trường hợp thực tế.

Những lỗi phổ biến dẫn tới kết quả tệ

Một quy tắc có thể nghe rõ với một người nhưng vẫn khiến người xây dựng bối rối. Điều đó thường xảy ra khi tài liệu mơ hồ, nhồi nhiều ý, hoặc không nhất quán từ dòng này sang dòng khác.

Một lỗi hay gặp là nhồi nhiều quy tắc vào một đoạn dài. Ví dụ: "Quản lý phê duyệt đi lại trừ khi tổng lớn, tài chính kiểm tra biên lai, và yêu cầu khẩn cấp có thể bỏ qua xem xét." Câu đó có vẻ hiệu quả, nhưng nó che dấu nhiều quyết định riêng biệt. Hãy tách thành các quy tắc riêng để mỗi hành động có một kích hoạt và một kết quả.

Vấn đề khác là ngôn ngữ mơ hồ. Những từ như normal, large, urgent hay recent chỉ có ý nghĩa nếu bạn định nghĩa chúng. Nếu "chi tiêu lớn" có nghĩa là trên $2,000, hãy nói vậy. Nếu "khẩn cấp" nghĩa là cần trong 24 giờ, hãy viết điều kiện chính xác đó.

Dữ liệu thiếu cũng là nguồn gây rắc rối lớn. Các đội thường mô tả đường thuận lợi rồi quên nói chuyện gì xảy ra khi thông tin không đầy đủ hoặc sai. Nếu yêu cầu không có số tiền, không có phòng ban, hoặc không có biên nhận, quy tắc nên nói bước tiếp theo là gì.

Những lỗi gây rắc rối nhất thường là:

• ghép nhiều quy tắc vào một đoạn
• dùng thuật ngữ không định nghĩa cho kích thước, thời gian hoặc ưu tiên
• quên các trường hợp lỗi và trường dữ liệu thiếu
• để mơ hồ ai có quyền phê duyệt cuối cùng
• đổi tên cùng một thứ giữa chừng

Quyền phê duyệt cuối cùng quan trọng hơn nhiều đội nghĩ. Nếu quản lý và người kiểm toán tài chính bất đồng, ai có quyết định cuối cùng? Nếu không ai nắm bước cuối, ứng dụng có thể bị treo hoặc gửi công việc vòng vo.

Việc đổi tên tạo lỗi âm thầm. Nếu bạn bắt đầu gọi là "request" rồi giữa chừng gọi là "submission" hoặc "ticket", người đọc có thể nghĩ đó là các mục khác nhau. Chọn một thuật ngữ và giữ nó xuyên suốt tài liệu.

Điều này càng quan trọng hơn trong công cụ xây dựa trên chat, nơi ngôn ngữ đơn giản điều khiển hành vi. Quy tắc rõ ràng không cần trang trọng. Chúng cần cụ thể, nhất quán và hoàn chỉnh.

Danh sách kiểm tra nhanh trước khi xây

Trước khi biến yêu cầu thành màn hình, luồng hay prompt, hãy xem lại lần cuối. Một kiểm tra ngắn bây giờ có thể cứu hàng giờ sửa hành vi lạ sau này.

Làm cho mọi quy tắc có thể kiểm thử. Mỗi quy tắc nên kết thúc bằng kết quả rõ ràng như có hoặc không, phê duyệt hay từ chối, áp phí hay không. Nếu hai người có thể đọc cùng một câu và đưa ra câu trả lời khác nhau, quy tắc cần sửa.

Ghi rõ mọi phép tính. Gọi tên các đầu vào, công thức và khi nào tính. Thêm làm tròn, tiền tệ, xử lý ngày và chuyện gì xảy ra nếu giá trị thiếu hoặc bằng 0.

Giữ ngoại lệ tách biệt. Viết quy tắc mặc định trước, sau đó thêm ngoại lệ riêng. Giới hạn chi tiêu chính không nên bị chôn trong trường hợp đặc biệt cho nhà thầu, mua khẩn cấp, hay công tác được duyệt trước.

Dò lại toàn bộ đường phê duyệt. Với mỗi ngưỡng, nêu ai phê duyệt và chuyện gì xảy ra tiếp theo. Hãy chính xác cả các cạnh: nói rõ quy tắc bắt đầu ở trên $500 hay từ $500 trở lên.

Rồi làm bài kiểm tra người mới. Đưa quy tắc cho người chưa từng làm và yêu cầu họ giải lại bằng lời của họ. Nếu họ cần ngữ cảnh thêm, quy tắc vẫn còn mơ hồ.

Một ví dụ nhỏ cho thấy tầm quan trọng. "Quản lý phê duyệt chi tiêu lớn" nghe rõ cho đến khi ai đó hỏi $500 có tính là lớn không. "Quản lý phê duyệt chi tiêu trên $500. Giám đốc phê duyệt chi tiêu trên $2,000. Chi tiêu $500 hoặc thấp hơn được tự động phê duyệt" để lại ít chỗ cho nhầm lẫn.

Biến quy tắc thành ứng dụng hoạt động

Khi quy tắc rõ ràng, xem lại cùng những người dùng quy trình hàng ngày. Quản lý, điều phối viên, nhân viên tài chính và người duyệt thường nhận ra các chi tiết nhỏ không bao giờ vào tài liệu. Những chi tiết đó thường là điều làm ứng dụng mượt mà hoặc gây khó chịu.

Xem tài liệu quy tắc như hướng dẫn vận hành, không phải bản nháp một lần. Nó nên giải thích điều gì xảy ra, ai quyết định, ngoại lệ là gì, và ứng dụng làm gì khi thiếu thông tin.

Trước khi xây toàn bộ ứng dụng, kiểm thử vài kịch bản thực tế gần đây. Dùng cả trường hợp sạch và rối: một yêu cầu tiêu chuẩn nên qua, một yêu cầu thiếu thông tin, một ngoại lệ cần xem thủ công, và một trường hợp vượt ngưỡng chi tiêu hoặc ngưỡng phê duyệt.

Bước này phát hiện lỗ hổng sớm. Một quy tắc có thể nghe rõ trên giấy nhưng vỡ vụn khi một yêu cầu thực tế không khớp mẫu.

Khi những kịch bản đó hoạt động ổn, chuyển chúng vào công cụ xây. Nếu bạn dùng nền tảng dựa trên chat như Koder.ai, bộ quy tắc rõ ràng làm quá trình xây nhanh hơn nhiều vì bạn đang dịch một quy trình đã định nghĩa thành màn hình, hành động và phê duyệt thay vì quyết định khi làm.

Sau khi ra mắt, giữ tài liệu là nguồn sự thật. Khi chính sách thay đổi, thêm người duyệt, hay cập nhật giới hạn, chỉnh tài liệu trước rồi mới cập nhật ứng dụng. Điều đó giúp sửa đổi sau này đơn giản hơn và giảm khả năng mọi người nhớ quy tắc khác nhau.

Một thói quen nhỏ giúp: xem lại quy tắc mỗi khi quy trình thay đổi, không chỉ khi ứng dụng hỏng. Các cập nhật nhỏ làm sớm dễ hơn nhiều so với sửa hành vi gây rối sau này.

Nếu tài liệu luôn cập nhật, ứng dụng sẽ dễ kiểm thử, cải tiến và đáng tin cậy theo thời gian.