Các bác làm thế nào để hạn chế OT, ON (overnight) trong công việc?

Đôi khi chỉ cần đọc kinh nghiệm của những người đi trước cũng học được nhiều điều.

Mình từng làm OT rất nhiều.

Trong năm thứ 2 mình làm việc ở công ty đầu tiên, có những dự án mình làm ngày thường thì cứ 2 ngày OT liên tục, ngủ lại ở công ty (khoảng 4-5 tiếng/ngày), mình về nhà một buổi sáng rồi chiều hôm đó lên công ty tiếp tục cái vòng xoay ấy. Thứ 7 và chủ nhật thì mỗi tháng cũng phải làm fulltime 2-3 tuần.

Hồi đó công ty mình chủ yếu trả lương theo kiểu nếu anh làm OT thì tính lương 150%, 100% là lương và 50% cộng vào ngày nghỉ phép. Lúc đó phải 3 - 4 tháng liền tháng nào mình cũng lãnh gấp đôi lương. Còn ngày nghỉ phép? Sau 2.5 năm làm việc mình xin nghỉ 1 kỳ nghỉ lớn, 2 tháng được ăn lương không phải đi làm, và mình vẫn còn thừa ra một ít ngày nghỉ khi chuyển hợp đồng sang công ty con.

Chuyên đó là bình thường! Đó là suy nghĩ của 1 đứa nhóc 2.5 năm tuổi nghề. Dự án cần, bạn không làm tức là bạn không yêu dự án, không hết lòng với công ty. Sau 1 năm rưỡi từ khi bước vào công ty, mình từ QC Junior level 1 trở thành QC senior level 2.

Rồi mình thay đổi.

Cũng chính đứa nhân viên làm hết lòng vì công ty đó, sau này khi trở thành QA team lead lại là đứa to mồm phản đối chuyện này nhất. Nó kiên quyết phản đối chuyện OT đến nỗi mà nó đã đắc tội với không biết bao nhiêu là manager của công ty, bao gồm cả founder.

Sau này, khi ra đi ấn tượng xấu nhất của mình về nơi đã nuôi nấng mình thành 1 QA trưởng thành chính là chính sách OT và cách đánh giá đóng góp của nhân viên của công ty đó.

Điều buồn cười là, sau này, khi mình vào công ty gần đây nhất (SSS) thì mình lại làm thêm giờ. Nó thậm chí chẳng phải là OT, mình không được trả thêm tiền nhưng mình vẫn làm. Mặc dù mình kiểm soát bản thân để làm cao lắm đến 9h rồi về nhưng không có ngày nào mình về nhà mà mình cảm thấy thỏa mãn. Mình không thức buổi tối giỏi, nhưng buổi sáng mình vẫn dậy sớm, tập thể dục và ngồi làm cho tới giờ đi làm.

Tại sao lại như vậy?

Mình vẫn hiểu được tâm mình muốn gì, nhưng thật khó diễn đạt thành lời. Chỉ đến khi mình đi event Founders Stories: Empowering Women Entrepreneurship và nghe chị Linh Thái, CEO & founder of Rita & Phill kể chuyện, vốn chẳng focus vào việc OT lắm, mình mới giải thích rõ được mình thật sự cần gì để chuyện OT trở thành một việc hiệu quả. Đây là câu chuyện chị kể:

Chị làm việc 10 năm ở Mỹ và họ làm rất tập trung và cật lực, nhưng sang VN thì không vậy nữa và chị phải học cách chấp nhận và improve nó. Chị hiểu rằng cách tốt nhất là khuyến khích nhân viên về nhà đúng giờ nhưng luôn luôn học hỏi. Công việc sẽ hiệu quả vào ngày mai nếu bạn học hỏi và tiến bộ hơn, hiểu nhiều điều hơn so với ngày hôm qua. Và nếu họ cảm thấy ở cty, làm việc tiếp là học hỏi họ sẽ tự động ở lại…

…Lúc còn bé chúng ta trả học phí để được học kiến thức, và chúng ta học ngày học đêm. Bây giờ, hãy nghĩ rằng có người trả học phí cho chúng ta để được học. Hãy học hỏi thật nhiều! Tích lũy kiến thức thật nhiều và nếu có cơ hội …. leave! Open your own business!
Vậy tôi đã thấy được OT cần gì để hiệu quả?

1/ Hãy biến nó thành thời gian học hỏi.

Mình nghĩ đó là lý do tại sao mà trong những năm đầu mình OT và ít ca thán. Tất cả mọi thứ xung quanh mình đều mới mẻ, đều đáng giá để mình bỏ thời gian và công sức đề tìm hiểu.

