Viết tài liệu yêu cầu phần mềm để đơn vị làm hiểu đúng ý bạn

"Tôi tưởng cái này có sẵn rồi mà." Câu đó là hạt giống của khá nhiều tranh cãi giữa doanh nghiệp và bên làm phần mềm. Không ai xấu ý. Chỉ là hai bên hiểu chữ "quản lý đơn hàng" theo hai nghĩa, và không ai viết ra cho tới khi đã mất nhiều tuần. Tài liệu yêu cầu sinh ra để chặn đúng chuyện này. Nó không cần dài, không cần kỹ thuật, chỉ cần để hai bên nhìn cùng một bức tranh.

Tài liệu yêu cầu là gì, và không phải là gì

Nó mô tả điều phần mềm phải làm cho người dùng, bằng ngôn ngữ mà cả người làm kinh doanh lẫn người làm kỹ thuật đều hiểu. Ba câu hỏi chính: ai dùng, họ cần xong việc gì, và thế nào là xong tốt. Nó không phải bản thiết kế kỹ thuật, không chọn công nghệ, và không cần hoàn hảo ngay lần viết đầu.

Hãy coi nó như một bản thỏa thuận về phạm vi. Khi có thay đổi, hai bên sửa tài liệu thay vì dựa vào trí nhớ. Nhờ vậy việc đọc báo giá và nghiệm thu bớt cảm tính, như đã bàn trong bài checklist thuê ngoài làm website và phần mềm.

Trang đầu: mục tiêu và người dùng

Một câu như "giảm thời gian tổng hợp đơn cuối ngày" giúp được nhiều hơn "xây dựng hệ thống quản lý hiện đại". Mục tiêu rõ cho bên thực hiện cơ sở để đề xuất, và cho bạn cơ sở để từ chối những chức năng chẳng phục vụ mục tiêu đó.

Sau đó liệt kê nhóm người dùng và việc chính của từng nhóm. Nhân viên bán hàng cần nhập đơn nhanh trên điện thoại. Kế toán cần đối chiếu và xuất báo cáo. Quản lý cần xem tổng quan và duyệt ngoại lệ. Mỗi nhóm vài dòng là đủ, nhưng việc tách vai trò sớm quyết định cách phân quyền và số màn hình về sau.

Kể tình huống, đừng liệt kê chức năng

Muốn mô tả một chức năng, hãy kể một lần chạy từ đầu đến cuối. Nhân viên nhận đơn, nhập vào hệ thống, quản lý xem giá, kho xác nhận tồn, hệ thống tạo phiếu xuất. Rồi thêm các nhánh: hết hàng thì sao, khách đổi ý giữa chừng thì sao, giá vượt mức cho phép thì ai duyệt.

Phần lớn công sức và hiểu lầm nằm trong những nh��nh đó. Một dòng "quản lý đơn hàng" che chúng đi. Một tình huống cụ thể buộc cả hai bên nhìn thẳng vào chúng từ sớm.

Đi kèm là mẫu thật: file Excel đang dùng, phiếu in, ảnh chụp báo cáo hiện tại. Chúng cho thấy dữ liệu nào thực sự được ghi, cột gọi là gì, công thức nằm đâu và những ngoại lệ mọi người quen xử lý bằng tay. Có khi bên thực hiện phát hiện ra nhiều điều chỉ nhờ nhìn một file đã dùng mười hai tháng. Nếu được, thêm vài dòng dữ liệu thật đã che thông tin nhạy cảm, vì dữ liệu thật luôn lộn xộn hơn dữ liệu mẫu.

Ba hộp ưu tiên

Ép mọi thứ vào bản đầu là cách nhanh nhất để dự án kéo dài. Chia chức năng ra ba hộp. Hộp bắt buộc: thiếu là không dùng thật được. Hộp nên có: làm việc dễ hơn nhưng có thể tạm bù bằng cách khác. Hộp để sau: những ý hay chưa cần ngay.

Cách chia này cũng là nền cho việc chia giai đoạn, và làm cuộc nói chuyện về tiền bớt căng, vì hai bên cùng thấy cái gì nằm trong phạm vi bản đầu. Cách tính chi phí theo phạm vi được trình bày trong bài chi phí làm web app và phần mềm nội bộ.

Những điều kiện ngoài chức năng và các hệ thống phải nối

Ngoài việc phần mềm làm gì, hãy ghi nó phải đáp ứng điều kiện nào. Bao nhiêu người dùng cùng lúc, dùng điện thoại hay máy tính, có phải chạy khi mạng yếu không, dữ liệu lưu bao lâu, ai xem được dữ liệu nào, có cần nhật ký thao tác không. Những điều này ảnh hưởng đến cách xây từ đầu và rất khó chèn vào sau.

Nếu có dữ liệu cá nhân của khách hay nhân viên, hãy ghi rõ và xem quy định hiện hành như Nghị định 13/2023/NĐ-CP. Về bảo mật ứng dụng web, OWASP ASVS là danh mục tham khảo nhiều đội kỹ thuật dùng.

Rồi liệt kê hệ thống phải làm việc cùng: kế toán, kho, cổng thanh toán, hóa đơn điện tử, Zalo, email, vận chuyển. Với mỗi cái, ghi tên sản phẩm, ai giữ tài khoản, có tài liệu kết nối không, dữ liệu đi chiều nào. Tích hợp là nơi hay phát sinh việc ngoài dự kiến nên càng rõ càng đỡ.

Tiêu chí nghiệm thu bằng điều quan sát được

Phần này bị bỏ qua nhiều nhất. Với mỗi chức năng quan trọng, viết một câu nói cách kiểm tra: nhân viên tạo được đơn trên điện thoại trong vài thao tác và quản lý thấy ngay, báo cáo cuối ngày khớp với file Excel hiện tại. Tiêu chí dạng này đưa việc nghiệm thu về kiểm tra thay vì tranh luận ý kiến.

Cũng nên chốt từ đầu ai nghiệm thu phía doanh nghiệp, người đó quyết được đến đâu, và xử lý ra sao khi có góp ý mới sau khi đã nghiệm thu một phần.

Thử một phép kiểm tra đơn giản: đưa tài liệu cho một người chưa từng nghe về dự án và nhờ họ kể lại bằng lời của mình phần mềm sẽ làm gì. Nếu câu chuyện họ kể khác với điều bạn nghĩ trong đầu, đó chính là chỗ cần viết lại trước khi bên thực hiện bắt đầu, vì cùng khoảng cách ấy sẽ xuất hiện giữa bạn và họ nếu để nguyên.

Một khung ba đến năm trang là đủ

Không cần mẫu cầu kỳ. Mục tiêu và bối cảnh, người dùng và vai trò, các tình huống chính kèm nhánh rẽ, mẫu biểu và dữ liệu hiện có, ba hộp ưu tiên, điều kiện ngoài chức năng, hệ thống cần nối, tiêu chí nghiệm thu. Chỗ nào chưa biết thì ghi hẳn là chưa biết và đánh dấu để hỏi, đừng bỏ trống hay đoán.

Một mẹo cuối: đưa bản nháp cho một người dùng thật, không phải người quản lý, đọc thử và hỏi họ có thấy việc hằng ngày của mình trong đó không. Chỗ nào họ nhíu mày là chỗ tài liệu còn thiếu. Nếu bạn muốn có người cùng làm bản nháp đầu tiên, hãy gửi vài dòng về nhu cầu qua trang liên hệ của F2C Labs. Phần dịch vụ phát triển web app và hệ thống quản trị mô tả cách chúng tôi bắt đầu một dự án.