Mở đầu — vì sao bài này quan trọng
Khi bạn còn làm Finance hay Kế toán, công việc của bạn có một nhịp điệu khá rõ ràng. Đầu tháng đóng sổ, giữa tháng làm báo cáo quản trị, cuối quý quyết toán thuế. Deadline cố định, đầu việc lặp lại, và quan trọng nhất: phần lớn thời gian bạn ngồi một mình với Excel và con số. Bạn được "yên" để tập trung.
BA thì khác hẳn. Một ngày làm việc của Business Analyst điển hình là một chuỗi gián đoạn liên tục: dev nhắn hỏi business rule, PO kéo bạn vào họp refinement, stakeholder bên nghiệp vụ gọi điện than phiền requirement chưa rõ, QC ping bạn xác nhận một edge case trong UAT. Có một con số đáng giật mình mà nhiều BA mới chuyển ngành nhận ra muộn: nếu không chủ động quản lý, 40–60% thời gian trong tuần của một BA sẽ tan vào các cuộc họp và tin nhắn. Phần còn lại bị xé vụn thành những mảnh 15–20 phút — không đủ để viết nổi một trang SRS tử tế.
Vấn đề nằm ở bản chất công việc. Sản phẩm cốt lõi của BA là tài liệu tư duy: PRD, use case, business rule catalog, process flow. Những thứ này không thể viết được trong trạng thái bị gián đoạn. Nghiên cứu của Cal Newport (tác giả "Deep Work") chỉ ra rằng các sản phẩm trí tuệ chất lượng cao đòi hỏi những khối thời gian tập trung không gián đoạn ít nhất 90 phút, lý tưởng là 2–4 tiếng. Một BA viết SRS trong lúc cứ 10 phút lại trả lời một tin nhắn Slack sẽ tạo ra tài liệu đầy lỗ hổng logic, mà chính họ cũng không nhận ra.
Tin tốt là: tư duy quản lý nguồn lực của người làm Finance lại cực kỳ phù hợp để giải bài toán này. Bạn vốn quen với việc phân bổ nguồn lực khan hiếm (ngân sách, dòng tiền) vào nơi tạo ra giá trị cao nhất. Thời gian chỉ là một loại "ngân sách" khác. Bài này dạy bạn cách áp dụng đúng tư duy đó để bảo vệ khả năng tạo ra giá trị cốt lõi của mình.
Khái niệm cốt lõi
Deep work vs. Shallow work
Cal Newport chia mọi công việc thành hai loại. Deep work (làm việc sâu) là những hoạt động nhận thức đòi hỏi tập trung cao độ, đẩy năng lực của bạn đến giới hạn, và tạo ra giá trị khó sao chép. Với BA, đó là: viết SRS, thiết kế process flow phức tạp, phân tích trade-off giữa các giải pháp, mô hình hóa data (ERD), viết business rule cho một nghiệp vụ rối rắm.
Shallow work (làm việc nông) là những việc mang tính hậu cần, ít đòi hỏi trí tuệ, thường làm được trong lúc bị phân tâm: trả lời email xác nhận, cập nhật trạng thái ticket Jira, đặt lịch họp, trả lời câu hỏi nhanh của dev. Shallow work cần thiết nhưng không tạo ra lợi thế cạnh tranh cho bạn.
Sai lầm chí mạng của BA mới: để shallow work lấp đầy giờ vàng (sáng sớm, đầu giờ chiều — lúc não minh mẫn nhất), rồi cố nhồi deep work vào lúc 5h chiều khi đã kiệt sức. Kết quả là tài liệu chất lượng kém và phải làm thêm giờ.
Ma trận Eisenhower — phân loại theo Khẩn cấp × Quan trọng
Đây là công cụ nền tảng. Mọi đầu việc được xếp vào một trong bốn ô, dựa trên hai trục: việc có khẩn cấp (urgent — cần xử lý ngay) hay không, và có quan trọng (important — đóng góp vào mục tiêu lớn) hay không.
| Khẩn cấp | Không khẩn cấp | |
|---|---|---|
| Quan trọng | Ô 1 — Làm ngay: Bug production chặn release, requirement gap khiến dev đang block, chuẩn bị cho buổi UAT chiều nay | Ô 2 — Lên lịch (deep work): Viết SRS cho epic tháng sau, thiết kế lại process flow, học domain mới, xây business rule catalog |
| Không quan trọng | Ô 3 — Ủy thác / xử lý nhanh: Trả lời câu hỏi mà người khác có thể tự tìm trong Confluence, họp mà bạn chỉ ngồi nghe, cập nhật status | Ô 4 — Loại bỏ: Lướt Slack vô định, họp không có agenda, làm đẹp tài liệu quá mức cần thiết |
Time blocking — "đóng sổ" cho lịch làm việc
Time blocking là kỹ thuật chia ngày làm việc thành các khối thời gian, mỗi khối được gán trước cho một loại công việc cụ thể. Thay vì có một to-do list trôi nổi, bạn đặt từng việc vào một ô giờ trên lịch.
Người làm Finance sẽ thấy điều này quen thuộc đến bất ngờ: nó giống hệt cách bạn lập kế hoạch dòng tiền (cash flow planning) hay phân bổ ngân sách. Bạn không để tiền "tự trôi", bạn gán mỗi đồng vào một mục đích. Time blocking làm điều tương tự với 8 tiếng làm việc.
Quy luật giảm thiểu context switching
Mỗi lần não chuyển từ việc này sang việc khác, có một chi phí gọi là attention residue — phần chú ý còn "dính" lại ở việc cũ. Một nghiên cứu kinh điển cho thấy sau mỗi lần gián đoạn, trung bình cần 23 phút để quay lại trạng thái tập trung sâu ban đầu. Với BA, mỗi tin nhắn "Anh ơi business rule này thế nào?" giữa lúc đang viết use case không chỉ tốn 2 phút trả lời — nó tốn thêm 23 phút phục hồi. Đây là lý do batching (gom việc cùng loại) lại quan trọng đến vậy.
Tình huống thực tế
Tình huống 1 — Linh tại một fintech ở TP.HCM: tuần đầu vỡ trận
Linh từng là kế toán tổng hợp 5 năm, mới chuyển sang làm BA cho một ví điện tử tại TP.HCM. Tuần thứ ba đi làm, cô được giao viết SRS cho tính năng "chia hóa đơn nhóm" (split bill), deadline 5 ngày. Linh nghĩ đơn giản: cứ ngồi viết là xong, như hồi làm báo cáo.
Thực tế: thứ Hai cô vào làm lúc 9h, nhưng đến 11h mới mở được file SRS vì liên tục bị kéo vào standup, một cuộc gọi của QC, và ba lượt hỏi đáp trên Slack. Buổi chiều có hai cuộc họp refinement. Đến hết thứ Tư, SRS của Linh mới được... 2 trang, và phần business rule rối tung vì cô viết mỗi lần được 15 phút lại bị ngắt, mất mạch logic. Cô phải thức đến 1h sáng thứ Năm để hoàn thành, và bản nháp đầu bị PO trả lại vì thiếu mất 3 luồng exception.
Bài học: Linh đã để Ô 1 và Ô 3 nuốt trọn giờ vàng, đẩy deep work (Ô 2) vào ban đêm khi não đã cạn. Sai lầm không phải ở năng lực viết SRS — mà ở việc không bảo vệ khối thời gian tập trung. Sau sự cố này, Linh đặt cố định khối 9h–11h sáng mỗi ngày là "deep work, không họp, không Slack", và năng suất viết tài liệu của cô tăng gấp đôi chỉ trong hai tuần.
Tình huống 2 — Đức ở một công ty ERP: chiến lược "batching" tin nhắn
Đức, ex-Finance làm BA cho một nhà triển khai ERP tại Hà Nội, phụ trách module kế toán cho ba khách hàng cùng lúc. Anh nhận thấy mình bị "chết" vì context switching: ba nhóm dev của ba dự án nhắn tin liên tục, mỗi câu hỏi kéo anh ra khỏi luồng đang làm.
Đức áp dụng một nguyên tắc đơn giản học từ chính thói quen "đóng sổ theo chu kỳ" hồi làm kế toán: anh không trả lời tin nhắn ngay lập tức, mà gom lại xử lý trong ba khung giờ cố định — 8h30, 13h30 và 16h30, mỗi khung 30 phút. Anh thông báo rõ với các nhóm: "Câu hỏi không khẩn cấp gửi vào channel, mình trả lời theo ba khung này. Việc thật sự chặn release thì gọi điện trực tiếp." Ban đầu vài dev khó chịu, nhưng sau hai tuần họ nhận ra: câu trả lời của Đức kỹ hơn hẳn (vì anh có thời gian tra cứu thay vì trả lời vội), và số lần phải hỏi lại giảm hẳn.
Bài học: Không phải mọi câu hỏi đều khẩn cấp. Bằng cách batching giao tiếp và đặt kỳ vọng rõ ràng với team, Đức biến hàng chục lần gián đoạn mỗi ngày thành ba phiên xử lý gọn gàng, giải phóng được hai khối deep work liền mạch buổi sáng.
Tình huống 3 — Hằng và cái bẫy "luôn online"
Hằng chuyển từ kiểm toán sang BA tại một startup logistics ở Singapore. Vốn quen áp lực phải phản hồi khách hàng kiểm toán trong vài phút, cô mang luôn thói quen đó sang: để thông báo Slack, email, Telegram bật hết, và tự hào vì "luôn sẵn sàng". Sau hai tháng, cô kiệt sức và nhận ra mình chưa hoàn thành nổi tài liệu phân tích cho dự án tích hợp API mà sếp giao từ đầu tháng — dù ngày nào cũng làm 10 tiếng.
Manager của Hằng chỉ ra vấn đề: cô đang tối ưu cho tính phản hồi (responsiveness) thay vì giá trị tạo ra (output). Một BA được đánh giá qua chất lượng requirement và quyết định mình đưa ra, không phải qua tốc độ trả lời tin nhắn. Hằng tắt toàn bộ thông báo trong hai khối deep work mỗi ngày, đặt status "Đang viết tài liệu — phản hồi sau 11h", và lần đầu tiên hoàn thành tài liệu API integration đúng hạn với chất lượng được dev khen "rõ đến mức không cần hỏi lại câu nào".
Bài học: "Luôn online" là một dạng shallow work trá hình. Sự bận rộn không bằng năng suất. Bảo vệ deep work đôi khi đồng nghĩa với việc chấp nhận trả lời chậm hơn một chút để tài liệu chất lượng hơn nhiều.
Hướng dẫn từng bước
Đây là quy trình thiết lập hệ thống quản lý thời gian cho một tuần làm việc của BA. Hãy coi nó như một "ngân sách thời gian" mà bạn lập đầu tuần.
Bước 1 — Audit thời gian một tuần (làm một lần để biết hiện trạng). Trước khi tối ưu, hãy đo. Trong 5 ngày, cứ mỗi giờ ghi nhanh bạn vừa làm gì và thuộc ô Eisenhower nào. Cuối tuần, cộng lại tỷ lệ thời gian cho deep work, họp, và shallow work. Đa số BA mới giật mình khi thấy deep work thực tế chỉ chiếm 10–15%. Bạn không thể quản lý thứ bạn không đo — đúng tinh thần kế toán.
Bước 2 — Xác định 2–3 đầu việc Ô 2 quan trọng nhất tuần. Đầu mỗi tuần (sáng thứ Hai hoặc chiều thứ Sáu tuần trước), liệt kê những deliverable deep work then chốt: ví dụ "viết xong SRS module thanh toán", "thiết kế process flow cho luồng hoàn tiền". Đây là những thứ quyết định bạn có được đánh giá là BA giỏi hay không.
Bước 3 — Đặt khối deep work vào lịch TRƯỚC. Trên Google Calendar, đặt cố định 1–2 khối 90–120 phút mỗi ngày cho deep work, ưu tiên giờ vàng buổi sáng. Đặt tên rõ ràng như "[Focus] Viết SRS — không họp". Quan trọng: đặt chúng vào lịch trước khi người khác kịp đặt họp vào giờ đó. Đây là bước người Finance làm rất tự nhiên — bạn luôn "khóa" nguồn lực cho ưu tiên cao nhất trước.
Bước 4 — Gom shallow work thành các batch. Chỉ định 2–3 khung cố định trong ngày để xử lý email, Slack, cập nhật Jira (ví dụ: 11h, 14h, 16h30). Ngoài các khung này, tắt thông báo.
Bước 5 — Bảo vệ khối deep work bằng quy ước với team. Báo trước cho dev/PO về khung giờ focus của bạn và kênh dành cho việc thật sự khẩn. Đặt status chat phù hợp. Điều này biến việc bảo vệ thời gian thành một thỏa thuận chứ không phải hành vi "khó gần".
Bước 6 — Rà soát cuối ngày (5 phút "đóng sổ"). Cuối ngày, đối chiếu kế hoạch với thực tế, dời việc chưa xong sang ngày mai, và lên 3 ưu tiên cho ngày hôm sau. Nghi thức này giống việc đối chiếu số dư cuối ngày — nó giúp bạn "tắt" công việc và phục hồi cho deep work hôm sau.
Lỗi thường gặp & mẹo
Lỗi 1 — Lập kế hoạch quá kín, không chừa đệm. Người Finance giỏi lập kế hoạch nên dễ rơi vào bẫy xếp lịch kín 100%. Ngày làm việc của BA luôn có biến cố (Ô 1 phát sinh). Mẹo: chỉ block khoảng 60% thời gian, chừa 40% làm "vùng đệm" cho việc khẩn và việc tràn.
Lỗi 2 — Đặt deep work vào lúc não đã cạn. Đừng để giờ tập trung quý giá rơi vào cuối ngày. Mẹo: nhận diện "giờ vàng" sinh học của riêng bạn (đa số là 8h–11h) và bảo vệ nó bằng mọi giá cho việc Ô 2.
Lỗi 3 — Nhầm "bận" với "hiệu quả". Trả lời 100 tin nhắn không bằng viết xong một SRS không lỗi. Mẹo: cuối tuần tự hỏi "Tôi đã tạo ra deliverable nào?", không phải "Tôi đã trả lời bao nhiêu tin?".
Lỗi 4 — Tham gia mọi cuộc họp. Không phải họp nào BA cũng cần dự trọn. Mẹo: nếu được mời họp không agenda hoặc bạn chỉ ngồi nghe, hỏi thẳng "Em cần đóng góp phần nào ạ?" và xin đọc biên bản nếu không cần thiết. Đây là việc thuộc Ô 3 — ủy thác hoặc cắt.
Lỗi 5 — Không có nghi thức "khởi động" deep work. Ngồi vào bàn rồi mới loay hoay tìm việc làm sẽ phí 15 phút đầu. Mẹo: trước khi đóng máy hôm trước, viết sẵn câu đầu tiên cần làm cho khối deep work sáng mai. Bắt đầu luôn dễ hơn khởi động từ trang trắng.
Mẹo bổ sung — Kỹ thuật Pomodoro cho ngày khó tập trung. Vào những hôm não khó vào guồng, chia deep work thành các phiên 25 phút tập trung + 5 phút nghỉ. Nó tạo "đà" và giảm cảm giác choáng ngợp khi nhìn một SRS dài 20 trang.
Bài tập thực hành
- Audit một tuần: Trong 5 ngày tới, mỗi giờ ghi lại bạn làm gì và phân vào ô Eisenhower nào. Cuối tuần tính tỷ lệ % thời gian cho deep work, họp, shallow work. Viết một đoạn 3–4 câu nhận xét về hiện trạng của bạn.
- Phân loại Eisenhower: Lấy 10 đầu việc gần nhất bạn đã làm (hoặc đầu việc điển hình của một BA), xếp mỗi việc vào một trong 4 ô. Đánh dấu những việc Ô 3, Ô 4 mà lẽ ra có thể ủy thác hoặc loại bỏ.
- Thiết kế lịch mẫu: Vẽ thời khóa biểu một ngày làm việc lý tưởng của bạn, có ít nhất 2 khối deep work (90 phút trở lên) vào giờ vàng, 2–3 khung batch xử lý tin nhắn, và 40% vùng đệm. Ghi rõ status chat bạn sẽ đặt trong mỗi khối focus.
- Soạn thông điệp đặt kỳ vọng: Viết một tin nhắn ngắn (3–4 câu) gửi cho team dev/PO, thông báo lịch deep work của bạn, kênh dành cho việc khẩn, và cam kết thời gian phản hồi tin nhắn thường. Mục tiêu: lịch sự, rõ ràng, không gây cảm giác "khó gần".
Tóm tắt
Công việc BA bị xé vụn bởi họp và tin nhắn, trong khi sản phẩm cốt lõi của bạn — SRS, process flow, business rule — lại chỉ ra đời được trong những khối deep work 2–4 tiếng không gián đoạn. May mắn là tư duy phân bổ nguồn lực của người Finance hoàn toàn áp dụng được vào việc quản lý thời gian.
Ba trụ cột cần nhớ: Ma trận Eisenhower giúp bạn phân biệt việc quan trọng (Ô 2 — deep work) với việc chỉ khẩn cấp hoặc gây nhiễu; Time blocking giúp bạn "lập ngân sách" thời gian, khóa giờ vàng cho deep work trước khi bị họp chiếm; và batching + giảm context switching giúp bạn gom shallow work, tránh trả giá 23 phút phục hồi cho mỗi lần gián đoạn.
Đừng đánh đồng bận rộn với hiệu quả. Như Linh, Đức và Hằng đã học được, một BA được đánh giá qua chất lượng quyết định và tài liệu mình tạo ra, không qua tốc độ trả lời Slack. Hãy bảo vệ deep work như bảo vệ dòng tiền của doanh nghiệp — đó là khoản đầu tư quyết định bạn sẽ là một BA tầm thường hay xuất sắc.