Sau này cũng vậy, mình được giao 1 role mới BA và cũng có 1 việc chưa thành thạo là QA automation. Khi mình ở lại, thực ra mình không hẳn đang làm việc, mình chỉ đang dùng cái project hiện có của mình để làm “bãi thử nghiệm” cho những skill còn chưa hoàn thiện của mình thôi.

Nó hoàn toàn khác với việc bạn bắt một người ở lại làm thêm giờ để làm những công việc lặp đi lặp lại, cái mà họ đã làm buổi sáng hết mình nhưng vẫn không xong. Rất nhiều đồng nghiệp của mình, kể cả ở công ty khác nói rằng sau khi làm 1-2 năm ở công ty của họ, họ chỉ thấy sức khỏe giảm sút và chẳng học được thêm điều gì. Họ còn nói với nhau " làm chỉ vì tiền thôi còn nếu muốn học hỏi thêm thì đừng vào đây!". Mình cũng vậy, và mình cũng không cam tâm khi thấy member của mình cũng vậy!

Hãy luôn tạo điều kiện để họ học cái mới. Nhưng đi kèm với nó là điều ở dưới đây

2/ Room to learn, room to fail

“Tạo môi trường học hỏi”. Ai cũng nói được câu này, nhưng ít ai hiểu rằng một môi trường tốt là một môi trường cho bạn cơ hội để thở, để thấm thấu cái bạn học, và để thư giãn cho ngày mai học tiếp. Lại càng ít manager hiểu rằng, họ phải control expectation của họ, để không làm cho nhân viên cảm thấy ngộp thở và cảm thấy họ vô dụng, trong khi họ thực sự đã học được rất nhiều.

“Bạn đã bao giờ nói nhân viên của bạn dừng lại, đừng làm nữa và hãy đi về với gia đình chưa?”

Có một lần, như là BA, mình đã phân tích sai yêu cầu của 1 feature. Lúc đó là 8h tối khi chúng tôi phát hiện ra bug và kết quả sẽ là Developer phải rework ít nhất là 1 ngày. Câu đầu tiên bạn lead nói với mình là:

“Anh Hải, anh đi về thôi! Ngày mai hãy làm tiếp!”

Ở đây có 2 điều mình muốn nói:

Khi học, bạn phải chấp nhận họ có thể fail. Control cái fail này trong giới hạn cho phép và luôn dành ra time cho rủi ro là điều quan trọng.
Phải có điểm dừng trong chuyện học. Nếu không, chỉ đơn giản là bạn overworked và died. That’s it!
Ở công ty đầu tiên, mình không có được cái cảm giác an toàn đó. Mình từng làm ở 1 project, cuối cùng cả team dính NDA contract. Và cho dù đó là lần đầu tiên cả team được nghe nói về cái NDA contract này, kết quả vẫn quy lỗi về của Development team (PM+Dev+QA) thay vì là người đã không nói cho team biết cái này từ khi bắt đầu dự án. Như là QA lead, mình cũng cảm thấy rất có lỗi vì đã không nghĩ ra sớm. Nhưng mà mình hiểu rằng, với lượng task mình làm ngày làm đêm mà vẫn không xong, thì chuyện dành ra thời gian để thở, để suy nghĩ ra những risk như thế này là chuyện nực cười. Lời khuyên nếu bạn là lead mà thậm chí không có thời gian để thở, để nhìn dự án một cách bao quát, ngập mặt vào việc thì cái danh của bạn chỉ là danh hão thôi!

3/ “Get Shit Done?”. Let’s apply for ALL shit!

Rất nhiều manager khi nói rằng nhân viên của họ nên (phải) ở lại làm, là vì yêu dự án, là vì dự án có vấn đề và như là người làm ra nó, chúng ta phải có trách nhiệm giải quyết. “Get shit done!”. Một trong những cách giải quyết là OT (?). Mình có vài lần đã nói với họ rằng “Ok! OT 1, 2 lần không sao vậy anh giải quyết vấn đề OT đó thế nào?”, Họ nói rằng “OT là chuyện không tránh khỏi!”. Không! OT không bình thường, nó là dấu hiệu của việc team bạn đang làm không đúng theo kế hoạch, hoặc không hiệu quả, hoặc có gì đó làm họ chậm lại. Bạn yêu cầu Developer của bạn OT để chạy cho kịp dự án? Vậy bạn có bao giờ làm những việc này:

• Nhận lỗi là có sự chủ quan từ estimate của mình và leaders?
• Nói với client yêu cầu của họ về thời gian hay chức năng là vô lý?
• Yêu cầu họ đưa requirement và design đúng thời hạn?
• Nếu họ làm không đúng, bạn đứng ra thay mặt team nói rằng team không thể làm khi họ không làm tròn phần của họ được?
  Nói ngắn gọn là thế này:

