Kỹ thuật
- Yêu cầu viết lại hệ thống cốt lõi trong vòng 6–18 tháng. Đổ lỗi cho CTO tiền nhiệm.
- Khuyến khích mỗi người dùng một ngôn ngữ và framework khác nhau.
- Chia hệ thống theo các ranh giới tùy tiện để một tính năng phải có nhiều hệ thống cùng tham gia.
- Tạo ra môi trường phát triển phức tạp. Bắt chạy service mesh với ít nhất 12 dịch vụ.
- Làm cho môi trường production và môi trường của lập trình viên khác nhau tối đa có thể.
- Triển khai càng ít càng tốt. Khuyến khích cực kỳ thận trọng với việc deploy.
- Đưa vào quy trình cực kỳ phức tạp cho việc thay đổi code và workflow nói chung. Lấy cớ là vì "bảo mật" hoặc "tuân thủ".
- Ghi mọi việc vào công cụ theo dõi công việc và để ít nhất 5 người cùng xem xét, ưu tiên và phê duyệt.
- Cấm mọi thứ nằm ngoài phạm vi công việc ban đầu. Ví dụ, cấm dọn dẹp code hay các cải tiến khác.
- Tự xây gần như mọi thứ không phải năng lực cốt lõi. Biện minh rằng là "để tránh phụ thuộc nhà cung cấp".
- Khăng khăng thêm lớp trừu tượng vào mọi thứ. Dùng các vendor đã được trừu tượng hóa rồi lại thêm một lớp trừu tượng nữa.
- Khuyến khích các quyết định kỹ thuật với quy mô lạc quan phi thực tế. Lập kế hoạch cho tải lớn hơn hiện tại ít nhất 3 lần.
- Khuyến khích đồng sở hữu hệ thống. Để không ai cảm thấy có trách nhiệm với việc bảo trì.
- Khăng khăng tập trung hóa gần như mọi thứ thành "platform". Giữ cho đội platform luôn thiếu người và không cho các đội khác xây thứ mà platform có thể sở hữu.
- Để đội platform lặp lại API thường xuyên và buộc các đội khác refactor code theo phiên bản mới nhất.
- Tuyển "architect" và yêu cầu "đánh giá kiến trúc" ngay cả với thay đổi nhỏ.
- Yêu cầu "đánh giá bảo mật" ngay cả với thay đổi nhỏ.
Sản phẩm
- Phớt lờ các chỉ số hữu ích vì lý do học thuật. Ví dụ gọi chúng là "thiên lệch" hoặc "chỉ số trễ".
- Chọn các vanity metric không liên quan đến giá trị kinh doanh. Chọn các chỉ số nhiều nhiễu.
- Xem mọi thứ là một "cú cược lớn" và khăng khăng không phát hành cho tới khi mọi thứ hoàn toàn xong xuôi.
- Xem mọi tính năng đều là "bắt buộc" và là phần quan trọng của "phiên bản zero". Tuyệt đối không nhượng bộ.
- Xây dựng các kế hoạch "chiến lược" cực kỳ chi tiết.
- Đổi hướng thường xuyên.
- Bỏ qua các cải tiến hiển nhiên bằng cách gọi chúng là "tối ưu cục bộ".
- Dùng các xu hướng mới nhất để trói tài nguyên lại. Khởi động một "chiến lược AI" nghe có vẻ hợp lý trên bề mặt. Chi rất nhiều tiền cho vendor và tư vấn để làm việc đó.
- Khuyến khích product manager dành phần lớn thời gian cho "chiến lược" và "lập kế hoạch".
- Làm cho kỹ sư và product manager khó hoặc không thể dùng sản phẩm nội bộ.
- Nội bộ thì coi người dùng là "ngu ngốc".
Lãnh đạo
- Gắn thưởng với chức danh và quy mô đội để khuyến khích phình to bộ máy.
- Nói to về chiến lược, tính năng hoặc độ phức tạp kỹ thuật.
- Thực hiện các thương vụ mua lại đắt đỏ để bước vào lĩnh vực sản phẩm mới. Nhắc đến "synergy". Rồi khai tử sản phẩm đã mua.
- Dùng thật nhiều quan hệ báo cáo dạng đường nét đứt trong cơ cấu báo cáo.
- Để càng nhiều người càng tốt báo cáo cho quản lý ở đội khác, địa điểm khác hoặc chức năng khác. Để quản lý không thể giám sát người báo cáo cho mình.
- Thường xuyên chuyển người làm việc kém sang đội khác.
- Đưa người làm việc xuất sắc vào các dự án R&D đầy suy đoán với đầu ra không chắc chắn.
- Luôn yêu cầu họp ngay cả với quyết định vụn vặt.
- Khăng khăng rằng mọi "stakeholder" đều phải dự họp.
Tuyển dụng
- Tạo ra quy trình tuyển dụng nhìn bề ngoài có vẻ khách quan nhưng thực chất là chủ quan.
- Loại những nhân tài giỏi nhất vì "không hợp văn hóa" hoặc các tiêu chí mơ hồ khác.
- Tuyển ứng viên yếu nhất vì "tiềm năng" hoặc "thái độ" hay các tiêu chí mơ hồ khác.
- Tuyển các lãnh đạo cấp cao cực kỳ đắt đỏ với cam kết nhân sự quy mô lớn.
- Dùng chức danh thổi phồng và vai trò bịa ra để thu hút những kẻ cơ hội.
- Tuyển các "chuyên gia" siêu chuyên biệt rồi tạo ra các dự án nhân tạo để họ không nghỉ việc.
- Dùng sự chuyên biệt làm lý do để tuyển thêm người bổ trợ khác.
Quản lý dự án
- Yêu cầu ước tính cực kỳ chi tiết cho mọi dự án.
- Khuyến khích các dự án trải qua càng nhiều đội càng tốt, lý tưởng nhất là các đội ở các địa điểm khác nhau.
- Thêm các yêu cầu mới phụ thuộc vào phần việc do đội khác thực hiện.
- Thường xuyên dùng agency đắt đỏ. Làm cho phạm vi mơ hồ và giao các prototype dang dở cho đội nội bộ hoàn thiện.
- Xây dựng các hệ thống "self-service" phức tạp cho stakeholder của các đội khác.
Kết quả
- Làm giảm năng suất là việc khó. Nhưng nếu nhảy dù vào hậu phương địch và nhận việc CTO thì bạn có thể làm được.
- Với những người không thích phá hoại: đây là câu chuyện về cách khai thác tối đa năng suất của đội. Năng suất được tạo nên từ những điều nhỏ nhặt cộng lại.
- Nếu 100 điều nhỏ, mỗi điều áp một loại thuế năng suất 5%, thì mọi thứ sẽ chậm hơn 131 lần. Muốn kỹ sư vui vẻ, bạn phải từ chối 100 điều nhỏ nghe có vẻ hợp lý đó.
Ý kiến của GN⁺
- Bài viết này mô tả một cách hài hước nhiều cách khác nhau làm suy giảm năng suất trong phát triển phần mềm. Qua đó, nó giúp làm rõ những hành vi thực sự cần tránh.
- Điều quan trọng là phải giảm technical debt và duy trì văn hóa phát triển hiệu quả. Tránh sự phức tạp không cần thiết và quan liêu là then chốt.
- Điều quan trọng là tạo ra một môi trường giúp nâng cao tinh thần đội ngũ và thúc đẩy hợp tác. Điều này ảnh hưởng trực tiếp đến việc cải thiện năng suất.
- Bài viết này giúp hiểu rõ hơn sự phức tạp của software engineering và quản lý. Đặc biệt, nó mang lại những góc nhìn hữu ích cho các kỹ sư mới vào nghề.
- Một dự án tương tự khác có thể kể đến là cuốn sách "The Phoenix Project". Cuốn này bàn về cách nâng cao hiệu quả của IT và DevOps.
11 bình luận
Có công ty nào không làm như vậy sao? hu hu
Ngay cả những công ty nhỏ đã thành công thì khi lớn lên, có vẻ cuối cùng cũng đều trở nên như vậy...
Hầu hết đều là những việc tôi từng được chỉ thị ở công ty trước đây. Bắt buộc dùng những nền tảng chẳng dùng được vào đâu... phớt lờ các chỉ số hiệu năng tiêu chuẩn... bắt làm lại những task đã từng làm rồi, vân vân.
Ờ..?
Đúng là kiểu "Cách viết code để khó bảo trì: bạn cũng có thể sống nhàn cả đời với nghề lập trình viên"...
Tôi sẽ chọn chết.
Ôi..ôi!..a a!!.. á!... a......
Thật đáng tiếc vì trong tổ chức của chúng tôi cũng đang thấy xuất hiện vài điều như vậy. hu hu
Nhớ đến cuốn sách huyền thoại "Cách viết code sao cho khó bảo trì" quá.
Tôi cũng cuốn sách này!
Có thể bạn sẽ nghĩ “Nhiều đến vậy sao?”, nhưng tôi cũng thấy rằng những điều trên hoàn toàn có thể được một người hoặc một tổ chức làm được.^^
Ý kiến trên Hacker News
Thiếu chắc chắn về việc đề xuất của CIA có thực sự hiệu quả hay không: Chưa từng thấy lý do đủ thuyết phục nào cho việc đề xuất ban đầu của CIA thực sự có hiệu quả, và các tổ chức có xu hướng tự nhiên là phớt lờ những người như vậy.
Cách làm hỏng một công ty: Thăng chức những người tệ lên vị trí quản lý và tối ưu hóa những thứ không sinh lợi có thể giáng đòn mạnh vào công ty.
Cách trở thành một CTO mang tính phá hoại: Rất dễ để hầu như không làm gì cả, loại bỏ những người có năng lực và nuôi dưỡng một văn hóa đẩy trách nhiệm xuống cấp dưới.
Làm việc qua kênh chính thức và yêu cầu mệnh lệnh bằng văn bản: Với một số người, làm việc qua kênh chính thức và yêu cầu chỉ thị bằng văn bản có thể hiệu quả hơn.
Sự khác biệt giữa OSS và CIA: OSS (Văn phòng Dịch vụ Chiến lược) đã tạo ra một cuốn sách tuyệt vời trong Thế chiến II, còn CIA được thành lập vào năm 1947.
Tầm quan trọng của tầm nhìn: Bước quan trọng nhất là loại bỏ những người có tầm nhìn nhất quán về cách sản phẩm vận hành tổng thể hoặc về một tương lai tốt đẹp hơn.
Cần cập nhật mục tuyển dụng: Cần yêu cầu ứng viên giải các bài Leetcode khó trong vòng 30 phút và không dung thứ cho sự không chắc chắn hay nghi ngờ.
Sự khác biệt giữa môi trường production và môi trường developer: Trong kiến trúc hiện đại có rất nhiều dịch vụ bên ngoài nên môi trường production và môi trường developer khó tránh khỏi khác nhau, điều đó có nghĩa là các developer luôn phải kết nối Internet.
Các quyết định để tự bảo vệ bản thân: Nhiều quyết định phục vụ cho việc "phá hoại" liên quan đến việc thuyết phục người khác rằng đó là nỗ lực che đậy sai lầm của chính mình.
"Best practice" trong công ty: Tám quy tắc được nêu ở phần đầu bài viết đang được tuân thủ nghiêm ngặt như "best practice" trong công ty.
Hành vi của các consultant: Nhiều consultant đang làm hầu hết, nếu không phải là tất cả, những điều này.
Vấn đề của ngành công nghệ: Có rất nhiều người trong ngành công nghệ hành xử theo cách này, và họ tin rằng mình đang giúp ích.
Kinh nghiệm ở các tập đoàn lớn: Kinh nghiệm hạn chế ở các tập đoàn lớn rất khớp với nội dung của bài viết này.