Bỏ qua

Personal OKR — đặt mục tiêu cho việc học như đặt OKR cho công việc

Bạn đã có thời gian (buổi sáng được bảo vệ), có phương pháp (học nhanh, nhớ lâu), có sandbox để thực hành. Nhưng cuối quý nhìn lại — bạn đã "học" nhiều thứ mà không build được gì cụ thể. Kiến thức rời rạc, không đo được tiến độ, không biết mình đang ở đâu trên lộ trình.

Vấn đề không phải thiếu thời gian hay thiếu phương pháp. Vấn đề là thiếu mục tiêu rõ ràng và hệ thống accountability. Không ai tạo OKR học tập cho bạn. Và nếu bạn không tự làm, việc học sẽ mãi ở chế độ "noodling" — làm gì cũng được, không làm cũng không sao.

Bài viết này là phần thứ ba trong bộ ba: Học nhanh. Nhớ lâu. cho phương pháp, Sắp xếp thời gian cho thời gian, và bài này cho mục tiêu + kỷ luật.

1. "Học X" không phải mục tiêu

Hầu hết mọi người đặt mục tiêu học kiểu này:

  • "Quý này học Kubernetes"
  • "Tháng này đọc xong cuốn sách Y"
  • "Tuần này tìm hiểu về streaming"

Vấn đề: không có cách nào biết bạn đã "học xong" hay chưa. Đọc xong cuốn sách ≠ hiểu. Xem xong 20 video ≠ làm được. Và khi không có đích rõ ràng, bạn sẽ nhảy từ chủ đề này sang chủ đề khác mỗi khi gặp thứ mới hấp dẫn hơn.

"Build được Y bằng X" mới là mục tiêu. Bạn chỉ thực sự hiểu một thứ khi bạn dùng nó để tạo ra thứ gì đó — một hệ thống chạy được, một bài viết giải thích được, một quyết định thiết kế có lý do.

2. Cấu trúc Personal OKR

Mượn framework OKR của công ty, nhưng áp dụng cho việc học cá nhân:

Objective = Bạn muốn đạt được năng lực gì? (Định tính, truyền cảm hứng)

Key Results = Làm sao biết bạn đã đạt? (Định lượng, đo được, có deadline)

Ví dụ cho một Data Engineer:

Objective: Nắm vững container orchestration đủ để vận hành production workload

  • KR1: Dựng homelab cluster chạy 3+ services, có monitoring (cuối tháng 1)
  • KR2: Viết 1 blog post giải thích networking model từ trí nhớ (cuối tháng 2)
  • KR3: Tự troubleshoot ít nhất 2 production issues liên quan mà không cần hỏi ai (cuối quý)

Objective: Nâng kỹ năng lập trình từ "viết được" lên "viết tốt"

  • KR1: Hoàn thành 1 CLI tool hoặc automation project có test coverage > 80% (cuối tháng 2)
  • KR2: Refactor 1 pipeline cũ của team theo design patterns đã học (cuối quý)
  • KR3: Viết 1 bài phân tích trade-off giữa 2 cách tiếp cận mình đã thử (cuối quý)

Nguyên tắc đặt Personal OKR:

  • 1-2 objectives mỗi quý — nhiều hơn = phân tán. Bạn chỉ có ~17.5h/tuần cho Invest.
  • 2-3 key results mỗi objective — đủ cụ thể để đo, không quá nhiều để áp lực.
  • Ít nhất 1 KR là "build" — tạo ra artifact cụ thể: code chạy được, blog post, system diagram.
  • Ít nhất 1 KR là "giải thích" — viết hoặc dạy lại (Feynman Technique). Nếu không giải thích được, bạn chưa hiểu.
  • Deadline theo tháng, không theo tuần — đủ dài để sâu, đủ ngắn để không trôi.

3. Từ OKR quý → lịch tuần

OKR quý chỉ có ý nghĩa khi nó hiện diện trong lịch tuần. Cách breakdown:

Quý → Tháng → Tuần

OKR Quý (3 tháng)
  └── Milestone tháng 1: nghiên cứu + setup cơ bản
  └── Milestone tháng 2: build + thực hành sâu
  └── Milestone tháng 3: hoàn thiện + tổng hợp + viết

Gắn vào block buổi sáng

Mỗi tuần, trong 5 phút cuối review thứ 6, tự hỏi:

  • Milestone tháng này là gì?
  • Tuần tới Block 1 nên tập trung vào đâu?
  • Block 2 nên thực hành/build gì?

Ví dụ cho tuần thứ 3 của tháng 2:

Block 1 (Học) Block 2 (Làm)
T2 Đọc docs về feature X Code thử trên sandbox
T3 Debug lỗi gặp hôm qua, đọc sâu hơn Tiếp tục build, thử edge cases
T4 Đọc source code liên quan Refactor lại code cho clean
T5 So sánh approach của mình vs best practices Viết ghi chú tổng hợp
T6 Viết blog draft Review tuần + plan tuần sau

