Vì sao Kanban hiệu quả, và làm sao biết đội ngũ của bạn đã sẵn sàng cho nó

Hầu hết các nhóm áp dụng Kanban chỉ vì ai đó đọc được một bài blog. Câu hỏi thông minh hơn là liệu những vấn đề Kanban giải quyết có thực sự là vấn đề của nhóm bạn hay không.

Có một khoảnh khắc mà hầu hết các nhóm đều quen thuộc, thường xuất hiện khi đội ngũ vượt quá tám hay chín người. Công việc vẫn được hoàn thành: email được gửi, tính năng được phát hành, khách hàng được chăm sóc, nhưng không ai có cái nhìn rõ ràng về việc những người khác đang làm gì. Dự án chồng chất. Việc được hứa rồi lặng lẽ bị quên. Bạn mất hai mươi phút trước mỗi cuộc họp chỉ để tìm xem một đầu việc thực sự đang ở đâu. Câu trả lời thường là "đâu đó".

Đó là vấn đề mà Kanban được thiết kế để giải quyết. Không phải vấn đề hoạch định chiến lược, tuyển đúng người hay xây dựng văn hóa, mà là vấn đề vận hành cụ thể, dai dẳng: biết đội ngũ đang làm gì và điều gì đang cản trở.

Đây là một công cụ khiêm tốn đến bất ngờ so với sự chú ý nó thu hút. Kanban không tuyên bố sẽ sửa tổ chức của bạn. Nó chỉ làm công việc trở nên hiển thị. Và hóa ra sự hiển thị, nếu áp dụng nhất quán, thay đổi rất nhiều thứ ở các khâu phía sau.

Kanban thực sự bắt nguồn từ đâu

Từ này có gốc tiếng Nhật, nghĩa là "bảng hiệu" hoặc "biển quảng cáo", và hệ thống được Toyota phát triển vào cuối thập niên 1940 để quản lý tồn kho trong các nhà máy sản xuất của họ. Ý tưởng rất đơn giản: thay vì sản xuất linh kiện theo lịch cố định, nhà máy chỉ sản xuất khi một công đoạn phía sau báo rằng nó cần. Một tấm thẻ vật lý, chính là kanban, sẽ di chuyển ngược lên dây chuyền như một yêu cầu. Không có gì được làm theo kiểu dự phòng. Không có gì chất đống không cần thiết.

Cái nhìn thấu đáo mà Toyota có, và sau này các nhóm phần mềm vay mượn, là phần lớn sự kém hiệu quả của một hệ thống không đến từ việc con người làm quá chậm, mà từ việc làm sai việc vào sai thời điểm. Quá nhiều việc được bắt đầu cùng lúc. Những điểm nghẽn mà không ai nhận ra cho đến khi quá muộn. Công việc nằm xong xuôi ở chỗ này trong khi bước kế tiếp đang quá tải ở chỗ khác.

Các lập trình viên phần mềm, đặc biệt ở những công ty như Microsoft vào đầu những năm 2000, bắt đầu điều chỉnh các ý tưởng này cho công việc tri thức. Những tấm thẻ trở thành các tác vụ. Các công đoạn nhà máy trở thành các giai đoạn trong quy trình làm việc. Và bảng hiệu trở thành một bảng công việc, ban đầu là bảng vật lý, sau đó là bảng số, nơi bất kỳ ai trong nhóm cũng có thể nhìn thoáng qua và thấy việc gì đang làm, việc gì đang chờ và việc gì đã xong.

Một bảng Kanban thực sự cho bạn thấy điều gì

Một bảng Kanban cơ bản có ba cột: Cần làm, Đang làm và Hoàn thành. Như vậy đã đủ cho nhiều nhóm nhỏ và là điểm khởi đầu tốt. Nhưng giá trị thực sự xuất hiện khi bạn bắt đầu tùy chỉnh các giai đoạn cho khớp với cách công việc thực sự luân chuyển, chứ không phải cách bạn ước nó luân chuyển.

Một nhóm nội dung có thể dùng: Ý tưởng, Brief, Đang viết nháp, Đang duyệt, Đã lên lịch, Đã đăng. Một nhóm phần mềm có thể tách "Đang làm" thành các cột riêng cho phát triển, review code và QA. Một nhóm tư vấn có thể theo dõi Khảo sát, Đề xuất, Đang thực hiện, Chờ khách hàng và Đã đóng. Các giai đoạn nên phản ánh những điểm bàn giao thực và thời gian chờ thực, nơi công việc đổi tay hoặc nằm chờ cho đến khi có điều gì khác xảy ra.

Hãy chú ý thẻ ở cột giữa: báo cáo kiểm kê kho, đã tám ngày, được đánh dấu là bị chặn. Trong một hệ thống không có bảng, tác vụ đó có thể nằm đó thêm hai tuần nữa mà không ai nhận ra nó không nhúc nhích. Có người đang chờ một bên thứ ba. Hoặc cần một quyết định từ một quản lý không biết mình chính là điểm nghẽn. Cái bảng làm sự tắc nghẽn hiển thị. Đó là phần lớn công việc.

