4 điều cần điền đủ trước khi bàn giao cho công ty phát triển thuê ngoài — Lý do thật sự khiến bạn không nhận được báo giá

Bạn đã gửi tài liệu kế hoạch đi nhưng không nhận được báo giá. Nếu có thì cũng kèm theo câu "có nhiều điểm cần xác nhận".

Khi vất vả ký được hợp đồng, lần này lại nảy sinh chuyện khác. Nhìn các màn hình đã được làm ra, bạn thấy chúng khác với những gì mình hình dung. Khi yêu cầu sửa, câu trả lời nhận được là "nội dung đó không có từ đầu".

Không bên nào làm sai cả. Chỉ là tài liệu không có căn cứ để đưa ra quyết định.

Lập trình viên sẽ hỏi những điều như thế này

Những câu mà người nhận tài liệu yêu cầu hỏi lại thường khá cố định. Những gì công ty phát triển thuê ngoài hỏi trước khi báo giá cũng gần như giống vậy.

• "Màn hình này hiện ra khi nào?"
• "Khi việc kết nối đang diễn ra thì người dùng đang ở đâu?"
• "Nếu bị từ chối thì màn hình sẽ thế nào?"
• "Đây là số hay ngày tháng? Có nhập trực tiếp được không?"
• "Dữ liệu này lấy từ đâu? Một API có đủ không?"
• "Bấm nút này thì cái gì được thêm vào, và chuyển đến đâu?"
• "Nếu đăng nhập thất bại thì sao?"
• "Nếu ngày kết thúc sớm hơn ngày bắt đầu thì sao?"

Không phải vì các câu hỏi này khó tính. Mà vì thiếu những câu trả lời này thì không thể viết code. Vì vậy cũng không thể báo giá. Muốn báo giá thì phải đếm được số thứ cần làm và số trường hợp, mà các trường hợp lại không có trong tài liệu.

Những gì thiếu trong tài liệu thường là cùng 4 mục

Màn hình đã được vẽ. Chức năng cũng đã được ghi. Thứ bị thiếu luôn là bốn mục này.

1. Trạng thái — màn hình này hiện đang ở trạng thái nào

Cùng một màn hình nhưng trông khác nhau tùy trạng thái: khi trống, khi đang tải, khi đã tải xong, khi thất bại. Thông thường chỉ một trạng thái đã tải xong được vẽ ra.

• Viết thế này là chưa đủ — Hiển thị danh sách tài khoản đã liên kết
• Cần viết thế này — Trước khi liên kết / Đang liên kết / Liên kết xong / Liên kết thất bại — bốn màn hình

2. Điều kiện — khi nào thứ này xuất hiện

Nếu không ghi rõ nút bấm hay dòng thông báo luôn luôn hiển thị hay chỉ hiển thị trong điều kiện nhất định, lập trình viên sẽ phải hỏi lại hoặc tự quyết định.

• Viết thế này là chưa đủ — Nút đăng ký lại
• Cần viết thế này — Chỉ hiển thị nút đăng ký lại khi lần đăng ký ngay trước đó bị từ chối

3. Kết quả — bấm vào thì điều gì xảy ra

Nhiều trường hợp chỉ có tên nút mà không có bước tiếp theo. Cái gì được lưu, chuyển đến đâu, người dùng thấy gì — tất cả mới là một bộ hoàn chỉnh.

• Viết thế này là chưa đủ — Nút xác nhận
• Cần viết thế này — Xác nhận → lưu đơn đăng ký → chuyển đến màn hình hoàn tất → hiển thị mã tiếp nhận

4. Thất bại — khi không thành công thì sẽ thế nào

Đây là mục đặc biệt hay bị bỏ sót. Người ta chỉ vẽ luồng suôn sẻ rồi dừng lại. Nhưng trong dịch vụ thực tế, phần lớn thời gian lại bị tiêu tốn vào việc xử lý khi không thành công.

• Viết thế này là chưa đủ — (không ghi gì cả)
• Cần viết thế này — Khi lỗi mạng, hiển thị hướng dẫn thử lại / Khi đăng ký trùng, thông báo về đơn đã có / Khi giá trị nhập sai, đánh dấu ô tương ứng

Vì sao mục 4 quan trọng nhất

Chức năng thì chỉ cần tưởng tượng là nghĩ ra. Thất bại thì phải trải qua mới biết.

Vì vậy, một tài liệu để trống mục thất bại thường là một dịch vụ chưa từng được vận hành thực tế. Công ty phát triển cũng nhận ra điều đó. Báo giá đưa ra trong tình trạng ấy thường tăng lên về sau, bởi các trường hợp chưa được ghi lại sẽ lần lượt lộ ra trong quá trình phát triển.

Ngược lại, nếu cách xử lý thất bại đã được ghi rõ, báo giá sẽ có nhanh. Vì có thể đếm được.

