Kanban — как наконец внедрить

Сегодня мы представляем запись интервью с Александром Торгашовым, деливери-менеджером одного из крупнейших банков России — «Т-банка». Александр делится своим опытом работы с методологией Kanban, рассказывает о распространённых мифах, подводных камнях и практических инструментах, которые помогают командам становиться прозрачнее и эффективнее. Интервью будет полезно как начинающим, так и опытным менеджерам, а также всем, кто интересуется Agile-подходами и эволюционным улучшением процессов.

Анна Сабадаш:

На связи «Софториум». Сегодня у нас в гостях Александр Торгашов, человек, который знает о практиках Kanban все.

Александр Торгашов:

Надеюсь, что я знаю все. Всем привет.

Анна Сабадаш:

Александр работает деливери-менеджером в крупнейшем банке Российской Федерации а, может быть, в одном из крупнейших в мире — «Т-банке». Управляет 12 проектными командами и ведет свой телеграм-канал «Я деливери-менеджер» https://t.me/iDeliveryManager. Мы задумывали этот стрим для тех, кто только начинает внедрять практики гибкого управления, практики Kanban.

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

Александр Торгашов:

Есть, наверное, три основных мифа о Kanban. Первый, что Kanban-доска — это просто какая-то доска в каком-то таск-трекере: в Jira, Kaiten, еще где-то. Второй миф, что это пришло от Toyota, и это производство, конвейер. А третий миф, что Kanban подходит только для поддержки какого-то продукта, что это саппорт, который для других команд не подходит.

Суть в том, что Kanban — это просто метод управления процессами и их улучшения. У вас есть какая-то команда, которая производит виртуальный продукт, например мобильное приложение или какой-то сайт, и вы хотите понимать, как вам улучшать ваши процессы, как работает ваша команда, что вам потренировать.

Для этого Kanban-метод и нужен, он подходит, по моему ощущению, на любом этапе развития вашего продукта. У вас стартап, у вас уже есть какая-то аудитория, какие-то клиенты, у вас уже стабильный продукт, его можно прикрутить к чему угодно. И вот этот миф, что Kanban подходит только для саппорта, только для поддержки, — неверный, его можно везде использовать. То есть Kanban — это просто метод улучшения управления вашими процессами. Вы можете что-то использовать из Kanban, что-то не использовать, вы можете какую-то часть внедрить потом, то есть там очень много вариаций, и вы можете использовать все из Kanban.

И методы, и практики, которые там есть, они супербазовые. У вас, наверное, есть какая-то доска, с которой вы работаете, и у вас есть визуализация вашей работы. Это одна из первых практик Kanban — визуализировать свою работу.

Анна Сабадаш:

То есть первое — внедряем систему управления проектами. У нас это YouTrack, также может быть Jira или Trello.

Если у нас есть Kanban-доска в Jira, значит ли это, что у нас уже внедрен Kanban? С какого размера команды можно начинать внедрять методологию Kanban?

Александр Торгашов:

Смотрите, вот у Kanban есть практики. Практика отвечает на какой-то вопрос и решает какую-то проблему, какую-то боль. Внедрять практику просто ради внедрения не имеет смысла. У вас должна быть какая-то боль, вы ее хотите решить. И вот первая практика, про которую говорил, — визуализация. Она отвечает на вопрос, что происходит с вашими задачами, где они сейчас находятся и сколько им еще нужно этапов производства пройти, чтобы завершить процесс. Если у вас визуализация на доске уровня «Готова к работе», «Завершена работа», это визуализация, но на вопрос, что происходит с задачей, она не отвечает. Если она находится в работе, это не говорит о том, что происходит с задачей.

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

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

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

Анна Сабадаш:

То есть доска, как все гибкие инструменты может содержать любое количество столбцов и с любыми названиями?

Александр Торгашов:

Если у нас базовое производство какого-нибудь продукта, ну, допустим, мы делаем приложение для продажи товаров. У вас есть этап производства, у вас есть сначала какая-то идея, она появляется в основном у бизнеса, что вот эта гипотеза говорит о том, что, если мы ее превратим в фичу… Давайте сразу определим, что такое фича. Фича — это какой-то новый функционал или текущий функционал, который подвергается изменению.