Quy tắc giúp Kanban vận hành: giới hạn WIP

Nếu có một khái niệm phân biệt nhóm dùng Kanban đúng cách với nhóm chỉ có một danh sách việc cần làm đẹp hơn, đó là giới hạn công việc đang thực hiện, gọi tắt là giới hạn WIP. Ý tưởng là mỗi cột có một số lượng mục tối đa được phép có mặt cùng lúc. Khi một cột đã đầy, bạn không thể thêm việc cho đến khi có thứ gì đó rời đi.

Điều này nghe ngược trực giác. Chẳng lẽ đưa được nhiều tác vụ vào thực hiện hơn nghĩa là làm được nhiều hơn? Không. Điều thực sự xảy ra khi mọi người làm quá nhiều việc cùng lúc là mọi thứ đều lâu hơn. Chuyển đổi ngữ cảnh rất tốn kém. Công việc dang dở tạo ra chi phí phối hợp. Và khi mười việc đều "đang làm", rất khó nhận ra việc nào thực sự đang tiến triển và việc nào chỉ đang kẹt mà không được đánh dấu.

Giới hạn WIP bằng ba ở cột Đang làm nghĩa là khi việc thứ tư đến bàn ai đó, một người trong nhóm phải quyết định: tác vụ hiện có nào sẽ được hoàn thành trước? Nó buộc phải ưu tiên. Nó buộc phải trao đổi. Và nó thường giúp từng đầu việc hoàn thành nhanh hơn, dù tốc độ bắt đầu việc mới chậm lại.

Kanban so với Scrum: câu hỏi các nhóm luôn đặt ra

Nếu bạn đã từng tiếp xúc với các nhóm phần mềm hoặc tư duy vận hành hiện đại, hẳn bạn đã gặp Scrum, khung làm việc tổ chức công việc thành các sprint hai tuần cố định, với các buổi lập kế hoạch, retrospective và các vai trò xác định như Scrum Master và Product Owner. Nhiều nhóm coi Scrum và Kanban là hai phương pháp luận cạnh tranh và nghĩ rằng phải chọn một. Sự khác biệt thực ra đơn giản hơn thế.

Nhiều nhóm, đặc biệt là những nhóm không thuần kỹ thuật phần mềm, thấy các nghi thức của Scrum nặng nề và cấu trúc sprint cố định khó áp dụng cho công việc vận hành liên tục. Các nhóm marketing, customer success, vận hành và những nhà sáng lập vừa làm mọi thứ cùng lúc hiếm khi có công việc khớp gọn vào chu kỳ hai tuần. Mô hình dòng chảy liên tục của Kanban thường phù hợp với họ hơn.

Dù vậy, nhiều nhóm kết hợp cả hai. Họ dùng chu kỳ lập kế hoạch kiểu sprint cho phát triển sản phẩm, đồng thời chạy một bảng Kanban cho công việc vận hành và hỗ trợ cứ đổ vào bất kể đang ở sprint nào. Đó là một mô hình lai hoàn toàn hợp lý.

Ba câu hỏi bảng của bạn phải trả lời được trong ba mươi giây

Một bảng Kanban hữu ích nhất khi bạn nhìn vào và, không cần hỏi ai, trả lời nhanh ba câu hỏi này: Nhóm đang làm gì ngay lúc này? Công việc đang kẹt ở đâu? Có việc nào đáng lẽ phải làm nhưng chưa được bắt đầu không?

Nếu bạn không trả lời được cả ba câu trong vòng ba mươi giây sau khi nhìn bảng, có lẽ bảng chưa được duy trì đúng cách. Dạng thất bại phổ biến nhất là một cái bảng mà các tác vụ được tạo ra nhưng không bao giờ được di chuyển: nó trở thành nghĩa địa của những ý định tốt thay vì tấm bản đồ sống của công việc thực. Một cái bảng không cập nhật còn tệ hơn không có bảng, vì nó tạo ra ảo giác về sự minh bạch.

Kỷ luật cần để duy trì một cái bảng là có thật. Tác vụ cần được di chuyển khi công việc di chuyển. Các mục bị chặn cần được đánh dấu ngay khi chúng đình trệ, không phải hai tuần sau. Thẻ cần có người phụ trách rõ ràng, và người phụ trách cần cập nhật thẻ của mình. Không việc nào trong số này tốn nhiều thời gian, một thực hành Kanban vận hành tốt có thể chỉ mất năm đến mười phút mỗi người mỗi ngày, nhưng nó đòi hỏi sự nhất quán. Những nhóm hưởng lợi nhiều nhất từ Kanban là những nhóm coi cái bảng là nguồn sự thật duy nhất, chứ không phải một việc ghi chép bổ sung.

