Làm Cùng Long.
← Quay lại Kho ghi chú
Automation & AI · 8 phút đọc ·

Quản lý công việc bằng công nghệ: đừng chọn tool trước khi thiết kế hệ thống

Một team có thể dùng Notion rất đẹp mà vẫn không biết việc nào đang trễ.

Một bảng Trello có thể có 200 card nhưng không ai biết card nào là ưu tiên thật.

Một Google Sheet có thể cập nhật mỗi ngày nhưng số liệu ở ba tab không khớp nhau.

Và AI có thể làm mọi thứ tệ hơn bằng cách tự động hóa tốc độ tạo task, nhắc việc và báo cáo, trong khi vấn đề gốc chưa bao giờ được giải quyết.

Đó là lý do tôi không bắt đầu bài toán quản lý công việc bằng câu hỏi:

“Nên dùng Notion, Asana, ClickUp hay Trello?”

Tôi bắt đầu bằng:

Một công việc đi từ lúc xuất hiện đến lúc hoàn tất qua những trạng thái nào, ai chịu trách nhiệm và đâu là nguồn sự thật?

1. Tool chỉ là giao diện của một operating system

Một hệ thống quản lý công việc tối thiểu cần trả lời được sáu câu:

  1. Việc mới đi vào hệ thống ở đâu?
  2. Một task có những trạng thái nào?
  3. Ai là owner duy nhất ở mỗi thời điểm?
  4. Cái gì quyết định ưu tiên?
  5. Khi nào task được coi là hoàn tất?
  6. Team review hệ thống theo nhịp nào?

Nếu sáu câu này chưa rõ, đổi tool thường chỉ di chuyển sự hỗn loạn sang một giao diện mới.

2. Bước đầu tiên: chọn một source of truth

Một anti-pattern quen thuộc:

Task từ chat
 + Task từ email
 + Task trong Sheet
 + Task trong Notion
 + Task nhớ trong đầu
 = Không ai biết danh sách thật nằm ở đâu

Không nhất thiết mọi thứ phải sống trong một app. Nhưng phải có rule:

Task nào được coi là “đang tồn tại chính thức” khi nó nằm ở đâu?

Ví dụ:

  • chat/email là inbox;
  • task manager là source of truth cho action;
  • Drive là source of truth cho tài liệu;
  • dashboard là source of truth cho metric;
  • calendar là source of truth cho time-bound meeting/event.

Mỗi loại thông tin có một home rõ ràng.

3. Status phải mô tả trạng thái của công việc, không mô tả cảm xúc

Các status kiểu:

  • Đang làm;
  • Đang xử lý;
  • Pending;
  • Có vấn đề;
  • Cần xem;

thường quá mơ hồ.

Tôi ưu tiên state machine đơn giản:

Inbox
  ↓
Ready
  ↓
In progress
  ↓
Waiting / Blocked
  ↓
Review
  ↓
Done

Mỗi trạng thái cần có ý nghĩa vận hành.

Ready

Đủ thông tin để bắt đầu.

In progress

Có owner đang thực sự làm.

Waiting / Blocked

Không thể tiến tiếp vì phụ thuộc bên ngoài hoặc blocker rõ.

Review

Output đã có, đang chờ kiểm tra/duyệt.

Done

Đáp ứng Definition of Done, không chỉ “đã làm gần xong”.

Khi state rõ, automation mới có trigger đáng tin.

4. Một task chỉ nên có một owner chịu trách nhiệm chính

“Team Marketing” không phải owner.

“Long + A + B” cũng rất dễ trở thành không ai chịu trách nhiệm cuối.

Task có thể có nhiều collaborator, nhưng nên có một accountable owner.

Ví dụ:

Task: QA tracking form submit
Owner: Long
Collaborator: Dev
Reviewer: Marketing Lead
Due: 19/08
Definition of Done:
- submit thành công
- GA4 DebugView nhận event
- lead vào Sheet/CRM
- không gửi PII vào analytics

