Чому Kanban працює - і як дізнатися, чи ваша команда готова

Більшість команд приймають Kanban, тому що хтось читав пост блогу. Розумніше питання - чи насправді проблеми, які вирішує Kanban, є проблемами, які має ваша команда.

Є момент, який визнає більшість команд, як правило, близько часу, коли у них більше восьми-дев'яти людей. Робота виконується - надсилаються електронні листи, функції поставляються, клієнти керуються - але ніхто не має чіткого розуміння того, над чим кожен інший працює. Проекти накопичуються. Речі обіцяються та потім безтихо забуваються. Ви витрачаєте двадцять хвилин перед кожною зустріччю, намагаючись дізнатися, де насправді перебуває робота. Відповідь, зазвичай, - "десь."

Це проблема, яку Kanban було розроблено для вирішення. Не проблема встановлення стратегії, наймання правильних людей або побудови культури - але конкретна, мелька, операційна проблема знання, над чим працює ваша команда й що перешкоджає шляху.

Це дивовижно скромний інструмент для чогось, що привернув стільки уваги. Kanban не претендує на виправлення вашої організації. Це просто робить роботу видимою. І виявляється, що видимість, застосована послідовно, змінює видатне число речей, що йдуть вниз.

Де Kanban насправді прийшов

Слово японське - воно означає "знак" або "дошка" - і система була розроблена Toyota в кінці 1940-х років як спосіб управління запасами на їх заводах. Ідея була простою: замість виробництва деталей за встановленим графіком, завод виробляв їх лише тоді, коли нижчестояча станція сигналізувала, що їй вони потрібні. Фізична карта - канбан - подорожував назад по лінії як запит. Ніщо не було зроблено спекулятивно. Ніщо не накопилося непотрібно.

Розуміння, яке мало Toyota, і яке згодом запозичили команди програмного забезпечення, полягає в тому, що більшість неефективності в системі походить не від людей, які працюють занадто повільно, а від неправильної роботи, яка виконується в неправильний час. Занадто багато речей розпочато одночасно. Вузькі місця, які ніхто не помічає, поки не стане занадто пізно. Робота, яка завершена в одному місці, тоді як наступний крок перевтомлений де-небудь іще.

Розробники програмного забезпечення, особливо в компаніях на кшталт Microsoft на початку 2000-х років, почали адаптувати ці ідеї для роботи зі знаннями. Карти стали завданнями. Станції заводів стали етапами в робочому процесі. А дошка стала дошкою - спочатку фізичною, потім цифровою - де будь-хто в команді міг миттєво побачити, що сталося в процесі, що очікувало, й що зроблено.

Що дошка Kanban насправді показує вам

Базова дошка Kanban має три колони: До виконання, В процесі, Готово. Цього достатньо для багатьох малих команд і хорошого місця для початку. Але справжня цінність з'являється, коли ви починаєте налаштовувати ці етапи, щоб відповідати тому, як ваша робота насправді текує - а не як ви бажаєте, щоб вона текла.

Команда контенту може використовувати: Ідея, Завдання, В проекті, На розгляді, Заплановано, Опубліковано. Команда програмного забезпечення може розділити "В процесі" на окремі колони для розробки, перевірки коду та тестування. Консалтингова команда може відстежувати Дослідження, Пропозицію, Активно, Очікування клієнта, Закрито. Етапи повинні відображати реальні передачі й реальні часи очікування - місця, де робота змінює руки, або де вона сидить, поки щось ще не відбудеться.

Помітьте карту в середній колоні - звіт про аудит складу, вісім днів, позначений як блокований. У системі без дошки це завдання могло б сидіти ще два тижні, перш ніж хто-небудь усвідомить, що вона не рухається. Хтось чекає на третю сторону. Або потрібне рішення від менеджера, який не знає, що він блокуючий. Дошка робить блокування видимим. Це більшість роботи.

Правило, яке робить це роботою: Обмеження WIP

