Читать книгу Менеджмент цифрового мира - Максим Цепков - Страница 12

Итак, разделение ответственности руководителя группы, при котором ее значительная часть передается всей команде, потребовало средств синхронизации представления о текущем состоянии работ для всех членов команды. Прорыв 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 – целостная схема, а не прикольная картинка

Я хочу начать со схем итерационного процесса Scrum. Собственно, наличие такой схемы, в которой собраны связанные и дополняющие друг друга элементы, обеспечивающие целостность процесса, и делает Scrum фреймворком, а не просто методом организации работы. Схема показывает, как функционально следует устроить процесс, чтобы он работал, чтобы его элементы взаимодействовали между собой и в комплексе обеспечивали результат. Функционально, а не процедурно – наполнение конкретных функций может быть различно, оно сильнее зависит от условий и содержания конкретного проекта или потока работ, и его надо адаптировать. А вот рассказывают схему часто в сильно упрощенном варианте, делая фокус не на функциях элементов схемы, а на процедурах, которые могут их обеспечить в простом случае. Вред понятен: люди видят, что конкретную процедуру в их проекте применить нельзя, и не понимая функциональной схемы, заменяют упрощенным вариантом и в реализации получаются функциональные дыры, в результате «Scrum не работает». Так вот, не работает не Scrum, а его плохая адаптация. И потому дальше я буду подробно останавливаться на функциях элементов и вариантах адаптации.

Отметим, что создатель Scrum Джеф Сазерленд в своей книге «Scrum – революционный метод управления проектами» пишет о том, что он был скептически настроен по применению Scrum за пределами IT, потому что полагал, что фреймворк сильно нагружен IT-спецификой. Однако, по мере того, как его пробовали использовать и достигали успеха, его скепсис развеялся, и в книге он приводит различные примеры использования. Кстати, я рекомендую эту книгу всем, кто хочет понять дух и культуру Scrum и Agile в целом. При этом Джеф описывает сам фреймворк, логику и историю его создания, и дает множество кейсов применения. А еще книга достаточно очищена от IT-специфики, так что может быть обобщенным руководством. Кстати, говорят, что это – одна из двух книг, прочитав которые Герман Греф проникся новым менеджментом. Вторая «Открывая организации будущего» Фредерика Лалу.

А вторая книга, которую я хочу порекомендовать – Хенрик Книберг «Скрам и XP: заметки с передовой», в оригинале «Scrum and XP from the Trenches». Русский перевод был сделан энтузиастами и долгое время лежал на infoq.com, потом был оттуда убран, но в сети остался, например, здесь. а английский там доступен уже во втором издании. Книга – про IT, очень популярна и в свое время именно по ней изучали Agile-методы. Я тоже впервые детально познакомился со Scrum именно по ней в 2007, а когда в 2011 Книберг приезжал на AgileDays, то проходил у него тренинг, заметки и конспект сохранились у меня на сайте. Книга актуальна не только для IT-шников, но и для заказчиков софта, особенно в корпорациях, она помогает понять логику разработки и наладить сотрудничество. Отмечу, что и Сазерленд и Книберг – не спикеры или тренеры, они ведут реальные проекты, в том числе разбираются и спасают проблемные проекты, когда критерием успеха является успех самого проекта. Поэтому их книги, выступления и тренинги так интересны.

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

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

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

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

Схема Scrum – деление на спринты и подготовка к ним

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

Однако, в своем рассказе не буду строго следовать Scrum Guide. Основная причина в том, что он по-прежнему в значительной мере наполнен спецификой IT-проектов, в то время как Scrum применяется гораздо шире. Да и в самом IT характер проектов значительно изменяется. Я не выверял текст по Scrum Guide.

