Канбан: что это такое? Собираетесь внедрить канбан в бизнес-процессы? Вот с чего стоит начать

Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009 , где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи - это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.

Для начала напишу про происхождение термина Канбан .

Этот термин пришёл к нам из Японии благодаря широко известной в узких кругах производственной системе Тойота . Хотелось бы, чтобы как можно больше людей прочитало про эту систему и основные принципы, заложенные в неё - бережливое производство, постоянное развитие, ориентацию на клиента и т.п. Все эти принципы описаны в книге Тайити Оно Производственная система Тойоты , которая переведена на русский.

Термин Канбан имеет дословный перевод: “Кан” значит видимый, визуальный, и “бан” значит карточка или доска.
На заводах Тойота карточки Канбан используются повсеместно для того, чтобы не загромождать склады и рабочие места заранее созданными запчастями. Например, представьте, что вы ставите двери на Тойоты Короллы. У вас около рабочего места находится пачка из 10 дверей. Вы их ставите одну за другой на новые машины и, когда в пачке остается 5 дверей, то вы знаете, что пора заказать новые двери. Вы берете карточку Канбан, пишете на ней заказ на 10 дверей и относите ее тому, кто делает двери. Вы знаете, что он их сделает как раз к тому моменту, как у вас закончатся оставшиеся 5 дверей. И именно так и происходит - когда вы ставите последнюю дверь, прибывает пачка из 10 новых дверей. И так постоянно - вы заказываете новые двери только тогда, когда они вам нужны.
А теперь представьте, что такая система действует на всём заводе. Нигде нет складов, где запчасти лежат неделями и месяцами. Все работают только по запросу и производят именно столько запчастей, сколько запрошено. Если вдруг заказов стало больше или меньше - система сама легко подстраивается под изменения.

Основная задача карт Канбан в этой системе - это уменьшать количество «выполняющейся в данный момент работы» (work in progress).
Например, на всю производственную линию может быть выделено ровно 10 карточек для дверей. Это значит, что в каждый момент времени на линии не будет больше 10 готовых дверей. Когда заказывать новые двери и сколько - это задача для того, кто их устанавливает. Только он знает свои потребности, и только он может помещать заказы производителю дверей, но он всегда ограничен числом 10.
Этот метод Бережливого производства (Lean manufacturing) был придуман в Тойоте и сейчас многие производственные компании по всему миру его внедряют или уже внедрили.

Но это всё относится к производству, а не к разработке программного обеспечения.
А что же такое Канбан разработка применительно к ПО, и чем она отличается от других гибких методологий, буть то SCRUM или XP?

Во-первых, нужно сразу понять, что Канбан - это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.
Во-вторых, весь Канбан можно описать одной простой фразой - «Уменьшение выполняющейся в данный момент работы (work in progress)» .
В-третьих, Канбан - это даже еще более «гибкая» методология, чем SCRUM и XP. Это значит, что она не подойдет всем командам и для всех проектов. И это также значит, что команда должна быть еще более готовой к гибкой работе, чем даже команды, использующие SCRUM и XP.

Разница между Канбан и SCRUM:
- В Канбан нет таймбоксов ни на что (ни на задачи, ни на спринты)
- В Канбан задачи больше и их меньше
- В Канбан оценки сроков на задачу опциональные или вообще их нет
- В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи

А теперь посмотрите на этот список и задумайтесь - что остается от гибкой методологии, если мы удаляем спринты, увеличиваем размеры задач и перестаем мерять скорость работы команды? Ничего?
Как вообще можно говорить о контроле за разработкой, если мы убираем основные инструменты контроля - сроки, скорость работы и спринты? Для меня этот вопрос является чуть ли не самым важным.
менеджеры всегда думают о контроле и пытаются его получить, хотя на самом деле никогда его не имеют. Контроль разработки со стороны менеджера - это фикция. Если команда не хочет работать, то как ее не контролируй, она провалит проект.
Если команда получает фан от работы и работает с полной отдачей, то никакой контроль и не нужен, а только мешает, увеличивает издержки.
Например, общеизвестная проблема SCRUM - это большие издержки от обсуждений, встреч и большие потери времени на стыках спринтов (когда как минимум день уходит на закрытие одного спринта, а потом день на открытие нового. И если спринт - 2 недели, то 2 дня из 2 недель - это 20%, чертовски много). В итоге чуть ли не 30-40% времени при применении SCRUM тратится на поддержание самого процесса - на ежедневные митинги, на 5% workshop, на спринт ретроспектив и т.п. 30%!

Канбан разработка отличается от SCRUM в первую очередь ориентацией на задачи. Если в SCRUM основная ориентация команды - это успешное выполнение спринтов (надо признать, что это так), то в Канбан на первом месте задачи.
Спринтов никаких нет, команда работает над задачей с самого начала и до завершения. Деплоймент задачи делается тогда, когда она готова. Презентация выполненной работы - тоже. Команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале.
Если менеджер верит команде, то зачем иметь оценку времени? Задача менеджера - это создать приоритизированный пул задач, а задача команды - выполнить как можно больше задач из этого пула. Всё. Никакого контроля не нужно. Всё, что нужно от менеджера - это добавлять задачи в этот пул или менять им приоритет. Именно так он управляет проектом.

