- Cũng như nghiên cứu cho thấy trong Thế chiến II, thực tế chỉ 15~20% binh sĩ thực sự nổ súng, phần lớn thành quả thực chất trong tổ chức được tạo ra bởi một số ít người
- Ngành công nghệ đã đưa ra "hợp tác" như lời giải cho vấn đề này, nhưng trên thực tế chỉ làm gia tăng các công cụ điều phối công việc trong khi sản phẩm đầu ra hầu như không xuất hiện, và cấu trúc đó dần cố định
- Khi tập thể càng lớn, chi phí giao tiếp và chi phí điều phối bùng nổ, kéo theo hiện tượng trách nhiệm bị khuếch tán khi các cuộc họp sinh ra thêm nhiều cuộc họp khác
- Khi tính minh bạch bị nhầm lẫn với tiến độ, và tính hiển thị bị nhầm với trách nhiệm, văn hóa hợp tác trở thành cơ chế làm loãng trách nhiệm cá nhân
- Trên thực tế, phần lớn công việc phức tạp và chất lượng cao được thực hiện bởi cá nhân hoặc nhóm nhỏ có quyền hạn và trách nhiệm rõ ràng, còn hợp tác chỉ đóng vai trò như ngôn ngữ để tô vẽ điều đó
- Điều thực sự cần không phải là hạ tầng hợp tác mà là khả năng phán đoán chủ động và trách nhiệm cá nhân (ownership), và các tổ chức cần chuyển hướng sang việc tin tưởng điều đó
Ảo tưởng mang tên hợp tác
- Hợp tác (collaboration) thường được xem như biểu tượng của năng suất trong các tổ chức hiện đại, nhưng trên thực tế lại vận hành như một cấu trúc né tránh trách nhiệm và kém hiệu quả
- Theo nghiên cứu của S.L.A. Marshall trong Thế chiến II, chỉ khoảng 15~20% binh sĩ thực sự nổ súng trong chiến đấu
- Tương tự mô hình mà IBM phát hiện trong thập niên 1960 rằng “80% mức sử dụng đến từ 20% tính năng”, một số ít thành viên tạo ra phần lớn kết quả
- Những người còn lại chỉ cung cấp “hỗ trợ mang tính cấu trúc (structural support)”, và sự mất cân bằng trong nỗ lực liên tục lặp lại trong tổ chức
- Để giải quyết vấn đề này, ngành công nghệ đã bắt đầu tôn sùng khái niệm “hợp tác” như một đức tin
- Hàng loạt công cụ hợp tác như Notion, ClickUp, Slack, Jira, Monday, Teams đã xuất hiện, nhưng hoạt động (activity) tăng lên nhiều hơn sản phẩm đầu ra (output)
- Tính minh bạch và khả năng hiển thị bị ngộ nhận là tiến triển hay trách nhiệm, và “được đưa vào một thread” bị đồng nhất với “sở hữu kết quả”
- Vì thế, hợp tác bị biến chất thành mô phỏng của sự tham gia thay vì tạo ra kết quả thực sự
- Sự khuếch tán trách nhiệm (diffusion of responsibility) là hiện tượng đã được quan sát từ lâu
- Hiệu ứng Ringelmann năm 1913 cho thấy khi quy mô nhóm tăng lên thì tỷ lệ nỗ lực của từng cá nhân giảm xuống
- Năm 1975, Frederick Brooks đã nêu ra quy luật qua trường hợp IBM System/360 rằng thêm người vào một dự án đang chậm sẽ khiến nó chậm hơn nữa
- Càng nhiều người, chi phí giao tiếp và chi phí điều phối càng tăng theo cấp số nhân, tạo ra vòng luẩn quẩn khi các cuộc họp sinh ra thêm nhiều cuộc họp khác
- Dù ngành công nghiệp hợp tác đã đổ nguồn lực khổng lồ để che giấu vấn đề cấu trúc này, công việc chất lượng cao thực sự vẫn do một số ít cá nhân hoặc các nhóm nhỏ đảm nhiệm
- Dostoevsky đã một mình viết Anh em nhà Karamazov, còn Apollo Guidance Computer được phát triển bởi một nhóm nhỏ của MIT dưới cơ chế trách nhiệm rõ ràng
- Thành quả thực sự đến từ quyền hạn rõ ràng và trách nhiệm cá nhân, còn hợp tác chỉ vận hành như thứ ngôn ngữ dùng để đóng gói kết quả đó
- Trong khi đó, các tổ chức hiện đại chỉ xây dựng một hạ tầng hợp tác phức tạp để phục vụ quản trị xã hội (social management), còn công việc thực tế bị đẩy xuống hàng sau
- Quyền sở hữu thực sự (ownership) tồn tại dưới dạng cá nhân tự đưa ra quyết định và tự gánh lấy kết quả
- Nhưng trong môi trường mà hợp tác đã trở thành chuẩn mực văn hóa, việc tự quyết một mình lại bị xem là hành vi thiếu hợp tác
- Hệ tư tưởng hợp tác đã khiến trách nhiệm và tinh thần chủ động bị cảm nhận như hành vi phản xã hội, từ đó làm suy yếu cơ chế cốt lõi của sản xuất
- Họp hành, tài liệu, hồi cứu, kickoff cứ lặp đi lặp lại bất tận, nhưng cuối cùng chỉ còn lại sự điều phối quá mức không gắn với thực thi thực tế
Sự cần thiết phải quay lại với trách nhiệm cá nhân
- Phần lớn dự án đã chuyển sang cấu trúc thời gian điều phối > thời gian thực thi, và khi thất bại thì lời giải lại thường là “cần nhiều hợp tác hơn”
- Nhưng câu hỏi thực sự phải là: chúng ta đang tạo ra cái gì, và ai là người chịu trách nhiệm cho nó?
- Dù là việc gì đi nữa, người chịu trách nhiệm cuối cùng phải là một người duy nhất, ngay cả khi cấu trúc hợp tác che khuất điều đó
- Cần khôi phục niềm tin vào cá nhân
- Không cần cả tổ chức cùng giám sát mọi trách nhiệm
- Thay vì quản trị quá mức và văn hóa ám ảnh bởi chỉ số, mỗi cá nhân cần tự quản công việc của mình và được đánh giá bằng kết quả
- Khi thất bại, cần có cấu trúc quy trách nhiệm rõ ràng cho cá nhân đó
- Cần từ bỏ ảo tưởng về nỗ lực tập thể và quay về một môi trường có thể nhận diện rõ ai là người thực sự hành động
- Quay lại cấu trúc đơn giản, nơi mỗi người tự quản phần việc của mình và được đánh giá bằng kết quả
- Chỉ khi buông bỏ thứ hư cấu “hợp tác” nghe có vẻ ấm áp nhưng đắt đỏ, ta mới có thể nhìn rõ ai là người thực sự bóp cò
19 bình luận
Có vẻ như đây chỉ là một bài viết dài để tuyên bố rằng "tôi không thể cộng tác". Trong một tổ chức quy mô lớn, đúng là có những lúc khái niệm cộng tác trở thành lực cản, nhưng ngay cả điều đó cũng là hiện tượng phát sinh vì cộng tác không tốt, chứ không phải vấn đề của bản thân việc cộng tác.
Có vẻ tính cách của tác giả hơi không ổn lắm.
kkkkkkkkkkkkkkkk trời ơi tôi cười bể bụng luôn rồi kkkk
"Trong Thế chiến II, thực tế chỉ có 15~20% binh sĩ nổ súng"
Các nghiên cứu và bài luận tiếp theo phản biện trực diện và phân tích tuyên bố "tỷ lệ nổ súng 15~20%" của Marshall đã được giới sử học quân sự xem xét với trọng lượng khá lớn. Từ sau thập niên 1980, khi nhiều sử gia và chuyên gia quân sự lần theo hồ sơ nghiên cứu của Marshall, họ đi đến kết luận rằng con số này trên thực tế либо bị ngụy tạo, либо bị phóng đại một cách nghiêm trọng.
Robert Engen (2010) đã phân tích khảo sát và hồ sơ tác chiến của các sĩ quan bộ binh Canada trong Thế chiến II, những người chiến đấu trong môi trường tương tự quân đội Mỹ. Ông chứng minh rằng tỷ lệ nổ súng thực tế của quân Canada cao vượt trội so với mức 15~20% mà Marshall đưa ra, và phản bác rằng lập luận của Marshall là một lỗi khái quát hóa nghiêm trọng, không thể áp dụng cho toàn bộ lực lượng Đồng Minh phương Tây.
Ngay từ đoạn đầu đã thấy có gì đó không ổn nên tôi thử tìm hiểu, và có vẻ đây là một thông tin bị truyền sai. Những gì người ta nói trong phần bình luận trên Hacker News bên dưới cũng vậy.
Ý kiến trên Hacker News
Trong hơn 30 năm làm nghề này, điều tôi thấy là “ngày chốt (date)” luôn được coi trọng hơn kết quả đầu ra
Trên thực tế, gần như không thể đáp ứng chính xác ngày đó, nhưng tổ chức vẫn lấy nó làm thước đo duy nhất
Việc phát triển phần mềm về bản chất là một hoạt động không thể dự đoán hầu như không được cân nhắc
Khi Tuyên ngôn Agile mới ra đời thì còn có hy vọng, nhưng rồi nó nhanh chóng bị biến thành kiểu quản lý “hãy nói chính xác mỗi giai đoạn sẽ mất bao lâu”
Chậm một chút thì còn được tha thứ, nhưng xin thêm tiền thì sẽ bị ghét mãi mãi
Agile chỉ vận hành tốt khi có một Product Owner giỏi nắm được ngân sách phù hợp và quyền ra quyết định
Đội ngũ chỉ giao trong phạm vi có thể hoàn thành trong khoảng thời gian đó, và càng gần deadline thì càng cắt bớt tính năng
Đây là cách đảm bảo việc giao hàng, thay vì đảm bảo nội dung của sản phẩm
Nếu ngày tháng thực sự quan trọng đến thế, chẳng phải cách tiếp cận này cũng đáng để thử sao?
Tổ chức càng nhỏ thì càng có những bên liên quan thực sự, còn trong tổ chức lớn thì thành quả và sự nghiệp bị tách rời
Tôi làm bên phần cứng, và xác định mục tiêu cuối năm của mình là “ở trạng thái có thể demo được bằng chính đoạn mã tôi trực tiếp viết”
Nói là “mất vài tuần”, nhưng thực tế lại triển khai xong trong 30 giây
Có vẻ tác giả nói hơi quá
Có lẽ họ mang sang chấn vì từng làm ở một đội cộng tác tệ hại
Nhưng chắc chắn vẫn có những đội vận hành tốt, và một tập thể có thể tạo ra thành quả lớn hơn cá nhân
Kim tự tháp, Linux kernel hay AWS đều không phải do một người làm ra
Đội càng lớn thì chi phí giao tiếp càng tăng, và phần lớn trong số đó đến từ nhu cầu muốn có tính hiển thị của tầng quản lý
Một đội tốt sẽ giao tiếp tốt ở bên trong, nhưng phía quản lý cũng cần một mức độ hiển thị nhất định
Cuối cùng thì tổ hợp đội tốt + quản lý tốt là điều bắt buộc
Phần lớn tổ chức không biết cộng tác hiệu quả, nhưng lại lấy chữ cộng tác để che đậy thất bại đó
Dù vậy, lập luận “chỉ đội nhỏ mới làm được việc” thì có phần quá đà
Những ví dụ như xây kim tự tháp, theo nghĩa hiện đại, gần với hệ thống chỉ huy nghiêm ngặt hơn là cộng tác
Chương trình máy tính Apollo được làm bởi một đội nhỏ, nhưng để lên được Mặt Trăng thì cần sự hợp tác ở quy mô lớn hơn rất nhiều
Có quá nhiều bằng chứng cho thấy cộng tác thực sự hiệu quả
Một người không thể tự làm ra bom tấn như Assassin’s Creed, còn một ủy ban thì không thể tạo ra game như Stardew Valley
Đó là những loại năng lực khác nhau
Tôi cũng đồng cảm với trải nghiệm của tác giả
Sau khi bị sa thải ở startup, tôi chuyển sang một tập đoàn lớn, ban đầu phối hợp trong nhóm rất ăn ý nên kết quả khá tốt
Nhưng rồi một Agile coach xuất hiện và bắt đầu áp agenda của mình dưới danh nghĩa “cộng tác”
Trong 8 tháng, chỉ toàn workshop vô bổ và đấu đá quyền lực, cuối cùng đội ngũ giỏi lại bị kéo lê theo đội ngũ bất lực
Vấn đề là văn hóa không sa thải người kém năng lực
Cộng tác thực sự chỉ có thể xảy ra khi mọi người bỏ cái tôi xuống, lắng nghe nhau và cùng làm việc
Làm một mình thì có thể hoàn thành được nhiều việc hơn, nhưng lại có rủi ro định nghĩa sai vấn đề
Cộng tác giúp ngăn điều đó nhờ có nhiều góc nhìn khác nhau
Những người không làm việc lại đi cản trở những người đang làm việc
Gần đây tôi đọc bài báo “The Organizational Physics of Multi-Agent AI” của McEntire và thấy rất thú vị
Ngay cả các tác nhân AI cũng tái hiện nguyên xi sự kém hiệu quả mang tính chính trị của tổ chức con người
Cuối cùng, nếu tổ chức tệ thì bạn chỉ toàn làm “việc liên quan đến công việc (work about work)”
Những đội nhỏ có trách nhiệm rõ ràng vui hơn rất nhiều, nhưng khó nhân rộng
Tôi cũng bàn về chủ đề này trong bài blog Where to Cut
Cảm giác chỉ khi vai trò và cấu trúc rõ ràng thì orchestration mới thực sự hoạt động tốt
Khi thay người hoặc chuyển đội sẽ phát sinh chi phí chuyển ngữ cảnh, làm đứt gãy sự gắn kết của đội
Bản gốc khiến tôi không rõ rốt cuộc muốn nói gì
Một nền văn hóa không công nhận người tạo ra kết quả sẽ bào mòn tổ chức
20% những người gánh thêm trọng lượng thực ra chỉ muốn được ghi nhận
Nếu không cho họ điều đó, công ty sẽ nhanh chóng trống rỗng
Tôi không quan tâm đến lời khen từ người thậm chí còn chẳng biết tôi đang làm gì
Bài này có thể mở rộng vượt ra ngoài tổ chức, sang ý nghĩa xã hội của ‘quyền tác giả và tính chủ thể’
Những công việc phức tạp, chất lượng cao rốt cuộc vẫn đến từ trách nhiệm rõ ràng của cá nhân hoặc đội nhỏ
Giống như Dostoevsky hay đội máy tính Apollo
Ngược lại, một không tưởng cộng tác kiểu “ai cũng đóng góp nhưng không ai được tưởng thưởng” thì khá xa rời thực tế
Con người có động lực mạnh hơn với những sáng tạo gắn tên mình
Bản thân chuỗi cung ứng phức tạp cũng là một dạng cộng tác khác
Tôi thấy nghi ngờ về lập luận “80% binh sĩ không nổ súng”, nên tìm thử thì hóa ra đó là tư liệu đã bị bác bỏ từ lâu
Bài báo năm 2011 cũng nói cơ sở của nó rất yếu
Nếu nhìn vào tỷ lệ tooth-to-tail của quân đội Mỹ thì lực lượng chiến đấu thực tế chỉ khoảng 4~10%
Vì vậy có thể nguyên nhân là do nhầm lẫn số liệu
Nhưng đồng thời tỷ lệ PTSD cũng tăng theo
Toàn bộ bài viết tạo cảm giác như một nỗ lực thiếu mạch lạc khi cố kéo ví dụ quân đội sang làm mô hình cho lao động văn phòng
Nhưng tác giả vẫn có một tin tốt — bạn cũng có thể trở thành một nhà sáng tạo cá nhân
Giống như Notch hay nhà phát triển của Stardew Valley
Thay vì than phiền, cứ tự mình làm ra thứ gì đó đi
Việc 80% không nổ súng vẫn là một chi tiết thú vị
Tác giả hoàn toàn không xét đến thiết kế incentive cho thành quả
Như Munger nói, “hãy nhìn incentive thì sẽ biết kết quả”
Quan trọng hơn khó khăn của cộng tác là xây được cơ chế thưởng cho người tạo ra kết quả và chế tài kẻ ăn theo
Mà cũng không nhiều
Nếu làm được thì có lẽ chúng ta đã sống trong utopia từ lâu rồi
Ngoài chuyện ngay từ căn cứ ở câu đầu tiên đã khác với sự thật, việc lấy vấn đề nổ súng trong chiến tranh (có thể giết người, mức độ huấn luyện của binh sĩ thời chiến... v.v. là những vấn đề bị trộn lẫn vào) rồi liên hệ với vấn đề cộng tác trong phát triển phần mềm ngay từ đầu cũng đã có vẻ kỳ lạ. Đây là một bài viết chứng minh rằng phần mở đầu quan trọng sao...
Nhìn các phản ứng thì có vẻ thật sự có khá nhiều người đang sống trong sự ngộ nhận đúng như bài viết này nói.
Chỉ cần
1 + 1 = 1.1thôi thì dù một cá nhân có năng suất cao đến đâu cũng không thể tạo ra đầu ra lớn hơn 1.000 người làm việc kém hiệu quả.Bởi phát triển phần mềm vừa mang khía cạnh tinh thần thủ công của người thợ lành nghề, vừa mang khía cạnh của sản phẩm được sản xuất trong nhà máy.
Một số ít người thông minh sắp xếp mọi thứ thật tốt để ngay cả bọn ngốc cũng có thể hiểu và hành động cho đúng. Bọn ngốc lại ảo tưởng rằng đó là do chính họ đang cộng tác với nhau, haha
Đúng là sự hợp tác phần lớn đều thất bại, nhưng mọi việc vĩ đại, bao gồm cả sự ra đời của sự sống, đều đến từ hợp tác.
Trừ khi là thiên tài siêu hạng thực sự, dù giỏi đến đâu thì cũng không thể làm việc một mình. Cho dù 80% còn lại chỉ đóng vai trò cổ vũ đi nữa, chỉ cần ở bên động viên thôi cũng đã tương đương nửa người; rồi các ace gánh khối lượng công việc của 2~3 người thì công ty mới vận hành được. Làm việc một mình thì cũng không có cảm giác được công nhận, và vì cô đơn nên không thể chịu đựng nổi.
Rất đồng cảm.
Đặc biệt là thay vì sản phẩm tạo ra, người ta cứ thao thao bất tuyệt chỉ về những hoạt động nhằm tạo ra tính hiển thị và minh bạch trong các công cụ cộng tác...
Nhìn những PM để lại đủ thứ ghi chú chỉ để bớt trách nhiệm của bản thân, với tư cách là developer tôi chỉ thấy tụt mood.
Trông như một học sinh trung học lần đầu phát hiện ra sự kiểu cách, hình thức của người lớn và bắt đầu nổi giận. Không hiểu sao thấy tác giả có lẽ sẽ thích Holden Caulfield trong The Catcher in the Rye...
Tùy quy mô dự án thì đúng là có trường hợp một người chủ động dẫn dắt còn quan trọng hơn mức đóng góp của cả team... nhưng tùy quy mô thì cũng không hẳn vậy.
Chẳng phải là thế này sao..
Đó là quy tắc hai chiếc pizza.
Hợp tác là vô dụng
Hình như trước đây tôi đã từng thấy một tiêu đề y hệt như thế này rồi...
Có vẻ như ngay cả tài liệu được nêu ở dòng đầu cũng chưa được kiểm chứng thì phải.
Ở thời điểm hiện tại khi AI tools đã trở thành hiện thực, tôi nghĩ đây là một bài viết khá thực tế và có góc nhìn riêng về cách tối đa hóa sức mạnh cá nhân. Trong tương lai, mọi thứ sẽ ngày càng đòi hỏi tính gọn nhẹ và tốc độ cao hơn, nên quan niệm cộng tác cũ kỹ từ trước đến nay có lẽ sẽ được thiết lập lại. Tuy nhiên, để phát triển các giải pháp cấp doanh nghiệp thì cộng tác vẫn là điều bắt buộc.