Chắc hẳn không ít lần Project Manager phải đau đầu, méo mặt vì khách hàng thay đổi yêu cầu liên tục, hệ quả là dự án thường xuyên bị kéo dài, trễ deadline. Trên thực tế không có cách nào để ngăn chặn sự thay đổi này, điều chúng ta cần làm là chủ động ứng phó với thay đổi. Sau đây là một số gợi ý dành cho bạn từ chuyên gia thực chiến.
Chắc hẳn Project Manager (PM) nào cũng đã từng gặp phải trường hợp khách hàng nay muốn thế này, mai muốn thế kia. Không ít trường hợp nhận feedback và sửa một hồi sau đó họ lại lựa chọn “lấy lại bản đầu tiên”. Câu hỏi được đặt ra ở đây là: Tại sao khách hàng hay thay đổi?
Phần mềm là một loại sản phẩm đặc biệt, rất trừu tượng. Ban đầu nó chỉ được mô tả bằng ngôn ngữ tự nhiên, khi khách hàng nói tôi muốn có chức năng A, chức năng B,… Nhưng chính bản thân họ cũng chưa hình dung ra được chức năng A, chức năng B sẽ hoạt động thế nào, giao diện ra sao. Khách hàng không biết thực sự họ muốn gì, cho đến khi nhận được một phần sản phẩm và phát hiện ra rằng đó chưa phải điều họ thật sự muốn và họ lại thay đổi yêu cầu.
Dĩ nhiên, việc chạy theo khách hàng không phải là một điều dễ dàng và dễ chịu. Như chia sẻ của một số Project Manager,
Việc khách hàng thay đổi yêu cầu hoặc có thêm yêu cầu chỉnh sửa đối với những tính năng đã làm trước đó dẫn đến thay đổi thiết kế ban đầu, nếu là những tính năng core thì mức độ ảnh hưởng rất lớn và kéo dài thời gian dự án so với kế hoạch.
Hợp đồng với khách bị ảnh hưởng, phải đàm phán lại hoặc deal thêm effort, giá và deadline cho các task thay đổi đó. Với một số khách hàng khó tính, thì họ sẽ đưa yêu cầu liên tục ngay sát deadline, ảnh hưởng đến việc release sản phẩm. Ảnh hưởng tới tâm lý nhân sự, gây khó khăn trong việc giao tiếp, bàn bạc giữa khách và team phát triển, giữa các thành viên trong team phát triển.
Vậy có cách nào để ngăn chặn sự thay đổi này không? Thật không may, câu trả lời là KHÔNG. Chúng ta không thể bảo khách hàng dừng thay đổi được, vì vậy việc chúng ta cần làm là chủ động ứng phó khi khách hàng thay đổi yêu cầu.
Trên thực tế, việc lên kế hoạch kỹ càng, chi tiết, rồi thi hành và kiểm soát thật chặt để đạt được kết quả tốt đã không còn phù hợp đối với các dự án hiện nay do sự biến động của thị trường, môi trường kinh doanh và nhu cầu khách hàng thay đổi liên tục. Trong khi, kết quả thì không phải lúc nào cũng dễ dàng hình dung rõ ràng ngay từ lúc lập kế hoạch.
Do đó, Project Manager cần một kế hoạch có khả năng phản ứng nhanh với các thay đổi. Phương pháp quản lý dự án theo Agile với ưu tiên “Phản hồi với thay đổi hơn là bám sát kế hoạch” và “Cộng tác với khách hàng hơn là đàm phán hợp đồng”, giúp đáp ứng nhu cầu khách hàng và yêu cầu về giải pháp thay đổi thường xuyên.
Quản lý dự án theo Agile sẽ không lập kế hoạch dài hạn, thay vào đó sẽ phân chia thành những quá trình lập kế hoạch nhỏ, đơn giản và gọn nhẹ. Cuối mỗi phân đoạn (Sprint), nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng. Khác với phương pháp Waterfall truyền thống – vốn chỉ cho phép nhìn thấy sản phẩm tới khi gần hoàn thành dự án, sản phẩm trong dự án Agile sẽ được phát triển lớn dần theo thời gian, tăng trưởng cho tới khi đạt được trạng thái đủ để phát hành.
Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, việc lập kế hoạch hay có những điều chỉnh, thay đổi trong quá trình phát triển đều có thể đáp ứng nhanh để phù hợp. Ngoài ra, việc khách hàng được tham gia vào các quy trình phát triển cũng giúp nhóm dự án có thể đáp ứng và thay đổi ngay những yêu cầu phát sinh từ phía khách hàng.
Để minh họa chi tiết cho phương pháp quản lý dự án theo Agile trong trường hợp thay đổi yêu cầu liên tục, hãy cùng tham khảo case study của một nhóm dự án khi build phần mềm đặt xe.
Bối cảnh: Product Owner của nhóm đồng thời cũng là Marketing Manager của công ty, là một người có rất nhiều ý tưởng và liên tục muốn team thay đổi theo các ý tưởng đó. Bản thân CEO của công ty cũng là một người hay thay đổi ý tưởng. Điều này dẫn đến tình trạng nhóm không biết ưu tiên phục vụ ai, việc này chưa làm xong đã có việc khác xen vào. Phần lớn thời gian của nhóm là để làm rõ yêu cầu của các bên liên quan, nên cái gì cũng dang dở, sau 2-3 tháng triển khai vẫn không chuyển giao được sản phẩm.
Giải pháp: Có thể thấy rằng, vấn đề của nhóm xuất phát từ việc nhóm khách hàng nội bộ (Product Owner, CEO) hay thay đổi yêu cầu liên tục. Để giải quyết tình trạng này, nhóm Tech đã quyết định sử dụng phương pháp quản lý dự án theo Agile. Cụ thể:
Nhóm sử dụng 01 bảng Kanban vật lý để trực quan hóa khối lượng công việc và tiến độ hoàn thành của cả nhóm.
Mọi ý tưởng của Product Owner, CEO và các bên liên quan đều được đưa vào cột “Want to”, để tránh tình trạng cứ có ý tưởng mới là lao vào làm ngay.
Lúc này, công việc của Product Owner là phải sắp xếp, sàng lọc và quyết định độ ưu tiên của các hạng mục để đưa vào danh sách công việc. Sau đó, team sắp xếp độ ưu tiên, đưa vào Sprint Backlog để triển khai theo thứ tự ưu tiên.
Hành động này giúp nhóm có thể loại bỏ đi các ý tưởng không phù hợp, các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm và rút ngắn thời gian để đi đến sản phẩm cuối cùng.
Kết quả: Ngay sau Sprint 1, nhóm Tech đã hoàn thiện được tính năng cơ bản nhất của một phần mềm đặt xe là khách hàng đặt được xe. Đến Sprint 2 thì hoàn thiện tiếp tính năng đặt xe cho nhiều người và menu. Sau Sprint 3, khách hàng có thể chọn địa điểm nhanh. Thế là chỉ sau 3 Sprint, nhóm Tech đã có được bản MVP đầu tiên cho khách hàng bao gồm các tính năng cơ bản.
Trong mỗi dự án, khách hàng thay đổi yêu cầu là điều không thể tránh khỏi. Project Manager cần lôi kéo khách hàng tham gia vào quá trình triển khai dự án càng nhiều càng tốt, điều này không chỉ giúp quá trình phát triển diễn ra suôn sẻ mà còn đảm bảo rằng khách hàng sẽ nhận được giá trị xứng đáng với những gì họ kỳ vọng và thực sự hài lòng. Hãy luôn nhớ rằng thành công của một dự án không được quyết định bởi sự hoàn thành mà bởi sự hài lòng của khách hàng.
Bài viết liên quan:
Khóa học liên quan:
Bạn đã đăng ký thành công
Xin cảm ơn bạn đã đăng ký nhận tư vấn
Xin cảm ơn bạn đã đăng ký
Mời bạn kiểm tra Email để tải tài liệu.