Change Requests là gì? Những điều các Software Business Analysts cần biết

Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request?

Published on: January 08, 2022
Last updated: July 28, 2026 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 239/1244
11 May 2021 Khác nhau giữa Padding và Buffer trong quản lý rủi ro dự án 239/1244
10 Jul 2021 Padding là gì? Tại sao padding cần thiết cho Project Estimation? 229/663
01 Aug 2021 Hiện tượng Gold plating (mạ vàng) là gì? Tại sao có ảnh hưởng quyết định đến chất lượng dự án? 226/682
10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 203/448
08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp ERP 191/451
04 Feb 2024 Quiet firing là gì? Làm thế nào để nhận diện? 188/205
03 May 2022 Mô hình Hybrid Agile là gì? 185/757
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)? 182/792
02 Dec 2025 Chủ Nghĩa Gia Đình Trị (Nepotism) Làm Suy Giảm Sự Hài Lòng Và Niềm Tin Trong Công Việc Như Thế Nào? 182/220
14 Aug 2023 Công bằng phân phối (distributive justice) giúp "virtual team" làm việc hiệu quả hơn như thế nào? 182/239
11 Mar 2024 Materialized Views là gì? Bí quyết tăng tốc truy vấn dữ liệu cho hệ thống lớn 181/226
04 Feb 2026 Cô lập nơi công sở (Workplace Ostracism): Một hành vi thường bị hiểu lầm 178/226
20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 177/634
03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 175/821
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 175/827
17 Oct 2025 Hồ sơ quyết toán và hồ sơ kiểm toán là gì? 175/213
15 Mar 2024 SDLC là gì? So sánh với Full-Cycle Software Development 167/217
15 May 2023 ICT Project Manager là gì? Phân biệt ICT Project Manager với Software Project Manager 165/202
11 Feb 2024 "PMO Coach" là nghề gì? Tại sao doanh nghiệp bạn cần một PMO Coach? 162/203
07 Feb 2024 Vì sao Scrum Team thường bị Spillover / Carry Over? 162/188
12 Feb 2024 CPI và SPI trong PMP: Case Study thực tế cho quản lý dự án phần mềm 161/189
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 159/343
14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 153/621
14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 152/361
04 Feb 2024 “Nợ kỹ thuật” (technical debt) là gì? 152/215
21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 151/517
07 Feb 2024 Thất bại của nhóm Scrum - Phân loại các mô hình phản tác dụng trong Scrum (Scrum Anti-Patterns) 150/193
13 Aug 2024 Cognitive friction (ma sát nhận thức) là gì? 149/225
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 149/675
30 Aug 2024 Friction points (điểm ma sát) là gì? 149/312
13 Aug 2025 Kinh nghiệm phát triển dự án phần mềm cho khối Chính phủ/nhà nước 148/198
24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 142/487
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)? 141/579
11 Dec 2025 Vì Sao Hệ Thống Báo Cáo Trong Phần Mềm Kế Toán Luôn Được Đánh Giá Là Khó Nhất? 138/155
11 Dec 2025 Phần mềm cho SMEs: Vì sao “Best-Fit” lên ngôi và “Best-of-Breed” dần lỗi thời 137/196
30 Aug 2023 Critical Path là gì? Tại sao nói Critical Path là con đường "long mạch" của dự án? 135/291
04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 134/953
13 Feb 2024 "Weighted milestone" là gì? 128/137
16 Aug 2025 Hoài nghi khoa học với 20 thuật ngữ bi quan về hiệu quả của Scrum 125/184
01 Jan 2024 Tổng hợp 25 quy luật quan trọng trong quản lý dự án 124/714
02 Sep 2025 Bốn Nhóm Người Dễ Bị “Brain Rot” Trên Mạng Xã Hội Và Cách Phòng Tránh 124/177
02 May 2025 Vì sao học giỏi mà vẫn nghèo, học dốt lại thành đạt trong cuộc sống? 120/203
02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 119/510
05 Mar 2023 14 Loại Quyền Lực Trong Quản Lý Dự Án 119/189
01 May 2022 Nghệ thuật quản lý rủi ro của người Nhật - kinh nghiệm cho BrSE 117/363
08 Aug 2023 Mất kiểm soát phạm vi dự án (Scope Creep) và hiệu ứng quả cầu tuyết (snowball) 116/369
02 Feb 2026 Làm thế nào để tránh văn hóa nhóm độc hại trong phát triển phần mềm? 115/148
08 Sep 2024 Da Thịt Trong Cuộc Chơi - Skin In The Game 114/476
12 Jan 2024 Tư duy hệ thống trong Quản Lý Dự Án diễn ra như thế nào? 106/382
11 May 2025 Từ điển kỹ thuật trong quản lý tài nguyên truy cập hệ thống (System Access Resource Management) 104/243
24 Feb 2026 [Sổ tay PM] Cách Tiếp Quản Một Dự Án Đang Triển Khai 104/122
19 Feb 2025 “Tribal knowledge” là gì? 100/120
19 Sep 2025 Luật chống ôm đồm (WIP limits): Làm ít hơn và chất hơn 100/157
01 Dec 2022 Quản trị rủi ro trong dự án phần mềm 95/416
18 Sep 2025 Bị sa thải sau 25 năm làm việc trong lĩnh vực công nghệ: Nỗi lo lắng, sự hy sinh và thực tế mà không ai dám nhắc đến 94/149
03 Mar 2026 10 kiểu lãnh đạo khiến nhân sự liên tục đội nón ra đi 93/111
13 Sep 2025 Vanity Metrics: Follower tăng vọt nhưng doanh thu đứng yên 90/192
09 Feb 2025 Làm gì nếu người quản lý luôn thúc ép: "Đừng làm forwarder, hãy là solver"? 86/100
23 Sep 2024 Lỗi FUBAR trong phần mềm là gì? 85/244
28 Aug 2025 Tổng quan tất cả các RỦI RO trong cuộc sống 83/126
25 Jun 2025 "Company’s DNA" là gì" 77/83
02 Aug 2022 BVP (Billable Viable Product) là gì? 70/163
19 Jul 2023 3 cấp độ của thất bại và bí quyết "cái khó ló cái khôn" 70/182
09 Dec 2024 10 nghịch lý quản trị khiến tổ chức mãi loay hoay 69/219
24 Jun 2020 PMP - Quản lý dự án quốc tế chuyên nghiệp 68/299
18 Nov 2025 Điều khoản Clawback là gì? 63/66
28 Feb 2025 “Học giỏi” hay “giỏi học”? 57/289
11 Sep 2025 📚 Từ điển thuật ngữ về DevOps 56/117
18 Jun 2026 Tại sao Quản lý Dự án cần học cả Generative AI và Agentic AI 50/53
01 Jul 2026 Sandbox: Tư duy "Vùng thử" - Chìa khóa tự học trong kỷ nguyên AI 44/53
20 Feb 2026 Office GAME: "Luật chơi ngầm" tại nơi làm việc diễn ra như thế nào? 28/101
18 Jul 2026 Tư duy nhiệm kỳ là gì? 17/21
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 5/933
10 Jul 2026 Ngụy biện dựa vào uy tín (Appeal to Authority) là gì? 2/25
13 Mar 2024 Vì sao Man-Month vẫn còn được sử dụng trong ngành công nghệ phần mềm? /200

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

A A A A

[{"displaySettingInfo":"[{\"isFullLayout\":false,\"layoutWidthRatio\":\"\",\"showBlogMetadata\":true,\"showAds\":true,\"showQuickNoticeBar\":true,\"includeSuggestedAndRelatedBlogs\":true,\"enableLazyLoad\":true,\"quoteStyle\":\"1\",\"bigHeadingFontStyle\":\"1\",\"postPictureFrameStyle\":\"1\",\"isFaqLayout\":false,\"isIncludedCaption\":false,\"faqLayoutTheme\":\"1\",\"isSliderLayout\":false}]"},{"articleSourceInfo":"[{\"sourceName\":\"\",\"sourceValue\":\"\"}]"},{"privacyInfo":"[{\"isOutsideVietnam\":false}]"},{"tocInfo":"[{\"isEnabledTOC\":true,\"isAutoNumbering\":false,\"isShowKeyHeadingWithIcon\":false}]"},{"termSettingInfo":"[{\"showTermsOnPage\":true,\"displaySequentialTermNumber\":true}]"}]

Nguồn

{content}