Đừng cố né tránh việc lắng nghe lời người khác bằng cách kỹ thuật hóa nó

• Trở ngại cốt lõi trong môi trường phần mềm không phải là thiếu đối thoại mà là thiếu lắng nghe; việc đổi nó thành những cách diễn đạt như framework hay system để giải quyết thực chất là né tránh việc lắng nghe cần thiết
• Làm đúng y như yêu cầu của ai đó khác với việc hiểu nhu cầu thực sự; hiệu ứng chuyên môn và lối phân đôi technical/non-technical khiến ta bỏ lỡ kiến thức và bối cảnh của đối phương
• Nếu cho rằng ai cũng có cùng mức năng lượng, kỹ năng và nguồn tiền, hoặc khái quát đặc điểm của một người cho cả tập thể, ta sẽ không nắm bắt đúng các ràng buộc và tiêu chí phán đoán khác nhau của từng người
• Con người và tổ chức thay đổi theo thời gian, vai trò, mức độ căng thẳng và động lực nhóm; điều họ nói ra cũng không phải lúc nào trùng với điều họ thực sự nghĩ, nên yêu cầu cố định rất dễ lệch khỏi quá trình làm phần mềm
• Thất bại trong lắng nghe khiến ta bỏ lỡ những insight giá trị nhất, dẫn tới mất cơ hội doanh thu và lợi thế cạnh tranh, đồng thời làm tăng tech debt do hiểu lầm tích tụ

---

Luận điểm cốt lõi

• Trong môi trường phần mềm, vấn đề cốt lõi lớn hơn việc thiếu đối thoại giữa con người là thiếu lắng nghe; việc cố giải quyết nó bằng cách đổi sang các thuật ngữ như framework hay system là một kiểu né tránh công việc thực sự cần làm
• Các nhà thiết kế và người phụ trách product thường cố chuyển việc đối thoại với con người thành cách diễn đạt mà engineering dễ tiếp nhận hơn, nhưng điều cần thiết không phải là một hệ thống tốt hơn mà là thực sự lắng nghe người khác nói gì
• Dựa trên tiền đề rằng lắng nghe lời người khác còn khó hơn cả việc trò chuyện với họ, bài viết tổng hợp những cái bẫy điển hình cản trở việc lắng nghe trong thực tế

Những cái bẫy điển hình cản trở việc lắng nghe

• Làm theo lời nói không đồng nghĩa với lắng nghe

  • Việc làm đúng những gì ai đó nói họ muốn không đồng nghĩa với lắng nghe nhu cầu thực sự
  • Các cách tiếp cận đã có liên quan đến chủ đề này như Jobs To Be Done, Outcome Driven Innovation, và empathy mapping trong lĩnh vực UX được nhắc đến

• Hiệu ứng chuyên môn khiến ta đánh giá thấp góc nhìn của chính mình

  • Khi học lâu trong một lĩnh vực cụ thể, rất dễ hình thành giả định kiểu "chuyện này thì ai cũng phải biết"
  • Dù đối phương cũng là chuyên gia trong lĩnh vực đó, họ chưa chắc biết cùng một kiểu tri thức; thay vào đó họ có thể biết một kiểu tri thức khác
  • Muốn lắng nghe đúng, cần hiểu nhiều hơn về việc đối phương biết gì

• Xem technical như một phạm trù đơn nhất

  • Đây là cái bẫy đặc biệt phổ biến với lập trình viên phần mềm: technical không phải một thuộc tính duy nhất mà là một phổ rộng gồm nhiều miền tri thức khác biệt
  • Nếu nhìn con người bằng lối nhị phân "technical / non-technical", ta sẽ bỏ lỡ insight và làm tăng khả năng không thể lắng nghe đúng

• Giả định rằng ai cũng có cùng nguồn lực

  • Nếu cho rằng ai cũng có cùng năng lượng, cùng kỹ năng và cùng khoản tiền nhàn rỗi, ta sẽ đưa ra phán đoán sai
  • Ngay cả những người có cùng tình trạng sức khỏe cũng có thể khác nhau về cách quản lý và những hành động thực tế họ làm được
  • Có người giỏi toán, có người mạnh ở năng lực khác, có người ít tiền hay ít dư địa hơn nên hành xử theo hướng tránh rủi ro nhiều hơn

