Визуализируйте работу Деграндис Доминика

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

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

Меня часто спрашивают, как лучше повлиять на IT-директора, чтобы он согласился использовать DevOps / бережливое производство / Канбан / любой другой подход. IT-директора, с которыми я общалась, хотят две вещи: меньше риска и больше прогнозируемости. Диаграмма расхитителей времени как раз это показывает. Она отображает риск (то есть неопределенность) относительно незапланированной работы, заброшенной, конфликтующих приоритетов и неизвестных зависимостей. Диаграмма расхитителей времени также демонстрирует, когда WIP выходят за рамки ограничений (основываясь на лимитах, установленных самой командой). Поскольку WIP — ведущий индикатор, то, отслеживая его уровень, можно выявить проблемы на раннем этапе, и мы будем знать, что работа займет больше времени, чем ожидалось. Если важна прогнозируемость сроков, ваш IT-директор был бы на седьмом небе от счастья, получив такую прозрачность. Эффективная коммуникация требует ключевых сведений из разных источников. Диаграмма расхитителей времени станет надежным источником важной информации.

3.3

ОБЗОР ОПЕРАЦИЙ

Дэвид Андерсон предложил проводить обзор операции в Corbis. Все менеджеры должны показать метрики своей команды. Мне как руководителю впервые предстояло презентовать метрики группе из 30 человек. В ужасе я стояла в конференц-зале: голос дрожал, сердце бешено стучало и казалось, что меня стошнит. А если мое выступление разочарует команду?

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

На рисунке 48 предложена кумулятивная диаграмма потока (КДП) — это диаграмма с накоплением, которая показывает объем текущих и выполненных задач. Я представляла ее ежемесячно на обзоре операций от лица команды билда и релиза. С наступлением июня количество входящих запросов устремлялось вверх и, так как я смогла продемонстрировать этот взлет, мою просьбу о расширении команды одобрили.

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

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

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

Пример агенды13 обзора операций:

• вступительное слово руководства компании;
• презентации лидеров команд и фронтлайн-менеджеров;
• заключительное слово.

Какие метрики представить в обзоре

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

В начале обзора руководителям команд нужно сообщить следующие метрики и данные по первым нескольким месяцам:

1. Пропускная способность: сколько задач было выполнено за определенный период. Один из способов показать пропускную способность — кумулятивная диаграмма потока (КДП). Она также покажет соотношение входящих задач, выполненных проектов и WIP на каждом этапе.
2. Время потока: сколько времени нужно для передвижения задач по доске, начиная с момента вытягивания задачи в колонку «В работе» и до самого конца — когда задача выполнена. Визуально (надеюсь, отчет легко можно составить в вашем инструменте управления рабочим потоком) покажите реальное время потока по каждому выполненному проекту за предыдущий месяц. Это полезная информация, поскольку вы сможете внести изменения в процессы или систему либо снизить изменчивость и повысить прогнозируемость. Или, если размер карточек примерно одинаковый, интересно рассчитать среднее время цикла или выполнения задачи.
3. Проблемы и заблокированная работа: выделите основные проблемы или заблокированную работу, которая мешает команде двигаться вперед. Это поможет понять, почему выполнение задач заняло столько времени и какие изменения внесены, чтобы предотвратить подобные проблемы.
4. Диаграмма расхитителей времени: выберите одного или нескольких расхитителей времени и обличите их.

Дополнительные метрики, которые можно добавить в обзор:

• отчеты по задолженности;
• категории карточек;
• критическая нагрузка (соотношение требования ценности и требования сбоя) как метрика качества;
• эффективность потока.

Обзор будущих операций

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

Другой пример: между Портлендом и Сиэтлом ходит пассажирский поезд железнодорожной корпорации Amtrak и предполагается, что он должен следовать определенному расписанию в течение дня. Согласно графику последний состав приезжает в Сиэтл в 20:05. Но иногда он приходит в 20:25. И даже в 2:30 ночи. Так что он совершенно непредсказуем. Широкий диапазон времени прибытия создает изменчивость в расписании поезда.

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

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

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