Якщо є один концепт, який розділяє команди, які належно використовують Kanban, від команд, які просто мають красивіший список дел, це обмеження роботи в процесі - скорочено WIP. Ідея полягає в тому, що кожна колона має максимальну кількість елементів, яка дозволяється там одночасно. Коли колона повна, ви не можете додавати більше роботи, поки щось не переміститься.

Це здається контринтуїтивним. Безумовно, можливість поставити більше завдань в процес означає, що більше виконується? Це не так. Те, що насправді трапляється, коли люди працюють на занадто багато речей одночасно, це те, що все займає довше. Перемикання контексту дорого. Незавершена робота створює координаційні навантаження. І коли десять речей "в процесі", дуже важко сказати, які насправді рухаються, а які просто застрягли, але не позначені.

Обмеження WIP на три в вашій колоні "В процесі" означає, що коли четверте завдання прибуває на стіл когось, хтось у команді повинен прийняти рішення: яке існуюче завдання завершується першим? Це змушує пріоритизацію. Це змушує розмову. І це як правило призводить до швидшого завершення окремих елементів, навіть якщо темп початку нових елементів сповільнюється.

Kanban проти Scrum: запитання, яке команди завжди задають

Якщо ви витратили якийсь час навколо команд програмного забезпечення або сучасного операційного мислення, ви, мабуть, зіткнулися з Scrum - фреймворком, який організує роботу в фіксовані двотижневі спринти, із планування сеансів, ретроспектив, і визначені ролі, як Scrum Master і Product Owner. Багато команд ставляться до Scrum і Kanban як конкуруючих методологій і відчувають, що вони повинні вибирати. Розрізнення насправді простіше, ніж те.

Kanban вам підходить, якщо робота прибуває непередбачувано або безперервно, різні завдання мають дуже різні розміри, ваша команда охоплює множину функцій, ви хочете почати легко й розвивати процес, швидкість окремих елементів найбільше важлива.

Scrum вам підходить, якщо робота може бути заплановано в фіксовані партії, ваша команда в основному зосереджена на інженерії, передбачувальний ритм доставки - пріоритет, у вас є здатність до адміністрування процесу, зацікавлені сторони потребують регулярних структурованих оновлень.

Багато команд - особливо ті, які не є командами чистого програмного забезпечення - вважають церемонії Scrum важкими й фіксовану структуру спринту незручною застосовувати до постійної операційної роботи. Команди маркетингу, команди успіху клієнтів, операційні команди й засновники, що керують всім, рідко мають роботу, яка охайно вписується в двотижневі цикли. Модель безперервного потоку Kanban як правило їм краще підходить.

Це сказано, багато команд поєднують обидва. Вони використовують цикли планування в стилі спринту для розвитку продукту, в той час як запускають дошку Kanban для операційної та підтримуючої роботи, яка тече незалежно від того, якому спринту ви перебуває. Це абсолютно розумний гібрид.

Три запитання, на які ваша дошка повинна відповісти за тридцять секунд

Дошка Kanban найбільш корисна, коли ви можете подивитися на неї й, не розмовляючи з кимось, швидко відповісти на ці три запитання: На чому команда працює зараз? Де робота застрягає? Є щось, що повинно бути виконано, яке не розпочато?

Якщо ви не можете швидко відповісти на всі три протягом тридцяти секунд подивитися на дошку, вона, ймовірно, не належно обслуговується. Найчастіший режим відмови - дошка, де завдання створено, але ніколи не перемісцено - вона стає цвинтарем добрих намірів, а не живою картою справжньої роботи. Дошка, яка не поточна, гірша, ніж ніякої дошки, тому що вона створює хибне почуття видимості.

Дисципліна, необхідна для утримання дошки, реальна. Завдання повинні рухатися, коли рухається робота. Блоковані елементи повинні бути позначені в момент, коли вони зупиняються, а не два тижні потім. Карти повинні мати чітких власників, й власники повинні оновлювати свої карти. Ніщо з цього не вимагає багато часу - добре запущена практика Kanban може займати п'ять-десять хвилин на людину в день - але вона вимагає послідовності. Команди, які найбільше отримують користь від Kanban, - це ті, які розглядають дошку як джерело істини, а не як додаткову вправу в ведення записів.

