Tại Sao Người Lao Động Trí Óc Thực Hiện Hệ Thống Làm Việc 996 Được Coi Là Ngu Ngốc Hoặc Xấu Xí

Tại sao tôi cho rằng những người lao động trí óc áp dụng chế độ làm việc 996 đều thuộc hai loại: ngu ngốc hoặc độc ác?

Xin lỗi vì tiêu đề có phần gây sốc, nhưng thực chất tôi muốn phân tích tận gốc rễ vấn đề về chế độ làm việc 996. Lưu ý rằng tôi đang nói về những người trực tiếp thực thi 996, chứ không phải các ông chủ ép buộc nhân viên làm việc kiểu này. Đây là hai nhóm hoàn toàn khác nhau, và hôm nay tôi muốn tập trung phê phán nhóm thứ nhất.

Nếu phải định nghĩa lại 996, tôi cho rằng không nên nhầm lẫn nó với tinh thần cống hiến toàn diện cho công việc. Chế độ này không đơn thuần là làm việc nhiều giờ, mà là cố ý thiết lập một hệ thống làm việc vào những khung giờ phi tự nhiên. Thay vì lấy kết quả công việc làm chuẩn, họ lại đặt nặng vào việc “đóng khung” thời gian làm việc rồi cố nhồi nhét công việc vào đó.

Trong ngành công nghiệp game - lĩnh vực tôi am hiểu nhất, công việc vốn dĩ phải là lao động trí óc. Với lập trình viên, công việc thực sự diễn ra trong đầu qua quá trình tư duy logic. Nếu bạn phải gõ phím và rê chuột liên tục như máy, công việc đó đã biến thành lao động chân tay. Đến lúc đó, cả khỉ đột hay AI cũng có thể thay thế bạn. Kéo dài thời gian làm việc kiểu thể lực có thể hiệu quả, nhưng biến lao động trí tuệ thành chân tay thì chỉ có thể gọi là ngu xuẩn.

Khi công việc đòi hỏi tư duy, thời gian và địa điểm làm việc không còn quan trọng. Nhiều khi ý tưởng nảy ra ngay cả khi bạn đang chuẩn bị ngủ. Việc bắt buộc ngồi văn phòng 10 tiếng mỗi ngày chẳng mang lại ý nghĩa gì. Vậy tại sao 996 lại trở thành chuẩn mực trong ngành lập trình Việt? Nếu không phải vì động cơ xấu, thì chỉ có thể là do phần lớn lập trình viên hiện nay thiếu năng lực thực sự.

Hãy nhìn từ góc độ nhà đầu tư game: Điều họ mong muốn nhất không phải là ép nhân viên làm việc như trâu ngựa, mà là có được kế hoạch phát triển rõ ràng với tiến độ đảm bảo chất lượng. Dù thời gian có dài, nhưng kế hoạch cụ thể sẽ giúp dự báo doanh thu. Những game thành công thường có lợi nhuận khổng lồ, nên việc tiết kiệm chi phí bằng cách rút ngắn thời gian sản xuất là không đáng kể. Thực tế, việc sửa đổi và kéo dài thời gian phát triển game lại là chuyện thường thấy.

Trong dự án lành mạnh, yếu tố quan trọng nhất là tính khả thi của kế hoạch. Vậy điều gì phá vỡ kế hoạch? Không phải thời gian làm việc, mà là những yếu tố bất định trong quá trình phát triển. Một lập trình viên giỏi có thể sản sinh 300-500 dòng code chất lượng mỗi ngày. Tổng lượng code trong game thường không vượt quá 100.000 dòng (trừ những phần tự động sinh ra). Tính ra chỉ cần khoảng 10 người/tháng là đủ. Nhưng với các đội ngũ hàng chục lập trình viên làm việc vài năm trời, rõ ràng phần lớn công sức đã bị lãng phí do bug, thay đổi yêu cầu, hay sửa đi sửa lại.

