Vụ nói dối CTO để vượt qua khủng hoảng

Câu chuyện một lập trình viên đã nói dối CTO

• Đây là câu chuyện từ vài năm trước, khi tác giả còn làm việc tại một công ty thuộc Fortune 500
• Khi đó, CTO đã nhận một dự án lớn cho một khách hàng quan trọng có quan hệ cá nhân với mình, và quyết định thuê ngoài phần cốt lõi cho một nhà cung cấp dịch vụ công nghệ lớn
• Nhưng "sản phẩm" của nhà cung cấp thực tế lại cần tùy biến trên diện rộng để đáp ứng yêu cầu, và đó là lựa chọn tệ nhất có thể
• Trong các cuộc họp cập nhật trạng thái với CTO, không ai thực sự nghĩ đây là ý tưởng hay, nhưng tất cả chỉ nói "Ý tưởng hay đấy sếp"
• Cuối cùng, khi nhà cung cấp bàn giao "sản phẩm" thì đã là tháng 9, và cuộc chạy nước rút tử thần cho đợt phát hành tháng 10 bắt đầu
• Trong quá trình kiểm thử, nhiều lỗi nghiêm trọng đã được phát hiện, bao gồm vấn đề hiệu năng và việc đụng phải giới hạn tài liệu 16MB của MongoDB
• Trong lúc thông báo với khách hàng rằng việc phát hành sẽ bị chậm một tháng, nhóm cũng quyết định khởi động một dự án bí mật để thay thế phần tích hợp với nhà cung cấp
• Là một lập trình viên trẻ đầy nhiệt huyết, tác giả được giao 3 thành viên trong nhóm và bắt đầu phát triển hệ thống thay thế
• Đến giữa tháng 12, phần mềm thay thế gần như đã hoàn thành sau một tháng làm việc, nhưng tất cả đều trong trạng thái kiệt sức
• Đúng lúc đó, CTO đến và nói rằng kỳ nghỉ sẽ bị hủy, còn tác giả trả lời "Vâng, tôi hiểu"
• Nhưng nhớ lại lời khuyên của cha mình, tác giả bảo các thành viên cứ đi nghỉ, rồi một mình tham dự cuộc họp cập nhật trạng thái của cuộc chạy nước rút tử thần với CTO và nói dối
  • "Cả nhóm đang làm việc rất chăm chỉ. Hôm nay họ đã đạt tới điểm tích hợp cột mốc thứ 73"
  • "Hôm qua cả nhóm đã đạt được tiến triển tốt. Họ vừa hoàn thành thêm một web service nữa"
• Một tuần sau, các thành viên đã được nghỉ ngơi quay trở lại, và nhóm đã phát hành thành công đúng hạn vào tháng 1

Ý kiến của GN⁺

• Đây là một ví dụ nổi bật về năng lực lãnh đạo khi vẫn đưa được dự án đến thành công dù trong môi trường tệ và với những yêu cầu quá sức. Đặc biệt, việc quan tâm đến tình trạng thể lực và tinh thần của các thành viên rất đáng chú ý
• Tuy vậy, việc nói dối CTO là điều không nên. Về lâu dài, nó có thể làm mất lòng tin trong tổ chức và gây ra những vấn đề lớn hơn
• Việc thất bại trong khâu chọn nhà cung cấp và quản lý outsourcing phần lớn là trách nhiệm của CTO, nhưng trong quá trình sửa sai, đáng lẽ cần giao tiếp minh bạch và chủ động hơn
• Để ngăn lập trình viên bị kiệt sức, ngay từ đầu lẽ ra phải lập kế hoạch thực tế hơn và bố trí đủ nhân lực. Chế độ crunch không nên là một thông lệ được chấp nhận
• Một phương án thay thế đáng tham khảo trong các tình huống tương tự là phương pháp Agile. Bằng cách phát triển theo chu kỳ ngắn và lặp lại quá trình nhận phản hồi, có thể giảm thiểu rủi ro và điều tiết cường độ làm việc của nhóm

[GN⁺]

Ý kiến trên Hacker News

• Làm việc quá sức và hủy kỳ nghỉ:
  • Làm việc quá sức và hủy kỳ nghỉ để kịp một thời hạn phi thực tế không phải là điều khôn ngoan, và sau này sẽ phải hối tiếc
  • Những công ty dựa vào việc nhân viên hy sinh kỳ nghỉ để giao sản phẩm đang góp phần tạo ra một văn hóa làm việc có vấn đề