Команда для работы использует Канбан-доску. Например, она может выглядеть так (взял ):

Столбцы слева направо:

Цели проекта :
Необязательный, но полезный столбец. Сюда можно поместить высокоуровневые цели проекта, чтобы команда их видела и все про них знали. Например, «Увеличить скорость работы на 20%» или «Добавить поддержку Windows 7».

Очередь задач :
Тут хранятся задачи, которые готовы к тому, чтобы начать их выполнять. Всегда для выполнения берется верхняя, самая приоритетная задача и ее карточка перемещается в следующий столбец.

Проработка дизайна :
этот и остальные столбцы до «Закончено» могут меняться, т.к. именно команда решает, какие шаги проходит задача до состояния «Закончено».
Например, в этом столбце могут находиться задачи, для которых дизайн кода или интерфейса еще не ясен и обсуждается. Когда обсуждения закончены, задача передвигается в следующий столбец.

Разработка :
Тут задача висит до тех пор, пока разработка фичи не завершена. После завершения она передвигается в следующий столбец.
Или, если архитектура не верна или не точна - задачу можно вернуть в предыдущий столбец.

Тестирование :
В этом столбце задача находится, пока она тестируется. Если найдены ошибки - возвращается в Разработку. Если нет - передвигается дальше.

Деплоймент :
У всех проектов свой деплоймент. У кого-то это значит выложить новую версию продукта на сервер, а у кого-то - просто закомитить код в репозиторий.

Закончено :
Сюда стикер попадает только тогда, когда все работы по задаче закончены полностью.

В любой работе случаются срочные задачи. Запланированные или нет, но такие, которые надо сделать прямо сейчас. Для таких можно выделить специальное место (на картинке отмечено, как «Expedite»). В Expedite можно поместить одну срочную задачу и команда должна начать ее выполнять немедленно и завершить как можно быстрее. Но может быть только одна такая задача! Если появляется еще одна - она должна быть добавлена в «Очередь задач».

А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но считается, что они должны зависеть от числа разработчиков в команде.
Например, если вы имеете 8 программистов в команде, то в строку «Разработка» вы можете поместить цифру 4. Это значит, что одновременно программисты будут делать не более 4-х задач, а значит у них будет много причин для общения и обмена опытом. Если вы поставите туда цифру 2, то 8 программистов, занимающихся двумя задачами, могут заскучать или терять слишком много времени на обсуждениях. Если поставить 8, то каждый будет заниматься своей задачей и некоторые задачи будут задерживаться на доске надолго, а ведь главная задача Канбан - это уменьшение времени прохождения задачи от начала до стадии готовности.
Никто не даст точный ответ, какие должны быть эти лимиты, но попробуйте для начала разделить число разработчиков на 2 и посмотреть, как это работает в вашей команде. Потом эти числа можно подогнать под вашу команду.
Под «разработчиками» я понимаю не только программистов, но и других специалистов. Например, для столбца «Тестирование» разработчики - это тестеры, т.к. тестирование - это их обязаность.

Задачи на такой доске - это не просто задачи, а то, что называется Минимальной Маркетинговой Фичей, то есть фича, которую можно «продать» клиентам.
Хорошая проверка для ММФ - это вопрос себе «А стал бы я писать про эту фичу в блоге компании?». Если нет - это не ММФ.

Что нового и полезного дает такая доска с лимитами?

Во-первых, уменьшение числа параллельно выполняемых задач сильно уменьшает время выполнения каждой отдельной задачи. Нет нужды переключать контекст между задачами, отслеживать разные сущности, планировать их и т.д. - делается только то, что нужно. Нет нужды устраивать спринт планнинги и 5% воркшопы, т.к. планирование уже сделано в столбце «очередь задач», а детальная проработка задачи начинается ТОЛЬКО тогда, когда задача начинает выполняться.

Во-вторых, сразу видны затыки. Например, если тестеры не справляются с тестированием, то они очень скоро заполнят весь свой столбец и программисты, закончившие новую задачу, уже не смогут переместить ее в столбец тестирования, т.к. он заполнен. Что делать? Тут время вспомнить, что «мы - команда» и решить эту проблему. Например, программисты могут помочь тестерам завершить одну из задач тестирования и только тогда передвинуть новую задачу на освободившееся место. Это позволит выполнить обе задачи быстрее.

В-третьих, можно вычислить время на выполнение усредненной задачи. Мы можем помечать на карточке дату, когда она попала в очередь задач, потом дату, когда ее взяли в работу и дату, когда ее завершили. По этим трем точкам для хотя бы 10 задач можно уже посчитать среднее время ожидания в очередь задач и среднее время выполнения задачи. А из этих цифр менеджер или product owner может уже рассчитывать всё, что ему угодно.

Весь Канбан можно описать всего тремя основными правилами:
1. Визуализируйте производство
- Разделите работу на задачи, каждую задачу напишите на карточке и поместите на стену или доску.
- Используйте названные столбцы, чтобы показать положение задачи в производстве.
2. Ограничивайте WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства.
3. Измеряйте время цикла (среднее время на выполнение одной задачи) и оптимизируйте постоянно процесс , чтобы уменьшить это время.

Всего 3 правила!
Например, в SCRUM - 9 базовых правил. В XP - 13, а в классическом RUP - аж более 120. Почувствуйте разницу.