Будем называть это фичей. Бизнес решил придумать эту фичу, он ее придумал, обосновал и передал вам в разработку. У вас, скорее всего, будут какие-то предварительные статусы: это подготовка к разработке, проведение встречи, когда вы с вашим продакт-менеджером, с разработчиком, с QA встречаетесь. Продакт-менеджер приносит какую-то подготовленную спецификацию, ТЗ по вашему шаблону, по какому-то формату, который у вас есть, и вы ее обсуждаете.

Вот вы какие-то предварительные версии прошли, а потом у вас начинается стандартный этап производства, который требует разработки, требует тестирования, требует код-ревью, требует подготовки к релизу, например, если у вас релиз в Google Play или в App Store, вам надо подготовительные моменты провести. Требуется дизайн-ревью провести. Это вот основные этапы: разработка, ревью, тестирование, подготовка к релизу, релиз.

Между этими этапами у вас могут быть буферные зоны, когда у вас один этап производства завершен, завершена разработка, но тестирование еще не готово взять задачу в тестирование, у вас есть буферный статус типа «Ожидает». И такие буферные статусы могут быть везде. «Ожидание ревью», «Ожидание дизайна», «Ожидание взятия в разработку» — такой тоже может быть буферный статус. И вы это настраиваете. Чем детальнее декомпозирована ваша доска, тем лучше она отвечает на два вопроса.

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

Визуализация — это самая базовая практика. И так в любом фреймворке.

Это не Kanban придумал, это нормальная работа — все визуализировать.

Анна Сабадаш:

Какое, по твоей практике, самое большое количество столбцов было на доске?

Александр Торгашов:

Есть деливери-менеджер, он занимается end-to-end-процессом. Это когда у тебя есть подготовительный этап, Discovery, когда ты эту фичу прорабатываешь, проводишь какие-то исследования, доказываешь, что ее надо делать. И этап Delivery, когда ты уже все доказал, написал документацию, что ты ожидаешь заработать столько-то денег.

В моем (проекте), наверное, было где-то 13-14 столбцов, которые показывали движение фичи от момента идеи до момента, когда она появилась у клиента в приложении и он смог его использовать. Тринадцать статусов, и они отображали, что происходит с задачей. В нашем случае только на этапе Discovery порядка шести статусов было, у кого-то меньше будет.

Анна Сабадаш:

Ну не так страшно звучит.

Игорь Мазайкин:

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

Александр Торгашов:

Где-то автоматически происходит, можно настроить автоматизацию Jira, где-то надо переводить руками, например, ты отправил на ревью или смежить что-то, у тебя смежилось — и задача подвинулась автоматически. Или у тебя прошел какой-то этап, ты на него навесил автоматизацию, что если задача прошла этот столбец, то ты можешь автоматически перевести ее в другой столбец. То есть в основном, наверное, соотношение 70 на 30.

Семьдесят — руками надо двигать, тридцать — можно настроить автоматизацию, но это конкретно для Jira-трекера. Возможно, в другом можно больше автоматизации навесить, и это чисто проблема инструментов.

Игорь Мазайкин:

С автоматизацией понятно, там компьютер, мы его заставляем, и он безотказно работает. А что делать с людьми, если возникают отказы?

Александр Торгашов:

Ну это база, с которой надо начинать, это Jira-гигиена, когда какие бы ты там визуализации ни делал, какие бы ты метрики ни собирал, если команда не держит задачу в актуальном статусе, то это все бесполезно. То есть ты собрал метрику, у тебя получилась цифра 200. А на самом деле у тебя 190 дней задача валялась в каком-то статусе, про нее давно забыли и давно ее уже реализовали, выкатили на прод, она работает. Просто в таск-трекере ее забыли подвинуть, такое бывает, это нормально.

