Các công ty phần mềm ở VN luôn phải đối mặt với bài toán nhân lực khi mà nguồn nhân lực trong nước yếu kém cả về năng lực chuyên môn lẫn thái độ làm việc. Dưới góc độ một công ty phần mềm, đặc biệt đối với công ty tư nhân, đây là một khó khăn khách quan vượt ngoài tầm kiểm soát. Tuy nhiên điều mà họ có thể làm là tạo điều kiện làm việc tốt hơn cho LTV nhằm thu hút thêm nhân tài, đồng thời tận dụng tốt hơn nguồn lực sẵn có.
Trước hết ta cần phải hiểu một đặc thù tối quan trọng của công việc lập trình: nó đòi hỏi sự tập trung cao (đế suy luận) và cảm hứng (để sáng tạo).
- Hiệu quả làm việc của LTV sẽ tăng theo cấp số nhân so với mức độ tập trung. Nguyên nhân: LTV gần như phải nạp toàn bộ kiến trúc hệ thống và các chi tiết của module mà họ đang thực thi vào bộ nhớ tạm, trong khi bộ vi xử lý liên tục làm việc song song.
- Bên cạnh đó, nếu muốn tận dụng khả năng sáng tạo của LTV để có những bước đột phá công nghệ, cần trân trọng và kích thích cảm hứng, nhiệt huyết, đam mê của họ.
Lập trình gần với viết sách hơn đánh máy vi tính.
Theo tôi quan sát trực tiếp ở một số công ty, nghe ngóng từ bạn bè cũng như lượm lặt từ nhiều blog cá nhân, các công ty phần mềm ở VN chưa làm tất cả những gì có thể trong khả năng của họ để tạo điều kiện làm việc tốt nhất cho LTV, qua đó tận dụng tối đa nguồn lực trí óc mà LTV mang lại.
Sau đây tôi sẽ đi sâu vào 3 yếu tố cấu thành nên điều kiện làm việc: thời gian, không gian, con người.
Thời gian
Mọi chính sách quản lý thời gian trong một công ty phần mềm cần phải cân nhắc đến cách làm việc tối ưu cho LTV: họ làm việc theo từng khoảng thời gian dài, tuyệt đối không bị gián đoạn. Nguyên nhân: (1) LTV phải bỏ ra chi phí thời gian không nhỏ để "khởi tạo" bộ nhớ và bộ vi xử lý mỗi lần bước vào trạng thái tập trung, (2) bước vào trạng thái tập trung rất khó nhưng mất trạng thái này rất dễ, (3) trong một ngày, số lần có thể rơi vào trạng thái tập trung là hữu hạn (1-2 lần).
Đừng áp dụng giờ hành chính đối với LTV
Chính sách áp dụng giờ hành chính một cách nghiêm ngặt đối với LTV, theo tôi, là một sai lầm phổ biến nhất mà cũng dễ khắc phục nhất trong các công ty phần mềm. Dưới đây là những nhược điểm của chính sách này:
- Tăc đường: Ở HN, cứ tầm 8h sáng và 5h30 chiều là đường phố đều đầy bụi và xe. Đi lại vào các khung giờ này vừa lãng phí thời gian vừa tổn hại sức khoẻ. Khi đến công ty, LTV thường khá mệt mỏi về tinh thần, điều này gây khó khăn cho việc bước vào trạng thái tập trung.
- Không phù hợp với đồng hồ sinh học của mọi LTV: Mỗi người có một khoảng thời gian "ưa thích" trong ngày riêng, lúc mà họ dễ dàng rơi vào trạng thái tập trung nhất. Không phải ai cũng ưa khung giờ hành chính thông thường. Ép buộc họ phải theo khung giờ này tức là họ sẽ không thể làm việc tối ưu.
- Tạo cảm giác gò bó: Quản lý chặt chẽ theo khung giờ hành chính ảnh hướng không nhỏ đến cảm hứng làm việc của LTV. Nếu không quản lý, đôi khi LTV có thể mải mê với công việc đến 8-9h tối, vì họ vốn là những người yêu công việc. Thế nhưng nếu khắt khe, họ sẽ ra về "vào đúng giờ quy định". Vấn đề ở đây là, bản thân LTV không biết khi nào trạng thái tập trung của họ sẽ kết thúc. Đặt một mốc giờ ra về cố định sẽ làm ảnh hướng đến tâm lý của họ khi đang tập trung.
Đối với công việc lập trình, việc áp dụng giờ hành chính là không cần thiết. Liệu nhà xuất bản có nên yêu cầu người viết sách phải đến văn phòng theo giờ hành chính không?
Theo tôi, một chính sách thời gian mềm mỏng cho LTV sẽ hợp lý hơn. Trước hết, nên đảm bảo cho LTV có thể làm việc tại nhà. Tuy vậy, không gian ở công ty vẫn nên đủ hấp dẫn để LTV thích đến công ty hơn ở nhà (sẽ bàn trong phần sau). Về thời gian ở công ty, cho phép LTV đến và về lúc nào tuỳ thích, có thể ngủ lại qua đêm nếu muốn.
Hãy hình dung công ty như một không gian cho phép các nhóm đến bàn luận và làm việc cùng nhau, thay vì nơi để cấp trên có thể kiểm soát hoạt động của họ.
Nếu không quản lý LTV về thời gian thì quản lý họ theo kết quả công việc, nhưng kết quả công việc lập trình rất khó đo lường. Lập trình không giống như dịch sách. Khi tôi đi dịch sách, Alphabooks trả cho tôi theo số lượng 1000 từ tiếng Anh - rất rõ ràng, đơn giản và hiệu quả. Thế nhưng sẽ thật ngớ ngẩn nếu trả cho LTV theo số LOC (lines of code).
Đây là một thực tế, một thử thách đối với nhà quản lý. Dù sao ta nên nhớ rằng, thử thách này vẫn tồn tại cho dù bạn có yêu cầu LTV đến và về theo giờ hành chính hay không! Áp dụng chính sách thời gian chặt chẽ chỉ tạo cảm giác áo cho nhà quản lý rằng LTV của họ đang làm việc cật lực, trong khi nếu bỏ hẳn đi yếu tố thời gian thì nhà quản lý sẽ chuyên tâm hơn vào việc đánh giá tiến độ và kết quả công việc. Trong trường hợp tối ưu, nhà quản lý có thể hoàn toàn tin tưởng vào LTV tự ước lượng deadline theo khối lượng công việc; khi này, trách nhiệm của nhà quản lý chỉ là hiểu rõ thế mạnh, sở thích từng người, qua đó phân phối công việc một cách phù hợp.
Đừng tổ chức meeting tuỳ tiện
Cần cân nhắc kỹ trước khi tổ chức mọi loại meeting, từ seminar thảo luận công nghệ cho đến nhóm họp cập nhật tiến độ công việc. Chi phí cho mỗi buổi meeting không đơn thuần chỉ là:
meeting_cost := meeting_duration * number_of_participants; // too naive
Quan trọng hơn là chi phí ngầm của meeting: nó can thiệp vào khoảng thời gian tập trung của LTV.
Tôi còn nhớ khi còn làm ở công ty X. Chúng tôi làm việc từ 8h. Seminar sẽ bắt đầu vào 9h. Tôi cố gắng làm một việc gì đó trong khoảng 8-9h, nhưng sau nhiều lần như vậy, tôi phát hiện ra rằng mình không thể làm được việc gì thực sự hiệu quả trong khoảng ngắn ngủi này.
Ở nhiều công ty nơi mà khái niệm "trạng thái tập trung" không được coi trọng, nhà quản lý không hề biết đến chi phí này, có lẽ bởi vì LTV của họ vốn dĩ chưa bao giờ làm việc tập trung.
Nói như vậy không có nghĩa là không nên tổ chức meeting dưới mọi hình thức. Ở đây, tôi chỉ nhấn mạnh chi phí không nhỏ của mỗi buổi meeting. Nhà quản lý nên cân nhắc và chỉ tổ chức meeting khi thực sự cần thiết. Meeting nên có sự chuẩn bị kỹ từ những người tổ chức, phải ngắn gọn về thời lượng và giá trị về chất lượng. Điều này vừa tiết kiệm tổng thiệt hại thời gian cho công ty, vừa thể hiện rõ sự trân trọng của công ty đối với thời gian của LTV.
Một yếu tố nữa cần phải cân nhắc là thời điểm tổ chức meeting. Theo tôi, nên tổ chức meeting định kỳ (để LTV có thể yên tâm tập trung mà không lo có meeting bất chợt) vào cuối ngày (để không cần yêu cầu LTV đến công ty sớm) trong một ngày làm việc cuối tuần (để tiện cập nhật tiến độ và phân phối công việc cho tuần sau), có sự tham gia của các thành viên trong nhóm (LTV nên biết những người còn lại đang làm gì để họ có cảm giác công bằng).
Nếu muốn giảm stress cho các buổi meeting định kỳ cập nhật tiến độ, có thể tổ chức theo phong cách thân mật, trong một quán cafe quen. Phương án này phù hợp với các nhóm làm việc độc lập, hiệu quả, nhà quản lý có thể tin tưởng.
Sự thật về thời gian
Để kết thúc phần này, tôi mong muốn vạch trần một sự thật về thời gian mà nhiều công ty phần mềm đã hiểu sai: không mấy ai có thể làm việc tập trung 8h/ngày, 5 ngày/tuần, 52 tuần/năm. Điều này là quá sức chịu đựng đối với một công việc quá nặng về trí óc như lập trình. Nếu bạn ép LTV làm việc như vậy, họ sẽ chống đối bằng cách này hay cách khác (bật IDE lên làm thơ, check mail vô mục đích, chat, F5 Facebook, nếu block Facebook rồi thì xem ảnh girl xinh, etc).
Trong "Lời xin lỗi của một nhà Toán học", Hardy cho rằng 4h/ngày hoàn toàn tập trung cho Toán học là đủ. Một blogger mà tôi tìm thấy trên mạng đề xuất ngày làm việc 6h, trong đó 2h cho sự lãng phí không tránh khỏi trong cơ cấu doanh nghiệp, 4h làm việc thực sự. 37signals thử nghiệm tuần làm việc 4 ngày, nghỉ từ thứ 6 đến CN.
Nói như vậy không có nghĩa là LTV chỉ cần tiếp túc với lập trình 4h/ngày. Thông thường, LTV bỏ nhiều thời gian ra để nghĩ về công việc, tìm hiểu công nghệ mới, tham gia vào các dự án nguồn mở, giao lưu với cộng đồng LTV, đọc sách trau dồi kiến thức, chơi các môn thể thao trí tuệ ... Đó đều là những hoạt động giúp họ nâng cao trình độ chuyên môn, duy trì đam mê, kích thích nguồn cảm hứng sáng tạo.
Sai lầm cuối cùng về thời gian, cũng là sai lầm không thể chấp nhận được mà tôi hy vọng không quá nhiều công ty mắc phải là:
working_time := time_in_front_of_computer; // fatal error!
Quy chụp tổng thời gian làm việc của LTV bằng số thời gian ngồi bên máy tính chẳng khác nào khuyến khích LTV làm việc mà không suy nghĩ.
