Cột làm trạng thái

Một bảng kanban làm việc trở nên rõ ràng. Mỗi mảnh việc là một thẻ. Thẻ di chuyển từ trái sang phải qua các cột biểu thị trạng thái.

Các cột cổ điển là: Backlog → Selected → In Progress → Review → Done

Nhưng các cột chính xác không quan trọng. Điều quan trọng là mỗi thẻ luôn có một trạng thái hiện tại, và trạng thái đó rõ ràng cho tất cả những người làm việc trong hệ thống.

Gì một thẻ biểu thị

Một thẻ biểu thị một đơn vị công việc có thể hoàn thành độc lập. Không phải là dự án. Không phải là mục tiêu. Một điều gì đó rõ ràng, có phạm vi và có định nghĩa rõ ràng về việc hoàn thành.

Thẻ tốt: Đổi khóa SSH trên máy chủ sản xuất: hoàn thành khi tất cả các máy chủ hiển thị khóa mới trong authorized_keys & khóa cũ bị loại bỏ.

Thẻ xấu: Tăng cường an ninh. (Điều này là một dự án, không phải là nhiệm vụ. Hãy chia nhỏ nó.)

Giới hạn WIP

Cột In Progress trong hình ảnh này có Giới hạn WIP: 3. Điều này có nghĩa là không quá ba thẻ có thể ở trạng thái In Progress cùng một lúc. Nếu bạn muốn lấy một thẻ thứ tư, bạn phải hoàn thành một thẻ trước.

Điều này có vẻ như là một hạn chế. Nó là: một thiết kế. Giới hạn WIP khiến bạn phải hoàn thành những gì bạn đã bắt đầu trước khi bắt đầu điều mới. Bạn sẽ tìm hiểu thêm về lý do tại sao điều này quan trọng trong một phần sau.

Phạm vi công việc thẻ

Kỹ năng khó nhất trong kanban không phải là vẽ bảng. Nó là phạm vi thẻ. Lớn quá và thẻ sẽ nằm trong trạng thái In Progress trong nhiều tuần, cản trở công việc khác. Nhỏ quá và bảng sẽ đầy tiếng ồn.

Các khu vực chức năng hoạt động tốt

Mọi hoạt động đa ngành đều có các trung tâm công việc chức năng: một xưởng bánh có bánh ngọt, bánh mì, món ăn vặt và quầy trước. Một studio sản phẩm có thiết kế, nội dung, xây dựng và vận hành. Một dự án xây dựng có khung, ống, điện và hoàn thiện. Những trung tâm này tồn tại vì lý do tốt: sự chuyên sâu về chuyên môn đòi hỏi quyền sở hữu tập trung.

Kanban không giải thể những sự phân chia này. Nó làm rõ và rõ ràng các chuyển giao giữa chúng.

Cổng giao tiếp

Khi một đơn vị công việc di chuyển từ một trung tâm công việc sang trung tâm khác, ví dụ như tài sản thiết kế cần viết trước khi người xây dựng có thể lắp ráp trang, một cổng giao tiếp đi cùng với nó. Trung tâm downstream thấy card xuất hiện trong Backlog của họ. Họ pull nó khi họ có khả năng. Không cần email. Không cần cuộc họp để điều phối. Card là tín hiệu.

Gì mà hình ảnh thể hiện

Vé ★ bắt đầu ở Design (In Progress: tài sản hình ảnh). Khi Design hoàn thành phần việc của họ, một cổng giao tiếp được tạo ra và vé ★ xuất hiện trong Backlog của trung tâm Build. Build pull nó. Sau đó Ops pull nó. Mỗi trung tâm có bảng của riêng họ. Mỗi bảng chỉ hiển thị công việc hiện tại của trung tâm đó. Nhưng ★ di chuyển qua tất cả chúng và mọi người đều có thể xem nó ở đâu.

Đây là triết lý siêu thị áp dụng cho tổ chức: mỗi trung tâm công việc là một kệ hàng. Cards chỉ tiếp tế cho kệ hàng downstream khi công việc upstream được pull và tiêu thụ.

Thiết kế một Cổng Giao Tiếp

Cổng giao tiếp là hợp đồng giữa các trung tâm công việc. Nó phải chứa đủ thông tin ngữ cảnh cho đội nhận được hành động mà không cần cuộc họp.

Dừng Bắt Đầu. Bắt Đầu Hoàn Thành.

GIH viết tắt cho Công Việc Trong Tiến Trình. Giới hạn GIH là một giới hạn trên số lượng card có thể có trong một cột nhất định một lúc.

Điều này nghe có vẻ như một hạn chế. Nó là vậy. Đó là mục đích.

Tại sao giới hạn giúp

Mỗi khi bạn bắt đầu một nhiệm vụ mới mà không hoàn thành nhiệm vụ trước đó, bạn phải trả thuế chuyển ngữ cảnh. Não của bạn tải ngữ cảnh của nhiệm vụ mới và partiallyunload ngữ cảnh cũ. Khi bạn quay lại nhiệm vụ cũ, bạn phải tải lại nó. Đối với công việc tri thức, viết, debug, thiết kế, xem xét, chi phí reload được đo lường trong giờ, không giây.