Это надо работать как тимлид либо деливери-менеджер, скрам-мастер, проджект-менеджер, как угодно это можно назвать, с командой и объяснять, зачем это нужно: держать задачу в актуальном статусе. Самое первое: ее нужно держать в актуальном статусе для того, чтобы команда могла ответить на вопрос бизнеса, тимлида, кого угодно, кто приходит в команду и говорит, вы делаете медленно.

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

Ну и сначала это можно делать на дейлике, прямо вот открывать дейлик. Кто ведет дейлик, тимлид, проджект-менеджер, скрам-мастер, — не имеет значения.

Первое время надо прямо у людей спрашивать, в каком конкретном статусе стоит задача. Это дело привычки. То есть первое: надо объяснить команде, зачем это, а не просто всех бить палкой за то, что задача не в актуальном статусе. А второе — такое приседание периодически: на каждом дейлике две недели поспрашивать, потом люди будут сами все делать. Ну, либо, если кому-то очень тяжело двигать задачу по статусу, придумать какую-то автоматизацию и как-то это упростить. Такое тоже может быть.

Игорь Мазайкин:

Да, у меня с этим проблема. Наверное, надо на табличку твои слова написать и приколотить где-нибудь.

Анна Сабадаш:

Какие слова на табличку?

Игорь Мазайкин:

Содержать задачи в актуальном статусе.

Александр Торгашов:

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

Игорь Мазайкин:

Ну и об автоматизации все-таки надо подумать, особенно насчет задач, которые зависли, забылись и так далее, чтобы автоматика о них напоминала.

Александр Торгашов:

Ну да, у нас есть такие боты, которые нам в мессенджер пишут сообщение, что эта задача 20 дней лежит в бэклоге. Она актуальна? Проверьте, она вообще нужна? Уровни этого, сколько дней она лежит, все настраивается, и людям действительно напоминает: человек быстренько зашел, посмотрел и, если она не нужна, удалил эту задачу.

Анна Сабадаш:

Допустим, мы внедрили доску, и у нас даже есть Jira-гигиена. Мы знаем такие слова. На этом этапе можно сказать, что у нас уже Kanban?

Александр Торгашов:

Я говорил, что внедрить Kanban нельзя, работать по Kanban нельзя. Можно использовать принципы и практики из Kanban, чтобы улучшать свои процессы. Если нам надо прийти и кому-то сказать, что мы перешли на Kanban, у нас теперь Kanban, когда речь о доске, то да, это нормально. Никто вас за это не отругает. Главное — вы понимаете, что у вас есть. После того как вы внедрили доску, надо дальше решать проблемы, какие есть в команде.

Анна Сабадаш:

Как правило, проблемы связаны с эффективностью и с прозрачностью для заказчиков. Что мы еще можем сделать и какие еще практики Kanban нам нужно использовать, чтобы продвинуться дальше в нашей цели: быть эффективнее и прозрачнее?

Александр Торгашов:

Слово «эффективность» — очень крутое. Эффективно — это как? Это, наверное, мы должны давать какой-то прогноз нашим заказчикам, за сколько мы выполним эту задачу. Заказчик должен понимать, что задачу взяли в работу и что она через столько-то дней будет готова. Поэтому после того, как вы визуализировали свою работу, вам надо найти точку коммитмента, точку принятия обязательств, когда команда обязуется и говорит заказчику, что мы эту задачу выполним.

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

В основном у вас на доске есть предварительные статусы, где вы подготавливаетесь, проводите «Три Амиго», прорабатываете архитектуру, может быть, тест-кейсы пишете и так далее. Это предварительные работы, чтобы минимизировать возможность, когда вы задачу взяли в работу и не смогли ее выполнить, потому что технически она невозможна. Либо вы ее взяли в работу — и появились новые требования, либо вы ее взяли в работу, а оказалось, что заказчик совсем другое хотел. Вы ее выполнили, а она оказалось другой. Вот у вас есть точка коммитмента, где вы все как команда объединились.

Kanban в чем хорош, что это фокус на всей команде. Вы как команда даете обещание заказчику, что выполните задачу. Точка принятия обязательств, в основном это статусы, которые показывают, что работа началась, «В работе», «Разработка», «in progress».

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

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

