[EBM] Ví dụ về Key Value Measures

Khi áp dụng Scrum việc đo lường luôn là một câu hỏi lớn. Cần đo lường những tiêu chí gì để biết Scrum team đang làm tốt, và cần cải tiến những gì?

Key Value Measures

​Khi viết loạt bài về EVIDENCE-BASED MANAGEMENT. Tôi có trình bày qua bốn vùng giá trị cốt lõi (Key Value Areas) cần được tối ưu và đo lường là:

Current Value (CV)
Time-to-Market (T2M)
Ability to Innovate (A2I)
Unrealized Value (UV)

Bạn có thể nhấn vào link trên để xem qua định nghĩa về 4 vùng giá trị. Còn trong bài này tôi xin giới thiệu qua những ví dụ trực quan về những giá trị nào nên được đo lường trong bốn vùng CV, T2M, A2L và UV, để đảm bảo được nhóm đang phát huy được giá trị của Scrum/ Agile mang lại.

​
Current Value (CV)
​

• ​Revenue per Employee: Là tỉ lệ (Tổng doanh thu/ # số lượng nhân viên) là tỉ số cạnh tranh quan trọng trong ngành. Chỉ số này thay đổi tuỳ theo ngành.
• ​Product Cost Ratio: Tổng chi phí hoạt động, bao gồm chi phí duy trì sản phẩm được đo lường và chi phí cho hoạt động của tổ chức so với doanh thu.
• ​Employee Satisfaction: Bao gồm một số phương thức đánh giá, cảm xúc, tình cảm của nhân viên, mức năng lượng v.v.
• ​Customer Satisfaction: Một vài phương thức đánh giá cảm xúc của khách hàng để biết được mức độ hạnh phúc sản phẩm của họ.
• ​Customer Usage Index: Đo lường mức độ sử dụng theo tính năng. Để giúp suy ra mức độ sử dụng của khách hàng qua đó đánh giá được khách hàng có thấy sản phẩm hữu ích, và việc sử dụng tính năng đó có giúp ích hay không?

Time-to-Market (T2M)

• ​Build and integration frequency: Số lượng của những lần tích hợp hay hoàn thành thử nghiệm trong một khoản thời gian. Hay là đo lường khả năng phát hành (ở giai đoạn sẵn sàng ra thị trường) thường xuyên và liên tục của nhóm. Có thể được thay thế bằng đo lường việc phát hành thực tế ra thị trường.
  
• ​Release Frequency: Số lần release ra thị trường: hàng ngày, hàng tháng, hàng quý v.v điều này giúp phản ánh được thời gian đợi cần thiết để phục vụ hay chiều lòng khách hàng so với sản phẩm cạnh tranh.
  
• ​Release Stabilization Period: Khoản cách thời gian để sửa chữa các vấn đề của sản phẩm, tính từ lúc nhóm phát triển báo về việc sẵn sàng để release cho đến khi sản phẩm hay chức năng đó được thực sự release tới tay người dùng.
  
• ​Mean Time to Repair: Là thời gian trung bình kể từ khi phát triển ra lỗi cho đến khi nó được sửa. Đo lường điều này sẽ giúp cho tổ chức hiểu được khả năng sửa một sai lầm, hay team sửa một lỗi của sản phẩm.
  
• ​​Cycle Time: Là thời gian kể từ khi bắt đầu công việc cho đến khi sản phẩm hay chức năng đó thực sự đến tay của khách hàng. Đây là con số để tổ chức biết được khả năng tiếp cận khách hàng của mình.
  
• ​Lead Time: Là thời gian kể từ khi ý tưởng được hình thành cho đến lúc khách hàng được hưởng lợi từ ý tưởng đó. Điều này thay đổi bởi khách hàng và sản phẩm khác nhau. Và đây là nhân tố góp phần vào sự hài lòng của khách hàng.​
  
• ​Time-to-Learn: Tổng thời gian tính cho việc, phác thảo nháp, lên ý tưởng, xây dựng, phát hành ra thị trường, và học từ những feedback.

​Ability to Innovate (A2I)

• ​​Feature Usage Index: Đo lường các tính năng được sử dụng, điều nay giúp nhận ra được các tính năng hiếm khi được sử dụng.
• ​​Innovation Rate: Phần trăm của nổ lực hay chi phí dành cho sản phẩm mới. chia cho tổng nỗ lực hay chi phí. Điều này giúp có một cái nhìn rõ về năng lực của tổ chức trong việc cung cấp sản phẩm hay chức năng mới.
• ​​Defect trends: ​Đo lường thay đổi của lỗi hay những chức năng sản phẩm hoạt động không như mong đợi làm giảm giá trị của sản phẩm với khách hàng, người dùng hoặc cho chính tổ chức.
• ​​On-Product Index: Phần trăm thời gian các nhóm làm việc trên sản phẩm để tạo giá trị thặng dư.
• ​​Installed Version Index: Số lượng phiên bản của sản phẩm đang được người dùng sử dụng. Điều này giúp đánh giá chi phí và nỗ lực của tổ chức để duy trì những phiên bản của sản phẩm.
• ​​Technical Debt: Đây là một khái niệm trong lập trình, phản ánh những hao tổn sẽ phải trả thêm khi thực hiện những giải pháp "quick and dirty" và phải khắc phục sau đó. Nó tạo ra một tác động không mong muốn và khó lường cho việc deliver giá trị sản phẩm, tăng rủi ro không mong đợi.
• ​​Production Incident Trends: Số lần nhóm bị ảnh hưởng bởi việc phải sửa lỗi của sản phẩm đã phát hành. Số lượng và tầng suất của sự cố chỉ ra mức độ ổn định của sản phẩm.
• ​Active code branches, time spent merging code between branches: Đo thời gian làm việc giữa các nhánh của code. Vì khi có nhiều version, thì thời gian này càng tăng.
• ​​Time spent context switching: Số lượng cuộc họp mỗi ngày của mỗi người, và số thời gian nhóm bị làm gián đoạn cho việc giúp những người bên ngoài team, Đo lường điều này sẽ giúp có cái nhìn sâu sắc hơn về việc phân chia sức của nhóm. 

​
Unrealized Value (UV)

• ​​Market Share: Tỉ lệ tương đối của thị trường được kiểm soát bởi sản phẩm.​
• ​Customer or user satisfaction gap: Sự khác biệt giữa mong muốn thực của người dùng và kinh nghiệm hiện tại của họ.
  

​

 

---

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