Khách hàng đề nghị thêm hai cấp duyệt đơn và báo cáo theo mẫu nội bộ trước khi ký hợp đồng. Sales muốn cam kết để chốt, còn Product và Engineering phải biết đây là cấu hình dùng chung hay nhánh code riêng.

Đội cần kiểm tra vấn đề, khả năng dùng lại, tác động kỹ thuật và trách nhiệm sau bàn giao, thay vì chỉ nhìn quy mô hợp đồng.

Yêu cầu riêng thường đến trước khi đội hiểu đủ nhu cầu

Bối cảnh

Khách hàng yêu cầu đơn trên một mức giá phải qua trưởng bộ phận rồi đến kế toán. Báo cáo cuối tháng phải đúng file Excel hiện tại.

Điểm nghẽn

Sao chép nguyên quy trình khiến tính năng dễ lỗi thời khi khách đổi chính sách. Từ chối ngay lại có thể bỏ qua nhu cầu chung của phân khúc.

Một mô-đun yêu cầu riêng đứng trước cấu trúc sản phẩm với điểm ghép chưa được xác định

Tách vấn đề kinh doanh khỏi giải pháp khách hàng đề xuất

“Thêm hai cấp duyệt” có thể xuất phát từ kiểm soát hạn mức, phân quyền theo chi nhánh hoặc yêu cầu biết ai xác nhận. Mỗi nhu cầu cần một thiết kế khác.

Product hỏi điều gì kích hoạt bước duyệt, ai chịu trách nhiệm, cần xem dữ liệu gì và khi nào được bỏ qua. Engineering xác định nơi lưu dữ liệu và hệ thống nhận kết quả. Sales ghi rõ điều kiện ký hợp đồng và phần có thể làm thủ công.

Đầu ra là mô tả vấn đề độc lập với màn hình, tên cột và file hiện tại. Yêu cầu “làm giống file Excel” chưa đủ để ước lượng hoặc cam kết.

Khối yêu cầu được tách thành điều kiện, vai trò và dữ liệu trước khi đi vào kiến trúc sản phẩm

Khung quyết định đưa yêu cầu vào sản phẩm

Nên đưa vào roadmap khi

  • Vấn đề xuất hiện ở nhiều khách hàng mục tiêu.
  • Có thể thiết kế bằng cấu hình, vai trò hoặc quy tắc dùng chung.
  • Tính năng phù hợp với định vị và luồng chính của sản phẩm.
  • Đội chấp nhận chi phí hỗ trợ và kiểm thử về sau.

Chưa nên đưa vào roadmap khi

  • Yêu cầu phụ thuộc vào biểu mẫu hoặc quy trình của một doanh nghiệp.
  • Chưa xác định ai dùng và kết quả nào cần đạt.
  • Cách triển khai tạo nhánh xử lý khó kiểm thử cùng sản phẩm chính.
  • Cam kết bán hàng đi trước đánh giá kỹ thuật.

Chọn cách xử lý phù hợp thay vì chỉ trả lời có hoặc không

Đưa vào sản phẩm chung chỉ là một lựa chọn. Quy trình duyệt có thể bắt đầu bằng cấu hình vai trò và ngưỡng giá. Khi nhu cầu chưa ổn định, đội duyệt thủ công để kiểm tra ngoại lệ.

Báo cáo riêng có thể dùng tệp xuất chuẩn để khách chuyển sang biểu mẫu nội bộ. Tích hợp API phù hợp khi khách có hệ thống nhận dữ liệu. Phần phát triển riêng chỉ hợp lý khi phạm vi, chi phí và trách nhiệm nâng cấp được ghi rõ.

Có bốn phương án thường gặp:

  • Cấu hình trong sản phẩm khi quy tắc có thể dùng chung.
  • Quy trình thủ công có kiểm soát để kiểm chứng nhu cầu.
  • Tích hợp dữ liệu khi khác biệt nằm ở hệ thống của khách.
  • Hạng mục riêng khi giá trị hợp đồng đủ bù chi phí xây và duy trì.

Bài Cách tránh bẫy gia công tính năng khi xây sản phẩm B2B phân tích rủi ro của yêu cầu theo từng hợp đồng. Nếu đầu vào sales đang rải rác, hãy dùng quy trình ghi nhận yêu cầu tính năng trước khi đánh giá.

Bốn tuyến xử lý tách thành cấu hình, thủ công, tích hợp và triển khai riêng quanh lõi sản phẩm

Tính chi phí bảo trì ngay khi duyệt yêu cầu

Ước lượng ban đầu thường chỉ gồm phân tích, code và kiểm thử lần đầu. Tính năng riêng còn tăng số trường hợp kiểm tra khi đổi quyền truy cập, dữ liệu hoặc luồng chính. Đội hỗ trợ phải biết khách nào dùng cấu hình nào.

Engineering nêu thay đổi trong dữ liệu, API, phân quyền, kiểm thử hồi quy và giám sát lỗi. Product xác định tính năng có mở cho khách khác không. Sales xác nhận phạm vi báo giá. Phần việc chưa có người phụ trách là chi phí chưa được tính.

Trách nhiệm khi đánh giá yêu cầu tùy chỉnh

Đội sản phẩm và kỹ thuật xử lý

  • Xác minh vấn đề, người dùng và điều kiện hoàn thành.
  • Đề xuất phương án dùng chung hoặc thử nghiệm nhỏ.
  • Ước lượng tác động tới dữ liệu, quyền truy cập và kiểm thử.
  • Ghi rõ giới hạn kỹ thuật cùng kế hoạch duy trì.

Người có quyền kinh doanh xác nhận

  • Quyết định giá trị hợp đồng có đủ cho phần đầu tư riêng.
  • Chốt điều khoản, thời hạn và trách nhiệm hỗ trợ.
  • Chấp nhận phương án thủ công nếu chưa đủ cơ sở phát triển.
  • Duyệt ngoại lệ khi yêu cầu lệch khỏi định vị sản phẩm.

Một cổng trách nhiệm tách đánh giá sản phẩm kỹ thuật khỏi quyết định cam kết thương mại

Ghi quyết định và kiểm tra bằng thử nghiệm nhỏ

Với mỗi yêu cầu lớn, đội ghi vấn đề, nhóm người dùng, nhu cầu từ khách khác, phương án chọn, phần không làm, người duyệt và ngày xem lại. Kèm theo ước lượng phát triển, chi phí duy trì và cách đo mức sử dụng. Sales nhờ đó trả lời nhất quán.

Nếu chưa có cơ sở dùng lại, hãy thử với một nhóm nhỏ bằng cấu hình hiện tại hoặc thao tác thủ công. Kiểm tra tần suất sử dụng, ngoại lệ và phần còn xử lý ngoài hệ thống. Kết quả giúp chọn giữa phát triển chung, tích hợp hoặc triển khai riêng.

Dịch vụ Product Consultant của Auranium có thể cùng đội rà yêu cầu B2B, chọn phương án và đặt điều kiện trước khi đưa vào roadmap. Quyết định sản phẩm cần gắn với nhu cầu kiểm chứng được, không chạy theo từng cuộc trao đổi bán hàng.