- Với công cụ gỡ lỗi hiệu năng, khi gặp một yêu cầu kỳ lạ thì thay vì trả lời ngay cần hỏi về bối cảnh, vì như vậy mới lộ ra vấn đề thực sự của người dùng và những khoảng trống của công cụ
- Cách này vượt xa việc chỉ xử lý vấn đề XY đơn thuần, lấy chính sự mơ hồ dẫn đến câu hỏi sai làm điểm xuất phát để nâng cao hiểu biết cho cả người dùng lẫn sản phẩm
- Trong Perfetto, việc dùng trace để tính mọi chỉ số tuy có thể làm được nhưng lại không hiệu quả, và một hệ thống thu thập chỉ số chuyên dụng có thể phù hợp hơn
- Khi câu trả lời bề ngoài và nhu cầu thực tế khác nhau, như với yêu cầu tách trace, thì các tính năng sẵn có như periodic trace snapshots có thể là hướng đi tốt hơn
- Nên quyết định thay đổi sản phẩm sau khi nhu cầu lặp đi lặp lại đã bộc lộ đủ rõ; bổ sung tính năng quá vội vàng có thể dẫn tới nợ kỹ thuật lớn
Vì sao không trả lời ngay câu hỏi đầu tiên
- Trong công cụ gỡ lỗi hiệu năng như Perfetto, nếu người dùng hỏi một điều có vẻ kỳ lạ như “Làm sao chia một Perfetto trace thành nhiều tệp?”, thì thay vì đưa ngay cách làm, nên hỏi trước “Điều gì khiến bạn phải thu thập một trace lớn như vậy?”
- Cách tiếp cận này tiến thêm một bước so với việc chỉ giải quyết vấn đề XY
- Nó không chỉ biến câu hỏi của người dùng thành “ý định thật sự” rồi trả lời cho xong, mà dùng chính sự mơ hồ sinh ra câu hỏi sai làm điểm khởi đầu của cuộc đối thoại
- Người dùng có được một mô hình tư duy tốt hơn về công cụ, còn phía xây dựng công cụ thì nhìn rõ hơn sản phẩm đang gây nhầm lẫn ở đâu
- Đôi khi cuộc trò chuyện còn dẫn đến kết luận rằng bản thân sản phẩm cần phải thay đổi
- Đây là cách đặc biệt áp dụng trực tiếp với những người xây công cụ cho kỹ sư
- Với sản phẩm tiêu dùng hay dịch vụ B2B, nó có thể không chuyển nguyên xi được, nhưng cách tiếp cận nền tảng vẫn hữu ích
Cách chẩn đoán một yêu cầu
- Không phải mọi câu hỏi đều cần một cuộc trao đổi sâu
- Những câu hỏi đơn giản, lặp lại, chỉ cần trỏ tới tài liệu thì không phải đối tượng của cuộc bàn luận này
- Trường hợp thú vị là khi chỉ từ yêu cầu đầu tiên đã thấy thiếu ngữ cảnh, và bản thân câu hỏi trông khác thường
- Với câu hỏi kỳ lạ, hãy tìm điểm lệch theo các tiêu chí sau
- Xem đó có phải kiểu câu hỏi từng gặp trước đây không; nếu không, coi đó là yêu cầu hiếm và chậm lại
- So với các câu hỏi khác, nó có hợp lý không; nếu không, hãy tìm xem bên dưới có một câu hỏi tổng quát hơn không
- Yêu cầu đó có khớp với cấu trúc của công cụ không, hay người dùng đang vô tình chống lại chính kiến trúc của nó
- Sau khi tìm ra điểm lệch, hãy đặt câu hỏi để phần ngữ cảnh còn thiếu lộ ra
- Cách mở đầu cuộc trò chuyện có thể là: câu trả lời trực tiếp là X, nhưng vì lý do Y đây là một yêu cầu khá lạ, nên hãy cho biết vấn đề rộng hơn mà bạn đang gặp
- Sau đó, tốc độ trao đổi sẽ tùy vào việc người dùng truyền đạt suy nghĩ của họ tốt đến đâu
- Cuộc trò chuyện thường dẫn đến một trong ba kết luận
- Người dùng đang bỏ lỡ triết lý của công cụ
- Con đường đúng đã có trong sản phẩm nhưng bị che khuất
- Bản thân sản phẩm cần thay đổi
Khi người dùng bỏ lỡ triết lý của công cụ
- Người dùng thường tìm đến công cụ trong trạng thái chưa thực sự biết chính xác mình muốn gì hoặc đang cố giải quyết vấn đề nào
- Điều này không nhằm chỉ trích người dùng
- Các đội ngũ giải quyết vấn đề trong điều kiện thời gian và nguồn lực hạn chế, rồi khi không còn tiến triển mới tìm tới công cụ gỡ lỗi mới
- Ngay cả khi công cụ cung cấp phần lớn tính năng họ muốn, nếu nó không khớp với mô hình “nó nên hoạt động như thế này” trong đầu họ, thì yêu cầu tính năng sẽ xuất hiện
- Một ví dụ phổ biến trong Perfetto là coi trace như lời giải vạn năng để tính mọi chỉ số
- Perfetto trace ghi lại rất chi tiết những gì thiết bị đã làm trong một khoảng thời gian nhất định
- Vì có thể tính chỉ số từ trace, người dùng cố tính cả những giá trị như tốc độ khung hình hay mức dùng bộ nhớ của ứng dụng từ trace
- Về nguyên tắc, bất kỳ chỉ số nào cũng có thể được tính từ trace
- Nhưng cách tính mọi chỉ số bằng trace là không hiệu quả
- Trace tốn kém cả ở khâu thu thập lẫn xử lý
- Ngay cả khi chỉ cần một con số duy nhất, bạn vẫn phải thu thập dữ liệu của toàn hệ thống
- Một hệ thống thu thập chỉ số chuyên dụng có thể làm cùng việc đó hiệu quả hơn rất nhiều
- Công cụ nào cũng có triết lý thiết kế, và người dùng rất dễ bỏ qua khi đang tập trung vào vấn đề trước mắt
- Điều quan trọng không chỉ là dạy cách dùng Perfetto, mà còn là dạy cách tiếp cận kỹ thuật hiệu năng nói chung
- Cần chỉ cho họ cách suy nghĩ và xử lý các chủ đề như thời gian khởi động, rớt khung hình, bộ nhớ, điện năng
- Cần giúp họ hiểu nên dùng công cụ nào trong cả trạng thái bình thường lẫn khi có sự cố
Khi con đường đúng bị che khuất
- Cũng có trường hợp người dùng hiểu vấn đề của mình nhưng không biết phải kết hợp các công cụ hiện có như thế nào
- Công cụ được thiết kế có chủ đích để rất mạnh mẽ, và không thể giả định rằng đội khác sẽ hiểu hết toàn bộ phạm vi tính năng
- Khi xác định được điều họ thực sự muốn, nhiều khi một tính năng vốn được tạo ra cho mục đích khác lại đáp ứng được nhu cầu đó
- Yêu cầu tách trace là ví dụ điển hình
- Người dùng nói rằng trong một trace dài có một đoạn họ quan tâm và muốn cắt nó ra
- Lý do là để cải thiện hiệu năng và giúp trực quan hóa dễ hơn
- Nhưng trong trường hợp này, cách phù hợp hơn có thể là ngay từ đầu đừng thu thập một trace dài như vậy
- Perfetto đã có sẵn periodic trace snapshots
- Đây là tính năng ghi lại nhiều bản ghi ngắn lặp lại thay vì một bản ghi dài duy nhất
- Nó loại bỏ luôn nhu cầu phải chia nhỏ trace sau khi đã thu thập
- Câu trả lời mà người dùng hỏi và câu trả lời họ thực sự cần có thể khác nhau
- Phản ứng kiểu “Đó mới chính xác là thứ tôi cần” là dấu hiệu cho thấy bạn đã tìm ra nhu cầu thật, chứ không phải chỉ trả lời yêu cầu mà người dùng nghĩ ra
Khi sản phẩm thực sự cần thay đổi
- Có những phản hồi bộc lộ một nhu cầu mới có thể dẫn đến thay đổi lớn trong sản phẩm
- Đây là những trường hợp khó
- Dù yêu cầu là mới, người đưa ra yêu cầu vẫn có thể không mô tả rõ được họ thực sự cần gì
- Cái giá của một quyết định sai trong phần mềm nền tảng là rất lớn
- Vì vậy nên ưu tiên không xây cho đến khi sự thiếu vắng đó thực sự gây đau đớn
- Khi nhiều đội bắt đầu nói về cùng một nhu cầu, thì lúc đó phần cốt lõi thật sự đáng để xây thường mới hiện ra rõ ràng
- Rất khó tìm ra phần cốt lõi này chỉ từ một yêu cầu đơn lẻ, nên chờ đợi là một chiến lược mạnh
- Tùy biến UI tạm thời trong Perfetto là một ví dụ về quyết định sai
- Mọi người muốn “hack” UI cho khớp với workflow của họ và liên tục phàn nàn rằng điều đó quá khó
- Ngay khi cho phép việc này, một lượng nợ kỹ thuật khổng lồ đã xuất hiện
- Mỗi tính năng mới đều phải tương tác với toàn bộ tính năng hiện có, và cấu trúc tổng thể nhanh chóng trở nên không thể mở rộng
- Phải mất khoảng 1 năm để thoát ra bằng cách thiết kế một plugin API đúng đắn
- Nhu cầu thực sự là “một cách cá nhân hóa UI theo đội nhóm hoặc use case mà không ảnh hưởng đến mọi người dùng khác”
- Nhu cầu này không được diễn đạt rõ ràng ngay từ đầu
- Trách nhiệm nhận ra nó đủ sớm trong dòng yêu cầu thuộc về phía làm sản phẩm
- Tính năng cho phép “merge” Perfetto trace là một ví dụ được xử lý tốt
- Mọi người liên tục yêu cầu, nhưng nó không được làm ngay
- Nhóm duy trì thái độ hướng dẫn cách vòng tránh và tiếp tục quan sát
- Họ biết đây là tính năng đòi hỏi khối lượng công việc lớn và rất dễ làm sai nếu triển khai vội
- Sau khi hiểu đủ không gian vấn đề, họ mới triển khai theo cách có thể duy trì được vào năm ngoái
Bài học cốt lõi
- Câu hỏi đầu tiên thường không phải câu hỏi thật sự
- Trước khi trả lời, hãy hỏi vì sao người dùng lại đặt câu hỏi đó
- Trong một số trường hợp, người dùng sẽ học được cách nên dùng công cụ như thế nào
- Trong một số trường hợp, sự thật là con đường đúng trong sản phẩm đang bị che khuất sẽ lộ ra
- Trong một số trường hợp, kết luận sẽ là chưa có gì đáng để xây cả
- Trong một số trường hợp, bạn sẽ sẵn sàng làm đúng tính năng lớn tiếp theo ngay trong một lần thay vì phải làm lại hai lần
- Đây là một kỹ thuật đơn giản nhưng rất dễ bị bỏ qua
- Áp lực phải phản hồi nhanh luôn tồn tại
- Trả lời nhanh lúc nào cũng cho cảm giác như đang làm việc hiệu quả
- Dù vậy, nếu lùi lại một bước thì gần như lúc nào cả hai bên cũng thu được nhiều hơn so với ban đầu
1 bình luận
Ý kiến trên Lobste.rs
Tác giả nói bài này đi xa hơn rất nhiều so với vấn đề XY, nhưng với tôi nó giống một bài viết giải thích khá chi tiết cách xử lý vấn đề XY kèm theo những góc nhìn thú vị hơn
Nếu đóng khung câu hỏi theo kiểu vấn đề XY, rất dễ quay lại những heuristic phản tác dụng mà người ta thường dùng khi trả lời các câu hỏi trông giống vấn đề XY.
Tôi đã không biết bao nhiêu lần phải liên tục giải thích chỉ vì khi tôi đi xin lời khuyên, những người xung quanh tự kết luận rằng tôi đang gặp vấn đề XY, cho đến khi tôi gặp được ai đó thực sự đọc kỹ điều tôi viết. Tôi cảm thấy cách văn hóa lập trình phản ứng với vấn đề XY đang bị hiệu chỉnh sai, và bài này giống như một lời phản biện đối với sự hiệu chỉnh quá tay đó.
Ngay cả khi cảm thấy người hỏi biết ít hơn mình rất nhiều, điều quan trọng là phải chậm lại và đừng vội pattern matching. Ngay từ đầu xác suất đó là vấn đề XY cũng không hề áp đảo, và kể cả đúng là vậy thì đôi khi vẫn nên xử lý như thể không phải
Bài viết rất hay. Nó làm tôi nghĩ đến mặt còn lại của cùng một đồng xu: phải cẩn thận đừng biến điều được hỏi thành một câu hỏi đơn giản hơn rồi trả lời câu hỏi đó.
Ví dụ như khi ai đó hỏi “Khoảng cách giữa Amsterdam và San Francisco là bao nhiêu?” mà lại trả lời “Bay mất 12 tiếng”.
Câu hỏi là về khoảng cách, nhưng vì khoảng cách khó biết hơn còn thời gian bay thì dễ liên tưởng hơn, nên người trả lời đã đổi sang một câu hỏi dễ hơn để trả lời.
Kiểu này xảy ra khá thường xuyên, và có vẻ còn phổ biến hơn khi giữa người hỏi và người trả lời có khoảng cách quyền lực
Vì nhiều lý do, trong lúc hiện đại hóa hệ thống chúng tôi đã thêm trang 404 vào ingress router, và thế là phát sinh sự cố. Một lập trình viên yêu cầu khôi phục hành vi 404 cũ, vì trang cũ có thanh điều hướng và menu.
Hỏi kỹ hơn mới lòi ra rằng trong một số cấu hình của khách hàng, đăng nhập lúc nào cũng ra 404, và khách hàng thực tế đang dùng trang 404 cũ để đi tới nơi họ cần đến.
Tôi đã phát minh ra lolcry chỉ cho những khoảnh khắc như thế này 🤣😭
@lalitm, chuyện này có trước cả Internet và đã có tên từ lâu rồi. Đó là phân tích yêu cầu.
Ed Yourdon và những người khác phân biệt giữa quy trình — tức kết quả mà người dùng muốn đạt được — và thủ tục, tức cách đạt được kết quả đó. Ví dụ, thông báo cho khách hàng rằng đơn hàng đã được gửi đi là quy trình; còn gửi thông tin đó qua email là thủ tục.
Người dùng hệ thống có xu hướng nghĩ về lời giải như thể đó là một chức năng của hệ thống. Lập trình viên cũng không ngoại lệ, nên mới có nhiều biến thể kiểu “giải Y trong X”. Công việc của nhà phân tích là trích xuất yêu cầu ra khỏi một hình thức triển khai cụ thể; còn với vai trò kỹ sư thì sau đó chỉ việc hiện thực lời giải.
Gần đây tôi có tham gia một cuộc thảo luận về việc làm logging nhanh hơn vì syslog(3) bị ùn khiến sự kiện biến mất khỏi log. Nhưng vấn đề thật sự không phải là logging nhanh hơn. Người dùng không muốn logging nhanh hơn, họ muốn vấn đề được giải quyết. Cung cấp thông tin cần thiết mới là quy trình; còn ghi mọi thứ vào log chỉ là một trong những cách để làm điều đó.
Yourdon từng là một trong những người ủng hộ công cụ CASE. Có lẽ nó đã thành công nếu ban lãnh đạo đo được chất lượng và năng suất, nhưng đó là chuyện để than phiền vào một ngày khác
Người ta nói rằng “chính sự bối rối sinh ra câu hỏi sai mới là cơ hội”, nhưng nếu không phải chuyên gia hàng đầu trong lĩnh vực đó thì rất khó để ngay từ đầu phán rằng câu hỏi nào là sai
Thực ra vẫn nên trả lời.
Trừ khi bạn đang làm người gác cổng để bảo vệ tài nguyên tinh thần quý giá, còn không thì cứ theo chiến thuật ứng biến kiểu “vâng, và rồi…”. Dĩ nhiên vẫn có thể thêm rằng có thể còn những cách khác để đi đến kết quả mong muốn.
Khi cố gỡ một tình huống bế tắc, tốt hơn là dùng tất cả các chiến lược có thể thay vì chỉ bám vào một chiến lược