Bạn quản lý nhóm tốt nhất của công ty: thời gian chu kỳ nhanh nhất, độ chính xác của kế hoạch cao nhất và số lượng công việc phải làm lại ít nhất. Nhóm của bạn có thời gian xem xét thấp nhất, triển khai hàng tuần nhiều nhất và tỷ lệ lỗi/KLOC tốt nhất. Và sau đó ai đó ở cấp cao tắt dự án của bạn - chuyện gì vừa xảy ra vậy?

Nghịch lý đầu ra

Là một nhà phát triển cơ sở, tôi đã được dạy rằng việc hợp nhất các thay đổi nhỏ thường xuyên là chìa khóa để mang lại giá trị nhanh chóng. Là một nhà quản lý kỹ thuật cấp dưới, tôi được cho biết rằng việc theo dõi và tối ưu hóa các chỉ số là rất quan trọng đối với công việc của người quản lý. Kết quả đầu tiên của Google chỉ cho tôi một loạt các thuật ngữ và từ viết tắt, và đây là những giới thiệu đầu tiên của tôi về các chỉ số dành cho nhà phát triển.

Các chỉ số dành cho nhà phát triển về cơ bản là một tập hợp các chỉ số giúp các nhóm kỹ thuật theo dõi tốc độ của họ (di chuyển nhanh) và chất lượng (mà không làm hỏng mọi thứ). Các số liệu khác nhau có thể được sử dụng để đo lường các thuộc tính này. Thời gian chu kỳ, số lượng PR hoặc tốc độ theo dõi các sự cố đã đóng. Để theo dõi chất lượng, hãy theo dõi số lượng lỗi, thời gian giải quyết trung bình hoặc số lần triển khai gây ra lỗi. Mỗi chỉ số này sẽ cung cấp thông tin chi tiết khác nhau về thuộc tính mà bạn kiểm tra. Một số chỉ số cũng giúp phân tích các thuộc tính proxy. Theo dõi công việc làm lại để phân tích hiệu quả, tác động đến vận tốc. Độ chính xác của kế hoạch là một chỉ số tốt về khả năng dự đoán, cho phép cả tốc độ và chất lượng và có giá trị riêng.

Vấn đề với tất cả các chỉ số trên là mặc dù chúng thực hiện rất tốt công việc đo lường hiệu quả, nhưng chúng thường không đủ để đo lường thành công. Lý do chính là chúng hoàn toàn bị ngắt kết nối với KPI của doanh nghiệp (chỉ số hiệu suất chính, một tên gọi ưa thích khác của số liệu). Sự ngắt kết nối này thường dẫn đến việc giao tiếp không hiệu quả giữa các tổ chức trong công ty, chủ yếu là sản phẩm và kỹ thuật. Xét cho cùng, tổ chức sản phẩm (và phần còn lại của doanh nghiệp) không chỉ quan tâm đến vận tốc hoặc chất lượng, vì chúng theo dõi đầu ra . Tổ chức sản phẩm thường quan tâm đến kết quả - tính năng mới của chúng tôi đã tạo ra doanh thu gì? Chúng tôi đã thu hút được bao nhiêu người dùng mới?

Là một giám đốc kỹ thuật mới, điều này thật khó hiểu với tôi. Một mặt, rõ ràng là việc tiếp tục đo lường nhóm của tôi dựa trên chỉ số nhà phát triển thay vì chỉ số kinh doanh sẽ dẫn đến sự sai lệch với nhóm sản phẩm. Mặt khác, có vẻ không công bằng khi đo lường nhóm của tôi dựa trên các chỉ số kinh doanh: Họ có thể tác động đến họ như thế nào? Đó có phải là công việc của chúng tôi? Liệu tôi có đang giẫm lên chân tổ chức sản phẩm không?

Đo lường những gì quan trọng

Tôi đã có một bước nhảy vọt về niềm tin và thử sử dụng các số liệu kinh doanh làm ngôi sao định hướng của mình. Khi thời gian trôi qua, nó dẫn đến kết quả tốt hơn.

Đầu tiên, nó đơn giản hóa giao tiếp. đối tác sản phẩm của bạn sẽ dễ dàng hiểu lý do tại sao cần ưu tiên nâng cấp DB khi bạn đặt nó dưới dạng KPI được chia sẻ sẽ bị tổn hại. Chỉ vì bạn thấy rõ rằng nếu bạn không ưu tiên nâng cấp DB, một số câu chuyện của người dùng sau đây sẽ mất gấp đôi thời gian và bạn sẽ phải dành thời gian bảo trì, điều này sẽ làm trì hoãn việc phát hành tính năng đến mức bạn đã thắng không có đủ thời gian để đạt được mục tiêu sử dụng mà bạn đã đặt làm KPI, không có nghĩa là điều đó rõ ràng đối với đối tác sản phẩm của bạn. Ý tôi là, đó là rất nhiều bước nhảy; tại sao không bắt đầu với cái quan trọng? (không, đó không phải là bản nâng cấp DB)

