10 lời khuyên dành cho chủ sản phẩm trong quản lý sản phẩm Agile
Bài đăng này đã không được cập nhật trong 7 năm
Quản lý sản phẩm Agile
Trước khi chúng ta đi sâu vào các mẹo quản lý sản phẩm Agile, đầu tiên chúng ta hãy xem xét xem quản lý sản phẩm Agile là gì? Chủ sản phẩm trong khung làm việc Scrum là người duy nhất chịu trách nhiệm về sự thành công của một sản phẩm và tối đa hóa giá trị của sản phẩm đó. Trong khu làm việc Scrum, một số nhiệm vụ của chủ sản phẩm được mô tả như là quản lý backlog sản phẩm, tối đa hóa giá trị và quản lý các bên liên quan. Bên cạnh các nhiệm vụ trên, vai trò của chủ sản phẩm cũng liên quan nhiều tới quản lý sản phẩm. Vì vậy , chủ sản phẩm là một loại quản lý sản phẩm Agile.
Vai trò của chủ sàn phẩm hoàn toàn khác biệt so với các vai trò truyền thống được biết tới ở hầu hết các tổ chức. Một vài người nghĩ rằng chủ sản phẩm là một dạng của "quản lý dự án Agile" hoặc một số khác nghĩ rằng chủ sản phẩm là một dạng chuyên viên phân tích nghiệp vụ. Điều đó không đúng. Chủ sản phẩm thực sự là người sở hữu sản phẩm. Anh/cô ấy là người duy nhất chịu trách nhiệm và được tin tưởng cho sự thành công của sản phẩm. Vì vậy, sự chú ý của chủ sản phẩm không phải là "thực hiện dự án" mà là phân phối, duy trì và tiếp thị sản phẩm!
10 lời khuyên cho chủ sản phẩm
1. Hành động như một người lãnh đạo sản phẩm chứ không phải "người quản lý dự án Agile"
Một người quản lý dự án chịu trách nhiệm quản lý phạm vi, ngoại lệ, "nguồn lực" và các báo cáo (tất nhiên, trong số nhiều thứ khác). Là một chủ sản phẩm, công việc của mạn không phải là quản lý "nguồn lực" và "nhiệm vụ". Việc của bạn là tối đa hóa giá trị sản phẩm của bạn. Để tạo ra những tính năng mang lại giá trị cao nhất cho người dùng. Để tối đa hóa giá trị cho sản phẩm của bạn, bạn không phải quản lý những thứ như nhiệm vụ, những gì mọi người làm hàng ngày, sựu tiến bộ của nhóm trong một sprint. Tất cả những thứ đó có thể được team tự quản lý. Do đó, hãy dừng việc quản lý tiểu tiết đối với team và bắt đầu tối đa hóa giá trị sản phẩm của bạn, trong việc hợp tác với người dùng, khách hàng và các bên liên quan.
2. Giải thích cho các bên liên quan của bạn tại sao bạn đang làm việc theo Agile
Agile không phải là một sự cường điệu, cũng không phải cái bạn làm. Đó là một quan niệm suy nghĩ. Đó là một tập hợp của những giá trị và nguyên tắc hướng dẫn bạn. Scrum là một khung làm việc. Đó là một khung làm việc được sử dụng trong môi trường phức tạp để phát triển và duy trì những sản phẩm phức tạp. Các làm việc, các giá trị và nguyên tắc mà bạn muốn nắm lấy khá khác biệt so với cách làm việc truyền thống. Điều đó cũng áp dụng cho văn hóa và quản trị của tổ chức. Các bên liên quan cần cách suy nghĩ và hành vi của họ, vì thế bạn cần đầu tư thời gian (cùng với Scrum Master hoặc Agile Coach)để huẩn luyện các bên liên qua và giải thích Agile cho họ.
3. Hãy hướng sản phẩm thay vì hướng dự án
Một dự án (như trong định nghĩa của nó) là cái gì đó có kết thúc. Dự án là một tổ chức tạm thời được tạo ra để cung cấp một phạm vi cụ thể,trong một khoảng thời gian và ngân sách nhất định. Một chủ sản phẩm nên tập trung vào việc cung cấp một sản phẩm. Hãy đoán xem? Việc phát triển sản phẩm không kết thúc miễn là sản phẩm tồn tại. Ngoài ra, chúng tôi đo lường sự thành công của một dự án bằng nhiều cách khác nhau hơn là đo sự thành công của sản phẩm. Một dự án thường thành công khi phạm vi thỏa thuận trước được thực hiện đúng thời hạn và trong phạm vi ngân sách. Tuy nhiên, một sản phẩm được coi là thành công khi nó được chấp nhận, sử dụng và đánh giá bởi người dùng.
4. Cải thiện thời gian học (thay vì thời gian ra thị trường)
Rất nhiều người và tổ chức tập chung vào việc giảm thời gian ra thị trường. Tất nhiên, nó có giá trị, bởi vì bạn có thể cung cấp sản phẩm tới khách hàng nhanh hơn. Là chủ sản phẩm, bạn muốn tối đa hóa giá trị cho khách hàng của bạn, do đó, cung cấp nhanh hơn và thường xuyên hơn có vẻ tốt?Chắc chắn nó có! Nhưng có một vấn đề...bạn không xác định được giá trị từ trước. Đúng rồi, bạn không thể xác định được giá trị từ trước. Bất kể cái gì có giá trị hay không, được xác định bởi khách hàng và người dùng của bạn. Dựa vào cách sử dụng và phản hồi của họ, bạn sẽ học được những gì có giá trị và cái gì không. Vì vậy, bạn chỉ nên cải thiện thời gian ra thị trường, Bạn nên tập trung vào việc nâng cao thời gian học. Thời gian học không chỉ có nghĩa là ra thị trường mà nó cũng bao gồm phản hồi của khách hàng và người dùng. Vì thế thời gian học sẽ thú vị hơn, vì nó cũng bao gồm vòng lặp phản hồi từ khách hàng / người dùng mà ở đó thời giẩn thị trường không được bao gồm trong vòng lặp phản hồi.
5. Chịu trách nhiệm cho sự thành công của sản phẩm
Là chủ sản phẩm, bạn chịu trách nhiệm cho sự thành công cuối cùng của sản phẩm. Tôi thấy rất nhiều chủ sản phẩm, những người chịu trách nhiệm cho một số phần của hệ thống, hoặc là "chủ sản phẩm chuyển tiếp"đang quản lý backlog sản phẩm thay cho người khác (người không tồn tại).
6. Dừng "waterfall" trong sprint, bắt đầu cung cấp giá trị cho khách hàng / người dùng
Chúng ta thấy nhiều chủ sản phẩm đang thực hiện Scrum trong một dư án. Tôi cũng thấy nhiều chủ sản phẩm chia cắt hệ thống thành các lớp hệ thống (như giai diện người dùng, phần xử lý, phần trung gian, phần cứng...). Nó không giúp bạn trong việc tối đa hóa giá trị. Ví dụ, một kiến trúc hoàn chỉnh không mang lại bất cứ giá trị nào cho người dùng. Dù vậy, một tính năng hoàn chỉnh của sản phẩm lại mang lại giá trị cho người dùng. Do đó đừng cung cấp một lớp của hệ thống trong một Sprint, hãy cung cấp một tính năng hoàn thiện. Một ví dụ khác tôi gặp thường xuyên, đó là team tạo ra thiết kế trong một sprint và phát triển trong sprint tiếp theo, họ test trong sprint kế tiếp và cuối cùng cung cấp cho người dùng trong sprint thứ tư. Hãy cố gắng làm cho product backlog item nhỏ hơn, như thế bạn sẽ có thể cung cấp một tính năng hoàn thiện trong một sprint.
7. Hiểu rằng phân tích nhiều hơn không (nhất thiết) làm cho sản phẩm tốt hơn.
Có nhiều team thường làm việc trong các dự án. Các dự án là những cách tuyệt vời để làm việc trong các môi trường rắc rối, tuy nhiên không nhiều lắm trong các môi trườngphức tạp. Trong các môi trường phức tạp, bạn cần một phương pháp tiếp cận thực nghiệm, chẳng hạn như khung làm việc Scrum. Trong môi trường rắc rối, các vấn đề thường có nguyên nhân và ảnh hưởng điển hình. Do đó, thực hiện phân tích nhiều hơn từ trước sẽ có kết quả là giải pháp tốt hơn về sau. Tuy nhiên, trong môi trường phức tạp, các vấn đề thường có nhiều nguyên nhân và ảnh hưởng. Điều này có nghĩa là phương pháp tốt nhất không phải là phân tích nhiều hơn. Phương pháp tốt nhất trong môi trường phức tạp là thực hiện một bước (hành động), hơn là quan sát những gì xảy ra (ý thức)và hơn phản ứng với các dữ liệu mới thu thập được(phản hồi). Vì vậy, các chủ sản phẩm thân yêu, hãy nhớ rằng thế giới không thể dự đoán, nhưng bắt đầu thử nghiệm, kiểm thử, phát hành và thu thập phản hồi từ thị trường!
8. Nghiên cứu thị trường, bán hàng và tiếp thị là một phần nhiệm vụ của bạn
Rất nhiều chủ sản phẩm chỉ chịu trách nhiệm cho một hệ thống hoặc một phần của hệ thống. Tuy nhiên, điều đó không bao gồm ý tưởng về một chủ sản phẩm thực sự là người sở hữu một sản phẩm, của một chủ sản phẩm trở thành một doanh nhân (được biết đến như mức độ trưởng thành cao nhất của chủ sản phẩm). Một chủ sản phẩm kinh doanh, người chịu trách nhiệm cuối cùng cho sự thành công của sản phẩm, cũng chịu trách nhiệm trong việc nghiên cứu thị trường, bán hàng, tiếp thị...
9. Tập trung vào nâng cao giá trị(kết quả) thay vì nâng cao vận tốc(đầu ra)
Rất, rất nhiều chủ sản phẩm tập trung vào việc nâng cao vận tốc của team. Xin hãy dừng việc đó lại. Đo lường vận tốc của một team dựa trên cơ sở của một kỹ thuật ước tính tương đối. Nó có nghĩa rằng story point có giá trị tương đối. Nó rất dễ dàng cho một team để nhân đôi vận tốc nếu bạn yêu cầu họ làm như vậy, họ sẽ có thể nhân đôi vận tốc chỉ trong vài giây. Đơn giản, họ chỉ việc nhân đôi hoặc nhân ba ước lượng của họ. Do đó, đừng so sánh các team dựa trên vận tốc, hay tập trung quá nhiều vào việc nâng cao vận tốc. Hãy bắt đầu tập trung vào giá trị. Đo lường giá trị được cung cấp bởi team, đo lường sự ảnh hưởng của những bản cung cấp mới với KPI sản phẩm của bạn, đo lường sự hài lòng của khách hàng/ người sử dụng...
10. Hãy là một chú cá heo chứ đừng là tàu ngầm
Lời khuyên cuối cùng của chúng tôi về quản lý sản phẩm Agile là hãy ở trên mặt nước (như một chú cá heo). Một chú cá heo chỉ lặn xuống dưới mặt nước trong một khoảng thời gian ngắn và sau đó sẽ lại nổi lên trên mặt nước, nói cách khác, một con cá heo luôn có thể nhìn thấy được. Trong môi trường phức tạp và phát triển sản phẩm phức tạp, bạn cần có phản hồi từ khách hàng và người dùng sớm và thường xuyên. Tuy nhiên, rất nhiều chủ sản phẩm bị dụ dỗ để ẩn mình quá lâu (như một chiếc tàu ngầm). Họ có ý tưởng rằng nếu như chúng ta dành thêm một chút thời gian nữa cho sản phẩm, chúng ta có thể làm cho sản phẩm trở nên hoàn hảo đối với khách hàng và người dùng. Đừng làm điều đó. Nó không giúp bạn dành nhiều thời gian hơn cho sản phẩm, mà nó giúp bạn phát hành sớm và thường xuyên, để cung cấp cho khách hàng và người dùng của chúng ta và nhận phản hồi của họ. Phương pháp này giúp bạn rất nhiều trong việc tối đa hóa giá trị sản phẩm.
(nguồn : https://www.scrum.org/resources/blog/10-tips-product-owners-agile-product-management)
All rights reserved