На этом я закончу первую статью про Канбан.
Жду ваших отзывов и комментариев, а также пожеланий к следующим статьям.

Мария Денисенко, эксперт по финансам и закупкам, руководитель направления по развитию приоритетных проектов компании ScrumTrek , рассказывает о своем опыте внедрения метода в финансовом подразделении одного из российских министерств. Эту колонку стоит прочитать и представителям бизнеса, которые намерены внедрить методологию в свои проекты.

Что мне предстояло сделать?

Заступив на службу в подразделение закупок Министерства цифрового развития, связи и массовых коммуникаций РФ в далеком 2013 году, я встала перед выбором процесса организации деятельности целого структурного подразделения. Организовать работу необходимо было «с нуля» в соответствии с новыми требованиями законодательства. На смену Закону № 94-ФЗ приходил новый закон о контрактной системе – Закон № 44-ФЗ.

Передо мной стояли две задачи. С одной стороны, необходимо было четко выстроить систему организации осуществления закупок в соответствии с новыми нормами. А это значит: новые процессы, новые документы, новые электронные системы, новые люди. С другой стороны, необходимо было наложить все эти нововведения на текущие реалии организации. Ведь некие процессы в организации уже существовали и даже работали. В наличии была гора локальных актов (более двадцати пяти).

Работал штат специалистов – целый отдел. Но не было структуры. Не было эффективного процесса улучшений. Отсутствовало понимание цели деятельности. Специалисты были перегружены.

После достаточно длительного изучения всех имеющихся документов, регулирующих деятельность закупочного подразделения (должностных регламентов сотрудников и положений о структурных подразделениях, приказов о создании закупочных и приемочных комиссий, приказов о закупках и о заключении контрактов) и опросов работников министерства я пришла к выводу, что для начала весь процесс необходимо визуализировать. Понять и разобраться в том, что есть сейчас.

Какие были проблемы?

В итоге оказалось, что, с одной стороны, есть множество важных процессов, которые не зарегламентированы. Например, передача контракта на подписание, сроки рассмотрения документов по жалобе, процесс обоснования и планирования закупки. А каждому специалисту в сфере государственного и муниципального заказа известно, что ошибка в любом из этих значимых действий может привести к наложению на конкретного сотрудника административной ответственности.

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

С функциональными заказчиками (заказывающими структурными подразделениями министерства) работники закупочного подразделения практически не общались. И этот факт приводил к существенному увеличению и усложнению любых совместных или последовательных процессов. Руководство было нагружено массой микроменеджерских функций, напрочь закрывающих возможность стратегического развития направления. Постоянное подписание приказов, проверка контрактов, разруливание проблем при взаимодействии закупочного подразделения и иных, участвующих в закупках подразделений.

Поток задач был настолько бессистемным и большим, что каждый из сотрудников «с успехом» оправдывал пункт трудового контракта, где было указано, что государственный гражданский служащий работает «в рамках ненормированного рабочего дня».

Что я сделала?

Еще не зная, что в продвинутом мире существует канбан-метод, я интуитивно уже следовала его принципам и использовала практики.

Визуализировала процессы

Это было сложно и достаточно долго. Некоторые процессы необходимо было насилу вытаскивать из сотрудников смежных подразделений. Некоторые стали явными уже в процессе работы. Для этого мне приходилось общаться с работниками от уровня топ-1 до уровня рядового специалиста, визуально отсеивать лишний функционал, структурировать систему. Стали явно видны узкие места, лишние документы, потребности в новых сотрудниках.

Разъясняла руководству принципы «вытягивающей системы»

И параллельно строила процессы таким образом, чтобы заказывающие подразделения министерства, по заявкам которых осуществлялись закупки, четко понимали разницу между принятыми и отложенными обязательствами. С каждым днем WIP-лимит «выделенной полосы» становился все более вменяемым, пока не пришел к стандарту в одну единицу. От «срочно все» мы не сразу перешли к приоритизации и вытягиванию. Далеко не сразу.

Руководству сложно объяснить, почему его задача до сих пор не взята в работу. Для большинства руководителей висящие в «in progress» неделями задачи – это лучше, чем реально выполняемая на текущий момент работа и стоящие в очереди для принятия обязательств другие задачи.

Приоритизация и ограничение потока, на мой взгляд, оказались самыми сложными задачами. Это министерство, говорили мне, здесь важно все. Здесь все срочно. И каждый руководитель заказывающего структурного подразделения, а их на тот момент было около двенадцати, имеет право ставить задачу для подразделения закупок. После года масштабной информационно-разъяснительной работы мы пришли к тому, что приоритеты закупочного подразделения выстраивались мной. И редкие звонки руководителей уровня топ-1 (заместителей министра) приводили к изменению приоритетности или добавлению задач в выделенную полосу.

Работала с руководством и командой в части «устаканивания» понимания того, что значит для нашего сервиса «соответствие предназначению»

Это была ломка системы. Люди, работающие на небольшом участке «технической», как они считали, работы большого министерства, трудно приходили к пониманию цели и качества. Почти всю команду пришлось сменить. Более того, отбор специалистов являлся залогом успеха дальнейшего развития направления. Поэтому я подходила к нему очень серьезно, учитывая, в том числе и особенности отбора, стандартизированные в Законе 79-ФЗ.

