Bản yêu cầu và người sử dụng
Mô tả công việc hiện tại, điểm vướng, người sử dụng và quyền của từng vai trò. So sánh việc chỉnh công cụ sẵn có với xây phần mềm riêng trước khi chọn hướng.
Phần mềm theo yêu cầu
Dịch vụ viết phần mềm theo yêu cầu
Xây dựng công cụ phù hợp với cách doanh nghiệp xử lý công việc.
ĐIỀU CẦN BIẾT
Chọn phiên bản đầu từ vai trò, dữ liệu và một luồng công việc hoàn chỉnh.
- Bắt đầu
- Quy trình, người dùng, hệ thống và chức năng thiết yếu.
- Nhận được
- Phiên bản đã duyệt, mã nguồn, tài khoản và hướng dẫn.
- Thống nhất
- Kiểm tra kết nối; tính năng tiếp theo có phạm vi riêng.
Phạm vi của mức giá này
- Đơn giá cho phần việc đã thống nhất: phân tích, lập trình hoặc kiểm thử.
- Ước tính số giờ, kết quả bàn giao và trần ngân sách trước mỗi đợt.
- Ghi nhận thời gian; mã nguồn và tài liệu theo phạm vi hợp đồng.
Tính riêng / điều kiện: Đây là đơn giá giờ, không phải giá trọn gói một phần mềm. Hạ tầng, dịch vụ ngoài và tích hợp phức tạp được dự toán riêng.
So sánh các dịch vụ →Chi phí phụ thuộc vào khối lượng và yêu cầu thực tế. Chọn ít hạng mục hơn có thể giảm tổng chi phí; chúng tôi xác nhận sau khi xem yêu cầu. Chi phí công việc chưa gồm thuế nếu áp dụng; tên miền, hosting, công cụ/API trả phí và quảng cáo tính riêng. Báo giá cuối cùng xác nhận phạm vi, tổng tiền, thuế và tiến độ trước khi bắt đầu.
Phiên bản đầu
Từ bài toán đến phạm vi phiên bản đầu
Chọn chức năng thiết yếu và tiêu chí để người dùng nghiệm thu.
Một luồng công việc hoàn chỉnh
Ví dụ để trao đổi: nhận yêu cầu, giao người phụ trách, cập nhật trạng thái và tìm lại hồ sơ. Phác thảo màn hình và dữ liệu mẫu để người sử dụng kiểm tra cách làm trước khi lập trình.
Phiên bản đầu tiên có thể nghiệm thu
Chốt chức năng thiết yếu, dữ liệu cần có, người duyệt và điều kiện hoàn thành. Ghi rõ tính năng để giai đoạn sau; phát triển tiếp dựa trên sử dụng thực tế và phạm vi được duyệt.
Kết nối
Kết nối hệ thống và dữ liệu
Làm rõ nguồn dữ liệu chính, quyền truy cập và cách xử lý lỗi.
Nguồn dữ liệu và trách nhiệm
Xác định hệ thống giữ dữ liệu chính, chủ dữ liệu và các trường cần trao đổi. Chốt quyền xem, sửa, xuất và xóa theo vai trò trước khi thiết kế kết nối.
Khả năng tích hợp và xử lý lỗi
Kiểm tra tài liệu API hoặc cách nhập xuất, quyền sử dụng và giới hạn nhà cung cấp. Xác định cách báo lỗi, thử lại và tránh tạo bản ghi trùng khi một yêu cầu được gửi nhiều lần.
Đối chiếu dữ liệu sau khi chuyển
Kiểm tra dữ liệu mẫu, định dạng và thông tin còn thiếu. Nếu có chuyển dữ liệu, thống nhất cách đối chiếu số lượng, xử lý bản ghi lỗi và phương án khôi phục trước khi thay hệ thống đang dùng.
Nghiệm thu
Nghiệm thu và bàn giao rõ ràng
Kiểm thử theo vai trò và bàn giao tài sản, hướng dẫn đã thống nhất.
Kiểm thử theo vai trò và tình huống
Kiểm tra luồng chính, quyền bị từ chối, dữ liệu không hợp lệ, yêu cầu trùng và lỗi kết nối. Ghi kết quả so với tiêu chí đã duyệt; lỗi của chức năng đã chốt và yêu cầu mới được quản lý riêng.
Mã nguồn, tài khoản và hướng dẫn
Danh sách bàn giao liệt kê mã nguồn, dữ liệu, tài khoản, hướng dẫn vận hành và cấu hình cần thiết. Thống nhất quyền sở hữu, giấy phép bên thứ ba và người chịu trách nhiệm duy trì từng phần.
Chi phí và thay đổi sau bàn giao
Báo giá phân biệt khảo sát, xây dựng, chuyển dữ liệu và tích hợp với chi phí hosting, công cụ và bảo trì định kỳ. Thống nhất cách báo lỗi và duyệt yêu cầu bổ sung về phạm vi, chi phí và tiến độ.
Tìm hiểu bước tiếp theo.
CÁCH CHÚNG TÔI LÀM VIỆC
Rõ ràng ở từng bước.
Khảo sát và xác định phạm vi
Bàn giao bản yêu cầu: vai trò, luồng chính, dữ liệu, phạm vi phiên bản đầu và tiêu chí nghiệm thu.
Thiết kế và xác nhận
Phác thảo luồng thao tác, giao diện và cấu trúc dữ liệu để kiểm tra cách sử dụng trước khi lập trình.
Lập trình và kiểm thử
Phát triển theo phần đã thống nhất, cho người dùng kiểm tra và xử lý lỗi theo tiêu chí nghiệm thu.
Triển khai và bàn giao
Triển khai phiên bản đã duyệt, chuyển dữ liệu trong phạm vi và kiểm tra sau chuyển. Bàn giao quyền truy cập, tài liệu và hướng dẫn; ghi rõ việc còn lại cùng cách yêu cầu hỗ trợ.
TÌNH HUỐNG MINH HỌA
Một yêu cầu, một hồ sơ xử lý.
Ví dụ cách xác định yêu cầu và kiểm tra đầu ra. Đây là tình huống minh họa, không phải dự án đã triển khai hoặc kết quả đo lường cho khách hàng.
- Tình huống
- Nhân viên nhận yêu cầu từ website và theo dõi trạng thái trong một công cụ nội bộ. Kết nối có thể gửi lại cùng một yêu cầu khi gặp lỗi.
- Giới hạn thử nghiệm
- Dùng hồ sơ mẫu. Người tiếp nhận và người quản lý có quyền khác nhau; chưa kết nối với CRM hoặc dữ liệu khách hàng thật.
- Đầu ra mong đợi
- Một hồ sơ cho mỗi mã yêu cầu, có người phụ trách và trạng thái. Lần gửi trùng được nhận diện; lỗi kết nối hiện rõ để xử lý.
- Tiêu chí kiểm tra
- Gửi lại cùng mã không tạo hồ sơ mới; người không có quyền không sửa được; khi kết nối lỗi, hồ sơ vẫn còn và không báo hoàn thành sai.
FAQ
Trước khi bắt đầu.
Những điều cần làm rõ để chọn đúng phạm vi công việc.
Nên mua phần mềm có sẵn hay đặt viết riêng?
So sánh khả năng đáp ứng quy trình, chi phí duy trì và nhu cầu tích hợp. Nếu công cụ có sẵn đáp ứng tốt, chưa cần xây dựng riêng.
Có thể kết nối với hệ thống đang dùng không?
Cần kiểm tra từng hệ thống. Khả năng kết nối phụ thuộc API hoặc cách xuất nhập dữ liệu, quyền sử dụng và sự hỗ trợ từ bên cung cấp.
Có thể bổ sung yêu cầu khi đang làm không?
Có thể trao đổi thay đổi. Hai bên đánh giá ảnh hưởng đến phạm vi, chi phí và lịch thực hiện trước khi duyệt bổ sung.
Mất bao lâu để hoàn thành phần mềm?
Thời gian phụ thuộc chức năng, tích hợp, dữ liệu và tiến độ phản hồi. Kế hoạch theo giai đoạn được xác định sau khảo sát.
CÙNG XÁC ĐỊNH YÊU CẦU
Trao đổi về phần mềm bạn cần.
Mô tả quy trình và vấn đề cần giải quyết để cùng xác định phạm vi phù hợp.