Mọi công ty đều đặt trọng tâm vào khách hàng ở trong tuyên bố tầm nhìn hay sứ mệnh của mình, nhưng thực tế có phải như vậy không?
Với tư cách là nhân viên của nhóm phát triển, làm cách nào để biết công ty chúng ta đang tập trung vào khách hàng?
Làm sao ta biết công ty của chúng ta đang bị khách hàng ám ảnh?
Làm thế nào để mình cảm nhận nó? 

Đây là những câu hỏi mà tôi muốn khám phá trong bài đăng này.
Hãy bắt đầu với một câu hỏi đơn giản cho nhóm:

Khách hàng

Có bao nhiêu người ở giữa khách hàng và nhóm phát triển?

Thông thường, bạn thấy một cái gì đó như thế này:

Thường có nhà quản lý dự án, nhà phân tích kinh doanh, kỹ sư về kĩ thuật yêu cầu, cấp phó, ban chỉ đạo, chuyên gia về khả năng sử dụng của sản phẩm, người kiểm thử phần mềm hoặc nhóm Q&A giữa nhóm phát triển và người dùng.

Tôi xem những người dùng là khách hàng quan trọng nhất của chúng tôi, bởi vì nếu người dùng không hài lòng, sẽ không ai trả tiền cho sản phẩm (nhà tài trợ).

Product Owner có thể làm gì để cải thiện tình trạng này?

Tôi đã thu thập 6 mẹo cho việc này:

1. Mời người sử dụng

Thay vì tập trung vào các yêu cầu hoàn hảo và đầu tư rất nhiều thời gian vào đó, tôi khuyên bạn nên đưa người dùng đến gần hơn với nhóm phát triển. Chúng ta có bao giờ muốn mời một người dùng tham gia buổi Sprint Review không? Hay đến phòng của nhóm và trình bày cách chúng ta làm việc và mời anh ấy góp ý về tính năng hiện tại?

Tôi có thể làm gì để tách mình với vai trò là Product Owner ra khỏi hệ thống này và tập trung nhiều hơn vào chiến lược sản phẩm?

2. Hợp nhất các Nhóm lại thay vì chia chúng ra

Thay vì chia nhóm thành các nhóm chuyên biệt, chẳng hạn như nhóm kiểm thử  hoặc nhóm Q&A, nhóm này sau đó chuyển giao công việc để có thể tự phát triển “hiệu quả” hơn, thì tôi khuyên bạn nên tập hợp các nhóm này lại với nhau.
Tôi thường xuyên thấy “bug ping pong” giữa các teams và không bao giờ thấy nó hiệu quả.

Tôi thực sự khuyên bạn nên tập hợp các nhóm lại với nhau, ghép nối nhóm và hoàn thành cũng như hoàn thiện (Definition of Done) các tính năng của sản phẩm (Product Backlog Items) cùng nhau. 

3. Giới thiệu Feedback Moments

Thay vì chấp nhận hoặc “từ chối” các mục trong Product Backlog, với tư cách là Product Owner, tôi khuyên bạn nên tìm kiếm một cách cộng tác khác. Ví dụ: “feedback moments” đi theo hướng là cho phép đưa người dùng trực tiếp đến nhóm và để họ đưa ra lời góp ý. Những feedback moments này có thể trao quyền cho nhóm, cho nhóm phát triển bất cứ điều gì mà họ cần và đối mặt với các vấn đề của người dùng thay vì đưa ra các giải pháp đã được nhắc đến trước đó. Điều này cũng giúp tạo động lực.

Product Owner đang từ chối một tính năng

Tái bút: Việc chấp nhận hoặc từ chối cũng ngụ ý một hệ thống phân cấp mà chúng tôi không muốn có trong nhóm Scrum . Vì vậy, hãy gọi đó là những feedback moments.

4. Tôn vinh giá trị gia tăng thay vì các KPI bận rộn

Thay vì tôn vinh Velocity, khả năng sử dụng và “sự hoàn thiện của tính năng”, chúng ta nên định nghĩa thành công là tác động đến với người tiêu dùng.
Điều gì trong sản phẩm của chúng ta đã đem lại lợi ích cho nhân loại?

5. Chia nhỏ các tính năng lớn thành các mục tiêu và mục tiêu nhỏ hơn

Thay vì thực hiện các tính năng lớn (big features) với nhiều sprints một lúc, tôi khuyên bạn nên làm việc theo từng bước nhỏ. Làm thế nào chúng ta có thể chia nhỏ tầm nhìn sản phẩm lớn thành các sprint goals có thể hành động được ngay?
Mục tiêu hàng ngày mà chúng ta có thể ăn mừng và đo lường khi cùng chung một nhóm là gì ?

Thật ngược đời khi làm việc theo từng đợt nhỏ, tuy nhiên với sự tiến bộ và kỷ luật sẽ mang lại thành công nhanh hơn và cho phép sản phẩm có thể đưa ra thị trường nhanh hơn.

6. Uỷ quyền các Sprint Goals

Thay vì tự mình làm mọi thứ, tôi nghĩ về những gì tôi có thể ủy quyền với tư cách là Product Owner.
Tôi có thể ủy thác toàn bộ mục tiêu sprint cho một bộ phận không?

Ví dụ về suy nghĩ: “Trong 2 sprints tiếp theo, chúng tôi sẽ nghiên cứu các tính năng cho bộ phận tiếp thị nội bộ. Vui lòng nói chuyện trực tiếp với Stefan và chỉ cần cập nhật cho tôi. Tôi sẽ luôn có mặt tại Daily Scrum.“

Nói cách khác, tôi giao trách nhiệm về nội dung của sản phẩm cho người khác và chỉ lấy thêm thông tin từ họ để đưa ra quyết định khi tôi cần.

Link bài gốc: https://www.scrum.org/resources/blog/dear-scrum-team-does-your-product-make-your-users-happy-6-tips-more-customer-focus