Смена сотрудников – достаточно частое явление при изменении подходов к организации деятельности. Новые задачи, новые особенности работы – все это не каждый работник готов выдержать. Около года после смены ряда сотрудников мы перешли к новой системе работы: от закрытого кабинета – к опенспейсу с постоянным обсуждением и встречами, от неотвеченных звонков – к клиентоориентированности, от оправданий за совершенные ошибки при подготовке документов – к командной работе над ними. И всех последующих сотрудников в закупочное подразделение я уже подбирала в соответствии с новой процессной парадигмой.

Работала с источниками неудовлетворенности в текущей системе и с внедрением циклов обратной связи

С ними я призываю работать постоянно и плотно. Это основной двигатель прогресса, на мой взгляд. Реализация принципа эволюционного развития. До этого собирать «обратную связь» от стейкхолдеров в данной организации было просто не принято. Кроме как «жалобами» обратную связь никто не называл. И все эти жалобы тонули в кулуарах руководства навсегда, выливаясь лишь в личные выговоры сотрудникам.

Фидбэк мы получали регулярно по организованным каналам (служебные запросы на уровень руководства, полуформальные встречи, звонки контроля качества). Мы превратили это в систему. И в результате такой совместной работы структурировали процессы контрактной службы министерства, в которую по последним данным входило около 80 работников.

Взращивание проявлений лидерства также было непростой задачей

Ситуация осложнялась тем, что с учетом специфики работы на каждом из сотрудников лежала не просто ответственность, а ответственность, подкрепленная административной ответственностью (любые нарушения в сфере закупок квалифицируются в соответствии с соответствующей статьей КоАП). В системе, где из «бонусов» есть только благодарность министра, а из ответственности от 3 до 50 тысяч рублей за каждое нарушение быть «лидером» никто не горел желанием.

Сначала я давала небольшие задания в малых группах. Позже коллеги стихийно увеличивали задействованных в решении вопроса работников. Мы проводили семинары и мозговые штурмы. Организовывали внутренние проекты обучения сотрудников. Взращивали институт наставничества, когда закупочное подразделение пополнилось новыми сотрудниками.

Вскоре совместная работа стала привычной. Теперь почти любая задача выполнялась (подстраховывалась или контролировалась) несколькими сотрудниками. Снизилось количество ошибок (почти в пять раз), повысилась скорость работы на каждом из участков. Мы стали уходить домой вовремя, исключая сезонные периоды формирования бюджета и планирования.

При формировании правил для улучшения показателей мы также сталкивались с определенными трудностями

После визуализации процесса и обкатки работы с учетом WIP-лимитов руководством было принято решение зарегламентировать процессы (ну, куда же без этого в госоргане). И любые последующие изменения необходимо было проводить через согласования. Но, следуя общей парадигме гибкого подхода, такие согласования проходили достаточно безболезненно. И частично решались на моем уровне.

Нами был сформирован регламент контрактной службы. Это процессный документ, который был создан после визуализации процессов и их увязки с законодательными нормами, а также после перераспределения функционала. Он был живой, подвергался постоянным изменениям по итогам отладки процессов, а также в случае изменения законодательных норм.

Принцип вытягивания задач значительно осложнялся на первоначальном этапе законодательными особенностями осуществления закупок

Эти процессы имеют жесткие сроки и четкий процесс осуществления, изложенный в Законе № 44-ФЗ. Все зарегламентировано: формирование и публикация плана закупок и плана-графика закупок, сроки публикации извещения об осуществлении закупки и сроки размещения документации, сроки рассмотрения заявок участников и сроки подписания контракта. Соотнести все это с WIP-лимитами и выработать идеальную скорость поставки – задача не из легких. А с учетом постоянного изменения законодательства без постоянного эволюционного развития подобная система вообще работать не будет.

Что в итоге?

Спустя время всю целостность знаний и наработанный опыт мне удалось систематизировать, углубить и расширить в процессе обучения канбан-методу. Открылась важность применения некоторых, ранее не учтенных процессов. Существенно пополнилась линейка метрик. Пришло понимание широты применимости метода. До конца выстроилась система основных принципов (теперь я их не просто понимала, я с легкостью могла сделать их явными для других).

Исходя из более чем пятилетней практики работы могу сделать однозначный вывод о том, что в финансовом блоке канбан может эффективно работать. Более того, он существенно облегчает работу при взаимодействии финансового блока со смежными структурными подразделениями.

Представленный выше набор принципов и практик вполне возможно использовать как краткое руководство по внедрению канбан в финансовом блоке. При этом хочу обратить внимание, что в этой статье мы не затрагивали подробные аспекты системного подхода к внедрению канбан (S.T.A.T.I.K.). Эту тему мы разберем в отдельной статье.

К сожалению, мне не удалось масштабировать процессы на более широкий круг сервисов. Но в блоках, смежных финансовым подразделениям, применение канбан-метода также возможно и эффективно, даже с учетом особенностей госсектора. И в скором времени мы поделимся с вами результатами подобного кейса.