Thứ hai, việc đo lường nhóm của tôi dựa trên các số liệu kinh doanh khiến tôi thấy rằng chúng tôi có thể tác động đến họ khá nhiều:

• Chúng tôi có thể xác định các tính năng mà chúng tôi có thể xây dựng 80% giá trị người dùng cho 20% nỗ lực. Điều này có thể giải phóng tài nguyên để giúp di chuyển KPI của chúng tôi nhanh hơn nữa. Để làm được điều đó, nhóm phải hiểu rõ mục tiêu kinh doanh, nhu cầu của người dùng và động lực để cải thiện chúng.
• Chúng tôi có thể sử dụng KPI để hướng dẫn chúng tôi nên tích lũy khoản nợ công nghệ nào: Có phải chúng tôi đang cố gắng thu hút người dùng tính năng đầu tiên của mình và lỗi tính năng là một tùy chọn? Hãy phát hành càng nhanh càng tốt và lo lắng về nợ công nghệ sau này. Có phải chúng ta đang cố gắng cải thiện việc duy trì một cơ sở khách hàng lớn? Hãy đảm bảo chất lượng cao cho cái này.
• Chúng tôi có thể đề xuất giải pháp cho các vấn đề nan giải mà sản phẩm thậm chí không biết là có thể giải quyết được hay không, dựa trên tiến bộ công nghệ mới hoặc góc độ kỹ thuật sáng tạo.
• Chúng ta có thể (dù khó chịu đến mức nào) sử dụng KPI để hiểu rằng không ích gì khi theo đuổi một giải pháp công nghệ tuyệt vời cụ thể mà chúng ta muốn triển khai vì bản thân vấn đề không quan trọng đối với doanh nghiệp.

Làm Thế Nào Để Đo Lường Thành Công?

Sau khi chuyển sang các số liệu quan trọng đối với doanh nghiệp, tôi và đối tác sản phẩm của tôi phải chọn một khuôn khổ để đo lường chúng. Tại Epsagon, chúng tôi đã sử dụng khuôn khổ OKR . Tôi sẽ không đi vào chi tiết vì có rất nhiều tài nguyên tuyệt vời để triển khai OKRs trực tuyến. Ý chính là đây là một khuôn khổ tuyệt vời cho các tổ chức vừa và lớn, thường là trong giai đoạn hậu sản phẩm phù hợp với thị trường. Nó giúp sắp xếp các đội, nhóm và tổ chức khác nhau trong doanh nghiệp hướng tới cùng một mục tiêu định hướng kết quả.

Tại Epsagon, chúng tôi có OKR cho mọi nhóm sản phẩm và chúng là mục tiêu của các kỹ sư, sản phẩm và nhà thiết kế đã tạo nên nhóm sản phẩm. Sau khi triển khai, chúng tôi đã có sự hợp tác tốt hơn giữa sản phẩm và kỹ thuật. Ít tranh cãi hơn về các yêu cầu và hợp tác nhiều hơn để giải quyết vấn đề. Chúng tôi cũng nhận thấy rằng sự gia tăng quyền tự chủ do đặt mục tiêu cho các nhiệm vụ đã làm tăng sự đổi mới và quyền sở hữu đối với kết quả. Các nhóm thiết lập lộ trình và các giải pháp đến từ kỹ thuật cũng như sản phẩm.

Nhược điểm của phương pháp này là nó đòi hỏi một số nỗ lực trong việc thực hiện và cũng yêu cầu bạn phải có khả năng nêu rõ các mục tiêu của mình trong khoảng thời gian hàng tháng. Điều này thường khó đối với các công ty khởi nghiệp nhỏ, đặc biệt là trước khi sản phẩm phù hợp với thị trường. Đối với các giai đoạn trước, bạn có thể làm việc với một chỉ số chính và vẫn được thúc đẩy bởi mục tiêu kinh doanh trong khi vẫn đủ linh hoạt để thay đổi mục tiêu của mình và tập trung vào mức độ chi tiết của tuần hoặc ngày.

Cho dù nhóm của bạn lớn hay nhỏ, có một nhiệm vụ hay các ưu tiên cạnh tranh — miễn là bạn đo lường được những gì quan trọng, bạn sẽ có cơ hội thành công cao hơn. "Làm thế nào" chỉ là một tối ưu hóa.

Giao tiếp là chính

