Quản lý thay đổi dự án: Quy trình tiếp nhận, đánh giá tác động và phê duyệt Change Request.

Tiếp nhận vấn đề trước khi tiếp nhận giải pháp

Người đề nghị thường mô tả tính năng muốn có, nhưng đội dự án cần hiểu công việc đang gặp khó. Thêm một bước phê duyệt có thể xuất phát từ thiếu quyền quyết định hoặc thiếu thông tin, không nhất thiết cần sửa hệ thống. Hồ sơ ban đầu nên ghi nguồn yêu cầu, lý do, người chịu tác động, kết quả mong muốn và thời điểm cần. Những nội dung này giúp đánh giá giá trị của thay đổi trước khi tính công phát triển.

Mọi kênh trao đổi có thể cung cấp đầu vào, nhưng cần một nơi ghi nhận chính thức. Yêu cầu phát sinh trong cuộc họp, email hay trao đổi trực tiếp phải được đưa về cùng đầu mối trước khi trở thành cam kết. Người thực hiện có thể xác nhận khả năng kỹ thuật nhưng không nên tự chốt lịch và chi phí nếu chưa có quyền. Việc ghi nhận phải thuận tiện để các bên không có động lực đi vòng ngoài quy trình.

Phân loại ban đầu giúp chọn cách xử lý. Một đề nghị có thể là làm rõ yêu cầu, sửa sản phẩm chưa đáp ứng điều đã thống nhất, thay phạm vi hoặc thay cách triển khai. Không phải mọi trường hợp cần cùng mức phê duyệt, nhưng trường hợp làm đổi cam kết phải được đánh giá. Phân loại cũng không được dùng để bỏ qua tác động chỉ vì yêu cầu được gọi là sửa nhỏ.

Năng lực quản lý dự án IT giúp giữ liên kết giữa yêu cầu và phần việc. Khi đã hiểu vấn đề, bước kế tiếp cần xác định cơ sở nào sẽ bị thay đổi và thông tin nào phải có trước khi ra quyết định.

Xác định phiên bản bị tác động và phần cần khảo sát

Đội dự án cần đối chiếu yêu cầu với phạm vi, tiêu chí chấp nhận, kiến trúc và kế hoạch đang được sử dụng. Nếu các bên không cùng phiên bản, phân tích có thể giải quyết một thay đổi đã có hoặc bỏ sót phần phát sinh thật. Hồ sơ nên chỉ rõ yêu cầu hay sản phẩm liên quan bằng mã hoặc đường dẫn ổn định. Một mô tả chung như thay báo cáo khó giúp nhóm kiểm thử biết cần kiểm tra lại phần nào.

Phần chưa đủ thông tin phải được ghi thành câu hỏi cần khảo sát. Ví dụ, muốn mở rộng phân quyền cần biết vai trò nghiệp vụ, nguồn dữ liệu và cách xử lý người dùng giữ nhiều vai trò. Nếu chưa rõ, có thể đề nghị thực hiện một bước phân tích giới hạn. Quyền khảo sát và quyền triển khai phải được tách để tránh một bước tìm hiểu nhỏ trở thành cam kết toàn bộ.

Người sở hữu sản phẩm cần xác nhận tác động nghiệp vụ, còn kỹ thuật xác nhận phần giải pháp và tích hợp. Đội vận hành, dữ liệu hoặc an toàn thông tin tham gia khi thay đổi ảnh hưởng trách nhiệm của họ. Không cần tham vấn mọi người cho mọi yêu cầu, nhưng không được bỏ người có thông tin thiết yếu. Hồ sơ cần giữ những ý kiến khác biệt và điều kiện còn chưa đạt.

Việc kiểm tra sử dụng và hỗ trợ gắn với năng lực Quản Lý Dịch Vụ IT – ITSM. Một thay đổi có thể dễ triển khai nhưng làm tăng việc cấp quyền, giám sát hoặc xử lý sự cố. Khi nhìn rõ chuỗi trách nhiệm, đội mới có thể đưa ra các phương án đủ để người phê duyệt lựa chọn.

Đánh giá tác động bằng các phương án có điều kiện

Phân tích cần tính cả phần mới và phần phải làm lại. Thay đổi phân quyền có thể kéo theo dữ liệu mẫu, kịch bản kiểm thử, hướng dẫn và kiểm tra những báo cáo không được sửa trực tiếp. Nỗ lực cần được nối vào lịch để biết có tác động mốc kết thúc hay không. Một công việc nhỏ nhưng cần chuyên gia khan hiếm trước nghiệm thu có thể ảnh hưởng lớn hơn dự kiến.

Không nên chỉ trình một lựa chọn làm hoặc không làm. Có thể triển khai giới hạn, thay thế một phần ít ưu tiên, đưa sang lần phát hành sau hoặc xử lý bằng quy trình tạm phù hợp. Mỗi phương án cần nêu giá trị còn giữ, chi phí, điều kiện và rủi ro. Giải pháp tạm phải có chủ sở hữu và thời điểm xem lại, không trở thành nghĩa vụ vận hành vô thời hạn.

Bảng dưới đây là công cụ đề xuất cho hồ sơ tác động. Nó giữ nội dung đủ gọn để hỗ trợ quyết định nhưng không thay thế phân tích kỹ thuật chi tiết khi cần.

Một ước lượng có khoảng bất định cần giữ căn cứ cùng khoảng đó. Nếu người phê duyệt muốn giữ ngày cũ, hồ sơ phải cho thấy phần nào phải đổi để thực hiện được. Không nên giảm ước lượng chỉ để đề nghị dễ được chấp thuận. Điều cần xin là một quyết định khả thi, không phải sự đồng ý đối với một kế hoạch đẹp hơn bằng chứng.