Bạn push member của bạn để họ chạy kịp dealine. Chuyện dễ! Đừng tự hào về việc đó!
Bạn làm việc chung với team bạn, xắn tay làm để kịp deadline. Ok! bạn là leader tốt nhưng không giỏi!
Bạn dám đứng ra giải quyết những vấn đề, như một leader, để team bạn có một môi trường làm việc tốt. Sign me up! Tôi muốn làm nhân viên của bạn đó!
Có 1 lần, ở công ty cũ mình đã phải đập bàn và chỉ thẳng mặt vào người PGM/Onshore nước ngoài đó nói rằng: “Chị (you) không biết control client! Cost 1 ngày test chị giảm xuống còn 3 tiếng. Lúc team tôi test thì chị cứ đứng canh rồi hối! Bây giờ chị còn muốn tụi tui nghĩ cho client những thứ không có trong hợp đồng kiểu như “best for customer” hả? Chị ít nhất hãy cho chúng tôi thời gian để làm tốt việc của chúng tôi đã rồi hãy tính đến chuyện đó!”. Founder đứng ngay kế bên đã phải lên tiếng đỡ lời cho người PGM đó. Sau cuộc họp, anh Technical Director của công ty, trong cuộc họp của QA tới và nói rằng: “Hải! Câu quá thẳng thắn, cho dù cậu có nói đúng đi nữa thì nói như vậy cũng chỉ hại cậu mà thôi!”

Sau này, tôi thề sẽ không bao giờ nhìn mặt cái người PGM/Onshore đó nữa, và may mắn thay tôi đã rời công ty, còn cô ta thì đi về công ty mẹ ở nước ngoài.

4/ Nhìn nhận sự đóng góp và tiến bộ của nhân viên

Câu hỏi là “Nếu họ làm OT, bạn nghĩ đó là việc của họ?”

Đã từng có thời tôi nhận được câu trả lời là “Họ đang đóng góp tích cực cho công ty!”. Không phải chỉ từ công ty tôi, mà là từ tất cả những công ty IT nói chung mà bạn bè tôi làm việc. Và đúng là họ có những sự khen thưởng đúng đắn và trả công xứng đáng (OT) cho nhân viên!

Về sau này, câu trả lời thường xuyên mình nhận được là: “That’s their job! It’s their fault to not complete their tasks on time, so they have to finish it!”

Có một số công ty, trong job description gửi kèm qua email thậm chí còn có một dòng headline ở dưới, ngụ ý nói rằng việc OT sẽ có thể được diễn ra, không thường xuyên nhưng sẽ có, và có thể sẽ không có OT money.

Tôi vẫn nghĩ chuyện đó bình thường! Thực ra thì, cái quan trọng không phải là bạn nói gì mà quan trọng là bạn làm gì. Và theo kinh nghiệm của tôi, OT có thể được đên bù bằng nhiều thứ, không chỉ là trả tiền thêm giờ:

• Bạn có flexible hour, và phải chắc chắn là nó flexible. OT là khi bạn nhất thiết phải có người đó để làm việc. Hãy release họ khi bạn không cần.
• Promotion.
• Chê độ khen thưởng, tăng lương.
• Team building.
• Trả tiền thêm giờ! Hãy fair với nhân viên. Làm việc lâu năm, mình hiểu là nếu client không trả tiền, thì bạn cũng không thể trả cho nhân viên được. Vây câu hỏi là, nếu client đã trả tiền rồi bạn có minh bạch, thông báo và trả tiền cho nhân viên không? Hay đi xa hơn nữa, là một khoản khấu hao nho nhỏ?
  Lời kết

Bài viết này chỉ đơn giản chủ yếu là nhưng câu chuyện mà mình, như là một đứa trẻ QA 6 tuổi trải qua. Mình biết rằng ở đâu đó cũng có rất nhiều bạn đang gặp những vấn đề tương tự. Cái mình hy vọng, là những manager sẽ nghe những câu chuyện về member của họ, để họ có thể làm cho công ty của họ tốt hơn, bắt đầu từ việc OT này. Nếu bạn không đồng tình, cho rằng mình là kẻ lắm điều nổi loạn, hãy cứ xem như bạn được nghe kể những câu chuyện thật, đã từng xảy ra với ai đó. Đối với mình vậy là được rồi

ref:
https://www.linkedin.com/pulse/chuyện-ot-trong-ngành-nguyen-duong-hai/

