Change Request là gì?

Change request (CR) là một đề xuất nhằm thay đổi một sản phẩm, hệ thống, thường được đưa ra bởi khách hàng hoặc một thành viên khác trong nhóm. Trong một dự án phần mềm, CR có thể xảy ra khi khách hàng muốn thay đổi Req Spec hoặc FS (Functional Spec), thay đổi sản phẩm cái mà đã được thỏa thuận từ trước.

Có 2 loại thay đổi:

• Những yêu cầu nằm trong phạm vi
• Những yêu cầu nằm ngoài phạm vi

Cụ thể là:

• CR trong phạm vi liên quan đến các chỉnh sửa nhỏ với 1 yêu cầu hiện có và thường ảnh hưởng nhỏ tới budget của dự án hoặc phần còn lại của dự án.
• Mặt khác, CR ngoài phạm vi thường cần một thời gian đáng kể để thực hiện và có tác động nhiều tới budget của dự án.

Yêu cầu thay đổi thường chứa đựng nhiều rủi ro, nguyên nhân của các incidents, các problem, là nguồn cơn của các phàn nàn về chất lượng dịch vụ.

Thay đổi yêu cầu có cần thiết hay không?

Yêu cầu đôi khi cũng chỉ là yêu cầu, hãy đưa ra thật nhiều câu hỏi để trả lời cho câu hỏi "why".

Với bất kỳ yêu cầu thay đổi nào, người tham gia cung cấp dịch vụ CNTT cần trả lời cho các câu hỏi:

• Tại sao khách hàng lại muốn CR?
• Ai (Stakeholder, Advisor, Admin user, end-user...) nào đưa ra CR?
• Giá trị tạo ra (hay trả về) cho CR là gì?
• Những rủi ro nào đi kèm nếu CR đó được triển khai?
• CR này xuất hiện khi nào? Trước nửa chặng đường triển khai hay ở nửa sau?
• Chấp nhận CR có ảnh hưởng đến kế hoạch triển khai dự án? 
• Khách hàng có đồng ý điều chỉnh tiến độ nếu CR được thông qua?
• Ai là người chịu trách nhiệm nghiệm thu CR?
• Không thực hiện yêu cầu này có sao không?
• Thực hiện yêu cầu này có ảnh hưởng gì tới các phần khác không? 
• Có đủ nhân sự để nhận trách nhiệm xây dựng, kiểm thử, triển khai CR?

Với mọi trao đổi của khách hàng, chúng ta nên bình tĩnh trao đổi hơn là chỉ biết làm theo. Chúng ta không nên từ chối ngay tại cuộc họp, chúng ta có thể trả lời thân thiện "chúng tôi ghi nhận thay đổi này, chúng tôi sẽ báo cáo với lãnh đạo và sẽ cùng team BA phân tích kỹ các tác động đến các tính năng đã hoàn thiện. Chúng tôi sẽ gửi văn bản kết luận sau 3 ngày".

Có một quy luật là: Sau một thời gian đủ dài trao đổi thông tin qua lại, "xới tung" các vấn đề hiện tại và dự báo cáo vấn đề sẽ gặp phải, chính bản thân khách hàng cũng sẽ nghĩ là không cần làm CR này nữa. Như vậy về phía nhà thầu thì "không đánh mà thắng", còn phía khách hàng thì tránh được các vấn đề tồi tệ phát sinh sau này liên quan đến chất lượng và tiến độ tổng thể của dự án. 

Tại sao Change Request không tránh khỏi trong các dự án phần mềm?

Có bao giờ bạn tự đặt câu hỏi tại sao cần phải thay đổi? Đó là một câu hỏi không dễ trả lời. Trong cuộc sống, ngay chính bản thân bạn cũng có lúc thay đổi ít hay nhiều. Do đó khách hàng không phải ngoại lệ. Có những thay đổi là hợp lý, có những thay đổi là bất hợp lý, là sai logic...

Chúng ta cần trả lời các câu hỏi sau:

• Chúng ta có chắc hệ thống đang vận hành có đang lỗi thời?
• Chúng ta có biết khách hàng có thể sẽ thích những dịch vụ mà hiện tại chúng ta không cung cấp?
• Trước những thay đổi của thời đại thì hệ thống có cần phải điều chỉnh ... Có rất nhiều lý do khiến chúng ta phải thay đổi, việc thay đổi là cần thiết và không cần bàn cãi ở đây. Trong Agile cũng đã đề cập tới Change Request ở nguyên tắc số 2.

One of the principles of Agile, a methodology for iterative and flexible software development, is Embrace Change. The principle says, “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”

Việc thay đổi là không tránh khỏi, vậy thì hãy đón nhận việc thay đổi là bình thường. Cũng giống như mọi quy luật khác trong cuộc sống: Mọi thứ đều có giới hạn. Dự án có thành công hay thất bại, tất cả nằm trong khả năng kiểm soát thay đổi của người quản lý dự án.

Tại sao cần xây dựng quy trình quản lý các Change Request?

Quản lý thay đổi nhằm tạo ra một tập hợp các tiêu chuẩn và quy tắc cần được tuân thủ trong tài liệu thay đổi theo yêu cầu. Đối với mỗi sự thay đổi lớn đối với phạm vi của dự án, cần xác định rằng CR phải được đi qua một quy trình phân tích và phê duyệt trược khi được chuyển cho nhóm kỹ thuật thực hiện. Có những trường hợp cần linh hoạt, quy trình quản lý thay đổi cho phép thay đổi nhỏ được thực hiện mà không có sự yêu cầu của văn bản đề nghị thay đổi yêu cầu.

Khi một yêu cầu thay đổi được chấp thuận, nhóm dự án cần được thông báo và các sản phẩm cần được cập nhật. Xem xét các bản cập nhật tiềm năng sau, tùy thuộc vào mức độ ảnh hưởng và trạng thái dự án của bạn.

• Requirements Documentation
• Technical Design Documentation
• Software or Programming Code
• Project Plans and Schedules
• Test Plans or Test Cases
• Training Documentation
• Business Process Documentation

Estimate cho Change Request

• Như đã nói ở mục đầu, tất cả các thay đổi đều gây biến động về efforts, và thường là sẽ đội effort hơn so với phần est ban đầu.
• Vì vậy cần thiết phải ước lược effort trước khi đàm phán và quyết định công thức: Total effort = effort implement CR + effort cho phần bị ảnh hưởng.
• Phần ảnh hưởng thật sự rất quan trọng đôi khi chính chúng ta hoặc khách hàng bị quên.

Kết luận

Quản lý CR là một nghệ thuật. Bạn không thể từ chối một cách cứng nhắc, điều đó sẽ khiến khách hàng không hài lòng. Bạn cũng không thể "dễ dãi" chấp nhận các CR vượt quá khả năng của nhóm dự án, hoặc ảnh hưởng đến kế hoạch tài chính của công ty bạn.Nếu bạn có khả năng "lèo lái" dự án, bạn sẽ xem quản trị CR là một phần công việc hàng ngày. Không có gì gọi là "đáng sợ" với CR cả. Hãy cứ ghi nhận CR, nhưng để biến CR thành một tính năng cần trải qua một quá trình không đơn giản chút nào.

Xem thêm: Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu