Từ ý tưởng phần mềm đến bản mô tả dự án đủ rõ

Ý tưởng như cổng thông tin khách hàng mới chỉ nêu một giải pháp, chưa giải thích lý do nên đầu tư. Bản mô tả hữu ích phải cho biết ai đang gặp khó khăn, hiện tại công việc diễn ra thế nào và khoản đầu tư tiếp theo phục vụ quyết định gì. Tài liệu cũng cần để ngỏ phương án nhỏ hơn nếu phần mềm không phải câu trả lời phù hợp.

Mô tả vấn đề trước sản phẩm

Hướng dẫn khám phá của GOV.UK khuyến nghị xem xét lại giải pháp được định sẵn và diễn đạt thành vấn đề trước khi nghiên cứu.[1] Có thể áp dụng nguyên tắc này cho bản mô tả dự án thương mại. Hãy kể một tình huống vận hành gần đây, những người tham gia và hệ quả của cách làm hiện tại.

Tách bằng chứng quan sát được khỏi diễn giải của các bên. Một nhóm yêu cầu hỗ trợ có thể cho thấy câu hỏi lặp lại. Điều đó không chứng minh mọi khách hàng đều muốn một cổng thông tin. Nêu rõ mẫu bằng chứng bao quát những gì và phần nào chưa biết.

Xác định ranh giới hữu ích đầu tiên

Chỉ rõ điểm bắt đầu và kết thúc của quy trình đang xem xét. Giải thích nhóm người dùng, địa điểm, dữ liệu và hệ thống hiện có nào nằm trong phạm vi. Nêu phần loại trừ cẩn thận tương tự. Cụm từ bao gồm tích hợp chưa đủ để so sánh các đề xuất.

Mô tả hành vi mong muốn thay vì chỉ liệt kê màn hình. Xác định ai được gửi, duyệt, sửa và đóng yêu cầu. Bổ sung cách xử lý lỗi và người chịu trách nhiệm. Tách ràng buộc nghiệp vụ khỏi sở thích công nghệ để nhà cung cấp có thể đề xuất phương án khác.

Ví dụ giả định: tiếp nhận yêu cầu sửa chữa

Một nhà phân phối thiết bị giả định muốn có ứng dụng tiếp nhận sửa chữa. Bản mô tả chuyển câu hỏi thành cách giúp nhân viên chi nhánh gửi đủ thông tin mà không cần gọi lại nhiều lần. Phạm vi gồm tiếp nhận và theo dõi trạng thái, nhưng không gồm xếp lịch kỹ thuật viên hay mua phụ tùng.

Bên mua đính kèm các ví dụ yêu cầu thiếu thông tin đã loại bỏ dữ liệu nhận dạng. Thử biểu mẫu tiếp nhận được sửa lại trở thành một lựa chọn bên cạnh phát triển phần mềm riêng. Chưa có tuyên bố nào về mức giảm cuộc gọi. Quyết định tiếp theo phụ thuộc vào việc nhân viên có cung cấp đủ thông tin một cách ổn định hay không.

Rà soát tài liệu như công cụ mua sắm

Dùng danh sách này trước khi yêu cầu nhà cung cấp gửi đề xuất. Danh sách chuyển kỳ vọng mơ hồ thành câu hỏi mà các nhóm có thể trả lời theo cùng cách.

• Chỉ định người bảo trợ nghiệp vụ và đầu mối vận hành.
• Đính kèm bằng chứng đại diện đã loại bỏ thông tin nhạy cảm.
• Xác định ranh giới quy trình và hoạt động bị loại trừ.
• Liệt kê kết nối bắt buộc, giới hạn quyền và phụ thuộc chưa rõ.
• Nêu bằng chứng cho phép tiếp tục, điều chỉnh hoặc dừng.

Giữ phần chưa chắc chắn trong ước lượng

Bản mô tả ngắn không thể giải quyết mọi quy tắc hay phụ thuộc kỹ thuật. Thêm chi tiết cũng tốn thời gian và có thể nhanh lỗi thời. Hãy yêu cầu khoảng ước lượng kèm giả định cụ thể, thay vì ép một con số chính xác từ thông tin chưa đủ.

Kết thúc tài liệu bằng quyết định tiếp theo, người quyết định và câu hỏi có thể làm thay đổi quyết định đó. Xem bản mô tả là điểm khởi đầu có kiểm soát cho trao đổi, không phải bảo đảm rằng phạm vi và chi phí sẽ không thay đổi.