Trong Scrum, các nhà phát triển có nên nói chuyện trực tiếp với khách hàng (bỏ qua PO) không?

Làm thế nào một chủ sở hữu sản phẩm trong scrum đối phó với các câu hỏi rất chi tiết từ nhóm về các tính năng họ đang triển khai mà anh ta không thể tự trả lời ngay lập tức? Khi nào thì rõ ràng sẽ là giải pháp nhanh hơn để nhà phát triển nói chuyện trực tiếp với chính khách hàng?

Tôi tự hỏi nếu giao tiếp trực tiếp giữa nhóm và khách hàng làm suy yếu vai trò của chủ sở hữu sản phẩm. Tôi cảm thấy như PO nên đại diện độc quyền cho khách hàng và do đó trả lời tất cả các câu hỏi liên quan đến các yêu cầu - ngay cả khi điều đó mất nhiều thời gian hơn. Bỏ qua anh ta dường như làm anh ta yếu đi và cuối cùng khiến anh ta trở nên thừa thãi ...

Có một thực hành tốt nhất trong scrum?

Luôn luôn là một ý tưởng tốt (đặc biệt là trong các dự án được gọi là Agile) không dính vào giáo phái hàng hóa hoặc sách giáo khoa nói với bạn "ai nên (không) nói chuyện với ai", nhưng bật bộ não của bạn và làm bất cứ điều gì tốt nhất trong một dự án.

Mặc dù giao tiếp giữa PO và khách hàng phải là tiêu chuẩn (vì lý do được @PatrickHughes đưa ra trong nhận xét của anh ấy), bạn có thể phải đối mặt với một tình huống yêu cầu kinh doanh phức tạp phải được làm rõ và giao tiếp trực tiếp giữa nhà phát triển và nhà cung cấp chuyên gia kinh doanh sẽ tăng tốc mọi thứ rất nhiều. Trong tình huống như vậy, người ta nên tránh chơi "tiếng thì thầm Trung Quốc" với PO ở giữa, và để nhà phát triển và chuyên gia kinh doanh nói chuyện trực tiếp với nhau - cho bối cảnh bị hạn chế này.

Tuy nhiên, PO không bao giờ nên được bỏ qua. Lý tưởng nhất là anh ấy tham gia vào cuộc trò chuyện đó, có lẽ là người điều hành. Anh ta có thể xác minh khách hàng không đưa ra các yêu cầu hoàn toàn mới trên bàn trong suốt cuộc nói chuyện, hoặc các yêu cầu trái với những gì đã thỏa thuận trước đó.

Điều này cũng phụ thuộc vào những người liên quan, và tình hình. PO có thể có đủ niềm tin vào nhà phát triển cụ thể và chuyên gia của khách hàng, để hai người nói chuyện một mình về một chủ đề cụ thể và để anh ta hoặc cô ta báo cáo những gì đã nói sau đó. Trong một tình huống khác, với những người khác có liên quan, anh ta có thể thích tham gia một phần tích cực hơn. Để có được quyết định này đúng là cốt lõi của quản lý dự án tốt.

Đối với các nhà phát triển, chủ sở hữu sản phẩm là khách hàng. Lý tưởng nhất (và tôi biết rằng không phải lúc nào cũng có thể) chủ sở hữu sản phẩm nên là đại diện trực tiếp của khách hàng, chuyên gia về miền và người dùng tương lai của hệ thống.
Đó là cách tốt nhất để đảm bảo bạn có sẵn thông tin trực tiếp và chính xác và các dòng ngắn nhất có thể vào quy trình của họ.

Ví dụ lý tưởng có lẽ là nhóm tôi đang làm việc cùng. Chủ sở hữu sản phẩm là người dùng cuối và chuyên gia tên miền cao cấp có toàn quyền ủy quyền cho các quyết định thiết kế tại chỗ (và sự sẵn sàng và khả năng thực sự làm như vậy). Anh ấy là một phần không thể thiếu của nhóm và trực tiếp hỗ trợ nhà phân tích và nhà thiết kế viết các câu chuyện của người dùng, cũng như các lập trình viên và người thử nghiệm trong việc xây dựng sản phẩm bằng cách cung cấp phản hồi gần như ngay lập tức về các câu hỏi triển khai và các kịch bản thử nghiệm.
Các dòng thực sự không thể ngắn hơn việc người dùng tương lai của bạn ngồi cạnh bạn trong khi mã hóa :)

Bạn phải nhớ rằng khách hàng của công ty sử dụng bạn là nhà phát triển có những mục tiêu khác nhau đối với công ty sử dụng bạn.

Chủ sở hữu sản phẩm phải đại diện cho các mục tiêu của công ty bạn chứ không phải là mục tiêu của khách hàng. Vì vậy, nếu các nhà phát triển đi thẳng đến khách hàng, họ có thể phá hoại công ty riêng của họ.