Hôm nay tôi thực sự burn out1, mặc dầu cả ngày cũng chẳng làm được gì nhiều ngoài đi họp và cãi lộn tranh luận với đồng nghiệp. Còn thời điểm nào tốt hơn để viết về năng suất cơ chứ?
Một mô hình về năng suất
Mô hình này được cựu nhân viên Google Y.Zhang nghiên cứu và chia sẻ. Ý tưởng là: con người, về cơ bản, hoạt động giống một cái máy tính trong một hệ thống phân tán (distributed system). Chúng ta không chia sẻ bộ nhớ, và giao tiếp, phối hợp với nhau bằng cách gửi và nhận những tập tin. Chúng ta nhận đầu vào (input) là email, chat, họp hành, tài liệu, bugs, v..v; xử lý chúng bằng kỹ năng và tài nguyên (thời gian + năng lượng) nhằm tạo ra kết quả (output). Output này sau đó được gửi đến cho 1 người khác để xử lý tiếp, giống như 1 pipeline trong data engineering.
Mục tiêu là tạo ra được nhiều output với chất lượng cao nhất, muốn vậy chúng ta chỉ cần kiểm soát 3 đại lượng: input, kỹ năng và tài nguyên.
Kỹ năng - Skill
Hai hệ thống tư duy
Trước hết, kỹ năng thực ra không phải thứ gì đó cao siêu, tất cả những gì bạn đang làm hằng ngày đều là kỹ năng: đi, đứng, ngồi, gõ phím, giải bài trên leetcode. Con người mất hơn 12 tháng để có thể đứng vững trên đôi chân mình và tập những bước đầu tiên. Vậy tại sao khi lớn lên, chúng ta hầu như quên đi quá trình tập đi và thậm chí không còn coi “đi” là 1 kỹ năng, vì ai mà chả biết đi, đúng không?
Đó là bởi có 2 hệ thống vận hành bộ não:
Hệ thống #1 hoạt động một cách bản năng, và không cần nhiều nỗ lực.
Hệ thống #2 có sự suy xét cẩn trọng và đòi hỏi nhiều tập trung hơn.
Hệ thống số 1 giúp chúng ta thực hiện những hằng ngày như ăn, uống, đi, lại; hay những việc đã từng rất khó lúc mới bắt đầu như gõ phím 10 ngón hay lái xe. Miễn là bạn dành cho hệ thống số 1 đủ nhiều thời gian và công sức luyện tập, (hầu hết) mọi kỹ năng đều có thể được học và cải thiện. Thời gian ở đâu ra thì lại là một câu chuyện khác.
20% Project
Hãy tưởng tượng bạn vừa gia nhập công ty mới. Bạn choáng ngợp trước một hệ thống lạ lẫm và khối lượng công việc cần hoàn thành trong thời gian thử việc. Rồi thời gian trôi qua, bạn quen dần với bộ máy, nhưng danh sách công việc cứ dài ra vô tận: PM liên tục nghĩ ra tính năng mới, tester dí cho bạn những chú bug hằng ngày. Bạn trở về nhà, kiệt sức vì cố gắng bắt kịp công việc, và không còn đủ năng lượng để tự phát triển kỹ năng. Ngày qua ngày, day by day… Đây là tấn bi kịch thường thấy ở anh chị em lập trình viên. Chúng ta có thể làm gì?
Google đã tiên phong trong một ý tưởng có tên là “20% Project”, trong đó nhân viên có thể dành 20% thời gian làm việc, tương đương 1 ngày trong 1 tuần, để tự do đóng góp vào những dự án lề (side project). Ban đầu người ta lo ngại rằng nó có thể làm xao nhãng công việc chính. Tuy nhiên, trên thực tế, nhiều sản phẩm cốt lõi của Google lại bắt nguồn từ những dự án lề “20% Project” như Gmail, Google News, AdSense.
Học tập từ ý tưởng này của Google, chúng ta có thể dành ra 20% thời gian để đầu tư cho phát triển kỹ năng. Năng suất làm việc có thể sẽ suy giảm ở giai đoạn đầu, nhưng nó sẽ giúp bạn làm việc hiệu quả hơn về lâu dài.
Một vài điều tôi thường làm trong “20% thời gian”, hi vọng có thể là gợi ý cho các bạn:
Tham gia các chương trình đào tạo nội bộ. Đây là một trong những điểm tôi thích nhất ở Google, có rất nhiều các chương trình đào tạo về đủ mọi thứ như: kỹ năng sử dụng Gmail hiệu quả, kỹ năng viết, kỹ năng review code, kỹ năng tiến hành meeting 1-1 với sếp.
Đọc và học hỏi từ code/ tài liệu thiết kế của những kỹ sư tốt nhất ở công ty. Ở công ty tôi thì không ai khác đó chính là Jeff Dean, người tạo ra Protocol Buffers, Spanner, MapReduce, TensorFlow v..v
Tham gia những khóa học online về những lĩnh vực mà bạn muốn cải thiện. Budget của Google cho khoản này là khoảng $6000 mỗi năm. Hiện tại nhiều công ty cũng đã offer những gói học tập hằng năm kiểu như thế cho nhân viên, đừng lãng phí chúng.
Tài nguyên - Resource
Trong công việc, tài nguyên mà chúng ta có chủ yếu ở 2 dạng: thời gian và năng lượng (mặc dù, năng lượng thường hết trước thời gian). Có 3 công cụ có thể cải thiện số tài nguyên bạn có: bổ sung nguồn cung, cắt giảm lãng phí và tập trung.
Bổ sung nguồn cung
Nguồn cung năng lượng thường có 2 loại: thể chất và tinh thần. Nhà đồng sáng lập Google, Sirgey Brin, từng yêu cầu các nhà thiết kế văn phòng: “Không ai được ở cách đồ ăn quá 200 feet”. Với tôi, điều này quá hợp lý cả về thể chất lẫn tinh thần, haha 😅.No one should be more than 200 feet away from food.
Cắt giảm lãng phí
Nguồn cơn của lãng phí thời gian và năng lượng thường đến từ:
multi-tasking: não người giống như 1 chiếc server với một core, hoặc cùng lắm là hai core (tôi chưa thấy ai làm 3 việc cùng lúc cả). Multi-tasking tương tự như việc các thread trong máy tính switch context. Một nghiên cứu cho thấy việc chuyển task liên tục có thể làm mất 40% thời gian làm việc hiệu quả.
chần chừ: chúng ta thường dùng hệ thống #2 để phân tích và ra những quyết định quan trọng. Tuy nhiên nhược điểm của hệ thống này là nó tốn thời gian và cả năng lượng. Càng chần chừ ra quyết định thì càng mệt.
lo lắng + không hành động: điều này khá rõ ràng, lo âu sử dụng chung pool năng lượng với hành động, càng lo lắng nhiều thì càng có ít tài nguyên để hành động và giải quyết vấn đề.
Tập trung
Theo tôi, 2 việc làm mất tập trung nhất ở công ty là check mail và đi họp. Gần đây tôi đã chuyển qua chế độ auto từ chối lời mời đi họp, nghĩa là mặc định từ chối đã, xong rồi mới xem xét tiếp 😏.
Input
Input là phần chúng ta có ít kiểm soát nhất vì nó thường đến từ sếp hoặc đồng nghiệp. Tuy nhiên, có 2 khía cạnh chúng ta có thể ít nhiều tác động được là: tần suất và thứ tự ưu tiên.
Tần suất
Nếu ôm nhiều việc quá sẽ dẫn đến burn out, nếu nhận ít việc quá thì lại ảnh hưởng đến khả năng thăng tiến. Tôi thấy lập trình viên thường hay under-estimate thời gian cần thiết để hoàn thành 1 việc, để rồi sau đó lại cuống cuồng làm ngoài giờ (OT). Về mục này, tôi học được 2 công thức từ sếp cũ:
Promotion = Under promise + Over deliver
Thăng tiến còn phụ thuộc vào nhiều yếu tố khác, dạo gần đây lại nổi lên trend tinh giản, nên tôi xin sửa lại công thức thành Risk of Layoff = Promise - Deliver cho hợp với thời cuộc. Hứa thật nhiều mà thất hứa cũng thật nhiều thì khả năng bị cook rất cao.
Total performance = constant value * sqrt(number of people)
Tổng hiệu suất tỉ lệ thuận với căn bậc hai của số người tham gia dự án. Khi bạn mới bắt đầu với một nhóm nhỏ, việc bổ sung thêm người sẽ mang lại những lợi ích đáng kể cho hiệu suất. Khi nhóm đã đủ lớn, việc bổ sung thêm thành viên mới sẽ không còn nhiều ý nghĩa nữa với hiệu suất tổng thể.
Thứ tự ưu tiên
Cựu kỹ sư Google, Edmond Lau - tác giả cuốn sách The Effective Engineer2 - đã đưa ra một công thức mà tôi rất tin dùng: L = I / T. Trong đó L là leverage - hệ số đòn bẩy, I là impact - mức độ ảnh hưởng, và T là time - thời gian thực hiện.
Đại ý là giữa muôn vàn công việc ở công ty, chúng ta nên ưu tiên những việc có hệ số đòn bẩy cao nhất, nghĩa là đem lại nhiều giá trị nhất trong dài hạn mà lại tốn ít thời gian nhất để thực hiện. Công thức này khá giống công thức ROI mà tôi đề cập trong bài viết Trồng cây gì, nuôi con gì?. Một vài hoạt động có hệ số đòn bẩy cao:
sắp xếp ưu tiên công việc: bản thân việc sắp xếp thứ tự công việc sử dụng hệ số đòn bẩy là một việc có hệ số đòn bẩy cao
mentor + sharing
cải tiến hoặc cắt bỏ bớt quy trình (ví dụ: áp dụng DevOps, Agile)
tạo ra những component, lib có thể tái sử dụng
viết doc, viết postmortem sau mỗi lần có sự cố
sử dụng 20% thời gian để nâng cao kỹ năng
Kết
Ngoài kia có đầy rẫy những sách báo đưa lời khuyên để tăng hiệu suất công việc nhưng, theo tôi, chúng ta cần có một framework hợp lý trước khi áp dụng bất cứ bí kíp nào. Hi vọng những điều tôi học được ở Google và chia sẻ trong bài viết này đem lại cho các bạn một góc nhìn mới về hiệu năng.
Cheers, until next time!
Burn out là tình trạng kiệt sức do áp lực công việc hoặc stress kéo dài.
Một trong những cuốn sách ưa thích của tôi The Effective Engineer
Kudos Quang vì đã có một bài viết chất lượng, có tính thực tiễn, súc tích và rất sáng tạo!
Có vài điểm mình muốn chia sẻ thêm:
- Về việc dành 20% cho dự án cá nhân rất hay nhưng phần lớn các công ty ở VN, vừa và nhỏ sẽ khó nếu muốn nói là không khả thi vì họ muốn tận dụng tối đa effort/capacity của nhân viên để có output/deliveries nhiều nhất có thể. Nên chỉ còn cách sắp xếp lối sống để làm những việc mình thích sau giờ làm hoặc cuối tuần. Một cách khác mà mình đã áp dụng là khi tham gia các dự án hãy xung phong chọn những việc mình chưa từng làm trước đó, để có cơ hội on job training và áp dụng vừa học vừa làm, một công đôi việc
- Về việc từ chối họp, theo quan sát và kinh nghiệm của bản thân mình thì khi ở cấp độ dev, việc họp sẽ không nhiều, trừ khi được allocate vào 2-3 dự án cùng 1 lúc hoặc team có văn hóa over-communication (cái gì cũng lôi ra họp). Còn khi đã lên manager phải quản lý nhiều thứ hơn thì có những cuộc họp bắt buộc phải có mặt để nắm được context mà xử lý. Một số cuộc họp có thể đổi lại thành async qua email hoặc chat hoặc đọc meeting notes (cho dev) hoặc kiếm ai đó delegates (cho lead/manager)
Mình đã có chia sẻ một bài về burnout cho dev, hi vọng có thể phần nào giúp Quang sớm vượt qua:
https://bryanthuynh.substack.com/p/cam-nang-phong-tranh-kiet-suc-cho
Take care!
Bài viết hay quá anh, e cũng học được 2 ý chính giống bài a viết từ 1 thầy em dạy là: làm vượt kì vọng, và làm việc quan trọng nhất.