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

Більшість команд беруть Kanban, бо хтось прочитав допис у блозі. Розумніше запитання: чи справді проблеми, які розв'язує Kanban, — це проблеми вашої команди.

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

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

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

Звідки насправді з'явився Kanban

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

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

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

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

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

Контент-команда може використовувати: «Ідея», «Бриф», «Чернетка», «На перевірці», «Заплановано», «Опубліковано». Команда розробників може розбити «У роботі» на окремі колонки для розробки, код-рев'ю та QA. Консалтингова команда може відстежувати «Дослідження», «Пропозиція», «Активно», «Очікуємо клієнта» та «Закрито». Етапи мають відображати реальні передачі та реальні часи очікування, тобто місця, де робота переходить з рук у руки або де вона лежить, доки не станеться щось інше.

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

Правило, що змушує це працювати: ліміти WIP

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

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

Ліміт WIP, що дорівнює трьом у колонці «У роботі», означає, що коли четверта річ потрапляє комусь на стіл, хтось у команді мусить ухвалити рішення: яке з наявних завдань завершити першим? Це змушує пріоритезувати. Це змушує говорити. І це, як правило, призводить до швидшого завершення окремих елементів, навіть якщо темп старту нових сповільнюється.

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

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

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

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

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

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

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

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

Чого Kanban не робить

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

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

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

Як почати без триденного воркшопу

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

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

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

Погляд у довшій перспективі: метрики потоку

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

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

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