Giới hạn WIP ngăn ngừa sự tích tụ của công việc chưa hoàn thành. Chúng cũng làm điều gì đó có giá trị hơn: chúng làm nổi bật điểm nghẽn.

Điểm nghẽn trở nên rõ ràng

Nếu cột Review có giới hạn WIP là 2 và nó luôn ở mức 2, đó là một tín hiệu: review chậm hơn sản xuất. Có nhiều công việc hoàn thành trong In Progress hơn có thể được tiêu thụ bởi Review. Không có giới hạn WIP, bảng công việc sẽ đầy 'hoàn thành nhưng đang đợi review' và điểm nghẽn sẽ không rõ ràng. Với giới hạn WIP, cột In Progress không thể chấp nhận các thẻ mới, và cả đội đều thấy giới hạn.

Điều này không phải là một sự thất bại. Đây là thông tin. Hệ thống đang告诉bạn cần sửa Review, tuyển dụng, ghép đôi, giảm kích thước lô, thay vì cố đẩy thêm công việc thông qua.

Định luật Little (không chính thức)

Thời gian chuẩn bị (số giờ một thẻ mất từ ​​bắt đầu đến hoàn thành) = Công việc trong tiến trình ÷ Thống kê (số thẻ hoàn thành mỗi đơn vị thời gian). Nếu bạn muốn thời gian chuẩn bị ngắn hơn mà không thuê thêm, hãy giảm WIP. Có ít việc đang bay có nghĩa là mỗi việc hoàn thành nhanh hơn.

R = (W × C) + T

Giới hạn WIP bảo vệ ba biến. Nhà tư vấn hiệu suất Brian Tracy đặt tên cho chúng năm 1986.

R = (W × C) + T

- R: Kết quả: kết quả bạn muốn

- W: Độ rõ ràng của mục tiêu: bạn biết rõ điều gì bạn muốn (0-10)

- C: Nhu cầu tập trung: cường độ nỗ lực tập trung (0-10)

- T: Thời gian làm việc không bị phân tâm (giờ không bị gián đoạn)

Tại sao W & C nhân với nhau

Độ rõ ràng và sự tập trung không độc lập. Sự tập trung cao độ trên một mục tiêu không rõ ràng sẽ tạo ra sự di chuyển nhanh chóng trong hướng sai. Mục tiêu rõ ràng với không có sự tập trung sẽ không tạo ra điều gì. Chúng tương tác: vì vậy Tracy đã viết chúng dưới dạng sản phẩm, không phải là tổng. Một 9/10 trên mỗi biến sẽ cho R = 81 + T. Một 3/10 trên mỗi biến sẽ cho R = 9 + T. Sự khác biệt không tăng tuyến tính.

Tại sao T cộng thêm

Mỗi giờ không bị phân tâm sẽ cộng thẳng vào kết quả. T không thể nhân với W & C: nó chỉ có thể chồng lên trên sản phẩm. Điều này giải thích tại sao bước đầu tiên luôn là cải thiện W & C, không phải là làm thêm giờ. T nhiều hơn trên một sản phẩm thấp (W × C) vẫn là một kết quả kém.

Bảng kanban làm gì với mỗi biến

- W: Một thẻ có yêu cầu đầy đủ (tiêu đề rõ ràng, tiêu chí chấp nhận đo lường, chủ sở hữu duy nhất) nâng cao W trước khi bắt đầu công việc. Các thẻ không rõ ràng tự động giảm W.

- C: Giới hạn WIP thúc đẩy sự tập trung. Một thẻ trong cột Active có nghĩa là chú trọng toàn bộ vào một vấn đề. Ba thẻ trong cột Active có nghĩa là C được chia ba.

- T: Các khối Pomodoro & bảo vệ lịch tạo ra giờ không bị phân tâm mà T đo lường. Timer bảng là không phải là trang trí: nó theo dõi T trong thời gian thực.

Tracy tuyên bố bất kỳ vấn đề nào cũng có thể được giải quyết trong 30 phút khi W, C, & T được tối ưu hóa. Bảng Kanban là công cụ để tối ưu hóa tất cả ba đồng thời.

Đọc bảng

Thực hành đọc nút cổ chai từ trạng thái bảng.

Không Agile. Không Waterfall.

Agile là một phương thức. Waterfall là một phương thức. Kanban là một hệ thống.

Phương thức quy định cách bạn làm việc. Hệ thống mô tả điều gì về công việc. Kanban không告诉bạnphải có hai tuần sprints, daily standups hoặc retrospectives. Nó告诉bạnmột điều: làm công việc rõ ràng, giới hạn WIP và pull.

Sự vấn đề với các phương thức

Agile phù hợp với các đội xây dựng sản phẩm theo từng bước lặp lại, phần mềm, chủ yếu. Waterfall phù hợp với các dự án có yêu cầu cố định & những điều không biết biết trước, xây dựng, sản xuất phần cứng. Không có cách nào ánh xạ một cách rõ ràng vào công việc xuyên ngành nơi một nhiệm vụ thiết kế & một nhiệm vụ thực hiện có chu kỳ thời gian & định nghĩa 'hoàn thành' khác biệt.