3.4

ИСКУССТВО ВСТРЕЧ

Сиэтл, среда, 9:00

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

Это лин-кофе («бережливый кофе») — структурированная встреча с минимальными правилами. Участники собираются, выстраивают агенду и начинают обсуждать.

Придуманный Джимом Бенсоном и Джереми Лайтсмитом в 2009-м, лин-кофе стал одним из наиболее эффективных способов для группы обсудить те или иные идеи [1]. Это продуктивно, потому что агенда составляется по демократическим принципам. Люди вовлечены, поскольку могут поговорить на важные для них темы. Лин-кофе работает, потому что участники сами выбирают агенду обсуждения и голос каждого обязательно будет услышан. Минимальные правила вкупе со взаимоуважением создают условия, стимулирующие открытый диалог и сотрудничество. Адам Юрет, автор книги How to Have Great Meetings: A Lean Coffee Book («Лучшие встречи: руководство по лин-кофе»), говорит:

Лин-кофе ставит традиционные односторонние встречи с ног на голову, помогая командам сформулировать самые важные для большинства темы, позволяя каждому услышать и быть услышанным и обеспечивая обратную связь в режиме реального времени [2].

Я добавлю, что лин-кофе не просто меняет характер командных встреч, этот формат способен преобразовать всю культуру предприятия.

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

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

Как готовить лин-кофе

Мой опыт фасилитации лин-кофе с 2012 года позволил выработать неплохой план действий для проведения этих встреч в команде или компании.

Сначала выделите 60–90 минут.

Затем разложите на столе стикеры и маркеры. Когда все рассядутся, объясните правила лин-кофе: говорить может только один и все должны стремиться больше слушать, чем говорить.

Затем предложите участникам в течение двух-трех минут, вооружившись стикерами и маркерами, набросать столько тем, сколько они хотят, однако на каждом листке должна быть только одна тема (куда мы без стикеров!). После этого участники коротко (пары предложений обычно вполне достаточно) резюмируют свои темы для группы, чтобы другие поняли, за что голосуют. Каждый получает два голоса. Можно выбирать и свои темы. Или отдать оба голоса одной теме или двум разным.

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

Установите таймер на пять минут и предложите автору темы из первой колонки начать дискуссию. Фасилитатор должен проследить, чтобы у каждого была возможность высказаться. (Следите, чтобы громогласные экстраверты не монополизировали обсуждение!) Когда зазвенит таймер, позвольте спикеру закончить мысль, затем проголосуйте: большой палец вверх или вниз. Если большинство пальцев вверх, обсуждение можно продлить еще на минуту. Большинство пальцев вниз означает, что группа готова перейти к следующей теме. В случае ничьей решает фасилитатор.

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

Хотя лин-кофе обычно проводят с небольшой группой, количество участников неограниченно (рис. 49). Я проводила лин-дискуссии, где было 15–20 столов по 10 человек за каждым.

Стендапы

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

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

В одной компании, где я работала, группа из 35 человек ежедневно проводила стендапы в 9:30. Изначально применяли «хождение по комнате». Некоторым было настолько некомфортно говорить, когда на них все смотрят, что они бормотали нечто несуразное. Кому-то нравилось внимание, и они старались отхватить как можно больше ценного времени. Представьте, сколько денег теряет компания, когда 35 инженеров и менеджеров тратят время на неэффективную встречу, не говоря уже о том, что безумно скучно слушать 35 докладов о статусе работы. Правила изменились. Вместо расхаживания по комнате мы решили до 9:00 обновлять доску. Теперь достаточно было просто взглянуть на нее, чтобы увидеть последние сведения по статусу работы, а на стендапе обсудить более важные вопросы — риск и неопределенность.

Три вопроса легли в основу новой агенды стендапов:

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

