Chuyện OT trong ngành IT

Bài viết được sự cho phép của vntesters.com

Chia sẻ thẳng thắn, góc nhìn đa chiều của bạn Nguyễn Dương Hải về chuyện OT (overtime). OT có lẽ khá quen thuộc với một số bạn trong ngành IT (Information Technology).

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 mình (BA) đã 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ả 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!”

Tối đó, mình có cảm giác bạn lead không còn tin tưởng mình nữa. Mình mang tâm lý đó và cố gắng làm tiếp việc của mình. Đây là cuộc nói chuyện trên chat của mình và bạn lead:

• Bạn phải chấp nhận team 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 project cả team dính NDA. Đó là lần đầu tiên team nghe nói về cái NDA này. Kết quả quy lỗi về Development team (PM+Dev+QA) thay vì người không nói cho team biết cái này từ đầu. Mình (QA lead) cũng cảm thấy rất có lỗi vì đã không nghĩ ra sớm. Nhưng với lượng task mình làm ngày làm đêm mà vẫn không xong. Chuyện dành thời gian để thở, suy nghĩ ra những risk 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 đó!
• 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 đó!

Control client

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. 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. Bạn cũng không thể trả cho nhân viên được. 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!

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

• Mặt trái của ngành kiểm thử phần mềm
• Code Đức
• “Sống sót” qua những áp lực trong tuyển dụng IT – lập trình, có dễ không?

Xem thêm Việc làm Developer hấp dẫn trên Station D