Nói rõ việc cần giải quyết trước khi hỏi về công nghệ
Muốn chọn công ty phát triển phần mềm, trước hết bạn cần giúp các bên hiểu cùng một nhu cầu. Nếu một bên báo giá cho việc quản lý đơn hàng đơn giản, còn bên kia tính cả kho và kế toán, tổng tiền sẽ không thể so sánh trực tiếp. Bạn chưa cần tài liệu kỹ thuật đầy đủ. Hãy bắt đầu bằng công việc cần cải thiện, người sẽ sử dụng và những giới hạn đã biết.
Một bản mô tả ngắn nhưng rõ vấn đề thường hữu ích hơn danh sách dài tên các màn hình. Chẳng hạn, “giảm việc nhập lại đơn hàng giữa bộ phận bán hàng và kho” cho đối tác biết mục tiêu cần giải quyết. Hãy tách điều bắt buộc, điều có thể làm sau và điều chưa rõ cần khảo sát thêm.
Mẫu mô tả yêu cầu gửi cho các nhà cung cấp
Bản mô tả ban đầu cần cho đối tác biết doanh nghiệp đang làm việc ra sao và mong muốn thay đổi điều gì. Chỉ gửi tài liệu được phép chia sẻ; dùng dữ liệu giả lập thay cho dữ liệu thật khi cần. Nếu có điều kiện về bảo mật hoặc pháp lý, hãy nêu ngay từ đầu vì chúng có thể ảnh hưởng đến cách thiết kế và triển khai.
Bạn có thể sao chép mẫu dưới đây và thay phần trong ngoặc vuông bằng thông tin của mình. Gửi cùng một bản cho các nhà cung cấp để nhận được những đề xuất dễ so sánh hơn. Với mục chưa có câu trả lời, hãy ghi “cần khảo sát” thay vì đoán rồi coi đó là yêu cầu đã chốt.
- Bài toán: [công việc đang gặp khó khăn và hậu quả hiện tại].
- Người sử dụng và người quyết định: [vai trò, phòng ban, đầu mối xác nhận].
- Quy trình: [các bước chính, người duyệt, ngoại lệ và biểu mẫu minh họa].
- Phạm vi: [chức năng bắt buộc] / Chưa làm: [phần loại trừ].
- Dữ liệu và tích hợp: [nguồn cần chuyển, hệ thống cần kết nối, hạn chế chia sẻ].
- Nghiệm thu: [thao tác cần hoàn thành, kết quả mong đợi, người xác nhận].
- Ngân sách và thời hạn: [khoảng ngân sách dự kiến, ngày cần hoàn thành và lý do].
- Bàn giao và hỗ trợ: [mã nguồn, tài liệu, quyền truy cập, nhu cầu bảo hành/bảo trì].
- Điểm cần khảo sát: [điều chưa rõ hoặc mới đang dự đoán, người có thể xác nhận].
Đối tác có hỏi đúng những điều còn thiếu không?
Một đối tác phù hợp cần giúp bạn nhận ra điều còn thiếu, không chỉ xác nhận rằng họ làm được. Hãy hỏi họ sẽ tìm hiểu quy trình bằng cách nào, khi nào bạn được xem thiết kế và điều gì có thể làm báo giá thay đổi. Nếu câu trả lời chỉ nói về tốc độ lập trình mà chưa đề cập đến dữ liệu và người sử dụng, bạn cần hỏi thêm.
Ví dụ giả định: bạn muốn làm hệ thống duyệt chi phí. Đối tác nên hỏi ai được duyệt từng mức tiền, ai thay thế khi quản lý nghỉ và chứng từ được lưu thế nào. Nếu đề xuất mới chỉ có đăng nhập, danh sách và nút duyệt, các quy tắc quan trọng vẫn chưa được làm rõ. Đây mới là phần ảnh hưởng nhiều đến cách xây dựng hệ thống.
| Câu hỏi | Câu trả lời đủ rõ | Điểm cần hỏi lại |
|---|---|---|
| Ai kiểm thử và dựa vào đâu? | Nêu người kiểm tra, điều kiện đạt, kết quả và cách xử lý lỗi còn lại | Chỉ nói có bộ phận kiểm thử hoặc đảm bảo chất lượng |
| Báo giá bao gồm những gì? | Nêu kết quả bàn giao, điều kiện tính giá, việc chưa bao gồm và phần khách hàng cần chuẩn bị | Chỉ đưa tổng tiền và tên các màn hình |
| Thay đổi yêu cầu được xử lý thế nào? | Đánh giá ảnh hưởng rồi xin phê duyệt chi phí và lịch trình trước khi làm | Không nêu ai duyệt hoặc lúc nào tính phát sinh |
| Sau bàn giao, ai tiếp nhận sự cố? | Nêu kênh liên hệ, phạm vi hỗ trợ và thời gian phản hồi theo thỏa thuận | Hứa hỗ trợ lâu dài nhưng không có điều kiện cụ thể |
Một câu trả lời ngắn chưa đủ để kết luận nhà cung cấp thiếu năng lực. Hãy hỏi thêm và đề nghị xem tài liệu mẫu họ được phép chia sẻ. Những nội dung đã trao đổi cần được ghi lại trong đề xuất hoặc hợp đồng để hai bên có cùng cơ sở thực hiện.
Báo giá có đang bao gồm cùng một khối lượng công việc?
Với mỗi báo giá, hãy yêu cầu danh sách việc sẽ làm, việc chưa bao gồm, kết quả bàn giao từng giai đoạn và phần khách hàng phải chuẩn bị. Báo giá thấp hơn có thể chưa tính chuyển dữ liệu, kiểm tra kết nối với hệ thống khác hoặc hướng dẫn sử dụng. Điều này không nhất thiết là bất lợi, miễn là bạn biết rõ trước khi ký.
- Có tài liệu yêu cầu, thiết kế và môi trường thử nghiệm để khách hàng xác nhận không?
- Ai kiểm thử, dựa vào tiêu chí nào và lỗi được phân loại ra sao?
- Yêu cầu thay đổi được ước tính, phê duyệt và cập nhật tiến độ như thế nào?
- Khi khách hàng chậm cung cấp dữ liệu hoặc bên tích hợp chưa sẵn sàng, kế hoạch được xử lý ra sao?
Bạn nhận được gì và ai hỗ trợ sau bàn giao?
Hãy làm rõ quyền của bạn đối với mã nguồn, dữ liệu và các thư viện hoặc dịch vụ bên ngoài được dùng trong phần mềm. Thanh toán dự án không có nghĩa bạn sở hữu mọi thành phần đó. Hợp đồng cần nêu tài liệu, tài khoản và quyền truy cập được bàn giao, cũng như điều kiện để một đội ngũ khác tiếp quản khi cần.
Bảo hành lỗi, bảo trì và làm thêm tính năng là các công việc khác nhau. Bạn cần hỏi lỗi nào được sửa trong phạm vi bảo hành, việc cập nhật thư viện có nằm trong bảo trì không và tính năng mới được tính phí thế nào. Hãy ghi rõ kênh báo sự cố, thời gian phản hồi đã thỏa thuận và điều kiện hỗ trợ ngoài giờ.
Cần hỏi gì nếu đối tác dùng AI để lập trình?
Nhà cung cấp dùng AI để lập trình không có nghĩa phần mềm của bạn sẽ là một sản phẩm AI. Điều cần hỏi là dữ liệu nào được gửi vào công cụ, ai cho phép và ai kiểm tra code trước khi bàn giao. Nếu đối tác nói sẽ nhanh hơn hoặc rẻ hơn, hãy yêu cầu họ nêu công việc cụ thể và cách so sánh, thay vì chỉ đưa một lời hứa chung.
Nếu nhu cầu còn nhiều điểm chưa rõ, bạn có thể bắt đầu bằng khảo sát hoặc thử làm một phần nhỏ với kết quả bàn giao cụ thể. Ưu tiên đối tác giải thích được lựa chọn của họ, nói rõ giới hạn và cho bạn xem kết quả kiểm tra. Hai bên cần thống nhất ai quyết định, ai thực hiện và cách xử lý khi yêu cầu thay đổi.
Để kiểm tra các khoản trong đề xuất, xem cách lập ngân sách phát triển phần mềm theo yêu cầu