Chốt đúng thẩm quyền và giữ dấu vết quyết định

Quyền phê duyệt nên được xác định trước theo mức ảnh hưởng. Người quản lý có thể xử lý trong giới hạn được giao, còn thay mục tiêu, tăng ngân sách hoặc chấp nhận rủi ro vượt giới hạn cần trình cấp có thẩm quyền. Cơ chế không phải lúc nào cũng cần một ban riêng; điều quan trọng là người chốt có quyền phù hợp và các bên biết đường xử lý.

Các lựa chọn có thể là chấp thuận, chấp thuận có điều kiện, yêu cầu bổ sung, hoãn hoặc từ chối. Mỗi trạng thái cần lý do và việc tiếp theo. Một yêu cầu chấp thuận có điều kiện chưa nên được thực hiện ngoài phần đã cho phép trước khi điều kiện được đáp ứng. Yêu cầu bị hoãn cần điểm xem lại để không bị hiểu thành lời hứa thực hiện chắc chắn.

Vai trò điều hành trong chương trình Giám Đốc Dự Án IT giúp đưa sự đánh đổi về giá trị đến đúng người. Nhóm kỹ thuật đánh giá khả thi, nhưng không mặc nhiên chốt việc giảm lợi ích hoặc tăng gánh nặng cho nghiệp vụ. Quyết định cần có thời điểm, người xác nhận và những giới hạn kèm theo.

Đối với trường hợp khẩn, vẫn cần đường phê duyệt phù hợp, ghi phạm vi được thực hiện và bằng chứng quyết định. Những bước hoàn thiện hồ sơ sau đó phải có người nhận và thời hạn. Khẩn cấp không có nghĩa mọi người được quyền sửa trực tiếp mà không kiểm soát phiên bản hoặc không thông báo cho người chịu tác động.

Chuyển quyết định vào kế hoạch và kiểm tra thực hiện

Sau phê duyệt, phải cập nhật yêu cầu, gói công việc, lịch, dự báo chi phí và tiêu chí kiểm tra liên quan. Người nhận công việc phải biết phiên bản áp dụng. Các kế hoạch cũ cần được giữ làm lịch sử nhưng không tiếp tục được dùng như phiên bản hiện hành. Nếu thay đổi ảnh hưởng hợp đồng, người phụ trách cần xử lý theo thẩm quyền và điều kiện thực tế.

Nguồn lực bổ sung phải được xác nhận với người cung cấp, không chỉ được ghi trong hồ sơ. Sự phối hợp với Trưởng Phòng IT – IT Manager giúp chuyển lựa chọn thành lịch làm việc có thể thực hiện. Khi nhiều thay đổi dùng chung chuyên gia, phải xem tổng cam kết, không chỉ khả năng đáp ứng từng yêu cầu riêng lẻ.

Hồ sơ thay đổi cần được liên kết với kết quả kiểm chứng. Đội kiểm thử xác định phần kiểm tra mới và hồi quy phù hợp, còn người dùng xác nhận tác động nghiệp vụ. Không nên đóng Change Request chỉ vì mã đã được đưa vào môi trường. Điều kiện đóng phải phản ánh phần được phê duyệt đã hoàn tất và những nghĩa vụ còn lại đã có nơi tiếp nhận.

Dùng lịch sử thay đổi để phát hiện vấn đề trong cách khởi động

Một yêu cầu riêng lẻ có thể hoàn toàn hợp lý, nhưng nhiều yêu cầu tương tự có thể cho thấy phạm vi ban đầu hoặc quá trình làm rõ nhu cầu còn thiếu. Nên xem nguồn phát sinh, thời điểm, phần làm lại và những yêu cầu quay lại sau khi bị hoãn. Mục đích là cải thiện cách xác nhận nhu cầu và dự báo, không phải đặt chỉ tiêu ngăn mọi thay đổi.

Nếu phần lớn đề nghị chỉ xuất hiện lúc trình diễn cuối, cần xem người dùng đã có cơ hội phản hồi sớm chưa. Nếu thay đổi thường chậm phê duyệt, cần xem hồ sơ thiếu thông tin hay quyền quyết định quá nhiều tầng. Dữ liệu quy trình nên dẫn đến một biện pháp cụ thể có người thực hiện. Chỉ thống kê số yêu cầu đóng sẽ ít giúp giải quyết cơ chế tạo ra sự chậm trễ.

Với phân quyền báo cáo ở mở bài, bước cần làm là đối chiếu phiên bản yêu cầu, lịch kiểm thử và tài liệu hỗ trợ với quyết định đã chấp thuận. Sau đó xác nhận bằng chứng trước khi đóng. Một quy trình thay đổi tốt nối được đề nghị, lựa chọn và thực hiện thành một chuỗi, để dự án thích ứng mà không mất cơ sở kiểm soát.

Bài viết liên quan

• Quản lý yêu cầu và khả năng truy xuất bằng Requirements Traceability Matrix.
• Lập kế hoạch kiểm thử, UAT và nghiệm thu sản phẩm bàn giao.
• Kiểm soát nhà thầu và các sản phẩm bàn giao theo hợp đồng.
• Khách hàng đổi yêu cầu sát ngày nghiệm thu: Project Manager nên phản hồi ra sao?

Nguồn tham khảo

1. APM — What is change control?
2. UK Government — Government Functional Standard GovS 002: Project Delivery
3. APM — What is quality management and control?