• Khái quát đặc điểm của một người cho cả tập thể

  • Chỉ vì gặp một người có đặc điểm nào đó không có nghĩa những người còn lại cũng như vậy
  • Bài viết nêu ví dụ về thái độ mặc định rằng người lớn tuổi thì không hiểu máy tính
  • Việc quy toàn bộ phụ nữ về hình ảnh từ các quan hệ gia đình cá nhân cũng là cùng một sai lầm

• Giả định rằng con người và tổ chức là bất biến

  • Ở cấp độ vĩ mô, tính cách thay đổi theo thời gian
  • Ở cấp độ vi mô, persona tại nơi làm việc khác với con người ở nhà, và dưới căng thẳng hay trong điều kiện cụ thể thì phán đoán cũng thay đổi

• Giả định rằng lời nói và suy nghĩ là như nhau

  • Có người nói sao nghĩ vậy, nhưng cũng có người không như thế
  • Nhiều người tin rằng mình đang nói thật lòng, nhưng thực tế lại không hẳn vậy

• Phán xét con người

  • Nếu ghét bỏ hoặc dismiss một người vì họ hiểu sai thứ được tài liệu hóa sơ sài, khả năng lắng nghe đúng sẽ giảm đi rất nhiều
  • Thái độ mặc định rằng đối phương làm việc kém hoặc sống sai cách cũng là yếu tố cản trở việc lắng nghe

• Xem 80 người như một nhóm thay vì 80 con người riêng biệt

  • B2B thậm chí còn mang tính con người hơn B2C, vì trong đó quan hệ, động lực và những yếu tố như soft power ngoài sơ đồ tổ chức đều cùng vận hành
  • Khi có thêm động lực nhóm, các biến số phát sinh còn phức tạp hơn cấp độ cá nhân

Sự lệch pha giữa yêu cầu cố định và việc làm phần mềm

• Chính vì con người và tổ chức thay đổi nên fixed project management không phù hợp với việc làm phần mềm
• Dù yêu cầu được chốt ngay từ đầu, con người vẫn thay đổi trong khoảng thời gian đó, nên khi kết quả ra đời thì nhiều nhất nó cũng chỉ khớp với yêu cầu ở thời điểm bắt đầu
• Đến lúc phát hành, đó có thể không còn là thứ họ muốn nữa; trong thời gian chờ đợi, mỗi người lại tự thêm kỳ vọng riêng, nên thực tế sẽ không khớp với tất cả những kỳ vọng đó

Kết quả và tác động

• Nếu không thực sự lắng nghe người khác nói gì, ta sẽ bỏ lỡ những insight giá trị nhất, từ đó đánh mất cơ hội doanh thu và lợi thế cạnh tranh
• Càng nhiều hiểu lầm tích tụ, càng có thêm những yếu tố mới bị đưa vào phần code mà sau này mọi người phải cùng làm việc; việc lắng nghe cũng gắn với khả năng giảm bớt ít nhất một phần nguyên nhân gây ra tech debt
• Càng nhận ra những khoảnh khắc mình không lắng nghe được, khả năng lắng nghe tốt hơn sẽ càng cao

[GN⁺]

Ý kiến trên Hacker News