В основном эти знания надо накопить. Это, наверное, один из минусов Kanban, что у вас должен быть какой-то запас накопленных знаний.

Анна Сабадаш:

Мы сейчас моделируем ситуацию, когда мы на начальном этапе, у нас еще, допустим, не накоплены эти знания. Что делать в этом случае?

Александр Торгашов:

Копить. Тут нет другого решения. В чем разница между предварительной оценкой задачи и метрикой, которая у вас есть? Предварительная оценка задачи — это всегда прогноз. Вы даете прогноз на основе чего-то: своей экспертности, экспертности команды, того, сколько разработчиков у вас в команде, вы даете просто прогноз. И в большинстве случаев этот прогноз не сбывается. Наверное, у каждого есть куча историй, когда вы оценили задачу в один день, а по факту выполняли ее десять дней, потому что что-то не учли, потому что ее делал не senior, а делал джун, потому что кто-то уволился, ушел в отпуск и тд.

Есть куча факторов, которые влияют на ваш прогноз. А метрика — это факт, то есть вы сто задач выполнили, и эти сто задач по 85-му персентилю вы выполняете за 30 дней. Это вам говорит о том, что сто первую задачу, которая к вам придет, вы будете выполнять по 85-му персентилю за 30 дней, либо раньше, но есть исключение. Что такое 85-й персентиль?

То есть вы 85 % задач выполняете за 30 дней. У вас есть количество и в меньшую сторону, и в большую. То есть вы не обязательно 85 % задач выполняете за 30 дней, но это максимальное значение. У вас есть задачи, которые выполняются за два дня, за пять дней, за 27 дней, но 30 — это максимально по 85.

А есть задачи, которые за 85-й персентиль вылетают и выполняются дольше 30 дней. Тут надо каждую такую задачу разбирать и искать причины. Поэтому, пока вы не накопите знаний, факта у вас не будет. Вы можете давать какие-то прогнозы, но, скорее всего, они в лучшем случае на 50 % будут сбываться. Нужен ли кому-то такой?

Вы можете давать прогнозы, пока не накопите знаний.

Анна Сабадаш:

Мы в любом случае будем давать прогнозы, потому что у нас всегда есть заказчики, для которых это жизненно важно. Скажи, вот персентиль — это термин из статистики. В каком объеме деливери-менеджеру нужно знать такой предмет, как статистика? В других метриках он пригодится?

Александр Торгашов:

Мне кажется, это не только деливери-менеджеру надо знать, любой человек, который работает с данными, должен знать, что такое персентиль: бизнес-аналитик, системный аналитик, еще какой-то аналитик, разработчик, потому что это, мне кажется, еще и с математикой связано, это не только навык деливери-менеджера.

Анна Сабадаш:

Немножко хочу вернуться. Ты вскользь упомянул про такую всем понятную практику, как «Три Амиго».Расскажи подробнее.

Александр Торгашов:

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

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

У вас есть, наверное, в команде человек, который пишет ТЗ. Он называется по-разному. Бизнес-аналитик, продакт-менеджер, Product Owner, как угодно. Просто какой-то бизнес-чувак, который пишет ТЗ. Вот он написал это ТЗ, и он является инициатором встречи. Он берет и зовет туда второго амиго и третьего амиго. Второй амиго — это разработчик, который будет выполнять эту задачу. Если у вас в команде есть один iOS-разработчик и спека для iOS, значит, будет выполнять именно он и никто другой.

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

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

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

Если это требует еще какой-то проработки, затянется на две-три недели, то тут надо бизнесу говорить, что мы делаем то, что в ТЗ, новые требования переноси, и мы будем заново проходить «Три Амиго», заново это все делать, заново запускать задачу в работу. Поэтому «Три Амиго» — это такая базовая практика.

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

Анна Сабадаш:

Какие метрики лучше всего помогают целям прозрачности, управляемости и эффективности?

Александр Торгашов:

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

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

