Đo lường Value Cycle trong APOM

​Các gợi ý đo lường, và đánh giá ​Value Cycle trong APOM


​Đo lường Discovery

Đo lường	Lý do	Chi tiết
Tần suất nghiên cứu tìm hiểu người dùng	Khám phá liên tục, không ngừng tìm tòi: Nếu bạn không thử nghiệm một giả thuyết trước khi bạn xây dựng tính năng, vòng lặp về học hỏi của bạn sẽ bị tổn hại. Xem mỗi lần phát hành sản phẩm ra thị trường như một thí nghiệm để kiểm chứng giả định, đồng thời mang lại giá trị mới cho người dùng, là một việc khôn ngoan.	Quá trình khám phá nhu cầu người dùng là một hoạt động liên tục được tích hợp vào công việc phát triển sản phẩm hằng ngày. Không giống như mô hình phát triển project, product team liên tục khám phá những vấn đề của người dùng, xây dựng giả định, và tìm kiếm cơ hội song song với việc phát hành giá trị mới của sản phẩm.
% của công việc Discovery với giả thuyết rõ ràng.	Học tập dựa trên giả thuyết. Không bao giờ tất tay xây dựng tính năng mà không làm rõ giả thuyết, và không để bắt đầu chu kỳ tiếp theo mà chưa có được bài học kinh nghiệm nào. Nếu một sản phẩm được đưa đến tay người dùng mà không chứng minh được một giả định về giá trị hoặc tính khả thi thì nó không phải là Product Increment, nó chỉ là nhiễu loạn.	Tất cả các hoạt động nghiên cứu khám phá đều được xây dựng dựa trên các giả định có thể kiểm chứng được về giá trị khách hàng, hành vi hoặc tính khả thi. Quá trình học hỏi được ghi nhận một cách rõ ràng và được sử dụng để hướng dẫn việc ưu tiên, đầu tư và ra quyết định.
Tỷ lệ giữa vấn đề và xác thực giải pháp	Xác thực giá trị người dùng. Đừng vội vàng xác định “HOW”, cho đến khi bạn nắm rõ được “WHY”. Nếu bạn không làm rõ được khó khăn của người dùng và giá trị mong muốn đạt được một cách rõ ràng, bạn chưa sẵn sàng tiến hành xây dựng giải pháp.	Giai đoạn khám phá ưu tiên hiểu và xác nhận các vấn đề của khách hàng và kết quả mong muốn trước khi cam kết thực hiện các giải pháp hoặc tính năng cụ thể.
Tần suất liên hệ trực tiếp với người dùng	Tiếp cận trực tiếp người dùng. Loại bỏ những lớp trung gian: Nếu team không thể trực tiếp nói chuyện với người dùng về những khó khăn của họ, team không xây dựng sản phẩm - mà đang chơi trò chơi "tam sao thất bản" với chiến lược của mình. Đừng bao giờ để một bên trung gian quyết định những gì liên quan đến nhu cầu của người dùng.	Các nhóm sản phẩm duy trì quyền liên hệ trực tiếp với người dùng và các bên liên quan để xây dựng sự đồng cảm, bối cảnh và hiểu biết thực tế tránh việc ra quyết định gián tiếp.
% của sản phẩm được phát triển dựa trên quá trình Discovery	Discovery cung cấp thông tin cho việc phát triển sản phẩm. Discovery rồi để đó giống như làm cho vui. Nếu như việc Discovery không giúp xây dựng một điều gì đó khác biệt, loại bỏ một chức năng, hay thay đổi gì về timeline, thì bạn đã không Discovery, mà chỉ làm trên lý thuyết.	Việc discovery chỉ tạo ra giá trị khi việc học hỏi làm thay đổi rõ rệt các quyết định triển khai - những gì được xây dựng, bị trì hoãn hoặc bị dừng lại - thay vì chỉ tồn tại như một hoạt động nghiên cứu riêng lẻ.

​Đo lường Delivery

