Đo lường năng suất lập trình viên: các ví dụ thực tế từ Google, Notion và nhiều công ty khác

xguru · 2024-01-22T11:06:01+09:00

Phân tích chuyên sâu về cách 17 công ty công nghệ như Google, LinkedIn, Peloton, Amplitude, Intercom, Notion và Postman đo lường năng suất lập trình viên 1. Các chỉ số năng suất lập trình viên tại 17 công ty công nghệ Việc đo lường năng suất lập trình viên là một bài toán phức tạp, vì bản thân ý nghĩa của việc "năng suất" trong kỹ nghệ phần mềm — một công việc dựa trên tri thức — vốn đã mơ hồ Các nhóm thường được gọi là nhóm năng suất lập trình viên (DevProd) hoặc trải nghiệm lập trình viên (DevEx) hỗ trợ để lập trình viên có thể dễ dàng triển khai phần mềm chất lượng cao Các nhóm này cần chỉ số năng suất lập trình viên để đo năng suất và các yếu tố cản trở của đội ngũ kỹ thuật, đồng thời theo dõi xem công việc của họ có thực sự tạo ra tác động hay không Các chỉ số năng suất lập trình viên được những công ty này sử dụng Mức độ dễ dàng khi delivery (Amplitude, GoodRx, Intercom, Postman, Lattice) Tốc độ thử nghiệm (Etsy) Độ ổn định của dịch vụ/ứng dụng (DoorDash) Chỉ số SPACE (Microsoft) Thời gian tập trung hàng tuần trên mỗi kỹ sư (Uber) Chọn 4 công ty theo quy mô công ty Google: hơn 100.000 nhân viên LinkedIn: hơn 10.000 Peloton: từ 1.000 đến dưới 10.000 Scale-up (từ 100 đến dưới 1.000 kỹ sư): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice 2. Cách tiếp cận của Google Google thường được nhắc đến như một hình mẫu về đo lường năng suất lập trình viên, nhưng cũng có ý kiến cho rằng hầu hết các công ty không thể sao chép mức đầu tư như Google Nhóm Developer Intelligence của Google là một bộ phận chuyên trách đo lường năng suất lập trình viên và cung cấp insight cho lãnh đạo Google tin rằng không có một chỉ số đơn lẻ nào có thể nắm bắt được năng suất, và nhìn nhận năng suất qua ba chiều: tốc độ, mức độ dễ dàng, chất lượng Speed tốc độ: Mất bao lâu để hoàn tất một code review? Ease mức độ dễ dàng: Việc đi qua quy trình code review dễ hay khó đối với lập trình viên đến mức nào? Quality chất lượng: Chất lượng phản hồi nhận được qua code review ở mức nào? Google kết hợp cả phép đo định tính và định lượng để tính toán chỉ số 3. LinkedIn LinkedIn hoạt động độc lập trong Microsoft và có hơn 10.000 nhân viên LinkedIn có nhóm Developer Insights để đo lường năng suất và mức độ hài lòng của lập trình viên, đồng thời chuyển tải insight tới phần còn lại của tổ chức LinkedIn thu thập chỉ số bằng khảo sát hàng quý, hệ thống phản hồi thời gian thực và các chỉ số dựa trên hệ thống Khảo sát hàng quý: Nhóm Developer Insights đánh giá trải nghiệm lập trình viên trên nhiều công cụ, quy trình và hoạt động thông qua khảo sát hàng quý Khảo sát gồm khoảng 30 câu hỏi và lập trình viên có thể trả lời trong khoảng 10 phút Khảo sát được cung cấp thông qua một nền tảng độc quyền do nhóm Developer Insights phát triển và vận hành; các câu hỏi có thể được tùy biến và cá nhân hóa ở mức cao dựa trên dữ liệu thu thập từ hệ thống phản hồi thời gian thực và hệ thống chỉ số Hệ thống phản hồi thời gian thực: Để thu thập phản hồi giữa các đợt khảo sát hàng quý, LinkedIn đã phát triển một hệ thống phản hồi thời gian thực theo dõi các sự kiện và thao tác mà lập trình viên thực hiện trong công cụ phát triển, rồi gửi khảo sát mục tiêu dựa trên các trigger cụ thể Hệ thống này dùng cơ chế smart throttling để tránh dồn quá nhiều yêu cầu phản hồi tới lập trình viên Chỉ số dựa trên hệ thống: LinkedIn cũng dùng dữ liệu hệ thống để tính chỉ số, cung cấp phép đo có độ chính xác cao cho các mục như thời gian build và tần suất triển khai Nhóm Developer Insights duy trì một hệ thống toàn cục để thu thập và phân tích dữ liệu này, gọi là developer insights hub (hay iHub) Thông qua hệ thống này, mọi nhóm tại LinkedIn đều có thể tạo dashboard và metric tùy chỉnh phù hợp với nhu cầu riêng LinkedIn xem xét cả chỉ số định tính và định lượng Mức độ hài lòng ròng của người dùng là lập trình viên (Developer Net User Satisfaction, NSAT): đo mức độ hài lòng tổng thể của lập trình viên với các hệ thống phát triển của LinkedIn. Được đo theo quý Thời gian build của lập trình viên (Developer Build Time, P50 và P90): đo bằng giây khoảng thời gian lập trình viên chờ build hoàn tất trên máy cục bộ trong quá trình phát triển Thời gian phản hồi của người review code (Code Reviewer Response Time, P50 và P90): đo khoảng thời gian (theo giờ làm việc) để người review phản hồi cho mỗi cập nhật code review từ tác giả Tốc độ CI sau commit (Post-Commit CI Speed, P50 và P90): đo bằng phút thời gian mỗi commit đi qua pipeline tích hợp liên tục (CI) Tính quyết định của CI (CI Determinism): khái niệm đối lập với độ lỗi của test. Nghĩa là xác suất kết quả của test suite là hợp lệ chứ không phải lỗi Tỷ lệ triển khai thành công (Deployment Success Rate): đo mức độ thường xuyên mà việc triển khai lên production thành công Winsorized Means: cách nhận diện cải thiện trong các metric có ngoại lệ. Tính bằng cách thay giá trị cao nhất và thấp nhất bằng các con số gần trung tâm hơn Chỉ số trải nghiệm lập trình viên (The Developer Experience Index): một chỉ số đặc biệt LinkedIn cung cấp cho các đội. Đây là điểm tổng hợp dựa trên nhiều metric như các chỉ số đã liệt kê ở trên 4. Peloton Peloton là một công ty lớn với khoảng 3.000-4.000 nhân viên, nhưng vẫn nhỏ hơn LinkedIn rất nhiều Cách tiếp cận đo lường của Peloton bắt đầu từ việc lấy insight định tính thông qua khảo sát trải nghiệm lập trình viên, sau đó kết hợp với các chỉ số định lượng. Peloton đo năng suất với trọng tâm là bốn lĩnh vực chính: mức độ gắn kết, tốc độ, chất lượng, độ ổn định Engagement: điểm hài lòng của lập trình viên Velocity: thời gian đến PR đầu tiên và PR thứ 10 của mọi nhân viên mới, lead time, tần suất triển khai Quality: tỷ lệ PR dưới 250 dòng, line coverage, tỷ lệ thất bại khi thay đổi Stability: thời gian khôi phục dịch vụ Khảo sát trải nghiệm lập trình viên — công cụ đo lường nhiều phần trong các metric này — do đội hỗ trợ kỹ thuật và trải nghiệm lập trình viên của Peloton, thuộc tổ chức vận hành sản phẩm, dẫn dắt Đội hỗ trợ kỹ thuật và trải nghiệm lập trình viên cũng chịu trách nhiệm phân tích kết quả khảo sát và chia sẻ với lãnh đạo trên toàn tổ chức 5. Các công ty scale-up và nhỏ hơn Nhiều công ty scale-up như Notion, Postman, Amplitude, GoodRx, Intercom và Lattice có từ 100 đến 1.000 kỹ sư Các công ty này tập trung vào "moveable metrics" Moveable metrics là những chỉ số mà đội năng suất lập trình viên có thể "dịch chuyển" bằng cách tạo tác động tích cực hoặc tiêu cực lên công việc. Chúng hữu ích để đội năng suất lập trình viên chứng minh ảnh hưởng của mình Các chỉ số phổ biến Mức độ dễ dàng khi delivery (Ease of Delivery, moveable): Hầu hết các công ty đo mức độ dễ hay khó mà lập trình viên cảm nhận khi hoàn thành công việc, một thước đo định tính về mức độ dễ dàng trong delivery Nhiều lãnh đạo DevProd cho biết họ xem đây là "ngôi sao Bắc Cực" cho công việc của đội, vì mục tiêu của đội là làm cho cuộc sống của lập trình viên dễ chịu hơn Chỉ số này cũng hữu ích để thể hiện tác động vì nó khá dễ dịch chuyển Từ góc độ lý thuyết, chỉ số này còn nắm bắt những khía cạnh quan trọng của trải nghiệm lập trình viên như tải nhận thức và feedback loop Mức độ gắn kết (Engagement) Theo dõi mức độ gắn kết, tức mức độ mà lập trình viên thấy hứng thú và được kích thích với công việc Thông thường HR đo mức độ gắn kết trong các khảo sát engagement, nhưng các đội DevProd cũng tập trung vào nó vì lý do này Mức độ gắn kết của lập trình viên và năng suất có liên hệ chặt chẽ. Nói cách khác, giống như câu "lập trình viên hạnh phúc là lập trình viên năng suất", mức độ gắn kết có thể được xem là một chỉ dấu của năng suất Lợi ích thực sự của việc đo engagement là có thể cân bằng với các chỉ số khác nhấn mạnh vào tốc độ. Việc giao phần mềm nhanh hơn là tốt, nhưng không nên đánh đổi bằng sự sụt giảm hạnh phúc của lập trình viên Thời gian thất thoát (Time Loss, moveable) GoodRx và Postman chú ý tới lượng thời gian thất thoát trung bình Chỉ số này được đo bằng tỷ lệ thời gian của lập trình viên bị mất do các trở ngại trong môi trường làm việc Nó tương tự Ease of Delivery ở chỗ cung cấp một moveable metric mà đội phát triển có thể tác động trực tiếp tới Một lợi thế lớn là có thể quy đổi ra chi phí, vì vậy lãnh đạo doanh nghiệp rất dễ hiểu time loss Ví dụ, nếu một tổ chức có chi phí nhân sự kỹ thuật là 10 triệu USD và một sáng kiến giúp giảm time loss từ 20% xuống 10%, điều đó tương đương tiết kiệm 1 triệu USD Tỷ lệ thất bại khi thay đổi (Change Failure Rate) Đây là một trong bốn chỉ số cốt lõi của chương trình nghiên cứu DORA (DevOps Research and Assessment) Là chỉ số cấp cao được nhiều công ty như Amplitude và Lattice theo dõi Nhóm DORA định nghĩa tỷ lệ thất bại khi thay đổi như sau: "Tỷ lệ các thay đổi phát hành lên production hoặc tới người dùng gây suy giảm dịch vụ (ví dụ: sự cố dịch vụ hoặc gián đoạn dịch vụ) và sau đó cần được khắc phục (ví dụ: cần hotfix, rollback, fix-forward hoặc patch)" 6. Những phát hiện thú vị DORA và SPACE được sử dụng có chọn lọc, và mọi công ty đều dùng cả phép đo định tính lẫn định lượng DORA: DevOps Research and Assessment SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow Có sự nhấn mạnh lớn vào "thời gian tập trung", và Stripe cùng Uber chia sẻ các metric cụ thể như "số ngày có đủ thời gian tập trung" và "thời gian tập trung hàng tuần trên mỗi kỹ sư" Một số chỉ số độc đáo Adoption Rate (DoorDash, GoodRx, Spotify) Design Docs Generated per Engineer (Uber) Experiment Velocity (Etsy) Developer CSAT/NSAT (Chime, LinkedIn) 7. Cách chọn chỉ số của riêng bạn Nên dùng framework Goals, Signals, Metrics (GSM) của Google để định hướng việc chọn chỉ số Hãy định nghĩa trước mục tiêu muốn giải quyết, tìm các tín hiệu cho biết bạn đã đạt được mục tiêu đó, rồi chọn các chỉ số phù hợp Định nghĩa mục tiêu Google: "Hỗ trợ lập trình viên có thể cung cấp sản phẩm tuyệt vời một cách nhanh chóng và dễ dàng." Slack: "Cung cấp môi trường phát triển mượt mà cho mọi kỹ sư." Stripe: "Làm cho kỹ nghệ phần mềm trở nên dễ dàng hơn." Đi ngược từ mục tiêu để xác định các chỉ số cấp cao Lập trình viên giao phần mềm dễ đến mức nào? (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate Lập trình viên giao phần mềm nhanh đến đâu? (Speed): Perceived Delivery Speed, Perceived Productivity Chất lượng của phần mềm được cung cấp (Quality): Incident frequency, Perceived Software Quality Nếu bạn là CTO, VPE hay engineering lead Lời khuyên tốt nhất là "định khung lại vấn đề" (reframe the problem) Hãy chọn chỉ số từ ba bucket Tác động kinh doanh Vì sao cần xây dựng điều này ngay bây giờ? Dự án này tạo doanh thu hoặc hỗ trợ mục tiêu kinh doanh theo cách nào? Dự án này đang diễn ra suôn sẻ hay bị chậm trễ? Hiệu năng hệ thống Hệ thống kỹ thuật có nhanh và ổn định không? Hạ tầng có an toàn và được bảo trì tốt không? Người dùng có hài lòng với dịch vụ họ sử dụng không? Hiệu quả kỹ thuật Việc đo lường bằng cách trộn cả chỉ số định tính và định lượng là điểm chung ở mọi công ty Hãy lấy cảm hứng từ các hạng mục đo lường đa dạng mà mỗi công ty sử dụng Tùy theo ưu tiên và văn hóa kỹ thuật của từng công ty mà các hạng mục được tập trung đo sẽ khác nhau rất lớn

(newsletter.pragmaticengineer.com)

53 điểm bởi xguru 2024-01-22 | 1 bình luận | Chia sẻ qua WhatsApp

Phân tích chuyên sâu về cách 17 công ty công nghệ như Google, LinkedIn, Peloton, Amplitude, Intercom, Notion và Postman đo lường năng suất lập trình viên

1. Các chỉ số năng suất lập trình viên tại 17 công ty công nghệ

Việc đo lường năng suất lập trình viên là một bài toán phức tạp, vì bản thân ý nghĩa của việc "năng suất" trong kỹ nghệ phần mềm — một công việc dựa trên tri thức — vốn đã mơ hồ
Các nhóm thường được gọi là nhóm năng suất lập trình viên (DevProd) hoặc trải nghiệm lập trình viên (DevEx) hỗ trợ để lập trình viên có thể dễ dàng triển khai phần mềm chất lượng cao
Các nhóm này cần chỉ số năng suất lập trình viên để đo năng suất và các yếu tố cản trở của đội ngũ kỹ thuật, đồng thời theo dõi xem công việc của họ có thực sự tạo ra tác động hay không
Các chỉ số năng suất lập trình viên được những công ty này sử dụng
- Mức độ dễ dàng khi delivery (Amplitude, GoodRx, Intercom, Postman, Lattice)
- Tốc độ thử nghiệm (Etsy)
- Độ ổn định của dịch vụ/ứng dụng (DoorDash)
- Chỉ số SPACE (Microsoft)
- Thời gian tập trung hàng tuần trên mỗi kỹ sư (Uber)
Chọn 4 công ty theo quy mô công ty
- Google: hơn 100.000 nhân viên
- LinkedIn: hơn 10.000
- Peloton: từ 1.000 đến dưới 10.000
- Scale-up (từ 100 đến dưới 1.000 kỹ sư): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice

2. Cách tiếp cận của Google

Google thường được nhắc đến như một hình mẫu về đo lường năng suất lập trình viên, nhưng cũng có ý kiến cho rằng hầu hết các công ty không thể sao chép mức đầu tư như Google
Nhóm Developer Intelligence của Google là một bộ phận chuyên trách đo lường năng suất lập trình viên và cung cấp insight cho lãnh đạo
Google tin rằng không có một chỉ số đơn lẻ nào có thể nắm bắt được năng suất, và nhìn nhận năng suất qua ba chiều: tốc độ, mức độ dễ dàng, chất lượng
- Speed tốc độ: Mất bao lâu để hoàn tất một code review?
- Ease mức độ dễ dàng: Việc đi qua quy trình code review dễ hay khó đối với lập trình viên đến mức nào?
- Quality chất lượng: Chất lượng phản hồi nhận được qua code review ở mức nào?
Google kết hợp cả phép đo định tính và định lượng để tính toán chỉ số

3. LinkedIn

LinkedIn hoạt động độc lập trong Microsoft và có hơn 10.000 nhân viên
LinkedIn có nhóm Developer Insights để đo lường năng suất và mức độ hài lòng của lập trình viên, đồng thời chuyển tải insight tới phần còn lại của tổ chức
LinkedIn thu thập chỉ số bằng khảo sát hàng quý, hệ thống phản hồi thời gian thực và các chỉ số dựa trên hệ thống
- Khảo sát hàng quý:
  - Nhóm Developer Insights đánh giá trải nghiệm lập trình viên trên nhiều công cụ, quy trình và hoạt động thông qua khảo sát hàng quý
  - Khảo sát gồm khoảng 30 câu hỏi và lập trình viên có thể trả lời trong khoảng 10 phút
  - Khảo sát được cung cấp thông qua một nền tảng độc quyền do nhóm Developer Insights phát triển và vận hành; các câu hỏi có thể được tùy biến và cá nhân hóa ở mức cao dựa trên dữ liệu thu thập từ hệ thống phản hồi thời gian thực và hệ thống chỉ số
- Hệ thống phản hồi thời gian thực:
  - Để thu thập phản hồi giữa các đợt khảo sát hàng quý, LinkedIn đã phát triển một hệ thống phản hồi thời gian thực theo dõi các sự kiện và thao tác mà lập trình viên thực hiện trong công cụ phát triển, rồi gửi khảo sát mục tiêu dựa trên các trigger cụ thể
  - Hệ thống này dùng cơ chế smart throttling để tránh dồn quá nhiều yêu cầu phản hồi tới lập trình viên
- Chỉ số dựa trên hệ thống:
  - LinkedIn cũng dùng dữ liệu hệ thống để tính chỉ số, cung cấp phép đo có độ chính xác cao cho các mục như thời gian build và tần suất triển khai
  - Nhóm Developer Insights duy trì một hệ thống toàn cục để thu thập và phân tích dữ liệu này, gọi là developer insights hub (hay iHub)
  - Thông qua hệ thống này, mọi nhóm tại LinkedIn đều có thể tạo dashboard và metric tùy chỉnh phù hợp với nhu cầu riêng
LinkedIn xem xét cả chỉ số định tính và định lượng
- Mức độ hài lòng ròng của người dùng là lập trình viên (Developer Net User Satisfaction, NSAT): đo mức độ hài lòng tổng thể của lập trình viên với các hệ thống phát triển của LinkedIn. Được đo theo quý
- Thời gian build của lập trình viên (Developer Build Time, P50 và P90): đo bằng giây khoảng thời gian lập trình viên chờ build hoàn tất trên máy cục bộ trong quá trình phát triển
- Thời gian phản hồi của người review code (Code Reviewer Response Time, P50 và P90): đo khoảng thời gian (theo giờ làm việc) để người review phản hồi cho mỗi cập nhật code review từ tác giả
- Tốc độ CI sau commit (Post-Commit CI Speed, P50 và P90): đo bằng phút thời gian mỗi commit đi qua pipeline tích hợp liên tục (CI)
- Tính quyết định của CI (CI Determinism): khái niệm đối lập với độ lỗi của test. Nghĩa là xác suất kết quả của test suite là hợp lệ chứ không phải lỗi
- Tỷ lệ triển khai thành công (Deployment Success Rate): đo mức độ thường xuyên mà việc triển khai lên production thành công
- Winsorized Means: cách nhận diện cải thiện trong các metric có ngoại lệ. Tính bằng cách thay giá trị cao nhất và thấp nhất bằng các con số gần trung tâm hơn
- Chỉ số trải nghiệm lập trình viên (The Developer Experience Index): một chỉ số đặc biệt LinkedIn cung cấp cho các đội. Đây là điểm tổng hợp dựa trên nhiều metric như các chỉ số đã liệt kê ở trên

4. Peloton

Peloton là một công ty lớn với khoảng 3.000-4.000 nhân viên, nhưng vẫn nhỏ hơn LinkedIn rất nhiều
Cách tiếp cận đo lường của Peloton bắt đầu từ việc lấy insight định tính thông qua khảo sát trải nghiệm lập trình viên, sau đó kết hợp với các chỉ số định lượng.
Peloton đo năng suất với trọng tâm là bốn lĩnh vực chính: mức độ gắn kết, tốc độ, chất lượng, độ ổn định
- Engagement: điểm hài lòng của lập trình viên
- Velocity: thời gian đến PR đầu tiên và PR thứ 10 của mọi nhân viên mới, lead time, tần suất triển khai
- Quality: tỷ lệ PR dưới 250 dòng, line coverage, tỷ lệ thất bại khi thay đổi
- Stability: thời gian khôi phục dịch vụ
Khảo sát trải nghiệm lập trình viên — công cụ đo lường nhiều phần trong các metric này — do đội hỗ trợ kỹ thuật và trải nghiệm lập trình viên của Peloton, thuộc tổ chức vận hành sản phẩm, dẫn dắt
Đội hỗ trợ kỹ thuật và trải nghiệm lập trình viên cũng chịu trách nhiệm phân tích kết quả khảo sát và chia sẻ với lãnh đạo trên toàn tổ chức

5. Các công ty scale-up và nhỏ hơn

Nhiều công ty scale-up như Notion, Postman, Amplitude, GoodRx, Intercom và Lattice có từ 100 đến 1.000 kỹ sư
Các công ty này tập trung vào "moveable metrics"
- Moveable metrics là những chỉ số mà đội năng suất lập trình viên có thể "dịch chuyển" bằng cách tạo tác động tích cực hoặc tiêu cực lên công việc. Chúng hữu ích để đội năng suất lập trình viên chứng minh ảnh hưởng của mình
Các chỉ số phổ biến
- Mức độ dễ dàng khi delivery (Ease of Delivery, moveable):
  - Hầu hết các công ty đo mức độ dễ hay khó mà lập trình viên cảm nhận khi hoàn thành công việc, một thước đo định tính về mức độ dễ dàng trong delivery
  - Nhiều lãnh đạo DevProd cho biết họ xem đây là "ngôi sao Bắc Cực" cho công việc của đội, vì mục tiêu của đội là làm cho cuộc sống của lập trình viên dễ chịu hơn
  - Chỉ số này cũng hữu ích để thể hiện tác động vì nó khá dễ dịch chuyển
  - Từ góc độ lý thuyết, chỉ số này còn nắm bắt những khía cạnh quan trọng của trải nghiệm lập trình viên như tải nhận thức và feedback loop
- Mức độ gắn kết (Engagement)
  - Theo dõi mức độ gắn kết, tức mức độ mà lập trình viên thấy hứng thú và được kích thích với công việc
  - Thông thường HR đo mức độ gắn kết trong các khảo sát engagement, nhưng các đội DevProd cũng tập trung vào nó vì lý do này
  - Mức độ gắn kết của lập trình viên và năng suất có liên hệ chặt chẽ. Nói cách khác, giống như câu "lập trình viên hạnh phúc là lập trình viên năng suất", mức độ gắn kết có thể được xem là một chỉ dấu của năng suất
  - Lợi ích thực sự của việc đo engagement là có thể cân bằng với các chỉ số khác nhấn mạnh vào tốc độ. Việc giao phần mềm nhanh hơn là tốt, nhưng không nên đánh đổi bằng sự sụt giảm hạnh phúc của lập trình viên
- Thời gian thất thoát (Time Loss, moveable)
  - GoodRx và Postman chú ý tới lượng thời gian thất thoát trung bình
  - Chỉ số này được đo bằng tỷ lệ thời gian của lập trình viên bị mất do các trở ngại trong môi trường làm việc
  - Nó tương tự Ease of Delivery ở chỗ cung cấp một moveable metric mà đội phát triển có thể tác động trực tiếp tới
  - Một lợi thế lớn là có thể quy đổi ra chi phí, vì vậy lãnh đạo doanh nghiệp rất dễ hiểu time loss
  - Ví dụ, nếu một tổ chức có chi phí nhân sự kỹ thuật là 10 triệu USD và một sáng kiến giúp giảm time loss từ 20% xuống 10%, điều đó tương đương tiết kiệm 1 triệu USD
- Tỷ lệ thất bại khi thay đổi (Change Failure Rate)
  - Đây là một trong bốn chỉ số cốt lõi của chương trình nghiên cứu DORA (DevOps Research and Assessment)
  - Là chỉ số cấp cao được nhiều công ty như Amplitude và Lattice theo dõi
  - Nhóm DORA định nghĩa tỷ lệ thất bại khi thay đổi như sau:
  "Tỷ lệ các thay đổi phát hành lên production hoặc tới người dùng gây suy giảm dịch vụ (ví dụ: sự cố dịch vụ hoặc gián đoạn dịch vụ) và sau đó cần được khắc phục (ví dụ: cần hotfix, rollback, fix-forward hoặc patch)"

6. Những phát hiện thú vị

DORA và SPACE được sử dụng có chọn lọc, và mọi công ty đều dùng cả phép đo định tính lẫn định lượng
- DORA: DevOps Research and Assessment
- SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
Có sự nhấn mạnh lớn vào "thời gian tập trung", và Stripe cùng Uber chia sẻ các metric cụ thể như "số ngày có đủ thời gian tập trung" và "thời gian tập trung hàng tuần trên mỗi kỹ sư"
Một số chỉ số độc đáo
- Adoption Rate (DoorDash, GoodRx, Spotify)
- Design Docs Generated per Engineer (Uber)
- Experiment Velocity (Etsy)
- Developer CSAT/NSAT (Chime, LinkedIn)

7. Cách chọn chỉ số của riêng bạn

Nên dùng framework Goals, Signals, Metrics (GSM) của Google để định hướng việc chọn chỉ số
Hãy định nghĩa trước mục tiêu muốn giải quyết, tìm các tín hiệu cho biết bạn đã đạt được mục tiêu đó, rồi chọn các chỉ số phù hợp
- Định nghĩa mục tiêu
  - Google: "Hỗ trợ lập trình viên có thể cung cấp sản phẩm tuyệt vời một cách nhanh chóng và dễ dàng."
  - Slack: "Cung cấp môi trường phát triển mượt mà cho mọi kỹ sư."
  - Stripe: "Làm cho kỹ nghệ phần mềm trở nên dễ dàng hơn."
- Đi ngược từ mục tiêu để xác định các chỉ số cấp cao
  - Lập trình viên giao phần mềm dễ đến mức nào? (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate
  - Lập trình viên giao phần mềm nhanh đến đâu? (Speed): Perceived Delivery Speed, Perceived Productivity
  - Chất lượng của phần mềm được cung cấp (Quality): Incident frequency, Perceived Software Quality
Nếu bạn là CTO, VPE hay engineering lead
- Lời khuyên tốt nhất là "định khung lại vấn đề" (reframe the problem)
- Hãy chọn chỉ số từ ba bucket
  - Tác động kinh doanh
    - Vì sao cần xây dựng điều này ngay bây giờ?
    - Dự án này tạo doanh thu hoặc hỗ trợ mục tiêu kinh doanh theo cách nào?
    - Dự án này đang diễn ra suôn sẻ hay bị chậm trễ?
  - Hiệu năng hệ thống
    - Hệ thống kỹ thuật có nhanh và ổn định không?
    - Hạ tầng có an toàn và được bảo trì tốt không?
    - Người dùng có hài lòng với dịch vụ họ sử dụng không?
  - Hiệu quả kỹ thuật
Việc đo lường bằng cách trộn cả chỉ số định tính và định lượng là điểm chung ở mọi công ty
- Hãy lấy cảm hứng từ các hạng mục đo lường đa dạng mà mỗi công ty sử dụng
- Tùy theo ưu tiên và văn hóa kỹ thuật của từng công ty mà các hạng mục được tập trung đo sẽ khác nhau rất lớn

1 bình luận

demorier 2024-01-24

Tôi đã quan tâm từ bài viết trước về McKinsey, nên rất vui vì lần này được tóm tắt và nhắc lại.