Что это за метрики? Первая метрика, о которой я говорил, — это Lead Time. Это метрика от точки коммитмента, когда вы закоммитились и дали обещание, до момента, когда вы зарелизили задачу и она появилась в Google Play, клиент скачал продукт и смог им пользоваться. Это метрика Lead Time.

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

Еще эта пропускная способность может разделяться на типы задач. Вы же делаете не только фичи, не только бизнесовые задачи выполняете, а вы делаете техдолг, исправляете баги, у вас, возможно, есть какое-то техническое развитие. То есть можно смотреть пропускную способность по типам задач и видеть, что за сентябрь вы из 20 задач исправили десять багов.

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

Это вторая метрика — пропускная способность. Метрик очень много, есть метрика Cycle Time. Если Lead Time — это метрика от коммитмента до завершения, до релиза задачи, то Cycle Time — это метрика от точки коммитмента до технической готовности задачи без учета потраченного времени на релиз, потому что в основном, когда команда выполняет какую-то задачу, она может на эту задачу влиять до релиза, а релиз уже вне рамок этой команды.

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

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

Допустим, из 30 дней столбец тестирования занимает у вас 27 дней, то есть три дня статус идет по всем остальным столбцам, а 27 — он застревает в тестировании. Я просто привожу пример, а не тестировщиков обижаю. Такой срок — это уже сигнал, что, может быть, у нас мало тестировщиков, может быть, они вообще не знают, что есть какая-то доска и там есть какие-то задачи. Что-то с ними надо делать, может быть, тестировщик очень тщательно тестирует, а надо как-то поверхностно пройтись.

То есть это как раз то, что вызывает вопрос. Вот четыре такие метрики: Lead Time, пропускная способность команды, Cycle Time и Время статуса, можно так назвать эту метрику.

Игорь Мазайкин:

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

Александр Торгашов:

Не обязательно. Вот смотрите, как я и говорил, метрики меряются в основном по 85-му персентилю. У вас стопроцентно будет задача, которая по 85-му персентилю будет выбиваться. Поэтому не имеет значения, какого она размера.

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

То есть не надо специально нарезать задачи. Это не имеет значения. Не надо пытаться хакнуть метрику. Надо просто делать задачу, а потом смотреть, сколько времени она у вас занимает. И исследовать, из-за чего столько времени уходит.

Анна Сабадаш:

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

Александр Торгашов:

Ну, наверное, выработать какой-то шаблон вашего технического задания, чтобы у вас был прямо шаблон, в котором написано, что здесь должно быть: А, Б, В. Пока этого нет и вам этого не принесли, вы можете объяснять, что вы задачу в работу не возьмете, потому что это приведет к появлению новых требований из-за того, что вы всего не учли в ТЗ.

Или вот классика. Бизнес принес задачу, вы ее выполнили, бизнес начинает проверять — а сделали вообще не то, что он хотел. Ужасно! Хотел одно, в ТЗ написал второе, получил третье. Чтобы этого избежать, придумали три практики, которые называются Definition of Done, Definition of Ready и Acceptance Criteria.

Что это такое? Это договоренности внутри вашей команды, что Definition of Ready (DoR) — задача готова к работе, Definition of Done (DoD) — задача считается завершенной и Acceptance Criteria (AC) — это конкретно критерий приемки для каждой фичи. То есть, допустим, бизнес пишет свои критерии приемки для этой фичи, какие-то условия. Для другой фичи они могут различаться, а вот Definition of Ready и Definition of Done — они для каждого этапа производства всегда одинаковы.

Вне зависимости от того, какую фичу вы взяли в работу, у вас написано: чтобы из разработки ее перевести в тестирование, вы должны сделать такой-то чек-лист. Это Definition of Done, то есть из одного статуса в другой перевели. Или, наоборот, у вас есть какой-то бэклог, вы хотите взять в работу задачу, у вас есть Definition of Ready, это тоже чек-лист, в котором написано, что должно быть в задаче, чтобы ее взять в работу.

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

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

Анна Сабадаш:

Хорошее предложение. Являются ли ретроспективы и дейлики обязательными практиками управления проектами по методологии Kanban?

Александр Торгашов:

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