Менеджмент Камбан в экономической практике означает такую организацию предпринимательской деятельности - будь то производство, логистика или розничная торговля - которую можно охарактеризовать как система «точно в срок». В самом термине «Kanban», который переводится с японского как «видимая карточка», заложен подход к оптимизации бизнеса за счет деления на операции и визуализации рабочего процесса. И хотя философию Kanban впервые применили в фирме «Toyota» более полувека назад, этот метод в современном понимании был разработан и предложен экономистом Дэвидом Андерсоном.

Что представляет собой система Канбан?

Экономист Дэвид Андерсон, будучи весной 2005 года в Токио, во время прогулки в Восточных садах Императорского дворца пришел к выводу, что многоразовые разноцветные пластиковые билеты для туристов, называемые Kanban могут стать инструментом экономической деятельности в условиях неопределенности. Совершив прогулку и сдав Канбан, он, по сути, завершил «условную работу». Отметки о выдаче карточек посетителям и получении их обратно контроллёры делали на специальной доске с колонками.

Андерсон пришёл к выводу, что посредством карточек и колонок можно, например, контролировать запасы на складе или поставки товаров. За счет концепции «точно в срок» удастся минимизировать материальные издержки и оптимизировать продажи. Нечто подобное еще в конце 60-х годов прошлого века использовалось в машиностроительном производстве Toyota, однако тогда количество одновременно выполняемых задач было минимальным, работы осуществлялись в соответствии со строгим алгоритмом.

Итак, Андерсон увидел в доске Канбан ценный производственный инструмент, о котором рассказал в книге «Kanban: успешные эволюционные изменения для вашего технологического бизнеса».

Что дает Канбан для производства?

Таким образом, сформулированная Дэвидом Андерсоном методология Канбан являет собой эволюционный процесс управления задачами, предполагающий точную организацию работ (поставок).

«Главный принцип заключается в том, чтобы любой труд был не напрасным, - рассказывает экономист Максим Юркин. - Канбан дает возможность бизнесмену оптимизировать этапы проекта еще до его старта на основании имеющейся у него визуальной информации о выполнении аналогичных работ. Именно на этом строится «бережливое производство».

Если сравнивать производственные процессы до и после внедрения методологии Андерсона, то видно, как день за днем снижаются материальные издержки. При этом сотрудники ориентируются на запись в карточке Канбан «Done» («сделано») «точно в срок». Предприниматели, внедрившие метод Андерсона, сообщили о росте рентабельности своего бизнеса на 25-30% - причем без каких-либо серьезных инвестиций. Со временем метод Канбан становится все более распространённым и востребованным в среднем и малом бизнесе.

Как ввести Канбан в компании?

Анализ публикаций в российских СМИ показывает, что во многих случаях под внедрением Канбан подразумевается интеграция системы поставок «точно в срок», в которой используются специальные доски с колонками “to do” (начал работу), “in progress” (работаю), ”review” (пересмотр работы), ”test” (результат), “done” (завершено). Таким образом, контролируются действия всех сотрудников и не допускается возникновение такой ситуации, когда у одного сотрудника накопилось огромное количество невыполненных задач, а другой сидит без дела.

Российскому читателю книги Андерсона может показаться, что Канбан противоречит здравому смыслу. Это вроде как телегу поставить впереди лошади, ведь традиционное планирование осуществляется с нуля. Этот метод призывает «прекратить стартовать и начинать финишировать».

4 принципа Канбан

Чтобы понять и успешно применять в своем бизнесе систему «точно в срок», нужно обратить внимание на девять фундаментальных вещей Канбан: 4 принципа и 5 правил. Начнем с принципов:

• Всегда оценивайте то, что делаете.
• Будьте готовы к эволюционным изменениям.
• Уважайте роли, обязанности и титулы.
• Поощряйте неформальных лидеров.

Дело в том, что концепция Канбан не дает «железных» установок и тем более не прописывает «лечебные» процедуры. Именно поэтому Андерсон советует поверх имеющегося рабочего процесса «наложить» правила, которыми надо ежедневно руководствоваться в производстве. Отметим, что метод Канбан предполагает следование по пути наименьшего сопротивления. Иначе говоря, он поощряет непрерывные инкрементные и эволюционные изменения текущей системы, поскольку революционные перемены сталкиваются с серьезным сопротивлением - со стороны как сотрудников, так и клиентов.

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

Отмечается также, что в любом коллективе есть люди, которые пользуются авторитетом, даже если не занимают высоких должностей. Тем не менее, к ним прислушиваются и их уважают. Разумно способствовать их карьерному росту. Поощрение таких неформальных лидеров положительно сказывается на состоянии бизнеса в целом.

5 правил Канбан

Помимо 4 принципов Дэвид Андерсон в своей книге «Kanban: успешные эволюционные изменения для вашего технологического бизнеса» описал 5 базовых правил, которых придерживаются успешные бизнесмены:

• Визуализация рабочего процесса.
• Ограничение незавершенных производств (WIP — Work-In-Progress).
• Управление потоком работ.
• Понятность и прозрачность изменений.
• Улучшение совместной работы (с использованием моделей и научного метода).

Расскажем о правилах поподробнее. Поскольку цель Канбан заключается в позитивных изменениях рабочего процесса через последовательную его оптимизацию, прежде всего, нужно ответить на главный вопрос: что является целью эволюции бизнеса? Сделать это можно только после осознания того, как работает процесс. Лишь тогда целесообразно пытаться интегрировать концепцию «точно в срок».

