Các yêu cầu thay đổi (Change Requests) - nỗi ám ảnh của team dự án phần mềm
Last updated: February 12, 2026 Xem trên toàn màn hình
Recommended for you
- 06 Feb 2024
Bài toán Trolley Problem: Hi sinh thiểu số để cứu đa số? 158/381 - 11 May 2021 Khác nhau giữa Padding và Buffer trong quản lý rủi ro dự án 98/1024
- 01 Aug 2022 20 bài học kinh nghiệm rút ra từ Tam Quốc Diễn Nghĩa 68/1005
- 04 Mar 2020 Kinh nghiệm lập dự toán chi phí dự án phần mềm theo phương pháp Man-Month 63/2699
- 17 Aug 2020 Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 57/348
- 18 Jul 2020 Lợi ích cận biên (Marginal Utility) là gì? Qui luật lợi ích cận biên giảm dần 49/862
- 14 Aug 2022 Khác biệt giữa tiêu chí hoàn thành DOD (Definition of Done) với tiêu chí nghiệm thu (Acceptance Criteria) 49/622
- 01 Mar 2021 Ý nghĩa và bài học rút ra từ truyện thầy bói xem voi 49/721
- 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)? 47/528
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 46/352
- 09 Aug 2022 Hiệu ứng “rắn hổ mang” (Cobra effect): Khi giải pháp trở thành vấn đề, tưởng vui lại hóa xui 45/633
- 15 Apr 2020 Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 44/679
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 43/485
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 40/459
- 11 Sep 2025 Lightning Decision Jam: Quy trình Siêu tốc để Giải quyết Mọi Vấn đề 39/91
- 01 Jul 2023 Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 37/1107
- 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? 36/432
- 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? 35/63
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 34/264
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp ERP 32/268
- 22 May 2022 Tư duy ngoài hộp (Thinking out of box) là gì? Tại sao quan trọng với sự phát triển của doanh nghiệp? 32/534
- 01 Aug 2022 "Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 32/929
- 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? 32/108
- 01 Sep 2020 Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 31/320
- 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 30/766
- 01 Jan 2024 Tổng hợp 25 quy luật quan trọng trong quản lý dự án 30/582
- 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)? 30/416
- 15 Apr 2023 Nghịch lý từ câu chuyện “một chén gạo dưỡng ơn, một đấu gạo gây thù” 29/824
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 29/613
- 03 May 2022 Mô hình Hybrid Agile là gì? 28/551
- 19 Sep 2025 Agile vs. Ego: Làm Gì Khi Một Thành Viên Trong Nhóm Nổi Loạn 28/107
- 19 Aug 2020 Lift & Shift - Phương pháp tối ưu dịch chuyển hệ thống phần mềm qua đám mây 27/236
- 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 26/588
- 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 26/520
- 01 Apr 2023 Bí quyết đàm phán tạo ra giá trị từ câu chuyện Chia Cam 26/618
- 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 26/53
- 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 25/777
- 03 Feb 2020 Sản phẩm OEM và ODM là gì? 25/562
- 25 Apr 2018 Bảo hộ bản quyền phần mềm dưới khía cạnh sở hữu trí tuệ như thế nào? 24/228
- 09 Feb 2021 Tầm nhìn là gì? Tí dụ minh họa cụ thể về tầm nhìn 22/185
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 22/334
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 22/389
- 12 Apr 2023 Phương pháp 6 chiếc mũ tư duy là gì? Vận dụng trong điều hành cuộc họp hiệu quả 22/615
- 05 Dec 2022 Hỏi 5 lần (5 WHYs) – Kỹ thuật "đào" tận gốc cốt lõi vấn đề 22/233
- 10 Sep 2023 Định luật Murphy giải thích tại sao chúng ta luôn gặp xui xẻo vào những lúc tưởng thuận lợi 22/872
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 22/75
- 09 Dec 2025 Hiệu Ứng Tàu Điện Ngầm - The Subway Effect 21/37
- 02 Oct 2023 Ngôi Chùa Trăm Năm và Viên Gạch Vỡ: Bài Học Thấm Thía Về Lỗi Nhỏ Trong Bức Tranh Lớn 21/347
- 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) 21/262
- 11 Sep 2022 Từ truyện “Thầy bói xem voi” tới quản trị bằng Tư Duy Hệ Thống 20/304
- 01 Apr 2022 Chi phí nhà thầu phụ chiếm bao nhiêu phần trăm gói thầu? 20/188
- 18 Mar 2018 Dịch vụ Hosting cho Website là gì? Các lời khuyên chọn Hosting tốt nhất 20/295
- 10 Aug 2020 Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward 20/175
- 15 Aug 2025 Dự án phần mềm bị trì hoãn và vấn đề "akrasia" 19/64
- 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 19/167
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 19/204
- 28 Feb 2025 “Học giỏi” hay “giỏi học”? 19/170
- 15 Mar 2024 Tê liệt vì suy nghĩ quá nhiều (Analysis Paralysis) là gì? 18/296
- 07 Aug 2019 Câu chuyện thanh gỗ ngắn và bài học kinh doanh cho Doanh nghiệp 18/485
- 20 Dec 2022 Bài học quản lý nhân sự từ một trận chung kết bóng đá 18/333
- 11 Mar 2025 Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 18/101
- 07 Feb 2024 Vì sao Scrum Team thường bị Spillover / Carry Over? 18/23
- 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? 17/26
- 12 Jul 2023 Vì sao ngày càng nhiều dự án phần mềm thất bại? 17/589
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 17/329
- 03 Oct 2021 Khác biệt giữa thiết kế phần mềm và thiết kế công trình xây dựng 16/547
- 03 Sep 2020 Hiệu ứng rắn hổ mang, Luật Goodhart, Campbell & Chuyện thi cử 16/228
- 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 16/50
- 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? 15/50
- 10 Sep 2024 Tại sao những thứ chúng ta muốn lại ít khi có được? 15/245
- 23 Jun 2024 Người trí tuệ không tranh cãi ĐÚNG/SAI 15/465
- 04 Jan 2023 Đánh giá nhân sự theo chuẩn người Nhật 15/456
- 09 Jan 2025 10 Nghịch Lý Cuộc Sống Từ Phim Upstream (nghịch hành nhân sinh): Đối Mặt Rủi Ro Trong Thời Đại VUCA 14/221
- 01 May 2023 [Tư vấn CNTT] Quản lý ngân sách CNTT cho doanh nghiệp 14/231
- 01 Sep 2023 Định luật Goodhart và định luật Campbell - Nghịch lý về thành tích 13/217
- 01 Feb 2022 Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 13/793
- 08 Sep 2025 Tâm Lý Phản Kháng (Reactance): Vì Sao Càng Cấm, Người Ta Càng Muốn Làm? 13/98
- 19 Jul 2023 3 cấp độ của thất bại và bí quyết "cái khó ló cái khôn" 13/105
- 08 Mar 2020 Vì sao doanh nghiệp cần phải tạo Web bán hàng? 12/182
- 16 Feb 2024 Nghịch lý của sự hoàn hảo: AI có thể quá tốt để sử dụng? 12/199
- 01 Aug 2022 Bí quyết số 1 cho doanh nghiệp 4.0 với 10 chiến lược phát triển năng lực nhân sự CNTT 12/171
- 11 Sep 2024 Mindset, skillset, toolset là gì? 12/471
- 01 May 2025 Vì Sao Các Cửa Hàng Trung Quốc Không Vội Vã Phục Vụ Khách Hàng? 11/98
- 12 Jul 2021 Để chuyển đổi số, cần “bẻ gãy” (disrupt) trong tư duy 11/208
- 12 Jan 2024 Tư duy hệ thống trong Quản Lý Dự Án diễn ra như thế nào? 11/256
- 11 Sep 2020 Nghịch lý kinh doanh tại Mỹ: Chăm sóc khách hàng không tốt, nhưng công ty lại lãi lớn 11/177
- 16 Aug 2025 Hoài nghi khoa học với 20 thuật ngữ bi quan về hiệu quả của Scrum 11/59
- 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 11/29
- 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 11/18
- 12 Feb 2025 Phương pháp 1-2-4-All là gì? 11/15
- 14 May 2024 Chiến lược răng lược là gì? Làm thế nào để tận dụng chiến lược răng lược trong kinh doanh? 10/246
- 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 9/17
- 10 Sep 2025 Học Tài Thi Phận Là Gì? Cần Làm Gì Để Vượt Qua May Rủi? 9/38
- 30 Jan 2026 Vượt qua cơn bão sa thải nhân viên công nghệ: Những đêm thức trắng, phần mềm bị lỗi và hội chứng kẻ giả mạo (Impostor Syndrome) 8/12
- 09 Dec 2024 10 nghịch lý quản trị khiến tổ chức mãi loay hoay 8/146
- 17 Feb 2018 Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng 8/186
- 08 Mar 2022 Mô hình nguồn mở hoạt động ra sao? 7/233
- 04 Feb 2024 “Nợ kỹ thuật” (technical debt) là gì? 7/26
- 17 Oct 2025 Hồ sơ quyết toán và hồ sơ kiểm toán là gì? 6/14
- 12 May 2024 Groan Zone là gì? Khi mọi quan điểm va chạm, đâu là cách biến Groan Zone thành động lực đổi mới? 4/43
- 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"? 4/9
- 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) 3/11
- 17 Feb 2026 Giá trị con người nằm ở đâu trong thời đại AI và Robot? /1
Chào các bạn, sau nhiều năm làm BA, mình thường xuyên nhận được những yêu cầu tư vấn, giúp đỡ khi dự án có thay đổi yêu cầu hoặc đơn giản là những lời than từ BA, từ Dev khi dự án có yêu cầu phát sinh. Vì vậy hôm nay mình dành chút thời gian để chia sẻ bài này với kinh nghiệm và góc nhìn cá nhân của mình, đặc biệt dành cho các bạn:
- Các bạn BA đang gặp khó khăn với CR (Change Request).
- Các anh/chị/em có nhiều kinh nghiệm với vấn đề này chia sẻ thêm để cộng đồng cũng học tập.
Hãy cùng bắt đầu với câu chuyện trong nghề:
Nỗi sợ mang tên CR – Vì đâu nên nỗi?
Khi có yêu cầu phát sinh, các bên sẽ phản ứng như nào nhỉ? Và dưới đây là ví dụ của 1001 kiểu phản ứng:
Khách hàng:
- Anh nghĩ tính năng này dễ mà, chỉ thêm xíu xíu thời gian thôi.
- Chị có thay đổi gì nhiều đâu, toàn là chỉnh sửa nho nhỏ mà em.
- Tính năng này chỉ thêm có 20 trường thôi mà.
- Cái này không phải thay đổi yêu cầu em ơi, chị đã trao đổi với sales bên em rồi?
- Cái này có gì mà khó, Facebook, Google người ta làm nhiều mà em.
- Danh sách thay đổi chỉ có một trang thôi mà, sao bên kỹ thuật lại thấy khó nhỉ?
- Bên chị mới có một số thay đổi, em lên kế hoạch triển khai sớm nhé (không có chi phí bổ sung đâu, chốt là làm luôn nhé).
- Lãnh đạo muốn cho hộp tìm kiếm to hơn và kéo dài đến 2 mép màn hình, em sửa để lãnh đạo hài lòng nhé.
- Và những điều tương tự và thú vị khác...
Team dự án:
- Cái này thay đổi yêu cầu, không làm được ạ.
- Em sẽ "ghi nhận" về báo cáo lãnh đạo ạ. Em sẽ trả lời bằng văn bản sau ạ.
- Cái này là thay đổi yêu cầu, bên em sẽ làm nhưng phải thêm chi phí và thời gian ạ.
- Lại thay đổi à chị? Mai launching rồi chị.
- Không làm được đâu chị ạ, ngoài phạm vi dự án ạ.
- Không có trong hợp đồng chị ạ.
- Tổng số thay đổi đã vượt 10% tổng chi phí dự án rồi chị ạ.
- Chuyển sang version 2 được không chị?
- Vân vân và mây mây
Có những thay đổi nhỏ, như làm mịn hoặc hoàn thiện một số luồng nhỏ còn thiếu, chúng ta dễ dàng chấp nhận vì chỉ tốn vài giờ coding, vài giờ test và vài giờ đi lại nghiệm thu onsite.
Chúng ta không nên từ chối các thay đổi nhỏ như "thêm một data field" vì khách hàng sẽ đánh giá nhà thầu không có tinh thần "go the extra miles" (tạm dịch: "cố thêm một tí"). Khác nhau là "nội hàm" của thay đổi. Có những thay đổi tưởng nhẹ nhàng như "thêm 1 data field", nhưng nếu thay đổi đó diễn ra trên chính Core Flow thì nó là 1 rủi ro vô cùng tệ hại.
Phản ứng trái chiều của các bên liên quan thường gây ra xung đột giữa team và khách hàng, hoặc giữa nội bộ team với nhau, có khả năng gây hậu quả xấu tới dự án, tới mối quan hệ hợp tác kinh doanh. Nói chung là hậu họa khôn lường.
Có những thay đổi nhỏ sẽ đem lại giá trị cho sản phẩm. Nhưng cũng có những thay đổi nhỏ dẫn tới những sự thay đổi lớn hơn, và chúng ta cần cảnh giác điều này.
Khách hàng luôn cho rằng team kỹ thuật luôn từ chối làm thêm CR vì có tư tưởng "né việc", còn phía team thì luôn nghĩ rằng "Họ (khách hàng) đẽo cày giữa đường" quá nhiều. Xung đột cứ thế leo thang cho đến khi có một bên thứ 3 nhảy vào làm trọng tài phân xử.
Khách hàng quyết định thuê tư vấn để giám sát team kỹ thuật. Nhưng than ôi, người được thuê bao giờ cũng nói tốt cho người thuê mình. Đó là lý do 90% quyết định thuê tư vấn ở Việt Nam không đạt hiệu quả cao. Chất lượng tư vấn chỉ có thể đạt được khi đội ngũ tư vấn là người có tâm, có năng lực và hành động khách quan.
Có lẽ nhiều PM/BA có chứng chỉ PMI cũng phải than trời: Em làm gì sai mà em bị "lái" điên cuồng thế? Em quản lý dự án đúng chuẩn Mỹ, Nhật mà vẫn không đỡ nổi CR ...
Trước khi tìm hiểu vì sao chúng ta không thích CR thì mình cùng định nghĩa "em nó" một chút nhé:
Change Request (CR): Thay đổi yêu cầu được định nghĩa là những yêu cầu thay đổi so với scope ban đầu đã được thống nhất và ký kết với khách hàng. Thay đổi yêu cầu có thể bao gồm thêm tính năng mới, bổ sung hoặc thay đổi tính năng đã được thỏa thuận trước đó. Việc thay đổi yêu cầu này thường kéo theo sự biến động về thời gian, nguồn lực và chi phí của dự án. Có những thay đổi rất tinh tế, tiềm tàng diễn ra từ lúc bắt đầu dự án cho đến khi nghiệm thu. Toàn bộ stakeholders và team dự án giật mình nhận ra toàn bộ Spec, FS, prototypes khác quá xa so với phiên bản cuối cùng. Đó chính là vấn đề Scope Creep và quả cầu tuyết.
Đến đây thì có thể nhìn thấy lý do vì sao mọi người đều không thích CR rồi.
- Thay đổi yêu cầu => Ảnh hưởng tiến độ dự án => Chủ đầu tư phạt hợp đồng
- Thay đổi yêu cầu => Ảnh hưởng nguồn lực => Ảnh hưởng tới nguồn thu
- Thay đổi yêu cầu => Ảnh hưởng tới kế hoạch kinh doanh => Ảnh hưởng tới nguồn thu
- Thay đổi yêu cầu => Thêm chi phí => Vẫn là nguồn thu
- Thay đổi yêu cầu => Ảnh hưởng tới thành tích chung, KPI => Ảnh hưởng tới lương thưởng cuối năm
Đồng tiền đi liền khúc ruột, với tư cách của khách hàng, chắc hẳn không ai muốn trả thêm tiền cho 1 sản phẩm chưa nhìn thấy được trong khi họ đã trả rất nhiều tiền khi kí kết hợp đồng ban đầu rồi. Xót mà phải không các bạn?
Về phía công ty, chúng ta đương nhiên cần thêm chi phí để thực hiện các yêu cầu bổ sung, không có cứ miễn phí thì lấy đâu tiền mà trả lương mà được tăng lương nhờ?
Mâu thuẫn này có vẻ không nhỏ, luôn tồn tại và chẳng hề dễ giải quyết phải không các bạn? Cứ đụng tới Tiền là không vui rồi, nhưng biết sao được, khách hàng vẫn cần handle và dự án vẫn cần kết thúc tốt đẹp phải không nào?
Ngoài mâu thuẫn cốt lõi trên thì yếu tố tâm lý gây ảnh hưởng lớn tới cách mà team dự án phản ứng khi có thay đổi yêu cầu. Cả team đã cố gắng làm ra sản phẩm, rồi cuối cùng khách hàng đòi đổi này đổi kia, đã chốt rồi sau vài tháng lại bỏ, thậm chí đập đi làm lại, hoặc có những yêu cầu quá đáng. Nguy hiểm hơn là có những yêu cầu thay đổi đến từ một người không có tiếng nói (không phải stakeholder), hoặc thay đổi đến từ một trong các lãnh đạo nhưng không có người "chốt", không có người chịu trách nhiệm "nghiệm thu" thay đổi đó.
Hầu hết mọi người sẽ thấy công sức của mình bị lãng phí, không được tôn trọng, đặc biệt là từ phía DEV team. Đối với các PM/BA ít kinh nghiệm thì CR sẽ là một cái bẫy dễ dàng. Hậu quả là dự án mãi không xong, nghiệm thu UAT kéo dài mà vẫn chưa cảm thấy sản phẩm được hoàn thiện...
Đến đây thì có thể thấy rằng, phản ứng của các bên là phản ứng hết sức tự nhiên và có thể thông cảm được. Nhưng thông cảm được không có nghĩa là ta cứ để nó thuận theo tự nhiên như vậy được. Làm dự án không phải là làm công việc hành chính hàng ngày. Phải có điểm kết thúc!
Cuộc sống mà, cuộc đời đâu phải màu hồng, dự án của chúng ta cũng thế. Nếu tiếp tục để nó thuận theo tự nhiên như vậy thì sẽ ảnh hưởng tới tinh thần làm việc và chất lượng công việc của team dự án rất nhiề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