Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang quản lý một đội 8 người, và mỗi sáng đứng họp bạn nghe câu quen thuộc: "Em đang làm nhiều thứ lắm anh ơi, không kịp." Nhưng khi nhìn lại cuối tuần, chẳng có việc gì thực sự "xong". Đội bận rộn nhưng không giao được sản phẩm. Đây là căn bệnh phổ biến nhất của các team hiện đại: mọi người làm quá nhiều việc cùng lúc, và không việc nào chạy tới đích.
Kanban ra đời chính để chữa căn bệnh đó. Ở các bài trước bạn đã học Scrum — một framework có sprint cố định, có ceremony, có role rõ ràng. Kanban là một cách tiếp cận khác hẳn về triết lý: thay vì đóng gói công việc vào các sprint 2 tuần, Kanban tập trung vào dòng chảy liên tục của công việc (flow) và giới hạn số việc đang làm song song. Không có sprint, không bắt buộc estimation, không cần đảo lộn cơ cấu team hiện tại.
Với vai trò Project Manager, hiểu Kanban cho bạn thêm một công cụ cực kỳ linh hoạt — đặc biệt hữu ích cho các đội vận hành (operations), đội hỗ trợ (support), đội bảo trì (maintenance), hoặc bất kỳ môi trường nào công việc đến bất chợt và không thể "đóng băng" trong 2 tuần. Bài này sẽ giúp bạn hiểu bản chất Kanban, cách dựng một board thực tế, cách đọc chỉ số flow, và tránh những cái bẫy mà rất nhiều team Việt Nam mắc phải khi "làm Kanban" nhưng thực ra chỉ đang dán giấy nhớ lên tường.
Khái niệm cốt lõi
Nguồn gốc: từ nhà máy Toyota
Kanban (看板, nghĩa đen là "bảng hiệu" trong tiếng Nhật) khởi nguồn từ Toyota Production System những năm 1940-1950. Kỹ sư Taiichi Ohno quan sát cách siêu thị Mỹ bổ sung hàng lên kệ: khách lấy hàng, kệ trống, nhân viên mới bổ sung đúng lượng đã bán — không nhồi hàng dư thừa. Ông áp dụng nguyên lý này vào dây chuyền sản xuất: một công đoạn chỉ sản xuất khi công đoạn sau kéo (pull) yêu cầu, thay vì công đoạn trước đẩy (push) hàng loạt xuống.
Kết quả là giảm tồn kho, giảm lãng phí, và công việc chảy đều thay vì dồn ứ. Đầu những năm 2000, David J. Anderson chuyển hóa tư duy này sang lĩnh vực phát triển phần mềm và công việc tri thức (knowledge work), tạo ra Kanban Method mà chúng ta dùng ngày nay.
Bốn nguyên tắc nền tảng
Kanban không yêu cầu bạn phá bỏ quy trình hiện tại — đây là điểm khác biệt lớn nhất so với Scrum. Nó dựa trên bốn nguyên tắc:
- Bắt đầu từ những gì bạn đang làm — không cần tái cấu trúc team. Cứ giữ vai trò, quy trình, chức danh hiện có.
- Đồng thuận theo đuổi thay đổi tiến hóa, từ từ — cải tiến dần dần, không cách mạng đột ngột.
- Tôn trọng quy trình, vai trò và trách nhiệm hiện tại — nhờ vậy team ít kháng cự khi áp dụng.
- Khuyến khích lãnh đạo ở mọi cấp — bất kỳ ai cũng có thể đề xuất cải tiến, không chỉ sếp.
Sáu thực hành cốt lõi
Đây là phần bạn thực sự "làm" khi triển khai Kanban:
1. Trực quan hóa dòng công việc (Visualize the workflow). Bạn dựng một board với các cột thể hiện từng giai đoạn công việc đi qua. Cột kinh điển nhất là: Backlog → To Do → In Progress → Review → Done. Mỗi việc là một thẻ (card) di chuyển từ trái sang phải. Khi nhìn vào board, cả team thấy ngay ai đang làm gì, việc nào đang tắc.
2. Giới hạn công việc đang làm (Limit WIP — Work In Progress). Đây là trái tim của Kanban. Mỗi cột có một con số giới hạn tối đa. Ví dụ cột "In Progress" đặt WIP = 3, nghĩa là toàn team chỉ được có tối đa 3 việc đang chạy cùng lúc. Muốn kéo việc mới vào, phải hoàn thành một việc trước. Chính giới hạn này ép team hoàn thành thay vì bắt đầu liên tục.
3. Quản lý dòng chảy (Manage flow). Bạn theo dõi công việc chảy qua board nhanh hay chậm, chỗ nào bị nghẽn (bottleneck), và can thiệp để dòng chảy mượt mà, đều đặn.
4. Làm rõ chính sách quy trình (Make policies explicit). Ví dụ: "Một thẻ chỉ được chuyển sang Done khi đã qua code review và có test." Ai cũng biết luật chơi, không mập mờ.
5. Vòng phản hồi (Feedback loops). Họp đứng hằng ngày quanh board, review định kỳ để cải tiến.
6. Cải tiến liên tục dựa trên dữ liệu (Improve collaboratively). Dùng các chỉ số đo lường để cải tiến, không cải tiến theo cảm tính.
Ba chỉ số flow bạn phải biết
Kanban là môn "chơi bằng số". Ba chỉ số quan trọng nhất:
- Lead Time: tổng thời gian từ lúc yêu cầu được ghi nhận (vào Backlog) đến lúc giao xong (Done). Đây là con số khách hàng cảm nhận.
- Cycle Time: thời gian từ lúc team bắt đầu làm (In Progress) đến lúc Done. Đây là con số nội bộ, đo tốc độ thực thi.
- Throughput: số việc hoàn thành trong một khoảng thời gian (ví dụ 15 thẻ/tuần). Dùng để dự báo năng lực.
Little's Law — nền tảng toán học
Kanban có một công thức đơn giản mà quyền lực:
> Cycle Time trung bình = WIP trung bình ÷ Throughput trung bình
Nghĩa là: nếu bạn muốn giảm thời gian hoàn thành mỗi việc (cycle time), cách nhanh nhất là giảm số việc làm song song (WIP). Đây là lý do khoa học vì sao "làm ít việc một lúc lại xong nhanh hơn" — một điều phản trực giác với nhiều quản lý Việt Nam vốn thích thấy nhân viên "bận rộn".
Tình huống thực tế
Ví dụ 1: Đội hỗ trợ kỹ thuật của Tiki
Giả định một đội Technical Support 6 người tại Tiki xử lý ticket lỗi hệ thống từ đội vận hành kho. Trước đây họ dùng email và bảng Excel. Mỗi kỹ sư "ôm" 8-10 ticket cùng lúc, và ticket khó thường bị bỏ lơ vì kỹ sư nhảy sang ticket dễ để "cho có thành tích". Khách hàng nội bộ phàn nàn lead time trung bình một ticket là 5 ngày.
Team dựng board Kanban trên Trello với các cột: Mới → Đang phân tích → Đang xử lý → Chờ xác nhận → Xong. Họ đặt WIP cho cột "Đang xử lý" = 6 (mỗi người 1 việc). Kết quả sau một tháng: vì không thể ôm nhiều việc, kỹ sư buộc phải xử lý dứt điểm từng ticket. Lead time giảm từ 5 ngày xuống còn 2 ngày. Quan trọng hơn, khi một ticket khó bị tắc ở cột "Đang xử lý" quá 2 ngày, cả team nhìn thấy trên board và xúm vào giải quyết (gọi là swarming) thay vì để nó chìm.
Bài học: Giới hạn WIP không làm chậm team — nó ép team hoàn thành. Và board trực quan biến việc bị tắc từ "chuyện riêng của một người" thành "vấn đề chung của cả đội".
Ví dụ 2: Team marketing của một startup fintech tại TP.HCM
Một startup ví điện tử có đội marketing 5 người, công việc đến từ mọi hướng: viết bài blog, thiết kế banner khuyến mãi, chạy quảng cáo, làm nội dung TikTok. Không có sprint nào phù hợp vì yêu cầu thay đổi liên tục theo thị trường. Sếp marketing thử Scrum nhưng thất bại — sprint vừa lên kế hoạch xong thì CEO lại yêu cầu chiến dịch mới gấp.
Họ chuyển sang Kanban trên Jira với chính sách rõ ràng: mỗi thành viên WIP tối đa 2 thẻ, và có một làn (swimlane) riêng cho "việc gấp từ ban lãnh đạo" với WIP = 1 để tránh việc gấp nuốt hết dòng chảy bình thường. Họ đo throughput và phát hiện đội hoàn thành trung bình 12 thẻ/tuần. Từ đó, khi CEO hỏi "làm được 5 chiến dịch trong tuần không?", sếp marketing dựa vào dữ liệu để trả lời có căn cứ thay vì đoán mò.
Bài học: Kanban đặc biệt hợp với công việc khó dự báo, đến bất chợt. Swimlane cho việc khẩn cấp giúp cân bằng giữa "cháy nhà" và "công việc thường ngày". Và throughput biến những cuộc thương lượng cảm tính thành đối thoại dựa trên số liệu.
Ví dụ 3: Đội bảo trì phần mềm outsourcing tại một công ty ở Đà Nẵng
Một công ty gia công phần mềm ở Đà Nẵng có đội 4 người bảo trì hệ thống cho khách hàng Nhật. Công việc gồm sửa bug, xử lý yêu cầu nhỏ, và bảo trì định kỳ. Khách hàng Nhật rất coi trọng tính đúng hẹn và minh bạch.
Đội dựng board Kanban và làm rõ chính sách (explicit policy): mỗi loại việc có mức ưu tiên và SLA khác nhau — bug nghiêm trọng phải xong trong 4 giờ, yêu cầu thường trong 3 ngày. Họ dùng thẻ màu khác nhau và đặt WIP thấp cho cột "Testing" = 2 vì phát hiện đây là nghẽn cổ chai (chỉ có 1 tester). Cumulative Flow Diagram cho thấy dải "Testing" luôn phình to. Nhờ nhìn ra điều này, họ đào tạo chéo (cross-train) một dev biết test, và cycle time giảm 30%.
Bài học: CFD giúp bạn nhìn thấy bottleneck bằng mắt thay vì cảm nhận mơ hồ. Và bottleneck thường không nằm ở "làm chậm" mà ở một công đoạn có năng lực hạn chế (ở đây là testing).
Hướng dẫn từng bước
Đây là cách triển khai Kanban cho một team thực tế:
Bước 1 — Vẽ dòng công việc hiện tại. Ngồi cùng team, hỏi: "Một yêu cầu đi qua những giai đoạn nào từ lúc nhận đến lúc giao?" Đừng bịa quy trình lý tưởng — hãy vẽ đúng thực tế đang diễn ra. Đây trở thành các cột trên board.
Bước 2 — Dựng board. Có thể dùng bảng vật lý với giấy nhớ, hoặc công cụ số như Trello, Jira, Asana, hoặc Notion. Mỗi việc là một thẻ, ghi rõ tên việc, người phụ trách, ngày bắt đầu.
Bước 3 — Đặt giới hạn WIP. Đây là bước khó nhất về tâm lý. Nguyên tắc khởi đầu phổ biến: WIP = số người trong team, hoặc số người + 1. Đừng đặt quá cao (vô nghĩa) hay quá thấp (team đứng chờ). WIP là con số bạn sẽ điều chỉnh dần.
Bước 4 — Định nghĩa chính sách rõ ràng. Viết ra luật chơi: điều kiện để một thẻ chuyển cột (Definition of Done cho từng cột), cách xử lý việc khẩn cấp, ai được kéo việc. Dán luật này ngay cạnh board.
Bước 5 — Bắt đầu chạy và họp đứng quanh board. Mỗi ngày họp ngắn 10-15 phút, nhưng khác Scrum: bạn đọc board từ phải sang trái — ưu tiên đẩy việc gần Done trước, hỏi "việc nào đang tắc, cần gì để nó chảy tiếp?" thay vì hỏi từng người "hôm qua làm gì".
Bước 6 — Đo lường và cải tiến. Sau 2-4 tuần, thu thập lead time, cycle time, throughput. Vẽ CFD. Tìm nghẽn cổ chai. Điều chỉnh WIP, phân bổ lại nguồn lực, và lặp lại. Kanban là hành trình cải tiến liên tục, không phải cài đặt một lần.
Lỗi thường gặp & mẹo
Lỗi 1 — Dựng board nhưng bỏ qua giới hạn WIP. Đây là lỗi số một tại Việt Nam. Rất nhiều team dán giấy nhớ đầy tường và tự hào "đang làm Kanban", nhưng không đặt WIP. Không có WIP thì đó chỉ là một cái bảng theo dõi, không phải Kanban — và bạn mất hoàn toàn lợi ích cốt lõi. Mẹo: Nếu chỉ làm được một điều, hãy đặt WIP.
Lỗi 2 — Đặt WIP quá cao cho "an toàn". Nhiều quản lý sợ nhân viên "rảnh" nên đặt WIP thoải mái. Kết quả: mọi người vẫn ôm nhiều việc, không có tác dụng. Mẹo: Bắt đầu chặt tay, nới ra sau nếu team thực sự đứng chờ.
Lỗi 3 — Coi cột "Done" là đích thật sự nhưng không kiểm soát cột chờ. Các cột "Chờ review", "Chờ khách xác nhận" thường tích tụ việc âm thầm. Mẹo: Đặt WIP cho cả cột chờ, và theo dõi thời gian thẻ nằm chờ.
Lỗi 4 — Bỏ qua đo lường. Không đo lead time, cycle time thì bạn không biết mình đang cải thiện hay tệ đi. Mẹo: Ghi ngày vào và ngày ra của mỗi thẻ ngay từ đầu, dù chỉ ghi tay.
Lỗi 5 — Nhầm Kanban với "không có kỷ luật". Vì Kanban không có sprint hay ceremony bắt buộc, nhiều người tưởng nó lỏng lẻo. Ngược lại, Kanban đòi hỏi kỷ luật cao trong việc tôn trọng giới hạn WIP và chính sách rõ ràng. Mẹo: Chính sách rõ ràng là kỷ luật của Kanban.
Mẹo bổ sung — Khi nào chọn Kanban thay vì Scrum: Chọn Kanban khi công việc đến liên tục và khó đóng gói vào sprint (support, ops, bảo trì), khi ưu tiên thay đổi thường xuyên, hoặc khi bạn muốn cải tiến quy trình hiện có mà không muốn đảo lộn team. Nhiều team còn kết hợp cả hai thành Scrumban — dùng khung sprint của Scrum nhưng áp giới hạn WIP và tư duy flow của Kanban.
Bài tập thực hành
- Vẽ board cho chính công việc của bạn. Chọn một loại công việc bạn đang phụ trách (dự án cá nhân cũng được). Vẽ ra các cột thể hiện đúng quy trình thực tế, không phải quy trình lý tưởng. Liệt kê tất cả việc đang làm dở lên các cột. Bạn có bất ngờ về số việc đang "In Progress" không?
- Tính WIP hiện tại của bạn. Đếm số việc bạn (hoặc team) đang thực sự làm song song ngay lúc này. Nếu con số lớn hơn số người, hãy thử áp một giới hạn WIP và quan sát trong một tuần điều gì thay đổi.
- Áp dụng Little's Law. Giả sử team bạn có WIP trung bình là 12 việc và throughput là 4 việc/tuần. Hãy tính cycle time trung bình. Sau đó tính lại nếu bạn giảm WIP xuống 6. Bạn rút ra kết luận gì về mối quan hệ giữa số việc song song và tốc độ giao hàng?
- Tình huống thiết kế: Bạn quản lý đội vận hành 5 người xử lý yêu cầu nội bộ, thỉnh thoảng có "việc cháy" từ giám đốc. Hãy thiết kế board Kanban gồm: các cột, giới hạn WIP cho từng cột, một swimlane cho việc khẩn cấp, và ít nhất 2 chính sách rõ ràng (explicit policy). Giải thích lựa chọn của bạn.
Tóm tắt
Kanban là phương pháp quản lý công việc dựa trên dòng chảy liên tục thay vì các chu kỳ cố định như Scrum. Xuất phát từ hệ thống sản xuất Toyota, nó dựa trên nguyên lý kéo (pull) thay vì đẩy (push). Sáu thực hành cốt lõi gồm: trực quan hóa dòng công việc, giới hạn WIP, quản lý dòng chảy, làm rõ chính sách, tạo vòng phản hồi, và cải tiến liên tục dựa trên dữ liệu.
Trái tim của Kanban là giới hạn WIP — ép team hoàn thành thay vì bắt đầu liên tục. Ba chỉ số cần theo dõi là lead time, cycle time và throughput, với công cụ trực quan là Cumulative Flow Diagram. Little's Law cho thấy giảm số việc song song sẽ giảm thời gian hoàn thành mỗi việc — một sự thật phản trực giác nhưng cực kỳ mạnh.
Kanban đặc biệt phù hợp với công việc đến liên tục, khó dự báo, hoặc khi bạn muốn cải tiến quy trình hiện tại mà không đảo lộn team. Lỗi phổ biến nhất là dựng board mà quên đặt WIP — biến Kanban thành một tấm bảng vô nghĩa. Là một Project Manager, hãy nhớ: Kanban không đo bạn bận rộn đến đâu, mà đo công việc chảy tới đích nhanh và đều đến mức nào.