Анна Сабадаш:

Когда же они работают?

Александр Торгашов:

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

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

Есть ретроспектива команды, есть обзор поставки, обзор с заказчиком вашего всего процесса разработки производства.

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

Игорь Мазайкин:

Александр, ты сейчас затронул такую тему. Закончили задачу, чтобы быстрее взять следующую. Сколько задач одновременно может быть в работе? Твои рекомендации.

Александр Торгашов:

Одна из практик Kanban — это WIP-лимиты, которые ограничивают вашу работу и дают сфокусироваться. Есть замечательный лозунг в Kanban «Прекратите начинать, начните заканчивать». Не надо постоянно начинать новую работу, надо заканчивать ту, которая у вас есть. И вот WIP-лимит — это work in progress, это фокусировка на задачах одновременно, сколько у вас может быть в работе.

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

Но если вы часто блокируете задачи по каким-то причинам, заблокированные задачи WIP-лимит отжирают. Можно здесь подстраховаться и заложить дополнительные 20 %. У вас будут все те же пять разработчиков, а WIP-лимит — 12. Но WIP-лимит устанавливается в моменте и может постоянно пересматриваться. Не должно быть такого, что вы его установили и он на всю жизнь с вами: вы не можете его ни увеличивать, ни уменьшать.

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

Игорь Мазайкин:

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

Александр Торгашов:

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

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

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

То есть не обязательно его работа — это какой-то таск в Jira или в другом трекере, который нужно взять и делать. Он может чем-то другим заниматься. Надо просто об этом договориться, об этом рассказать, чтобы для всех это было нормально. Потому что есть такой уровень менеджмента, что для них это невозможно, что разработчик сидит без работы.

Игорь Мазайкин:

У меня следующий вопрос как раз о том, как ты борешься с перекосом, когда у тебя, например, бэкенд уже ускакал вперед, а фронт еще не успевает. Я так понимаю, ставить на паузу, заниматься чем-то другим?

Александр Торгашов:

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

Игорь Мазайкин:

Как понимаю, это больше касается продуктовой разработки?

Александр Торгашов:

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

Игорь Мазайкин:

Я хотел еще Swimlane затронуть.

Александр Торгашов:

Swimlane — это инструмент Jira. Если с Kanban соотносить, это классы обслуживания. В Kanban есть классы обслуживания, которые нам говорят, что это какой-то вид работ, который делает команда. Там четыре класса обслуживания, первый класс — это «Экспедит» (Expedite) — класс обслуживания, когда надо все бросить и делать только его, ничего другого.

Это в основном тушение какого-то пожара. У вас какая-то критическая ошибка на проде, у вас какой-то супербаг или вас удалили из стора и вам надо что-то придумать. Вот это «Экспедит» (Expedite).

Что такое Swimlane, если кто-то в «Джире» (Jira) не понимает? Вот есть Jira, доска, там есть колонки, которые идут как такие черты, они чем-то объединяются.

И получается, что «Экспедит» (Expedite) — это то, что надо тушить. Следующий класс обслуживания — это задача с какой-то фиксированной датой. Она называется Fixed Date. То есть это задача, которая должна быть сделана к определенной дате. И эта дата чем-то обоснована.

Всегда люблю приводить этот пример. Центробанк выпустил какое-то обязательство, что все банки к первому января должны делать вот это. И тебе нельзя нарушить его распоряжение. В теории ты его можешь нарушить, но это плохо закончится. Ты получишь какие-то штрафы, отзыв лицензии или что-то такое. Поэтому к первому января, это фиксированная дата, ты должен сделать задачу. До какого-то момента у тебя будет класс обслуживания Fixed Date, но, если ты понимаешь, что ты не успеваешь к первому января сделать, или у тебя мало времени осталось, она (задача) может перейти в класс «Экспедит» (Expedite), когда надо все бросить и ее выполнять, если по срокам затянешь.