Khi xây dựng một dịch vụ fintech, tôi từng phụ trách chung việc kết nối Open Banking. Để vượt qua vòng thẩm định của ngành tài chính, chỉ riêng việc chức năng chạy được là không đủ. Chúng tôi còn phải chuẩn bị đầy đủ cả kiểm thử chức năng và tài liệu bảo mật — tới mức trong điều kiện nào thì thất bại ra sao, lúc đó hiển thị gì và ghi lại gì.

Quá trình đó rất phiền phức, nhưng nhờ có tài liệu ấy mà dù chỉ là một nhóm nhỏ, chúng tôi vẫn vượt qua được thẩm định. Chỉ cần một lần viết loại tài liệu phải điền đủ mới được thông qua, từ đó trở đi nó sẽ trở thành tiêu chuẩn mặc định của bạn.

Danh sách kiểm tra trước khi bàn giao

Với mỗi màn hình, hãy thử điền bốn dòng dưới đây. Nếu có màn hình nào không điền đủ bốn dòng, đó chính là chỗ báo giá sẽ tăng lên về sau.

Tên màn hình: ____________
1. Trạng thái — Màn hình này có thể có những trạng thái nào? (Trống / Đang tải / Hoàn tất / Thất bại)
2. Điều kiện — Xuất hiện khi nào?
3. Kết quả — Khi người dùng thao tác, cái gì được lưu và chuyển đến đâu?
4. Thất bại — Khi không thành công, hiển thị gì và ghi lại gì?

Nên bổ sung thêm đúng một mục nữa: dữ liệu này đến từ đâu. Nếu không ghi rõ con số hiển thị trên màn hình đến từ hệ thống nào, sau khi bắt đầu phát triển bạn sẽ nhận được câu trả lời "không có giá trị đó".

Khi giao việc cho AI cũng vậy

Ngày nay nhiều người viết bản nháp yêu cầu bằng AI. Khi đó điều kiện vẫn giống như vậy.

Nếu chỉ nói "hãy viết tài liệu thiết kế màn hình", bạn sẽ chỉ nhận được luồng suôn sẻ. Bởi AI cũng không tưởng tượng ra được thất bại. Thay vào đó, nếu yêu cầu như sau thì kết quả sẽ khác.

"Hãy chia trạng thái của màn hình này thành bốn loại, và với mỗi trạng thái, ghi cả những gì người dùng nhìn thấy lẫn cách xử lý khi thất bại."

Điều AI làm tốt là điền vào những ô còn trống. Còn cần điền gì thì con người phải chỉ cho nó.

Nếu hôm nay chỉ làm một việc

Trong các màn hình bạn đang làm, hãy chọn chỉ một và thử điền bốn dòng ở trên.

Mục lộ ra nhanh nhất là mục 4. Nếu mục thất bại còn trống, màn hình đó vẫn chưa sẵn sàng để bàn giao.

---

Nếu bạn chưa rõ tài liệu của mình đã ở trạng thái có thể bàn giao hay chưa
Với bài chẩn đoán 2 phút, bạn có thể xem một việc nên bắt tay làm trước tiên, phương án khởi động thí điểm 2 tuần, và những rủi ro nhất định phải có người kiểm tra. Bạn chỉ cần trả lời trong phạm vi thấy thoải mái là được.

Chẩn đoán vận hành kinh doanh bằng AI của STAR-T →

---

Chú thích

① Tài liệu tham khảo · ngày xác nhận
Bài viết này không trích dẫn thống kê hay nghiên cứu bên ngoài. Căn cứ là các mẫu câu hỏi được xác nhận lặp đi lặp lại khi rà soát tài liệu yêu cầu trong các buổi giảng dạy và tư vấn (tích lũy hơn 500 buổi tư vấn 1:1 cho người chuẩn bị khởi nghiệp · theo SSOT hồ sơ kinh nghiệm). Trường hợp Open Banking trong bài là kinh nghiệm phụ trách chung việc kết nối tại một dịch vụ fintech vào năm 2021 (làm việc 2019.09~2022.06). Ngày xác nhận 2026-08-04.

② Những số liệu không sử dụng
Chúng tôi không dùng các số liệu như tỷ lệ rút ngắn thời gian phát triển hay tỷ lệ tiết kiệm chi phí báo giá. Đó không phải giá trị chúng tôi đo được, và mức chênh lệch giữa các dự án quá lớn nên không thể khái quát hóa. Số liệu từ khảo sát nội bộ hay phản hồi CS cũng không được sử dụng.

③ Cách thực hiện
Bản nháp được tạo bằng AI, sau đó con người kiểm chứng và biên tập. Trước khi xuất bản, bài viết đã qua 3 vòng kiểm duyệt: sự thật, giọng điệu và pháp lý.