Книга: Канбан. Альтернативный путь в Agile
Назад: Глава 3 Рецепт успеха
Дальше: Глава 5 Культура постоянного совершенствования
Глава 4
От худшего к лучшему за пять кварталов
В октябре 2004 года Драгош Думитриу был менеджером программ в Microsoft. Он только что возглавил отдел, который имел репутацию худшего IT-подразделения компании.
Должность «менеджер программ» в Microsoft примерно соответствует тому, что в других местах называют менеджером проектов, но обычно включает также некоторую ответственность за анализ и архитектуру. Менеджер программ назначается на инициативу, проект или продукт и отвечает за часть функционала. Чтобы выполнить работу, он привлекает ресурсы из функциональных областей, например разработки и тестирования. Драгош отвечал за техническое обеспечение ПО для бизнес-подразделения XIT. Эта команда (рис. 4.1), зрелость процессов которой оценивалась как CMMI Model Level 5, располагалась в Индии и состояла из трех разработчиков, трех тестировщиков и менеджеров, занимавшихся разработкой небольших обновлений и устранением ошибок примерно в 80 кроссфункциональных IT-приложениях, используемых сотрудниками Microsoft по всему миру. Сам Драгош находился в кампусе в Редмонде. В то же самое время там работал и я.
Рис. 4.1. Команда в Хайдарабаде (Индия). Драгош – четвертый слева
Проблема
Драгош сам вызвался возглавить команду, которая имела худшую репутацию в Microsoft с точки зрения клиентского обслуживания. В круг его обязанностей как агента изменений входило решение проблем длительного времени выполнения задач и плохо сформулированных, из-за сложившейся в компании конъюнктуры, ожиданий заказчиков. Некоторые из его предшественников на этой должности продолжали работать в компании с другими проектами того же подразделения. Они опасались, что если ему удастся улучшить производительность команды, то они будут выглядеть неудачниками.
Программисты и тестировщики этой организации следовали методологии PSP/TSP (Personal Software Process / Team Software Process). Такие требования компании Microsoft были записаны в контракте. Джон Де Ваан в то время – непосредственный подчиненный Билла Гейтса и большой поклонник Уоттса Хамфри из Института программной инженерии. Как глава Engineering Excellence в Microsoft, он мог требовать от IT-отдела и его поставщиков соблюдения определенных процедур. Поэтому изменение метода жизненного цикла разработки ПО было невозможным.
Драгош понял, что основная причина их проблем не в методе PSP/TSP и не в рейтинге зрелости организации. Более того, команда производила почти все, что от нее требовалось, с высоким качеством. Однако время выполнения запросов на изменения доходило до пяти месяцев и вместе с объемом бэклога продолжало бесконтрольно увеличиваться. Создавалось ощущение плохо организованной и почти неуправляемой команды. Высшее руководство не спешило выделять дополнительные средства на решение этой проблемы. Итак, сдерживающие факторы для изменений были связаны с политикой, финансами и правилами компании. Он обратился ко мне за помощью.
Визуализация рабочего процесса
Я попросил Драгоша сделать изображение рабочего процесса. Он набросал схему, в которой описывался жизненный цикл для запроса изменений, после чего мы обсудили проблему. Рис. 4.2 – это факсимиле того, что он сделал. Фигурка PM (менеджера программ) изображает Драгоша.
Рис. 4.2. Изначальный рабочий процесс технического обеспечения в XIT с указанием времени выполнения Initial
Поступление запросов было бесконтрольным. Четыре менеджера продукта представляли и контролировали бюджеты для ряда клиентов, которые владели приложениями, обслуживаемыми XIT. Они добавляли новые запросы и дефекты, выявленные в процессе промышленной эксплуатации.
Эти ошибки были внесены не командой техподдержки, а проектными командами разработки приложений. Такие команды обычно прекращают свое существование через месяц после выхода новой системы, а исходный код переходит к команде техподдержки.
Факторы, влияющие на производительность
Когда поступал запрос, Драгош отправлял его на оценку в Индию. Согласно регламенту, оценку нужно было произвести и представить владельцам бизнеса в течение 48 часов. Так было легче вычислить ROI (прибыли на инвестицию) и принять решения по запросу. Раз в месяц Драгош встречался с менеджерами продукта и другими заинтересованными лицами: проводилась новая расстановка приоритетов в бэклоге и составлялся план проекта по запросам.
В то время в месяц обрабатывалось около семи запросов. В бэклоге было более 80 записей, и его объем продолжал увеличиваться. Таким образом, ежемесячно подвергались переоценке более 70 запросов, а обработка запроса занимала в среднем четыре месяца. В этом и крылась основная причина неудовлетворительной работы. Сами запросы были небольшими, но постоянное изменение приоритетов означало стабильную неудовлетворенность клиентов.
Запросы фиксировались при помощи инструмента под названием Product Studio. Обновленная версия этой программы была впоследствии выпущена под названием Team Foundation Server Work Item Tracking. Команда техподдержки XIT представляла собой хорошо мне знакомый тип организации, в которой имеется множество данных, но они не используются. Драгош начал анализировать данные и обнаружил, что средний запрос занимал 11 рабочих дней.
Время выполнения при этом составляло от 125 до 155 дней, более 90 % времени тратилось впустую, в том числе на ожидание в очереди.
Оценки поступающей работы отнимали много ресурсов. Мы решили проанализировать процесс оценки, сделав ряд предположений. Хотя аббревиатура ROM расшифровывается как rough order of magnitude (приблизительный порядок величины), клиенты ожидали, что оценка будет очень точной, и члены команды проводили ее с особой тщательностью. У каждого разработчика и тестера одна оценка занимала примерно рабочий день. Мы подсчитали, что на это уходило около 33 % ресурсов команды, а в неудачный месяц – и 40 % рабочего времени, то есть больше, чем на разработку и тестирование. К тому же оценка новых запросов нередко вносила путаницу в планы, составленные на текущий месяц.
Помимо запросов на изменения у команды имелся и второй вид работ – так называемые текстовые изменения на продуктивной среде (Production text changes, PTC), касающиеся интерфейса, редакционных исправлений, изменения данных таблиц или xml-сообщений. Эти изменения не требовали участия разработчиков и часто вносились владельцами бизнеса, менеджерами продукта или программ. Но поскольку они подвергались формальной тестовой приемке, участие тестировщиков было все же необходимо.
PTC традиционно выполнялись прежде всей остальной работы или оценок. PTC поступали неравномерными порциями и тоже нарушали планы на месяц (рис. 4.3).
Рис. 4.3. Рабочий процесс, демонстрирующий оценки ROM и внесение PTC
Установление явных процедурных правил
Команда следовала предписанным процедурам, которые, к сожалению, содержали и неудачные решения, принятые менеджерами на различных уровнях. Важно помнить, что процесс – это набор правил, управляющих поведением, которые находятся под контролем руководства. Например, решение использовать PSP/TSP приняли на уровне вице-президента, то есть всего рангом ниже Билла Гейтса. Такое правило отменить тяжело или невозможно. Но другие правила, например приоритет оценок перед написанием кода и тестированием, были разработаны непосредственными руководителями на местах. Возможно, эти правила имели смысл, когда их внедряли. Но обстоятельства изменились, однако никто не попытался пересмотреть и обновить правила, по которым работала команда.
Оценка была пустой тратой времени
Побеседовав с коллегами и менеджером, Драгош решил внедрить в управление два важных изменения. Во-первых, команда перестала производить оценку. А те усилия, которые прежде тратились на нее, нужно было направить на разработку и тестирование ПО. Исключив этот фактор, вносивший к тому же хаос в рабочее расписание, Драгош надеялся повысить предсказуемость и, как следствие, – удовлетворенность клиентов.
Однако отказ от оценок вызвал целый ряд проблем. Он влиял на подсчет ROI, кроме того, клиенты могли заподозрить возможность неправильной расстановки приоритетов. К тому же оценки облегчали учет затрат и перераспределение бюджета между отделами, использовались для внедрения общих организационных принципов. В команду техподдержки поступали только небольшие запросы. Крупные, разработка или тестирование которых превышали 15 дней, должны были стать частью большого проекта и пройти все формальные процедуры управления портфелем проектного офиса (PMO). Вскоре мы вернемся к этому вопросу.
Ограничение задач в работе (WIP)
Еще одно изменение, задуманное Драгошем, – это ограничение числа задач в работе и вытягивание новых задач из очереди только после завершения старых. Он решил ограничить разработку одним запросом на разработчика, такой же норматив был установлен для тестировщиков.
Добавив очередь для получения PTC, он обеспечил равномерный поток работы между разработкой и тестированием, что показано на рис. 4.4. Этот подход – использование буфера для снижения вариативности размеров и усилий – обсуждается в .
Примечание. Это установленное правило: одна задача на одного разработчика в любое время. Позже правило может быть изменено. Представление процесса как набора правил – ключевой элемент Канбан-метода.
.
Рис. 4.4. Модель состояний, показывающая желаемый поток работ с ограничением незавершенной работы
Установление каденции пополнения
Примечание. Каденция – это понятие Канбан-метода, которое определяет ритм событий определенного типа. Расстановка приоритетов, поставка, ретроспективы и все повторяющиеся события могут иметь собственную каденцию.
Чтобы облегчить принятие решения об ограничении задач в работе и переходе на вытягивающую систему, Драгош должен был подумать о каденции взаимодействий с менеджерами продукта. Он посчитал, что еженедельное совещание – оптимальный вариант, поскольку его тема – пополнение входящей очереди производственной системы из бэклога. Обычно в течение недели освобождались три места в очереди, поэтому следовало обсуждать вопрос «Какие три элемента бэклога вы бы предпочли отправить сейчас в разработку?». Каденция моделируется на рис. 4.5.
Рис. 4.5. Рабочий процесс с Канбаном: ограничение задач в работе и очереди
Он хотел предложить «гарантированное» время выполнения – 25 дней с момента попадания задачи во входящую очередь. Конечно, 25 больше, чем 11. А на некоторые задачи требовалось до 30 дней. Но Драгош решил, что таких заданий не должно быть много. И, кроме того, 25 – это гораздо меньше, чем 140, а именно столько дней составлял текущий срок выполнения работ. Он рассчитывал добиться цели благодаря регулярности поставок, построению доверительных отношений с менеджерами продукта и их клиентами.
Достижение нового соглашения
Драгош сделал менеджерам продукта предложение – попросил примириться с тем, что они будут встречаться раз в неделю и обсуждать приоритеты, он ограничит количество незавершенной работы, а его команда перестанет заниматься оценкой. В обмен на это он сократит время выполнения до 25 дней и будет в дальнейшем ориентироваться на этот дедлайн.
Клиентам предложили отказаться от вычисления ROI и переводов бюджета между отделами на основе оценки планируемых трудозатрат. В обмен на это им пообещали беспрецедентно короткие сроки выполнения и надежность. Для удобства расчетов время обработки запроса – примерно 11 дней – устанавливалось на основании исторических данных, о чем говорилось выше, в разделе «Факторы, влияющие на производительность». Также их попросили считать затраты фиксированными и игнорировать ту калькуляционную парадигму, на которой ранее основывались переводы бюджета между отделами.
Драгош обосновывал эти перемены так: у организации-поставщика есть годичный контракт, по которому она ежемесячно выставляет счет. В соответствии с контрактом поставщик привлекает людей, получающих зарплату независимо от того, работают они в данный момент или нет. Бюджет, поступающий от четырех менеджеров продукта, – это фиксированная сумма, распределяемая пропорционально. Драгош гарантировал, что каждому менеджеру продукта достанется справедливая доля. Это освободит их от необходимости отслеживать каждый запрос. Если они смогут принять тот факт, что доллары приносят им гарантированный результат, то, возможно, откажутся от предубеждения против приблизительной оценки трудозатрат и переводов бюджета. Чтобы определить, чья очередь подходит, разработали несколько простых правил, поэтому распределение осуществлялось справедливо. Достаточно было простой круговой схемы с весовыми коэффициентами.
Внедрение изменений
Хотя менеджеры продукта и многие коллеги Драгоша по XIT оставались скептиками, они решили дать ему возможность попробовать. В конце концов, дела шли хуже некуда. Нужно было что-то предпринять, и Драгошу поручили внести изменения.
Итак, изменения начались.
И все наладилось! Запросы обрабатывались и выводились в новых релизах. Время выполнения по новым обязательствам укладывалось в обещанный 25-дневный срок. Ежедневные совещания работали как часы, пополнение производственной системы задачами тоже происходило каждую неделю. Менеджеры продукта стали проникаться доверием к команде.
Адаптация правил
Примечание. Это распространенная тема в канбан-методе. Сочетание четких правил, прозрачности и визуализации дает членам команды возможность принимать собственные решения и самостоятельно оценивать риски. Руководство в итоге начинает доверять системе, поскольку понимает, что процесс – это набор правил, которые предназначены для управления рисками и удовлетворения пользовательских ожиданий. Эти правила прописаны, работа открыто визуализируется, а все члены команды понимают правила и принципы их применения.
Но каким образом достигалась расстановка приоритетов, если подсчет ROI больше не проводился? Оказалось, что он и не нужен. Если элемент важен и ценен, то его выбирали из очереди в бэклоге, а если нет, то отодвигали дальше. Позже Драгош понял, что необходимо еще одно правило – безжалостно удалять из бэклога любой элемент более чем шестимесячной давности. Если за полгода о нем ни разу не вспомнили, то наверняка он не имеет никакого значения. А если выяснится, что данный элемент все же важен, то его можно включить заново.
А как насчет правила, согласно которому крупные запросы не поступали в техподдержку, а становились частью большого проекта? В итоге решили, что некоторые из них все же могут туда направляться. Опыт показывал, что таких запросов обычно менее 2 %. Разработчиков просили быть внимательными и, если новый запрос, по их оценкам, требовал на обработку более 15 дней, предупреждать своего менеджера. Риски и затраты в данном случае составляли менее 1 % доступной мощности. Это прекрасно окупалось: отказавшись от оценок, команда обрела более 33 % мощности за счет затрат менее 1 % той же мощности. Это новое правило позволило разработчикам управлять рисками и при необходимости высказывать свое мнение!
На первые два изменения отвели шесть месяцев. В течение этого периода внесли еще кое-какие незначительные улучшения. Как уже упоминалось, появилось правило очищения бэклога, а еженедельное совещание с владельцами продукта исчезло. Процесс протекал так гладко, что Драгош автоматизировал инструмент Product Studio: теперь он получал электронное сообщение каждый раз, когда образовывалось свободное место для нового задания. После этого Драгош предупреждал по электронной почте владельцев продукта, что им необходимо решить, за какое задание браться прежде всего. Производился выбор, и запрос из бэклога работы переводился в очередь через два часа после того, как появлялось свободное место.
Поиск дальнейших улучшений
Драгош начал искать способы для дальнейших улучшений. Изучив данные о продуктивности тестировщиков его команды и сравнив их с показателями других команд XIT от того же подрядчика, он заподозрил, что тестировщики располагают существенными резервами. Между тем звено разработчиков можно было назвать настоящим узким местом. Драгош решил навестить команду в Индии и, возвратившись, посоветовал подрядчику перераспределить ресурсы. Число тестировщиков сократили с трех до двух, но добавили дополнительного разработчика (рис. 4.6). Это привело к практически линейному увеличению производительности: пропускная способность за квартал повысилась с 45 до 56.
Рис. 4.6. Перераспределение ресурсов
Финансовый год Microsoft подходил к концу. Высшее руководство заметило значительный рост производительности и стабильности результатов команды техподдержки XIT.
Руководители наконец-то поверили в Драгоша и его методы. Отделу были выделены средства, чтобы нанять еще двух сотрудников. В июле 2005 года в команде появились новый разработчик и тестировщик. Результаты оказались существенными.
Рис. 4.7. Добавление ресурсов
Результаты
Дополнительная мощность позволила пропускной способности превысить требования. В результате бэклог 22 ноября 2005 года оказался полностью исполнен. К тому времени команда сократила срок выполнения в среднем до 14 дней при сохранении 11-дневного периода разработки. Выполнение 25-дневного дедлайна составляло 98 %. Пропускная способность увеличилась более чем втрое, время выполнения сократилось на 90 % и выше, а надежность программ примерно на столько же выросла. В процессы разработки ПО и тестирования не было внесено никаких изменений. Метод PSP/TSP остался неизменным, все корпоративные нормы, процедуры и контрактные обязательства строго соблюдались. Во второй половине 2005 года команда стала лучшей среди всех инженерных коллективов корпорации. Драгош получил дополнительные полномочия, а текущее руководство команды перешло к региональному менеджеру в Индии, который, впрочем, перебрался в Вашингтон.
Рис. 4.8. Квартальная пропускная способность на единицу производства
Эти улучшения отчасти стали возможны благодаря невероятным управленческим способностям Драгоша Думитриу, но главной причиной успеха послужили типовые элементы – формирование цепочки создания ценности, анализ потока, задание лимита задач в работе и внедрение вытягивающей системы. Без парадигмы потока и канбан-подхода к ограничению задач в работе выигрыш в производительности был бы невозможен. Благодаря Канбану произошли постепенные изменения, притом с низким политическим риском и уровнем сопротивления изменениям.
Пример XIT показывает, как вытягивающую систему с ограничением незавершенной работы можно применить к распределенному проекту с удаленной командой и как в этом помогает электронная система управления задачами.
Никакой визуализации еще не было, и многие более сложные приемы Канбан-метода, описанные в этой книге, в то время не существовали.
Рис. 4.9. Время выполнения командой техподдержки XIT по финансовым годам Microsoft
Но какой менеджер проигнорирует возможность увеличить производительность более чем на 200 %, сократить время выполнения на 90 % и существенно повысить предсказуемость при минимальных политических рисках и сопротивлении изменениям?
Выводы
• Первая канбан-система была внедрена в команде техподдержки XIT в Microsoft в 2004 году.
• Первая канбан-система использовала ПО для отслеживания работы.
• Первая канбан-система была внедрена в удаленной команде подрядчика в Хайдарабаде, которая стояла на пятом уровне в модели зрелости CMMI.
• Рабочий поток требуется описать и визуализировать.
• Процесс следует описывать как явно заданный набор правил.
• Канбан способствует постепенным изменениям.
• Канбан минимизирует политические риски при внесении изменений.
• Канбан минимизирует сопротивление изменениям.
• Канбан предоставляет возможности совершенствования, которые не предполагают сложных изменений в инженерных методах.
• Первая канбан-система показала более чем 200 %-ное увеличение производительности, 90 %-ное снижение времени выполнения и примерно такое же увеличение предсказуемости поставки.
• Значительные изменения становятся возможными благодаря управлению узкими местами, исключению потерь времени и снижению вариативности, которая негативно влияет на ожидания и удовлетворенность клиента.
• Чтобы изменения привели к результату, нужно время. В данном случае понадобилось 15 месяцев.