Изменения позволили команде сразу же увидеть и распознать основные факторы, препятствующие завершению работы. Три вопроса сделали стендапы простыми и быстрыми. Они заканчивались к 9:45 (всего 15 минут), и это приводило к удивительным результатам, совершенно неожиданным и спонтанным. Инженеры оставались после стендапов (потому что у них было еще 15 минут до следующей встречи) и обсуждали свои проблемы, блокировавшие работу. Мы назвали это временем после стендапа. Раньше мне приходилось назначать встречу за восемь дней, чтобы найти время в графике инженеров и свободную комнату (переговорные помещения всегда пользовались ошеломительным спросом, и люди часто устраивали заседания в кофейнях неподалеку).

В итоге количество встреч сократилось, потому что сотрудники оставались после стендапа и решали проблемы, которые только что обсудили. Полчаса — оптимальное время для 15-минутного стендапа, оставляющее еще 15 минут до следующего заседания.

Количество прерываний тоже сократилось, потому что сотрудники уже не заглядывали ко мне в офис с вопросом: «Есть пять минут?»; они знали, что смогут поговорить со мной после стендапа и осветить актуальные темы или быстро получить ответ.

Стендап и минуты после него позволили вывести на чистую воду всех расхитителей времени, что сэкономило немало часов.

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

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

3.5

ЗВЕРСКИЕ ПРАКТИКИ

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

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

Метрики времени потока, которые исключают выходные

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

1. Все метрики опираются на допущения. И чтобы дискредитировать метрику, достаточно подвергнуть сомнению эти допущения. Приведу пример. Вы говорите, что никогда не работаете по выходным? А по праздникам? А в отпуске? Нужно учитывать отпускные дни, причитающиеся сотрудникам, или только те, которые они реально используют? А если просто учитывать время, проведенное на работе? Все всегда заняты 40 часов в неделю? Сколько времени вы готовы потратить на споры вокруг допущений и предположений, чтобы сделать свои метрики обоснованными?
2. Если исключить время потока, данные будут некорректны. Что происходит, если решения об использовании ресурсов принимаются без табеля учета времени? Насколько точны эти расчеты? Когда люди работают по выходным, но не учитывают это время, метрики могут показаться предательски обнадеживающими. Более того, я видела, как сотрудники уделяли 100% своего времени проекту, так как боялись, что в противном случае это плохо отразится на их карьере. Данные были неверными, и все это знали. Если вы используете метрики, чтобы стыдить людей, то поощряете нечистоплотное поведение. То же самое касается таргетированных метрик. Когда акцент делается на метрике, а не на цели, это проблема. Если люди скрывают информацию, мы теряем прозрачность.
3. Бизнес-клиентам важна продолжительность. Если вы мой клиент и я говорю вам, что задача будет выполнена за месяц, но потом не укладываюсь в срок, потому что учла только рабочие дни, вы вряд ли обрадуетесь. Клиентам все равно, сколько времени их продукт провел на этапе разработки или тестирования. Они хотят знать продолжительность процесса.

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

Неэффективные методы расчета с табелем рабочих часов

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

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

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

Диаграммы Ганта

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

Диаграммы Ганта делят задачи проекта на временные интервалы, которые снова разбиваются на группы подзадач. Руководители проектов отмечают сроки их выполнения и поощряют сотрудников соблюдать их. Можно, к примеру, услышать такое обещание: «Если проект V будет выполнен к 1 июля, ты сможешь взять два дня отпуска на празднование Дня независимости, 4 июля!»

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

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

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

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

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

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

Дорожки с именами

На рис. 50 показана канбан-доска, которую навязал команде ее руководитель.

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

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

