Trong tình huống resource bị cắt 30% so với kế hoạch, bạn sẽ điều chỉnh roadmap như thế nào?

Với team engineering tôi transparent về tình huống và involve họ trong việc estimate impact. Engineers thường có solutions sáng tạo để cut scope mà vẫn preserve value — ví dụ dùng config thay vì build full UI, hoặc implement phiên bản basic trước rồi iterate. Morale tốt hơn khi họ là người contribute vào giải pháp thay vì chỉ nhận quyết định.

Sau khi có options rõ ràng, tôi communicate với stakeholder về tradeoffs cụ thể chứ không chỉ nói 'chúng ta bị cắt resource'. Tôi nói: 'Chúng ta có thể chọn A: ship feature X đầy đủ nhưng delay Y 2 tháng; hoặc B: ship cả X và Y với scope giảm 40%. Bạn muốn chúng ta prioritize theo hướng nào?' Điều này giữ cho họ engaged và feel ownership.

Đầu tiên tôi không panic cut ngẫu nhiên mà ngồi với tech lead để estimate impact thực sự của resource loss lên từng item đang plan. Một số item có thể scope down mà vẫn deliver core value. Một số khác phụ thuộc vào critical path nên phải postpone hoàn toàn. Tôi phân loại thành ba nhóm: ship as-is (nếu gần xong), scope down và ship, hoặc defer.

Tôi dùng cơ hội này để làm sạch backlog: khi resource eo hẹp, mọi người dễ accept việc cut những item không đủ strong evidence. Tôi review lại từng item và ask: 'Nếu chúng ta không bao giờ build cái này, user sẽ bị ảnh hưởng thế nào?' Thường thì 30-40% backlog sẽ bị cut mà không ai phàn nàn.