Що Kanban не робить

Kanban не є інструментом стратегії. Це не допоможе вам дізнатися, над чим працювати - лише допоможе керувати тим, на чому ви вже вирішили працювати. Якщо у вашій організації є проблема пріоритизації, або проблема невизначеного мандата, або проблема "ми починаємо занадто багато проектів перед завершенням старих", вкорінена в поведінці керівництва, а не в процесі, дошка Kanban розкриє ці проблеми, але не вирішить їх.

Це також не замінення для хорошого управління. Дошка не замінює один-на-один, продумане делегування або чіткої комунікації про те, чому певна робота важливо. Команди іноді приймають інструменти процесу, сподіваючись, що процес буде робити реляційну й організаційну роботу, яка насправді є роботою менеджера. Це не буде.

Те, що це буде робити, це зменшити навколишній неоднозначність, що сповільнює більшість команд. Питання "хто працює над чим", "це зроблено" й "що я повинен взяти дальше" генерують величезні суми низьковартісного спілкування в організаціях, які не мають спільної, видимої системи. Kanban усуває більшість цього шуму. І для команд, де цей шум - домінуючу проблему, різниця є значною.

Як почати - без трирічної майстер-класу

Найкращі реалізації Kanban, які я бачив, розпочались малі й розвивались. Найгірші включали консультанта, дводенний виїзд та красиво розроблену дошку, яку ніхто не використовував до третього тижня.

Почніть з вашою командою, як вона насправді є, з роботою, яку ви насправді маєте. Створіть три колони: Невиконане, В процесі, Готово. Витратьте тридцять хвилин з вашою командою, поставивши кожне поточне робочого елемента на карту. Погодьтеся на одне правило: коли ви щось починаєте, це йде на дошку. Коли це рухається, ви рухаєте карту. Робіть більше нічого два тижні.

Після двох тижнів подивіться на дошку разом. Де речі накопилися? Що залишалось у Невиконаному, про що всі говорили, що це пріоритет? Що рухалось швидше, ніж очікувалось? Що застрягло й чому? Використовуйте те, що ви спостерігаєте, для удосконалення колон й додавання конкретності. Можливо, "В процесі" повинна розділитися на "В процесі" й "Очікування Зовнішньої". Можливо, вам потрібна колона під назвою "На розгляді", тому що цей крок постійно втрачається. Дозвольте дошці розвиватися в відповідь на те, що ваша справжня робота розкриває, а не на те, що книга методології говорить вона повинна виглядати.

Довша гра: метрики потоку

Після запущення системи Kanban вона генерує дані, які більшість команд ніколи не використовує. Час свинцю - загальний час від створення завдання до його завершення - найбільше важливо. Якщо ваш середній час свинцю для типового завдання - дванадцять днів, й ви хочете, щоб це було п'ять, у вас тепер є число для роботи й дошка, яка покаже вам, де ці сім додаткових днів йдуть.

Час циклу вимірює лише активний період роботи, виключаючи час, коли завдання сидить у Невиконаному. Пропускна спроможність вимірює, скільки елементів ваша команда завершує за тиждень. Жодна з цих метрик не вимагає спеціального програмного забезпечення, якщо ви дисциплінуйтесь примітити коли карти створено й коли вони закриваються. І разом, вони дають вам набагато чесніший образ здатності вашої команди, ніж будь-який процес планування, заснований на оцінках, може.

Більшість малих і середніх команд ніколи не потрапляють сюди. Вони використовують Kanban як інструмент видимості - який цінний сам по собі - й не йдуть далі. Це добре. Але якщо ви виявляєте себе, бажаючи зробити зобов'язання перед зацікавленими сторонами про те, коли щось буде виконано, або хочуть зрозуміти, чому деяка робота займає в три рази довше, ніж очікувалось, метрики там, коли вам вони потрібні.