• Công ty lành mạnh vs công ty không lành mạnh:
  • Ở một công ty lành mạnh, những người giàu kinh nghiệm hẳn đã dự đoán được các vấn đề của cách tiếp cận outsourcing và nêu lo ngại từ sớm
  • Giao tiếp cởi mở, cùng nhau nỗ lực tìm giải pháp, và quản lý đứng ra bảo vệ phúc lợi của cả nhóm là những dấu hiệu của một môi trường lành mạnh
  • Câu chuyện mô tả một tình huống không lành mạnh, nơi quản lý liên tục nói dối cấp trên
• Những thực hành kỳ quặc của vendor:
  • Cách tiếp cận của vendor là lưu mọi giao dịch trong một tài liệu JSON khổng lồ và phải đọc toàn bộ mỗi lần cập nhật là điều hết sức vô lý
  • Một ví dụ khác là một startup lưu dữ liệu vé của người dùng dưới dạng các cột bổ sung trong bảng người dùng, tạo ra hàng trăm cột
• Tình huống rối loạn chức năng và vai trò lãnh đạo:
  • Cách tiếp cận của trưởng nhóm là nói dối về kỳ nghỉ là không thể chấp nhận được và là một hành vi vi phạm có thể dẫn đến sa thải
  • Cách làm tốt hơn là phản đối các yêu cầu làm thêm giờ vô lý và khẳng định phạm vi dự án hợp lý cùng trách nhiệm của vendor
  • Trưởng nhóm có trách nhiệm bảo vệ cả nhóm khỏi những yêu cầu điên rồ, ngay cả khi phải đặt công việc của mình vào rủi ro
• Không ai được hưởng lợi:
  • Vendor giao chất lượng thấp, CTO thì không biết chuyện gì đang xảy ra, các lập trình viên làm việc quá sức, còn nhân vật chính thì phải dựa vào nói dối
  • Đây là một tình huống điên rồ mà không ai nên chấp nhận. Rời đi để tìm một nơi làm việc tốt hơn là điều đáng cân nhắc
• Sự trung thực và minh bạch:
  • Với một số người, việc nói thật với ban lãnh đạo về các vấn đề kỹ thuật, vấn đề hiệu năng, thay đổi phạm vi công việc, v.v. đã mang lại kết quả tốt
  • Nói dối để kịp một thời hạn tùy tiện do ban lãnh đạo xa rời thực tế đặt ra không phải là cách làm đúng đắn
• Khoảng cách niềm tin giữa lập trình viên và ban quản lý:
  • Giữa lập trình viên và quản lý không chuyên kỹ thuật thường tồn tại sự bất cân xứng thông tin và thiếu tin tưởng
  • Quản lý không thể dễ dàng đánh giá tiến độ và cảm thấy không chắc chắn về khả năng thành công của dự án
  • Vì rủi ro nằm ở phía kinh doanh, lập trình viên bị thúc ép phải lấp đầy khoảng cách niềm tin này và giao ra kết quả
• Hứa ít làm nhiều:
  • Việc nhân vật chính nói dối rằng phần việc đã hoàn thành thì ở một mức độ nào đó có thể được xem là "hứa ít làm nhiều"
  • Nói dối về công việc chưa hoàn thành còn nguy hiểm hơn và có thể làm giảm tinh thần của các thành viên trong nhóm khi họ quay lại
• Tổ chức bất lực và công cụ low-code:
  • Những thực hành tệ hại của vendor và phạm vi dự án khiêm tốn cho thấy một số tập đoàn lớn cảm thấy bất lực đến mức nào với các dự án phần mềm
  • Điều này có thể phần nào giải thích sự phổ biến của các công cụ low-code như Retool đối với giới lãnh đạo công nghệ, nếu không phải là với kỹ sư
• Chính trực và biết từ chối:
  • Một “rockstar” thực sự là người có chính trực và có dũng khí từ chối sự ngu ngốc cùng những yêu cầu vô lý
  • Việc bù đắp cho sự bất tài nghiêm trọng hoặc gánh thay gánh nặng cho cả đội không phải là trách nhiệm của một cá nhân