Доска визуального планирования на производстве

Обновлено: 28.03.2024

Как я писал в предыдущей статье «Scrum – пять изменений организации команды, принесшие успех Agile», разделение ответственности руководителя группы, при котором ее значительная часть передается всей команде, потребовало средств синхронизации представления о текущем состоянии работ для всех членов команды. Прорыв Scrum стал возможен благодаря тому, что в него включены простые и наглядные способы визуализации продвижения внутри спринта: доска и burndown chart, а также встречи, на которых эти представления обсуждаются и синхронизируются у всей команды. С момента появления техника работы с досками развивалась, довольно много в нее внес Kanban, который используется не только для организации работы небольшой команды, но и для больших подразделениях. И сейчас накоплено множество техник, позволяющих наглядно представить на доске ситуацию в проекте. Опыт внедрения Agile-методов показывает, что сама по себе визуализация работ на доске позволяет существенно повысить эффективность работы даже без перестройки других механизмов управления, просто за счет прозрачности ситуации для всего коллектива. Поэтому десятую статью серии «Менеджмент цифрового мира» я посвящу именно работе с досками.

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

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

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

На рисунке показано, как устроена доска. Она по вертикали разделена на несколько колонок, каждая из которых соответствует своему этапу выполнения задачи. При этом, как правило, есть разделение колонки на область задач в процессе выполнения, и выполненные, ожидающие следующего этапа. Первая колонка содержит задачи, которые еще предстоит сделать, последняя – уже выполненные. В простейшем виде колонок всего три ToDo – Doing – Done. Однако, важно, чтобы набор колонок соответствовал реальным стадиям работ. Для каждой из них должен быть понятен набор выполняемых действий, и быть сформулирован набор условий, при которых стадия считается завершенной. Хорошая практика – когда этот набор условий сформулирован как чек-лист.

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

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

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

Как понять, какие именно стадии, дорожки и типы карточек должны быть у вас на доске? Казалось бы, все просто: возьми регламенты и должностные инструкции и выпиши из него этапы работ. Однако, практика показывает, что реальные потоки задач оказываются достаточно разнородны, при обработке возникают различные особые случаи работ, которые скрыты внутри фазы. А для того, чтобы доска могла служить рабочим инструментом, она должна адекватно отражать ситуацию. Поэтому доска требует отдельного проектирования, которое не является тривиальной задачей. При внедрении Kanban проектирование доски является составной частью процесса STATIK (Systems Thinking Approach to Introducing Kanban), в ходе которого анализируют реальный поток задач, выделяют их фазы и классы обслуживания. Часто при этом выясняют много интересного о том, как же на самом деле сотрудниками выполняется работа ☺ Впрочем, доски не отливаются в чугуне, поэтому могут быть доработаны позднее.

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

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

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

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

Различные примеры досок легко ищутся и интересующиеся наверняка видели много разных вариантов. Поэтому я хочу привести пример большой доски – доску одного из департаментов Центрального Банка, о которой в докладе на AgileDays-2018 «Банк России: знать путь и пройти его — не одно и то же» рассказывали Светлана Иванова, Дарья Корнеева и Николай Арапов.

​Канбан-доска департамента Банка России. Светлана Иванова, Дарья Корнеева и Николай Арапов на AgileDays-2018 «Банк России: знать путь и пройти его — не одно и то же»

Я не только слушал доклад, но и был в этом подразделении на экскурсии и доска реально впечатляет – 8 метров, она занимает всю стену в переговорной перед кабинетом директора департамента, на нее вынесено около 150 важных задач департамента, при том что в отделах департамента есть собственные доски. И в ней как раз использованы приемы о которых я писал выше.

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

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

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

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

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

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

Я не сказал про еще один важный элемент, который был на схеме – это WIP-лимиты, ограничивающие Work In Progress - незавершенную работу. По понятной причине – это достаточно продвинутая техника, которую стоит вводить не на первом шаге, а постепенно и экспериментально проверять эффекты, которые приносит изменение лимитов. Техника WIP-лимитов основана на теории ограничений (TOC) Голдратта. Важно, что в случае неоднородного потока работ, которым характеризуется IT-разработка и другие задачи умственного труда точки ограничений могут перемещаться по стадиям обработки, поэтому и есть смысл ставить лимиты на все колонки.