Khi owner và Done rõ, status ít phụ thuộc vào giải thích miệng.

5. Priority không nên chỉ là High / Medium / Low

Nếu mọi task “High”, hệ thống không còn khả năng ưu tiên.

Một rule đơn giản hơn:

P0 — Chặn vận hành / rủi ro nghiêm trọng

Ví dụ production form không nhận lead.

P1 — Ảnh hưởng mục tiêu gần

Ví dụ campaign sắp launch nhưng landing chưa QA.

P2 — Cải thiện có giá trị

Ví dụ refactor dashboard, thêm automation tiết kiệm thao tác.

Backlog

Có thể làm, chưa có lý do làm ngay.

Có thể kết hợp với cost/impact, nhưng đừng biến priority thành một công thức 12 biến nếu team chưa dùng nổi bốn mức.

6. Definition of Done là nơi nhiều hệ thống thất bại

Một task “setup GA4” chưa có nghĩa rõ.

Done có thể là:

  • property tồn tại;
  • web stream đúng;
  • event map được triển khai;
  • DebugView test;
  • form submit chỉ bắn khi gửi thành công;
  • không có PII;
  • owner biết xem report ở đâu.

Một task “viết bài” cũng vậy.

Done có thể gồm:

  • Root Idea;
  • nguồn;
  • draft;
  • fact check;
  • SEO/meta;
  • cover/alt;
  • internal links;
  • validation/build;
  • publish URL.

Definition of Done biến output kỳ vọng thành checklist có thể kiểm tra.

7. Cadence quan trọng hơn notification

Tool rất giỏi gửi notification.

Nhưng notification không tạo ra quyết định.

Team cần nhịp review.

Hàng ngày

  • blocker;
  • việc đến hạn;
  • task cần handoff.

Hàng tuần

  • P1/P2;
  • task quá lâu ở một trạng thái;
  • workload theo owner;
  • quyết định bỏ/hoãn;
  • learning.

Hàng tháng

  • workflow nào tạo nhiều task vô nghĩa;
  • automation nào lỗi nhiều;
  • metric nào không dùng;
  • technical/process debt.

Một hệ thống ít notification nhưng review đều thường tốt hơn một hệ thống alert liên tục nhưng không có cadence.

8. Chỉ tự động hóa sau khi state và rule ổn định

Automation phù hợp với những rule rõ:

Task → Review
   ↓
Notify reviewer

hoặc:

Due date < today
AND status != Done
   ↓
Add overdue flag

hoặc:

Form submit thành công
   ↓
Create lead
   ↓
Assign owner theo rule
   ↓
Log source/UTM

Không nên tự động hóa những quyết định chưa rõ như:

“AI tự xác định task nào quan trọng nhất cho team.”

AI có thể đề xuất; owner vẫn cần rule và quyền quyết định.

9. AI nên làm gì trong work management?

AI có giá trị ở phần mơ hồ nhưng có thể review.

Tóm tắt

  • meeting → action items;
  • thread dài → quyết định;
  • weekly log → blockers.

Phân loại

  • tag task;
  • đề xuất project/area;
  • gợi ý duplicate.

Draft

  • status update;
  • handoff note;
  • checklist QA.

Chẩn đoán

  • task nào nằm Blocked quá lâu;
  • owner nào có quá nhiều WIP;
  • loại việc nào lặp lại đủ để automation.

Nhưng AI không nên tự:

  • đóng task có tác động lớn;
  • đổi deadline mà không có owner;
  • gửi email khách hàng;
  • thay đổi production;
  • xóa dữ liệu;
  • tự coi summary của nó là source of truth.

10. WIP limit: làm ít thứ cùng lúc để hoàn thành nhiều hơn

Một hệ thống có 15 task In progress cho một người thường không có 15 task đang được làm.

Nó có 15 task đang mở context.

