Change requirement hay Change request (CR) là một phần việc trong quá trình quản lý yêu cầu (requirement management). CR không chỉ giới hạn ở việc thay đổi yêu cầu mà còn là thay đổi phạm vi dự án hoặc kế hoạch phát triển. Tuy nhiên trong post này mình sẽ chỉ nhắc đến việc thay đổi về yêu cầu.
CR đến từ đâu?
CR có thể đến từ nhiều nguồn khác nhau, thường gặp nhất là các nguồn sau:
Từ khách hàng: khách hàng thay đổi tư duy, nghiệp vụ hoặc do các ràng buộc về cơ chế nội bộ, nguồn vốn… dẫn đến việc phát sinh CR.
Từ BA: phát sinh thêm chức năng/logic trong quá trình phân tích mà ban đầu BA không phát hiện ra hoặc bị thiếu sót.
Từ dự án: các ràng buộc về mặt công nghệ, nguồn lực dẫn đến việc phải thay đổi yêu cầu để phù hợp với giải pháp về mặt công nghệ
Làm gì khi gặp CR?
Khi gặp CR, BA nên có 1 quy trình rõ ràng để quản lý. Việc này giúp đảm bảo rằng các CR được đánh giá, kiểm tra, và thực hiện một cách có hệ thống. Từ đó, các bạn sẽ tránh được tình trạng cập nhật tủn mủn, cứ có CR là lao vào update tài liệu.
Quy trình quản lý CR các bạn có thể tham khảo các bước sau:
Ghi nhận: khi tiếp nhận CR, bạn cần đảm bảo được thông tin về sự thay đổi được ghi nhận lại một cách đầy đủ. Tại bước này, URD, MoM là các công cụ hữu ích trong việc ghi nhận thông tin.
Đánh giá & phân tích ảnh hưởng: CR sau khi được tiếp nhận không nên triển khai luôn mà cần phân tích mức độ ảnh hưởng. Ở bước này này, bạn dùng kỹ thuật Impact analysis để phân tích phạm vi ảnh hưởng, mức độ ảnh hưởng khi áp dụng thay đổi. Từ đó đưa ra được danh sách các chức năng/tính năng bị ảnh hưởng cùng với ước lượng về thời gian, nguồn lực cho CR tương ứng.
Xác nhận: CR sau khi được đánh giá ảnh hưởng, ước lượng thời gian và nguồn lực thực hiện cần phải được xác nhận lại với các bên. Trong một số trường hợp, vì thời gian và nguồn lực phải bỏ ra quá lớn mà CR có thể sẽ bị huỷ bỏ hoặc chuyển đổi thành CR khác. Nếu CR được chuyển đổi, các bạn bắt đầu lại từ bước 1 cho đến khi được chấp thuận.
Thực hiện: đến đây thì đơn giản rồi, đã hiểu rõ được thay đổi, phân tích được hết phạm vi ảnh hưởng thì bắt tay vào triển khai, viết tài liệu …
Theo dõi: bình thường sau khi triển khai được CR thì hầu hết các bạn đều coi như là đã xong. Tuy nhiên như mình có nhắc đến ở bài viết về quản lý yêu cầu. CR sau khi được cập nhật cũng cần phải được lưu lại lịch sử thay đổi. Các bạn có thể sử dụng requirement traceability để tracking.
Lưu ý trong quá trình quản lý CR:
Đảm bảo CR được đánh giá kỹ lưỡng về mức độ nghiệp vụ cũng như kỹ thuật như khi các bạn tiếp nhận yêu cầu mới.
Phân tích ảnh hưởng cần được thực hiện để giảm thiểu rủi ro cho sản phẩm.
Mọi CR nên được chia sẻ minh bạch và được confirm từ các bên liên quan.
Khi có quá nhiều CR hoặc dự án đang trong giai đoạn gấp rút, cần sắp xếp độ ưu tiên để thực hiện. Chẳng hạn như: Impact ít, dễ làm và mang lại nhiều giá trị có thể làm trước, khó làm mà ít giá trị để lại sau…
Thực tế gặp phải:
Trong quá trình làm việc, có một số điểm mình rút ra trong thực tế quản lý, triển khai CR như sau:
CR xảy ra quá thường xuyên: vấn đề này đến tự việc khách hàng thay đổi quá nhiều cho một hoặc một vài vấn đề. Nếu bạn gặp phải trường hợp này thì hãy lên tiếng để họ nắm được rằng:
Việc thay đổi như này sẽ ảnh hưởng đến dự án và ví tiền của nhà đầu tư.
Không phải lúc nào CR cũng sẽ được đáp ứng luôn mà còn phải phát triển những phần yêu cầu khác nữa.
Thay đổi quá nhiều sẽ dẫn đến giảm tinh thần của đội ngũ phát triển, ảnh hưởng đến chất lượng sản phẩm.
Đưa ra 1 vài tiêu chí chấp thuận cho việc đưa ra CR (VD như không quá 5% tổng effort dự án, hoặc không thay đổi quá 3 lần cho 1 function/feature…)
Giai đoạn ghi nhận và xác nhận hoàn toàn có thể làm cùng lúc và trong cùng 1 thời điểm bạn nhận yêu cầu từ khách hàng nếu bạn đủ tự tin về mức độ hiểu biết sản phẩm và kỹ năng phân tích của bản thân. Tuy nhiên, không nên chủ quan mà hãy cố gắng cẩn thận nhất có thể.
Quá trình phê duyệt CR có thể không có hoặc rất mất thời gian: nếu bạn gặp trường hợp trên, thay vì chờ khách hàng confirm, bạn hãy bàn với quản lý dự án để đưa ra quyết định tạm thời về việc triển khai/tạm dừng CR. Bạn không nên treo đầu việc mà không có xử lý gì.
CR vô lý: đôi khi CR khách hàng đưa ra khá vô lý hoặc không khả thi với công nghệ hiện tại của dự án. Thay vì việc gạt đi, bạn hãy thử tìm một giải pháp khác vẫn đáp ứng được mong muốn của khách hàng và thuyết phục họ với giải pháp đó.
Hy vọng bài post này sẽ giúp ích cho các bạn trong quá trình quản lý yêu cầu.
Comments