Механизм действия лимитов следующий. Как мы помним, колонка стадии делится на части, где отражаются выполняемые задачи, и уже выполненные, готовые к переходу дальше. Если в какой-то стадии возникло бутылочное горлышко, то на предыдущей колонке задачи накапливаются в состоянии «выполнено». При этом лимит – общий, и потому освободившиеся сотрудники не могут взять очередную задачу. И это служит сигналом о том, что надо перестать забирать в работу все новые задачи, а надо коллективными усилиями начать разбирать бутылочное горло. Да, это может провести к простою сотрудников, но теория ограничений четко говорит, что даже простой лучше, чем увеличение незавершенной работы, так как в целом это ведет к повышению пропускной способности системы. Правда, надо отметить, что такой простой часто негативно воспринимается и в том числе может негативно влиять на метрики и KPI, если они спроектированы традиционным образом. Кстати, это – известная проблема применения теории ограничений, и правильный подход – изменить соответствующие метрики, если вам интересны детали, то об этом есть книга: Томас Корбет «Учёт прохода. Управленческий учет по теории ограничений» (Throughput accounting).

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

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

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

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

Одним из моих профессиональных интересов, как координатора команды тестировщиков, являются методологии разработки программного обеспечения. В настоящее время все большую популярность приобретают так называемые Agile-методологии, в особенности Scrum и Kanban. На «раcпиаренных» терминах играют недобросовестные «тренеры», семинары и сертификации («сертифицированный Scrum-мастер», «сертифицированный Product owner» и т.д.) растут как на дрожжах.

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

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

Если вам не хочется читать — я сделал видео, где на пальцах описываю историю и основные принципы метода Канбан.

История термина

Kanban – японский термин, который начали использовать применительно к производству в 60-х годах 20-го века в компании Toyota. В основу данного принципа положен конвейерный метод производства, а также различные скорости выполнения отдельных технологических операций на производстве. Попробую объяснить на пальцах. При любом производстве есть основное производство («главный конвейер») и дополнительное производство («дополнительные конвейеры»). Темп выпуска конечных изделий задает главный конвейер, в то время как дополнительные конвейеры не могут ускорить темп выпуска изделия, но могут замедлить его, в случае несвоевременного выпуска требуемых деталей.

Дополнительно, при производстве может произойти смена приоритетов. К примеру выяснилось что станция, которая производила левые зеркала произвела 20 шт., а станция производившая правые зеркала — 10 шт., в то время как на конвейере находятся 15 автомобилей и необходимо 15 штук зеркал обоих типов. Налицо конфликт метрики — количественно производство не упало (дополнительные конвейеры выпустили 30 изделий в срок), но производство все равно рискует остановится. Kanban призван помочь с этой проблемой.

В упрощенном варианте, Kanban включает в себя два простых правила:

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

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

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

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

image

  1. изменить лимит на количество задач в работе;
  2. добавить задачу с более высоким приоритетом (к примеру p0) для того чтоб она была взята как можно скорее;

В процессе работы может так произойти, что работа заблокирована (сломался хостинг, не скачан нужный framework и т.д.). В общем случае, заблокированная работа возвращается в backlog, и выбирается новая задача, с максимальным приоритетом. В зависимости от характера задач и типа команды лимит может быть увеличен или уменьшен. К примеру, наш разработчик может одновременно рисовать форму регистрации и смотреть за процессом развертывания нового сервера. Тем не менее, если время завершения задач будет меньше требуемого, руководитель проекта может уменьшить лимит, или увеличить команду. Таким образом, при грамотном руководстве, Kanban обеспечивает максимально возможную для данной команды скорость работы, максимальную скорость реагирования на изменения и в то же время сократить «расходы» на поддержку методологии. В общем все! Kanban — это не просто, просто. Это очень просто!

  • данная методология плохо работает с большими командами (больше 5 человек);
  • в чистом виде, Kanban плохо работает с кросс-функциональными командами. Т.е. в отличие от Scrum, тяжело совместить тестирование и разработку в одной команде. Более удачной мыслью является разбить процесс на «станцию» разработки и «станцию» тестирования с отдельными руководителями и backlog-ами;
  • ввиду своей истории и специфики, Kanban не предназначен для долгосрочного планирования.
Заключение

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

В случае возникновения интереса к теме продолжу рассмотрение Kanban'a подробнее. В последствии, предлагаю разобрать по полочкам и картинкам Scrum и RUP.

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

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

image



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

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

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

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