Третий тип класса обслуживания — это стандартный, это такая же задача, как и вторая с Fixed Date, только у нее нет конкретной даты, к которой ее надо выполнить. Ее надо просто выполнить, если у вас команда уже накопила эти знания, у вас есть метрики, вы можете сказать, что мы ее выполним за 30 дней. Обычная стандартная задача. И четвертое — это такая неважная обычная задача, которая сейчас неважна, ее можно какое-то время не выполнять, но наступит момент — и она станет суперблокером, ее надо будет все равно выполнить.

Здесь иногда приводят технический долг как пример. У вас есть какой-то накопленный технический долг, вы его не делаете, не делаете, не делаете, а потом у вас — бах, и продукт перестает работать из-за этого. Аналогия не совсем верная, но понятная. Эти классы обслуживания Swimlane вы можете разделять. Можно по-другому их использовать в Jira. Например, у вас есть какие-то цели. Вы ставите себе цель на квартал, на год. Все задачи, которые под Swimlane, должны к этой цели относиться. Но это уже вопрос больше про инструмент, поэтому, если достаточно, можем пойти дальше.

Анна Сабадаш:

Хороший инструмент. Мы вернемся на уровень внедрения практики Kanban. Какие наиболее частые проблемы испытывают команды, которые внедряют эти практики, метрики, и что с этим можно делать? Есть ли какой-то накопленный опыт, который можно сейчас обобщить?

Александр Торгашов:

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

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

Вы внедрили WIP-лимиты, теперь внедряйте следующую практику. Внедрите Acceptance Criteria (критерии приемки), DoR и DoD. Потом с точкой коммитмента поработайте. Начните управлять потоком, а не людьми. У вас должна выстроиться такая задача, которая просто тянется слева направо. Ничто их не блокирует, они предсказуемы, понятны и нигде не застревают.

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

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

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

Анна Сабадаш:

Ты сейчас затронул уровни развития компании с точки зрения Kanban-зрелости?

Александр Торгашов:

Есть не Kanban-зрелость, есть Kanban Maturity Model. Это такая карта, которая показывает уровень зрелости команд и компаний. В словосочетании Kanban Maturity Model слово Kanban можно убрать. Оно никак с Kanban не пересекается. Просто команды проходят определенные уровни зрелости, а потом уже начинается уровень зрелости компании.

Их всего шесть: с нулевого по шестой.

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

У меня на канале была статья об этом. Тут проблема в том, что не только надо переходить на следующий уровень, как-то растить зрелость в команде, надо понимать, зачем команде переходить с нулевого на первый уровень, для чего. Если есть понимание, для чего, есть какая-то проблема, то можно перейти. А если этого понимания нет, нет никаких проблем, все устраивает — не надо переходить на следующий уровень просто из-за того, чтобы перейти и кому-то сказать, что мы Maturity Model посмотрели и мы типа относимся ко второму уровню, поэтому мы молодцы.

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

Анна Сабадаш:

Где совсем хаос — это ноль, а лучший — это шестой. Ответ на вопрос, зачем, очевидно, чтобы стать лучше. Шестой — это лучше, чем пятый.

Александр Торгашов:

А зачем становиться лучше, для чего?

Анна Сабадаш:

Чтобы быть эффективнее, прозрачнее, полезнее, больше денег зарабатывать.

Александр Торгашов:

Становиться лучшим не равно быть эффективным. Перейти на новый уровень не равно быть суперэффективным. Ты можешь быть на втором уровне суперэффективным, а на шестой тебе и не надо идти. Был доклад на одной конференции по теме этой модели, у нас в России есть компании, которые достигли четвертого уровня, это максимум. Есть ли вообще в мире шестой уровень?

Анна Сабадаш:

А четвертый уровень, это какие, например, компании и что их характеризует?

Александр Торгашов:

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

Анна Сабадаш:

Отраслеобразующая компания, может быть?

Александр Торгашов:

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

Анна Сабадаш:

Сама за клиента решает, что ему будет нужно?

Александр Торгашов:

Да, она задает тренд, формирует рынок, я сейчас не готов назвать такие компании. Когда у всей команды такой уровень, там все просто: вы в команде все настроили и работаете. А то надо строить всю компанию с нуля. Я не знаю, возможно ли такое вообще.

