Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request?
Last updated: July 09, 2023 Xem trên toàn màn hình
Recommended for you
- 11 May 2021
Khác nhau giữa Padding và Buffer trong quản lý rủi ro dự án 82/910 - 01 Aug 2023 Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 16/411
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 15/379
- 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 12/694
- 18 May 2021 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 9/654
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 9/414
- 02 Aug 2023 Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 8/429
- 28 Jun 2024 Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 8/322
- 28 Aug 2025 Tổng quan tất cả các RỦI RO trong cuộc sống 8/30
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 7/219
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 7/332
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 7/506
- 03 May 2022 Mô hình Hybrid Agile là gì? 6/470
- 18 Mar 2021 Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 4/484
- 10 Jul 2021 Padding là gì? Tại sao padding cần thiết cho Project Estimation? 4/278
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 3/166
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 2/194
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 2/279
- 01 May 2022 Nghệ thuật quản lý rủi ro của người Nhật - kinh nghiệm cho BrSE 2/199
- 22 Jul 2020 Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 1/95
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 1/256
- 08 Sep 2024 Da Thịt Trong Cuộc Chơi - Skin In The Game /310
- 01 Dec 2022 Quản trị rủi ro trong dự án phần mềm /274
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
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
Link copied!
Mới cập nhật