Kỹ thuật không cái tôi: bài học và góc nhìn
Mở đầu
- Trong ngành công nghệ, cái tôi và chủ nghĩa cục bộ (bè phái) là những yếu tố chính cản trở tinh thần làm việc nhóm
- Chia sẻ những góc nhìn rút ra trong quá trình suy nghĩ về cách giúp các nhóm kỹ thuật trở nên hiệu quả và hợp tác hơn
Thế lưỡng nan của việc phân chia trách nhiệm
- Chỉ cần có hai nhân viên thì việc phân chia công việc đã là điều bắt buộc
- Tuy nhiên, cách phân chia có thể tạo ra tác động tức thời và lâu dài
- Nhiều công ty không suy nghĩ đủ sâu về vấn đề này
Thực tế của khoa học máy tính
- Nhiều người học khoa học máy tính chỉ về sau mới nhận ra rằng mình đã bước vào một lĩnh vực gắn với công việc trừu tượng mang tính toán học
- Cú sốc ban đầu này khiến họ dành phần lớn sự nghiệp để tránh áp dụng những gì đã học sang các lĩnh vực ngoài máy tính
- Nếu môi trường làm việc cũng được suy xét sâu sắc như cách người ta tiếp cận vấn đề kỹ thuật, nó có thể được cải thiện
Bệnh lý tổ chức và những trải nghiệm thực tế
- Ngay cả công ty thành công cũng khó tránh khỏi các bệnh lý tổ chức, và ta có thể học được từ đó
- Một startup nơi tác giả bắt đầu sự nghiệp:
- Dù công ty còn nhỏ ở giai đoạn đầu, họ đã sớm áp dụng một cấu trúc quan liêu quá mức
- Họ thêm một "middleware Python" dựa trên một lý thuyết sai lầm rằng điều đó sẽ tăng tốc độ xử lý web request
- Kết quả là phát sinh thêm nhiều network hop hơn và hiệu năng giảm sút
- Để phát hành một tính năng cần có sự phối hợp phức tạp giữa nhiều vai trò
- Người làm cơ sở dữ liệu viết DDL và phát triển stored procedure
- Lập trình viên Python xử lý lớp middleware kém hiệu quả
- Lập trình viên PHP viết mã frontend
- Vì cấu trúc phân công như vậy, trong suốt hai năm họ không thể phát hành bất kỳ tính năng mới nào
- Kết quả
- Toàn bộ nhân viên bị sa thải do cấu trúc và quy trình làm việc kém hiệu quả
- Trừ tác giả. Tác giả sống sót nhờ luôn lên tiếng bất mãn
Vấn đề phân hóa vai trò trong công ty quy mô lớn
- Bối cảnh: làm việc tại một công ty sản phẩm B2B có hơn 1.000 nhân viên
- Ban đầu, công ty vận hành theo cấu trúc gồm các nhóm chức năng (Feature Teams) phân vai rõ ràng và các nhóm dịch vụ dùng chung (vận hành, DBA, v.v.)
- Lúc đầu, đó trông như một cấu trúc khá phổ biến
- Theo thời gian, vai trò bị phân tách quá mức và sự kém hiệu quả gia tăng
- Một vai trò mới là "Release Manager" được thêm vào để quản lý việc phát hành
- Lý do thêm vai trò này không rõ ràng, còn cấu trúc tổ chức thì ngày càng phức tạp
- Ví dụ về vấn đề:
- Kỹ sư frontend bị giới hạn chỉ làm frontend, kỹ sư backend chỉ được làm backend
- Sự phân chia này còn có thể tồn tại được, nhưng chính sách để đội bảo mật phụ trách toàn bộ công việc bảo mật đã gây ra vấn đề nghiêm trọng
- Kết quả: khi vai trò bị đồng nhất với công việc, hiệu quả tổ chức bị suy giảm
- Thiếu hợp tác giữa các nhóm và xuất hiện trùng lặp công việc
Danh mục sản phẩm phân tán và sự thiếu vắng cấu trúc giám sát
- Làm việc tại một công ty chủ yếu phát triển ứng dụng client native
- Ban đầu công ty có một ứng dụng client chủ lực thành công, nhưng đến thập niên 2020 thì nhiều dự án rời rạc, thiếu nhất quán được triển khai song song
- Vấn đề trong quản lý danh mục sản phẩm
- Cấu trúc giám sát toàn bộ sản phẩm rất yếu
- Không hề có sự điều phối giữa các sản phẩm về tech stack hay các quyết định quan trọng
- Mỗi nhóm sản phẩm báo cáo trực tiếp lên CEO, còn CEO thì không nỗ lực điều phối
- Nỗ lực xây dựng chức năng vận hành dùng chung
- Nhiều khó khăn phát sinh vì nhóm vận hành không tham gia vào quá trình ra quyết định kiến trúc
- Đội vận hành bận quản lý hàng trăm dịch vụ mà các nhóm phát triển đã sử dụng trong quá khứ nên không còn thời gian tham gia các quyết định quan trọng
- Đây có thể xem là một ví dụ điển hình của sự kém hiệu quả trong tổ chức
[Khái quát hóa các mẫu vấn đề tổ chức]
Mẫu 1: Nhầm lẫn giữa vai trò và công việc
- Có xu hướng tạo ra mô tả công việc mới cho mỗi loại việc mới
- Ví dụ: dù kỹ sư hiện tại có thể xử lý công việc liên quan đến AI, công ty vẫn lập ra vai trò mới là AI engineer
- Điều này gây xung đột trong tổ chức và có thể làm suy giảm động lực của các thành viên hiện có
- Sự phân chia vai trò quá mức như vậy dẫn tới quan liêu không cần thiết
Mẫu 2: Cuộc cách mạng DevOps được phân bổ không trọn vẹn
- Nhiều công ty tuyên bố rằng họ "đã triển khai DevOps", nhưng trên thực tế sự phân công cứng nhắc và xung đột vẫn tồn tại
- Ranh giới rõ rệt giữa đội vận hành và đội phát triển, hoặc giữa SRE và đội phát triển, cản trở hợp tác
- Mục tiêu ban đầu của DevOps là xóa nhòa ranh giới thông qua hợp tác và đồng cảm, nhưng thực tế hiếm khi đạt được
Mẫu 3: Giới hạn của phân công lao động cứng nhắc
- Việc chia nhỏ và chuyên môn hóa công việc có thể trông rất hiển nhiên với lãnh đạo
- Ví dụ: việc AI thì giao cho chuyên gia AI, việc vận hành thì giao cho người phụ trách vận hành
- Nhưng cấu trúc như vậy tạo ra nút thắt cổ chai
- Kỹ sư được bổ sung cố tạo thêm công việc mới để tăng tốc, nhưng rốt cuộc thời gian chờ phân tích lại tăng theo kiểu phi tuyến
- Khi nhà khoa học dữ liệu hoặc nguồn lực phân tích chạm ngưỡng, toàn bộ quy trình chậm lại
Mẫu 4: Cấu trúc tổ chức sai tạo ra thêm công việc
- Nếu ranh giới tổ chức không rõ ràng hoặc được đặt sai, khối lượng công việc không cần thiết sẽ tăng lên
- Ví dụ: đội bảo mật xử lý mọi vấn đề bảo mật và hình thành một hàng đợi ticket bảo mật
- Đội phát triển cứ tiếp tục làm việc mà không quan tâm đến bảo mật, kết quả là việc liên quan đến bảo mật càng tăng
- Điều này có thể bị bỏ qua trong ngắn hạn, nhưng về dài hạn sẽ trở thành vấn đề nghiêm trọng
Mẫu 5: Những thiên kiến cố hữu của con người
- Có xu hướng đánh giá quá cao vai trò của mình và đánh giá thấp vai trò của người khác
- Một số người sai lầm khi cho rằng công việc về server "không đủ tính kỹ thuật"
- Ngược lại, cũng thường có người cho rằng công việc sản phẩm ít tính kỹ thuật hơn
- Thái độ này làm suy yếu niềm tin giữa các nhóm và cản trở hợp tác
- "Những cá nhân xuất sắc nhưng độc đoán" không mang lại giá trị thực sự nếu nhìn từ góc độ hệ thống
- Lãnh đạo và tổ chức thường đánh giá nhầm những thái độ như vậy là "thông minh" hoặc "có giá trị"
[Bè phái và cái tôi]
- Chủ nghĩa cục bộ (Parochialism) và cái tôi (Ego) là nguyên nhân chính gây ra sự kém hiệu quả trong tổ chức
- Chủ nghĩa cục bộ: thái độ không muốn xâm phạm phạm vi của người khác hoặc thiếu tò mò với lĩnh vực của họ
- Cái tôi: niềm tự hào với công việc đôi khi có thể tạo ảnh hưởng tích cực, nhưng cũng có thể biểu hiện tiêu cực như giữ lãnh địa hoặc xem nhẹ năng lực của người khác
- Những hành vi mang tính bản năng này gây ra sự thiếu đồng cảm và cản trở hợp tác
Một ví dụ tốt hơn: trải nghiệm ở một nhóm kỹ thuật thành công
- Tại một startup trước đây, cấu trúc "lãnh địa" (fiefdom) tách biệt theo chiều ngang đã được đơn giản hóa và tổ chức lại thành các nhóm nhỏ hơn
- Các lãnh đạo nghiêm túc áp dụng DevOps đã phá bỏ rào cản và thúc đẩy hợp tác
- Trong khoảng 2 năm "phá hủy mang tính sáng tạo", mọi thành viên trong nhóm đều tham gia vào nhiều loại công việc khác nhau
- Kết quả là độ ổn định của hạ tầng và năng lực phát hành phần mềm được khôi phục
- Sau khi tái cấu trúc, nhóm kỹ thuật có thêm thời gian và quyền tự chủ
- Từ đó, nhóm bắt đầu thảo luận nên sử dụng năng lực bổ sung của mình như thế nào
Đề xuất 1: Đại tu quy mô lớn (Proposition 1: Boil the Ocean)
- Các nhóm thường dùng nguồn lực dư thừa để đại tu toàn diện những phần mà họ không thích
- Nhưng đây là cách đã từng được thử và không được ưa chuộng
Đề xuất 2: Hoạt động "thể hiện bản thân" (Proposition 2: Dress Like Big Dorks)
- Nhóm từng thử dùng thời gian rảnh để làm hàng lưu niệm nhấn mạnh văn hóa đội ngũ
- Tuy nhiên đây không phù hợp làm chiến lược chính
- Sự kiện mang tính quyết định: lỗi build do designer gây ra
- Giữa đêm, một designer làm hỏng bản build và nhóm phải khôi phục lại
- Ban đầu có ý kiến rằng nên phân định vai trò giữa designer và coder rõ hơn
- Nhưng một người trong nhóm đã đưa ra quyết định táo bạo là cấp thẳng deployment key cho designer
- Kết quả:
- Designer bắt đầu tham gia vào công việc code và mức độ hợp tác được cải thiện
- Nhóm xây dựng monitoring, test suite, v.v. để tạo ra môi trường làm việc an toàn
- Hiệu quả công việc và năng suất tăng lên rõ rệt
Đề xuất 3: Trao quyền cho mọi nhóm khác (Proposition 3: Empower Everybody Else)
- Nhóm chọn chiến lược dùng nguồn lực dư thừa của mình để hỗ trợ và nâng cao năng lực cho các nhóm khác
- Áp dụng cho cả nhóm kỹ thuật lẫn phi kỹ thuật
- Từ đó thúc đẩy hợp tác trên toàn tổ chức và dẫn tới việc thực thi hiệu quả hơn
Ý chí thực hành
- Sau trường hợp với designer, nhóm tiếp tục hợp tác với nhiều nhóm khác và đạt được những thành công tương tự
- Nhóm tận dụng thời gian rảnh và quyền hạn trong tổ chức để hỗ trợ các nhóm phối hợp hiệu quả hơn
- Việc triển khai thành công dựa trên nền tảng là sự hợp tác và đồng cảm ở quy mô toàn công ty
[Cảm giác của một lần triển khai thành công]
- Chuyên gia vs. chủ sở hữu
- Nhóm có các chuyên gia theo domain, nhưng không có ai là "chủ sở hữu" của một công việc hay domain cụ thể
- Trường hợp bảo mật: thay vì đội bảo mật xử lý mọi vấn đề, cả nhóm cùng chịu trách nhiệm về bảo mật còn đội bảo mật đóng vai trò nâng cao năng lực cho các thành viên khác
- Mô hình này lẽ ra cũng nên được áp dụng ở các lĩnh vực khác, nhưng phần lớn các nhóm đã không làm được
- Ví dụ thất bại
- Tách biệt triệt để kỹ sư frontend và backend
- Sự thiếu hợp tác gây ra những độ phức tạp không cần thiết như GraphQL
- Cần có chuyên gia cho từng vai trò nhất định, nhưng việc chia chức danh thành "frontend" và "backend" là không hiệu quả
- Nguyên tắc cốt lõi:
- "Chuyên gia theo domain, không phải chủ sở hữu"
- Khuyến khích chuyên gia có thời gian hỗ trợ các thành viên khác ngoài công việc chính của mình
Thúc đẩy hợp tác chủ động
- Tạo thời gian dư
- Cung cấp thời gian dư cho các thành viên để duy trì tinh thần làm việc nhóm ở quy mô tổng thể
- Không chỉ chờ hợp tác xảy ra một cách tự nhiên, mà chủ động tiếp thêm sinh lực cho hệ thống
- An toàn tâm lý và mở rộng in-group
- Mọi người cảm thấy an toàn về mặt tâm lý trong nhóm mà họ thuộc về, nhờ đó dám thử nghiệm hoặc học điều mới
- Đầu tư thời gian và nguồn lực để mở rộng "in-group" của các thành viên
- Bootcamp: cho mọi người sang làm việc bắt buộc ở nhóm khác để tạo cơ hội hợp tác
- Hackathon: cũng được dùng như một sự kiện tạo hiệu quả tương tự
Các giá trị đội ngũ được xây dựng có chủ đích
- Thiết lập triết lý và nguyên tắc cho nhóm
- Xác định rõ các mục tiêu cấp cao hơn của những hoạt động như code review, bootcamp, hackathon
- Tuyên bố rằng chủ nghĩa tinh hoa là chất độc
- Xây dựng một văn hóa nơi mọi người đều "tự mình xử lý việc cần làm"
- Niềm tin lẫn nhau và kỳ vọng cải thiện
- Đặt ra kỳ vọng mạnh mẽ rằng khi đụng đến sản phẩm công việc của người khác, bạn phải để lại nó ở trạng thái tốt hơn
- Văn hóa này khiến các thành viên sẵn sàng hợp tác hơn
Suy nghĩ kết lại
- Vấn đề của ngành công nghệ: chủ nghĩa tinh hoa và lãnh đạo độc đoán
- Những lãnh đạo độc đoán thiếu khiêm tốn cản trở hợp tác trong nhóm và cổ vũ sự tàn nhẫn không cần thiết
- Ngành công nghệ thường nhầm tưởng những lãnh đạo độc đoán như vậy là hữu ích, nhưng đó là hiện tượng ký sinh và có hại
- Không có lý do gì để việc tôn trọng người khác lại phải là điều cấp tiến, nhưng trên thực tế thường không phải vậy
- Hợp tác mang lại kết quả tốt hơn
- Hợp tác cải thiện kết quả, và cuộc sống sẽ tốt hơn khi không có những lãnh đạo độc đoán
- Cần nỗ lực loại bỏ chủ nghĩa cục bộ và cái tôi
- Tầm quan trọng của trao quyền
- Muốn khuyến khích thành viên tò mò và hợp tác thì cần sự cho phép và ủng hộ từ lãnh đạo
- Ví dụ: thay đổi để developer tự xử lý việc deploy thay vì chỉ SRE làm
- Ban đầu có lo ngại về sai sót của developer, nhưng đa số developer đã tự giải quyết vấn đề và thành công
- Các product engineer cho thấy thái độ muốn tự mình xử lý vấn đề
- Tạo độ dư (slack) cho hệ thống
- Những chương trình như bootcamp hay hackathon cần cam kết duy trì liên tục
- Những chương trình như vậy rất dễ biến mất nếu hệ thống không có độ dư
- Chúng ta không vận hành máy tính ở mức 100%, nhưng lại có xu hướng muốn vận hành chính mình như thế
- Tầm quan trọng của giá trị và phần thưởng
- Lãnh đạo cần thưởng cho sự hợp tác và tò mò, rồi biến điều đó thành văn hóa đội ngũ
- CEO thường cố loại bỏ các chương trình tích cực như bootcamp, hackathon, nhưng lại ít nỗ lực loại bỏ các chương trình tiêu cực như code review bắt buộc
- Cần từ bỏ niềm tin sai lầm rằng "đau đớn" sẽ tạo ra kết quả
- Đau đớn không phải chỉ báo thay thế phù hợp cho kết quả; hợp tác và niềm tin mới mang lại thành quả tốt hơn
7 bình luận
> Để khuyến khích các thành viên trong nhóm hợp tác với sự tò mò, cần có sự cho phép và ủng hộ từ người lãnh đạo
Có vẻ như việc khuyến khích mọi người tò mò về lĩnh vực của đồng đội, ngay cả khi đó không hẳn là phạm vi của bản thân, là điều rất quan trọng!
Thực tế là...!
Đó là một cấu trúc bất khả thi ở các startup "wejail" cứ ngày nào cũng thúc ép tiến độ.. Mọi người làm thực tế đều phải có thể tiếp tục duy trì hứng thú ban đầu khi mới vào công ty, nhưng thường thì không có hoặc thiếu sự hỗ trợ cho khía cạnh đó.
Toàn là những lời rất đúng..
Nhưng thực tế thì.................. hu hu
Có vẻ là một bài viết rất hay!
Bài viết rất hay.
Ý kiến trên Hacker News
Có ý kiến cho rằng việc gạt bỏ cái tôi của lập trình viên trong phát triển phần mềm là điều quan trọng. Sẽ tốt hơn nếu nhìn nhận sản phẩm phần mềm như thành quả của cả nhóm thông qua tinh thần làm việc tập thể.
Từ những bài học rút ra trong sự nghiệp phát triển, có lời khuyên rằng không nên thêm các quy trình không cần thiết, cần yêu cầu tinh thần sở hữu sản phẩm ở mọi vai trò, tránh các quyết định mang tính phản ứng, và khuyến khích sự hợp tác giữa các nhóm.
Những đội ngũ tốt nhất gồm các pizza team sở hữu toàn bộ stack và các chuyên gia đưa ra lời khuyên khi cần.
Dù các ẩn dụ thể thao không được ưa chuộng trong lĩnh vực công nghệ, vẫn có ý kiến cho rằng động lực vận hành của đội thể thao tương tự với một đội ngũ kinh doanh giỏi.
Thành công của tổ chức phụ thuộc vào việc mỗi thành viên hành động vị tha để đáp ứng nhu cầu của tập thể.
Nhấn mạnh tầm quan trọng của việc chủ động thiết lập các giá trị cho đội ngũ.
Khi làm việc ở bộ phận tăng trưởng, ban đầu người quản lý xem xét và hợp nhất mọi commit, nhưng về sau mới nhận ra rằng bản thân đã có quyền tự triển khai trực tiếp lên production.
Chuyên gia về domain được ưa chuộng hơn người sở hữu domain, và sự chuyên môn hóa quá mức một cách cứng nhắc có thể gây ra vấn đề.