Эффективный Kanban-инструмент поможет управлять Agile-разработкой с помощью удобных досок и карточек, потока действий, функций Swimlanes и WIP limits, диаграмм и таймлайнов — всего, что помогает качественно визуализировать управление рабочими процессами.

image

Что включает в себя мощное Канбан ПО

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

Тем не менее, существуют решения, которые выполняют работу лучше и эффективнее других. Рассмотрим главные критерии для поиска лучшего Канбан-инструмента:

  • Kanban доска — система, которая предназначена для организации карточек с задачами с помощью горизонтальных колонок (Swimlanes), ограничений (WIP limits), сабколонок, а также стандартного набора колонок («To-do», «In Progress» и «Done»).
  • Kanban карточка — элемент системы Канбан, который назначает задачи при помощью чек-листов и вложений. Карточки позволяют связывать задачи, добавлять иерархию и назначать необходимые ресурсы.
  • Аналитика — система, позволяющая создавать отчеты.
  • Интеграция — способность инструмента легко интегрироваться с другими системами управления проектами.
  • Автоматизация — возможность настроить рабочий процесс в соответствии с условиями вашего проекта.

Лучшие Канбан инструменты для управления проектами

У вас, по сути, есть два пути:

  • Не заморачиваться и бездумно зарегистрироваться в проверенные и пресловутые JIRA или Trello.
  • Потратить немного времени на изучение новой волны крутого ПО по управлению проектами, ориентированного на Kanban, с целью отбора самого подходящего софта для ваших нужд.
ПО Лучше всего для
JIRA Для разработки программного обеспечения Agile-командами. Не лучший вариант для нетехнических команд и процессов вне системы Agile. Идеальный вариант – для IT компаний с большим штатом разработчиков.
Trello Для частного и командного использования в разных областях (маркетинг, продажи, HR, и т.д.) которым необходим функционал Kanban. Не лучший вариант для Agile-разработчиков. Идеальный вариант – индивидуальное использование Канбан-досок.
Hygger Преимущественно для Agile-команд разработчиков. Поддерживает Kanban и Scrum, estimations, Burndowns, Swimlanes и WIP limits. Предлагает качественную приоритизацию бэклога. Идеальный случай – любая Agile-ориентированная команда.
MeisterTask Для тех же потребностей, что и Trello, но с улучшенной интеграцией с MindMeister.
Favro Для мелких и средних команд разработчиков. Поддерживает Kanban и Scrum процессы.
Asana Для персонального использования и для небольших команд, которым преимущественно нужны to-do листы и базовый функционал Канбан доски.
Kanbanchi Для персонального использования Канбан досок с тесной интеграцией с G Suite.
Paymo Для агентств и команд, которым нужно автоматически отслеживать время, приоритизировать задачи и следить за рабочим временем.
Breeze Для команд, которым нужна усовершенствованная версия Basecamp с базовым Kanban-функционалом.
Blossom Лучше всего для распределенных команд. Минималистичный инструмент для управления проектами, построенный на основе Kanban-досок.
ProofHub Для команд, которым необходимо полноценное решение с Kanban-досками, диаграммами Ганта, календарем, заметками, обсуждениями, листами задач. Это своеобразный Basecamp «на стероидах».
ZenHub Это плагин для GitHub, который добавляет поддержку Multi-repo Boards, Epics, индивидуальных рабочих пространств и улучшенный репортинг.
Taiga Опен-соурс программа для разработчиков, которым нужно проверять задачи и пользоваться стандартным набором для управления проектами.
Leankit Для создания кастомизированных досок с детальным потоком задач.

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

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

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

image

Trello

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

Сомнения: Trello не имеет своего собственного учета времени, поэтому вам придется платить за другое программное обеспечение (например, Everhour или Toggle). Кроме того, в Trello нет функций WIP limits, Swimlanes и диаграмм Burndown.

image

Hygger

Hygger — яркий представитель нового поколения PM-инструментов, который отлично подходит продуктовым компаниям, стартапам и организациям средних размеров. Сервис предоставляет удобные to-do листы с кастомными полями, Канбан досками, функциями Swimlanes, WIP limits и Timelines.

Достоинством сервиса является возможность приоритизировать функции, идеи или задачи, используя различные методы приоритизации. Этот фактор часто является решающим при выборе Hygger vs Trello. Кстати, если вы знакомы с функционалом Trello, то быстро освоиться в Hygger не составит труда, потому что платформа имеет похожий интерфейс.

