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.
há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.
Nguồn: TIGO