• Tôi là kiểu người chọn từ khá chính xác, và nếu tôi dùng một cách diễn đạt nào đó thì đúng là tôi có ý như vậy. Nhưng nhiều người, theo cảm nhận của tôi, lại nói kiểu như tone poem, lượn quanh bằng những từ ngữ gần đúng rồi mong người khác tự hiểu ra một sắc thái chung, nên bản thân việc diễn giải đã rất mệt. Khi tôi viết, tôi chọn từng từ một cách có chủ đích, thế mà ngay cả ở chỗ làm, lời tôi cũng gần như luôn bị hiểu như thể tôi đã diễn đạt không chính xác, điều đó khá đau đớn. Có thể tôi có xu hướng nằm trên phổ tự kỷ, nhưng chưa từng được chẩn đoán. Khoảng nửa năm trước, tôi làm một RPC nhỏ và viết tài liệu để bộ phận khác có thể bắt đầu một công việc dài hơi; tài liệu chưa đến một trang, nhưng đầy đủ, chính xác và súc tích. Thế mà quản lý của tôi lại cho tài liệu đó qua AI rồi chuyển tiếp đi mà không hề giải thích lý do, và tôi thậm chí còn không biết chuyện đó. Chưa đầy một ngày sau, hàng loạt phản hồi vô lý đổ về, và khi xem ví dụ yêu cầu thực tế thì hóa ra đã có thao tác chỉnh sửa endpoint. Không phải lỗi gõ nhầm, mà là một địa chỉ hoàn toàn bịa ra; trong tài liệu, endpoint và các tham số bắt buộc đều sai hết, thậm chí còn phát minh ra cả tính năng không tồn tại. Bình thường tôi khá nhẫn nhịn, nhưng chưa từng giận dữ như lúc đó, và đến giờ vẫn còn tức. Nếu thị trường việc làm không như hiện nay, có lẽ tôi đã nghỉ ngay rồi. Giao cho AI xử lý thứ ngôn ngữ mà con người lẽ ra phải tự đọc và tự diễn giải khiến tôi cảm thấy như đó là cái chết của ngôn ngữ nghiêm ngặt, và đã nhiều tháng nay tôi nghiêm túc nghĩ rằng generative AI có thể là một kiểu Great Filter đang hủy hoại nền văn minh

  • Tôi thấy góc nhìn này hơi xa lạ. Tôi không nghĩ lời nói có thể cắt rạch ròi ranh giới của tư duy rồi chứa trọn nó một cách chính xác; ngôn ngữ là công cụ để biểu đạt thế giới và sự hiểu của mỗi người, nên việc mô tả cùng một khái niệm bằng những lời khác nhau là điều tự nhiên. Với người chuyển suy nghĩ thành ngôn từ thì mọi thứ có vẻ rõ hơn, nhưng với người nghe thì không hẳn vậy. Vì thế tôi không nghĩ có thể xem nhẹ lao động diễn giải. Có lẽ nếu nói chuyện với phía bên kia của tình huống đó, họ rồi cũng sẽ nói điều tương tự rằng rốt cuộc lời của bạn khó diễn giải
  • Bối cảnh này quá mạnh nên tôi lập tức nghĩ tới tiểu thuyết. Ý tưởng kết nối Great Filter với generative AI rất hay, cảm giác như đây là một câu chuyện mà Cory Doctorow nên viết ngay
  • Trước hết tôi nghĩ phải hỏi vì sao quản lý lại đưa tài liệu đó vào AI. Đôi khi độ chính xác càng tăng thì độ dễ đọc lại càng giảm, và ngôn ngữ càng nén thì người đọc càng phải trả chi phí nhận thức lớn hơn cho từng từ. Đọc là quá trình dịch mô hình trong đầu người viết sang mô hình của người đọc, chứ không phải thứ tự động biến đổi chỉ bằng từ ngữ; nó đòi hỏi hành vi diễn giải. Quá súc tích có thể làm mất đi những điểm tựa giúp người đọc. Cũng có thể tài liệu một trang đó đối với độc giả phổ thông là quá ngắn, không đủ hỗ trợ việc hiểu, nên mới nảy sinh đường vòng kiểu tóm tắt bằng AI. Viết cho người đọc là một công việc hoàn toàn khác với việc ghi chú chính xác cho người đọc có cùng bối cảnh tối đa, và đặc biệt khi viết cho số đông không xác định thì cần thêm lặp lại, ví dụ dễ hiểu, bối cảnh quen thuộc, chia nhỏ quy trình, thậm chí đôi khi cả chút hài hước và giải thích nền để hỗ trợ việc hiểu
  • Gần đây tôi cũng gặp chuyện tương tự. Tôi viết một bản đặc tả dài 4 trang, nhưng người nhận không đọc mà chỉ dùng LLM rút ra vài bullet summary, và kết quả là một bản đề xuất không phù hợp với yêu cầu được gửi ngược lại. Khi tôi phản đối, anh ta nói nội dung đó lẽ ra phải có trong bản đặc tả, nhưng thực ra nó đã có sẵn rồi, chỉ là không có trong LLM summary của anh ta mà thôi. Tôi không phải kiểu ám ảnh từng từ, nhưng tôi không nghĩ thông tin của một tài liệu 4 trang có thể được chứa trọn vẹn trong 10 gạch đầu dòng
  • Ngược lại tôi thấy đây chính là trường hợp hoàn hảo cho một prompt chuyên dụng hay custom LLM để chuyển thứ này sang normie speak

