From Wikipedia, the free encyclopedia
This article is about the process-management and improvement method. For the lean-manufacturing process, see Kanban.
Kanban (Japanese: 看板, meaning signboard or billboard) is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.
Work items are visualized to give participants a view of progress and process, from start to finish—usually via a kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested.
In knowledge work and in software development, the aim is to provide a visual process management system which aids decision-making about what, when, and how much to produce. The underlying kanban method originated in lean manufacturing,[1] which was inspired by the Toyota Production System.[2] It has its origin in the late 1940s when the Toyota automotive company implemented a production system called just-in-time; which had the objective of producing according to customer demand and identifying possible material shortages within the production line. But it was Microsoft engineer David J. Anderson who realized how this method devised by Toyota could become a process applicable to any type of organizational process. Kanban is commonly used in software development in combination with other methods and frameworks such as Scrum.[3]
Kanban boards[edit]
The diagram here shows a software development workflow on a kanban board.[4]
Kanban boards, designed for the context in which they are used, vary considerably and may show work item types («features» and «user stories» here), columns delineating workflow activities, explicit policies, and swimlanes (rows crossing several columns, used for grouping user stories by feature here). The aim is to make the general workflow and the progress of individual items clear to participants and stakeholders.
As described in books on kanban for software development,[5][3] the two primary practices of kanban are to visualize work and limit work in progress (WIP). Four additional general practices of kanban listed in Essential Kanban Condensed are to make policies explicit, manage flow, implement feedback loops, and improve collaboratively.[6]
The kanban board in the diagram above highlights the first three general practices of kanban.
- It visualizes the work of the development team (the features and user stories).
- It captures WIP limits for development steps: the circled values below the column headings that limit the number of work items under that step.
- It documents policies, also known as done rules,[7] inside blue rectangles under some of the development steps.
- It also shows some kanban flow management for the «user story preparation», «user story development», and «feature acceptance» steps, which have «in progress» and «ready» sub-columns. Each step’s WIP limit applies to both sub-columns, preventing work items from overwhelming the flow into or out of those steps.
Managing workflow[edit]
Kanban manages workflow directly on the kanban board. The WIP limits for development steps provide development teams immediate feedback on common workflow issues.[5][7]
For example, on the kanban board shown above, the «deployment» step has a WIP limit of five and there are currently five epics[clarification needed] shown in that step. No more work items can move into deployment until one or more epics complete that step (moving to «delivered»). This prevents the «deployment» step from being overwhelmed. Team members working on «feature acceptance» (the previous step) might get stuck because they can’t deploy new epics. They can see why immediately on the board and help with the current epic deployments.
Once the five epics in the «deployment» step are delivered, the two epics from the «ready» sub-column of «feature acceptance» (the previous step) can be moved to the «deployment» column. When those two epics are delivered, no other epics can be deployed (assuming no new epics are ready). Now, team members working on deployment are stuck. They can see why immediately and help with feature acceptance.
This workflow control works similarly for every step. Problems are visual and evident immediately, and re-planning can be done continuously. The work management is made possible by limiting work in progress in a way team members can see and track at all times.
Evolution and documentation of method[edit]
David Anderson’s 2010 book, Kanban,[5] describes an evolution of the approach from a 2004 project at Microsoft[8] using a theory-of-constraints approach and incorporating a drum-buffer-rope (comparable to the kanban pull system), to a 2006–2007 project at Corbis in which the kanban method was[by whom?] identified. In 2009, Don Reinertsen published a book on second-generation lean product-development[9] which describes the adoption of the kanban system and the use of data collection and an economic model for management decision-making. Another early contribution came from Corey Ladas, whose 2008 book Scrumban[3] suggested that kanban could improve scrum for software development. Ladas saw scrumban as the transition from scrum to kanban. Jim Benson and Tonianne DeMaria Barry published Personal Kanban,[10] applying kanban to individuals and small teams, in 2011. In Kanban from the Inside (2014),[11] Mike Burrows explained kanban’s principles, practices and underlying values and related them to earlier theories and models. In Agile Project Management with Kanban (2015),[7] Eric Brechner provides an overview of kanban in practice at Microsoft and Xbox. Kanban Change Leadership (2015), by Klaus Leopold and Siegfried Kaltenecker,[12] explained the method from the perspective of change management and provided guidance to change-initiatives. In 2016 Lean Kanban University Press published a condensed guide to the method, incorporating improvements and extensions from the early kanban projects.[6]
See also[edit]
- List of software development philosophies
References[edit]
- ^ Womack, James P. (2007). The Machine That Changed the World. ISBN 978-1847370556.
- ^ Ohno, Taiichi (1988). Toyota Production System: Beyond Large-Scale Production. ISBN 978-0915299140.
- ^ a b c Corey, Ladas (2008). Scrumban and other essays on Kanban System for Lean Software development. Seattle, Washington: Modus Cooperandi Press. ISBN 9780578002149. OCLC 654393465.
- ^ Boeg, Jasper (February 2012). «Priming Kanban». InfoQ. Retrieved 17 February 2014.
- ^ a b c Anderson, David J. (April 2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. ISBN 978-0-9845214-0-1.
- ^ a b Anderson, David J.; Carmichael, Andy (2016). Essential Kanban Condensed. Seattle, WA: Lean Kanban University Press. ISBN 978-0-9845214-2-5.
- ^ a b c Brechner, Eric (2015). Agile Project Management with Kanban. Microsoft Press. p. 160. ISBN 978-0735698956.
- ^ Anderson, David J.; Dumitriu, Dragos (November 2005). From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution at Microsoft’s IT Department (PDF). TOC ICO World Conference November 2005. USA: Microsoft Corporation. Retrieved 24 September 2020.
- ^ Reinertsen, Donald (May 2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing. ISBN 978-1935401001.
- ^ Benson, Jim; DeMaria Barry, Tonianne (January 2011). Personal Kanban: Mapping Work, Navigating Life. Modus Cooperandi Press. ISBN 978-1453802267.
- ^ Burrows, Mike (2014). Kanban From The Inside. Seattle, WA: Blue Hole Press. ISBN 978-0-9853051-9-2.
- ^ Leopold, Klaus; Siegfried, Kaltenecker (2015). Kanban Change Leadership. Hoboken, NJ: John Wiley & Sons. ISBN 978-1-119-01970-1.
Further reading[edit]
- Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson. (United States, Blue Hole Press, 2010. ISBN 978-0984521401
- Scrumban: Essays on Kanban Systems for Lean Software Development, Corey Ladas. (United States, Modus Cooperandi Press, 2009. ISBN 9780578002149
- Agile Project Management with Kanban (Developer Best Practices), Eric Brechner. (United States: Microsoft Press, 2015). ISBN 978-0735698956.
- Kanban in Action, Marcus Hammarberg and Joakim Sunden. (Shelter Island, NY: Manning Publications, 2014). ISBN 978-1-617291-05-0.
- Lean from the Trenches: Managing Large-Scale Projects with Kanban, Henrik Kniberg. (Dallas, TX: The Pragmatic Programmers, 2012). ISBN 978-1-93435-685-2.
- Stop Starting, Start Finishing! Arne Roock and Claudia Leschik. (USA: Lean-Kanban University, 2012). ISBN 978-0985305161.
- Real-World Kanban: Do Less, Accomplish More with Lean Thinking, Mattias Skarin. (United States: Pragmatic Bookshelf, 2015). ISBN 978-1680500776.
From Wikipedia, the free encyclopedia
This article is about the process-management and improvement method. For the lean-manufacturing process, see Kanban.
Kanban (Japanese: 看板, meaning signboard or billboard) is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.
Work items are visualized to give participants a view of progress and process, from start to finish—usually via a kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested.
In knowledge work and in software development, the aim is to provide a visual process management system which aids decision-making about what, when, and how much to produce. The underlying kanban method originated in lean manufacturing,[1] which was inspired by the Toyota Production System.[2] It has its origin in the late 1940s when the Toyota automotive company implemented a production system called just-in-time; which had the objective of producing according to customer demand and identifying possible material shortages within the production line. But it was Microsoft engineer David J. Anderson who realized how this method devised by Toyota could become a process applicable to any type of organizational process. Kanban is commonly used in software development in combination with other methods and frameworks such as Scrum.[3]
Kanban boards[edit]
The diagram here shows a software development workflow on a kanban board.[4]
Kanban boards, designed for the context in which they are used, vary considerably and may show work item types («features» and «user stories» here), columns delineating workflow activities, explicit policies, and swimlanes (rows crossing several columns, used for grouping user stories by feature here). The aim is to make the general workflow and the progress of individual items clear to participants and stakeholders.
As described in books on kanban for software development,[5][3] the two primary practices of kanban are to visualize work and limit work in progress (WIP). Four additional general practices of kanban listed in Essential Kanban Condensed are to make policies explicit, manage flow, implement feedback loops, and improve collaboratively.[6]
The kanban board in the diagram above highlights the first three general practices of kanban.
- It visualizes the work of the development team (the features and user stories).
- It captures WIP limits for development steps: the circled values below the column headings that limit the number of work items under that step.
- It documents policies, also known as done rules,[7] inside blue rectangles under some of the development steps.
- It also shows some kanban flow management for the «user story preparation», «user story development», and «feature acceptance» steps, which have «in progress» and «ready» sub-columns. Each step’s WIP limit applies to both sub-columns, preventing work items from overwhelming the flow into or out of those steps.
Managing workflow[edit]
Kanban manages workflow directly on the kanban board. The WIP limits for development steps provide development teams immediate feedback on common workflow issues.[5][7]
For example, on the kanban board shown above, the «deployment» step has a WIP limit of five and there are currently five epics[clarification needed] shown in that step. No more work items can move into deployment until one or more epics complete that step (moving to «delivered»). This prevents the «deployment» step from being overwhelmed. Team members working on «feature acceptance» (the previous step) might get stuck because they can’t deploy new epics. They can see why immediately on the board and help with the current epic deployments.
Once the five epics in the «deployment» step are delivered, the two epics from the «ready» sub-column of «feature acceptance» (the previous step) can be moved to the «deployment» column. When those two epics are delivered, no other epics can be deployed (assuming no new epics are ready). Now, team members working on deployment are stuck. They can see why immediately and help with feature acceptance.
This workflow control works similarly for every step. Problems are visual and evident immediately, and re-planning can be done continuously. The work management is made possible by limiting work in progress in a way team members can see and track at all times.
Evolution and documentation of method[edit]
David Anderson’s 2010 book, Kanban,[5] describes an evolution of the approach from a 2004 project at Microsoft[8] using a theory-of-constraints approach and incorporating a drum-buffer-rope (comparable to the kanban pull system), to a 2006–2007 project at Corbis in which the kanban method was[by whom?] identified. In 2009, Don Reinertsen published a book on second-generation lean product-development[9] which describes the adoption of the kanban system and the use of data collection and an economic model for management decision-making. Another early contribution came from Corey Ladas, whose 2008 book Scrumban[3] suggested that kanban could improve scrum for software development. Ladas saw scrumban as the transition from scrum to kanban. Jim Benson and Tonianne DeMaria Barry published Personal Kanban,[10] applying kanban to individuals and small teams, in 2011. In Kanban from the Inside (2014),[11] Mike Burrows explained kanban’s principles, practices and underlying values and related them to earlier theories and models. In Agile Project Management with Kanban (2015),[7] Eric Brechner provides an overview of kanban in practice at Microsoft and Xbox. Kanban Change Leadership (2015), by Klaus Leopold and Siegfried Kaltenecker,[12] explained the method from the perspective of change management and provided guidance to change-initiatives. In 2016 Lean Kanban University Press published a condensed guide to the method, incorporating improvements and extensions from the early kanban projects.[6]
See also[edit]
- List of software development philosophies
References[edit]
- ^ Womack, James P. (2007). The Machine That Changed the World. ISBN 978-1847370556.
- ^ Ohno, Taiichi (1988). Toyota Production System: Beyond Large-Scale Production. ISBN 978-0915299140.
- ^ a b c Corey, Ladas (2008). Scrumban and other essays on Kanban System for Lean Software development. Seattle, Washington: Modus Cooperandi Press. ISBN 9780578002149. OCLC 654393465.
- ^ Boeg, Jasper (February 2012). «Priming Kanban». InfoQ. Retrieved 17 February 2014.
- ^ a b c Anderson, David J. (April 2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. ISBN 978-0-9845214-0-1.
- ^ a b Anderson, David J.; Carmichael, Andy (2016). Essential Kanban Condensed. Seattle, WA: Lean Kanban University Press. ISBN 978-0-9845214-2-5.
- ^ a b c Brechner, Eric (2015). Agile Project Management with Kanban. Microsoft Press. p. 160. ISBN 978-0735698956.
- ^ Anderson, David J.; Dumitriu, Dragos (November 2005). From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution at Microsoft’s IT Department (PDF). TOC ICO World Conference November 2005. USA: Microsoft Corporation. Retrieved 24 September 2020.
- ^ Reinertsen, Donald (May 2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing. ISBN 978-1935401001.
- ^ Benson, Jim; DeMaria Barry, Tonianne (January 2011). Personal Kanban: Mapping Work, Navigating Life. Modus Cooperandi Press. ISBN 978-1453802267.
- ^ Burrows, Mike (2014). Kanban From The Inside. Seattle, WA: Blue Hole Press. ISBN 978-0-9853051-9-2.
- ^ Leopold, Klaus; Siegfried, Kaltenecker (2015). Kanban Change Leadership. Hoboken, NJ: John Wiley & Sons. ISBN 978-1-119-01970-1.
Further reading[edit]
- Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson. (United States, Blue Hole Press, 2010. ISBN 978-0984521401
- Scrumban: Essays on Kanban Systems for Lean Software Development, Corey Ladas. (United States, Modus Cooperandi Press, 2009. ISBN 9780578002149
- Agile Project Management with Kanban (Developer Best Practices), Eric Brechner. (United States: Microsoft Press, 2015). ISBN 978-0735698956.
- Kanban in Action, Marcus Hammarberg and Joakim Sunden. (Shelter Island, NY: Manning Publications, 2014). ISBN 978-1-617291-05-0.
- Lean from the Trenches: Managing Large-Scale Projects with Kanban, Henrik Kniberg. (Dallas, TX: The Pragmatic Programmers, 2012). ISBN 978-1-93435-685-2.
- Stop Starting, Start Finishing! Arne Roock and Claudia Leschik. (USA: Lean-Kanban University, 2012). ISBN 978-0985305161.
- Real-World Kanban: Do Less, Accomplish More with Lean Thinking, Mattias Skarin. (United States: Pragmatic Bookshelf, 2015). ISBN 978-1680500776.
В бизнесе сейчас в моде такие понятия как “система управления проектами”, “бережливое производство”, “визуализация процесса работы”, “эффективное выполнение поставленных задач”.
Мы все знаем и понимаем их значения (хотя бы приблизительно), но мало кто знает, что всё это — множество частей одной системы. Системы, которая помогает компаниям работать сверхрезультативно. И называется она — канбан.
Система “Канбан” это и вправду очень сильный инструмент по управлению задачами на разных уровнях (даже в продажах).
И недаром её реализацию мы сейчас можем видеть в разных организациях и сервисах. Скорее всего Вы даже пользовались этим подходом, например в CRM-системах.
Для многих такие инструменты не относятся к маркетингу, но мы считаем наоборот. Ведь благодаря такому внедрению, компания может делать свою работу лучше и быстрее, а значит клиенты будут более лояльны. Они будут рекомендовать нас и покупать снова и снова. Но, как всегда, мы расскажем всё просто и понятно. Поэтому начнём с истоков, чтобы всё разложить по полочкам.
Что такое система канбан
Помните нашу статью про agile-методологию? Так вот, с появлением самого термина “agile” всё понятно.
А вот с возникновением “Канбан” не совсем. Я смог найти только то, что сам термин и само понятие было придумано инженерами компании Тойота в 1940-х годах и с тех пор они только и делают, что развивают его.
Самое интересное, что упоминается два варианта того, как была придумана концепция канбан.
Вариант 1. Каждый мастер на своём участке производства писал своим подчинённым задания на листке и вывешивал его на видном месте. Другие мастера участков делали то же самое и вывешивали задачи рядом.
Таким образом стало видно, что мастера поручают работникам, и при необходимости они стали давать советы друг другу для повышения работоспособности бригады (чтобы на одном участке не стало скапливаться большое число невыполненных задач).
Вариант 2. После открытия завода Тойота в Америке, инженеры начали путешествовать по стране.
Периодически они заезжали в супермаркеты для покупки продуктов. И настоящим инсайтом для них стало то, что товары на полках пополнялись не по мере того, как поставщик их привозил, а по мере того, как пустели полки.
То есть запасы привозились не когда было удобно поставщику, а когда запас достигал минимума.
Какой из этих вариантов правда — я не знаю. Лично мне нравится второй. Однако, в 1959 году корпорация Тойота стала использовать методы схожие с современной системой канбан.
А в 1962 полностью и довольно кардинально компания поменяла весь процесс работы на своих заводах. Но давайте пошагово.
Канбан в переводе обозначает “кан” — “видимый/визуальный”, а “бан” — “вывеска/доска”.
Единого определения у системы канбан нет. Поэтому я приведу две фразы, которые на мой взгляд максимально отражают суть:
- Система, направленная на уменьшение количества одновременно выполняемых задач;
- Система вытягивающего управления складскими запасами.
Помните историю про супермаркет? Так вот методика работы “just-in-time” (по английски, “точно в срок”) и есть основная суть системы канбан.
То есть нет смысла производить продукцию, если она ещё не продана. Это захламляет склады и рабочие места, а также увеличивает время ненужной работы (так как продукция может быть не продана).
Поэтому как только готовая продукция на складе подходит к концу, склад начинает “вытягивать” изготовление из производства.
Интересно. Сейчас существуют готовые сервисы, которые делают автоматический заказ у поставщиков, когда в наличии количество единиц продукта становится минимальным. Это особенно актуально для общепита и продуктовых магазинов.
Как это работает в Тойота
Как у любой нормальной компании, в Тойота ставится план продаж на год. Этот план разбивается на месяца.
В результате получается среднесуточный план выпуска автомобилей. Затем этот план берут продажники и начинают активно договариваться с дилерами о реализации их автомобилей.
В это время на заводе склад пишет карточку, сколько готовых автомобилей необходимо произвести.
Далее по каждому цеху (производства стёкол, панелей, колёс, запчастей и так далее) пишутся карточки, сколько необходимо выпустить единиц каждого наименования на данный момент времени.
При подходе готовых единиц, к концу выпускаются новые карточки с указанным числом новых необходимых деталей. И так далее.
Как видите, на протяжении всего процесса идёт использование карточек канбан, так их называют сейчас.
Таким образом соблюдается как раз 2 основных принципа. Количество задач уменьшается за счёт “вытягивания” управления складскими запасами.
Простым языком — всё делается ровным счётом тогда, когда это нужно. Действует закон приоритетов.
Основные принципы системы
Как и у любой методологии, у канбан есть принципы, на которых она была основана и успешно развивается.
Я отобрал для Вас всего 4 принципа, хотя в Интернете и книгах Вы можете встретить 7 и даже 10. Однако эти — наиболее понятны среднему человеку (который не живёт системами управления процессами).
1. Визуализация. Главный принцип канбан — это визуализация. Недаром используются и пишутся карточки канбан.
Ваша главная задача — сделать визуальную доску, которую Вы разобьёте по необходимым для Вас этапам и расположите задачу по стадии её развития. Классика жанра это 3 направления — планируется, выполняется и сделано.
2. Количество выполняемых задач. Большая проблема множества людей — прокрастинация. Мы откладываем всё на потом. Соответственно, задачи накапливаются.
Поэтому должно быть понимание, сколько задач должен выполнять сотрудник/отдел за определённый срок (например, неделю/месяц). Такой KPI, если хотите. Или еще можно назвать личный канбан.
3. Фокусировка на работе. Правила канбан учат нас принципу, что задачи не нужно постоянно планировать, их нужно делать.
Соотвественно, фокусировка на невыполненных задачах — главный приоритет. Подключение дополнительных людей, правильное использование ресурсов — всё, что необходимо, чтобы выполнить нерешенные задачи.
4. Улучшение. В связи с тем, что в канбан идёт работа по принципу “минимальными партиями”, проблемы в продукции или работе персонала будут видны на ранних этапах работы.
Их нужно выявить и устранить. Это и есть один из главных принципов — постоянное улучшение за счёт внимания к мелочам.
Примеры
Чтобы материал усвоился максимально легко и понятно, я Вам приведу несколько вариантов реализации данной методологии в жизни компании.
Ведь по ходу прочтения этой статьи у Вас, скорей всего, возникло ощущение, что внедрение канбан возможно только в производстве или IT-сфере.
Пример №1 Императорский дворец Японии
Я хочу, чтобы Вы представили современную Японию. А конкретно Токио. Но не сам высокотехнологичный город с огромными небоскрёбами, а Восточные сады в Императорском дворце Японии. Красивейший современный парк, да ещё и в момент цветения сакуры.
Если Вы видели в Интернете картинки цветков сакуры, мирно лежащей на воде, то сделаны они скорей всего именно в этом парке.
В момент входа в парк, вместо покупки билета, смотритель выдаёт Вам небольшую пластиковую карточку, которую Вы обязаны будете сдать в стеклянную будку, когда будете выходить с территории парка. Заметьте, это не билет. Это обычная карточка.
Самое интересное начинается потом. Как только в будке на выходе скапливается горка подобных карточек, смотритель забирает их и начинает выдавать желающим войти, которые ожидают своей очереди.
Это и есть kanban в действии. Только поданный через инструмент маркетинга — сторителлинг.
Выглядит необычно, но в действии это просто изумительно. Новый посетитель получает билет на вход (карточку), как только она освобождается.
Благодаря такому подходу, парк получает лёгкий способ контроля посетителей и избавляет руководство от контроля с переизбытком людей.
Пример №2 Отдел продаж
Вы — менеджер по продажам. И через Вас ежедневно проходят десятки клиентов. Помимо новых, у Вас есть старые, которым тоже нужно что-нибудь отправить или позвонить.
Ко всему этому Вам нужно контролировать исполнение договора, в виде оказания услуг или отгрузки.
Такая ситуация с огромным количеством задач на одного человека в 9 из 10 компаний.
Это не нормально, но естественно в условиях нашей реальности. Как с этим всем справиться? Как ничего не забыть? Как не получить штраф из-за просроченных сроков? К Вам идёт на помощь внедрение системы канбан.
Вы разделяете весь этап ведения клиента на шаги от А до Я. Начиная от первого контакта, заканчивая подписанием актов, а ещё лучше, звонков из серии “Как дела?”.
Кстати, звонок “Как дела?” это очень интересная техника по повышению лояльности и продаж.
В результате, после внедрения системы канбан, сотрудник полностью видит весь процесс продаж и ведения проекта.
Получается некая синергия этапов воронки продаж и введения проектов. Такой вот личный канбан для сотрудников.
Обратите внимание, что сейчас даже продажи реализуют по методологии канбан, ведь это и вправду интересно.
Вот пример успешной реализации канбан нами как еще одно доказательство, что это возможно в России:
Пример №3 Выполнение проекта
С этим всё максимально просто. Например, Вы — студия дизайна. А значит клиентский проект проходит по заранее составленному плану. На каждом участке этого плана есть свои ответственные и задачи.
С помощью внедрения канбан это будет выглядеть следующим образом. Когда менеджер по продажам подписал договор, он передаёт задачу (карточку канбан) на первый этап, который называется “Бриф и снятие размеров”.
После того, как из клиента вытащили все хотелки, то ответственный переносит карточку на следующий этап — “Дизайн” уже с другим ответственным. Затем карточка переходит к “Электрику”, “Раскройщику” и т.д.
Что мы имеем на выходе? А то, что каждый видит, какое количество задач у него есть на данном этапе.
Еще он может оценить, сколько у него будет задач в дальнейшем и какие затыки у него есть по этапам (куда направить все силы). Это в чистом виде адаптация под любую реализацию проекта.
Адаптация к бизнесу
А теперь давайте представим, что я убедил Вас начать внедрение системы канбан в своей компании. Что же для этого нужно сделать? Использовать доски и карточки канбан. Всё верно.
Наверное, Вы подумали о реальной доске, которая будет висеть у Вас на стене офисе, и на которую сотрудники будут приклеивать свои карточки.
Но так как у нас 21 век, то доска, а также карточки канбан могут быть виртуальными.
Именно для этого я подобрал 3 программы, которые помогут Вам совершить внедрение системы канбан совершенно безболезненно и результативно.
Программа 1. Мегаплан
Одна из самых популярных CRM систем в России. Мегаплан — полноценная система управления эффективностью бизнеса. Система помогает контролировать задачи и сроки их выполнения, настраивать персональный маркетинг, выстраивать оптимизированные бизнес-процессы — и в целом избавляет от рутины.
Все достоинства описывать не буду, могу лишь сказать, что сейчас Мегаплан можно настроить именно под Вашу компанию даже в бесплатной версии. Но вернёмся к канбан.
Как в любой CRM, в Мегаплане можно ставить задачи для себя и для сотрудников. И для удобства Вы можете делать это в канбан, если уж решили, что эта японская система Вам приглянулась.
Вкладки по типу “Выполняется” и “Сделано” Вы можете настроить индивидуально.
Также видно, какая задача и каким сотрудником выполняется в моменте, что позволяет контролировать производительность.
Самый главный плюс в том, что это полноценная CRM система, то есть всё в одном. Вы можете управлять клиентами по той же самой схеме, которую мы рассматривали выше в примере про отдел продаж.
И все это как с компьютера, так и с телефона через мобильное приложение. Сервис “must have” для большинства организаций. Хоть и не единственный, но зато бесплатный.
Кстати. Если Вы хотите протестировать другую CRM, то рекомендую Мегаплан, по ссылке 14 дней бесплатно -> megaplan.ru
Программа 2. Трелло
Мы сами использовали Трелло более года и были весьма довольны, пока проектов не стало “Мама не горюй”.
Во-первых, он бесплатный (но есть и платная версия), во-вторых, очень удобный и интуитивно понятный.
Когда выбирали, нам нужна была система с возможностью отслеживать проект целиком и выделять ответственных за этапы. В голову даже не пришло, что это как раз сущность системы канбан.
Как я уже писал, преимущества Трелло даже не в том, что он бесплатный и удобный. К тому же, у программы есть мобильное приложение, где Вы можете посмотреть или поставить задачу не будучи привязанным к компьютеру.
Трелло нам настолько понравился, что мы уже “подсадили” несколько клиентов на него.
Программа 3. Кайтен
Сервис Кайтен я нашел только потому, что список из 2-х пунктов смотрится неполноценно.
Но чем больше я изучал его, тем больше он мне нравился. Это специальный сервис, чтобы внедрить командный подход в своей компании.
Есть бесплатный тестовый период 14 дней (я, если честно, уже не представляю сервис без этой функции), интеграция всевозможных инструментов и две методологии для удобной работы: канбан и scrum (о ней ещё будет статья).
Кроме того, здесь учтён один из главных принципов канбан — ограниченное число задач.
То есть каждому процессу/сотруднику Вы можете задать определённое число задач, и он не сможет добавить новые, пока не завершит старые.
Недостатки: он платный (хотя 500 рублей за пользователя не такая уж и большая плата), и пока мобильное приложение есть только для пользователей Андроид.
Сам я ярый поклонник Apple, но разработчики сервиса обещают скоро порадовать и меня, выпустив мобильное приложение на iOS. Полноценно оценить сервис мне сложно, но то, что он достоин внимания, это точно.
Лайфхак. Прибыль любой компании зависит от эффективность сотрудников. Поэтому рекомендуем вам организовать рабочие процессы через специальный сервис Week. С его помощью Вы сможете распределить задачи, установить дедлайн и контролировать процесс работы в одном месте. Кликайте и тестируйте бесплатно -> Week
Коротко о главном
Я читал, изучал и внедрял разные системы управления проектами — agile, scrum, xp, канбан. И могу сказать, что одна из самых простых для малой и средней компании — это канбан.
Возможно это связано именно с тем, что большинство людей — визуалы (то есть воспринимают информацию наглядно), а главный принцип канбан — визуализация.
Поэтому я рекомендую Вам попробовать эту систему управления, если Вы ещё её не использовали. Благо, для этого есть такие бесплатные инструменты как Мегаплан и Трелло.
Но когда Ваш проект вырастет или перестанет быть линейным, то Вам придётся переходить на другие сервисы и методологии. Но это уже потом, сейчас канбана Вам будет достаточно.
Нашли ошибку в тексте? Выделите фрагмент и нажмите ctrl+enter
Разбираем, как канбан помогает управлять проектами и доводить их до результата. А также — три главных принципа канбана и как его внедрить в любой проект.
28 марта 2022
Система канбан. Как устроено умное управление проектами на реальных примерах
Канбан ― система управления проектами. Визуализирует путь проекта от идеи до готового продукта. Помогает контролировать выполнение задач и ограничивать их количество. За счет этого нагрузка равномерно распределяется между сотрудниками и команда делает больше с меньшими затратами.
Канбан можно использовать в любом проекте — он поможет управлять отделом продаж, планировать ивенты или построить космический корабль. В статье расскажем о том, как канбан помогает управлять проектами и доводить их до результата (на реальных примерах команды разработки и ивент-команды Mindbox), а также о трех главных принципах системы и как внедрить ее в любой проект.
Для работы по системе нужна только канбан-доска. На ней все процессы визуализируют с помощью колонок, а карточки отражают, на каком этапе находится единица работы
Содержание
- Как канбан помогает управлять проектами и доводить их до результата, который можно измерить
- Визуализация задач в виде карточек
- Распределение задач по колонкам
- Приоритизация задач с помощью классов обслуживания
- Визуализация задач и рабочего процесса на доске
- Три главных принципа канбана, которые помогают управлять проектами
- 1. Визуализировать выполнение всего проекта и отдельных задач
- 2. Ограничивать количество незавершенной работы
- 3. Постоянно улучшать рабочие процессы
- Как внедрить систему канбан в любой проект
Как канбан помогает управлять проектами и доводить их до результата, который можно измерить
Мнение
Канбан помогает оптимизировать рабочие процессы. Принципы канбана не диктуют, как, например, нужно декомпозировать работу или с какой скоростью нужно ее делать, но принципы должны выполняться, чтобы инструмент работал.
Визуализация задач в виде карточек
В переводе с японского канбан означает «сигнал, карточка». Карточки визуализируют задачи, которые находятся в работе. Они помогают команде отслеживать, что происходит с задачами, и если есть задержки — сразу видеть, на каком этапе.
Карточка может быть физической (в виде стикера) или электронной. На стикере обычно указывают минимум данных: название задачи, срок выполнения и имя ответственного. Электронная карточка более подробная — в ней собирают всю информацию о задаче и обсуждают ее с коллегами:
Карточка в Trello
Распределение задач по колонкам
Карточки размещены на специальной канбан-доске. Условно она делится на три колонки:
― задачи, которые предстоит выполнить;
― задачи, над которыми команда работает сейчас;
― завершенные задачи.
Это базовое деление, которое подойдет для любого проекта. Но колонок может быть больше, главное — учесть все этапы создания продукта. Например, у разработчиков ПО на канбан-доске, кроме колонок «Бэклог», «Разработка» и «Готово», скорее всего, будут колонки «Анализ», «Проектирование» и «Приемка».
Названия колонок на канбан-доске ― этапы, которые проходит задача. Как только задача проходит очередной этап, исполнитель перемещает карточку в следующую колонку.
Мнение
На доске карточки с задачами двигаются слева направо: от идеи до результата, который можно проверить в продакшене.
Положение карточки на доске отражает, сколько денег вложили в каждую задачу. Чем ближе задача к правому краю, тем больше денег на нее потратили. Если задача еще не в колонке «Готово», никакой ценности она не приносит.
Поэтому карточки нельзя двигать в обратном направлении — если сделать это, доска перестанет отражать реальность.
Дмитрий Кожевников, senior engineering manager Mindbox
Если в какой-то колонке начинают скапливаться карточки ― это сигнал, что работа на этом этапе настроена неправильно. Например, в разработке задачи часто скапливаются на этапе приемки, когда заказчику (часто это product owner) нужно проверить работу. В таком случае канбан визуализирует проблему: узкое место, из-за которого снижается скорость работы команды.
Решение этой проблемы — не брать еще больше работы, потому что количество решенных задач не увеличится, а разобраться, как можно расширить это узкое место.
Мнение
На канбан-доске может быть сколько угодно колонок ― здесь нет ограничений. Доска помогает найти этап, на котором задача застревает. А дальше ты начинаешь разбираться, почему это происходит, и искать способы, как это улучшить.
Дмитрий Кожевников, senior engineering manager Mindbox
Приоритизация задач с помощью классов обслуживания
Классы обслуживания показывают приоритет задач. Он зависит от дедлайна и стоимости задержки ― прибыли, которую компания не получила из-за невыполненных вовремя задач.
Есть четыре класса обслуживания:
Ускоренный. Неотложная задача появляется непредсказуемо, ради нее нужно бросить все остальное. У разработчиков это дефекты. Например, ошибка в логике кода приводит к отказу 10% клиентских операций.
Класс с фиксированной датой означает, что стоимость задержки резко возрастает с определенного момента. Например, с 28 января 2020-го изменился «Закон о рекламе» — устройства для нагревания табака и вейпы так же, как и обычные сигареты, запрещено рекламировать. Производитель знал об этом заранее и старался до этой даты адаптировать продвижение продукта к новым условиям. Опоздание увеличило бы стоимость задержки, поэтому задачу нужно было выполнить в срок.
Стандартный — для заранее запланированных рабочих задач, например для организации ивентов. Стоимость задержки этих задач растет параллельно со временем выполнения. Чем больше времени займет организация ивента, тем дольше компания будет ждать прибыль.
Нематериальный — для рутинных задач. Стоимость задержки растет медленно, потому что у таких задач нет предсказуемого финансового результата, тем не менее их нужно выполнять.
Мнение
У нас есть несколько типов задач, которые попадают в нематериальный класс:
― Некоторые задачи из техдолга. Например, есть кусок кода, который очень сложно менять. Его хорошо бы переписать, чтобы сделать последующие изменения дешевыми. Однако эти самые изменения не предвидятся даже в отдаленном будущем, поэтому стоимость задержки такой задачи незначительна.
― Задачи из «малого» продуктового бэклога. Обычно это фичи, которые немного улучшают ежедневную работу клиентов на платформе. Клиенты могут решать свои задачи и без этих фич, но с ними будет немного удобнее.
Дмитрий Кожевников, senior engineering manager Mindbox
Визуализация задач и рабочего процесса на доске
Канбан-доска может быть реальной — на доске с разноцветными стикерами — или виртуальной — в специальном приложении.
Приложений для канбана не меньше десятка. Мы расскажем о трех: одном из самых популярных (Trello), о приложении для управления продажами («Битрикс24»), о бесплатном приложении (GitHub).
1. Trello. Подходит для небольших команд на 5–6 человек и для больших компаний с командами по 10–15 человек. Позволяет создать отдельную доску для каждой команды, отдела или проекта. На доске может быть сколько угодно колонок ― зависит от того, сколько этапов проходит задача.
В карточку добавляют ответственного, прикрепляют файлы, обсуждают задачу, устанавливают дедлайн.
Фрагмент Trello-доски редакции Mindbox
В Trello есть бесплатная версия, но без доступа к некоторым функциям. Например, будет ограничен объем файлов, которые можно загрузить в него.
Работает в браузере, есть десктопное и мобильное приложение.
2. «Битрикс24». Готовый шаблон канбан-доски для любого проекта уже разделен на базовые этапы: «Новые», «Выполняются», «Сделаны». В карточках устанавливают дедлайны, прикрепляют файлы, обсуждают задачи в комментариях, чтобы их детализировать. Если нужно, для каждого проекта устанавливаются дополнительные этапы.
Канбан-доска в «Битрикс24»
На канбан-доске для управления продажами в виде карточек представлены лиды и сделки. Здесь менеджеры по продажам планируют, с кем из клиентов связаться, кому оформить доставку или выставить счет. Доска разделена на пять основных этапов: «Входящие», «На согласовании», «В производстве», «Произведено» и «К отгрузке». Если нужно, на доску добавляют дополнительные этапы. В верхней части каждой колонки отображается ее финансовая ценность:
Фрагмент канбан-доски для управления продажами в «Битрикс24»
«Битрикс24» дает бесплатный доступ к канбан-доске, но с ограниченным функционалом — например, нет возможности интегрировать ее с «1С».
Работает в браузере, есть мобильное приложение.
3. GitHub подходит и для задач одного человека, и для проектов, в которых задействованы несколько команд.
В колонки можно добавлять заметки. Они напоминают о задачах или содержат дополнительную информацию по проекту. Заметку можно преобразовать в задачу.
В GitHub есть настройка, которая автоматически распределяет задачи по колонкам. Например, любые новые задачи сразу оказываются в колонке «К исполнению». Это помогает стандартизировать работу с доской.
Фрагмент доски в GitHub
Три главных принципа канбана, которые помогают управлять проектами
1. Визуализировать выполнение всего проекта и отдельных задач
Например, компания планирует годовой бюджет. Проект делят на небольшие задачи и назначают ответственного. Три задачи для примера:
— план продаж, готовит коммерческий отдел;
— маркетинговый бюджет, составляет отдел маркетинга;
— постоянные и переменные затраты, считает финансовый отдел.
Для таких глобальных проектов, когда вместе работает много людей, канбан-доска получится огромной и сложной. Поэтому ее делят на несколько досок: высокоуровневую доску, на которой обозначены крупные блоки работы, и отдельную доску внутри каждого блока, чтобы фиксировать более мелкие задачи. Например:
Получилась одна общая доска «Годовой бюджет» и отдельные доски для каждого отдела
В канбане нет четких правил оформления доски — карточки и колонки могут комбинироваться разными способами. Пример команды Mindbox, которая организовывает офлайн- и онлайн-мероприятия:
Мнение
Каждый месяц мы проводим одновременно около сорока мероприятий, за каждым нужно следить.
Канбан предполагает, что можно придумать несколько структур ведения проекта. У нас структура зависит от масштаба:
— Небольшие ивенты (вебинары) мы разделяем по месяцам: один столбец — месяц, одна карточка — ивент.
— Большие ивенты разделяем по составляющим, которые нужно учесть в организации. Получается так: один столбец — большой ивент, каждая карточка посвящена лишь одной составляющей, например площадке, оборудованию или персоналу.
При организации любого ивента система помогает нам видеть всю картину целиком, учитывая предстоящий объем работы. В сравнении с тем, как я работала раньше (не по канбану, когда четкой структуры не было), сейчас организация любого ивента происходит гораздо проще и нагляднее.
Анна Парфёнова, ивент-менеджер Mindbox
Фрагмент доски для небольших ивентов
Фрагмент доски для крупных мероприятий
2. Ограничивать количество незавершенной работы
В канбане есть термин WiP ― work in progress ― количество задач, которые одновременно находятся в работе у команды или у отдельного исполнителя. Если таких одновременных задач становится больше, чем команда может сделать, на одном или нескольких этапах работа останавливается и под угрозой оказывается весь проект.
Невыполненные задачи ― это препятствия, которые мешают компании получить прибыль. Чем быстрее карточка с задачей окажется в колонке «Готово», тем быстрее компания начнет зарабатывать на ней. Когда количество задач ограничено, команде проще планировать работу, сотрудники не устают, ошибок меньше, а качество выше. Поэтому устанавливают WiP-лимиты. Например, надпись «WiP=4» в названии колонки означает, что одновременно в работе могут быть только четыре задачи.
Мнение
Чтобы отслеживать количество незавершенной работы, я пользуюсь таблицей, в которой есть список всех задач команды и цифры — сколько дней отвели для каждой задачи и сколько реально было потрачено.
Например, я вижу, что для задачи отвели пять дней, а делали почти две недели. Для меня это повод начать разбираться, почему мы так много времени потратили на эту задачу. Я докапываюсь до причины задержки и устраняю ее. А потом в этой же таблице смотрю, стала ли аналогичная задача решаться быстрее.
Дмитрий Кожевников, senior engineering manager Mindbox
3. Постоянно улучшать рабочие процессы
Система канбан предполагает, что идеальных проектов не бывает. Проблемы, ошибки и сложности есть всегда, главное — всей командой анализировать их и улучшать рабочие процессы. Если в работе ничего не менять, каждый следующий проект будет спотыкаться в одном и том же месте и на задачу будут уходить лишнее время и ресурсы.
Например, перед началом проекта команда установила WiP-лимит — договорилась, что одновременно в работе может быть 10 задач. По факту оказалось, что это много, и режим работы стал довольно напряженным. Тогда команда решает сократить количество задач. Если же команда оставит WiP-лимит прежним, есть вероятность, что задачи будут задерживаться в одной или нескольких колонках доски и проект в итоге обойдется дороже.
Как внедрить систему канбан в любой проект
Мнение
Я часто запускаю работу по канбану в новых командах. Бывает, что команда состоит из людей, которые ничего о нем не знают.
Поэтому на первой неделе я объясняю правила — в чем суть канбан-доски, почему она выглядит именно так. Рассказываю про движение карточек — что оно означает и почему их нельзя двигать обратно. Показываю, как пользоваться статистикой выполнения задач. Договариваюсь с командой о том, как мы работаем с доской. При этом обязательно каждому объясняю — на доске можно менять процессы и делать так, как у нас принято в компании: прозрачно, и доводить изменения до всех заинтересованных людей.
Начинаем работу с максимально простой доски. В ней может быть всего четыре колонки: «Проектирование», «Можно разрабатывать», «В работе» и «Готово». А дальше мы эту доску подстраиваем под то, как в команде делаем задачи и в каком виде, с какими этапами — это нужно бизнесу.
Дмитрий Кожевников, senior engineering manager Mindbox
Рекомендуем по теме
Статья-дневник разработчика Ромы Ивонина об истории Mindbox с ноября 2013 года по май 2020 года ― в канбан-досках разработчиков: «Эволюция компании в канбан‑досках»
Дэвид Андерсон «Канбан. Альтернативный путь в Agile». Автор впервые применил канбан в разработке ПО, в книге рассказывает, как внедрить систему в технологические разработки.
Сборник «Канбан и „точно вовремя“ на Toyota. Менеджмент начинается на рабочем месте». В основе книги ― учебные материалы для семинаров по производственной системе Toyota. Это краткое руководство по снижению затрат на производстве, повышению производительности процесса и качества продукции.
Майк Барроуз «Канбан Метод. Улучшение системы управления». Книга рассказывает об основных принципах канбана и дает пошаговое руководство по внедрению метода с учетом специфики бизнеса.