Я думаю, что большая часть присутствующих знакома со мной по статьям на Инфостарте, тренингам и Infostart Event. Я расскажу про такой аспект своей деятельности, как консультирование и внедрение различных методов организации бизнес-процессов в компаниях. Буду говорить и про опыт Инфостарта, и про опыт ИТ-подразделений в других компаниях.
О докладчике
Прежде чем мы пойдем дальше, хочу сказать пару слов о своих увлечениях. Мои хобби: я капитан парусной яхты и добровольный лесной пожарный. В рамках этих видов деятельности хорошо понимаешь, что в любой нештатной ситуации гораздо лучше оказываться, если имеешь определенный алгоритм действий. Канбан – это про четкий алгоритм действий, который можно корректировать в зависимости от ситуации.
Канбан-доска и Канбан-система
Под словом «Канбан» понимают два разных понятия. С одной стороны, это Канбан-доска – инструмент, который используют. И с другой стороны, это Канбан-система – подход к работе в целом.
Канбан-доски
Я не буду агитировать за «советскую власть», но подавляющее большинство компаний Канбан-доски используют. На экране представлен фрагмент отчета The Version One, в котором проанализированы Agile-компании по всему миру. Среди всех инструментов, которые используют, лидируют именно Канбан-доски. Итак, около 75% компаний Канбан-доски используют.
Канбан-доски позволяют нам избавиться от иллюзий, что мы прекрасно все удержим в голове. Максим Дорофеев в своей книге «Джедайские техники» рассказал, что наш мозг работает, пользуясь эффектом «дырявого стека». Когда нам приходит срочная задача, мы бросаем все и начинаем заниматься ей. Когда приходит еще более срочная задача – мы переходим к ней.
Брошенные нами дела потихоньку погружаются на дно дырявого стека, пока не выпадут, и вся работа не провалится в трещину. Канбан-доска позволяет этого избежать, и задачи "падают на пол" только когда мы осознанно принимаем решение их не делать.
Второй аргумент за Канбан-доску: она помогает разобрать ситуации, когда у нас спорный вопрос «Кто является ответственным?».
В действительности во многих компаниях случается корпоративный пинг-понг, когда задачи перекидываются от одного к другому, и каждый считает, что это не его сфера ответственности. Канбан-доска позволяет выявить эту ситуацию, договориться, собрать совещание и назначить административно ответственного.
По поводу инструментов для Канбан-доски подробно говорить не буду: идеального инструмента не существует. Вот список досок, с которыми работают в моем окружении. Практически по каждому из них можно сказать, что кому-то этот инструмент нравится, а кому-то неудобно с ним работать.
Лидер во всей этой истории – Jira, продукт от Atlassian, который позволяет максимально четко организовать работу. Там хорошая аналитика.
Возвращаясь к отчету The Version One, мы увидим, что Jira находится на первом месте.
Приглядевшись к этому отчету мы увидим, что находится во втором месте. Вовсе не сложные специализированные инструменты, а Excel. Это еще раз подтверждает, что в каждой команде своя специфика и привычные инструменты для работы. Ведь что такое Excel? По сути, это решение, подстроенное под команду.
Альтернатива Jira – Trello, в базовой версии он бесплатный. Если он у вас зашел – можно использовать что-то более сложное. Если Trello использовать не получается – это признак того, что нет смысла инвестировать в более дорогое решение.
Есть масса решений на 1С, есть обработки на Канбан-доски. Я связалась с теми, кто скачивал эти обработки, и спросила, насколько это удобно. Получила тот же ответ, что и для других инструментов: кому-то нравится, а кому-то – нет.
Очевидное решение для 1С-ников – Bitrix24.
BPM в Инфостарте сделан на базе Bitrix. Это удобно для ситуаций, когда Канбан-доски нужно интегрировать с другими приложениями.
Сейчас я показываю доску – реальную доску одной из команд, где я внедряла Канбан-систему. Физическая доска считается наиболее удобным и универсальным инструментом. Как минимум, у нее три достоинства: она наглядна, к ней легко подойти, ее можно гибко подстраивать под ваши пожелания, ведь у любого автоматизированного решения есть ограничения, и это удобно для совещаний.
В условиях перехода на онлайн-рельсы этой команде тоже пришлось перейти на электронную доску, но они вернутся к физической, как только смогут. Я знаю внедренцев, которые отказываются внедрять какие-то решения на производстве без физической доски.
У доски есть недостатки. Один из наших пользователей сравнил такую доску с осенним деревом, с которого опадают разноцветные стикеры-листочки. Если уборщица решит прибраться, она куда-нибудь прилепит ваши задачи, и вы будете удивляться, что с ними стало.
В каждой шутке есть доля шутки: вы можете использовать магниты, кнопки, ну и, конечно, делайте бэкапы в виде электронной доски или фотографий.
Канбан-система
Интереснее поговорить про Канбан-систему. Это подход к организации работы, когда мы используем не выталкивающую систему – берем в работу столько задач, сколько нам ставят – а вытягивающую. То есть, берет в работу такой объем задач, который реально можем сделать. На самом деле, большой разницы нет, потому что мы в любом случае сделаем только тот объем задач, который можем сделать. И от того, что мы возьмем больше задач – они будут дольше висеть в работы, мешать, отвлекать и портить нам жизнь, а работать быстрее мы не начнем.
Канбан-доска построена на ограничении одновременного числа задач и лимитах Work and Progress, WIP-лимитах. На каждый бизнес-процесс эти лимиты ограничивают общее число задач, которые мы можем делать. Поскольку мы не взяли все запросы от бизнеса, те задачи, которые взяли в работу, мы завершаем быстрее.
Во многих компаниях ИТ-отделы воспринимаются как черный ящик. Туда задачи попали, когда они выйдут – неизвестно. Приоритеты расставляют сами разработчики, иногда как бог на душу положит. В истории с Канбан-системой, у нас более предсказуемая производительность.
В этом примере WIP-лимит у тестировщиков заполнен, две задачи из двух заняты. И хотя разработчики обе задачи закончили, ни одна из них не может уйти из разработки. Нужно, чтобы тестировщики хотя бы одну задачу отметили, как выполненную.
После этого готовая задача от разработчиков попадет в тестирование.
А аналитики передадут свою готовую задачу в разработку.
В нашей практике сложилась ситуация, как на текущем слайде, что кроме тестировщиков никто работать не может. Столбец пользовательского тестирования был заполнен скопившимися задачами, а пользователи, в данном случае бухгалтерия, говорили, что у них нет времени на проверку. Разработчики из-за этого вынуждены были простаивать, ведь они не могли переместить готовые задачи в раздел тестирования.
Что случилось бы без Канбан-системы? В раздел тестирования попал бы еще ворох задач, и они продолжили бы скапливаться. В Канбан-системе, за счёт ограничений на одновременное число задач в работе, двигать задачи дальше в такой ситуации нельзя. Благодаря этому мы получаем два важных результата. Мы замечаем бутылочное горлышко. Стало понятно, что нужно собрать совещание и организовать процесс тестирования, чтобы сделать то, что необходимо, и работать дальше.
Второе – у нас видны заблокированные задачи, проблемы, и есть общая мотивация решать их вместе. Например, усложнить этап технического тестирования, чтобы пользователи тестировали более готовый функционал. В нашем случае понадобилось модифицировать бизнес-процесс, потому что не все задачи можно проверить сразу: некоторый функционал можно протестировать только при сдаче следующего квартала, например.
Еще одно преимущество Канбан-системы – она позволяет убрать переключение между задачами. Поскольку в действительности, когда нам нужно решать много вопросов и одновременно держать в голове большое количество дел, мы теряем много времени, переключаясь между делами. Канбан-система позволяет этой ситуации избежать и уменьшить число переключений. Честно скажу, в моей практике совсем избежать их не получалось, но уменьшить точно возможно.
Немножко про практический опыт. WIP-лимиты можно фиксировать программно: Jira или BPM это позволяют. И если команда договорилась их не нарушать, это тоже сработает.
Если случился пожар, упал сервер, а бухгалтерия не может сдать отчет, мы можем превысить лимит. Но при условии, что срочная задача - только одна, и она проходит систему проверки, что она и правда срочная.
Про Канбан-систему важно помнить, что она состоит не только из доски. Есть ритуалы: стенд-ап совещания и другие мероприятия. Здесь схема немножко похожа на Scrum, но на ежедневном стенд-ап совещании нет необходимости задавать вопрос - что я сделал вчера и сегодня, потому что это и так видно на доске. Плюс к этому, Канбан-система предлагает диаграммы, которые показывают нашу производительность.
Следующий момент – Канбан-система – это четкие правила. Например, в какой ситуации задача считается взятой в работу. На практике во многих ИТ-отделах бизнес-заказчики накидывают большое количество задач с нечетко сформулированными требованиями.
В Канбан-системе фиксируется, при каких условиях задача может быть взята в работу. Эти же требования фиксируют, что именно мы считаем задачей. С другой стороны, фиксируется, какие у нас требования к приемке, и в какой момент задача считается выполненной.
На практике мне пока не приходилось сталкиваться с ситуацией, чтобы 1С-разработчики работали над одним проектом и ни на что не отвлекались. Чаще всего идет сочетание разработки и техподдержки. Что здесь можно сделать? Можно разделять по времени: сколько мы занимаемся текущими задачами, а сколько - проектами. Потому что есть тенденция, когда текучка начинает занимать все имеющееся время.
Есть притча про учителя, который клал в банку разные камни. Сначала крупные – банка наполнилась. Затем камни поменьше – банка заполнилась еще больше. Наконец, добавил песка – и в банке не осталось места. Если бы учитель начал с песка, то песок – текучка – занял бы все время. Но он начал с проекта – больших камней – он текучку тоже успел.
Еще хочу сказать два слова, почему в моей практике для 1С-разработки лучше подходит Канбан, чем Scrum. Основных аргументов, на мой взгляд, три. Чаще всего деятельность – это смесь проектов и поддержки, смесь операционной деятельности и разработки нового продукта, поэтому жестко поставить границы не получается.
Следующий момент – в 1С разработке как правило работает несколько команд: аналитики и разработчики. Сам по себе процесс разработки, на который заточен Scrum, занимает меньшую часть работы, иногда категорически меньшую. Когда задачи разнородные, их трудно уложить в фиксированные по времени спринты. Проще не привязываться к конкретному времени, а WIP-лимитам, делая задачи по блокам. И ничего страшного, что каждый блок займет разное время.
Поскольку дьявол в деталях – несколько моментов, в какой ситуации у вас выше шанс на успешное внедрение Канбан-системы.
Во-первых – управленческая воля. При помощи доброго слова и участия руководства у вас получится лучше. К чести руководства Инфостарта, оно при внедрении Канбан-досок начало с себя и настаивало на применении этого инструмента. Когда на совещаниях анализирует задачи по Канбан-доскам, и для сотрудников это стимул их использовать. Когда руководитель сам перестает пользоваться Канбаном, всё перестает работать.
Следующий момент – важно включать команду, чтобы доски были спроектированы с участием команды. Люди охотнее выполняют решения, которые были приняты с их участием.
Конечно, выбор удобного инструмента. Например, я знаю одного франчайзи, в котором часть задач живет в Bitrix24, а часть – в Trello. Им катастрофически неудобно, а когда мы работаем по принципу здесь пишем, здесь не пишем, здесь рыбу заворачиваем – получается странно.
Одной Канбан-доски мало, ее важно сочетать с базой знаний и мессенджером.
Важно помнить, что автоматизированный хаос – это быстрый хаос. Оттого, что вы запускаете Канбан-доску – это вам ничем не поможет, если ваши бизнес-процессы в хаосе.
Пример выстроенного процесса одной из команд.
Важно, что здесь есть процессы «техническое тестирование» и «документирование». Когда этих столбцов нет – все волшебным образом забывают про них. Разработчики сразу передают пользователям на функциональное тестирование якобы рабочий продукт или забывают про документацию.
Это такой способ контроля, в том числе для руководства. Начальник ИТ-отдела однажды гордо рассказывал мне, что после внедрения Канбан-доски он может встать ночью и рассказать, как идут дела с проектами у его подчиненных. До Канбан-доски такой возможности у него не было. Не только благодаря доске, конечно, но совещаниям и другим атрибутам Канбан-системы.
Что еще важно? Наглядность и визуализация. Например, разноцветные теги. Должны быть видны заблокированные задачи, по которым мы не можем работать. Они занимают WIP-лимиты, и все должны быть заинтересованы в их скорейшем решении.
Я люблю для тегов использовать матрицу Эйзенхауэра. Самый главный, на мой взгляд, квадрат матрицы – в котором собраны несрочные задачи, от них зависит наши развитие. В пылу текучки мы про них забываем, но если их не делать, не получится внедрять какие-то комплексные изменения.
Важно, чтобы были видны ответственные. Важно, чтобы были видны сроки. Например, если задача 70 дней находится в одном бизнес-процессе - это признак того, что с ними что-то не так.
Канбан-система позволяет наглядно увидеть, какие у нас есть проблемы, четко расставить приоритеты и быстрее завершать взятые в работу задачи.
Как внедрять Канбан-систему на практике
Краткий список разной литературы, сайтов и видео.
А еще я предлагаю поиграть в игры:
Если надумаете внедрять Канбан-систему, советую поиграть в игру GetKanban. Она требует полдня как минимум. За это время мы раскручиваем месяц работы ИТ-компании.
Игра попроще – это TWIG. В нее нельзя выиграть, можно стать мудрее и посмотреть, как это выглядит на практике.
В наше непростое удаленное время рекомендую игру FutureBan, в которой удаленно разыгрывается три итерации. С доской и без лимитов, с доской и лимитами, а дальше знакомитесь с разными графиками, чтобы оценить производительность.
В частности, с участниками курса по управлению ИТ-проектами мы в эту игру играли, и участники соглашаются, что Канбан-система становится понятнее, если пройти игру. Командные KPI работают лучше, чем личные.
Спасибо за внимание, попутного ветра вашим проектам!
*************
Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Saint Petersburg.Online.