Những gì Kanban không làm được

Kanban không phải công cụ chiến lược. Nó sẽ không giúp bạn xác định nên làm gì, chỉ giúp bạn quản lý những gì bạn đã quyết định làm. Nếu tổ chức của bạn có vấn đề về ưu tiên, hoặc vấn đề về thẩm quyền không rõ ràng, hoặc vấn đề "chúng ta bắt đầu quá nhiều dự án trước khi hoàn thành dự án cũ" bắt nguồn từ hành vi của ban lãnh đạo hơn là quy trình, một bảng Kanban sẽ phơi bày những vấn đề đó nhưng không giải quyết được chúng.

Nó cũng không thay thế được quản lý tốt. Một cái bảng không thay thế các buổi 1:1, việc ủy quyền chu đáo hay giao tiếp rõ ràng về lý do một số công việc quan trọng. Các nhóm đôi khi áp dụng công cụ quy trình với hy vọng quy trình sẽ làm thay công việc về quan hệ và tổ chức vốn là việc của người quản lý. Nó sẽ không làm.

Điều nó làm được là giảm bớt sự mơ hồ bao trùm vốn làm chậm hầu hết các nhóm. Những câu hỏi như "ai đang làm gì", "việc này xong chưa" và "tôi nên nhận việc gì tiếp theo" tạo ra lượng giao tiếp giá trị thấp khổng lồ ở những tổ chức không có một hệ thống chung, hiển thị. Kanban loại bỏ phần lớn tiếng ồn đó. Và với những nhóm mà tiếng ồn đó là vấn đề chính, sự khác biệt là đáng kể.

Cách bắt đầu mà không cần hội thảo ba ngày

Những lần triển khai Kanban tốt nhất mà tôi từng thấy đều bắt đầu nhỏ và tiến hóa dần. Những lần tệ nhất có sự tham gia của một nhà tư vấn, một kỳ offsite hai ngày và một cái bảng được thiết kế đẹp đẽ mà đến tuần thứ ba không ai còn dùng.

Hãy bắt đầu với đội ngũ đúng như hiện tại, với công việc bạn thực sự có. Tạo ba cột: Tồn đọng, Đang làm, Hoàn thành. Dành ba mươi phút cùng nhóm đưa mọi đầu việc hiện tại lên thẻ. Thống nhất một quy tắc: khi bạn bắt đầu việc gì, nó lên bảng. Khi nó chuyển giai đoạn, bạn di chuyển thẻ. Đừng làm gì khác trong hai tuần.

Sau hai tuần, cùng nhau nhìn lại cái bảng. Việc gì đã chất đống? Cái gì nằm mãi ở Tồn đọng dù mọi người đều nói là ưu tiên? Cái gì chạy nhanh hơn dự kiến? Cái gì bị kẹt và vì sao? Dùng những gì bạn quan sát được để tinh chỉnh các cột và bổ sung chi tiết. Có thể "Đang làm" cần tách thành "Đang làm" và "Chờ bên ngoài". Có thể bạn cần một cột "Đang duyệt" vì bước đó cứ bị thất lạc. Hãy để cái bảng tiến hóa theo những gì công việc thực tế của bạn bộc lộ, chứ không theo những gì một cuốn sách phương pháp luận nói nó nên trông như thế nào.

Chặng đường dài hơn: các chỉ số dòng chảy

Khi một hệ thống Kanban đã chạy, nó tạo ra dữ liệu mà hầu hết các nhóm không bao giờ dùng. Lead time, tổng thời gian từ khi một tác vụ được tạo đến khi hoàn thành, là chỉ số quan trọng nhất. Nếu lead time trung bình của một tác vụ điển hình là mười hai ngày và bạn muốn còn năm, bạn đã có một con số để hướng tới và một cái bảng sẽ chỉ cho bạn bảy ngày dư thừa kia đang đi đâu.

Cycle time chỉ đo khoảng thời gian làm việc thực tế, không tính thời gian tác vụ nằm trong tồn đọng. Throughput đo số mục nhóm bạn hoàn thành mỗi tuần. Không chỉ số nào trong số này cần phần mềm đặc biệt nếu bạn kỷ luật ghi lại thời điểm thẻ được tạo và thời điểm đóng. Và cùng nhau, chúng cho bạn bức tranh trung thực hơn nhiều về năng lực của nhóm so với bất kỳ quy trình lập kế hoạch dựa trên ước tính nào.

Hầu hết các nhóm nhỏ và vừa không bao giờ đi đến bước này. Họ dùng Kanban như một công cụ hiển thị, vốn đã có giá trị riêng, và không đi xa hơn. Như vậy cũng không sao. Nhưng nếu bạn muốn cam kết với các bên liên quan về thời điểm hoàn thành, hoặc muốn hiểu vì sao một số công việc mất gấp ba thời gian dự kiến, các chỉ số đó luôn sẵn khi bạn cần.