Hygger предлагает определять приоритеты с помощью простых методов (Eisenhower matrix, Value vs Effort, Value vs Risk), а также продвинутых техник (ICE и RICE, Weighted Scoring).

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

image

Asana

Asana – не менее популярный сервис с доступными iOS и Android приложениями, который хорош в управлении задачами, отслеживании дедлайнов и постановке приоритетов. Asana позволяет качественно следить за статусом выполнения задач и статусом проекта в целом.

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

Сомнения: Платформа вряд ли будет полезна маркетинговым и креативным агентствам или сервис-компаниям.

image

Favro

Favro предоставляет инновационное решение для управления проектами, более всего подходящее для разработчиков, маркетологов и руководителей, которые планируют, отслеживают и развивают свои идеи. Favro предлагает встроенную поддержку Kanban и Scrum досок с панелями управления, масштабируемыми бэклагами и отчетами.

Функция Breakdown в Favro помогает разбить ваши проекты на различные задачи. Инструмент интегрирован с Google Drive и Dropbox, что позволяет прикреплять файлы к доске планирования.

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

image

MeisterTask

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

Канбан доски MeisterTask помогают пользователям просматривать и управлять текущими действиями и активными проектами, создавать планы проектов и сотрудничать с членами команды. Платформа предлагает интеграцию с GitHub, DropBox, Zendesk и Bitbucket.

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

image

Kanbanchi

Kanbanchi – еще одно подходящее решение, если вам нужно программное обеспечение для управления задачами и совместной работы с досками Kanban, диаграммами Ганта и системой учета времени.

Вы легко визуализируете рабочие процессы всех задач и действий с помощью удобных досок проектов со списками и карточками. Инструмент предназначен для G Suite. Вы должны зарегистрироваться в учетной записи Google, управлять досками в виде файлов на Google диске, помещать даты в Google календарь и т. Д. Приложение отлично подходит для работы отделов компании, потому как каждый член команды знает, над чем он работает.

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

image

Paymo

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

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

image

Breeze

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

Инструмент основан на принципах Agile и Lean и включает в себя следующие основные функции: списки задач, отслеживание времени, бюджетирование проекта, отчетность, календарь, экспорт данных, неограниченное количество пользователей, поддержка Android и iOS, интеграция с Google Drive и Dropbox, и т.п.

Сомнения: Малое количество инструментов, с которыми Breeze может быть интегрирован.

image

Blossom

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

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

Сомнения: Нет бесплатного плана для личного использования. Интеграционные возможности — только отправление обновлений на канал Slack.

image

ProofHub

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

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

Сомнения: ProofHub может показаться слишком простым с первого взгляда, но может не подойти для сложных проектов и крупных организаций.

image

ZenHub

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

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

Сомнения: Zenhub не предоставляет достаточно аналитических и отчетных функций. В UX есть некоторые «причуды», которые могут периодически отвлекать и беспокоить.

image

Taiga

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

Сервис можно легко интегрировать с GitHub, GitLab, Webhooks, Bitbucket и Gogs. Доступны мобильные приложения для Android, iOS и Windows.

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

image

LeanKit

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

LeanKit предлагает удобный способ соединения досок проектов на уровне команды и проекта и предоставляет пользователям полную видимость. Вы также получите модуль отчетности и аналитики с полезными показателями и метриками. Платформа поддерживает интеграцию с JIRA, Zendesk, Pivotal Tracker и другими инструментами.

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

image

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

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

Канбан особенно легко внедряется начиная с топ-менеджмента и прекрасно комбинируется с теорией ограничений, изложенной в книге «Цель» Элияху Голдрата. Канбан выбирают для себя отделы техподдержки, системные администраторы, и даже менеджеры по персоналу и бухгалтеры, тесно работающие с IT.

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

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

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

Выгоды внедрения

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

1) Канбан создан для того, чтобы увеличить прозрачность процессов внутри организации

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

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

2) Канбан помогает бороться с «многозадачностью» в самых плохих ее проявлениях

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

3) Канбан позволяет больше не заниматься оценкой сроков выполнения конкретной задачи

Вместо этого предполагается использовать статистические методы. Представьте себе, что вы измеряете диаметр сечения водопроводной трубы и скорость потока, а не занимаетесь предсказанием, как быстро конкретная капля(пусть даже помеченая синим красителем) пролетит через трубу из точки A в точку B.

Полезные инструменты, делающие Канбан эффективным

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

Канбан-доска

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