Đo lường	Lý do	Chi tiết
EBM - xu hướng Current Value	Outcomes quan trọng hơn outputs. Vứt bỏ checklist công việc đi: hoàn thành 100% kế hoạch vẫn thất bại nếu không đạt được bất kỳ % nào từ sự hài lòng của người dùng. Nếu road-map của bạn không thay đổi dựa trên dữ liệu của tuần trước, bạn sẽ không tạo ra được giá trị thực sự nào - bạn chỉ tỏ ra là mình có làm việc mà thôi (việc vô nghĩa).	Thành công của việc bàn giao được đo lường bằng tác động đến khách hàng và doanh nghiệp chứ không phải bằng việc hoàn thành các tính năng hoặc kế hoạch đã được xác định trước. Công việc phải được điều chỉnh trong quá trình học hỏi, phát triển để tối đa hóa giá trị.
Release thường xuyên	Đưa sản phẩm ra thị trường thường xuyên và chia thành các phần nhỏ. Phát hành sản phẩm thường xuyên bằng cách chia công việc thành những phần tăng trưởng nhỏ và ít rủi ro; bất kỳ thứ gì lớn hơn một tuần đều chứa đựng rủi ro và là một cuộc đánh cược.	Công việc được thực hiện theo từng giai đoạn nhỏ, sẵn sàng được sử dụng bởi người dùng, nhằm giảm thiểu rủi ro, đẩy nhanh phản hồi và cho phép học hỏi nhanh chóng từ việc sử dụng thực tế.
Tỉ lệ lỗi sau khi phát hành	Chất lượng nội tại. Nếu chất lượng kém ảnh hưởng đến hoạt động của sản phẩm, nó không được release. Xem technical debt và mức độ tin cậy về chất lượng như tính năng của sản phẩm. Nếu bạn bỏ qua chất lượng để đưa sản phẩm ra thị trường nhanh vào hôm nay, bạn chỉ đang tự đánh cắp năng lực của team vào tuần tới.	Việc delivery sản phẩm sẽ chưa được hoàn tất cho đến khi sản phẩm trở nên đáng tin cậy, có khả năng vận hành và dễ bảo trì. Chất lượng được đúc kết chặt chẽ vào bên trong sản phẩm chứ không phải đánh đổi lấy tốc độ.
Tính ổn định của chu kỳ	Hiệu suất của dòng chảy giá trị. Hãy dừng việc làm cho mọi người bận 100% và tập trung vào việc làm cho công việc được minh bạch 100%. Nếu mục tiêu nào đó chưa đạt được, hãy tập trung tìm ra chỗ tắc nghẽn và khắc phục trong workflow - tối ưu hóa lượng công việc. Việc đảm bảo ai cũng phải luôn có task chỉ làm cho hệ thống tắc nghẽn nhanh hơn.	Các hệ thống phát triển sản phẩm được tối ưu hóa để đảm bảo dòng chảy giá trị diễn ra suôn sẻ và có thể dự đoán được thay vì tối đa hóa mức độ sử dụng hoặc thông lượng. Hệ thống này tập trung vào việc liên tục giải quyết các điểm nghẽn.
Thời gian học sau mỗi lần release	Đưa sản phẩm đến tay người dùng để học. Dừng việc cung cấp câu trả lời mà hãy bắt đầu cung cấp câu hỏi trong những lần release. Nếu một sản phẩm được đưa đến tay người dùng mà bạn không có kế hoạch để đo lường nó như thế nào là thất bại hay thành công, bạn đang không cung cấp một sản phẩm mà bạn đang tạo ra điểm mù.	Mỗi lần giao hàng tạo ra bằng chứng mới, từ đó trực tiếp hỗ trợ quá trình Discovery, củng cố một vòng lặp inspect và adapt liên tục.

​Đo lường Support

Đo lường	Lý do	Chi tiết
Thời gian để sữa chữa	Hỗ trợ người dùng nằm trong quyền hạn của team sản phẩm. Loại bỏ rào cản rằng việc support chỉ là "tiêu sản": Nếu các yêu cầu hỗ trợ không được coi là yêu cầu trong lộ trình phát triển sản phẩm, sản phẩm của bạn đang thất bại trước mọi người. Công việc support của bạn là bản đồ chân thực duy nhất về Unrealized Value của sản phẩm - bỏ qua nó, bạn chỉ đang đốt tiền để đẩy khách hàng đi xa.	Support và Operations là những vấn đề cốt lõi của sản phẩm ảnh hưởng trực tiếp đến lòng tin của khách hàng, sự chấp nhận và giá trị lâu dài - chứ không phải là một trung tâm chỉ gây tốn chi phí vận hành riêng biệt.
% của roadmap thay đổi bởi dữ liệu vận hành	Vòng lặp phản hồi trong cơ chế vận hành. Nếu những công việc support của bạn không hỗ trợ hay ảnh hưởng đến việc bạn quyết định Sprint Backlog sắp tới, thì bạn không xây dựng sản phẩm, bạn chỉ xây dựng ảo tưởng. Mỗi lượt rời đi của khách hàng là "lời cảnh tỉnh" từ thị trường - tôn trọng tiếng nói của khách hàng hoặc sẽ mất họ.	Các sự cố, ticket hỗ trợ và thói quen sử dụng định hình các ưu tiên về discovery và delivery thay vì được coi là nhiễu loạn ở khâu xử lý tiếp theo.
Tính khả dụng của dịch vụ	Khả năng vận hành của sản phẩm phải được thiết kế từ đầu. Nếu bạn không thể thấy cách nó vận hành, bạn không nên phát hành nó. Hãy coi khả năng giám sát, đo lường từ xa và 'tự phục hồi' là những tính năng đầu tiên trong mọi lộ trình phát triển—nếu team không thể cảm nhận được tình trạng của sản phẩm, họ chỉ đang tạo ra một cục nợ.	Các sản phẩm được thiết kế với khả năng quan sát, độ tin cậy và khả năng phục hồi ngay từ đầu nhằm mục đích giảm thiểu rủi ro vận hành và gánh nặng nhận thức.
Tính liên tục về khả năng làm chủ	Trách nhiệm toàn diện từ đầu đến cuối của sản phẩm. Nếu bạn xây một mớ hỗn độn, bạn sẽ phải ở trong dó. Ngừng đổ trách nhiệm của team phát triển lên support team. Khi phủi tay với những vấn đề của sản phẩm đang live, xem đó là trách nhiệm của người khác, bạn tăng độ trễ của phản hồi từ người dùng và giết chết động lực để xây dựng sản phẩm một cách đúng đắn.	Các hệ thống phân phối sản phẩm được tối ưu hóa để đảm bảo dòng chảy giá trị trơn tru, không tắc nghẽn, có thể dự đoán được thay vì tối đa hóa số lượng công việc, liên tục giải quyết các điểm nghẽn.
Xu hướng của technical debt	Nếu công việc support của bạn không làm giảm technical debt, thì sản phẩm của bạn là một con tàu đang chìm. Mỗi lỗi vận hành là một khoản nợ chưa trả - bỏ qua nó hôm nay, và bạn sẽ phải chi 100% ngân sách ngày mai chỉ để cố gắng trụ vững.	Hỗ trợ hiệu quả ngăn ngừa technical debt chưa được quản lý và sự yếu kém trong hoạt động, bảo toàn khả năng đổi mới của tổ chức theo thời gian.

 

---

Những bài viết khác có thể bạn sẽ quan tâm