Колони як стани

Дошка канбану робить роботу видимою. Кожна робота — карта. Карти рухаються ліворуч направо через колони, які представляють стани.

Класичні колони: Невиконане → Обрано → В процесі → Рецензування → Готово

Але точні колони не мають значення. Що має значення — що кожна карта має рівно один поточний стан, & цей стан видимий для кожного, хто працює в цій системі.

Що представляє карта

Карта представляє одиницю роботи, яка може бути незалежно завершена. Не проект. Не мета. Конкретна, обмежена річ із чітким визначенням готово.

Хорошої карта: Ротацію SSH-ключів на prod-серверах: готово, коли всі сервери показують новий ключ в authorized_keys & старий ключ видалено.

Погана карта: Покращити безпеку. (Це проект, не завдання. Розбийте його.)

Обмеження WIP

Колона В процесі на діаграмі показує обмеження WIP: 3. Це означає, що одночасно можуть бути В процесі не більше трьох карт. Якщо ви хочете витягнути четверту карту, ви повинні спершу завершити одну.

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

Визначення обсягу карт роботи

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

Силосу працюють добре

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

Канбан не розчиняє ці поділи. Це робить передачу між ними видимою & явною.

Карта передачі

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

Що показує діаграма

Квиток ★ починається в Дизайні (В процесі: візуальні активи). Коли Дизайн завершує свою частину, карта передачі створюється & квиток ★ з'являється в Невиконаному конструктора центру. Конструктор витягує це. Тоді Експлуатація витягує це. Кожен центр має свою дошку. Кожна дошка показує тільки поточну роботу цього центру. Але ★ подорожує через всіх них, & кожен може бачити, де це.

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

Проектування передачі

Карта передачі — це договір між робочими центрами. Вона повинна містити достатньо контексту для отримуючої команди, щоб діяти без зустрічі.

Припиніть почати. Почніть закінчувати.

WIP означає Роботу В процесі. Обмеження WIP — це верхня межа, на скільки карт може бути в даній колоні одночасно.

Це звучить як обмеження. Це є. Це сенс.

Чому обмеження допомагають

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

Обмеження WIP запобігають накопленню недоробленої роботи. Вони також роблять щось більше цінне: вони поверхневі вузькі місця.

Вузькі місця стають видимими

Якщо колона Рецензування має обмеження WIP 2 & вона завжди на 2, це сигнал: рецензування повільніше за виробництво. Більше роботи завершується В процесі, ніж може бути спожито Рецензуванням. Без обмеження WIP, дошка заповнює «готово-але-чекає-рецензування» карти & вузьке місце невидимо. З обмеженням WIP, колона В процесі не може прийняти нові карти, & вся команда бачить обмеження.

Це не провал. Це інформація. Система говорить вам, що потрібно виправити Рецензування, найняти, сполучити, зменшити розмір партії, замість того щоб сліпо штовхати більше роботи через.

Закон Літла (неофіційно)

Час розроблення (скільки часу карта займає від початку до готово) = Роботу В процесі ÷ Пропускна спроможність (карти завершені за одиницю часу). Якщо ви хочете коротшого часу розроблення без найму, зменшіть WIP. Менше речей у польоті означає, що кожна річ швидше завершується.

R = (W × C) + T

Обмеження WIP захищають три змінні. Консультант з ефективності Браян Трейсі назвав їх у 1986 році.

R = (W × C) + T

- R: Результат: результат, який ви хочете

- W: Ясність цілі: як точно ви знаєте, що хочете (0–10)

- C: Концентрація: інтенсивність зосередженої роботи (0–10)

- T: Час, відпрацьований без відволікання (неперервні години)

Чому W & C множаться

Ясність & концентрація не незалежні. Висока концентрація на розпливчатій цілі виробляє швидкий рух у неправильному напрямку. Досконала ясність цілі без концентрації виробляє нічого. Вони взаємодіють: тому Трейсі написав їх як продукт, а не суму. 9/10 на кожному дає R = 81 + T. 3/10 на кожному дає R = 9 + T. Різниця не адитивна.

Чому T додає

