Cách viết bản mô tả dự án phần mềm

1. Mô tả vấn đề và những người bị ảnh hưởng

Hãy bắt đầu từ quy trình hiện tại. Ai đang làm công việc đó, họ dùng công cụ nào và khó khăn xuất hiện ở đâu? Viết đủ cụ thể để người không làm trong doanh nghiệp của bạn cũng hiểu được.

Ví dụ, một doanh nghiệp dịch vụ nhỏ nhận yêu cầu đặt lịch qua email. Có thể mô tả vấn đề như sau: nhân viên lễ tân chép yêu cầu vào lịch, rồi kiểm tra thời gian với nhân viên phụ trách; khách hàng chưa thể tự xem khung giờ còn trống. Đây là tình huống minh họa, không phải câu chuyện khách hàng của Alvaxis.

Ghi lại kết quả bạn mong muốn và cách quan sát kết quả đó, chẳng hạn giảm số lần sửa lịch hoặc thời gian nhập lại thông tin. Nếu chưa đo quy trình hiện tại, hãy nói rõ thay vì tự đặt ra số liệu ban đầu.

2. Chọn phạm vi nhỏ nhất nhưng vẫn hữu ích

Liệt kê những thao tác chính của từng nhóm người dùng. Tách tính năng cần có ngay khỏi những phần có thể làm sau. Phiên bản đầu tiên vẫn phải hoạt động đáng tin cậy cho công việc mà nó cam kết giải quyết.

Với ví dụ đặt lịch, khách có thể cần gửi yêu cầu chọn giờ, còn nhân viên cần xác nhận hoặc từ chối. Tích điểm, báo cáo phức tạp và ứng dụng di động có thể được xem xét riêng. Hãy nhờ đối tác phản biện phạm vi này: một sản phẩm đặt lịch có sẵn có thể đã đáp ứng nhu cầu.

Thêm ví dụ để xác định khi nào công việc được coi là hoàn thành. Chẳng hạn: nếu hai khách yêu cầu cùng một khung giờ, nhân viên chỉ có thể xác nhận một lượt đặt lịch. Ví dụ cụ thể giúp hai bên thống nhất cách kiểm tra kết quả.

3. Nêu rõ hệ thống và dữ liệu liên quan

Liệt kê các công cụ phần mềm mới cần làm việc cùng: lịch, dịch vụ thanh toán, hệ thống khách hàng hoặc bảng tính. Cho biết kết nối nào bắt buộc phải có khi ra mắt. Không nên mặc định rằng mọi sản phẩm đều cho phép kết nối theo cách bạn cần.

Mô tả loại thông tin hệ thống sẽ lưu và ai được phép truy cập. Khi chia sẻ bản mô tả ban đầu, hãy dùng dữ liệu mẫu giả định. Không đưa mật khẩu, khóa API hoặc hồ sơ khách hàng thật vào tài liệu.

Nếu khách hàng hoặc nhân viên ở nhiều quốc gia, hãy nêu ngôn ngữ, tiền tệ và múi giờ thực sự cần hỗ trợ. Ghi riêng những yêu cầu hợp đồng hoặc chuyên môn cần được xem xét; bản mô tả dự án thông thường không thay thế tư vấn pháp lý.

4. Chia sẻ giới hạn và hỏi rõ cách ước tính chi phí

Nêu khoảng ngân sách bạn sẵn sàng trao đổi và giải thích các mốc thời gian quan trọng. Phân biệt ngày bắt buộc phải đáp ứng vì hoạt động kinh doanh với ngày ra mắt mong muốn. Nếu chưa chốt ngân sách, hãy hỏi có thể làm rõ những gì trong một giai đoạn lập kế hoạch nhỏ ban đầu.

Đề nghị từng đối tác giải thích giả định, phần không bao gồm và chi phí vận hành. Hosting, dịch vụ bên thứ ba, bảo trì và hỗ trợ cần được trao đổi cùng chi phí phát triển. Bạn sẽ dễ so sánh báo giá hơn khi hiểu rõ nội dung và những yếu tố có thể làm giá thay đổi.

Khi làm việc từ xa, hãy thống nhất khung giờ họp phù hợp, cách ghi lại quyết định và người có quyền duyệt thay đổi. Hai bên không nhất thiết ở cùng quốc gia, nhưng cần có cách xử lý câu hỏi rõ ràng.

5. Thống nhất việc bàn giao từ đầu

Hỏi rõ ai sẽ quản lý tài khoản hosting, tên miền, mã nguồn và tài liệu dự án. Làm rõ quyền sở hữu và quyền truy cập trong thỏa thuận. Đồng thời trao đổi điều gì sẽ xảy ra nếu sau này bạn đổi đối tác phát triển.

Xác định hỗ trợ sau khi ra mắt gồm những gì: loại lỗi nào được xử lý, cách báo lỗi và việc nào tính phí riêng. Hỏi cách sao lưu và khôi phục dữ liệu. Đây là những vấn đề thực tế cần thống nhất, không nên để đến tuần cuối mới bàn.

Mẫu bản mô tả dự án phần mềm để sử dụng ngay

Bạn có thể chép các câu hỏi này vào tài liệu hoặc email. Với lần trao đổi đầu tiên, câu trả lời ngắn và đúng thực tế là đủ. Đánh dấu những điểm chưa rõ để đối tác cùng tìm hiểu.

• Vấn đề kinh doanh: hiện tại công việc diễn ra thế nào, vì sao cần thay đổi?
• Người dùng: ai sử dụng và họ cần làm những việc gì?
• Kết quả mong muốn: thế nào là tốt hơn và sẽ đo bằng cách nào?
• Phiên bản đầu: việc nào bắt buộc, việc nào có thể để sau?
• Công cụ và dữ liệu hiện có: cần kết nối hoặc chuyển những gì?
• Giới hạn: khoảng ngân sách, thời gian, ngôn ngữ và giờ làm việc.
• Nghiệm thu: ví dụ về một công việc phần mềm hoàn chỉnh phải xử lý được.
• Bàn giao: quyền sở hữu, tài khoản, tài liệu và kỳ vọng hỗ trợ.
• Câu hỏi còn mở: điều gì cần tìm hiểu trước khi thống nhất phạm vi?