Bạn đã define requirement một cách ngon lành, dự án đang chạy, team đang deliver đúng tiến độ. Bỗng nhiên, business requirement có sự thay đổi.

Trong một thị trường chuyển động nhanh và cạnh tranh khốc liệt như hiện nay, việc kỳ vọng những yêu cầu business luôn cố định một chỗ và stakeholder luôn biết rõ họ cần phải làm gì là phi thực tế.

Sự thay đổi luôn đến và mang theo rất nhiều rắc rối. Nếu chúng ta không quản lý tốt các thay đổi trong requirement, những sự thay đổi đó sẽ xoay cả team vòng vòng không hồi kết. Là một BA, sứ mệnh của bạn là không để cho sự thay đổi gây ra hỗn loạn, cứu team khỏi tình trạng phải “đập đi xây lại” mọi thứ, và ảnh hưởng đến năng lượng làm việc của mọi người.

Hôm nay chúng ta sẽ nói về 4 bước quản lý thay đổi trong requirement:

Bước 1: Xác định phạm vi thay đổi

Đừng vội xác nhận hay hứa hẹn gì khi vừa nhận change request. Bạn cần thực hiện phân tích phạm vi ảnh hưởng của yêu cầu này. Đây là ảnh hưởng ở cấp độ nào:

• Business requirement
• User requirement
• Functional requirement
• Data requirement

Tham khảo technical lead về đánh giá của bạn, họ có thể cho 1 vài ý kiến về những “side effect” có thể xảy ra khi triển khai change request này.

Bên cạnh việc khoanh vùng ảnh hưởng, cần nắm rõ lý do thực sự cần thực hiện thay đổi này. Triển khai nó thì được gì, mà không làm thì mất gì. Liệu rằng có xứng đáng để đánh đổi thời gian và nguồn lực cho việc thay đổi này không.

Hãy đối xử với change request như 1 requirement mới, việc đó giúp bạn đánh giá khách quan và hiệu quả hơn. Đừng bị “bias” bởi tư duy không muốn thay đổi, muốn giữ cái cũ.

Bước 2: Xác định các bước thực hiện

Bạn đã xác định được cái gì cần thay đổi và tại sao. Giờ thì hãy nhìn vào thực tế dự án, tiến độ, những output đang có, bối cảnh về con người và nguồn lực… Bắt đầu breakdown các bước cụ thể cần thực hiện (1 cách tổng quát) để đạt được sự thay đổi. Technical design sẽ cần làm gì, project roadmap sẽ thay đổi như thế nào, sprint schedule, plan,… Từ đó nhìn thấy được khái quát khối lượng công việc tăng thêm để triển khai thay đổi.

Tham khảo ý kiến của dev team, PM và stakeholder để có thêm thông tin và bắt đầu đề xuất. Đưa ra 1 vài option để có sự cân nhắc đa dạng hơn. Bạn có thể đề xuất loại bỏ bớt những công việc có độ ưu tiên thấp hơn, hoặc thay đổi thứ tự thực hiện chúng trong product backlog.

Bước 3: Thông qua nhu cầu thay đổi

Sau bước 1 và 2, bạn đã có đủ thông tin và cũng đã đưa ra 1 vài đề xuất thực hiện thay đổi. Hãy tổng hợp chúng vào 1 form Change Request (google là có đủ template). Đặt những thông tin cần thiết vào form. Output từ 2 bước trên sẽ giúp bạn điền vào chỗ trống nhanh thôi.

Bây giờ bạn sẽ cần thông qua các bên liên quan để bắt tay vào tiến hành thay đổi. Change request không phải lúc nào cũng cần thông qua 1 cấp nhất định. Hãy xác định mức độ ảnh hưởng của yêu cầu và từ đó xem xét mình sẽ cần sự đồng thuận của ai để triển khai

• Nếu 1 yêu cầu đòi hỏi 1 ngày để thực hiện, bạn có thể đơn giản thông qua bằng cách làm việc với dev team
• Nếu yêu cầu cần 1 tuần hoặc nhiều hơn, có thể bạn cần ý kiến và xác nhận của PM hoặc PO để thực hiện. Với phạm vi này, thay đổi có thể ảnh hưởng đến product roadmap
• Nếu yêu cầu cần 1 tháng hoặc nhiều hơn, bạn sẽ cần chữ ký của cấp lãnh đạo để có thể bắt đầu tiến hành. Điều này có thể ảnh hưởng đến những dự án khác và có thể là chiến lược của công ty.

Một số công ty có quy trình rõ ràng và chuyên nghiệp sẽ có quy định rõ về việc bộ phận nào hoặc ai sẽ có quyền approve những yêu cầu thay đổi nào.

Bước 4: Thông báo và triển khai

Khi đã được thông qua, bắt đầu đến với giai đoạn triển khai.

Hãy đảm bảo và tất cả những bên liên quan đến thay đổi đều được thông báo và nhận thức được về thay đổi này. BA hoặc PM sẽ có trách nhiệm truyền thông về thay đổi.

Thực hiện những thay đổi liên quan đến cập nhật tài liệu, quy trình và sản phẩm đầu ra có liên quan.

Ví dụ: BA sẽ quan tâm đến việc điều chỉnh các tài liệu, requirement liên quan đến thay đổi. Designer sẽ quan tâm đến update version design mới, QA sẽ cập nhật test case và test plan, PM/PO sẽ điều chỉnh project plan và update product backlog…

Lời kết

Không ai muốn gặp quá nhiều thay đổi hay rắc rối trong quá trình làm dự án. Chúng ta muốn một dự án trơn tru từ đầu đến cuối. Nhưng đừng vì vậy mà ngại việc thay đổi, đôi khi có những cơ hội cần nắm bắt, miễn sao tạo được nhiều giá trị nhất cho khách hàng và dự án là được. Hãy chắc chắn rằng, thay đổi xứng đáng để đánh đổi thời gian và công sức của cả team.

Bài viết giải thích 4 bước quản lý thay đổi yêu cầu trong dự án: Xác định phạm vi thay đổi, xác định các bước thực hiện, thông qua nhu cầu thay đổi, và triển khai.

“4 Bước Quản Lý Thay Đổi Yêu Cầu Trong Dự Án Agile”