Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Project Manager của một đội vận hành: xử lý ticket khách hàng, sửa lỗi gấp, vừa làm tính năng nhỏ, vừa hỗ trợ bộ phận khác. Công việc đến liên tục, không theo nhịp hai tuần gọn gàng như Scrum. Nếu bạn cố ép một đội như vậy vào các Sprint cố định, bạn sẽ liên tục phải phá kế hoạch giữa chừng vì có việc khẩn. Đây chính là lúc Kanban tỏa sáng.
Kanban không yêu cầu bạn đảo lộn cách tổ chức công việc hiện tại. Nó là một phương pháp tiến hóa: bắt đầu từ đúng những gì đội đang làm, rồi cải thiện dần. Với một Project Manager, Kanban là công cụ cực kỳ thực dụng để nhìn thấy công việc, kiểm soát khối lượng, và làm cho luồng công việc chảy mượt — thay vì để mọi thứ tắc nghẽn trong vô hình.
Trong bài này, chúng ta tập trung vào Kanban như một công cụ quản lý dự án ở mức nền tảng: cách trực quan hóa công việc, cách giới hạn việc đang làm (WIP), cách quản lý luồng và đo lường hiệu quả. Đây là kiến thức cốt lõi mà bất kỳ PM nào cũng nên nắm, bất kể bạn đang theo Scrum, Waterfall hay một mô hình lai.
Khái niệm cốt lõi
Kanban (tiếng Nhật nghĩa là "bảng tín hiệu" hoặc "thẻ trực quan") khởi nguồn từ hệ thống sản xuất của Toyota những năm 1950, sau đó được David J. Anderson đưa vào lĩnh vực công việc tri thức (knowledge work) vào khoảng năm 2007. Khác với Scrum vốn là một khung làm việc (framework) với vai trò và sự kiện cố định, Kanban là một phương pháp (method) bạn áp lên hệ thống hiện có.
Triết lý nền tảng của Kanban gói trong ba câu: Bắt đầu từ nơi bạn đang đứng. Đồng thuận theo đuổi thay đổi tiến hóa, từng bước. Tôn trọng vai trò, trách nhiệm và chức danh hiện tại. Bạn không cần "tái cấu trúc" đội ngay ngày đầu — bạn chỉ cần nhìn rõ công việc rồi cải tiến.
1. Trực quan hóa luồng công việc (Visualize the workflow)
Bước đầu tiên và quan trọng nhất: đưa công việc vô hình ra ánh sáng. Bạn vẽ một bảng Kanban gồm các cột đại diện cho các trạng thái mà một công việc đi qua. Một bảng cơ bản nhất:
Cần làm (To Do) → Đang làm (In Progress) → Hoàn thành (Done)
Mỗi đầu việc là một thẻ (card) di chuyển từ trái sang phải. Với đội thực tế, bạn sẽ chia chi tiết hơn theo đúng quy trình của mình, ví dụ:
Backlog → Phân tích → Đang code → Review → Kiểm thử → Chờ deploy → Xong
Nguyên tắc vàng: bảng phải phản ánh đúng quy trình thật, không phải quy trình lý tưởng trong đầu sếp. Nếu thực tế công việc luôn dừng lại chờ duyệt ngân sách, hãy có một cột "Chờ duyệt". Bảng càng thật, bạn càng thấy được vấn đề thật.
2. Giới hạn việc đang làm (Limit WIP — Work In Progress)
Đây là trái tim của Kanban và cũng là điều khó áp dụng nhất về mặt tâm lý. WIP limit là số lượng tối đa thẻ được phép tồn tại trong một cột (hoặc một nhóm cột) cùng lúc.
Vì sao phải giới hạn? Vì làm nhiều việc cùng lúc không khiến ta nhanh hơn — nó khiến ta chậm hơn. Khi một người ôm năm việc song song, họ liên tục chuyển ngữ cảnh (context switching), mỗi lần chuyển mất thời gian khởi động lại tư duy, và không việc nào hoàn thành sớm. Theo Định luật Little (Little's Law), thời gian hoàn thành trung bình của một công việc tỷ lệ thuận với số việc đang dở dang chia cho tốc độ hoàn thành. Nói đơn giản: càng ít việc làm cùng lúc, mỗi việc càng nhanh xong.
Khi một cột chạm trần WIP, không ai được kéo thêm thẻ vào. Điều này tạo ra một hiệu ứng kỳ diệu: thay vì bắt đầu việc mới, cả đội buộc phải xúm vào đẩy nốt việc đang dở cho xong. Đây chính là nguyên tắc "Stop starting, start finishing" (Ngừng bắt đầu, hãy hoàn thành).
3. Quản lý luồng (Manage flow)
Mục tiêu cuối cùng của Kanban không phải là giữ mọi người luôn bận rộn, mà là làm cho công việc chảy mượt và nhanh từ đầu đến cuối. Bạn quản lý luồng bằng cách quan sát các điểm tắc nghẽn (bottleneck) — nơi thẻ chất đống lại — và xử lý chúng.
Hai chỉ số quan trọng:
- Lead time: tổng thời gian từ lúc một yêu cầu được tiếp nhận đến lúc giao xong cho khách. Đây là điều khách hàng quan tâm.
- Cycle time: thời gian từ lúc đội bắt đầu thực sự làm một thẻ đến lúc hoàn thành nó.
4. Các thực hành bổ sung
Ngoài ba thực hành cốt lõi trên, Kanban đầy đủ còn có: làm rõ chính sách (make policies explicit) — viết rõ điều kiện để một thẻ được chuyển sang cột tiếp theo; vòng phản hồi (feedback loops) — họp nhanh quanh bảng; và cải tiến cộng tác (improve collaboratively) — dùng dữ liệu để liên tục tinh chỉnh hệ thống.
Tình huống thực tế
Ví dụ 1 — Đội hỗ trợ kỹ thuật tại một công ty fintech ở TP.HCM
Một công ty fintech (giả định tên FinanceX, khoảng 80 nhân sự) có đội kỹ thuật vận hành 6 người, mỗi tháng nhận khoảng 120 yêu cầu: sửa lỗi, cấu hình, hỗ trợ tích hợp đối tác. Trước đây họ không có bảng nào — việc được giao qua chat Zalo và email. Hậu quả: yêu cầu của đối tác lớn bị quên mất 9 ngày, khách hàng nổi giận.
PM mới về dựng một bảng Kanban trên Trello với 5 cột và đặt WIP limit là 2 thẻ/người ở cột "Đang làm". Tuần đầu, đội phản đối: "Em đang làm dở 5 việc, giờ chỉ cho 2 thì 3 việc kia bỏ à?". PM giải thích: 3 việc kia vẫn nằm trên bảng ở cột chờ, chỉ là chưa được kéo vào làm. Sau một tháng, dữ liệu cho thấy: lead time trung bình giảm từ 6,5 ngày xuống 2,8 ngày. Lý do không phải đội làm nhanh hơn, mà vì mỗi việc không còn bị bỏ dở giữa chừng.
Bài học: WIP limit ban đầu gây khó chịu, nhưng nó cưỡng bức đội hoàn thành thay vì bắt đầu. Trực quan hóa cũng đảm bảo không yêu cầu nào "rơi" khỏi radar.
Ví dụ 2 — Đội marketing nội dung tại một startup thương mại điện tử
Một startup TMĐT (giả định Shoppy, đội nội dung 4 người) sản xuất bài blog, video ngắn và email. Quy trình của họ là: Ý tưởng → Viết nháp → Biên tập → Thiết kế → Đăng. Vấn đề: cột "Thiết kế" luôn tắc, vì chỉ có một designer trong khi ba người viết liên tục đẩy bài qua.
Khi nhìn vào bảng Kanban, PM thấy rõ: cột "Thiết kế" thường xuyên có 7-8 thẻ chất đống, trong khi các cột khác trống trơn. Đây là một bottleneck lộ ra ngay bằng mắt thường. Giải pháp không phải là viết nhanh hơn (làm vậy chỉ khiến đống chờ thiết kế cao thêm), mà là: tạm thời cho một người viết hỗ trợ làm các thiết kế đơn giản, đồng thời đặt WIP limit cho cột "Biên tập" để giảm áp lực đổ xuống.
Sau hai tuần, thời gian một bài đi từ ý tưởng đến đăng giảm từ 11 ngày xuống 6 ngày.
Bài học: Bảng Kanban biến nút thắt cổ chai vô hình thành hữu hình. Tối ưu toàn bộ luồng quan trọng hơn việc bắt từng cá nhân chạy hết công suất — một người viết "chạy 100%" chỉ làm tắc nghẽn nặng thêm.
Ví dụ 3 — Đội phát triển sản phẩm chuyển từ Scrum thuần sang Scrumban
Một đội 7 người tại một công ty phần mềm gia công ở Đà Nẵng dùng Scrum 2 tuần/Sprint. Vấn đề: khoảng 40% công việc là yêu cầu khẩn từ khách hàng đến bất chợt, phá vỡ kế hoạch Sprint liên tục. Mỗi lần như vậy đội phải họp lại để điều chỉnh, mệt mỏi và mất tinh thần.
PM quyết định áp các thực hành Kanban lên trên Scrum — mô hình thường gọi là Scrumban. Họ giữ Daily Standup và Retrospective, nhưng bỏ cam kết cứng theo Sprint, thay bằng một bảng Kanban có WIP limit và bổ sung một làn (swimlane) riêng cho "Việc khẩn" với chính sách rõ ràng: tối đa 1 việc khẩn trong làn đó tại một thời điểm.
Kết quả sau hai tháng: số lần phải họp khẩn để xáo trộn kế hoạch giảm hẳn, vì việc khẩn đã có chỗ và có giới hạn ngay trong hệ thống. Đội báo cáo cảm giác kiểm soát tốt hơn nhiều.
Bài học: Kanban không loại trừ Scrum — nó có thể được áp lên trên để xử lý đúng những tình huống mà Sprint cố định gặp khó. Đây là sức mạnh "tiến hóa, không cách mạng" của Kanban.
Hướng dẫn từng bước
Đây là cách bạn dựng một hệ thống Kanban cho đội của mình từ con số không:
- Vẽ bản đồ quy trình thật. Ngồi cùng đội và hỏi: "Một công việc thực tế đi qua những bước nào từ lúc nhận đến lúc xong?". Viết các bước đó lên giấy. Đừng vẽ quy trình lý tưởng — vẽ đúng cái đang xảy ra.
- Tạo bảng và các cột tương ứng. Dùng công cụ (Trello, Jira, Notion, hoặc một bảng trắng dán giấy note nếu đội ngồi cùng phòng). Mỗi bước trong quy trình thành một cột.
- Đưa tất cả công việc hiện tại lên bảng. Mỗi đầu việc là một thẻ, đặt vào đúng cột nó đang ở. Lần đầu làm việc này thường gây sốc: đội nhận ra mình đang ôm gấp đôi số việc tưởng tượng.
- Đặt WIP limit ban đầu. Một quy tắc khởi đầu hợp lý: WIP của cột "Đang làm" bằng số người trong đội, hoặc số người cộng một. Đừng cầu toàn — cứ đặt một con số rồi điều chỉnh.
- Định nghĩa chính sách cho mỗi cột. Viết rõ điều kiện để thẻ được kéo sang cột kế tiếp. Ví dụ: "Thẻ chỉ rời cột Code khi đã có unit test và đã được một người khác review."
- Vận hành theo cơ chế kéo (pull). Khi một người rảnh, họ kéo thẻ từ cột bên trái sang, thay vì bị giao việc đẩy xuống. Khi cột chạm trần WIP, không kéo thêm.
- Họp nhanh quanh bảng mỗi ngày. Nhìn từ phải sang trái (ưu tiên đẩy việc gần xong nhất), tìm thẻ bị kẹt và bottleneck.
- Đo lường và cải tiến. Theo dõi lead time, cycle time. Định kỳ điều chỉnh WIP limit và cấu trúc cột dựa trên dữ liệu thật.
Lỗi thường gặp & mẹo
Lỗi 1 — Bảng đẹp nhưng không ai giới hạn WIP. Đây là sai lầm phổ biến nhất. Nhiều đội dựng bảng Kanban rồi tự hào, nhưng bỏ qua WIP limit. Khi đó bảng chỉ là một danh sách công việc trực quan, không phải Kanban thật. Không có WIP limit, công việc vẫn chất đống và không có áp lực nào buộc đội hoàn thành. Mẹo: nếu chỉ làm được một điều, hãy đặt WIP limit — đó là thứ tạo ra phần lớn giá trị.
Lỗi 2 — Cột phản ánh mong muốn thay vì thực tế. Đội giấu các bước "xấu" như "chờ duyệt", "chờ phản hồi khách". Kết quả là bảng nhìn mượt mà nhưng giấu đi đúng những điểm tắc nghẽn cần xử lý. Mẹo: mạnh dạn thêm các cột "chờ" — chúng phơi bày sự lãng phí.
Lỗi 3 — Tối ưu sự bận rộn cá nhân thay vì luồng. Nhiều PM ám ảnh việc "ai cũng phải bận 100%". Nhưng giữ mọi người bận tối đa thường tạo ra bottleneck và kéo dài lead time. Mẹo: hãy đo tốc độ giao hàng của cả luồng, đừng đo mức độ bận của từng người.
Lỗi 4 — Đặt WIP limit quá cao đến mức vô nghĩa. Đặt limit 10 cho đội 5 người thì coi như không có limit. Mẹo: bắt đầu thấp (gây hơi khó chịu một chút là đúng), rồi nới ra nếu thực sự cần.
Lỗi 5 — Dựng bảng rồi để đó. Kanban là hệ thống sống, cần được nhìn và điều chỉnh liên tục. Một bảng không ai cập nhật còn tệ hơn không có bảng. Mẹo: gắn việc nhìn bảng vào nhịp họp hằng ngày.
Bài tập thực hành
- Vẽ bảng của riêng bạn. Chọn một đội hoặc một mảng công việc bạn đang phụ trách. Liệt kê đúng các bước thực tế một công việc đi qua. Vẽ bảng Kanban với các cột tương ứng (dùng giấy note hoặc Trello miễn phí).
- Đưa công việc thật lên bảng. Liệt kê toàn bộ việc đang dở dang và đặt mỗi việc vào đúng cột. Đếm tổng số thẻ ở cột "Đang làm". So với số người trong đội — con số đó nói lên điều gì?
- Thử nghiệm WIP limit. Đặt WIP limit cho cột "Đang làm" bằng số người trong đội. Theo dõi trong một tuần: cảm giác của đội thay đổi thế nào? Có việc nào xong nhanh hơn không?
- Săn bottleneck. Sau vài ngày quan sát, ghi lại cột nào hay bị chất đống thẻ nhất. Viết một giả thuyết về nguyên nhân và một hành động bạn sẽ thử để khơi thông.
- Tính lead time. Với 5 công việc gần nhất đã hoàn thành, ghi lại ngày tiếp nhận và ngày giao xong. Tính lead time trung bình. Đây sẽ là con số nền (baseline) để bạn đo cải tiến về sau.
Tóm tắt
Kanban là một phương pháp quản lý công việc theo tinh thần tiến hóa: bắt đầu từ nơi bạn đang đứng, làm việc trở nên hữu hình, rồi cải tiến dần. Ba thực hành cốt lõi mà một Project Manager cần nắm là: trực quan hóa luồng công việc bằng bảng và thẻ phản ánh đúng quy trình thật; giới hạn việc đang làm (WIP) để buộc đội hoàn thành thay vì liên tục bắt đầu việc mới; và quản lý luồng bằng cách săn bottleneck và rút ngắn lead time.
Điểm mấu chốt cần khắc cốt ghi tâm: giá trị lớn nhất của Kanban đến từ WIP limit — thứ mà các đội hay bỏ qua. "Stop starting, start finishing." Hãy đo tốc độ giao hàng của cả luồng, đừng đo mức độ bận của từng người. Và nhớ rằng Kanban không xung đột với Scrum; bạn hoàn toàn có thể kết hợp cả hai (Scrumban) khi công việc của đội mang tính dòng chảy liên tục, khó ép vào các Sprint cứng. Khi nắm vững Kanban, bạn có thêm một công cụ cực kỳ thực dụng để dẫn dắt đội giao hàng đều đặn và bền vững.