Scrum Team của bạn đang luôn bị quá tải bởi công việc? Scrum Team của bạn đang chịu áp lực phải làm nhiều hơn? Bạn không hiểu được mục đích công việc hiện tại của bạn đang làm là gì? Những thay đổi cứ diễn ra liên tục, khiến Team bạn mệt mỏi và mất phương hướng? Có cái gì đó cứ sai sai trong cái guồng quay công việc này? Hãy cùng Scrumviet bắt mạch xem vì sao nhé.
Cùng xem qua biểu đồ dưới đây: Trong bài thứ 3 của loạt bài công cụ hỗ trợ Scrum team đưa ra quyết định, Scrumviet xin chia sẻ cùng các bạn một biểu đồ tương quan khác giữa xác suất xảy ra và lợi ích nhận lại, để giúp Scrum Master có thể linh hoạt và sử dụng khi cần thiết. Biểu đồ này rất hữu dụng để giúp Scrum team xác định được phần trăm của sự mơ hồ, khó đoán (Liệu dịch vụ hay chức năng mới xây dựng đạt được giá trị như kỳ vọng), kèm với lợi ích có thể nhận lại nếu dịch vụ hay chức năng mới xây dựng có mang về thành công mong muốn cho sản phẩm.
Tiếp theo chuỗi bài giúp cho Scrum Master có thể facilitate để Scrum team có thể đưa ra được quyết định tốt nhất. Hôm nay Scrumviet chia sẻ cùng các bạn một biểu đồ khác, thể hiện sự tương quan giữa sự nỗ lực và giá trị (Effort x Value). Biểu đồ này có thể sử dụng cùng với biểu đồ khả thi x hữu ích (Feasible x Useful) để giúp Scrum team có được quyết định tốt nhất có thể.
Là một Scrum Master, nhiều lúc bạn sẽ cần phải facilitate giúp Scrum team quyết định được đâu là giá trị của sản phẩm nên làm và theo đuổi, đâu là những giá trị chưa cần đến trong lúc này. Bạn nắm được nhiều cách thức để tổ chức và tạo điều kiện cho Scrum team trao đổi bao nhiêu, thì Product Owner và Developer càng dễ dàng thảo luận và tối ưu hoá được quyết định của mình bấy nhiêu. Vì vậy hôm nay Scrumviet giới thiệu cùng bạn một phương pháp đơn giản, nhưng mạnh mẽ, giúp Scrum team có thể dễ dàng xác định đâu là giá trị sản phẩm hữu ích cho người dùng, và liệu nó có khả thi để thực hiện hay không?
Trong những tổ chức đang áp dụng Scrum vào công việc, rất nhiều tổ chức đang áp dụng Scrum ở quy mô lớn, nhiều Scrum team cùng làm việc trên một sản phẩm. Việc mở rộng nhiều Scrum team cùng làm trên một sản phẩm sẽ là cơ hội cho sản phẩm được phát triển nhanh hơn, mang lại nhiều giá trị hơn đến người dùng. Nhưng nó cũng chứa đựng nhiều thử thách và khó khăn trong việc làm sao để các Scrum team phối hợp với nhau một cách hiệu quả. Có một sai lầm cố hữu mà tôi nhận thấy đa phần các nhóm Scrum cùng làm trên 1 sản phẩm mắc phải, đó là có nhiều hơn 1 Product Owner cho sản phẩm đó. Không phải tự nhiên mà Scrum guide trực tiếp đề cập đến việc:
The Product Owner is one person, not a committee - Scrum guide 2020
Vậy khi một sản phẩm, có nhiều hơn một Product Owner thì chuyện gì sẽ xảy ra? Hãy cùng tôi điểm qua những vấn đề mà sản phẩm, và Scrum team sẽ gặp phải nếu có nhiều hơn một Product Owner nhé:
FAST Goal là gì?
FAST Goal là một phương thức đặt mục tiêu và đo lường cho nhóm hay tổ chức tương đối mới, được Donald Sull và Charles Sull chia sẻ gần đây vào năm 2018. Trong bài viết đầu tiên của mình Donald Sull và Charles Sull chia sẻ rằng họ đã nghiên cứu và thống kê hơn 500.000 công ty, tổ chức thành công về cách tạo ra mục tiêu và đạt được chúng. Họ đã tìm ra công thức thành công chung của những công ty, tổ chức này trong việc đặt ra và đạt mục tiêu, và gọi nó là “4 nguyên tắc cốt lõi” để đặt một mục tiêu hiệu quả.
FAST Goal là phương thức được cấu thành từ 4 nguyên tắc cốt lõi:
Goal Oriented Product Roadmap (GO Product Roadmap) là gì?
Goal Oriented Product Roadmap hay GO Product Roadmap là một trong những cách trình bày Product Roadmap tập trung vào mục tiêu (Goal) của sản phẩm trong tương lai. Việc trình bày Product Roadmap hướng đến mục tiêu của sản phẩm, sẽ giúp Product Owner có thể dễ dàng hơn trong việc quản lý Product Backlog cam kết với Product Goal, tránh việc chỉ chú tâm đến chức năng mà quên mất giá trị người dùng.
Lean Canvas là gì?
Lean Canvas là một công cụ giúp xây dựng chiến lược kinh doanh một cách đơn giản và nhanh chóng. Khi áp dụng Lean Canvas, chiến lược kinh doanh của sản phẩm sẽ được trình bày trong một trang duy nhất. Ash Maurya là tác giả của Lean Canvas, và ông đã tạo ra Lean Canvas dựa trên Business Model Canvas (được tạo ra bởi Alexander Osterwalder) kết hợp với tư duy khởi nghiệp tinh gọn (Lean Startups).
Trong khi kế hoạch/ chiến lược kinh doanh mất quá nhiều thời gian để viết, hiếm khi được cập nhật và hầu như không bao giờ được người khác đọc. Việc dễ dàng ghi chép lại, theo dõi và cập nhật kế hoạch của bạn là chìa khóa quan trọng góp phần thành công. Lean Canvas sẽ thay thế các kế hoạch kinh doanh dài và nhàm chán bằng một cách trình bày trong một trang duy nhất. Nó sẽ tạo ra tính đơn giản, gọn nhẹ, dễ thay đổi và có thể dễ chia sẻ để tương tác với các bên liên quan khác nhau. Những lợi điểm này mà đã giúp Lean Canvas được rất nhiều tổ chức hay các Scrum team sử dụng, và cũng trở thành một trong những công cụ hữu ích được sử dụng bởi Product Owner, khi xây dựng mô hình kinh doanh cho sản phẩm của mình.
Now - Next - Later Product roadmap là một công cụ giúp cho Product Owner có thể dùng để trình bày và truyền đạt ý tưởng về độ ưu tiên của các PBIs trong Product Backlog. Nó cũng được xem như là một cách trình bày Product Backlog của Product Owner nhằm nhấn mạnh và thể hiện rõ giá trị sản phầm nào có mức độ ưu tiên cao hơn. Cách trình bày này cung cấp cho nhóm và các bên liên quan một cách trực quan dễ hiểu và dễ dàng thay đổi trong bối cảnh những nhu cầu về sản phẩm thay đổi liên tục.
Pirate hay AARRR framework được tạo bởi Dave McClure và được chia sẻ vào năm 2007. Pirate hay AARRR framework là một công cụ giúp trực quan hoá mô hình kinh doanh thành những mảng nhỏ, nơi bạn có thể tập trung sự chú ý của mình để phát triển. Sở dĩ nó được gọi là mô hình/ framework ”cướp biển” là vì các chữ cái đầu tiên được viết thành AARRR (“Cướp biển thường hay nói AARRR!!!!”). AAARR ở đây là viết tắt của 5 vùng:
Bài viết này tôi xin chia sẻ về những sai lầm trong vai trò Product Owner (PO) mà tôi thường thấy nhất (Tôi phân tích và tổng hợp lại thành một vài sai lầm thường gặp nhất trong rất nhiều sai lầm khác nhau). Mục tiêu là để các Scrum Team nhận thấy được những ảnh hưởng từ những sai lầm này, để tránh hoặc thay đổi cách làm việc của mình, qua đó có thể xây dựng một Scrum Team tốt hơn.
Chú ý: Một Product Owner có thể đang mắc một hoặc nhiều sai lầm được liệt kê ở dưới cùng lúc. Empathy Map là gì?Empathy Map là công cụ giúp chúng ta có thể liên kết, và hình dung rõ hơn về hành vi và cảm nhận của người dùng sản phẩm, qua đó có được sự hiểu biết sâu hơn về khách hàng, để có sự điều chỉnh phù hợp làm hài lòng khách hàng hơn. Trong quá trình bạn lập lên biểu đồ, những khoảng trống, hay câu hỏi chưa được trả lời sẽ giúp bạn nhận ra được những thiếu sót, lỗ hỗng nào mà bạn chưa nhận ra để cải thiện.
Công cụ này được sử dụng rất nhiều bởi các nhóm làm việc chuyên về UX (User Experience), cũng như là một công cụ chủ lực cho Product Owner hiểu và định hình hành vi của khách hàng với sản phẩm. As the product owner, you are well aware that part of the success of your product depends on your decision. Every day, you must be facing:
Một trong những giá trị thể hiện được một Scrum team có thành công và tiến bộ qua từng Sprint hay không, được thể hiện qua việc Scrum Team xác định được giá trị khách hàng cần, và có cải tiến/tối ưu công việc của mình cần làm trong Sprint để đạt được Sprint Goal hay không. Việc Scrum team xác định/hiểu được nhu cầu của khách hàng, và Developer tự tối ưu hoá được công việc của mình trong Sprint là điều không dễ dàng, và có rất nhiều hiểu lầm và áp dụng KHÔNG đúng các công cụ và phương pháp như:
Kano Model là một mô hình giúp xác định rõ mối quan hệ giữa việc phát triển sản phẩm và sự hài lòng của khách hàng được xây dựng bởi giáo sư Noriaki Kano vào năm 1980s.
Nhiều bài viết của Scrumviet đã nói về làm sao để tạo ra được sản phẩm đúng với nhu cầu của người dùng. Để trả lời câu hỏi đó không dễ, và đòi hỏi Product Owner phải áp dụng nhiều phương thức, công cụ và kiểm nghiệm liên tục. Nói về công cụ, Kano Model là một trong những công cụ PO có thể sử dụng để xác định mối liên hệ giữa sản phẩm/ chức năng sản phẩm của mình đang đáp ứng được khách hàng của mình thế nào.
Little’s Law là gì?
Little’s Law là một định lý của John Little. Đơn giản là một công thức dùng để thể hiện mối tương quan giữa ba giá trị:
Để có thể tối ưu hoá được giá trị sản phẩm của mình, các Product Owner phải làm chủ được Product backlog. Nhưng việc quản lý Backlog không hề dễ dàng. Các Product Owner luôn gặp khó khăn trong việc xác định sự ưu tiên của các Product Backlog Items. Sự khó khăn này bắt nguồn từ việc các Product backlog thường chứa đựng rất nhiều thứ khác nhau, đến từ nhu cầu của nhiều bên khác nhau: Khách hàng, CEO, các phòng ban… hay còn là các lỗi hoặc nợ kỹ thuật cần được xem xét.
Sự hỗn tạp này khiến nhiều Product Owner bối rối, và gặp khó khăn khi đưa ra quyết định nên ưu tiên Product Backlog Items nào trước. Hay làm sao kết nối những ưu tiên đó với mục tiêu chung của sản phẩm hoặc doanh nghiệp. Với lý do đó Jeff Patton đã nghĩ ra một phương pháp gọi là User Story Mapping, để giúp Product Owner có thể dễ dàng hơn trong việc sắp xếp thứ tự của các Product Backlog Items (PBIs). Nói đơn giản: User Story Mapping là một phương pháp sắp xếp phân loại, trực quan hoá Product backlog, giúp cho Product backlog của bạn trở nên dễ quản lý hơn, và thể hiện được sự liên kết giữa người dùng và giá trị mà bạn muốn xây dựng cho họ. Phương thức này vô cùng đơn giản (Xem hình dưới):
Wrong determination
People often think that persistence or not giving up will bring them to the success. However looking back to your past, how many times you tried, but did not get a good result? Your determination faced with many failures than successes or even just only failures? Did you ask yourself "Why" and "What is missing to be successful"? Let's talk about football. Does the football team want to win the cup or want to win all the matches? If you put your expectations on how to win every match, that’s more challenging and might be impossible. But if the goal to win a cup, it will give you a better chance and strategies like you do not need to win all the matches (by accepting the loss or draw in some matches). Or even have a long preparation to be the champion in the couple years rather than this year . Having persistence and determination is good but putting it on the right thing, and the right time is more important. The journey to reach the goal is a long journey. And you can have a lot of strategies to achieve it. Knowing how to inspect and adapt the plan or strategy to help you reach the goal; once you failed, you learn from it, change your plan, and continue.
Có nhiều câu hỏi và mối quan tâm về việc quản lý rủi ro xoay quanh việc trao quyền cho Scrum Team như:
Làm thế nào để đảm bảo thành công cho Product nếu Product Owner không hiểu nhiều về Product hoặc chưa đủ kỹ năng? Làm sao Product Owner quyết định được Business Value nào sẽ là trong 20% mang lại 80% giá trị? (80/20 - Pareto Principle) Việc trao quyền cho Development Team dẫn đến nhiều rủi ro tiềm ẩn? Làm sao Development Team biết nên làm gì và làm thế nào để tạo ra Done Increment?
Nội dung đã được cập nhật theo bản Scrum guide 2020
Nhiều năm trước, tôi bắt đầu tìm hiểu và quan sát cách thức hoạt động của các dự án phần mềm. Lý do tôi quan tâm đến việc này là vì, nhiều dự án thậm chí đã rất thành công trong việc deliver đúng hạn, đạt được đúng yêu cầu đề ra ban đầu, và hoàn thành trong chi phí cho phép. Tuy nhiên, khi nó được đưa ra thị trường thì không ai sử dụng cả. Sau đó sản phẩm đó cũng chết đi để lại nhiều sự lãng phí trong đầu tư và sức lực của các bên để đảm bảo nó được hoàn thành. Từ đó, trong đầu tôi luôn tồn tại một câu hỏi: Điều gì tạo ra khoảng cách giữa một sản phẩm thành công, được đón nhận bởi người dùng và một sản phẩm thất bại? Qua nhiều năm quan sát, tôi rút ra được một điều, một trong những lý do sản phẩm không được đón nhận như nó được kỳ vọng đa phần là vì nó bị đánh giá sai giữa "Input", "Output" và "Outcome".
Vai trò Product Owner đối với Việt Nam còn mới mẻ, chỉ mới vài năm trở lại đây, người ta mới bắt đầu nói về nó, và nhiều công ty bắt đầu cần và tuyển dụng những ứng viên cho vị trí Product Owner. Nhưng thực ra vai trò Product Owner không hề mới, Product Owner là một trong ba vai trò của Scrum, mà Scrum thì đã hơn 20 năm tuổi.
Definition of Value
Human always follows and find Happiness. Although it's very difficult to find, everybody has different happiness. Some people think money is happiness or a happy family, others think happiness is the peace of the soul (like a monk)... So we can say "what makes people happy is value for them". The company is the same. Of course, every company has an ultimate purpose is revenue (except you are running a non-profit company). So, values of them are making the customer happy, good culture, good processes. over that values is assumed to have more money or save more money. Just start this post with a few questions: Is your product (#Noproject) roadmap working? How much time and effort you take to update it but it's still far away from reality?
If your roadmap is still well and value can be created to the end user, this post is not for you. This post also does not share how to have a good roadmap, just show some common issues when you build a roadmap to make your plan is useless. As Product Owner, how do you deliver Values to your Customer/End-User? To know what is value, you need to validate it. To validate your value, you need to know who is your Customer (End user).
I asked that because identifying your end user is very important. If you don't know who is your real customer, how can you build a product to make them happy? Or you will make no-one happy, no customer happy is no business, right? Let go through 3 Situations below: |