Визуализация бизнес-процессов - очень эффективный метод. Визуализировать можно посредством так называемой доски Канбан или платформы LeanKit. Отметим, что LeanKit поддерживает внедрение принципов бережливого производства с целью создания условий непрерывного совершенствования бизнес-процессов и интеграции инноваций.

«Способы визуализации столь же разнообразны, как и оптимизируемые рабочие процессы, - поясняет Максим Юркин. - При классификации операций помимо потока работ и времени их исполнения могут использоваться другие критерии, такие как рыночный риск и стоимость задержек».

Если грамотно визуализировать рабочий процесс, то легко найти фрагменты WIP, которые называют «убийцами бизнеса».

«Значит, борьба с незавершенным производством должна идти в течение всего рабочего процесса, - пишет Дэвид Андерсон. - Ибо вовремя не сделанная работа «переносит» негатив на следующий шаг, а потом удвоенный негатив - на последующий шаг. И это похоже на снежный ком. Снижение WIP до нуля является краеугольным камнем Канбан».

Очень важна обратная связь. Внеся изменения, следует убедиться, что и впрямь произошло улучшение.

«Метод Канбан - это увлекательное путешествие, когда не знаешь, куда придешь, - напоминает Дэвид Андерсон. - Решение одной проблемы может вызвать усугубление другой».

Чтобы процесс внедрения изменений не «зашёл в тупик», он должен быть понятен всем участникам проекта. В этой связи логично привести еще одну цитату Андерсона: «Без четкого понимания того, как все должно работать, любое обсуждение проблем имеет тенденцию быть эмоциональным, анекдотическим и субъективным. Это верно, как реакция коленного рефлекса».

В методе Канбан ключевым является понятие Кайдзен, означающее непрерывные, инкрементные и позитивные изменения.

«Бизнесмен, интегрирующий метод «точно в срок», должен понимать, что такое Кайдзен, - считает Андерсон. - Если вы не стремитесь к совершенствованию, внедрять Канбан не имеет смысла».

Kanban vs. Agile

Понятно, что у Канбан есть противники, утверждающие, что другие концепции лучше. Между тем, эксперты призывают не путать метод Андерсона с другими признанными системами менеджмента - мол, это все равно, что сравнивать яблоки с апельсинами. Чаще всего, концепции Канбан противопоставляют:

• Agile;
• Scrum;
• Lean;
• Six Sigma;
• PRINCE2.

Между тем, Канбан и Agile похожи друг на друга, как братья, с той лишь разницей, что Андерсон предложил более широкий метод, тогда как Agile ориентирован в большей степени на IT-проекты. Оба метода предполагают эволюционные изменения, хотя в первом случае роль бизнесмена несравнимо более значительна, чем статус работника согласно аджайл-манифесту.

Если Канбан предполагает непримиримую борьбу с незавершенным производством, то философия Agile в этом плане либеральнее, так как ставит во главу угла гибкость - готовность к изменениям, которые «важнее первоначального плана».

Программисты проще смотрят на «заброшенные подпроекты», если найдена более оптимальная архитектура программного обеспечения. О том, что Канбан в России является действенным методом, могут рассказать компании Dostаевский, Chernika, uKit Group и другие.

Заключение

Канбан - это интуитивно понятный способ организации потока работ, который помогает бизнесмену делать больше, работать быстрее. Тем не менее, система «точно в срок» - не панацея от всех проблем, а инструмент, которым нужно уметь правильно пользоваться, внося ежедневно в рабочий процесс малозаметные изменения, которые в совокупности дают результат.

Отметим, что Канбан малоэффективен в сложных многоуровневых технологических системах, но почти идеально подходит для малого и среднего бизнеса.

Что такое методология kanban и как она позволяет выполнять задачи в поставленные сроки?

В условиях постоянной многозадачности и и большого количества заказчиков у любой системы рано или поздно случается перегруз. Сроки начинают срываться, ожидания не оправдываются, а система превращается в хаос. Сегодня я предлагаю познакомиться с такой методологией, как kanban. Данный подход обещает эффективно распределить ресурсы и решить все наши проблемы. Проверим.

Минутка истории kanban

Основа идеи kaban была придумана компанией Toyoyta Motors. Производитель автомобилей нес большие потери из-за неправильного распределения запасов и мощностей на производственной линии. Часть этапов производства могла простаивать, а часть была перегружена.

В 1959 году была предложена система управления производством, которая позволяла уравновесить все участки линии. Основной принцип заключался в том, что на каждом этапе рабочие вывешивали карточки с необходимым количеством деталей, которые передавались дальше по линии. Каждый следующий по производственной линии работник, брал себе именно столько деталей от предыдущего, сколько положено ему в карточке.

Таким образом у каждой детали была карточка, а излишков просто не могло быть. В итоге запасы не росли на участках, а каждый следующий рабочий получал ровно то количество деталей, которое ему было необходимо.

Давайте сформулируем что же такое kanban и перенесем его на разработку интернет продуктов.

Kanban, это система управления бережливыми производством (перевод с японского: «сигнал»/«карточка»), которая использует информационные карточки для передачи заказа на всех этапах изготовления. Простыми словами, мы отслеживаем весь путь продукта, от идеи до выхода “на полку магазина”.