Анна Сабадаш:

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

Можешь рассказать об этом? В какую сторону эволюционирует эта методика? Есть ли представление о том, что на смену этим методологиям, этим практикам уже приходит или будет приходить что-то еще более удобное, новое, прогрессивное? Как это видится?

Александр Торгашов:

Kanban старый, да, только не надо его сравнивать с другими. Именно Kanban, который мы используем в IT, появился в 2007 году в компании «Майкрософт», и придумал его человек (Дэвид Дж. Андерсон), который не является айтишником, а он, по-моему, экономистом был, ему надо было задачи свои упорядочить. Вот он с 2007 года, наверное, вообще никак не изменился. Он только стал более популярным.

Есть теория ограничений, из которой заимствовано что-то в Kanban. Ограничения, узкие горлышки, уязвимости. В России есть Kanban-тренеры, как есть Алексей Пименов, это пионер Kanban, который продвигал его и сделал, мне кажется, популярным в России среди айтишников.

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

И что придет ему на смену? Ну, может быть, ИИ что-то придумает, искусственный интеллект. На все потребности отвечает Kanban, надо просто правильно подойти к нему, и он улучшает процессы внутри вашей компании, команды. Он может использоваться в IT, он может использоваться на производстве мебели, в деревообрабатывающей промышленности, еще где-то, где есть какое-то производство.

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

Анна Сабадаш:

В общем, он еще молодой, будущее у него впереди?

Александр Торгашов:

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

Анна Сабадаш:

Отлично. Тогда еще небольшой вопрос про мертвый Agile. Ты тоже в свое время затрагивал эту историю. Kanban — это же такая неотъемлемая часть методологии Agile, и ты поднимал на своем канале тему про дискуссию, которая, в свою очередь, в LinkedIn возникла, о том, что Agile отмирает. Какие там были тезисы:

· Agile стал чек-листом вместо философии.

· Ориентация на быструю реализацию проектов заменяет фокус на качестве и реальной ценности.

· Игнорирование человеческого фактора привело к выгоранию снижения вовлеченности.

Что ты думаешь про эти тезисы? Насколько они угрожают успешности применения гибких методологий? Насколько они имеют место?

Александр Торгашов:

Вопрос больше философский, наверное. Все зависит от контекста. В какой-то команде Agile, может, уже умер, а в какой-то, наоборот, он только сейчас приходит, расцветает, находится в полном расцвете сил. Конкретно в России, наверное, он перерождается, но это сугубо мое мнение. Я, например, еду на конференцию, где сначала будет доклад с темой «Agile умер», а за ним следующий доклад — «С Agile все хорошо».

И вот все зависит от контекста, надо смотреть на личный опыт. Возможно из философии он превратился в инструмент, но, мне кажется, он не умер точно, все зависит от контекста.

Анна Сабадаш:

Может быть, просто где-то его практика применения не очень правильна.

Александр Торгашов:

Где-то, может, да, кто-то считает, что он работает по Agile, а на самом деле это какой-то свой фреймворк или метод, который никак не похож на Agile.

Анна Сабадаш:

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

Александр Торгашов:

В IT вообще куча всяких терминов, которые мы используем, какие-то английские слова, которые означают что-то, и мы это все понимаем. Простым языком уже много всяких различных книжек написано, где просто по-русски объясняется, что такое Kanban. Могу прорекламировать книжку Алексея (Алексей Пименов. Канбан Метод. Базовая практика). Там вообще все написано. Вот есть много книг о Kanban, у Алексея написано все то же самое, только простым, доступным языком, не для IT.

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

Анна Сабадаш:

Можем ли мы рекомендовать нашим слушателям, которые пришли сюда не просто посмотреть на нас, а узнать что-то о том, как лучше внедрить в себя эти методики, его книгу как самоучитель?

Александр Торгашов:

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

С Александром Торгашовым беседовали сооснователи Софториума Анна Сабадаш и Игорь Мазайкин. Подписывайтесь на наш канал, где мы проводим стримы с топами IT в России и Центральной Азии.