Xử lý minh bạch những yêu cầu trái nhau giữa các bên

Kinh doanh có thể muốn kích hoạt ngay, còn vận hành muốn rà soát trước khi bắt đầu công việc. Cả hai lập trường đều có thể hợp lý theo mục tiêu riêng. Nhóm sản phẩm không nên âm thầm dung hòa thành yêu cầu mơ hồ. Làm rõ xung đột và xác định kết quả nghiệp vụ nào tổ chức ưu tiên trong tình huống cụ thể.

Tách đề xuất khỏi lý do

Hỏi từng bên về sự kiện hoặc hệ quả phía sau đề xuất. Phân biệt yêu cầu chính sách với giao diện hay thói quen ưa thích. Hướng dẫn khám phá của GOV.UK khuyến nghị chuyển giải pháp định sẵn thành vấn đề và tìm hiểu ràng buộc.[1] Cách này mở chỗ cho phương án giải quyết nhu cầu gốc.

Ghi nhóm nào hưởng lợi, nhóm nào gánh việc thêm và rủi ro nào còn lại. Tránh coi lời kể của người lên tiếng mạnh nhất là bằng chứng duy nhất. Bao gồm người phải vận hành phương án thỏa hiệp, nhất là khi quyết định tạo việc rà soát thủ công hoặc liên hệ lại khách hàng.

Làm rõ quyền quyết định

Xác định ai được đưa ra đánh đổi liên phòng ban. Nhóm triển khai có thể giải thích hệ quả kỹ thuật nhưng không nên tự tạo thẩm quyền về chính sách nghiệp vụ. Chuyển cấp khi không ai có mặt được quyền chấp nhận hệ quả, thay vì giấu vấn đề chưa chốt trong chi tiết kỹ thuật.

Với tổ chức dùng Scrum, Product Owner sắp thứ tự Product Backlog và vẫn chịu trách nhiệm quản lý danh sách này.[5] Đó là điểm quyết định sản phẩm hữu ích, không phải lý do bỏ qua người sở hữu chính sách. Làm rõ quyền Product Owner nối với quản trị rộng hơn thế nào.

Ví dụ giả định: kích hoạt tài khoản đơn vị lắp đặt

Một nhà cung cấp vật tư giả định nhận yêu cầu trái nhau: cho đơn vị lắp đặt truy cập ngay và xác minh trước khi mua. Nhóm tách quyền xem thông tin sản phẩm khỏi quyền đặt hàng. Nhóm so sánh truy cập giới hạn ngay với kích hoạt đầy đủ sau rà soát theo cùng tiêu chí vận hành.

Phương án được chọn cho người đăng ký xem thông tin, trong khi người duyệt cụ thể quyết định điều kiện mua. Biên bản nêu khối lượng hỗ trợ và năng lực rà soát còn chưa rõ. Không tuyên bố thỏa hiệp đã loại rủi ro hoặc làm mọi bên hài lòng như nhau.

Danh sách kiểm tra xử lý minh bạch

Giữ biên bản dễ hiểu với người không dự họp. Mục đích là giải thích quyết định, không quy lỗi.

• Mô tả mỗi đề xuất và nhu cầu hoặc ràng buộc phía sau.
• Xác định người dùng bị ảnh hưởng và việc chuyển sang nhóm khác.
• So sánh phương án khả thi theo tiêu chí nghiệp vụ đã thống nhất.
• Nêu người có quyền quyết định và ghi phản đối quan trọng.
• Nêu điều kiện xem xét lại và người phụ trách câu hỏi còn mở.

Tránh đồng thuận bất tận và đóng vấn đề âm thầm

Không phải mọi người đều thích lựa chọn cuối, nhưng họ cần thấy cách lựa chọn được đưa ra. Đề nghị sửa sai sót thực tế. Không viết lại bất đồng thành ủng hộ nhất trí chỉ vì việc triển khai cần tiếp tục.

Quy trình minh bạch tốn thời gian và không giải quyết được chiến lược nghiệp vụ còn thiếu. Nếu ưu tiên vẫn không tương thích, thu hẹp phạm vi hoặc dừng phần việc phụ thuộc. Quyết định chưa chốt được nêu rõ dễ trao đổi hơn phần mềm chứa thỏa hiệp mà không ai chủ động chấp nhận.