Как я писал в предыдущей статье «Scrum – пять изменений организации команды, принесшие успех Agile», разделение ответственности руководителя группы, при котором ее значительная часть передается всей команде, потребовало средств синхронизации представления о текущем состоянии работ для всех членов команды. Прорыв Scrum стал возможен благодаря тому, что в него включены простые и наглядные способы визуализации продвижения внутри спринта: доска и burndown chart, а также встречи, на которых эти представления обсуждаются и синхронизируются у всей команды. С момента появления техника работы с досками развивалась, довольно много в нее внес Kanban, который используется не только для организации работы небольшой команды, но и для больших подразделениях. И сейчас накоплено множество техник, позволяющих наглядно представить на доске ситуацию в проекте. Опыт внедрения Agile-методов показывает, что сама по себе визуализация работ на доске позволяет существенно повысить эффективность работы даже без перестройки других механизмов управления, просто за счет прозрачности ситуации для всего коллектива. Поэтому десятую статью серии «Менеджмент цифрового мира» я посвящу именно работе с досками.
Визуализация работ на доске позволяет существенно повысить эффективность работы даже без перестройки других механизмов управления
Итак, для начала определим, что такое работа? Выполнение любого проекта, да и вообще работа любого подразделения представляет собой выполнение некоторых задач. Задачи могут быть простые, выполняемые одним человеком, или сложные, распадающиеся на подзадачи. Выполнение задачи включает в себя несколько стадий, каждую из которых может выполнять отдельный исполнитель. Одновременно в работе может быть от десятка задач для небольшой команды, до нескольких сотен для большого подразделения. И все это надо наглядно представить. Все это достаточно хорошо проработано в классическом менеджменте, и тут нет ничего нового.
Отметим, что когда проект ведет менеджер, то ему доска не обязательна. Он может пользоваться различными сложными средствами слежения за ходом проекта, такими как диаграммы Ганта или просто списками дел в Excel, тем более, что это является одни из его основных фокусов внимания. А вот требования к визуализации для командной работы много выше: за краткое время ежедневной встречи все члены команды должны включиться в контекст, понять ситуацию и оценить ее. А еще хорошо бы, чтобы решая, какую взять очередную задачу они тоже могли адекватно оценить текущую ситуацию с задачами сделать выбор.
На рисунке показано, как устроена доска. Она по вертикали разделена на несколько колонок, каждая из которых соответствует своему этапу выполнения задачи. При этом, как правило, есть разделение колонки на область задач в процессе выполнения, и выполненные, ожидающие следующего этапа. Первая колонка содержит задачи, которые еще предстоит сделать, последняя – уже выполненные. В простейшем виде колонок всего три ToDo – Doing – Done. Однако, важно, чтобы набор колонок соответствовал реальным стадиям работ. Для каждой из них должен быть понятен набор выполняемых действий, и быть сформулирован набор условий, при которых стадия считается завершенной. Хорошая практика – когда этот набор условий сформулирован как чек-лист.
Набор колонок соответствует реальным стадиям работы, для каждой из них есть чек-лист завершения
На доске располагаются карточки, которые соответствуют задачам. Карточки различаются по цвету и размеру, и можно использовать дополнительные отличия. Очевидно, что надо различать отдельные задачи, задачи в составе сложных задач, и сами сложные задачи или минипроекты, в которых выполняются составляющие их простые задачи, но которые тоже путешествуют по доске, показывая интегральное состояние, и у которых тоже есть ответственный за продвижение минипроета в целом. Но полезными также являются другие различения, выделения различных потоков работ, например, отделение текущих операционных задач от работы на стратегические цели и от работы по заказам других подразделений. А еще – выделить сверхсрочные поручения от руководства компании или вызванные особыми причинами, при этом к таким карточкам можно приклеивать какие-то дополнительные символы для привлечения внимания, например, ракету. И вот здесь различие по цветам и формам позволяет просто кинув взгляд на доску понять, что команда что-то совсем не работает на стратегические цели, а поглощена текучкой. Или что важные проекты практически стоят, а выполняются только мелкие задачи. При этом человек может оценивать на глаз, просто сравнивая количество разных карточек на доске, без пересчета, это важно.
Помимо различных форм и цветов карточек потоки различных типов задач могут быть выделены за счет горизонтальных дорожек (на схеме этого нет). Преимущество в том, что каждая дорожка, в общем случае, может иметь свой набор стадий. Зато это требует больше места, а в случае, когда потоки неоднородны по мощности – еще и является сильно не оптимальным. Поэтому обычно применяется комбинация обоих вариантов.
Как понять, какие именно стадии, дорожки и типы карточек должны быть у вас на доске? Казалось бы, все просто: возьми регламенты и должностные инструкции и выпиши из него этапы работ. Однако, практика показывает, что реальные потоки задач оказываются достаточно разнородны, при обработке возникают различные особые случаи работ, которые скрыты внутри фазы. А для того, чтобы доска могла служить рабочим инструментом, она должна адекватно отражать ситуацию. Поэтому доска требует отдельного проектирования, которое не является тривиальной задачей. При внедрении Kanban проектирование доски является составной частью процесса STATIK (Systems Thinking Approach to Introducing Kanban), в ходе которого анализируют реальный поток задач, выделяют их фазы и классы обслуживания. Часто при этом выясняют много интересного о том, как же на самом деле сотрудниками выполняется работа ☺ Впрочем, доски не отливаются в чугуне, поэтому могут быть доработаны позднее.
На карточке должно быть написан код задачи, если есть привязка к электронной системе ведения дел, если она есть, и ее краткое название. Важно, чтобы содержание задачи было опознаваемо по названию большинством сотрудников, чтобы за содержанием не требовалось заглядывать в отдельную систему, а люди и так понимали, о чем идет речь.
У каждой задачи есть ответственный, и он должен быть на карточке. И хороший современный прием состоит в том, чтобы указывать ответственного не инициалами или именами-фамилиями, а с помощью опознаваемых фотографий, достаточно крупных, чтобы при взгляде на доску можно было узнать человека. Фотографии печатаются заранее, а когда человек берет задачу он ее просто прикрепляет степлером. Не аватары или мелкие изображения, а именно фото лица – дело в том, что в мозгу у нас есть отдельная система узнавания лиц, которая работает весьма эффективно. И если ее задействовать, то эффективность работы с доской сильно повышается. Появляется возможность простым взглядом на доску увидеть, кто из сотрудников сильно загружен, может быть перегружен, а кто, наоборот, загружен мало. А по фото в области сделанных задач примерно видны сравнительные результаты.
При анализе ситуации всегда важно представлять, что какая-то задача задержалась на определенной стадии дольше обычного. И есть очень простой прием, как это сделать наглядным: каждой колонке сопоставляем свой цветной маркер и регулярно, например, ежедневно для коротких итераций или еженедельно для досок, используемых для более долговременных задач, ставим на карточки точки маркером нужного цвета. Число точек показывает, как долго задача находилась в определенной стадии. Как и в случае с фотографиями важно, чтобы точки были видны, когда окидываешь доску взглядом.
Еще один прием связан с задержками, которые возникают при выполнении задачи, если они не зависят от исполнителя, а связаны с внешними взаимодействиями. Хороший способ – клеить на карточку стикер, где фиксировать причину задержки и ожидаемое время ответа. И, естественно, использовать стикеры различного цвета и формы визуального выделения, а также ставить точки на них, а не только на карточку.
Различные примеры досок легко ищутся и интересующиеся наверняка видели много разных вариантов. Поэтому я хочу привести пример большой доски – доску одного из департаментов Центрального Банка, о которой в докладе на AgileDays-2018 «Банк России: знать путь и пройти его — не одно и то же» рассказывали Светлана Иванова, Дарья Корнеева и Николай Арапов.
Я не только слушал доклад, но и был в этом подразделении на экскурсии и доска реально впечатляет – 8 метров, она занимает всю стену в переговорной перед кабинетом директора департамента, на нее вынесено около 150 важных задач департамента, при том что в отделах департамента есть собственные доски. И в ней как раз использованы приемы о которых я писал выше.
Как говорили в докладе, доски становятся «информационными радиаторами», излучая информацию на все подразделение, и давая представление о прогрессе работы. Люди учатся общаться, просить и предлагать помощь. И приемы визуализации тоже этому способствуют. Например, сотрудники оценивают, что операционных задач слишком много, а задач из проектов на стратегические цели маловато и они медленно двигаются. Или, видя на доске, что какая-то задача чересчур зависла на согласовании с внешним отделом, предлагают ответственному обходные пути для ускорения процесса, которые есть в каждой крупной организации. И в целом они сами были удивлены значительностью того эффекта, который принесла визуализация. Доска вовлекает людей в работу отдела в подразделения, побуждает не ограничиваться только своими задачами, а задумываться о работе в целом.
Доска вовлекает людей в работу отдела в подразделения, побуждает не ограничиваться только своими задачами, а задумываться о работе в целом.
Стоит сказать про обсуждение статуса работ у доски. Частая практика состоит в том, что члены команды по очереди рассказывают, какими задачами они занимались, чего достигли и какие препятствия. При этом перемещение по доске идет в произвольном порядке. А хорошей практикой является обсуждение от задач, а не от людей, начиная от тех, которые находятся справа, то есть дальше других продвинулись по доске. Потому что продвижение по доске означает, что в задачу уже вложено много работы, и потому она более важна для завершения.
Заметим, кстати, что по этой причине задача на доске не возвращается на предыдущие стадии, даже если были обнаружены недоделки, например, если при тестировании выявлены ошибки разработки, или при финальном согласовании договора с клиентом были обнаружены проблемы юридического характера, которые юристы должны были решить ранее. Не задача возвращается на предыдущую стадию, а компетентный специалист вызывается для помощи в решении проблем на текущую стадию, и это для него более приоритетная работа.
В целом важно, чтобы обсуждение у доски для новой команды вели опытные люди, которые умеют читать доску и понимают работу с ней и показывают другим. Тогда у людей, участвующих в обсуждении, через некоторое время возникает эмпатия к доске.
Еще один важный такт обсуждения – это снятие с доски завершенных задач. Это не должно быть технической процедурой, это повод отпраздновать завершение работы и вспомнить, что было сделано. Это может быть по-разному включено в процесс, но позитивный праздник – важен. Но и техническую часть тоже не следует забывать – в случае использовании физической доски это момент обработки метрик по сделанным задачам.
Я не сказал про еще один важный элемент, который был на схеме – это WIP-лимиты, ограничивающие Work In Progress - незавершенную работу. По понятной причине – это достаточно продвинутая техника, которую стоит вводить не на первом шаге, а постепенно и экспериментально проверять эффекты, которые приносит изменение лимитов. Техника WIP-лимитов основана на теории ограничений (TOC) Голдратта. Важно, что в случае неоднородного потока работ, которым характеризуется IT-разработка и другие задачи умственного труда точки ограничений могут перемещаться по стадиям обработки, поэтому и есть смысл ставить лимиты на все колонки.
Механизм действия лимитов следующий. Как мы помним, колонка стадии делится на части, где отражаются выполняемые задачи, и уже выполненные, готовые к переходу дальше. Если в какой-то стадии возникло бутылочное горлышко, то на предыдущей колонке задачи накапливаются в состоянии «выполнено». При этом лимит – общий, и потому освободившиеся сотрудники не могут взять очередную задачу. И это служит сигналом о том, что надо перестать забирать в работу все новые задачи, а надо коллективными усилиями начать разбирать бутылочное горло. Да, это может провести к простою сотрудников, но теория ограничений четко говорит, что даже простой лучше, чем увеличение незавершенной работы, так как в целом это ведет к повышению пропускной способности системы. Правда, надо отметить, что такой простой часто негативно воспринимается и в том числе может негативно влиять на метрики и KPI, если они спроектированы традиционным образом. Кстати, это – известная проблема применения теории ограничений, и правильный подход – изменить соответствующие метрики, если вам интересны детали, то об этом есть книга: Томас Корбет «Учёт прохода. Управленческий учет по теории ограничений» (Throughput accounting).
Отметим, что WIP-лимиты можно накладывать не только на колонки, но и на определенные классы задач, например, на срочные поручения руководителей высокого уровня. В уже упоминавшемся кейсе департамента Банка России они решили, что срочных поручений не может выполняться больше пяти одновременно, а чтобы их отличать от остальных клеили на карточку ракету. Может показаться, что это наивно, дескать, нельзя же отказать высокому руководителю, когда он дает поручение потому, что у вас, мол, установлен WIP-лимит. Но на самом деле это работает, просто надо весте коммуникацию по-другому: когда вам дают задачу вспомнить о тех, что уже в работе, напомнить о них руководителю, и попросить позиционировать относительно них. Если ее можно выполнить после завершения других, то она получается и не сильно срочная, а если новая задача действительно срочная, то он сам укажет, чем надо пожертвовать ради нее. Просто он вполне может не помнить, какие задачи уже в работе.
Ну и в заключении этой статьи поговорим о том, какую доску следует использовать – физическую или электронную. На самом деле, ограничение тут единственное: если у вас распределенная команда, то физическую доску использовать невозможно. У каждого варианта есть свои плюсы и минусы. Опыт показывает физическая доска гораздо лучше для команды, у которой вообще не было навыков работы с досками и таск-трекером: вокруг нее можно собраться, она способствует коллективным обсуждениям и коммуникации в команде, и к ней быстрее возникает эмпатия. А еще физические доски обладают гораздо большей вместимостью, приведенная в качестве примера доска в центральном банке в электронном варианте была бы невозможна.
С другой стороны, использование только физической доски без электронной и таск-трекера не позволяет работать с метриками на длинных временных горизонтах. В целом опыт развития Agile говорит об одном: это решение должна принимать сама команда. При этом, хотя использование таск-трекера в IT является стандартом, есть случаи использования физической доски с поддержкой синхронности различными методами: первичным источником при этом может быть как доска, так и таск-трекер. Кстати, в Банке России наряду с физической доской был список задач, и тоже проводилась синхронизация, это входило в обязанности отдельного сотрудника. Таск-трекеров существует громадное количество, и большинство из современных умеют представлять задачи в виде досок. И есть много обзоров этих инструментов, которые, впрочем, как обычно не дают однозначного ответа. Так что выбирать вам самим.
На этом я завершаю рассказ о досках. В следующей статье я продолжу рассказ о Scrum. А к Kanban мы тоже еще вернемся, он, конечно, не ограничивается визуализацией на доске, чтобы там не писали некоторые статьи, а наоборот, является одним из наиболее мощных и эффективных методов работы с потоками задач и обеспечения гибкости компании с постоянной подстройкой к изменяющимся условиям работы.
Продолжение следует…