Làm bắt buộc một trung tâm thiết kế & một trung tâm hoạt động vào cùng một chu kỳ sprint là một lỗi phân loại. Một sprint hai tuần làm việc cho tạo nội dung tạo sự cấp bách giả trong công việc logistics. Một nghi thức đứng dậy được xây dựng cho các đội cùng địa điểm tạo ra chi phí phụ trội cho các solo độc lập.

Tìm điểm chung về công việc cần làm

Phương pháp không của un: tìm ra công việc cần làm. Tìm người hoặc đối tác tốt nhất để thực hiện nó. Không áp đặt một quy trình trên đó: hãy để công việc hiện ra quy trình của nó thông qua một hệ thống hiển thị chung.

Điều này không phải là sự thiếu hụt quy trình. Đây là lượng quy trình đúng: đủ để điều phối, không đủ để tạo ra chi phí điều phối vượt quá giá trị của công việc.

Không xây dựng những thứ bạn có thể mua. Không mua những thứ bạn có thể phát triển.

Trước khi tạo bất kỳ thẻ công việc nào, hãy hỏi: điều này có tồn tại không? Mỗi mảnh công việc bạn xây dựng, bạn sở hữu mãi mãi. Mỗi SaaS bạn đăng ký, bạn phụ thuộc mãi mãi. Mỗi phụ thuộc nguồn mở bạn fork, bạn duy trì mãi mãi.

Cây quyết định: Chúng ta có thể phát triển điều này không? Một quy trình, một kỹ năng, một mối quan hệ sản xuất khả năng bền vững, ưu tiên điều này. Nếu phát triển không khả thi: Chúng ta có thể mua điều này không? Một công cụ sẵn có giải quyết 80% vấn đề mà không cần công việc tùy chỉnh, ưu tiên điều này. Nếu mua không khả thi: Xây dựng nó. Và xây dựng nó với sự hiểu biết rằng bạn đang sở hữu nó.

Hầu hết các tổ chức đảo ngược thứ tự này. Họ xây dựng cơ sở hạ tầng tùy chỉnh cho các vấn đề mà các công cụ thương phẩm giải quyết tốt, sau đó vội vàng duy trì những gì họ xây dựng. Kanban làm điều này rõ ràng: mỗi thẻ trong Backlog của bạn là một điều bạn đã chọn xây dựng. Câu hỏi chân thành là liệu nó có nên có mặt không.

Build / Buy / Grow

Áp dụng khung quyết định.

Thiết kế bảng

Gắn kết lại. Bạn sẽ thiết kế một hệ thống kanban cho một kịch bản xuyên chức năng cụ thể.

Kịch bản

Một studio nhỏ đang relaunch sản phẩm của họ với một thương hiệu mới. Việc làm này bao gồm bốn trung tâm:

- Thiết kế: logo mới, nhận dạng hình ảnh, ảnh sản phẩm, bố cục trang

- Nội dung: mô tả sản phẩm mới viết lại, bản copy trang landing, email thông báo

- Xây dựng: website được cập nhật, luồng checkout mới, chuyển hướng từ các URL cũ

- Ops: thiết lập lại nhà cung cấp thanh toán, briefing đối tác xử lý đơn hàng, cấu hình lại phân tích

Relaunch có một hạn chót cứng nhắc: một hội chợ thương mại trong 45 ngày khi thương hiệu mới được công bố.

Solos Trở thành Silos

Trong hầu hết các tổ chức, kanban tồn tại để làm công việc rõ ràng trên một hệ thống quản lý. Người quản lý điều phối giữa các silo. Kanban giảm bớt chi phí điều phối.

Trong mô hình un, không có người quản lý. Có solo. Một solo vận hành một doanh nghiệp độc lập: một nhà thiết kế solo, một nhà xây dựng solo, một nhà viết solo, một solo vận hành. Mỗi solo, theo định nghĩa, là một silo. Không có bảng tổ chức kết nối chúng. Không có mối quan hệ báo cáo. Không có người quản lý để ép buộc điều phối.

Kanban trở thành lớp điều phối. Không bằng cách làm phẳng silos, solo vẫn độc lập hoàn toàn, nhưng bằng cách làm rõ và rõ ràng các chuyển giao giữa chúng. Một solo không gửi email hoặc lên lịch cuộc họp để chuyển giao công việc. Chúng tôi đặt một thẻ trên bảng chung. Solo nhận rút nó ra khi họ có khả năng.

Điều này giải thích lý do tại sao kanban phù hợp với mô hình un hơn là agile hoặc waterfall: nó không cần một nhịp điệu chung, không cần các cuộc họp retrospectives, không cần lập kế hoạch đồng bộ. Mỗi solo đặt giới hạn WIP của họ, họ own cycle time, họ own definition của họ. Điều phối xảy ra ở mức thẻ, không ở mức quy trình.