Кожна година без відволікання додає лінійно до результату. T не може компонувати W & C: вона може тільки стосуватися верху продукту. Це пояснює, чому перший хід завжди вдосконалювати W & C, а не працювати довше годинами. Більше T на низькому (W × C) продукті все ще поганий результат.

Що дошка канбану робить до кожної змінної

- W: Добре визначена карта (чіткий заголовок, вимірювальні критерії прийняття, один власник) підвищує W перед тим, як робота починається. Розпливчаті карти автоматично знижують його.

- C: Обмеження WIP змушують концентрацію. Одна карта в Активна означає повна увага на одну проблему. Три карти в Активна означає, що C розділена на три способи.

- T: Pomodoro блоки & захист календаря створюють години без відволікання, які T вимірює. Таймер дошки — не декорація: він відстежує T в реальному часі.

Трейсі стверджував, що будь-яка проблема може бути вирішена за 30 хвилин, коли W, C, & T всі оптимізовані. Дошка канбану — це інструмент для оптимізації всіх трьох одночасно.

Читання дошки

Практика читання вузьких місць зі стану дошки.

Не Agile. Не Waterfall.

Agile — це методологія. Waterfall — це методологія. Канбан — це система.

Методології приписують, як ви працюєте. Системи описують те, що правда про роботу. Канбан не говорить вам мати двотижневі спринти, щоденні синхронізаціїs, чи ретроспективи. Він розповідає вам одне: зробити роботу видимою, обмежити WIP, & витягувати.

Проблема з методологіями

Agile добре працює для команд, які будують продукти ітеративно, програмне забезпечення, здебільшого. Waterfall добре працює для проектів із встановленими вимогами & відомими невідомими, будівництво, апаратне забезпечення. Жодна карта не чисто на роботу з кількома дисциплінами, де дизайнерське завдання & завдання виконання мають абсолютно різні часові цикли & визначення «готово».

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

Знайти спільний ґрунт на роботі, яка повинна бути зроблена

Підхід un: знайти роботу, яка повинна бути зроблена. Знайти людей чи партнерів, найкраще позиціонованих, щоб це зробити. Не накладайте процес на те: дозвольте роботі поверхневій власний процес через систему спільної видимості.

Це не відсутність процесу. Це правильна кількість процесу: достатньо, щоб координувати, недостатньо, щоб створити накладні видатки координації, що перевищує значення роботи.

Не будуйте, що ви можете купити. Не купуйте, що ви можете розвивати.

Перш ніж буде створена будь-яка карта роботи, запитайте: чи повинна це існувати взагалі? Кожен шматок роботи, який ви будуєте, ви володієте назавжди. Кожен SaaS, на який ви підписуєтеся, ви залежите назавжди. Кожне відкрите джерело залежності, яку ви форкуєте, ви обслуговуєте назавжди.

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

Більшість організацій це інвертують. Вони будують спеціальну інфраструктуру для проблем, які товарні інструменти добре вирішують, потім борються за підтримання того, що вони побудували. Канбан це робить видимим: кожна карта в вашому Невиконаному — це річ, яку ви вибрали побудувати. Чесне питання — чи повинно це бути там взагалі.

Побудувати / Купити / Розвивати

Застосувати фреймворк рішень.

Проектування дошки

Зберіть все разом. Ви проектуватимете систему канбану для конкретного сценарію з кількома дисциплінами.

Сценарій

Маленька студія перепускає свій продукт з новим брендом. Робота включає чотири центри:

- Дизайн: нове логотип, візуальна ідентичність, фотографія продуктів, макети сторінок

- Вміст: переписана опис продуктів, копія цільової сторінки, оголошення електронної пошти

- Побудова: оновлений веб-сайт, новий потік касси, перенаправлення зі старих URL

- Експлуатація: оновлені налаштування процесора платежів, брифінг партнера виконання, переконфігурація аналітики

Перепуск має твердий термін: торгова виставка за 45 днів, де новий бренд виходить на публіку.

Соло залишаються силосами

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

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

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

Це пояснює, чому канбан підходить моделі un краще, ніж agile чи waterfall: він не потребує спільного темпу, спільних retro, синхронізованого планування. Кожне соло встановлює свої обмеження WIP, свій цикл часу, своє визначення готово. Координація відбувається на рівні карти, не на рівні процесу.