Có thể đặt rule đơn giản:

  • mỗi người tối đa 2–3 task thực sự In progress;
  • task còn lại ở Ready;
  • chỉ kéo task mới khi một task đã Review/Done hoặc Blocked thật.

WIP limit không cần Kanban formal để hữu ích.

Nó chỉ bảo vệ attention.

11. Task age là một metric mạnh nhưng ít được nhìn

Ngoài số task Done, hãy nhìn:

  • task đã ở In progress bao lâu;
  • Waiting bao lâu;
  • Review bao lâu;
  • bao nhiêu task bị reopen;
  • bao nhiêu task bị tạo rồi không bao giờ làm.

Một task 30 ngày ở In progress có thể là:

  • scope quá lớn;
  • owner không rõ;
  • phụ thuộc bị giấu;
  • priority giả;
  • Definition of Done mơ hồ.

Task age giúp tìm bottleneck hơn là đếm “team có 120 task”.

12. Một schema tối thiểu

Cho đa số team nhỏ:

Task ID
Title
Project / Area
Status
Priority
Owner
Due date
Created date
Updated date
Blocker / dependency
Definition of Done
Source / link

Chỉ thêm field nếu field đó phục vụ một quyết định.

Không thêm 20 thuộc tính vì tool cho phép.

13. Ví dụ: từ chat hỗn loạn tới workflow có source of truth

Giả sử yêu cầu đến qua Google Chat:

“Tuần sau cần report performance Saga, nhớ check tracking form và cập nhật creative.”

Không để nguyên message làm task.

Chuyển thành:

Task 1: Report Saga tuần
Owner: Long
Due: Friday
Done: report + actions + source data linked

Task 2: QA form tracking
Owner: Long
Reviewer: Dev nếu có lỗi code
Done: submit → lead + analytics QA

Task 3: Review Saga creative
Owner: Media/Marketing
Done: asset list + decision + next test

AI có thể hỗ trợ tách task. Nhưng người chịu trách nhiệm xác nhận scope.

14. Cách chọn tool sau khi workflow rõ

Google Sheets

Tốt khi:

  • dữ liệu dạng bảng;
  • team quen Sheets;
  • cần formula/report nhanh;
  • workflow chưa phức tạp.

Notion

Tốt khi:

  • task cần gắn với docs/knowledge;
  • team muốn database view linh hoạt;
  • collaboration thiên về documentation.

Trello / Kanban tool

Tốt khi:

  • workflow theo trạng thái trực quan;
  • ít field;
  • team cần adoption nhanh.

Asana / ClickUp / Jira

Tốt khi:

  • dependency, project planning, permission, reporting phức tạp hơn;
  • team có kỷ luật sử dụng.

Custom/AppSheet

Chỉ nên làm khi workflow riêng tạo đủ giá trị để đáng gánh maintenance.

Không có “tool tốt nhất”. Có tool ít ma sát nhất cho operating model hiện tại.

15. Audit 30 phút cho hệ thống hiện có

Hỏi:

  • Source of truth nằm ở đâu?
  • Có task chỉ tồn tại trong chat không?
  • Có status trùng nghĩa không?
  • Có task nhiều owner không?
  • Có task không có Done rõ không?
  • Có field nào không ai dùng?
  • Có notification nào ai cũng bỏ qua?
  • Có automation nào tạo duplicate?
  • Có task stale hơn 30 ngày?
  • Có review cadence không?

Chỉ cần sửa 2–3 điểm lớn nhất trước khi đổi platform.

Kết luận

Quản lý công việc hiệu quả không bắt đầu từ app.

Nó bắt đầu từ một hệ thống đủ rõ để app chỉ cần hiển thị và thực thi rule, không phải che giấu sự mơ hồ.

Source of truth → trạng thái → owner → Definition of Done → cadence → automation.

Nếu thứ tự bị đảo, công nghệ thường làm sự hỗn loạn chạy nhanh hơn.

Đọc tiếp