Выше изображена kanban доска. Это основной инструмент отображения статуса по задачам. Главный принцип: мы видим на каком этапе производственного процесса находится та или иная задача. Плюс, отслеживается время на всех участках, то есть всегда можно обнаружить “ ” в системе и поработать с ними.

Количество столбцов вы определяете сами исходя из особенностей своего проекта. Важно, чтобы это были основные этапы, которые проходит ваш продукт. Пример выше, это плюс-минус основные этапы, которые проходит интернет продукт.

Применение методологии весьма широкое. Kanban используют для реализации проектов, управления службой продаж, производственных линий, it-разработки и даже для организации собственной жизни.

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал . Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

Принципы kanban

• Визуальное отображение задач. Все задачи должны быть представлены в виде карточек и отражены на доске. Очень важно обновлять статус задач. Например, если разработчики подготовили код и передали в тестирование, то карточка с задачей должна перейти в соответствующий столбец. Таким образом, любой участник команды в любой момент времени может посмотреть на каком этапе находится задача.
• Ограничение по столбцам WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства. Чтобы система рано или поздно не “захлебнулась” от потока задач, необходимо устанавливать ограничения. К примеру, на kanban доске выше в столбце Analisis (аналитика) у нас работают 2 человека и они могут обрабатывать не более 2 задач, нет смысла нагружать их больше, так как последующие этапы системы будут простаивать. Ограничение по столбцам подбираются опытным путем.
• Фокус на невыполненных задачах. Смотря на доску с задачами в первую очередь уделяйте внимание тем задачам, которые “подвисают” в том или ином столбце. Если у вас какой-то из этапов занимает больше всего времени, то попробуйте перераспределить ресурсы или же добавить людей, если есть такая возможность.
• Постоянное улучшение. Как только вы уравновесите нагрузку в системе, вам будет проще наблюдать за всем процессом в целом. Измеряйте время цикла (сколько задача висит в отдельном столбце, а сколько от момента попадания в To do, до релиза Done). Меняйте нагрузки в системе и сокращайте время на прохождение всех стадий.
• Уделяйте внимание мелочам. К примеру, если код, который пишут разработчики периодически не проходит тестирование и возвращается на доработку, то возможно, есть варианты улучшить качество разработки, чтобы в тест попадал более качественный продукт?

Подход kanban может показаться идеалистичным, но уверяю вас его принципы приносят результаты. В первую очередь необходимо адаптировать методологию под свою ситуацию, а после шлифовать систему.

Инструменты kanban

Или где вести kanban доску.

• Excel таблицы
• Доска со стикерами
• Еще фантазия…

На самом деле вариантов масса, можно погуглить и набраться вдохновения. Главное, чтобы у вас была эта доска и все участники процесса могли видеть, что происходит с задачами в данный момент.

Примеры kanban досок

Вот доска, которая висит на стене, где каждая задача отражена на стикерах.

Или же это может быть облачный сервис, типа Trello.

Есть ряд мнений по-поводу того, какие же инструменты и варианты использовать в работе, но это по-большей части вкусовщина. Просто попробуйте разные решения и остановитесь на том, которое больше понравится. Суть в том, чтобы начать использовать kanban, а не стопориться на использовании максимально красивой доски.

Мое мнение такое: для мозгового штурма или проработки кейсов в оффлайне хорошо работает обычная доска со стикерами. Но для повседневной работы само собой нужно использовать облачное решение типа Jira, Kanbantool, Trello и прочее. В них вся команда может добавлять комментарии к задачам, двигать их по столбцам и многое другое.

Нюансы/мыли

Если говорить об интернет продуктах, то kanban работает, помогает и улучшает, но есть ряд опасений или же нюансов, которые необходимо учитывать.

• Скорее всего введение лимитов WIP на столбец может немного напугать управленческий состав проекта. Ведь как определить сколько разработчик или, например тестировщик могут параллельно решать задач? А вдруг мы введем ограничения и они будут попросту прохлаждаться?

Понимаете, если человек не загружен на все сто, это не есть плохо. Он может обучаться и анализировать проделанную работу, находить недочеты и исправлять их, да пусть даже и отдыхать. Плюс, можно помочь товарищам с других частей процесса (столбцов), подробнее далее.

• Как утверждают гуру kanaban, система идеально работает в кросс-функциональных командах. Ну что-то вроде того, если тебе нечего делать, иди помоги товарищу по цеху. Правда, чтобы сколотить себе команду, где разработчики могут быть тестировщиками и наоборот, а архитектор системы поможет дизайнеру, нужно будет выложить немалые деньги, да и стоит ли?

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

Поэтому, я больше склоняюсь к оттачиванию своего скила, если уж выдалась спокойная минута. Посмотри, что сделал, подумай, как можно улучшить, почитай полезные статьи. Человек, это живой организм, а не шестеренка в конвеере.

Итого

Мы разобрали методологию kanban и теперь, надеюсь, вы понимаете как ее применить в своем проекте. Попробуйте разделить свои процессы на основные этапы и оптимизировать систему с учетом полученных знаний.

Вы когда-нибудь пытались собрать вместе группу людей, чтобы создать продукт или запустить проект? В качестве бонусов: жесткий дедлайн, объемное техзадание и несговорчивый заказчик. Получилось? Если да, то дальше можете не читать.

