Yêu cầu thay đổi giữa dự án: Xử lý thế nào?
Trong quá trình phát triển phần mềm, người dùng có thể phát hiện một bước xử lý còn thiếu hoặc nhận ra cách làm ban đầu chưa phù hợp. Tuy nhiên, trước khi nhận thêm việc, hai bên cần thống nhất sẽ sửa những gì, có phát sinh chi phí không và tiến độ có thay đổi hay không.
Bài viết dùng một ví dụ giả định về đổi địa chỉ giao hàng để giải thích cách xử lý yêu cầu thay đổi, từ lúc tiếp nhận đến khi kiểm tra bản sửa. Cách làm này giúp người phụ trách doanh nghiệp và đội phát triển cùng hiểu cần làm gì, ai quyết định và khi nào một yêu cầu được coi là hoàn tất.
1. Hỏi rõ cần thay đổi gì và vì sao
Khi có yêu cầu sửa phần mềm, hai bên cần hiểu rõ người dùng đang gặp vấn đề gì và muốn thay đổi điều gì.
Ví dụ, phần mềm hiện cho phép nhân viên tạo đơn, quản lý duyệt rồi kho chuẩn bị hàng. Khi dùng thử, đội bán hàng muốn thêm nút “duyệt lại” để xử lý trường hợp khách đổi địa chỉ sau khi đơn đã được duyệt. Tuy nhiên, điều cần làm rõ là đơn còn được đổi địa chỉ ở bước nào và làm sao để kho nhận đúng địa chỉ mới. Nếu chưa thống nhất cách xử lý, thêm nút cũng chưa giải quyết được vấn đề.
Tiếp theo, hãy đối chiếu với nội dung đã thống nhất trước đó. Nếu phần mềm phải hỗ trợ tình huống này nhưng chưa làm được, cần kiểm tra và sửa phần chưa đáp ứng. Nếu đây là nhu cầu mới, hai bên cần xác định phần việc bổ sung. Nếu tài liệu viết chưa rõ, hãy thống nhất lại trước khi bàn thời gian và chi phí.
Khi đã hiểu rõ yêu cầu, nhóm phát triển mới có thể xác định những phần cần sửa và xem việc sửa đó có ảnh hưởng đến chức năng hoặc dữ liệu nào khác không.
2. Xác định những phần cần sửa khi thay đổi yêu cầu
Trong ví dụ đổi địa chỉ, hai bên cần thống nhất cách xử lý cho từng trường hợp. Chẳng hạn, khi chưa bàn giao hàng cho đơn vị vận chuyển, bán hàng gửi yêu cầu đổi địa chỉ và kho chờ địa chỉ được xác nhận rồi mới tiếp tục. Khi hàng đã bàn giao, yêu cầu được chuyển cho người phụ trách vận chuyển. Doanh nghiệp cần xác nhận cách xử lý này có phù hợp với công việc thực tế hay không.
Từ quy trình đã thống nhất, nhóm phát triển sẽ kiểm tra địa chỉ trên màn hình, phiếu giao hàng, thông báo cho kho và dữ liệu gửi sang dịch vụ vận chuyển để xác định cần sửa ở đâu. Nếu màn hình hiện địa chỉ mới nhưng phiếu đã in vẫn ghi địa chỉ cũ, hàng vẫn có thể bị gửi nhầm. Vì vậy, cần xem cả những thông tin và bước xử lý liên quan, chứ không chỉ kiểm tra nút “duyệt lại”.
Một điểm khác cần làm rõ là quy tắc mới áp dụng cho đơn tạo sau lần cập nhật hay cả những đơn đang chờ giao. Nếu bao gồm đơn cũ, nhóm phát triển phải kiểm tra dữ liệu đã lưu và cách chuyển các đơn đó sang quy trình mới. Nhân viên cũng cần được hướng dẫn trước khi sử dụng. Đây đều là công việc cần tính đến khi ước lượng thời gian và chi phí.
Yêu cầu càng rõ thì nhóm phát triển càng có cơ sở xác định phần cần sửa. Bạn có thể tham khảo cách chuẩn bị thông tin trong bài Phân tích yêu cầu là gì? Bước đầu để phát triển đúng hướng.
3. Thống nhất phương án, chi phí và người phê duyệt
Khi đã biết cần sửa những gì, hai bên có thể so sánh các phương án. Với yêu cầu đổi địa chỉ, một cách là phát triển đầy đủ chức năng gửi yêu cầu và duyệt lại. Cách khác là chỉ cho phép đổi trước khi kho chuẩn bị hàng. Doanh nghiệp cũng có thể giữ lịch ra mắt và tạm giao một người tiếp nhận, xử lý các đề nghị đổi địa chỉ.
Mỗi phương án đều có điều cần cân nhắc. Phát triển đầy đủ cần thêm thời gian thiết kế và kiểm thử. Giới hạn thời điểm được đổi có thể giảm công phát triển, nhưng một số trường hợp vẫn phải xử lý riêng. Cách làm tạm bằng tay chưa đòi hỏi sửa phần mềm ngay, song tăng việc cho nhân viên và dễ bỏ sót nếu theo dõi không tốt. Doanh nghiệp nên cân nhắc số lần phát sinh, hậu quả khi xử lý sai và khả năng tiếp nhận của người phụ trách.
Trước khi chọn, hãy đề nghị đối tác làm rõ từng phương án cần bao nhiêu thời gian, chi phí có thay đổi không và có ảnh hưởng đến các việc đã lên kế hoạch hay không. Nếu chưa đủ thông tin để ước lượng, hai bên cần thống nhất nội dung phải khảo sát thêm và khi nào có thể trả lời. Ước lượng ban đầu chỉ nên được dùng để cân nhắc phương án, chưa phải ngày hoàn thành đã được cam kết.
Nếu phạm vi hoặc chi phí thay đổi, báo giá cũng cần thể hiện rõ nội dung đã điều chỉnh. Cần làm rõ những gì khi nhận báo giá phần mềm?
Người đề nghị cần giải thích vì sao thay đổi cần thiết; nhóm kỹ thuật đánh giá công việc và rủi ro; người có thẩm quyền phê duyệt phương án, ngân sách và thời điểm thực hiện. Nếu nhiều phòng ban cùng gửi yêu cầu, nên có một người tổng hợp và xác nhận việc nào đã được duyệt trước khi chuyển cho đội phát triển. Nhờ đó, một đề nghị đang trao đổi sẽ không bị hiểu nhầm là yêu cầu phải làm ngay.
4. Ghi lại quyết định và kiểm tra kết quả
Sau khi được phê duyệt, yêu cầu thay đổi cần được ghi vào danh sách theo dõi chung. Nội dung nên nêu rõ sẽ làm gì, chưa làm gì, ai đã duyệt và thời gian, chi phí đã thống nhất. Nếu hoãn hoặc không thực hiện, cũng cần lưu lý do để các bên có thể tra lại khi cần.
Đồng thời, cập nhật mô tả yêu cầu, tiêu chí nghiệm thu và hướng dẫn sử dụng có liên quan. Người phát triển, người kiểm tra và người hỗ trợ phải dùng cùng một bản tài liệu mới nhất. Chỉ chốt trong cuộc trò chuyện mà không sửa tài liệu có thể khiến nhóm tiếp tục làm theo yêu cầu cũ.
Cách kiểm tra cần được thống nhất trước khi nhóm bắt đầu sửa. Với ví dụ đổi địa chỉ, hai bên có thể kiểm tra đơn còn được phép thay đổi, đơn đã bàn giao vận chuyển và trường hợp gửi yêu cầu hai lần. Kết quả cần xác nhận là kho nhận đúng địa chỉ đã duyệt, địa chỉ cũ vẫn được lưu khi yêu cầu chưa được chấp nhận và thao tác lặp không tạo yêu cầu trùng. Những tình huống này phải được điều chỉnh theo phương án thực tế đã chọn.
Khi nhận bản sửa, hãy kiểm tra theo các tình huống đã thống nhất, thay vì chỉ xem chức năng mới có xuất hiện hay không.
Nghiệm thu phần mềm: Doanh nghiệp cần kiểm tra gì?
Trong quá trình thực hiện, hãy theo dõi riêng các trạng thái “đã duyệt”, “đã sửa” và “đã kiểm tra đạt”. Với việc khẩn cấp, cần ghi rõ ai cho phép sửa, phần nào phải làm ngay và phần nào cần kiểm tra bổ sung. Khi sự cố trước mắt đã được xử lý, các bước còn lại vẫn phải có người theo dõi đến khi hoàn tất.
Sau khi đưa bản sửa vào sử dụng, cần hỏi lại người dùng xem vấn đề ban đầu đã được giải quyết chưa và họ có còn phải xử lý bằng tay không. Nếu phát sinh nhu cầu khác, hãy tạo yêu cầu mới và ghi rõ liên quan đến thay đổi nào trước đó. Việc này giúp đội dự án theo dõi đúng phần đã hoàn tất, phần còn cần làm và lý do tiến độ hoặc phạm vi thay đổi.
Nếu dự án đang nhận yêu cầu từ nhiều phòng ban, hãy bắt đầu bằng một danh sách dùng chung và một người phụ trách tổng hợp. Bạn có thể trao đổi với Fenix từ một yêu cầu cụ thể để cùng xác định phần cần sửa, ảnh hưởng đến dự án và cách triển khai phù hợp.
