Log work và những chuyện liên quan

Log work là cụm từ chẳng xa lạ với các bạn làm công nghệ thông tin, đặc biệt là những lập trình viên làm việc ở các công ty gia công phần mềm. Những công ty gia công phần mềm đạt được chứng chỉ CMMi ở mức cao thì kiểm soát việc này rất chặt chẽ, ở các công ty startup hay product thì có thể không có và cũng ít đặt nặng vấn đề này hơn. Trong bài viết này mình muốn viết về những trải nghiệm của mình về việc này.

Log work là gì

Trong mô hình phát triển phần mềm Scrum thì có một thuật ngữ là Work Log để chỉ khoảng thời gian một người sử dụng để làm việc trên một đầu việc. Và log work chính là việc ghi lại bạn đã tiêu tốn hết bao nhiêu thời gian cho một đầu việc đó. Chừng nào đầu việc đó chưa hoàn thành, và bạn cần thời gian để làm, thì chừng đó bạn còn log work vào công việc đó. Thoạt nhìn thì vấn đề vô cùng đơn giản, bạn làm bao nhiêu thì báo cáo bấy nhiêu, nhưng thực tế có nhiều vấn đề phức tạp và thú vị xoay quanh vấn đề này.

Tại sao bạn cần phải log work chính xác

Trước hết, chúng ta cùng tìm hiểu một chút, tại sao lại cần phải log work. Log work giúp ích nhiều cho việc quản lý công việc của các thành viên trong một nhóm. Các thành viên trong nhóm khi làm việc và log work sẽ tạo ra dữ liệu báo cáo chuẩn về năng suất làm việc của từng thành viên, điều này sẽ giúp các thành viên và người quản lý dễ dàng estimate được tình hình công việc. Nếu người quản lý dự án có nghỉ việc giữa chừng, thì người quản lý tiếp theo cũng dễ dàng dựa vào số liệu đã có để biết về khả năng làm việc của các thành viên. Thậm chí những số liệu log work ở thời điểm đầu của dự án cũng giúp cho việc estimate ở những thời điểm sau của dự án dễ dàng và chính xác hơn.

Những dữ liệu này thực sự rất có giá trị, chúng còn được sử dụng để rút kinh nghiệm cho những dự án tương tự, giúp cho việc đánh giá, estimate các dự án khác có độ chính xác cao hơn, làm tăng khả năng thành công của dự án. Đồng thời đội bán hàng cũng dựa vào những dữ liệu này để đấu thầu dự án. Khi có những dữ liệu này, đội bán hàng có thể tính toán được tương đối thời gian, và chi phí cần bỏ ra, và ước lượng một mức giá tốt cho khách hàng mà vẫn đảm bảo được chất lượng hay tiến độ. Như vậy ta có thể thấy, việc log work hàng ngày của các thành viên trong dự án là vô cùng quan trọng và cần thiết.

Log work chính xác lại không hề dễ

Log work quan trọng như vậy nên việc log work chính xác cũng vô cùng cần thiết, nhưng không phải lúc nào chúng ta cũng làm được. Giả sử bạn bắt đầu một ngày mới với 1 cái task và 2 cái bug. Và bạn sẽ estimate từng việc một như sau task 4 tiếng, bug thứ nhất là 2 tiếng và bug thứ hai là 1 tiếng. Một ngày làm việc của bạn là 8 tiếng và lý tưởng bạn sẽ chỉ estimate cho 7 tiếng làm việc hiệu quả, còn 1 tiếng để trừ hao cho việc đi uống nước, vệ sinh cá nhân, đọc báo, chém gió thư giãn hay ăn uống.

Tuy nhiên thực tế thì sẽ chẳng bao giờ được như vậy cả, bạn sẽ làm một cái task mất 6 tiếng, và 1 cái bug mất 2 tiếng. Bạn sẽ log 6 tiếng vào task và 2 tiếng vào bug, cộng thêm thời gian đi uống nước và vệ sinh thì bạn đã mất hơn 8 tiếng ở công ty. Bạn đã vừa phải ở lại muộn lại còn log quá thời gian estimate ban đầu. Vẫn còn 1 bug bạn chưa hoàn thành, tùy vào mức độ cấp thiết, bạn có thể để ngày mai fix hoặc tiếp tục ngồi lại để fix nhưng chắc chắn bạn đã log quá thời gian estimate ban đầu. Nhiều task bị log quá thời gian như vậy sẽ khiến báo cáo năng suất của bạn thấp và thật khó để đòi quản lý của mình tăng lương vào kỳ đánh giá.

Vậy sao ta không log vào task 4 tiếng, vào bug thứ nhất 1 tiếng như dự định ban đầu, dù đã đến giờ về thì ta cố ngồi lại làm nốt cái bug còn lại, và dù làm mất bao lâu thì cứ log 2 tiếng thôi, vậy là ta đã hoàn thành chỉ tiêu với estimate ban đầu là 7 tiếng một ngày. Xin thưa nếu bạn cứ lặp lại việc này, bạn đang tự hại mình khi quản lý sẽ nhìn vào số liệu và nghĩ rằng năng suất bạn đang rất tốt và cứ giao việc như vậy khiến ngày nào bạn cũng phải ở lại làm muộn thậm chí rất muộn để hoàn thành công việc.

