Luận bàn, hay chút suy nghĩ về OT (Overtime)
OT, thân thuộc tới mức có lẽ chẳng có ai trong ngành IT ở Việt Nam lại không biết tới thuật ngữ này. Nhưng lướt qua các trang mạng, rồi hỏi chị Google, cũng có 1, 2 bài luận bàn về vấn đề này. Một con số không-thể-khiêm-tốn-hơn . Dường như OT đã trở thành một phần hiển nhiên trong cuộc sống ...
OT, thân thuộc tới mức có lẽ chẳng có ai trong ngành IT ở Việt Nam lại không biết tới thuật ngữ này.
Nhưng lướt qua các trang mạng, rồi hỏi chị Google, cũng có 1, 2 bài luận bàn về vấn đề này. Một con số không-thể-khiêm-tốn-hơn.
Dường như OT đã trở thành một phần hiển nhiên trong cuộc sống của giới IT Việt, tới độ người ta còn chẳng buồn nói về nó. Trong khi ngoài kia, các nước phương Tây họ đã có xu hướng làm 6, 4 tiếng một ngày; Nhật Hàn cho cả drom để đuổi người lao động về khi quá giờ tan ca...
Trong khuôn khổ bài viết nhỏ này, mình mong muốn đưa OT lên để soi xét từ nhiều chiều, một cách thật công bằng. Để các bạn mới vào ngành, hay kể cả những người đã có kinh nghiệm lâu năm, và cả bản thân mình nữa có được một mindset đúng đắn về nó.
Từ thư thoảng thêm 2, 3 tiếng tới thư thoảng vài ngày thứ 7 chủ nhật, rồi full cả tháng trời không biết ngày nghỉ tới xuyên đêm đều có thể có...
Sinh viên mới ra trường háo hức cống hiến, coi OT không là đáng quan tâm lắm, cho tới khi bắt đầu có gia đình và ngổn ngang thứ phải quan tâm.
Những manager làm việc lâu năm coi OT là điều thường thường hay xảy ra trong các dự án. Đôi khi còn thích tuyển dụng trẻ vì tinh thần máu lửa sẵn sàng OT.
Số người quan tâm đã ít, mong muốn cải thiện vấn đề ít hơn, và người đưa ra những biện pháp rõ ràng để xử lý nó và chia sẻ cực kì ít. Mình chẳng nói ngoa đâu, mọi người cứ lên mạng tìm xem.
Vậy thì OT có xấu hay không?
Theo luật pháp thì để kết luận một việc là xấu hay không xấu không phải chỉ nhìn vào kết quả, mà còn phụ thuộc vào động cơ của nó nữa. Nếu chỉ nhìn vào kết quả của việc OT là nhân viên mệt mỏi, tốn thêm chi phí điện nước, điều hoà; tỉ lệ bugs tăng...vv thì chắc chắn một điều là nó xấu. Tuy nhiên theo mình thì thư thoảng, nhưng cũng rất ít khi, nó cũng không phải là xấu.
Chúng ta hãy cùng tìm hiểu về nguyên nhân của nó để có được đánh giá khách quan hơn nhé.
Vì không thể viết rõ ràng cho từng loại dự án nên mình xin phép chia nguyên nhân ra làm 3 loại.
- Khách quan từ phía Khách hàng và Thị trường
- Chủ quan về mặt quản lý
- Chủ quan về mặt phát triển của team dự án
Trong 3 nguyên nhân này, thì chỉ có duy nhất việc OT do nguyên nhân số 1 là có thể chấp nhận được là không xấu hoặc ít xấu hơn mà thôi.
1. Nguyên nhân khách quan từ phía Khách hàng và Thị trường
Trong thực tế, sẽ có không ít trường hợp mà biến cố xảy ra nằm ngoài dự đoán của những chuyên gia kì cựu nhất. Như là một đối thủ đột ngột nhảy vào thị trường cạnh tranh với công ty, khách hàng bỗng dưng thay đổi thiết kế và chức năng của sản phẩm để phù hợp với kết quả điều tra từ thị trường, sự cố bảo mật liên quan tới hệ điều hành hay các thư viện được dùng, hay thậm chí là cả thiên tai, hay sự thay đổi thể chế chính trị dẫn tới thay đổi chiến lược kinh doanh của doanh nghiệp...vvv
Những biết cố ấy sẽ kéo theo hàng loạt những yêu cầu mới, yêu cầu xử lý khẩn cấp cho đội dự án. Để xử lý khủng hoảng, để sản phẩm đưa ra phục vụ tốt cho người dùng hơn, hay để giúp công ty vượt qua được thời khắc khó khăn và chiến thắng đối thủ; phương án OT đôi khi là sự lựa chọn chấp nhận được và cần thiết.
Không loại trừ cả trường hợp Khách hàng cũng tương đối lởm, không tự quản lý được tiến độ, tài liệu và thiết kế bên họ làm ảnh hưởng tới team của mình.
2. Nguyên nhân chủ quan về mặt quản lý
2.1 Quản lý Client không tốt
Có thể nhiều người bất ngờ khi mục quản lý Client này xuất hiện. Vì chưa từng nghĩ tới nó bao giờ, cũng không có đủ dũng khí để làm việc đó. Nhưng đúng là nó đấy, Quản lý Khách hàng. Những trường hợp sau sẽ có thể đưa cả con tàu tới bến bờ OT.
- Không hiểu Client:
Người quản lý không thấu hiểu khách hàng sẽ có xu hướng cung cấp cho họ những điều họ không cần nhưng lại thiếu những thứ họ thực sự mong mỏi. Thời gian và công sức team bỏ ra có thể nhiều, nhưng không được công nhận, đôi khi những thứ team làm lại phải đập đi. Bị yêu cầu làm thêm những thứ không thể nghĩ tới.
- Yếu đuối trước khách hàng và hay ép team:
Có rất nhiều yêu cầu từ phía khách hàng là vô lý và không cần thiết. Vì muốn làm vừa lòng KH mà ép buộc team phải làm thêm. Đó không chỉ là sự yếu đuối, mà còn là sự yếu kém trong năng lực quản lý nữa.
Khi bid hay deal với Khách hàng mà không đủ sự cứng rắn và sức thuyết phục ắt sẽ làm cho ngay từ lúc khởi đầu team đã chịu nhiều bất lợi về nhân lực và thời gian.
Quản lý CR (Change Request) từ Khách hàng không tốt cũng là một trong những nguyên nhân rất lớn dẫn tới OT.
2.2 Quản lý team dự án không tốt
Lỗi chủ quan về mặt quản lý thì có rất nhiều và đa dạng. Lỗi process, lỗi quản lý tiến độ, lỗi quản lý con người...vv Ví dụ như:
- Lựa chọn mô hình phát triển phần mềm không phù hợp với team và quy mô, đặc thù của dự án.
- Không xây dựng được bộ process đầy đủ và toàn diện khiến quá trình phát triển gặp nhiều trục trặc.
- Không dành đủ thời gian quản lý nên không nắm được velocity của team. Lúc bid sẽ không đủ chắc chắn và mạnh dạn để đưa ra con số.
- Không quan tâm đầy đủ tới các member trong team, không biết được điểm mạnh điểm yếu của mỗi người. Do đó giao việc một cách không phù hợp.
- không truyền được cảm hứng cho các thành viên khiến tinh thần team ủ dột, năng suất không cao.
- Không truyền đạt được lý do, hay mục tiêu của dự án của những task member phải làm, khiến cho member hiểu lầm lúc implement.
- Coi thường và làm lơ những báo cáo về nguy cơ, về issues mà các thành viên trong team đưa lên: Thực ra đa số các vấn đề xảy ra thường đã được ai đó nhận ra nguy cơ rồi, chỉ có điều nó có được truyền đến đúng người và lắng nghe hay không mà thôi.
...vv
3. Nguyên nhân chủ quan do đội phát triển
Không thể nhìn một chiều mà đổ hoàn toàn lỗi cho người quản lý được. Là một member, mỗi người là một phần rất quan trọng để đảm bảo cho dự án vận hành trơn tru. Không làm ảnh hưởng tới những phần task của người khác.
Những nguyên nhân chính từ phía đội phát triển khiến dự án phải đắm chìm trong OT là:
- Horenso không tốt (báo cáo-liên lạc-thảo luận không tốt)
Không chỉ khi gặp vấn đề, ngay cả khi có chút thắc mắc về tài liệu thôi member cũng phải có ý thức liên lạc và báo cáo đầy đủ để manager có định hướng xử lý sớm. Thông tin trong một tổ chức cũng giống như máu trong hệ tuần hoàn, khi nó tắc nghẽn, toàn bộ bộ máy sẽ gặp nguy.
- Năng lực của các thành viên còn non
Trong tình trạng chung của toàn ngành IT là thiếu nhân lực, thì các sinh viên mới ra trường đôi khi cũng sẽ phải gánh vác trọng trách rất quan trọng mà khi đó các em chưa nhận thức được, cũng chưa hiểu được mức độ quan trọng và yêu cầu cao của các nhiệm vụ ấy. Lỗi xảy ra là đương nhiên. Tiến độ chậm và cần phải cover lại bằng thời gian làm thêm giờ.
Những người đảm nhận trọng trách dẫn dắt, nhiều lúc cũng không thể đủ sức kéo những quả tạ quá nặng (yaoming)
- Teamwork chưa tốt
Tinh thần team work đôi khi còn quan trọng hơn cả process hay là mô hình phát triển phần mềm.
Khi làm việc không nghĩ tới ảnh hưởng của source code của mình cho người đọc về sau, hay cho task của các member khác thì thật sự là tai hoạ. Khi làm không thống nhất được với nhau phương án, không biết nhường nhịn và cầu thị, thì rất khó để một team có thể vận hành trơn tru. Tình trạng người ngày đi hốt sh^t của người kia sẽ có thể xảy ra và thời gian chúng ta mất đi là rất nhiều.
- Những phần tử cá biệt
Đôi khi dự án sẽ phải đối mặt với những chú sâu ngầm từ chính bên trong, làm việc không ý thức, cẩu thả, làm ảnh hưởng tới tinh thần của các member khác... hay đơn giản thôi, chỉ là một thời kì khủng hoảng, rồi người ta bùng nổ và gây nên sức tàn phá cho team.
...vv
Về phần hậu quả có lẽ ai cũng từng nhìn thấy, cảm nhận thấy, chỉ là mức độ khác nhau thế nào mà thôi.
Mình xin phép không đi quá sâu vào chủ đề này nữa. Tuy nhiên các bạn có thể tham khảo ý kiến và quan điểm của mình trong bài viết Sự khác biệt giữa SE và BrSE trước khối lượng công việc lớn
Tóm lại thì: hậu quả của nó không chỉ ảnh hưởng tới sức khoẻ, đời sống riêng tư của cá nhân, mà có những trường hợp gây ảnh hưởng rất lớn tới tổ chức vì một lỗi lầm trong lúc đang mất tập trung khi OT.
Nếu hiện tại người ta đang nhìn nhận OT như thế, hậu quả của nó lớn như vậy.
Thì phải có những giải pháp thế nào để giảm thiểu và hạn chế nó? Mời các bạn tới với phần tiếp theo.
Về cơ bản, base trên những nguyên nhân, mọi người có thể đưa ra các giải pháp phù hợp để hạn chế và ngăn chặn nó.
Rất mong mọi người đọc lại để tự mình đưa ra các giải pháp chi tiết tương ứng với nó.
Trong phần này mình chỉ muốn nhấn mạnh yếu tố then chốt để giải quyết triệt để vấn đề. Đó là Cần phải rèn luyện và training để có Mindset đúng đắn về OT
Tại sao lại như vậy?
Nguyên nhân sâu xa nhất của vấn đề OT là người ta coi nó là sự hiển nhiên đôi khi có trong ngành IT hay là một vấn đề cố hữu trong cuộc sống. Nói tới đây mình chợt nghĩ tới trào lưu rất là mới của giới trẻ nha. =))
Khi đã có một Mindset lệch lạch như thế, người ta chả bao giờ muốn nhìn thẳng chứ đừng nói tới việc nỗ lực tìm giải pháp phòng chống OT.
Ngược lại, nếu có một Mindset đúng đắn về OT, nó sẽ có ảnh hưởng rất lớn tới bản thân người đó trong những công việc khác, rồi tới toàn team.
Thật vậy.
Một Manager xem OT như một vấn đề quan trọng cần giải quyết sẽ dám đứng nên phản biện những ý kiến và yêu cầu không hợp lý từ phía Khách hàng. Cố gắng tìm hiểu rõ mong muốn của họ là gì trong từng ngày làm việc để đội dự án đáp ứng tối đa những yêu cầu đó mà không tốn công sức và thời gian vô ích.
Sẽ chủ động nâng cao năng lực, vị thế, và cả sự tự tin của bản thân mình.
Một Manager nghĩ tới nỗi khổ của từng thành viên trong team khi OT sẽ mạnh mẽ hơn khi thương lượng với KH về nhân sự hay thời hạn hoàn thành. Sẽ sẵn sàng bỏ nhiều thời gian hơn để quản lý và hiểu rõ khả năng của team, năng lực của từng thành viên...vv
Một member có Mindset đúng đắn về OT sẽ chủ động liên lạc khi nhận thấy có vấn đề sắp xảy ra. Sẽ suy ngẫm trước khi đặt ngón tay gõ từng dòng code xem nó có ảnh hưởng thế nào tới người đọc tiếp sau, hay người sẽ dùng các hàm mình viết...vv
Một member hiểu được nỗi vất vả và tổn hại sức khoẻ mà OT mang tới sẽ sẵn sàng giúp đỡ những member khác hoàn thành task lúc khó khăn. Rất nhiều chị em phụ nữ trong team vừa phải làm việc, vừa phải chăm lo gia đình, nấu nướng, đón con... Thời gian OT sẽ gặm nhấm quỹ thời gian họ dành cho gia đình. Người hiểu được điều ấy sẽ sẵn sàng giúp đỡ và khiến teamwork tốt lên.
Nhưng
Nói nghe thì có vẻ đơn giản lắm. Nhưng thay đổi suy nghĩ, thay đổi Mindset lại là một trong những điều khó nhất đối với mỗi người.
Người quản lý dám giữ vững Mindset đúng đắn sẽ phải đối mặt với sự phật ý của khách hàng hay sếp của họ. Nguy cơ cao hơn có thể mất dự án, mất chức. Phải là người thực sự dũng cảm và có năng lực mới làm được điều ấy.
Là một member, đôi khi phải có những lúc bắt buộc phải OT, dù có thể khó chịu hay bất mãn. Nhưng cũng nên thử đứng ở vị trí của người quản lý để thông cảm và cùng với họ giải quyết vấn đề gặp phải.
Mong rằng bài viết sẽ giúp ích được cho nhiều người trong quá trình làm dự án. Rất mong có sự đóng góp ý kiến từ mọi người để cho mình có cơ hội được học hỏi và biết thêm những kinh nghiệm quý báu. ^^