- Với kỹ sư senior·PM·designer càng ở cấp cao thì càng nên có ít nhất một biểu đồ chỉ số cốt lõi mà mình chịu trách nhiệm, và đây là một trong những cách nhanh nhất để làm việc hiệu quả
- Ở cấp độ senior, phần lớn các vấn đề quan trọng cần xử lý đều có thể biểu diễn bằng biểu đồ; bạn được kỳ vọng trực tiếp chịu trách nhiệm cho những chỉ số cho thấy thay đổi dài hạn như số trang, hiệu năng, chi phí, doanh thu, tỷ lệ rời bỏ
- So với một câu như “đã giảm 15%”, biểu đồ cho thấy quy mô, xu hướng, độ biến động và thời điểm trong một lần nhìn, đồng thời là công cụ giao tiếp mạnh nhất để giải thích tác động và tạo ra độ tin cậy có thể kiểm chứng
- Vòng lặp kết hợp biểu đồ vào việc đặt mục tiêu và kiểm tra biến việc theo dõi kết quả và phản hồi trở nên cực kỳ đơn giản, có thể dẫn tới khác biệt ở mức phân định giữa hiệu suất cao và thất nghiệp
- Một biểu đồ tốt phải là một trong số ít thứ quan trọng mà người khác thường xuyên tham chiếu, và việc chịu trách nhiệm đến cùng để khiến một biểu đồ trong các lĩnh vực như chất lượng, hỗ trợ, doanh thu, retention thực sự dịch chuyển chính là vai trò cốt lõi của senior
Xử lý những vấn đề quan trọng
- Ở giai đoạn senior, chịu trách nhiệm cho “những vấn đề lớn và quan trọng” là điều bắt buộc, và hầu hết các vấn đề như vậy đều có thể được biểu diễn bằng biểu đồ cho thấy sự thay đổi theo thời gian
- Ví dụ: giảm số trang, cải thiện hiệu năng, cắt giảm chi phí, tăng doanh thu, giảm tỷ lệ rời bỏ
- Kết quả công việc của bạn trong khoảng thời gian từ cấp độ quý trở lên phải hiện ra dưới dạng một đường cong có thể nhìn thấy được
- Không phải mọi công việc đều cần gắn trực tiếp với biểu đồ, nhưng nếu bạn không chịu trách nhiệm lấy nổi một biểu đồ nào thì với tư cách senior, bạn đang không thực sự làm đúng vai trò của mình
Truyền đạt tác động một cách rõ ràng
- Vấn đề mà senior thường gặp là than phiền rằng thành quả của mình không được hiểu đúng, và điều này phần lớn nên được xem là thất bại trong giao tiếp
- Nếu bạn chỉ gửi một câu như “đã giảm số trang 15%”, thì lập tức sẽ phát sinh hàng loạt câu hỏi bổ sung về điểm xuất phát, khoảng thời gian, xu hướng, có phải ngẫu nhiên hay không
- Biểu đồ cho thấy quy mô (scale), lịch sử trước đó, độ biến động, thời điểm thay đổi chỉ trong một cái nhìn
- Đồng thời có thể cung cấp kèm liên kết tới nguồn dữ liệu, giúp người xem tự xác minh tính xác thực của biểu đồ một cách dễ dàng
- Nếu chỉ diễn đạt tác động bằng văn bản mơ hồ, bạn sẽ khó nhận được phản hồi sắc bén về việc công việc hiện tại có đúng hướng hay không, và hiệu quả có xứng đáng với mức đầu tư hay không
- Ngược lại, nếu thể hiện bằng biểu đồ, bạn có thể vừa được ghi nhận công lao, vừa nhận được phản hồi rõ ràng về định hướng và mức độ ưu tiên
- Biểu đồ là phương tiện thể hiện rõ giá trị công việc và hiệu quả theo thời gian
Kết nối mọi yếu tố thành một
- Như đã nói trong bài trước On Achieving Goals, quá trình hoàn thành công việc có thể được tóm gọn thành một vòng lặp đơn giản “đặt mục tiêu → kiểm tra”
- Cốt lõi của việc đạt mục tiêu là một cấu trúc đơn giản: đặt mục tiêu tốt, chỉ định người chịu trách nhiệm rõ ràng, và thông qua các buổi check-in định kỳ để xác nhận trạng thái và các điều chỉnh cần thiết
- Phần lớn nguyên nhân khiến mục tiêu thất bại bắt nguồn từ việc đặt mục tiêu tồi như mục tiêu không có giá trị, sai ưu tiên, không có người chịu trách nhiệm, và từ sự đổ vỡ của quy trình cơ bản như thiếu check-in hoặc vận hành check-in sai cách
- Mục tiêu chính xác và việc kiểm tra đều đặn là hạ tầng nền tảng để tổ chức tạo ra thay đổi thực sự; nếu không có chúng, không mục tiêu nào có thể được đạt một cách bền vững
- Bài viết này bổ sung thêm một quy tắc nữa: hãy kết hợp biểu đồ vào đó
- Nghĩa là bạn phải đặt mục tiêu, rồi vận hành một vòng lặp kiểm tra định kỳ một biểu đồ duy nhất đại diện cho mục tiêu đó
- Tổ hợp này có thể trở thành một công cụ mạnh đến mức phân định giữa người hiệu suất cao và người thất nghiệp
Tổng kết
- Biểu đồ là đơn vị cốt lõi để senior theo dõi tiến độ, thể hiện kết quả và nhận phản hồi
- Chịu trách nhiệm và dẫn dắt một biểu đồ chính là đơn vị thực tế của ownership
- Nếu hiện tại bạn chưa có biểu đồ nào mình chịu trách nhiệm, hãy lập tức tìm một cái và sở hữu nó
Appendix: Mẹo & trick để sở hữu biểu đồ
- Nếu bạn có được một biểu đồ mà người khác thường xuyên trích dẫn, tức là bạn đang đi đúng hướng
- Mọi người thường lười, nên nếu đã có một biểu đồ hữu ích và chính xác, họ có xu hướng mang dùng lại y nguyên thay vì tự tạo lại
- Những biểu đồ như vậy cũng tự nhiên trở thành điểm cộng cho sự nghiệp của chính bạn
- Biểu đồ không cần hoàn hảo ngay từ đầu; quá trình dần dần cải thiện nó thông qua phản hồi mới là ownership thực sự
- Anti-pattern cần tránh là “sở hữu quá nhiều biểu đồ”
- Một số người thu thập vô số biểu đồ chỉ để dùng vào những thời điểm phù hợp với câu chuyện của mình rồi tuyên bố rằng mình “sở hữu” chúng
- Trạng thái tốt là chỉ chịu trách nhiệm sâu cho một số cực ít biểu đồ thật sự quan trọng
- Như bài “You have too many metrics” đã nói, chỉ số và biểu đồ phải ít nhưng cực kỳ hữu dụng
- Khi kỹ sư muốn tìm một biểu đồ để sở hữu, các vấn đề về chất lượng là điểm khởi đầu tốt
- Số trang, incident, bug, hiệu năng đều rất phù hợp để biểu đồ hóa và là các lĩnh vực đang chờ ai đó đứng ra chịu trách nhiệm
- Từ góc nhìn PM·designer, ticket hỗ trợ, doanh thu, tỷ lệ thắng trước đối thủ, attach rate của các sản phẩm bổ trợ ảnh hưởng đến retention là những ứng viên tốt
- Không nhất thiết bạn phải có khả năng tự mình làm dịch chuyển chỉ số đó,
- chỉ riêng việc liên tục theo dõi một chỉ số quan trọng và kiên trì thúc đẩy mọi người đi đúng hướng cũng có thể giúp sự nghiệp tiến rất xa
8 bình luận
Biểu đồ cân nặng của tôi đang đi lên.
Biểu đồ tăng lương của tôi đã 5 năm nay ở mức 0%.
Dù khó có thể khái quát hóa, nhưng trước hết đây chắc chắn là công cụ tốt nhất để thuyết phục ban lãnh đạo.
Vậy thì có lẽ biểu đồ đó rất dễ bị nhiễm bẩn.
Định luật Goodhart: "Khi một thước đo trở thành mục tiêu, thì thước đo đó không còn là một thước đo tốt nữa"
Một câu trích dẫn phản bác định luật Goodhart khiến tôi nghĩ đến câu nói thường được cho là của Peter Drucker: “Nếu không thể đo lường, thì không thể quản lý (If you can't measure it, you can't manage it)”.
Tìm hiểu thêm thì ngay cả Drucker Institute cũng nói rằng Drucker chưa từng nói như vậy.
Ngược lại, tôi lại tìm thấy một câu nói theo hướng đối lập.
Cho rằng nếu không thể đo lường thì không thể quản lý là sai lầm — đó là một huyền thoại đắt giá. (It is wrong to suppose that if you can't measure it, you can't manage it—a costly myth) - Edwards Deming
Dù vậy, tôi nghĩ vẫn sẽ có những tiêu chí đo lường có ý nghĩa. Đặc biệt, sẽ hiệu quả hơn nếu có ai đó phải chịu trách nhiệm cho cả hai chỉ số đối nghịch. Từ góc nhìn SRE, có thể vui vì đã giảm số vụ sự cố, nhưng vì quá thận trọng trước mỗi bước nên việc triển khai bị chậm lại và phát triển tính năng cũng chững hơn. Ngược lại, từ góc nhìn Dev, có thể vui vì đã làm được nhiều tính năng, nhưng đồng thời số sự cố phát sinh cũng có thể tăng lên.
Tôi cũng nghĩ những chỉ số như p99 latency, tỷ lệ phản hồi thành công, chi phí trên mỗi yêu cầu, MTTR, số vụ sự cố là các chỉ số tốt và khó bị lạm dụng. (Tất nhiên vẫn có thể bị lạm dụng, nhưng có vẻ lợi ích của việc theo dõi và quản lý chúng sẽ nhiều hơn tác hại...)
Bình thường, tôi vẫn nghĩ việc nêu thành tích bằng tỷ lệ phần trăm là vô nghĩa, và có vẻ như bài viết này đã hoàn thiện suy nghĩ đó của tôi.
Tôi nghĩ rằng không phải nói kiểu đã góp phần làm doanh thu tăng 5%, mà phải nói trong một khoảng thời gian đã tăng bao nhiêu, và so với trước khi có đóng góp của bản thân thì mức tăng đó đã trở nên dốc hơn đến mức nào.
Tôi từng nghĩ khả năng biểu đạt thành quả hay mục tiêu bằng con số là quan trọng, nhưng bài viết này lại nói rằng còn phải thể hiện được cả bằng biểu đồ nữa. Xét ở khía cạnh giúp đối phương dễ hiểu và tạo độ tin cậy thì đúng là một điểm rất đáng đồng tình.