Инструкция по внедрению:

1) Определите, через какие состояния реально проходит ваша типичная задача. Вариант «гнев, отчаяние, торг, депрессия, принятие», конечно, не принимается, но звучит поразительно часто.

Например, это могут быть такие столбики для общего IT-процесса(стратегический уровень):
В очереди | В работу | Анализ | Проектирование | Дизайн | Разработка | Тестирование | Выкладка

Или такие(для выделенного подразделения UX-дизайнеров):
В очереди | В работу | Макет | Прототип | Верстка | Передано в разработку

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

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

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

Ограничение на количество работ в процессе. (WIP Limit)

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

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

1) обсудите завалы недоделанных задач(если они есть) и примите решение с ними бороться;

2) введите ограничение на самый заваленный столбец и только на него;

3) как только мы начинаем уделять особенное внимание какой-то части процесса и ликвидируем «завал» в этом месте, то самым узким местом станет другой участок производства, найдите новое самое узкое место и поставьте ограничение и на этот столбик
(даже если для этого вам придется убедить смежное подразделение тоже обзавестись канбан-доской, почему нет);

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

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

SLA — Service level agreement, или соглашение об уровне сервиса

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

Внедрение

1) Подсчитайте статистическими методами, сколько времени в среднем проходит от постановки задачи в очередь заказчиком (внутренним или внешним). А также, в какой временной промежуток уложились наиболее быстрые 10% (назовем его X), и в какой уложились только 90% (назовем его Y). Подсчитайте также время Z для «долгостроев», сколько времени занимали самые длинные задачи.

2) Возьмите Х и прибавьте к нему Y, и вы получите реалистичные сроки выполнения 90% задач, даже если заказчики будут «набегать» со срочными поручениями, которые не могут ждать указанный срок и будут отодвигать ваши задачи. Скажем по секрету, что они наверняка приходят со срочными задачами и сейчас тоже в особом порядке. Автору известны случая «внутренней коррупции», где нарушение приоритетов стоило чашку кофе или шоколадку, некоторые рассказывают о реально заплаченных деньгах.

3) Договоритесь с заказчиком(не имеет значения, внутренним или внешним) о том, что в штатной ситуации задача обрабатывается за время X+Y, и лишь 10% задач могут выполняться крайне долго по тем или иным причинам вплоть до времени Z.

Классы сервисов

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

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

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

Роль Менеджера запросов(SRM)

В материалах по Канбану авторы изредка честно говорят, что эта роль нужна скорее для того, чтобы не увольнять Product Owner при переходе со скрама, но и в этой позиции (SRM) нет особенной нужды, если нет проблем с получением заданий от заказчика. Эта роль может быть полезна тем командам, которые страдают от отсутствия «единой точки входа» в продуктовых компаниях. Тогда этот человек может устанавливать формальные политики и разбираться с входящей очередью, но это точно не предполагается как работа на полную ставку. Как вариант, можно иметь одного реквест менеджера на несколько команд, и превратить в него бывшего менеджера проектов или руководителя группы разработки(в общем того, кто в новом процессе остался без лишней работы).

Роль Менеджера поставки(SDM)

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

Каденции. Различные встречи с изменяемой под процесс периодичностью

Таких встреч в канбане много, даже слишком много. Различные встречи от ежедневных до встреч планирования поставок и и планирования наполнения очереди(аналог планирования спринта в скраме).

Ежедневная «летучка» standup

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

Operations Review

Как при работе не уйти в формализм и следование правилам в ущерб продукту?

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

Планирование поставки

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

Наполнение бэклога

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

Метрики

Существует стандартный набор метрик продукта: выручка, прибыль, ARPPU(average rate per paying user), чуть более нелюбимая ARPU(average rate per user, которая учитывает выручку в пересчете на всех пользователей, а не только платящих) и другие. Эти метрики очень полезны для любого процесса в продуктовой компании, немного другие, но весьма схожие — для аутсорсной. Но это конечно касается стратегического уровня.

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

Взаимодействие с управлением продуктом

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

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

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

Менеджер продуктов может спроектировать нужный ему процесс и задать нужные ему метрики. Он может выборочно использовать скрам или канбан или даже fast waterfall на разных участках своего процесса, ведь в конечном итоге любая методология — лишь способ достижения цели.

Кросс-функциональные команды

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

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

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

И снова про доску, которую многие по ошибке принимают за сам канбан

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

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

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

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

Читайте также: