Quy tắc vàng trong kỹ thuật: Đừng vội trả lời câu hỏi đầu tiên

Trong công việc của tôi với Perfetto – một công cụ gỡ lỗi hiệu năng (performance debugging), một câu hỏi mà tôi thường nhận được là: “Làm thế nào để chia một file Perfetto trace thành nhiều file nhỏ?”.

Thay vì trả lời trực tiếp, tôi thường nói: “Không có cách nào dễ dàng để làm điều đó, nhưng điều gì đã dẫn bạn đến việc thu thập các trace lớn đến mức muốn chia nhỏ chúng?”.

Đây là một trong những quy tắc vàng của tôi trong công việc: Khi người dùng hỏi một điều gì đó “lạ lùng”, đừng trả lời ngay phiên bản đầu tiên của câu hỏi đó.

Về mặt bề nổi, điều này có vẻ giống với vấn đề XY – nơi người dùng cố gắng giải quyết vấn đề X bằng giải pháp Y và hỏi về Y thay vì X. Tuy nhiên, cách tiếp cận của tôi đi xa hơn một bước so với việc chỉ giải mã vấn đề. Sự nhầm lẫn dẫn đến câu hỏi sai chính là một cơ hội mở ra, và cuộc hội thoại mà nó khởi tạo mang lại giá trị cho cả hai phía. Người dùng sẽ rời đi với mô hình tư duy tốt hơn về công cụ, và tôi có được bức tranh rõ ràng hơn về nơi sản phẩm đang gây khó hiểu. Đôi khi, giữa chúng tôi, chúng tôi nhận ra rằng chính sản phẩm cần thay đổi.

Chẩn đoán câu hỏi

Một số câu hỏi dễ dàng, mang tính thường nhật và chỉ đơn thuần là việc chỉ vào tài liệu hướng dẫn; những câu hỏi đó không đáng để bàn luận nhiều. Những trường hợp thú vị là khi có điều gì đó bất thường, và hiếm khi người dùng cung cấp đủ thông tin trong câu hỏi đầu tiên.

Tôi chạy một danh sách kiểm tra trong đầu để xác định hướng đi tiếp theo:

• Tôi đã từng thấy điều này chưa? Nếu có, tôi có thể đã có câu hỏi trả lời. Nếu chưa, nó đủ hiếm để tôi muốn chậm lại.
• Câu hỏi có nghe hợp lý so với những câu khác tôi từng thấy không? Nếu không, tại sao họ lại hỏi như vậy, và có một câu hỏi bình thường hơn ẩn dưới đó không?
• Nó có phù hợp với kiến trúc của công cụ không? Hay người dùng đang chống đối kiến trúc mà không nhận ra?

Khi tôi xác định được điều gì đó không ổn, bước tiếp theo là đặt câu hỏi giúp làm rõ bối cảnh còn thiếu. Tôi có thể nói something như: “Câu trả lời cho câu hỏi ngay lập tức của bạn là X, nhưng đây là một yêu cầu khá lạ vì lý do Y. Bạn có thể cho tôi biết thêm về vấn đề rộng lớn hơn mà bạn đang cố gắng giải quyết không?”.

Điều này thường dẫn đến một cuộc đối thoại qua lại. Chúng ta thường sẽ kết thúc ở một trong ba điểm: họ đang thiếu tư duy cốt lõi của công cụ, sản phẩm đang che giấu đường đi đúng, hoặc chính sản phẩm cần thay đổi.

Khi người dùng thiếu tư duy cốt lõi

Rất phổ biến khi người dùng đến với chúng tôi mà không biết họ muốn gì, hoặc không hiểu vấn đề họ đang cố gắng giải quyết. Tôi không chỉ trích họ vì điều này; các đội nhóm thường cố gắng giải quyết vấn đề với thời gian hoặc nguồn lực hạn chế, và họ tìm đến các công cụ gỡ lỗi mới khi gặp khó khăn.

Một ví dụ phổ biến: mọi người đến với Perfetto, thấy rằng một trace là bản ghi chi tiết về những gì thiết bị đã làm trong một khoảng thời gian, nhận ra bạn có thể tính toán các chỉ số (metrics) từ trace, và coi đó là giải pháp thánh thánh cho mọi vấn đề. Muốn biết tốc độ khung hình (frame rate)? Đếm khung hình trong trace. Bộ nhớ ứng dụng dùng? Xem việc cấp phát và giải phóng.

Về nguyên tắc, bất kỳ chỉ số nào cũng có thể được tính từ trace. Nhưng đây là một ý tưởng tồi vì một lý do đơn giản: trace rất tốn kém để thu thập và xử lý. Bạn đang thu thập tất cả dữ liệu về hệ thống thay vì lấy mẫu một con số duy nhất. Bạn sẽ lãng phí rất nhiều tài nguyên, trong khi một hệ thống thu thập chỉ số chuyên dụng sẽ làm công việc này hiệu quả hơn nhiều.

Một phần lớn công việc của tôi là dạy cho đội nhóm cách tiếp cận kỹ thuật hiệu năng, không chỉ là giải thích cách dùng Perfetto.

Khi đường đi đúng bị ẩn

Đôi khi đội nhóm hiểu vấn đề; họ chỉ không thấy cách kết hợp các công cụ hiện có. Các công cụ của chúng tôi được thiết kế để mạnh mẽ, và chúng tôi phải lưu ý rằng các đội khác có thể không hiểu đầy đủ phạm vi những gì chúng tôi đã xây dựng.

Một ví dụ hoàn hảo là vấn đề chia trace tôi đã đề cập. Cuộc hội thoại thường đi theo hướng: “...điều gì dẫn bạn đến việc thu thập trace lớn đến mức muốn chia nhỏ?”. Họ nói rằng vì họ có những khoảng thời gian quan tâm trong một trace dài và muốn cắt nó ra. Một phần vì hiệu năng, một phần để dễ trực quan hóa.

Sau đó tôi chỉ ra rằng Perfetto đã hỗ trợ snapshot định kỳ (periodic trace snapshots) – các bản ghi ngắn lặp lại thay vì một bản ghi dài duy nhất, điều này loại bỏ nhu cầu thu thập trace dài ngay từ đầu. Họ đang cố gắng giải quyết một vấn đề mà họ lẽ ra không nên gặp phải.

Luôn rất hài lòng khi thấy người dùng nói “Đây chính xác là thứ tôi cần!”, dù đó không phải là điều họ hỏi ban đầu. Điều đó có nghĩa là tôi đã xác định được thành công những gì họ thực sự muốn chứ không phải những gì họ nghĩ mình muốn.

Khi sản phẩm cần thay đổi

Thỉnh thoảng, câu trả lời tiết lộ một cái gì đó thực sự mới mẻ, điều gì đó có thể đưa chúng ta trên con đường xây dựng một thứ lớn lao. Những trường hợp này rất tricky: ngay cả khi yêu cầu là mới lạ, người yêu cầu thường không thể nói cho bạn biết họ thực sự cần gì.

Chi phí của việc sai lầm trong phần mềm nền tảng là rất cao, vì vậy tôi thiên về phía không xây dựng cái gì cho đến khi việc không có nó gây đau đớn: nhiều đội nhóm đã đến với tôi nói “chúng tôi muốn cái này”. Lý tưởng là đến lúc đó chúng ta đã tìm thấy bản chất của điều thực sự đáng để xây dựng.

Chúng tôi đã mắc sai lầm này tại Perfetto với việc tùy chỉnh UI tự do. Mọi người muốn sửa đổi UI để phù hợp với quy trình làm việc của họ, và họ liên tục phàn nàn về việc khó khăn đến thế nào. Vì vậy chúng tôi để họ làm, và ngay lập tức gánh một lượng nợ kỹ thuật khổng lồ. Mọi tính năng mới phải tương tác với mọi tính năng hiện có, và cả thứ nhanh chóng trở nên không thể mở rộng.

Mất khoảng một năm để chúng tôi thoát khỏi hố sâu này bằng cách thiết kế một API plugin thích hợp. Nhu cầu thực sự, mà không ai có thể diễn đạt rõ ràng từ đầu, là một cách để cá nhân hóa UI theo nhu cầu của đội nhóm hoặc trường hợp sử dụng mà không ảnh hưởng đến người dùng khác.

Việc cho phép người dùng “hợp nhất (merge)” các Perfetto trace là một trường hợp chúng tôi làm đúng. Mọi người hỏi về nó liên tục, nhưng chúng tôi trì hoãn. Chúng tôi chỉ ra các giải pháp thay thế và nói “chúng tôi sẽ xem”. Chúng tôi biết làm đúng việc này tốn nhiều công và dễ sai, nên chúng tôi chờ đợi. Cuối cùng chúng tôi xây dựng nó vào năm ngoái theo cách có thể bảo trì, nhưng chỉ vì chúng tôi hiểu rất rõ về không gian vấn đề.

Kết luận

Phiên bản đầu tiên của một câu hỏi hiếm khi là câu hỏi thực sự. Hãy hỏi “tại sao” trước khi bạn trả lời. Đôi khi câu trả lời dạy người dùng cách công cụ được dự định sử dụng. Đôi khi nó cho bạn biết sản phẩm đang che giấu đường đi đúng. Đôi khi nó cho bạn biết chưa có gì đáng để xây dựng cả. Và đôi khi nó giúp bạn chuẩn bị để xây dựng điều lớn tiếp theo một lần, chứ không phải hai lần.

Kỹ thuật này đơn giản, nhưng dễ bỏ qua vì áp lực phải phản hồi là liên tục, và mọi câu trả lời nhanh đều cảm thấy hiệu quả. Hãy lùi lại một bước nhỏ. Cả hai phía hầu như luôn rời đi với nhiều hơn những gì họ mang đến.