Khi chúng tôi thiết lập KPI kinh doanh, bước tiếp theo là thực hiện theo. Theo kinh nghiệm của tôi, có hai khía cạnh quan trọng để truyền đạt và thực hiện thay đổi này. Đầu tiên là tính nhất quán: không đủ để thiết lập các số liệu đó và xem lại chúng ba tháng sau để phát hiện ra rằng chúng tôi đã bỏ lỡ điểm số của mình. Với tư cách là người lãnh đạo, nhiệm vụ của chúng tôi là liên tục theo dõi các số liệu này và đảm bảo trạng thái cũng như lộ trình cải thiện chúng luôn được thông báo cho toàn bộ nhóm của chúng tôi.

Khía cạnh thứ hai là sự cam kết: thật hấp dẫn khi quay trở lại thói quen cũ là đo lường các cá nhân bằng cách sử dụng các chỉ số dành cho nhà phát triển để tối ưu hóa họ. Điều này sẽ gửi thông điệp sai đến nhóm của bạn, gợi ý rằng mặc dù bạn nói rằng bạn quan tâm đến KPI kinh doanh, nhưng điều bạn thực sự quan tâm lại là các chỉ số dành cho nhà phát triển. Hãy chắc chắn thay đổi thói quen của bạn để phản ánh các ưu tiên của bạn: ăn mừng kết quả kinh doanh, cắt giảm các tính năng không bắt buộc phải có thay vì thúc đẩy thời hạn và giương cao cờ hiệu khi KPI của doanh nghiệp giảm. Bạn vẫn có thể sử dụng số liệu nhà phát triển làm chỉ số; chỉ cần nhớ liên kết chúng với ảnh hưởng của chúng đối với KPI kinh doanh.

Số liệu Dev có bị phản đối không?

Bất chấp tiêu đề câu nhấp chuột của bài viết này, câu trả lời là không — chúng chỉ nên được sử dụng đúng cách. Thứ nhất, số liệu nhà phát triển là công cụ mạnh mẽ để khắc phục sự cố số liệu kinh doanh của bạn. Ví dụ: sự sụt giảm trong tỷ lệ giữ chân người dùng có thể được giải thích bằng sự gia tăng số lượng lỗi. Trong trường hợp này, bạn có thể sử dụng chỉ số nhà phát triển làm chỉ báo hàng đầu: Thay vì đợi tỷ lệ giữ chân giảm xuống, bạn nên theo dõi số lượng lỗi để ngăn nó giảm xuống (tương tự như cách bạn theo dõi mức sử dụng CPU để tránh số lượng lỗi API 5xx khỏi tăng đột biến và gây hại thực sự cho người dùng của bạn). Một trường hợp sử dụng khác là chỉ số nhà phát triển như một chỉ báo hàng đầu về trải nghiệm và sự hài lòng của nhà phát triển (do đó, tác động đến việc giữ chân nhà phát triển).

Tuy nhiên, điều quan trọng cần nhớ là bạn không bao giờ được tối ưu hóa các chỉ số dành cho nhà phát triển. Bạn phải luôn tối ưu hóa các chỉ số kinh doanh và chỉ sử dụng tối ưu hóa chỉ số nhà phát triển như một công cụ để đạt được mục tiêu đó. Và, tất nhiên, bạn chỉ nên đặt, theo dõi hoặc tối ưu hóa các mục tiêu về số liệu của nhà phát triển sau khi bạn hiểu rõ về kết quả kinh doanh mà bạn đang cố gắng đạt được và các KPI kinh doanh mà bạn đang cố gắng đạt được. Số liệu thống kê kỹ thuật tuyệt vời sẽ không cứu được dự án của bạn nếu nó không có giá trị.

Cái gì tiếp theo?

Nếu bạn đang lãnh đạo một tổ chức kỹ thuật, việc chuyển sang tối ưu hóa kết quả kinh doanh qua các chỉ số dành cho nhà phát triển sẽ cải thiện cơ hội nhóm của bạn tạo ra tác động thực sự cho doanh nghiệp. Nếu bạn cam kết trở thành một nhà lãnh đạo hướng đến kết quả, tôi khuyên bạn nên tự hỏi mình những câu hỏi sau:

• Tôi có biết những kết quả kinh doanh nào được mong đợi ở tôi không?
• Tôi có đang làm bất cứ điều gì có thể để tối ưu hóa cho những kết quả này không?
• Tôi đang theo dõi thành công như thế nào? Các tiêu chí để treo cờ hoặc thay đổi kế hoạch của tôi là gì?
• Nhóm của tôi có nhận thức được các mục tiêu kinh doanh và lộ trình để đạt được chúng không? Đầu vào của họ là gì về nó?
• KPI kinh doanh nào của tôi có thể được cải thiện bằng cách cải thiện chỉ số nhà phát triển nào?