Một MVP đặt lịch đã hoàn thành luồng tạo lịch và đang xây phần thanh toán. Sales đề nghị thêm mã giảm giá vì khách hàng thử nghiệm sắp chạy khuyến mại. Vận hành muốn cho phép đổi lịch nhiều lần, còn dev phát hiện dữ liệu chưa lưu lý do hủy.
Nếu đưa cả ba yêu cầu thẳng vào sprint, đội sẽ không biết phần nào bị lùi, test case nào phải viết lại và ai chốt mốc mới.
Vì sao yêu cầu hợp lý vẫn làm MVP chậm bàn giao?
MVP cần phản hồi để sửa giả định sai. Rủi ro xuất hiện khi yêu cầu từ cuộc họp hoặc tin nhắn được chuyển thẳng cho dev mà chưa đánh giá tác động.
Một thay đổi nhỏ trên giao diện có thể kéo theo quy tắc dữ liệu và kiểm thử mới. Với mã giảm giá, đội phải xác định điều kiện áp dụng, quyền tạo, cách tính hóa đơn và trường hợp hoàn tiền. Nếu chưa chốt, dev vừa làm vừa hỏi lại, còn QA thiếu kết quả mong đợi để kiểm tra.
Bài cách chuyển ghi chú thành spec và test case trình bày cách làm rõ yêu cầu trước khi code. Với thay đổi giữa giai đoạn phát triển, đội cần so sánh yêu cầu mới với phạm vi đã cam kết.
Mỗi yêu cầu mới cần một bản mô tả ngắn
Người đề xuất chỉ cần nêu tình huống, người bị ảnh hưởng, kết quả mong muốn, mức khẩn cấp và nguồn phản hồi. Hãy ghi vấn đề trước giải pháp. Nếu yêu cầu đến từ một khách hàng, cần phân biệt nhu cầu riêng với dấu hiệu lặp lại ở nhóm người dùng mục tiêu.
Quy trình đánh giá và duyệt thay đổi phạm vi
1. Ghi nhận vào một hàng chờ chung
Product ghi nguồn, vấn đề, nhóm người dùng, kết quả mong muốn và thời điểm cần quyết định. Tin nhắn Zalo có thể là đầu vào, nhưng yêu cầu phải vào backlog trước khi giao cho dev.
2. Đánh giá tác động
Product rà luồng và phạm vi. Dev xác định ảnh hưởng đến dữ liệu, API, tích hợp và phần đang làm. QA chỉ ra test case cần sửa. Vận hành xác nhận quy tắc thực tế cùng ngoại lệ.
3. Chọn cách xử lý
Đội chọn một trong bốn hướng: thay thế việc đã có, bổ sung và điều chỉnh mốc, thử thủ công có kiểm soát, hoặc đưa sang phiên bản sau. Quyết định phải có lý do và người phê duyệt.
4. Cập nhật đầu ra liên quan
Product cập nhật spec, backlog, thiết kế và tiêu chí nghiệm thu. Tech lead cập nhật phụ thuộc kỹ thuật. Người phụ trách bàn giao thông báo thay đổi về phạm vi, mốc và rủi ro.
Đội có thể rà thay đổi mỗi tuần, trừ lỗi nghiêm trọng hoặc vấn đề chặn luồng chính. Dev không nhận thêm việc từ nhiều kênh.
Đánh giá cả phần phải làm lại
Ước lượng phải tính cả phần bị ảnh hưởng. Thêm lý do hủy lịch có thể làm đổi dữ liệu, API, hai giao diện và dữ liệu thử. Đội cũng phải chốt cách hiển thị bản ghi cũ.
Đội cần kiểm tra thay đổi có phục vụ mục tiêu của MVP không. Nếu phiên bản đầu chỉ kiểm tra việc đặt lịch và thanh toán, hệ thống khuyến mại đầy đủ có thể để sau. Nếu nhóm thử nghiệm cần ưu đãi mới chịu chạy thử, đội phải cân nhắc một phương án nhỏ hơn.
Khi nào nên đưa thay đổi vào phiên bản hiện tại?
Nên xử lý trong phạm vi hiện tại khi
- Yêu cầu sửa lỗi chặn luồng chính hoặc làm sai dữ liệu quan trọng.
- Thiếu yêu cầu này thì đội không thể kiểm tra giả định cốt lõi.
- Yêu cầu đáp ứng nghĩa vụ bảo mật, quyền truy cập hoặc quy định bắt buộc.
- Đội đã chọn phần việc thay thế hoặc chấp nhận đổi mốc bàn giao.
Nên đưa sang phiên bản sau khi
- Yêu cầu phục vụ một trường hợp riêng và chưa có dấu hiệu lặp lại.
- Luồng hiện tại vẫn đủ để kiểm tra mục tiêu chính.
- Tác động đến dữ liệu và kiểm thử chưa rõ.
- Người có thẩm quyền chưa chấp nhận thay đổi chi phí hoặc thời gian.
Quyền quyết định phải đi cùng tác động
Product duyệt điều chỉnh không ảnh hưởng phạm vi. Tech lead chọn cách triển khai trong giới hạn đã thống nhất. Thay đổi làm tăng chi phí, dời mốc hoặc bỏ cam kết cần người phụ trách ngân sách xác nhận. Sales không hứa ngày hoàn thành trước khi đội đánh giá, dev không tự thêm yêu cầu vì phần code có vẻ ngắn. Bài cách thiết kế vai trò và quyền truy cập là tham chiếu để mô tả chủ thể, hành động và điều kiện quyết định.
Sau quyết định, backlog và tiêu chí bàn giao phải khớp
Ticket mới cần liên kết với yêu cầu gốc, test case bị ảnh hưởng phải được sửa. Phần việc bị lùi cần có trạng thái và phiên bản dự kiến. Khi nghiệm thu, đội đối chiếu sản phẩm với phạm vi mới nhất thay vì dựa vào trí nhớ cuộc họp.
Bắt đầu bằng một hàng chờ thay đổi
Với đội nhỏ, hãy thêm loại yêu cầu, người đề xuất, tác động, quyết định và phiên bản xử lý vào backlog hiện có. Chọn một người giữ hàng chờ và một thời điểm rà cố định.
Nếu phạm vi hiện tại chưa đủ rõ để so sánh, đội nên quay lại quy trình xây MVP từ ý tưởng và chốt mục tiêu, luồng chính cùng tiêu chí bàn giao. Dịch vụ Product Development của Auranium có thể hỗ trợ đội thiết kế phạm vi, backlog và cơ chế duyệt thay đổi phù hợp với nhịp phát triển thực tế.