3 bài học từ Getting Things Done

Vừa nghe podcast của mình vừa đọc blog nhé!

Nếu như bạn để ý thì mình là một fan của Getting Things Done (GTD) – phương pháp quản lý công việc/thời gian nổi tiếng do David Allen tạo ra (mình có một bài giới thiệu về phương pháp này tại đây)

Sau hơn 2 năm áp dụng phương pháp này, mình nhận ra rằng GTD không hoàn hảo như tên gọi của nó. Getting Things Done cũng có những lợi ích và khuyết điểm như bao phương pháp khác.

Trong bài blog lần này, mình muốn chia sẻ kĩ hơn 3 bài học về năng suất mình đã rút ra được sau khi áp dụng Getting Things Done vào trong cuộc sống. Mình hi vọng rằng những bài học này sẽ giúp bạn tránh khỏi những “cạm bẫy” mà GTD dễ dàng khiến bạn mắc phải, và tối ưu cho hệ thống quản lý công việc của bạn tốt hơn.

Nội dung chính trong bài blog lần này:

Bài học số 1: Một việc cho chín còn hơn chín việc

GTD khuyến khích chúng ta ném mọi suy nghĩ ra khỏi đầu để đầu óc chúng ta luôn được minh mẫn nhất. Sau đó, chúng ta sẽ nhìn xem công việc nào có thể làm dưới 2 phút thì chúng ta sẽ làm luôn.

Khoan đã. Hãy thử làm một phép tính.

Nếu vậy, giả sử chúng ta có 10 việc có thể làm trong 2 phút, vậy thì tổng thời gian chúng ta mất là bao nhiêu?

20 phút?
Không.


60 phút. Hoặc hơn.
Vì sao?

Mình không có một công thức kì diệu nào cả, nhưng mình tin rằng dù bạn có dùng hàng triệu thuật toán đi chăng nữa, đáp án cũng chắc chắn lớn hơn 20. Lý do rất đơn giản:


“Fear is not the mind-killer. Context switching is.”

Elon Musk

Trong một buổi phỏng vấn trên Clubhouse (một mạng xã hội mới ra đời gần đây) vào tháng 2 năm 2021, Elon Musk đã nói rằng “nỗi sợ không phải là thứ ảnh hưởng đến tâm trí, mà kẻ thù lớn nhất là việc thay đổi ngữ cảnh”.

Khi bạn bắt đầu làm một công việc gì đó, não của bạn cần một khoảng thời gian để bắt đầu suy nghĩ và tư duy. Ví dụ, khi bạn có một công việc “Trả lời email của đồng nghiệp X”, bạn sẽ phải đọc lại tin nhắn của họ, suy nghĩ xem câu trả lời là gì, và nên gửi tin nhắn vào lúc nào (nửa đêm, really??).

Khi bạn chuyển sang một công việc khác, não bạn vẫn còn đang mải mê suy nghĩ về email kia (không biết mình đã đính kèm file chưa nhỉ, dùng Dear hay Hello thì hợp lý hơn…), nhưng bạn đã bắt nó phải suy nghĩ luôn cách giải quyết công việc mới.

Nguồn ảnh: RescueTime

Cứ thế, bạn làm đến công việc thứ 10, và trong não bạn vẫn còn dư âm từ công việc 1,2,3… Bất cứ một công việc nào được làm sau công việc đầu tiên đều chịu ảnh hưởng của việc não bạn bị phân tán và không hoàn toàn tập trung 100%.

Đọc thêm: Context switching: Why jumping between tasks is killing your productivity (and what you can do about it)

Như vậy, một công việc được coi là “có thể làm trong 2 phút” thực ra sẽ mất thời gian gấp đôi, gấp ba, vì còn tính cả thời gian não chúng ta khởi động và xóa bỏ nó ra khỏi đầu. Và đây chính là điểm mà mình nghĩ David Allen chưa làm rõ (hoặc bỏ qua) khi viết cuốn sách Getting Things Done.

Mình từng ưu tiên làm những việc chỉ mất 2 phút đầu ngày, nhưng mình nhanh chóng nhận ra là thường mình sẽ mất đến gần 1 buổi sáng cho các công việc đó, và đến khi mình xong thì hoặc là đến giờ ăn trưa, hoặc là mình không còn đủ tỉnh táo và tập trung để giải quyết công việc quan trọng nhất trong ngày. Tréo ngoe cái nữa là lúc nào số lượng việc 2 phút cũng nhiều hơn số công việc thực sự quan trọng.

Phần công việc “Later” và “Others” của mình lúc nào cũng nhiều hơn “Urgent” và “Important”. Làm cái này trước thì hết ngày mất =))

Kết quả của việc làm các việc ít quan trọng hơn là mình không có nhiều thời gian (và không gian tinh thần) để làm những công việc thực sự đem lại giá trị cho bản thân và công ty nữa. Đó đáng ra là những công việc nên được làm đầu ngày, lúc mà mình năng suất nhất, và ít bị xao nhãng nhất (vì thường đồng nghiệp của mình hay sắp xếp họp vào buổi chiều).

Kinh nghiệm của mình là gom những công việc 2 phút vào chung một chỗ, và làm những thứ hao hao giống nhau trong cùng một thời điểm (ví dụ: trả lời email và slack) bởi nó sẽ tận dụng được triệt để suy nghĩ của mình. Phương pháp này gọi là Task Batching – mình sẽ giới thiệu ở bài blog sau.

 Tổng kết: Không nên làm nhiều việc nhỏ luôn vì sẽ tốn nhiều thời gian hơn chúng ta tưởng tượng. Nên làm việc lớn trước và dành một khoảng thời gian nhất định trong ngày để làm các việc nhỏ có cùng chủ đề.

Bài học số 2: Viết cho tương lai

GTD khuyến khích mình cứ khi nào có suy nghĩ là mình sẽ ghi nó lại ngay bằng một công cụ nào đó. Chính nhờ sự tiện dụng của các sản phẩm công nghệ bây giờ mà gần như mình có suy nghĩ một cái thì chỉ vài giây sau là mình đã có thể lưu nó lại rồi.

Tuy nhiên, tốc độ lưu trữ quá nhanh đi kèm với việc mình chưa kịp suy nghĩ gì về… điều mình đang suy nghĩ. Vào thời điểm mình ghi cái suy nghĩ trong đầu ra, mình tin rằng “mình trong tương lai” sẽ hiểu được cái mình đang suy nghĩ. Vì thế, mình sẽ dễ phạm phải sai lầm ghi chú ngắn gọn hết sức có thể.

Kết quả là: lần sau đọc lại, mình chẳng hiểu gì.

Ví dụ, mình đang ngồi viết blog và chợt nhớ ra rằng mình cần lên kế hoạch cho event ngày 28/3 dành cho các subscribers của blog mình. Trong event này mình sẽ (làm một cái gì đó mình không nói đâu ahihi), nhưng đại để là mình đã mường tượng được trong đầu.

Khi có ý tưởng này, mình ngay lập tức muốn ghi lại để khỏi quên và tránh xao nhãng công việc hiện tại. Khổ nỗi, mình lại chỉ ghi chú là: “Plan event”

Chỉ ngay ngày hôm sau mình nhìn lại mình đã không còn nhớ “plan event” này là event gì nữa. Vì nó chưa có tag, hay label gì, nên mình cũng không biết đây là công việc ở công ty hay dự án cá nhân. Well, thế là thôi, xóa.

Do thời điểm chúng ta lưu trữ và thời điểm chúng ta xử lý một (danh sách những) công việc thường khác nhau, sẽ rất khó để chúng ta có thể nhớ lại chính xác vì sao mình viết như vậy.

Bài học mình rút ra được là khi viết lại một công việc cần làm cho bản thân, cố gắng viết chi tiết nhất có thể. Nếu được, bạn nên lựa chọn ứng dụng Todo list như Tick Tick hay Things 3 vì nó có phần Task description để bạn mô tả công việc mình muốn làm là gì.

Đôi khi không nhất thiết phải ghi lại đầy đủ như thế này, nhưng càng chi tiết được bao nhiêu thì “mình ở tương lai” sẽ càng dễ nhớ lại công việc này và bắt đầu làm nó bấy nhiêu
Tổng kết: Chúng ta ở tương lai sẽ không ở trong hoàn cảnh và suy nghĩ ở thời điểm hiện tại nên rất khó để hiểu một công việc nếu như nó được ghi chép lại quá sơ sài. Nên ghi chú thật chi tiết để chúng ta có thể dễ dàng làm công việc đó dù nhìn vào nó ở thời điểm nào trong tương lai.

Bài học số 3: Vấn đề không phải là cái gì, mà là khi nào

Mình thấy nhiều người thường cười khi nói đến câu: “Đúng người, sai thời điểm”.

Hai chữ “thời điểm” dường như bị coi nhẹ trong mắt nhiều người, trong khi thực tế thì thời điểm là một nhân tố cực kì quan trọng trong sự thành công của bất cứ thứ gì.

Kể riêng trong kinh doanh thôi, bạn có biết là Microsoft là công ty đầu tiên cho ra đời đồng hồ thông minh vào năm 2004, nhưng sản phẩm này đã thất bại do hạn chế về mặt công nghệ, và chỉ mãi đến năm 2015, khi Apple cho ra mắt chiếc Apple Watch đầu tiên, thì thế giới mới bắt đầu rục rịch đón nhận?

Nguồn ảnh: một bài báo từ Medium

Trở về những năm đầu tiên trong lịch sử loài người, chúng ta cũng chỉ phát minh ra công nghệ khi loài người chuyển dịch từ lối sống săn bắt hái lượm sang định cư và canh tác nông nghiệp (Súng, Vi Trùng và Thép). Chỉ đến thời điểm con người ta có đủ lương thực thì mới bắt đầu suy nghĩ đến cải thiện những mặt khác trong cuộc sống, và cũng chỉ khi con người chúng ta ở yên một chỗ thì việc sáng tạo các sản phẩm công nghệ mới khả thi (bạn thử tưởng tượng một bộ lạc du canh du cư phải mang vác các chế phẩm công nghệ, bên cạnh những thứ thiết yếu nhất trong cuộc sống, từ vùng này sang vùng khác mà xem, ai mà chịu nổi?)

Quay trở lại với GTD, mình nghĩ rằng thời điểm đóng một vai trò quan trọng trong chất lượng và số lượng công việc được hoàn thành.

Mặc dù David Allen có nhắc đến việc phân loại công việc dựa theo hoàn cảnh/thời điểm (context), nhưng những ví dụ mà David đưa ra lúc đó khá đơn giản (Chia công việc thành những nhóm như “Làm ở nhà”, “Làm ở trường”, “Làm ở văn phòng”…) và không còn phù hợp với môi trường công nghệ mà mình đang làm việc.

Do đó, trong thời gian đầu mới bắt đầu với GTD, gần như là hở ra lúc nào thì mình cố gắng làm luôn một cái gì đó. Mình chỉ nghĩ làm sao hoàn thành được nhiều việc nhất có thể mà thôi.

Tuy nhiên một thời gian sau đó mình nhận ra rằng làm như vậy không đem lại được hiệu quả cao nhất, bởi mỗi công việc sẽ có một “thời điểm tối ưu” để làm nó.

Ví dụ, mình có 2 công việc có cùng độ khó và độ quan trọng là “Nghiên cứu sản phẩm đối thủ” và “Thiết kế hệ thống cho tính năng mới”. Với hai công việc này thì không phù hợp để áp dụng phương pháp Eat the Frog hay Eisenhower để lựa chọn cái nào làm trước được.

Trong trường hợp bây giờ là buổi sáng, mình sẽ lựa chọn làm “Nghiên cứu sản phẩm đối thủ trước” vì:

  • Công việc “Thiết kế hệ thống” sẽ cần sự tham gia của các anh engineers công ty mình. Mà buổi sáng thì các anh thường hay đến trễ, và ít năng suất hơn buổi chiều.
  • Trong khi đó “Nghiên cứu sản phẩm đối thủ” là công việc mình có thể làm một mình được, và sau khi làm và đợi anh Product Lead của mình review vào buổi chiều, thì mình có thể tranh thủ làm “Thiết kế hệ thống” luôn.

Dĩ nhiên, nếu bây giờ là buổi chiều, thì mình sẽ làm “Thiết kế hệ thống trước” và “Nghiên cứu sản phẩm đối thủ” vào sáng hôm sau.

Có thể bạn sẽ nghĩ: Khiếp, việc gì phải tính toán phức tạp xem cái gì làm trước cái gì làm sau cho đau đầu ra, cứ cái nào quan trọng nhất thì làm trước thôi.

Mình cũng muốn thế lắm =))
Thế nhưng, trong môi trường startup của mình, nếu không chủ động nắm được lịch trình một ngày, mình sẽ rất dễ bị cuốn theo những công việc, yêu cầu của người khác. Vả lại, vì là làm theo nhóm, nên nhiều khi không phải cứ muốn làm là xong. Lúc nào cũng phải liên tục kiểm tra lịch xem hôm nay team mình có đi đủ không để mà tổ chức họp hay làm các công việc yêu cầu ý kiến của đầy đủ mọi người.

Lời kết

Phải thú thực, khi mình viết đến những dòng cuối này mình mới nhận ra rằng việc sắp xếp và quản lý công việc không chỉ đơn giản là cứ áp dụng đại một phương pháp do ai đó nghĩ ra là xong. Chúng ta cần thời gian để thử nghiệm, đúc rút và tiếp tục thử nghiệm cho đến khi tìm được công thức hoàn hảo cho bản thân mình.

Mình hi vọng rằng với những trải nghiệm và bài học kể trên, mình đã giúp bạn tiết kiệm được đôi chút thời gian trên con đường tìm thấy công thức đó.

Bạn nghĩ sao về những bài học của mình? Để lại comment phía dưới 👇 cho mình biết nhé!


Nếu bạn cảm thấy bài viết hay và hữu ích, đừng quên chia sẻ lên mạng xã hội để giúp cho nhiều bạn trẻ Việt Nam được tiếp cận với những phương pháp tối ưu năng suất nhé!

Còn nếu đây là lần đầu bạn đến với blog của mình, đừng quên subscribe (ở ngay dưới thôi) để nhận được email về những bài blog thế này, kèm theo những phát hiện công nghệ thú vị của mình nhé (ưu tiên subscribers mới được đọc thôi hehe).

6 thoughts on “3 bài học từ Getting Things Done

  1. Gracy says:

    Em cũng đồng ý với phần 3, khi mà lịch trình công việc của ta lúc nào cũng bị phụ thuộc vào những người khác trong team/ công ty thì cách duy nhất để “get things done” là gạt bỏ cảm xúc (vì cảm xúc là thứ khiến em vào mood làm việc tốt hơn) và priotize các tasks cho phù hợp với tính chất.

    Reply
    1. tuanmon says:

      A nghĩ đẹp nhất là kết hợp được cảm xúc và context, mặc dù cái đó không phải lúc nào cũng làm được 😉 ví dụ như là vừa đi xe mà vừa reflect thì đúng là rất phiêu nhưng mà hơi nguy hiểm à nha =)

      Reply
  2. Ms Nhi says:

    Những chia sẻ của anh rất bổ ích cho mình. Mình cũng vẫn đang loay hoay để lên Quy trình làm việc năng suất hơn & những chia sẻ của anh có giá trị với mình. Cảm ơn anh nhiều nhé ^^

    Reply
    1. tuanmon says:

      Cảm ơn bạn nhé! Không biết bạn gặp vấn đề ở đâu trong quá trình đó nhỉ?

      Reply
  3. Nhan says:

    Ủa rồi cuối cùng ngày 28/3 có event gì hong hay bị xóa rồi 😀

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll UpScroll Up