Khi làm quản lý sản phẩm, mình luôn cố gắng tạo không gian để tất cả mọi người trong team của mình cùng thống nhất một quyết định - nó cho mọi người cảm giác dân chủ và tăng tính trách nhiệm của từng cá nhân đối với dự án.
Tuy nhiên, gần đây mình mới biết rằng, làm vậy không phải lúc nào cũng hiệu quả. Số đông vẫn có thể sai. Thậm chí, đôi khi để một cá nhân quyết định khéo khả năng cao lại đúng đắn hơn.
Hai nhà tâm lý học Garold Stasser và William Titus đã thực hiện một thí nghiệm, trong đó người tham gia (cá nhân) được yêu cầu lựa chọn dự án tối ưu nhất A, B hoặc C, sau khi được đọc toàn bộ thông tin về các dự án đó.
Cùng thí nghiệm đó, hai nhà tâm lý hỏi thêm cả các nhóm nhỏ, với yêu cầu tương tự - lựa chọn một trong ba dự án mà họ thấy tối ưu nhất.
Lưu ý là, trong ba dự án này, có một dự án đã được chủ đích thiết kế để "trông" tối ưu hơn cả (B), và một người với logic thông thường có thể dễ dàng nhận ra.
Điểm khác biệt lớn nhất giữa hai thí nghiệm này, đó là ở thí nghiệm cá nhân, mỗi người tham gia được đọc đầy đủ thông tin về mỗi dự án. Còn trong thí nghiệm nhóm, mặc dù mỗi nhóm đều được đưa đầy đủ thông tin về mỗi dự án, nhưng thông tin này sẽ bị phân tán không đồng đều tới các thành viên. Nghĩa là mỗi người sẽ nắm một mảnh ghép của một bức tranh lớn. Về lý thuyết, nếu như các thành viên chia sẻ thông tin hết cho nhau, họ sẽ vẫn ghép được một bức tranh hoàn chỉnh và sẽ nhận ra đâu là dự án tối ưu nhất.
Điều thú vị xảy ra khi có tận 80% cá nhân chọn đúng dự án tối ưu nhất, trong khi chỉ có 31% nhóm chọn đúng. Và còn thú vị hơn khi mà số lượng nhóm chọn các dự án A, B, C là đều nhau!
Để lý giải cho hiện tượng này, chúng ta cần nhìn kĩ hơn vào cách thông tin được/bị các nhà nghiên cứu phân tán ở trong thí nghiệm nhóm:
Dự án A và C: toàn bộ thông tin tích cực được chia sẻ đều với các thành viên. Các thông tin tiêu cực thì mỗi thành viên sẽ biết một ít.
Dự án B (về lý thuyết là tối ưu nhất): toàn bộ thông tin tiêu cực được chia sẻ đều với các thành viên. Các thông tin tích cực thì mỗi thành viên sẽ biết một ít.
Việc dự án A, B, C nhận được tỉ lệ bình chọn gần như ngang nhau, trong khi B mới tối ưu nhất, cho thấy hai điều:
Các nhóm đánh giá dự án B kém hơn so với tiềm năng của nó. Điều đó có nghĩa thông tin tiêu cực mà được chia sẻ đều cho các thành viên có sức ảnh hưởng lớn hơn các thông tin tích cực bị phân tán riêng lẻ.
Các nhóm đánh giá dự án A và C tốt hơn so với tiềm năng của nó. Điều đó có nghĩa thông tin tích cực mà được chia sẻ đều cho các thành viên có sức ảnh hưởng lớn hơn các thông tin tiêu cực bị phân tán riêng lẻ.
Tới đây, có lẽ bạn đã nhận ra "kẻ phá hoại": Những thông tin mà ai cũng biết sẽ có tầm ảnh hưởng lớn (hơn) tới quyết định của cả một tập thể.
Garold Stasser và William Titus gọi đây là "Hiệu ứng kiến thức chung": những kiến thức mà ai cũng biết sẽ có cơ hội được chia sẻ nhiều hơn, do đó nhận được sự đồng thuận của mọi người cao hơn.
Và khi một kiến thức được nhiều người hưởng ứng, nó càng khiến cho những người khác (cũng biết kiến thức này) muốn đồng tình hơn, phần vì áp lực xã hội (sợ trở thành cừu đen), phần vì muốn tránh xung đột với đồng nghiệp. Và khi mà suy nghĩ cá nhân về vấn đề bị ảnh hưởng bởi đội nhóm, chúng ta sẽ dễ tự thuyết phục bản thân rằng phần thông tin độc nhất (và trái ngược với mọi người) mà mình có cũng không quá quan trọng đến thế, hoặc chỉ đơn giản là có nói ra cũng không thay đổi được điều gì…
Ở trong một team làm sản phẩm, một số role sẽ thuộc nhóm thiểu số, ví dụ như designer hoặc data analyst, trong khi những role như developers (hoặc có thể là PM) sẽ có nhiều người hơn hẳn. Điều này làm tăng số lượng kiến thức chung (do developers/PM sở hữu) trong nhóm lên, và nó có thể áp đảo phần kiến thức/ ý kiến của những người thuộc các nhóm còn lại.
Như vậy ngay cả khi mình, một PM, họp mọi người lại, và trong đầu mọi người có thông tin cần thiết cho dự án, chưa chắc họ đã nói ra, hoặc kể cả nói ra thì kết quả cuối sẽ vẫn bị ảnh hưởng bởi hàm lượng kiến thức chung từ nhóm developers sẽ được nói tới nhiều hơn và do đó ảnh hưởng tới quyết định của nhóm sâu sắc hơn.
Trong trường hợp này, PM phải làm gì?
Mình xin được mạnh dạn đề xuất một số ý kiến như sau. Một người PM nên:
Tích cực đóng vai trò "trọng tài", làm người khách quan nhất trong nhóm và chỉ ra thông tin của nhóm nào đang áp đảo và thông tin của nhóm nào đang chưa được chia sẻ.
Tạo ra môi trường đủ an toàn để các role "lép vế" không cảm thấy bị áp lực hoặc sợ nêu ý kiến riêng
Ưu tiên việc thu thập dữ liệu từ mọi người, kể cả việc đó phải làm với từng người và mất nhiều thời gian hơn
Trình bày được toàn bộ thông tin cho mọi người một cách công khai và khách quan nhất. Đồng thời, dành thời gian để mọi người nhìn và xử lý được toàn bộ lượng thông tin của người khác, trước khi yêu cầu họ đưa ra quyết định.
Nhìn vào danh sách này, mình tự tin để nói rằng cái "nghề PM", nghe thì có vẻ là chẳng làm một cái gì cụ thể như data hay dev, và nghe thì "ai mà chả làm được", nhưng thực tế thì không phải ai cũng có đủ cái mặt dày, cái sự kiên nhẫn và khách quan để làm những việc đó.
Nếu bạn muốn đọc kĩ hơn về nghiên cứu này, đây là bài viết gốc: Link
Havard Business Review cũng có một bài viết tương tự về vấn đề này: When crowds aren’t wise
Weekly discovery: ELI5
Nếu bạn chưa biết tới ELI5 thì xin hãy dành chỉ vài phút để đọc hết phần giới thiệu của mình và thử lướt qua ELI5 xem nhé!
ELI5, hay Explain Like I'm 5 (link), là một kênh reddit siêu thú vị, nơi những vấn đề phức tạp được giải thích một cách siêu dễ hiểu, như cho một đứa trẻ. Các câu hỏi ở đây bao gồm rất, rất nhiều chủ đề trên trời dưới biển.
Khi mình đang muốn hiểu nhanh một vấn đề nào đó, mình sẽ tìm trên Google theo cú pháp: {tên vấn đề} + {ELI5} để xem trên kênh reddit này có ai giải thích chưa. Và cái hay của kênh này đó là kể cả khi một câu hỏi đã có người trả lời, những người khác vẫn tích cực vào comment, và nhờ đó mình có thể xác thực được tính chính xác của comment đầu tiên/ được nhiều upvote nhất.
Hai câu hỏi mình rất thích trong tháng vừa rồi:
Vì sao con người có thể sản xuất lại các bộ phim cũ ở định dạng 4k?
Vì sao iPhone có thể nghe "Hey Siri" trong khi không nghe trộm bạn?
Một tí về On Life
Woa, mình không ngờ số On Life đầu tiên lại được các bạn đón nhận nhiệt tình tới như vậy! Thời gian này mình hơi bận, nên mình rất xin lỗi các bạn đã comment mà mình chưa kịp trả lời :-< Mình chỉ muốn các bạn biết rằng mình đã đọc hết, và đang dành thời gian để suy ngẫm về từng comment một! Mình cũng rất mong bạn có thể dành thời gian để đọc (tính tới thời điểm này) 14 comments trên bài post đó - mình cảm thấy vô cùng thú vị và hữu ích.
Nếu như bạn chưa biết tới On Life, mình giới thiệu về chuyên mục này ở lá thư số 111.
Còn nếu bạn đã biết tới On Life, và có một câu hỏi đau đáu trong lòng, đừng ngại gửi cho mình qua form này nhé, mình sẽ giúp bạn đăng lên số On Life tiếp theo để các bạn đọc cùng vào chia sẻ suy nghĩ, lời khuyên.
Cảm ơn bạn đã dành thời gian đọc thư! Đừng ngại chia sẻ lá thư này tới bạn bè nếu bạn thấy nó hữu ích!
Như thường lệ, nếu có điều gì newsletter này làm bạn suy nghĩ, hoặc mình có thể làm tốt hơn, hãy reply và chia sẻ với mình, mình sẽ rất rất vui đó
(*๑˘◡˘)
Chúc bạn một buổi tối thư giãn và một tuần mới thật năng suất!
Thân,
Tuấn Mon
Hello anh, newsletter tuần này hay quá ạ. Em nghĩ nó vượt ra khỏi công việc PM để apply cho bất kì việc nào cần nhiều teamwork. Thông thường làm teamwork cũng dễ có khả năng một (vài) bạn dominate các thành viên team, nên as a team lead thì cũng nên áp dụng những ý kiến anh gợi ý bên trên. Hồi học môn Organizational Behavior, có một term em thấy cũng khá relevant đến topic này. Group think là hiện tượng các thành viên có xu hướng chấp nhận một quan điểm hoặc kết luận đại diện cho sự đồng thuận của nhóm, cho dù các họ có hoặc không tin rằng nó hợp lý, chính xác hay tối ưu. Điều tệ là Group think trong thời gian dài sẽ dẫn đến hệ quả khá nghiêm trọng - ảnh hưởng đến năng suất, hiệu quả việc nhóm, giảm khả năng sáng tạo và critical thinking của thành viên team, khó chấp nhận idea mới (bảo thủ & fixed mindset). Vì thế nên nếu không phải project-based cross-function team thì một nhóm làm với quá lâu (năm) sẽ không thật sự là green-flag ạ :DD
Inspired bởi Onlife01, chắc mình sẽ sống thoải mái hơn khi mình bớt lo sợ và pay it forward nhiều hơn ạ :D.
Hello a ạ, tuần này lại là 1 bài viết mà e thấy rất thích liên quan đến 1 khía cạnh của PM ạ. E cx muốn hỏi thêm chút là với các roles bị "lép vế" hơn thì a thường làm thế nào để encourage mn lên tiếng ạ?