Управлять командой нелегко. Особенно в digital. Нужно организовать работу так, чтобы качество продукта было на высоте, дедлайны соблюдались, команде было комфортно, а заказчик остался доволен. Важно не допускать конфликтов и постоянно развивать команду.

Волшебной таблетки, чтобы разом решить все проблемы, не существует. Но есть методы и системы, которые помогут упростить процесс. Один из них ― Kanban.

Что такое Kanban

Kanban ― это метод улучшения процессов разработки и часть agile-философии. В его основе ― «Манифест гибкой разработки программного обеспечения».

Манифест гибкой разработки ПО

Цель Kanban ― получать готовый качественный продукт вовремя. Давайте разбираться, как этого добиться.

Kanban начинается с визуализации, чтобы процесс работы был на виду у команды. Для этого используют специальную доску и набор карточек или стикеров.

Доска ― это обязательный элемент для гибкой методологии. Она есть в Scrum, есть и в Kanban. Каждый член команды получает к ней доступ в любое время и может видеть, на каком этапе находится задача.

Доска может быть реальной или виртуальной: можно использовать простую пробковую или программы вроде Trello.

Kanban-доска ― универсальный инструмент, который можно подстроить под любой процесс и применить в любой области. Например, составить список дел.

Сначала нужно проанализировать процесс работы и разделить доску на столбцы, которые отражают этапы создания продукта. Например, для процесса создания IT-проекта этапы могут быть такими:

Названия столбцов можно менять в зависимости от проекта, но важно сохранять их последовательность. Доска должна полностью отражать процесс создания ценности, который в Kanban называют потоком.

Kanban-карточки ― это задачи, которые команда перемещает по доске в зависимости от их состояния. Количество карточек можно менять. На карточке или стикере пишут название задачи и прикрепляют в начало доски.

C помощью kanban-доски команда может вести несколько проектов одновременно, использовать карточки разных цветов: один цвет ― один проект.

Как помогает визуализация

Получить результат точно в срок возможно, если контролировать нагрузку. Для этого нужно ограничить количество задач.

В одном столбце kanban-доски одновременно находится столько задач, сколько команда реально выполняет в установленные сроки. Например, в состоянии «Проектирование» одновременно ― не больше двух задач, а в графе «Тестирование» ― только одна. Количество команда выбирает в зависимости от своих возможностей.

Пример

Разработчик еще не закончил с текущей задачей, а ему уже поступила следующая. Он не успевает и тормозит всю работу.

Решение: прекратить передавать задачи в разработку и дать программисту время закончить работу.

Важно найти баланс: выбрать темп работы, который удобен команде и не вредит срокам проекта. Для этого в Kanban учитывают время выполнения каждой задачи. Так команда понимает, что занимает больше времени, а что ― меньше, и может правильно организовать работу.

Пример

На этапе тестирования продукта возникли трудности и нужно больше времени.

Решение: выяснить, какую часть работы можно сделать быстрее, не потеряв в качестве. Или сотрудника, который свободен и поможет тестировщику.

На доске отражаются все процессы, а команда их анализирует и устраняет слабые места. В Kanban это называется управление потоком .

Чтобы использовать Kanban, мало просто повесить доску с карточками. Команда должна знать правила, по которым работает.

Это еще и про прозрачность процесса: когда работа - на виду и всем понятен результат.

Важна сплоченность, постоянное совершенствование продукта и развитие сотрудников. Команда в Kanban ― единый механизм. Если кто-то не справляется, то страдает общее дело. Работу планируют на доске, весь процесс на виду, поэтому каждый может увидеть свой вклад и ценность для проекта.

В Kanban смешались принципы agile-методологий и lean-мышления. Здесь нет жестких правил и кардинальных перемен, но есть принципы, на которые можно опираться.

Как не путать Kanban и Scrum

Kanban часто путают или объединяют с гибкой методологией Scrum. Чтобы с вами такого не произошло, давайте посмотрим, в чем основные различия.

Scrum ― это гибкая методология управления проектами, а Kanban ― метод улучшения любой методологии.

Нет совещаний

Нужна отправная точка

Могут работать узкопрофильные команды

Последовательные и плавные перемены

В команде нет разделения на роли

Есть совещания

Не нужна отправная точка

Команда, уже внедрила Scrum, но хочет продолжать совершенствовать процесс. Тут снова поможет Kanban.

Совсем не важно, какую методологию разработки использует команда, но чтобы внедрить Kanban, нужна отправная точка.

Как внедрить Kanban

Если вы решили использовать Kanban, то придется запастись терпением и научиться самодисциплине. Не стоит настраиваться на радикальные перемены и внедрять все практики сразу. Kanban ― это про последовательные и плавные улучшения. Возможно, вам не понадобится использовать все инструменты, чтобы добиться нужного результата.

Подведем итоги

Теперь вы знаете, что такое система Kanban, чем отличается от Scrum и как ее можно использовать. И уже готовы проверять все в деле. Теория ― это хорошо, но нужна практика. И лучше практиковаться без опасений, что одно неверное движение может навредить делу. Поэтому , который прокачает вас в управлении проектами. Вы сможете внедрять в свою работу любые agile-системы и будете уверены в результате.