Vậy hãy làm ngược lại, estimate ban đầu rộng rãi ra, cái task đó sẽ làm trong 8 tiếng đi, ta sẽ chỉ mất 6 tiếng để làm và còn dư 2 tiếng ăn chơi nhảy múa. Rất tiếc, bạn mà làm vậy sẽ càng sai lầm hơn, nhất là khi ai trong dự án cũng nghĩ như bạn, khi người quản lý tập hợp báo cáo từ nhiều người sẽ ra năng suất thấp cho cả dự án. Thường các dự án gia công là fixed-price, với chi phí và thời gian đã được xác định từ trước. Nếu thường xuyên estimate quá rộng hoặc thực sự là bạn làm chậm hơn so với estimate thì bạn sẽ bị chậm deadline và OT là điều không thể tránh khỏi.

Bạn có thể nghĩ, sao mấy ông quản lý lúc estimate dư ra cho anh em đỡ vất vả, và còn đề phòng những vấn đề rủi ro không lường trước được nữa. Thật ra lúc estimate, họ cũng luôn có buffer để dự trù những tình huống như này, tuy nhiên trong nhiều trường hợp cũng không thể đánh giá đúng tình hình, và dự án vẫn lụt và anh em phải OT. Cho dù có dữ liệu log work để tham khảo, thì không phải lúc nào cũng có thể lường được những phát sinh ngoài ý muốn, hay mức độ phức tạp của dự án vào thời điểm lên kế hoạch ban đầu. Những vấn đề phát sinh sẽ chỉ được mọi người nhận ra khi bắt tay vào làm dự án một thời gian. Vậy nên mới có những dự án buffer đến 200% mà vẫn cháy.

Một hệ lụy từ việc log work sai theo chiều hướng có lợi cho nhân viên, đó là sẽ hình thành những báo cáo sai về năng suất cho loại hình dự án đó. Năng suất nhân viên trong báo cáo thấp, chi phí nhân công sẽ tăng cao. Khi đó đội bán hàng lại gặp khó khăn trong việc bid dự án. Thị trường outsourcing vốn đang cạnh tranh khốc liệt, rất nhiều công ty dựa vào chi phí nhân công giá rẻ làm lợi thế cạnh tranh, nếu để chi phí giá cao thì khó bid dự án, còn nếu để thấp thì lại sợ làm không kịp tiến độ và không đảm bảo chất lượng. Khi đó chúng ta có thể không có dự án để làm hoặc sẽ nhận phải những dự án khó lường và anh em phải ngày đêm OT để hoàn thành công việc.

Phần lớn các dự án sẽ khiến chúng ta cảm thấy công việc ngập đầu, và để log work đúng với những gì estimate ban đầu là điều không đơn giản. Tuy nhiên, cũng có những lúc dự án lại rất nhàn và bạn không có task để mà log work. Bộ phận làm dự án ODC (offshore delivery center) có lẽ hay gặp điều này hơn khi dự án đã đi vào ổn định và thường mang tính chất maintain hay phát triển chậm mà chắc. Việc không quá nhiều, các đầu việc khi chia ra và phân bổ cho các thành viên cũng không hết được một ngày. Ví dụ như bạn có 1 cái task chỉ 4 tiếng hoàn thành xong, vậy 3 tiếng còn lại bạn log work vào đâu. Nếu để nhân viên không làm gì thì có vẻ phí nguồn nhân lực và báo cáo trống 3 tiếng vậy cũng không hay. Để giải quyết điều này, người quản lý thường tạo một task training một kĩ năng nào đó có thể liên quan đến công việc hiện tại, như vậy sẽ tránh để phí nguồn lực, biết đâu kĩ năng này sẽ có ích vào một lúc nào đó. Dù sao đây vẫn là một cơn đau đầu dễ chịu với người quản lý. Tuy nhiên những dự án thế này không nhiều.

Kết luận

Qua những điều kể trên, các bạn có thể thấy log work chính xác là vô cùng cần thiết. Tất nhiên, sẽ không có gì là tuyệt đối cả, các bạn chỉ cần để ý và log work tương đối đúng với năng suất làm việc của mình. Mỗi một người làm đúng thì cả dự án một chục hay vài chục còn người sẽ hình thành nên một dữ liệu báo cáo đầy đủ và khá chính xác. Như vậy sẽ thuận lợi cho người quản lý trong việc đảm báo chất lượng và tiến độ dự án. Đồng thời giúp cho các bạn và nhiều người khác gặp phải những dự án khó nhằn trong tương lai. Có thể nói việc bạn có phải OT hay không, dự án có thể release thành công được hay không, chính là nhờ một phần lớn ở công log work của các bạn ngày hôm nay.