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: October 12, 2023 Xem trên toàn màn hình
Recommended for you
- 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 2507 - 01 Jul 2023 Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 905
- 01 Aug 2022 "Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 764
- 01 Feb 2022 Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 669
- 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 654
- 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 622
- 15 Apr 2020 Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 533
- 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 493
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 478
- 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 459
- 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) 457
- 03 May 2022 Mô hình Hybrid Agile là gì? 443
- 03 Feb 2020 Sản phẩm OEM và ODM là gì? 440
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 395
- 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 382
- 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)? 371
- 04 Jan 2023 Đánh giá nhân sự theo chuẩn người Nhật 366
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 344
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 313
- 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)? 295
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 272
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 239
- 18 Mar 2018 Dịch vụ Hosting cho Website là gì? Các lời khuyên chọn Hosting tốt nhất 232
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 226
- 17 Aug 2020 Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 213
- 01 Sep 2020 Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 213
- 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? 205
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 197
- 08 Mar 2022 Mô hình nguồn mở hoạt động ra sao? 185
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 183
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 159
- 08 Mar 2020 Vì sao doanh nghiệp cần phải tạo Web bán hàng? 158
- 01 May 2023 [Tư vấn CNTT] Quản lý ngân sách CNTT cho doanh nghiệp 156
- 01 Apr 2022 Chi phí nhà thầu phụ chiếm bao nhiêu phần trăm gói thầu? 151
- 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 147
- 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? 140
- 17 Feb 2018 Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng 130
- 09 Feb 2021 Tầm nhìn là gì? Tí dụ minh họa cụ thể về tầm nhìn 121
- 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 93
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
Mới cập nhật