Я тут хочу оговориться, что текст далее в значительной мере посвящен IT. Сделано это не только потому, что, я думаю, много читателей будет из IT и им это интересно, но и потому, что если вы будете переносить процесс в другие отрасли и другие виды деятельности, то следует понимать те изменения, которые в IT потребовались для успешной реализации – вам придется делать аналогичные адаптации или смириться с недостаточной эффективностью процесса, или отказаться от него. Это касается не только Scrum, но и комбинированных процессов. И несмотря на все эти оговорки, можно сказать, что применение Scrum за пределами IT является более эффективным, чем регулярный менеджмент, и это дает компаниям преимущество – что и объясняет интерес к применению.

Начнем с сокращенной схемы.

Итерации: создаем ценность в каждой, а не просто квантуем поток

Основное изменение, которое принес Scrum в проектную работу – это деление потока работ на итерации, который и представлен на схеме. Рекомендуемая продолжительность итерации 2—4 недели, при том, что на практике встречаются и недельные итерации, а вот большая продолжительность не является эффективной, происходит размывание фокуса. Предполагается, что у нас есть список задач, которые следует выполнить для достижения цели – Product Backlog, и задачи там упорядочены по важности и приоритетам. О том, каким образом наполняется этот список, мы поговорим дальше. Перед стартом итерации из этого списка выбираются задачи, которые планируется выполнить в Sprint Backlog. Но, что важно, мы не просто выбираем некоторое количество задач из начала списка. Дело в том, что в конце итерации должен получиться целостное приращение к продукту, несущее ценность потребителю и пригодное к использованию. Собственно, в этом состояла основная революция: при традиционном проектном подходе команда работала несколько месяцев и продукт в понятном для потребителя и пригодном для использования виде собирался только в самом конце, а о пригодности для потребителя промежуточных сборок никто не заботился, даже если применялись практики continuous integration и проверка работоспособности сделанного.

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

Переход к инкрементальному созданию приложения в IT потребовало кардинального пересмотра способов работы с требованиями и проектирования приложения. Появились новые форматы, такие как user story, каждая из которых описывала ценную для пользователя функциональность и была относительно мала, так, что можно было легко ими маневрировать при планировании, в отличие от цельных проектов большого функционала, с которым работали в прошлом. И первая версия Scrum Guide (можно скачать здесь) рекомендовала использовать именно их в качестве элементов бэклога. По мере распространения Scrum другие форматы ведения требований и проектирования тоже адаптировались, например, появился Use Case 2.0, пригодный для инкрементальной реализации, и сейчас могут применяться разные варианты.

Отметим, что далеко не в любых проектах можно перейти к инкрементальной реализации с поставкой ценности. Понятным примером являются строительные проекты: мост или здание надо построить целиком и запустить в эксплуатацию. Другим примером является организация конференции или другого мероприятия – тут есть финальный релиз и нет промежуточных этапов, приносящих ценность. Однако, есть большая зона, где преобразование возможно в том или ином объеме. И надо отметить, что хорошо поддаются преобразованию проекты НИОКР. Например, концерн Калашникова на одной из встреч, что они применяют Scrum для разработки новых видов оружия. При этом за две недели получается сделать в железе некоторый очередной прототип, демонстрация которого позволяет увидеть ошибки проектирования и неверные пути, которые при традиционном способе были бы проявлены только через полгода, и это дает большую экономию и средств и времени. На AgileBusiness-2018 применении Scrum для разработки новых материалов рассказывала Северсталь (мой конспект), а для создания коллекций одежды – 12Storeez (видео), можно найти много других примеров. Отмечу также, что Scrum может применяться и для организации работы в случае, когда существенную часть работ вообще нельзя запланировать. Например, на AgileDays-2018 Марина Симонова (Marina Alex) рассказывала о применении Scrum в сети стоматологических клиник (видео), в которых работа состоит в обслуживании пациентов, и не может быть запланирована. В этом случае спринты Scrum использовались только для задания еженедельного ритма работы. Но при этом сознательно был выбран именно фреймворк Scrum для того, чтобы путем резких изменений организации работы и переходе к командам обеспечить изменение культуры в коллективе и наладить сотрудничество между врачами, медсестрами и немедицинским персоналом, которые обычно в медицине сильно разделены. Там были образованы именно смешанные команды, включающие все роли.

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