Block 1 và Block 2 không còn "học chung chung" — chúng phục vụ một KR cụ thể trong personal OKR.

4. Công ty = môi trường thực hành lớn nhất

Sandbox cá nhân là nơi bạn được phép sai. Nhưng công ty là nơi bạn học những thứ sandbox không tái tạo được:

  • Quy mô thật — hệ thống phục vụ hàng triệu request, không phải 3 container trên laptop
  • Sự cố thật — production issue lúc 3h sáng dạy bạn nhiều hơn 100 giờ đọc docs
  • Con người thật — phối hợp với team, negotiate technical decisions, communicate trade-offs
  • Hậu quả thật — quyết định của bạn ảnh hưởng đến người dùng, đến business

Cách tận dụng:

  • Mỗi production issue bạn debug → ghi lại: root cause là gì, mình thiếu kiến thức gì, cần học thêm gì
  • Mỗi system design bạn tham gia → vẽ lại kiến trúc từ trí nhớ sau 1 tuần (active recall)
  • Mỗi code review bạn nhận → đọc kỹ feedback, pattern nào lặp lại → đó là gap cần lấp

Đôi khi personal OKR trùng với OKR team — lúc đó bạn được "trả lương để học". Đôi khi không trùng — và đó chính là lý do buổi sáng tồn tại.

5. Accountability loop

Có OKR mà không review = không có OKR. Bạn cần một vòng lặp:

Hàng ngày (5 phút — cuối Block 2)

Ghi chú nhanh: hôm nay học/build được gì, mai tiếp ở đâu. Đây là seed cho ngày hôm sau — bạn không mất 15 phút "nhớ lại mình đang làm gì".

Hàng tuần (15 phút — thứ 6)

  • Tuần này tiến được bao nhiêu so với milestone tháng?
  • Buổi sáng có được bảo vệ không?
  • Có output cụ thể không? (code, blog draft, diagram)
  • Tuần sau Block 1/Block 2 tập trung vào gì?

Hàng tháng (30 phút)

  • Milestone tháng này đạt chưa?
  • Nếu chưa: do thiếu thời gian, thiếu kiến thức, hay scope quá lớn?
  • Tháng sau cần điều chỉnh gì?

Hàng quý (1 giờ)

  • KR nào đạt, KR nào không?
  • Objective có còn đúng hướng không, hay đã thay đổi?
  • Đặt OKR quý tiếp theo

6. Learn in public — accountability tốt nhất

Viết blog không chỉ là "chia sẻ kiến thức". Nó là hệ thống accountability mạnh nhất bạn có:

  • Deadline công khai — khi bạn nói "mỗi tháng 1 bài", người đọc (dù ít) tạo áp lực nhẹ đủ để bạn không trì hoãn.
  • Feynman Technique tự nhiên — viết cho người khác hiểu buộc bạn phải hiểu sâu hơn. Chỗ nào viết không ra = chỗ đó bạn chưa hiểu.
  • Đo được tiến độ — mỗi bài viết là một artifact. Cuối quý đếm lại: bao nhiêu bài, về chủ đề gì, sâu đến đâu.
  • Tạo danh tính — viết đều đặn → người khác biết bạn đang học gì → cơ hội networking, mentoring, thậm chí career.

Không cần blog hoàn hảo. Ghi chú thô trên GitHub cũng được. Điều quan trọng là output công khai, đều đặn.

7. Khi personal OKR thất bại

Cuối quý, bạn sẽ có KR không đạt. Đó là bình thường — không phải thất bại.

Đừng tự phạt. Hãy retrospective.

Hỏi:

  • Scope có quá lớn không? Nếu KR là "dựng toàn bộ data platform trên homelab" trong 3 tháng → scope sai, không phải bạn sai.
  • Ưu tiên có đúng không? Nếu bạn dành 3 tháng học thứ không dùng được → objective cần đổi.
  • Thời gian có được bảo vệ không? Nếu buổi sáng liên tục bị xâm phạm → vấn đề nằm ở hệ thống thời gian, không phải OKR.
  • Có output nào không? Dù không đạt KR, bạn có thể đã học được nhiều — chỉ là chưa đo đúng.

Điều chỉnh OKR quý sau cho thực tế hơn. Lặp lại. Mỗi quý bạn sẽ đặt OKR tốt hơn — vì bạn hiểu bản thân hơn.

8. Kết luận

Ba bài viết trong series này tạo thành một hệ thống:

Phương pháp mà không có thời gian = lý thuyết. Thời gian mà không có mục tiêu = noodling. Mục tiêu mà không có accountability = ước mơ.

Đặt 1-2 objective mỗi quý. Breakdown thành milestone tháng. Gắn vào block buổi sáng. Review hàng tuần. Viết ra để đo. Và khi trượt — retrospective, không tự phạt.