Chế độ 996 có thể kéo dài thời gian làm việc tối đa gấp đôi, nhưng khi mệt mỏi làm giảm khả năng phán đoán, tỷ lệ lỗi sẽ tăng vọt. Nếu có kế hoạch rõ ràng, bạn không thể dự kiến làm việc quá giờ thường xuyên, vì phải chừa thời gian cho những rủi ro bất ngờ. Việc không hoàn thành đúng hạn do thiếu kinh nghiệm chứng tỏ năng lực còn hạn chế, nhưng nếu đã là bất ngờ, thì ai cũng có ngày làm việc hiệu quả. Kéo dài giờ làm chỉ là giải pháp vô ích.

Trừ khi công việc đó không còn đòi hỏi trí tuệ. Khi hạ thấp yếu tố tư duy, 996 mới phát huy hiệu quả. Giống như việc bạn dùng máy tính bấm cộng từ 1 đến 100: chỉ cần kiên nhẫn bấm từng số, cuối cùng sẽ có kết quả. Nhưng nếu tìm công thức toán học để tính nhanh, lại không thể dự đoán thời gian chính xác. 996 chỉ hiệu quả khi bạn chọn phương pháp thô sơ nhất, đòi hỏi người thực hiện phải “giả ngu” để làm việc theo quy trình máy móc.

Yếu tố quan trọng khác là làm việc nhóm. Trong môi trường 996, các cuộc họp, thảo luận vô tận trở thành “đặc sản”. Công việc phụ thuộc lẫn nhau: bạn cần chờ tôi xong phần này mới làm tiếp được. Đội ngũ càng lớn, phân công càng chi tiết, càng cần nhiều người “trực chiến” suốt ngày. Nhưng lập trình viên chuyên nghiệp đều hiểu: dự án càng phức tạp càng cần phân tách module độc lập. Đôi khi phải chấp nhận chi phí giao tiếp cao giữa các module để đảm bảo tính độc lập. Việc “gọi API” liên tục giữa các phần việc như thế sẽ làm chậm tiến độ dù có tối ưu code đến đâu.

Tôi từng trải qua nhiều tình huống đáng nhớ. Có lần nửa đêm phát hiện bug, dù không phải do code tôi viết, tôi vẫn tự thức trắng đêm nghiên cứu và sửa lỗi thay vì làm phiền đồng nghiệp. Một lần khác, trước giờ ra mắt game, dữ liệu quan trọng gặp sự cố nhưng người phụ trách đã về hết. Thay vì gọi họ dậy, tôi tự viết lại công cụ xử lý dữ liệu trong đêm. Hai ví dụ này cho thấy: cống hiến hết mình không đồng nghĩa với 996. Có năng lực và ý thức tự giải quyết vấn đề mới là điều quan trọng.

Giảm thiểu giao tiếp không có nghĩa là “đóng cửa làm việc”. Ngược lại, nên tranh thủ thời gian ngoài giờ để học hỏi từ các lĩnh vực khác. Nhiều khi một ý tưởng từ bên ngoài sẽ giúp bạn phá vỡ lối mòn tư duy. Nếu suốt ngày chỉ biết cắm đầu vào bàn làm việc, bạn đã tự khóa trái cửa đổi mới.

Cuối cùng, nói về “cái xấu”. Dù không cố ý, nhưng hành động của một số người đã gây hại cho tập thể. Khi không đủ năng lực, họ chọn cách làm việc máy móc, không cần tư duy. Cách này dễ thực hiện, chỉ cần gõ phím liên tục để tạo cảm giác thành tựu. Nhưng hậu quả là kéo cả đội ngũ vào vòng xoáy cạnh tranh “ai chịu làm việc nhiều hơn”.

Phương pháp làm việc thông minh đòi hỏi cả nhóm cùng tư duy sáng tạo, giảm thiểu lỗi phát sinh. Nhưng chỉ cần một hai người lười biếng, cả hệ thống sẽ sụp đổ. Ví dụ