OT nhiều hay ít thì yếu tố đầu tiên đến từ phương thức quản lý dự án của công ty
Kế tới trình quản lý của tên PM (quản lý team, quản lý change request từ khách hàng)
Kế nữa là năng lực của team làm dự án
Kế nữa là năng lực bản thân

Tóm lại, để hạn chế OT, bạn có thể:

• nâng trình, code nhanh hơn và ít bug hơn
• training cho bọn level cùi trong team
• estimate thời gian chính xác hơn
• đưa task sau 5h không làm
• ép deadline quá không làm
• tìm hiểu về công ty trước khi ứng tuyển

Và, chúc bạn may mắn lần sau

Code ẩu.
Hết giờ về sống chết mặc bây.

Vui thôi

Cảm ơn anh. Điều này em đã nghiệm ra trong thời gian học đại học mà bị giao quá nhiều đồ án: [quote=“nguyenhuuca, post:2, topic:63998”]
một môi trường tốt là một môi trường cho bạn cơ hội để thở, để thấm thấu cái bạn học, và để thư giãn cho ngày mai học tiếp. Lại càng ít manager hiểu rằng, họ phải control expectation của họ, để không làm cho nhân viên cảm thấy ngộp thở và cảm thấy họ vô dụng, trong khi họ thực sự đã học được rất nhiều.
[/quote]
Làm việc nếu không có thời gian để thở, để nhìn bao quát lại xem mình đang làm, làm đến đâu, có ổn không mà chỉ biết cắm mặt vào làm cho xong thì không bao giờ ổn. Ngay cả những cái đồ án mà khiến cho em mắc bệnh mất ngủ đó, thầy chỉ chấm qua loa, xem sơ chức năng còn phần code thì xem qua cho biết, không có ý kiến xây dựng gì. Nếu vậy đồ án đó tồn tại để làm gì, khi đề tài không mới mẻ, thầy cô không muốn chấm, sinh viên không muốn làm. Thời gian đó dành vào việc học cách viết code tốt hơn, hoặc những kiến thức nền tảng cũng được. Ít nhất nó đem lại cho mình cảm giác tiến bộ hàng ngày, để mình biết rằng nếu bắt tay vào code thì mình cũng sẽ code thông minh, hiệu quả hơn.

Vụ đồ án là do em chọn đề đúng lĩnh vực giáo viên nghiên cứu hay không.

Thầy cô nào cũng có thể hướng dẫn build các app quản lý, nhưng với đề tài nghiên cứu học thuật, như: phát hiện vi phạm người tham gia giao thông qua camera, kĩ thuật dịch ngược tự động, xác định biển số xe thông qua ảnh, đăng nhập bằng khuôn mặt thông qua ảnh, phân task tự động trong hệ thời gian thực,… thì thầy cô có kiến thức, kinh nghiệm và những xu hướng mới đang nổi để truyền lại.

Mới đọc có nữa bài thôi. Nhưng mình quyết định dừng lại, like cái để đọc tiếp. Bạn cho mình cái nhìn tổng quát của nghề Dev, thông tin rất hữu ít cho mình.
Mình chia sẻ câu chuyện của mình: “Trước kia mình làm trưởng phòng kinh doanh của một cty nhật, sếp mình chỉ thị mình làm một phần mềm tính giá cho cty để giảm thời gian tính giá sản phẩm. Sau khi tìm được một cty phần mềm lãnh dự án bên mình, mình đã chỉ hết các nghiệp vụ. Giao cho họ cái deadline và yêu cầu họ hoàn thành đúng theo thời hạn đó.” Nhưng mà cuối cung vẫn không được, thế là mình lãnh đủ các chỉ trích. Bực mình quá mình xuống cty đó, ăn ngủ dưới đó hai ngày mới hoàn thành dự án".
Sau khi hoàn thành xong đi ăn nhậu với coder đó, mình biết nó làm rất nhiều dự án trong cùng một lúc. Nên không có thời gian hoàn thành dự án bên mình.
Và một lý do nữa là nó không quản lý được thời gian, triệu nhiều sự quấy rối của nhiều người nên không tập chung vào cv được.

mình thấy các fsu ở fsoft mà làm cho nhật thì ko hiểu sao ot on cực nhiều phải chăng nó là văn hóa khi làm việc với nhật chăng

mà có những người còn có cả thành tích ot on lấy ra để khoe với bàn dân thiện hạ họ coi đó là niềm tự hào trong công việc hay sao ấy

Để hạn chế OT thì giải pháp chính là có thời gian dự phòng. Ví dụ căn dự án làm trong 1 tháng thì phải thêm 1 tuần cho đến 10 ngày để dự phòng. Nếu không thì rủi ro nhỏ phát là OT mệt nghỉ.

Nhật nó làm kinh lắm đú không lại đâu