1. Так как доска составлена по конкретным сотрудникам, на стендапах тоже говорили о них, а не о самой работе. Стендап превратился в личное соперничество. «Я сделал это», «Я занимаюсь этим», «Я собираюсь заняться еще и этим». В центре внимания должна быть работа, а не люди.
2. Когда некоторые сотрудники не перемещали свои карточки так же быстро, как другие, возникало ощущение непрофессионализма и неэффективности. Не вся работа одинакова. Одни задачи больше поддаются расхитителям времени, чем другие. Незапланированная работа может раздувать объем дел и нарушать график. (Помните влияние оползней на расписание поезда?)
3. Люди решили, что нельзя притрагиваться к работе, которая выходит за рамки их дорожки. Вместо того чтобы развивать в себе Т-образные навыки (рис. 51), они сосредоточились на своей узкой специализации, что порадовало расхитителя по имени «Неизвестные зависимости».
   

   Рис. 51. Т-образные навыки

4. Акцент на производственной мощности мешал сотрудничеству. Людей поощряли не помогать друг другу. Зачем Алану помогать Рассу, если это значит, что работа из дорожки Алана займет больше времени? Люди будут приоритизировать проекты, чтобы выставить себя в лучшем свете. Подобное поведение может снизить бизнес-ценность. Возможно, самое ценное, что Алан мог сделать для компании, — помочь Рассу закончить его дело.

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

Работа, рассеянная повсюду

Организовать встречу — непростая задача. Убедиться, что нужные люди придут в подходящее время, чтобы обсудить важные темы и достичь необходимого результата, — согласитесь, это нелегко. А если добавить три разные доски, шесть электронных таблиц, четыре канала Slack, видеоконференцию с плохой связью, двадцать семь открытых браузеров и тьму тьмущую других инструментов и приложений — добро пожаловать в ад. Кто захочет управляться со всем этим хаосом? Никто, если ваша цель — дать хорошего пинка расхитителям времени, это точно. Старайтесь упростить процесс, чтобы люди меньше времени тратили на поиск информации. Время, потраченное на поиск, повышает объем WIP.

Слишком яркие цвета карточек

На информацию/данные приятно смотреть, но не тогда, когда цвета визуально совершенно не сочетаются друг с другом или фоном. Красота привлекает. Выбирая интерфейс Канбан, думайте о красоте. Автор трех бестселлеров по визуализации информации и спикер на конференции TED Talks Дэвид Маккэндлесс выделяет четыре необходимых элемента визуализации работы.

• Информация: данные должны быть объективными и точными.
• Функция: цель должна быть полезной и эффективной.
• Визуальная форма: символическое изображение информации должно быть красивым и структурированным.
• История: концепция должна быть интересной и актуальной [1].

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

Лучшие практики

В Гонолулу, во время работы на Boeing, я услышала, как кто-то (вообще-то это был мой босс) сказал: «Сделайте все правильно с первого раза». Я инстинктивно поняла, что это неверный принцип. Единственная ситуация, когда человек может сделать все правильно с первого раза, — когда он следует указаниям другого человека, который уже делал это много раз. Когда впервые берешься за работу, это всегда эксперимент. С Канбан та же история. Первая доска будет экспериментом, который поможет понять, как улучшить рабочий поток. Вот почему нельзя сказать, что есть «лучшая практика», когда речь идет о проектировании вашей канбан-доски, как и во многих других ситуациях. Если вы не делаете чего-то предельно простого, что было выполнено до вас сотни раз, — того, в чем известны причина и следствие, — невозможно абсолютно точно знать, что делать. Мы просто еще не знаем, чего еще мы не знаем.

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

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

ЗАКЛЮЧЕНИЕ: КАЛИБРОВКА

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

Марк Твен

Маунтин-Вью, Калифорния, сентябрь 2011 года

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

Теперь, глядя на этот оранжевый стикер (я его сохранила), я вспоминаю, что не знала, как ответить. Сейчас эта тема не менее актуальна, чем в 2011 году. Мой ответ сегодня начинается с одного комментария и двух вопросов. Комментарий: любое изменение, даже хорошее, влияет на результативность. Например, если в команде появляются новые люди, им нужно время, чтобы адаптироваться и нагнать остальных. Естественно, это повлияет на команду. Но стоит ли оно того? Должна быть конкретная выгода, чтобы нарушить налаженный процесс. А теперь два вопроса:

1. Зачем вам Канбан, если команды уже показывают высокую пропускную способность?
2. Какую проблему вы хотите визуализировать?

Мне придется сделать массу предположений, чтобы сформулировать достойный ответ. Допустим, что, несмотря на высокую пропускную способность, команда перегружена и существует только благодаря героическим усилиям избранных, которые выполняют план. Проблема, которую вы хотите обозначить, — чрезмерные требования к группе (слишком большой объем WIP) и их причины. Если визуализировать этот момент, вы увидите проблему и придумаете, что делать дальше. К примеру, сократить WIP и переосмыслить приоритеты. Или нанять больше людей, чтобы справиться со всеми задачами (и удержать сотрудников от бегства).

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

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

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

Согласованность работы технической команды и бизнес-команды

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

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

Люди тяжело воспринимают изменения и часто сопротивляются им всеми силами, особенно во время значительных преобразований. Коучи бережливого производства называют это кривой J (рис. 53). Крупные изменения вызывают спад производительности по самым разным причинам: нужно изучить новый материал, нанять людей, установить и использовать новые инструменты и так далее и тому подобное. Именно поэтому небольшие, поэтапные изменения легче внедрять. Они вызывают гораздо меньше отторжения. Возьмем, к примеру, eBay.

Однажды проектировщики eBay решили, что ярко-желтый фон — уже не круто и нужно сменить его на белый. Клиенты не проявили энтузиазма. Многие жаловались и требовали, чтобы eBay вернул желтый цвет. Так и сделали. Через несколько месяцев компания стала менять цвет фона постепенно, убирая по одному оттенку желтого за раз, пока весь колер не исчез, уступив место белому [1]. Пользователи ничего не заметили. Вот сила постепенных изменений — они встречают меньше сопротивления, поскольку людям предлагают постепенно приспосабливаться к новшествам, вместо того чтобы полностью перевернуть их жизнь с ног на голову. Предложите поэтапные изменения, а не революцию.

Другие трудности новых методов работы:

1. Ограничивать WIP кажется страшным и нелогичным. Лимитирование WIP означает, что люди не смогут со всем соглашаться, то есть будут чувствовать неловкость. Однако если игнорировать ограничения WIP, подумайте, что произойдет со временем потока и уровнем хаоса. Выберите достаточно реалистичные лимиты WIP, но при этом вынуждающие иногда говорить нет.
2. Требований всегда больше, чем возможностей. Остерегайтесь старых привычек, когда вы брались за все, что только можно, потому что никому не могли отказать. Помните: ограничители WIP — ваши друзья и ключ к выполнению самой важной работы.
3. Если человек боится, вряд ли он готов участвовать в визуализации, к которой вы стремитесь. Лидеры команды должны изгнать всякий страх, чтобы люди спокойно относились к такому уровню прозрачности. Не давите на людей; измените систему.

Что может сбить вас с курса:

1. Когда вы зациклены на внутренних процессах и не уделяете достаточно внимания взаимодействию с другими участниками и клиентами. Нужен баланс. Когда приоритизируете работу, учитывайте цену задержки — во сколько это обойдется вашему бизнесу.
2. Когда вы никак не можете завершить работу, потому что стараетесь добиться совершенства. Вы будете развиваться бесконечно. Законченный пост в блоге — это лучше, чем полное его отсутствие. Продемонстрируйте результаты своей работы, чтобы как можно скорее получить обратную связь.
3. Когда вы пытаетесь исправить все сразу. Визуализируйте текущее положение дел, а затем внесите небольшие коррективы, чтобы оценить воздействие каждого изменения и научиться на своих ошибках.
4. Когда вы ждете быстрых результатов. Могут пройти месяцы, прежде чем вы выработаете оптимальную форму Канбан. И даже тогда вы будете постоянно совершенствоваться. Всегда есть место для улучшений.

Как коуч бережливого производства я часто слышу вопрос: в чем разница между Канбан и Scrum (аgile-фреймворк по управлению проектами)? И то и другое относится к Agile, которая вносит ограничения, чтобы стимулировать продуктивные результаты.

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

Меня вдохновили Клаус Леопольд и Зигфрид Калтенекер, которые написали краткую презентацию Канбан в книге Kanban Change Leadership: Creating a Culture of Continuous Improvement («Трансформационное управление Канбан: как создать культуру непрерывного совершенствования»):

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

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

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

Чтобы изменить методы работы, нужно изменить мышление и отношение.

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

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

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

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

Однако я занимаюсь этим не ради теорий и метрик. Формулировать абстрактные или не интуитивные идеи в устной форме — не мой конек. Слова не поспевают за работой мысли. Я многое знаю о визуализации работы по той причине, что чаще всего (почти всегда) мне проще общаться визуально, а не устно. Меня всегда привлекал процесс визуализации работы и идей, чтобы людям было легко увидеть проблему или ситуацию. Создавать полезную, актуальную, зрительно доступную и красивую информацию, чтобы помочь людям понять происходящее на самом деле, — чистое наслаждение. Но я делаю это по другой причине.

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

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

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

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

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

Удачи!

СЛОВАРЬ

А3: метод, названный в честь общепринятого бумажного формата 11  17 дюймов (297  420 мм), позволяет структурировать дискуссию, чтобы достичь понимания и согласия.

Agile: инкрементальные и итерационные улучшения, которые проводятся с регулярной каденцией; альтернатива традиционным методам управления проектом, предлагает частую переоценку и адаптацию планов.

Scrum: аgile-фреймворк, который помогает завершить проекты.

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

Бережливое производство (Lean): философия в духе Сократа, нацеленная на совершенствование процесса. Бережливое производство опирается на принцип «точно вовремя» и визуальное управление.

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

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

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

Время выполнения: время, необходимое для обработки запроса, начиная с поступления запроса и заканчивая доставкой продукта клиенту.

Время развертывания: время, которое нужно для развертывания изменений, после того как код попадет в систему контроля версий.

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

Диаграмма Ганта: иллюстрация даты начала и конца всех этапов процесса.

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

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

Загрузка производственной мощности: процент общей возможной загрузки. Если человек способен работать по 10 часов в день, но работает 7 часов, то его загрузка составляет 70%.

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

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

Контрмеры: действия, которые предпринимаются для решения проблемы.

Объем незавершенных задач (WIP): вся работа, начатая, но еще не законченная.

Ограничение: узкое место системы; то, что мешает развитию.

Отток: клиенты или подписчики, которые рвут связи с вашим сервисом или компанией.

<>Очередь: вагон работы, ждущей, когда на нее обратят внимание; работа на стадии ожидания.

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

Первым пришел — первым ушел (FIFO): метод приоритизации, когда задачи обрабатываются в порядке их поступления.

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

Поток: система вытягивания, когда производственный процесс протекает гладко и прогнозируемо; позитивные аспекты и радость нахождения «в зоне».

Поток работы: последовательность рабочих операций в системе от начала до конца.

Поток создания ценности: полный цикл работы по конкретному продукту или услуге, нацеленной на создание бизнес-ценности.

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

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

Разработка на основе функционала (FDD): вид аgile-разработки, основанный на межфункциональной, коллективной разработке функций с соблюдением определенных временных рамок.

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

«Серебряная пуля»: срочный запрос, неотложная задача; обычно инициируется руководством компании.

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

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

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

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

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

Скорость команды: количество story points за пользовательскую историю, выполненных за определенное время (обычно две недели).

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

Стендап: короткая (обычно 15 минут) встреча, где команда обсуждает те или иные вопросы. Так как длится она всего 15 минут, люди обычно стоят.

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

Технический долг: дополнительные усилия, необходимые для того, чтобы исправить баги в программе и разработать новые функции — из-за предыдущих поспешных и необоснованных решений проектирования.

Требования сбоя: требования, вызванные сбоем, — когда не получилось выполнить задачу для клиента (вообще или должным образом).

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

Цена задержки (ЦЗ): способ отразить ценность и срочность задачи; демонстрирует влияние времени на ценные результаты.

Эффект масштаба: концепция экономики, которая связывает снижение расходов с ростом производительности; ценовая выгода, которая появляется с повышением объема производства.

Эффективность потока: процент времени, необходимого для выполнения работы, по сравнению со временем ожидания. Как рассчитать эффективность потока: время работы / объем работы + время ожидания.

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

БЛАГОДАРНОСТИ

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

Мне было бесконечно приятно работать с потрясающей Анной Ноак. Анна — самый увлеченный редактор, каких я знаю; она всегда готова помочь. Она поддерживала и обучала меня на протяжении всего процесса подготовки и издания книги — по выходным, праздникам и даже во время отпуска — как настоящий мастер своего дела. Так как я плохо разбираюсь в иллюстрациях, мне очень повезло работать с Джой Стобер; мы вместе выбирали цвет и создавали дизайн. Я также высоко ценю помощь редакторов Сильвии Коттрелл, Сары Хейлман и Ли Брауна.

Эта книга стала для меня возможностью собрать воедино и осмыслить все, что я узнала за время преподавания и коучинга бережливого производства, Канбан и потока. Мне бы хотелось поблагодарить всех коллег и друзей, которые повлияли на меня, пока я набиралась опыта, особенно команду Corbis — за поддержку в первые годы моих экспериментов; это Ларри Коэн, Даррен Дэвис, Сенди Томпсон, Эли Херст, Джей Фрир, Калвин Нгиен, Дуэйн Джонсон, Дебби Эрл, Сюзанн Бегдон, Джейсон Бирклид и Рик Гарбер.

У меня было множество учителей, которые помогли разобраться с Agile и Lean: Дэвид Андерсон, Даниэль Ваканти, Крис Хефли, Ян Кэрролл, Матиас Янсон, Арне Рок, Лиз Кеог, Торбьерн Йиллебринг, Матиас Скарин, Ювал Юрет, Карл Скотланд, Дэвид Джойс, Кэтрин Кирк, Клаус Леопольд, Маркус Андрезак, Павел Бродзински, Хакан Форсс, Йоаким Сунден, Эрик Виллеке, Дон Рейнертсен, Майк Барроуз, Джим Бенсон, Рассел Хили, Стив Холт, Майкл Чевелдейв, Джефф Андерсон, Джейсон Йип, Джон Терри, Гаэтано Маззанти и Джошуа Арнольд.

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

На DevOps Seattle 2016 Поли Комтуа продемонстрировал одну из его первых нарисованных от руки презентаций, которая вдохновила последовать его примеру. Позже в том же году Дэвид О’Нил познакомил меня со своей техникой рисования. Благодарю их обоих — мои презентации изменились в лучшую сторону.

Хотелось выразить особую благодарность за доброту, поддержку и терпение во время моего знакомства с сообществом DevOps, которое вдохновило меня в 2011–2012 годах и до сих пор воодушевляет практиковать то, чему я научилась: Патрик Дебуа, Джон Винсент, Дэймон Эдвардс, Эндрю Шафер, Стивен Нелсон-Смит, Джон Уиллис, Джез Хамбл, Бен Роквуд, Мэнди Уоллс, Дженнифер Дэвис, Том Салстон, Майкл Рембетси, Мариус Дука, Адриан Кокрофт, Картик Геквад, Джеймс Виккетт, Эрнст Мюллер и Саша Бейтс.

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

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

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

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

ПРИМЕЧАНИЯ

Введение

Часть 1

1.1

1.2

1.3

1.4

1.5

Часть 2

2.1