• Chỉ cần nhìn phần bình luận này thôi tôi cũng thấy thật trớ trêu, vì có rất nhiều người đang tái hiện đúng vấn đề mà bài viết chỉ ra. Tôi muốn bổ sung thêm vài điều. Thứ nhất, dù tích lũy bao nhiêu tri thức và tranh luận đi nữa, nếu người ta không muốn tiếp nhận thì họ cũng khó mà tiếp nhận. Thứ hai, lắng nghe thật sự là đặt bản thân vào trạng thái dễ tổn thương cả về tinh thần lẫn thể chất. Bởi bạn có thể phải nghe những điều va chạm với kinh nghiệm, niềm tin và thế giới quan của mình, và thái độ phán xét người khác thường là một cơ chế tự vệ, nên chính vì thế ta lại càng không nghe được tốt. Thứ ba, lắng nghe thường là việc không nhảy ngay vào giải pháp mà là hấp thụ nỗi đau của đối phương rồi xử lý nó. Ví dụ, Product manager rất dễ quy hết mọi thứ thành tính năng mới hay ticket, nhưng thực ra cần nghe use case, tìm ra điểm đau và giải quyết nó, chứ không nên chỉ cố hiểu cái tên tính năng mà người dùng yêu cầu

  • Tôi thấy việc mặc định tiền đề này từ trước là nguy hiểm. Phần lớn mọi việc đều có dư địa để thương lượng, và nếu biết cách thương lượng cho đúng thì mọi thứ có thể khác đi
  • Tôi đặc biệt thấy ý số 2 rất sâu sắc. Tôi rất muốn gửi câu này cho một người quan trọng với mình, và hy vọng người đó cũng thực sự listen
  • Tôi đồng cảm với ý lắng nghe là một hành động dễ tổn thương, nhưng cũng nghĩ rằng nếu có sự bảo đảm rằng sự tổn thương đó sẽ không bị lợi dụng mỗi lần, thì tôi sẵn sàng dành thời gian để luôn lắng nghe cho tử tế
  • Tôi thật sự tò mò. Việc hấp thụ nỗi đau của người khác trên thực tế nghĩa là gì, và từ đó làm sao chuyển tự nhiên sang việc định nghĩa tính năng hay viết ticket?
  • Tôi cảm thấy mô tả này chính là bản chất của presales discovery. Đây thực sự gần với nghệ thuật hơn là kỹ thuật

• Tôi đồng ý với mối bận tâm, nhưng danh sách này đọc hơi giống một lời than vãn. Giao tiếp hiệu quả gần như là vấn đề cốt lõi của toàn nhân loại, còn bài này lại có sắc thái quở trách rằng lập trình viên không biết lắng nghe, nên hơi trịch thượng. Vấn đề gốc là con người không biết mình không biết điều gì. Những người giao tiếp giỏi nhất giống như dịch giả, và chỉ khi thông điệp trở nên hiển nhiên trong khuôn khổ hiểu biết của người nghe thì họ mới thực sự tiếp nhận. Tôi không nghĩ đây chỉ là một sự sụp đổ đơn giản vì ai cũng cư xử như trẻ con bịt tai. Vì vậy chúng ta mới đi tìm hệ thống và kỹ thuật, để hệ thống tích hợp sẵn cơ chế phát hiện khoảng cách và khung dịch nghĩa. Dù không hoàn hảo, tôi vẫn nghĩ thay đổi môi trường ở cấp đội ngũ, công ty, hệ thống quan trọng hơn là chỉ dạy bảo từng cá nhân phải lắng nghe tốt hơn

  • Tôi nhớ có lần một ông lão bảo hãy nhìn chuyện này như một Noisy system. Tín hiệu lúc nào cũng yếu hơn nhiễu, và bên trong hệ thống đó là những con người hữu hạn. Mỗi người đều có giới hạn về những gì mình làm được, có giới hạn về tốc độ cập nhật mô hình tư duy, và giới hạn của tập thể còn thấp hơn của cá nhân. Đặc biệt, những tổ chức lớn có thể mất hàng chục năm để thay đổi mô hình sẵn có ngay cả khi thực tại đã thay đổi hoàn toàn. Vì vậy tôi thấy điều quan trọng là thừa nhận những ràng buộc đó rồi quyết định mình sẽ dùng thời gian và năng lượng vào đâu
  • Tôi thấy bài này chỉ giống một bài self-help bình thường, thậm chí còn hơi kém hơn vì thiếu ví dụ
  • Tôi là lập trình viên nhưng cũng đã làm khá nhiều việc khác, nên hiểu rõ tầm quan trọng của giao tiếp và việc lập trình viên thường yếu ở đó đến mức nào. Mẫu hình quen thuộc là họ giống bác sĩ tồi: giả vờ lắng nghe rồi chẩn đoán quá sớm. Trước khi đối phương nói hết điều quan trọng, họ đã tuyên bố mình biết cần gì rồi. Trong phần mềm, thứ quan trọng hơn điều khách hàng muốn thường là điều khách hàng thực sự cần. Rất hiếm khách hàng biết cách giải quyết vấn đề một cách thanh lịch bằng phần mềm, và thường thì người mang ý tưởng đến là ai đó chưa từng suy nghĩ sâu về phần mềm. Điều đó không có nghĩa ý tưởng của họ vô giá trị, mà có nghĩa là việc làm rõ yêu cầu và tìm ra giải pháp vẫn chưa xong. Cách hoàn thiện nó là quan sát, giải thích và đối thoại. Theo kinh nghiệm của tôi, nhiều lập trình viên thật sự không nghe tốt, mà bác sĩ hay các nghề kỹ thuật khác cũng tương tự. Họ muốn nhanh chóng tỏ ra có năng lực bằng cách cho thấy mình biết nhiều đến đâu, rồi phân loại đối phương vào một kiểu vấn đề mà họ đã gặp rất nhiều. Đôi khi cách đó có hiệu quả, nhưng đến lúc không hiệu quả thì nhất định sẽ hỏng
  • Nói đùa thôi, nhưng nếu giao tiếp thật sự là vấn đề trung tâm của nhân loại thì lẽ ra Bible cũng phải có một câu nào đó về chuyện này chứ

• Tôi nghĩ không nên dễ dàng giả định rằng điều người ta nói và điều họ thật sự nghĩ là một. Ngược lại, người nói cũng rất dễ tưởng rằng người nghe đang hình dung và hiểu cùng một đối tượng với mình. Vì vậy điều quan trọng là phải viết ra sao cho chi tiết và không mơ hồ nhất có thể. Nếu trong cuộc họp có người cố giải thích mục tiêu chỉ bằng một bullet 6 từ, thì với tôi đó gần như là tín hiệu rằng không ai thực sự hiểu mục tiêu. Nếu một người bước vào cuộc họp mà không có nổi một trang tài liệu, thì nghĩa là họ vẫn chưa hiểu nó đủ sâu, và nếu tiến độ của tôi phụ thuộc vào kết quả đó thì tôi sẽ đòi một bức tranh rõ hơn

  • Tôi thường xuyên rơi vào tình huống phải hỏi đồng nghiệp about what? vài lần mỗi ngày. Nhiều khi phải hỏi lại 4-5 lần cho đến khi họ nói cụ thể là khách hàng nào, tính năng gì, sản phẩm nào. Thậm chí có lúc tôi biết chính xác họ đang nói gì mà vẫn phải làm vậy
  • Tôi cảm thấy tính chính đáng của yêu cầu cũng luôn cần được xem xét. Vì cách dễ nhất để che giấu việc không biết nhu cầu thật sự là gì chính là đòi hỏi quá mức. Theo kinh nghiệm của tôi, chuyện đòi gấp 10 lần thứ thực sự cần là rất phổ biến, và tôi từng nghe cả những câu kiểu phải mua cấu hình cao nhất nếu không muốn lo về tương lai, trong khi giữa các lựa chọn có chênh lệch chi phí 500 lần
  • Tôi nghĩ việc viết chi tiết và không mơ hồ có thể là điều kiện tiên quyết cho sự thấu hiểu sâu sắc lẫn nhau, nhưng vài năm gần đây tôi thấy mọi người thật sự hầu như không đọc quá câu đầu tiên của tin nhắn, ticket hay email. Vì vậy người ta phải bẻ nhỏ thông tin thành những mẩu cực nhỏ rồi đút từng chút một, và tôi rất ghét điều đó
  • Tôi cảm thấy chuyện này ngoài đời xảy ra quá thường xuyên. Khi tôi nói chưa sẵn sàng cho production, ban lãnh đạo lại thường hiểu nó theo kiểu có thể bán cho khách như acceptance testing
  • Tự nhiên ở đây tôi nhớ đến bộ phim thời Liên Xô Kin-dza-dza. Trong đó có một nhân vật nói về người khác rằng anh ta nói những điều mình không nghĩ và nghĩ những điều mình không nghĩ, và tôi thấy câu đó diễn tả khá đúng sự rối loạn của kiểu hội thoại này

• Tôi chủ yếu làm vai trò quản lý quan hệ khách hàng, nên tôi cho rằng công việc quan trọng nhất là đưa kỳ vọng của khách hàng về đúng với thực tế. Nếu kỳ vọng của khách hàng khớp với những gì có thể làm được, mất bao lâu, tốn bao nhiêu, và khi nào có thể lên production, thì dù họ không thích ngày bắt đầu hay chi phí, cuối cùng họ vẫn là khách hàng hài lòng. Đặc biệt chi phí thường là yếu tố làm đổ vỡ thương vụ, nên tôi hay chốt sớm khoảng ước lượng ban đầu. Dù có lắng nghe và đồng cảm tốt đến đâu thì thực tế vẫn là thực tế, và khách hàng cũng phải thừa nhận hoặc chấp nhận những ràng buộc đó. Người phụ trách khách hàng mà cái gì khách muốn cũng hùa theo thì rốt cuộc chỉ khiến khách hàng bất hạnh hơn, và một người làm cầu nối giỏi phải lắng nghe cả khách hàng lẫn đội nội bộ để đảm bảo thứ thực sự có thể giao được khớp với kỳ vọng của khách hàng

• Tôi cảm thấy có lẽ chúng ta đang dành quá nhiều thời gian cho giao tiếp. Khi thời gian được phân quá rộng, sự tập trung sẽ loãng đi, và người ta dễ trì hoãn với suy nghĩ kiểu đằng nào lần sau cũng làm rõ tiếp được. Tôi nghĩ nếu cắt bớt các cuộc họp không cần thiết và chỉ dành minimum viable time thì mọi người ngược lại sẽ nghe tốt hơn

  • Tôi hầu như chưa từng thấy hiện tượng này ngoài đời. Phần lớn các cuộc họp thực ra không phải giao tiếp mà gần với chỉ đạo và thông báo hơn, còn khả năng lắng nghe là một kỹ năng riêng, không liên quan đến độ dài cuộc họp. Lắng nghe là năng lực được rèn bằng thực hành, chứ không tự nhiên xuất hiện chỉ vì rút ngắn thời lượng họp
  • Tôi đã dự quá nhiều cuộc họp mà kết quả duy nhất là lên lịch cho cuộc họp tiếp theo. Tôi còn thấy cả kiểu kéo thêm người vào, đội đông người thì lái quyết định về phía mình để giành ảnh hưởng chính trị, rồi điều đó lại dẫn đến thêm tuyển dụng và thêm họp vô nghĩa. Lối thoát không phải là tăng giao tiếp mà là dựng một tầm nhìn thống nhất, giảm phụ thuộc giữa các đội để mỗi đội có thể làm việc độc lập
  • Trong công việc kiến trúc phần mềm, tôi thường thấy chỉ một sơ đồ thôi đã tiết kiệm được hơn 60 phút tranh luận và nhiều cuộc họp lặp lại. Dù không vẽ quá đẹp, chỉ cần bức hình bám sát sự thật là đủ, và với những logic phức tạp hay không hiển nhiên thì diagram rõ ràng hơn lời nói rất nhiều. Nếu họp từ xa thì dùng AI agent với Mermaid.js để vẽ nhanh, còn gặp trực tiếp thì bảng trắng hoặc giấy bút là đủ
  • Tôi thấy dành thời gian cho giao tiếp và thực sự giao tiếp là hai việc hoàn toàn khác nhau
  • Tôi nghĩ vấn đề thường không phải là ta dành quá nhiều thời gian để giao tiếp, mà là dành quá nhiều thời gian để giả vờ đang giao tiếp. Người ta cố mở những cuộc họp còn chưa đủ điều kiện, tiến hành mà không có tiền đề, ném ra một AI slop document làm qua loa, rồi khi người khác không hiểu thì lại đổ cho người đọc là kém. Ba mươi phút đầu của cuộc họp trôi qua như gaslighting, rồi đến 10 phút cuối mới thừa nhận là phí thời gian và cố cứu vãn. Đáng ra cuộc họp phải là nơi chia sẻ suy nghĩ đã được ủ kỹ và một hướng đi nhất quán, nhận phản hồi có ý nghĩa cho một lập luận rõ ràng; nhưng trên thực tế thường chỉ là cả nhóm phải xử lý nỗ lực của ai đó muốn biến việc riêng của mình thành dự án nhóm kiểu stone soup. Nếu ngay từ đầu hỏi mục tiêu của cuộc họp là gì, nhiều khi sẽ lộ ra rằng người tổ chức chỉ đang mở một nhóm học bài đơn thuần. Những nhà quản lý chỉ nhìn ở tầm cao thường tưởng công việc được thực hiện trong cuộc họp, nhưng họ không thấy được công đoạn tư duy cần thiết trước một cuộc họp tốt. Nếu vội giao tiếp trước khi suy nghĩ được làm rõ, cuộc họp chỉ là nhiễu. Trong những tình huống như vậy, phản ứng mạnh nhất là thái độ cùng tìm hiểu ngay bây giờ, và tôi buộc mọi người tôn trọng chuỗi phụ thuộc Why, What, How, Who, When. Nếu phần trước còn trống thì không được nhảy sang phần sau, và dù là intern hay VP cũng không được phép lấp liếm dễ dãi. Nếu đã mổ xẻ vấn đề và suy nghĩ ngay tại chỗ mà đội vẫn không thay đổi, thì cuối cùng có lẽ nên tìm đội khác

• Tôi thấy nhận xét của bài về specialism effect khá bị đánh giá thấp. Tôi cũng từng bực vì người dùng không hiểu những gì tôi đã hấp thụ suốt nhiều năm, nhưng rồi sớm nhận ra vấn đề không phải họ thiếu kiến thức, mà là kiến thức của họ được tích lũy ở chỗ khác. Họ cũng đã dành quãng thời gian đó để đào sâu những thứ hoàn toàn khác

• Tôi không hoàn toàn đồng ý với lời giải thích rằng nguyên nhân cốt lõi là mọi người không nói và không nghe. Mượn ví dụ truyện tranh, tôi nghĩ nhiều người ngay từ đầu đã muốn cắt băng khánh thành hơn là muốn con đường, và vì họ đã đạt được thứ đó nên mọi chuyện mới thành ra như vậy

• Tôi từng có những trải nghiệm khá buồn cười với những người nói rằng bản thân họ nghĩ sao nói vậy nhưng thực tế lại không phải thế. Tôi gần như chỉ nhắc lại lời họ bằng cách diễn đạt hơi khác đi để xác nhận hiểu đúng, thế mà phản ứng nhận lại là sự phủ nhận rất mạnh, rằng đó tuyệt đối không phải điều họ định nói

• Tôi thấy cốt lõi của nhiều vấn đề khi nói chuyện với các bộ phận không kỹ thuật là họ chỉ đơn giản nói hãy thêm X, đổi Y mà không hề có bối cảnh chi phí. Tất nhiên gần như yêu cầu gì cũng làm được, nhưng mỗi yêu cầu đều có chi phí, và nếu không hiểu điều đó thì rất khó dung hòa với việc phát hành sản phẩm đáng tin cậy

  • Tôi lại thấy phản hồi này chính là minh họa hoàn hảo cho ý chính của bài. Không phải họ không hiểu chi phí, mà chỉ là bối cảnh khác nhau, và vai trò của người kỹ thuật không phải là chờ họ tự biết trước chi phí, mà là giúp họ đưa ra tradeoff dựa trên thông tin
  • Tôi cảm thấy các câu hỏi whys rất quan trọng trong tình huống này. Nếu hiểu quy trình phi kỹ thuật thì có khi việc thêm hay đổi đó thực ra chẳng cần thiết chút nào. Tôi cũng đồng ý rằng nếu cái gì cũng nhét vào thì cuối cùng sẽ thành một con quái vật kiểu Turing complete Excel/Email clone
  • Tôi nghĩ trong những tình huống này thường có sự bất đối xứng: phía không kỹ thuật không biết chi phí, còn phía kỹ thuật lại không biết lợi ích. Cuối cùng vẫn phải có giao tiếp từ cả hai phía mới tìm được điểm cân bằng chi phí/lợi ích ổn ổn
  • Tôi thấy đây là vấn đề khá có thể giải quyết. Chỉ cần với mỗi yêu cầu, trả lời bằng ước lượng mất bao nhiêu tháng và tốn bao nhiêu tiền, theo đơn vị tháng và đô la
  • Tuy nhiên tôi cũng thấy thực tế là dạo này AI đang làm thay khá nhiều phần code thing, nên bản thân chi phí triển khai đã giảm đáng kể. Dù thích hay không thì cũng phải thừa nhận thay đổi đó