Эту книгу хорошо дополняют:

Scrum

Джефф Сазерленд

Постигая Agile

Эндрю Стеллман, Дженнифер Грин

Коучинг agile-команд

Лисса Адкинс

Канбан

Дэвид Андерсон

Making Work Visible

EXPOSING TIME THEFT TO OPTIMIZE WORK & FLOW

DOMINICA DEGRANDIS
FOREWORD BY TONIANNE DEMARIA

IT REVOLUTION PRESS
PORTLAND, OR

Визуализируйте работу

Как выявить расхитителей времени и оптимизировать процессы

ДОМИНИКА ДЕГРАНДИС

Москва
«Манн, Иванов и Фербер»
2020

Информация
от издательства

Научный редактор Анастасия Макарова

На русском языке публикуется впервые

Издано с разрешения IT Revolution Press LLC c/o Fletcher & Company и Andrew Nurnberg Associates International Ltd. c/o Andrew Nurnberg Literary Agency

Деграндис, Доминика

Визуализируйте работу. Как выявить расхитителей времени и оптимизировать процессы / Доминика Деграндис ; пер. с англ. М. Чомахидзе-Дорониной ; [науч. ред. А. Макарова]. — М. : Манн, Иванов и Фербер, 2020.

ISBN 978-5-00146-399-3

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

Книга будет интересна IT-специалистам, разработчикам, руководителям IT-компаний.

Все права защищены.

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

СОДЕРЖАНИЕ

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

ПРЕДИСЛОВИЕ

День — сущ.
Период, состоящий из двадцати четырех часов, в основном растраченных впустую.

Амброз Бирс

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

Мне бы хотелось пресечь на корню эту снисходительную ложь и подчеркнуть: все не совсем так, как говорят. Хотя многие бизнес-идолы проявляют, казалось бы, сверхчеловеческую работоспособность и вкалывают по сто часов в неделю, а то и больше, у них все же есть преимущество перед нами, простыми смертными. Даже если мы с ними располагаем одинаковым количеством минут каждый день, тратим их совершенно по-разному. Когда у Илона Маска накапливается слишком много незавершенных задач, он имеет возможность делегировать их, исключить из приоритетов или просто сказать нет. Если возникают неожиданные обстоятельства и тщательно продуманный стратегический план перестает отвечать потребностям организации, Шерил Сэндберг запросто переключается на что-то другое. А когда Джефф Безос сталкивается с конфликтующими приоритетами, вряд ли ему приходится преодолевать десятки бюрократических инстанций, чтобы выяснить, каким курсом следовать.

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

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

Мы экономим время. Тратим его. Пускаем по ветру. Казалось бы, бесплатное, но тем не менее бесценное время, бесспорно, один из самых драгоценных ресурсов, каким мы располагаем, но нам его всегда не хватает — как индивидуумам, так и командам и организациям.

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

Вы не одиноки.

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

Стремление укротить время или удержать его совсем не ново. Доисторические люди отслеживали фазы Луны. Шумеры создали шестидесятеричную систему счисления, которую мы применяем до сих пор: делим час на шестьдесят минут, а минуту на шестьдесят секунд. Египтяне использовали обелиски, чтобы рассчитывать длину теней, отбрасываемых Солнцем. Но недостатки солнечных часов стали очевидны, как только небо затянули облака и наступила ночь, так что персы и греки предложили альтернативу — клепсидру (водяные часы) — и стали отслеживать время с помощью потока воды.

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

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

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

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

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

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

Если на свете и есть место, где я мало думала о времени, так это жемчужина северо-западной части Тихого океана — острова Сан-Хуан.

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

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

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

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

Дышать. Мыслить. Учиться. Расти. Веселиться. Любить. Жить.

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

Тонианна Демариа,
остров Оркас, Вашингтон

ВВЕДЕНИЕ: РАБОТА И ПОТОК

Не тратьте время впустую: это материал, из которого соткана жизнь.

Бенджамин Франклин

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

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

В научно-фантастическом фильме «Время» жизнь исчисляется секундами, которые буквально стоят денег: люди зарабатывают минуты, часы и дни, чтобы покупать еду, оплачивать проживание, транспорт и все остальное. Бандиты убивают людей, воруя их минуты. Растрачивать часы впустую — верный путь к смерти. В одном памятном эпизоде Уилл Салас, которого играет Джастин Тимберлейк, спасает жизнь богача — Генри Хамильтона, героя Мэтта Бомера. Когда оба добираются до безопасного укрытия, Генри рассказывает 28-летнему Уиллу, что ему 105 лет и он устал от жизни. Он спрашивает, что бы тот сделал, если бы жил сто лет. Уилл отвечает язвительно: «Я бы точно не стал тратить время понапрасну». Позже, когда парень засыпает, Генри передает ему свои сто лет и оставляет записку: «Не трать мое время понапрасну», а затем садится на край высокого моста и ждет, когда его часы отсчитают последние секунды [1].

Эта скомканная записка из научно-фантастической антиутопии прекрасно отражает нашу реальность. Время — это жизнь, пользуйтесь им мудро.

Мы мучаемся от бесконечных посягательств на наше время. Всем, от разработчиков до айтишников, тяжело соответствовать вечно растущим требованиям. В этом отношении не так уж много изменилось с моей первой работы после колледжа, когда я руководила конфигурацией софта в компании Boeing и занималась билдами и развертываниями на мейнфреймах IBM на базе ВВС Хикэм (Гавайи).

У моего рабочего стола выстраивались толпы коллег, которым не терпелось узнать статус билда. «Можно внести еще одну, последнюю коррективу?» Мне так хотелось сказать: «Встаньте в очередь. Я на пределе. Каждый раз, когда вы меня отвлекаете, дело затягивается еще на десять минут». То, что разработчики и тестеры приходили выяснить статус билда, было симптомом гораздо более серьезной проблемы, которую я в то время не распознавала.

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

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

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

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

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

В 2000-х годах я работала в компании Билла Гейтса Corbis (Сиэтл), в крупнейшем международном фотобанке: возглавляла команду билда и конфигурации.

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

Чтобы справиться со всеми этими изменениями, мы создали дополнительные долгоживущие ветки в рамках системы управления версиями — где разработчики хранят свои коды. Ужасное решение, но это помогло командам не нарушать чужих корректировок. Долгоживущие ветки — это место, где код хранится обособленно, там невозможно проверить, как он будет воздействовать на код, уже переданный в продакшен. Это как взять из приюта старую кошку и надеяться, что она и ваш кот, который старше ее лет на сто, примут друг друга с распростертыми лапами. Когда предстоит конфигурировать и поддерживать больше двухсот серверов, требуется грамотное управление. Нужно было как минимум две недели, чтобы восстановить данные продакшена в среды предпродакшена. Раз в шесть недель мы проводили день С (слияние), что отнимало немало времени у разработчиков.

Наша репутация ухудшилась. Разработчики жаловались, что на билды уходит слишком много времени. Это, естественно, оскорбляло меня. Я вознамерилась доказать, что они ошибаются, и записала сроки создания и развертывания билдов (рис. 1).

Я отметила, что архитектурная катастрофа — система с нераспознаваемой структурой — делала развертывание и поддержку сред проблематичными. Ручные smoke-тесты (проверка функционала сайта) затягивают время, спустя которое разработчики и тестеры могут увидеть последние изменения, а отсутствие автоматического тестирования мешает быстро выявлять проблемы. Ручные smoke-тесты были нормой. Так что начальство посчитало обе проблемы надуманными. Но факт оставался: разработчиков и тестеров это не устраивало. Бизнес-аналитиков — тоже. И начальство было недовольно. Какая радость работать в команде, которая «не справляется». Преграды между группами были сильнее, чем связи. Типичная проблема неадекватной системы.

Мой опыт работы с неадекватной системой совпал с решением финансового директора заменить систему планирования бизнес-ресурсов (ERP) другим продуктом под названием SAP. ERP — информационная система менеджмента, которая охватывает планирование, закупку, материально-техническое обеспечение, продажи, маркетинг, финансы и HR. SAP — собственная система ERP, разработанная SAP AG, четвертой крупнейшей софтверной компанией в мире.

Босс спросил меня: «Не возьмешь ли ты на себя управление командой SAP Basis в рамках управления командой билдов и релизов?» И, как форменная идиотка, я согласилась. До сих пор не понимаю, как я могла обречь себя на новые неудачи. У меня не было никакого опыта с SAP, а новые обязанности только распыляли внимание — настолько, что все другие задачи я стала выполнять из рук вон плохо. Многозадачность — прекрасный способ подорвать прогресс, как многие из вас наверняка знают по собственному опыту.

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

И обновила резюме.

В 2006-м мы много времени уделили анализу и сравнению разных инструментов управления исходным кодом. Команда выбрала Team Foundation Server (TFS). В конце концов, мы принадлежали Microsoft, так что я установила, сконфигурировала и поддерживала TFS — и при этом изучала SAP, еженедельно интервьюировала кандидатов и помогала внедрять новый процесс сопровождения. Этот процесс позволил нам вносить корректировки каждые две недели, а не раз в полгода.

Разработчик пользовательского интерфейса (UI) по имени Дуэйн Джонсон увидел, насколько полезно поставлять небольшие, но частые корректировки, и стал отстаивать идею подобных регулярных улучшений. Дуэйн запустил постоянный процесс исправления багов UI, раз в два месяца. Появилась новая вещь, которую нужно было поддерживать, но она была стоящая. Эти инкрементальные и итеративные усовершенствования с систематической каденцией стали нашей аgile-альтернативой традиционной разработке каскадного типа. Agile-методы влились в процесс и заставили задуматься о более эффективном подходе к работе.

В апреле 2006-го в Corbis появился шотландец из Microsoft. Дэвид Андерсон посещал нас ежемесячно и учил применять теорию ограничений (ТО) в обмен на разрешение написать историю аgile-преобразования Corbis. ТО — способ найти самые важные лимитирующие факторы (ограничения), которые препятствуют достижению цели, а затем систематически совершенствовать их, пока они не перестанут быть лимитирующими. Мы воодушевленно читали его книгу Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results («Гибкое управление в разработке программного продукта: как применить теорию ограничений для бизнес-результатов») и планировали использовать разработку на основе функционала (FDD) — тип аgile-разработки с межфункциональными, коллективными и ограниченными во времени методами создания функций. Как пишет Даррен Дэвис в блоге «Тайная история Канбан», методы Дэвида «…исключали из процесса однозначные расчеты и опирались на конкретные данные, чтобы прогнозировать, когда вероятнее всего будет завершена работа над продуктом» [2]. Дэвид провел с нами обзоры операций и объяснил, насколько важно оценивать прогресс (или его отсутствие). Когда я поняла, что именно нужно анализировать, мой мир изменился. Нытье не помогает, а вот оценка cycle time (времени, требующегося для выполнения работы) и представление этих данных руководству очень даже эффективны. Я смогла повлиять на начальство и получить одобрение на наем новых сотрудников для нашей команды.

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

Как пишет Кейт Мерфи в статье «Нет времени подумать», «одни из основных жалоб современного общества — чрезмерная занятость, повышенные обязательства и перегруженность работой. Спросите людей на любом социальном мероприятии, как у них дела, и ответ будет неизменным: “Я так занят”, “С ума схожу от работы” или “Сил моих уже нет”. Никто уже не говорит “хорошо”» [3]. Каждый день я вижу подтверждение этому. Когда выдается спокойная минутка для размышлений — допустим, пока ждешь очередной встречи, — звонит телефон. Для амбициозных личностей, которые стремятся постоянно быть на связи, занятость может перерасти в зависимость. Но занятость не приравнивается к росту, или совершенствованию, или ценности. Часто она означает, что вы взяли на себя столько задач, что не можете ни одну из них выполнить качественно. Иногда прогулка в парке или минутка размышления — оптимальный способ жить сегодняшним днем. Какой ужас: инженер сидит без дела целых пятнадцать минут и просто думает?!

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

В сентябре 2008 года, после восьми лет работы в Corbis, меня, как и еще 41 сотрудника, сократили. Я решила попробовать что-то новое и устроилась в AT&T Mobile в команду управления разработкой. Но отказ от бережливой системы Канбан, которую я помогала создавать в Corbis, и возвращение к каскадному подходу (традиционный метод разработки продукта: нельзя приступить к работе, пока не будут выполнены все предыдущие этапы), когда прогнозы строятся на основе отчета по отработанным часам, стали для меня большим шагом назад. В июле 2010-го я уволилась.

В январе 2011-го Дэвид Андерсон предложил мне заняться разработкой и проведением нового курса для компании David J. Anderson & Associates под названием «Канбан для IT-операций». В то время Европа обгоняла США по популярности Канбан, так что в феврале мои исследования начались с Англии, Швеции и Германии. В марте мы провели первый пробный семинар в Бостоне, где я выступила на DevOpsDays Boston 2011 в Центре исследований и разработок Microsoft в Новой Англии.

Изначально я планировала написать рекомендации для участников семинара, чтобы помочь им спроектировать канбан-доски. Но эти рекомендации переросли в настоящее хранилище информации и здорово сэкономили мне время. Я стала записывать не только все, что узнавала о применении бережливого производства, Канбан и потока в собственной работе, но и выборочные формулы, теории и статистические данные экспертов. К примеру, что такое бережливое производство? Я предпочитаю определение Никласа Модига и Пэра Олстрема. В своей фантастической книге This Is Lean: Resolving the Efficiency Paradox («Это бережливое производство: как разрешить парадокс эффективности») они определили бережливое производство как «стратегию эффективности потока с ключевыми принципами “точно в срок” и визуального менеджмента» [4].

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

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

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

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

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

Что мы обсудим в этой книге:

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

Все примеры, которые я привожу на этих страницах, основаны на опыте — моем и тех, кто был свидетелем расхищения времени. Некоторые избегают публичного обсуждения преступлений, совершенных в их компаниях, так что для их удобства я изменила имена, чтобы защитить и невиновных, и виноватых. Мы также рассмотрим системные организационные проблемы, которые необходимо решить, чтобы достичь успеха. Как сказал Эдвардс Деминг, «плохая система всегда побеждает хорошего человека» [5].

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

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

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

ЧАСТЬ 1

ПЯТЬ РАСХИТИТЕЛЕЙ ВРЕМЕНИ

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

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

Кто же его крадет?

Перечислим пять расхитителей времени, которые мешают вам выполнить намеченные дела.

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

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

1.1

СЛИШКОМ БОЛЬШОЙ ОБЪЕМ НЕЗАВЕРШЕННЫХ ЗАДАЧ

На крыше пристройки, суббота, 9:00

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

Недавно он провел сейсмическое усиление нашего неукрепленного пустотелого основания дома. Я его помощница, то есть в мои обязанности входит: держать рулетку, следить за безопасностью и ассистировать при демонтаже и уборке (и это неполный список). Однажды, помогая разбирать стропила старой, рассыпающейся пристройки размером 7,5  11 м (я была на земле, а он на крыше), я между делом выразила пожелание построить оранжерею 5  7 м на самом удаленном от дома участке. С высоты 7,5 м, сидя на сгнившей крыше, любимый супруг бросил на меня скептический взгляд и сказал: «Дорогая, ты не заметила, что я сейчас занят?!»

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

Нам трудно говорить нет — и тому есть целый ряд объяснений. Например, если нам нравится человек, которому нужна помощь. Даже в офисе. Поскольку сетевой инженер Шон часто предупреждает меня, если на горизонте маячат важные изменения, я считаю, что он заботливый и хороший, и всегда готова помочь ему, если попросит. А вот Карлос! Карлос узнал об изменениях в порте две недели назад и говорит мне об этом только сейчас, в пять вечера пятницы?! Внутренний голос возмущается: «Не хочу я ему помогать».

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

1. Мы командные игроки: «Я не хочу подвести команду».
2. Мы боимся унижения: «Не хочу, чтобы меня критиковали или уволили». Легче сказать да, чем нет — особенно боссу. Отказать менеджеру — рискованный шаг в некоторых культурах.
   
3. Нам нравится все новое и интересное: это намного приятнее рутинной работы, сложной и скучной.
4. Мы не осознаем, насколько масштабна просьба, пока не приступим к работе: «Конечно, нет проблем. Я сделаю это за пару часов», но задача отнимает намного больше времени.
5. Нам нравится угождать: «Я соглашаюсь на большинство просьб, поскольку хочу, чтобы ко мне хорошо относились, восхищались мной, уважали».

Ванесса Бонс, социальный психолог и профессор менеджмента в Университете Уотерлу (Онтарио), говорит: «Все сводится к фундаментальной мотивации — поддерживать связь с другими людьми. Мы не любим отвергать. Не хотим, чтобы о нас плохо думали… поэтому на самом деле стараемся контролировать впечатление, которое складывается у них относительно нас» [1]. Но при этом редко осознаем, какое влияние оказываем на других, когда просим их что-то сделать, особенно если они переживают из-за явного или воображаемого распределения власти.

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

Почему слишком большой объем WIP так опасен

Слишком большой объем WIP вреден по нескольким причинам. Это может привести ко многим проблемам, включая отложенную ценность, рост расходов, снижение качества, конфликтующие приоритеты и раздражительность персонала. Когда мы приступаем к новой задаче, не завершив предыдущую, количество текущих проектов возрастает и на все дела уходит больше времени. Также увеличиваются финансовые потери, из-за того что на действия требуется больше времени и невозможно достаточно быстро реализовать их ценность. Мы называем это временем цикла. Время цикла (cycle time) — период, который единица рботы проводит в статусе незавершенных задач. Более того, бизнес-ценность, которую можно реализовать быстрее, откладывается из-за завышенного объема WIP. Это называется цена задержки (cost of delay). Она отражает ценность и срочность, оценивает влияние времени на ожидаемые результаты: например, чтобы клиенты купили наш продукт в этом месяце, а не в следующем.

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

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

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

Внутренние клиенты: сотрудники вашей организации, которые ставят перед вами задачи или пользуются результатами вашей работы. Команда разработчиков продукта — клиент инженера по защите информации, который выявляет уязвимые места продукта или платформы. Сотрудник — клиент менеджера, который высказывает мнение по поводу его работы. Внутренние клиенты влияют на WIP. К примеру, объем WIP службы техподдержки растет, если руководитель не может войти в свой компьютер; WIP маркетинговой команды увеличивается, когда IT-евангелист добавляет новую конференцию в свой график; WIP отдела управления платформой тоже накапливается, когда один из вице-президентов нанимает стороннего вендора, чтобы выстроить иную интеграцию.

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

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

Вы поймете, что WIP крадет ваше время, в следующих ситуациях.

Частое переключение контекста. Когда на компьютере переключается контекст, текущий процесс запоминается, чтобы впоследствии восстановить информацию. Так как компьютеры проводят сотни переключений контекста в секунду, легко поверить, что множество задач выполняется параллельно, хотя на самом деле центральный процессор (ЦП) просто чередует задачи на колоссальной скорости. Как пишет Тодд Уоттс в своем блоге «Решение проблемы разрушительных последствий переключения контекста с помощью DevOps», перегрузка, вызванная переключением контекста, когда приходится сохранять и восстанавливать информацию, негативно влияет на операционную систему (ОС) и работу приложений [2]. Поскольку переключение контекста иногда требует изменений огромных объемов данных, это может стать одной из самых дорогостоящих операций в ОС [3].

Как и компьютеры, люди начинают тормозить, переключаясь с одной задачи на другую. И их перегрузка намного серьезнее. Структуры данных со всеми регистрами информации и данными ОС, а также точки входа, с которых нужно продолжить процесс, невозможно автоматически переупорядочить в голове, как в ЦП. Переключение контекста в компьютере следует определенной программе.

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

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

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

Страдает качество. Качество ухудшается от чрезмерного объема WIP. Когда я работала в Corbis и взяла дополнительные обязанности по управлению новой SAP-командой, сама себя загнала в тупик. Помимо прежних должностных функций, пришлось изучить сложный мейнфрейм-продукт и при этом строить новую команду. Я уже 17 лет не работала с мейнфреймами — с первой работы после колледжа — и ничего не знала о SAP. Досконально разбираться в этом не стала, потому что на меня и так много всего навалилось. Теперь можно сказать, что результат был предсказуем: ни команда, ни SAP, ни мои другие обязанности не получили адекватного внимания. Это привело к тому, что команда осталась без грамотного руководителя, а я была постоянно раздражена.

Раздраженный персонал. Переключение контекста выводит из себя — редко хватает времени на качественную работу и нечасто выдается возможность усовершенствовать свои навыки. В книге Дэниела Пинка «Драйв»4 приводятся слова американского психолога Гарри Харлоу: «Радость стремления превосходит радость достижения. В конце концов, мастерство привлекает именно потому, что вечно ускользает» [4]. Мастерство ускользает потому, что не хватает времени заниматься чем-то достаточно долго и глубоко, прежде чем переключиться на другие задачи.

Вторжение в рабочий процесс противоречит глубине мысли. Шерлоку Холмсу думается лучше всего, когда он уходит в «чертоги разума» (в BBC-адаптации приключений знаменитого сыщика Конана Дойля) [5]. С помощью ментальной техники под названием «Метод локусов» (в переводе с латинского locus — местоположение) он отправляется в свой банк памяти — некое подобие ментальной карты, где хранятся воспоминания, — чтобы извлечь нужную информацию. Но ему нужны определенные условия — полное отсутствие отвлекающих факторов, поэтому он всегда сердится, если кто-то нарушает ход его раздумий. Имеет полное право: ужасно раздражает, когда тебя прерывают во время глубоких размышлений. Расхитители времени обожают глубокомыслие, потому что, как рассказывает Дэвид Рок в своей книге «Мозг: инструкция по применению. Как использовать свои возможности по максимуму и без перегрузок»5, может понадобиться не меньше 20 минут, чтобы вернуться к той же мысли после прерывания [6].

Кто-то спрашивает, есть ли у вас пять минут, и вы отвечаете «да». Вы соглашаетесь слишком часто, и приходится работать допоздна. Это раздражает и выматывает, а винить некого, кроме себя. Хотя я учу людей этим принципам, тоже попадаюсь в эту ловушку. В свою защиту можно сказать, что слово «да» приносит нам больше эндорфинов [7]. Однако непродуктивно это делать постоянно, да и вообще невозможно регулярно работать по вечерам и выходным. Принцип Канбан создает условия для того, чтобы спокойно закончить работу.

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

Количество карточек «В работе» показывает WIP на канбан-доске. Доска на рис. 2 отражает четыре задачи в работе. Ограничения объема WIP и делают Канбан вытягивающей системой. Когда задание с карточки выполнено, появляется «свободная мощность» и другая карточка вытягивается из бэклога в текущую работу. Работа продвигается по доске, опираясь на ограничение WIP и политику вытягивания. Если лимитирование WIP установить грамотно, система не допустит перегрузки. Ограничение WIP как раз и позволяет сказать: «Извините, но сейчас нет возможности увеличить объем работы». Воспринимайте сокращение WIP не как ограничение, а как освобождение. Подходящий объем текущих задач позволяет поддерживать адекватный объем работы.

Говоря товарищу: «Да, я сделаю это», вы приоритизируете его просьбу по сравнению со всеми остальными задачами в бэклоге. Дэн Витбрук, менеджер Tableau WebOps, называет это умением пролезть без очереди [8]. Этот расхититель, который крадет время у предыдущих задач, и есть одна из причин, по которым задачи из бэклога так долго висят на стадии обработки (а иногда так и не переходят на следующий этап).

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

1.2

НЕИЗВЕСТНЫЕ ЗАВИСИМОСТИ

Мой друг работает в компании с годовым доходом в $23 млрд, где продуктовая команда X развернула компонент, который сломал продукт команды Y. Теперь клиенты команды Y должны раскошелиться на $5 млн за новый продукт Y. И это помимо $10 млн, которые они только что заплатили за свежий компонент X, потому что прежний уже устарел и не поддерживался. Клиенты в этой ситуации использовали продукты обеих команд — X и Y. Продукту Y нужен продукт X, чтобы корректно функционировать. Единственная возможность удовлетворить потребности клиентов команды Y — купить новый компонент X.

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

Определим значение слова «зависимости». С моей точки зрения, можно говорить о трех типах зависимостей:

1. Архитектура (программного обеспечения и аппаратной части) — где изменения в одной области могут нарушить функционирование другой области (например, вывести ее из строя).
2. Экспертиза — когда нужна консультация или помощь человека с конкретными знаниями.
3. Действие — когда достичь цели невозможно, пока не будет выполнено определенное действие.

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

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

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

Схожая проблема связана с изменениями, которые выходят за рамки вашего контроля, — например, в лице сторонних вендоров. Крупные облачные провайдеры, такие как Amazon EC2, Microsoft Azure и Google Compute Engine, предоставляют соглашения о качестве своих услуг, которые гарантируют клиентам 99,95% времени работоспособности. То есть 22 минуты допустимого простоя в месяц. Когда ваш облачный провайдер недоступен, вы тоже недоступны, и расхититель по имени «Неизвестные зависимости» смеется над вами от души. Конечно, облачный провайдер — известная зависимость, но всегда ли вы знаете, когда его заклинит? Сколько времени команда тратит на поиск и решение проблем, прежде чем понять, что во всем виноват облачный провайдер, который напортачил в информационном центре со свечным графиком? Вы все равно в проигрыше, даже если это его вина, потому что вы ограничены соглашением. Возможно, вы получите компенсацию в виде дополнительного времени, но, если ошибка случится, как долго вы будете восстанавливать утерянные данные? Если подсчитать, какое количество часов команда тратит на урегулирование подобных ситуаций, то сколько времени украдено на самом деле?

Почему зависимости так опасны

На аgile-конференции 2015 года в Вашингтоне с крайне информативной речью по поводу зависимостей выступил Трой Магеннис. Он опирался на базовые принципы булевой логики (когда все параметры можно разделить на истину и ложь) и показал, что есть только одна комбинация действий, которая приносит результат четко в намеченный срок. Каждый раз, когда вы убираете одну зависимость, устраняется половина общей возможной задержки. Если для достижения результата нужно выполнить все пункты, каждая удаленная зависимость удваивает шансы на то, что вы достигнете результата вовремя [1].

Приведем пример. Если для достижения цели нужны два входных элемента, есть только один шанс из четырех, что вы получите результат вовремя. Один шанс из 2ⁿ — формула для расчета общего числа бинарных перестановок.

Да ладно, математика — это весело! Вы же поняли. В двоичной, бинарной, системе числа записываются с помощью двух символов — 0 и 1. Перестановка — это варианты сочетаний. Бинарная перестановка в таком случае — сочетание бинарных чисел. 2ⁿ — это 2 в степени n. Когда число входных элементов равно двум, n = 2, и мы имеем 2  2, то есть 4, или 2².

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

Если нужны три входных элемента, только одним способом из восьми можно выполнить работу вовремя.

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

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

То есть 16 возможных комбинаций относительно того, окажутся люди на месте вовремя или нет. Если составить таблицу, то в 15 вариантах хотя бы один человек всегда опаздывает и есть только один случай, когда все приезжают вовремя. Зависимости оказывают асимметричное воздействие. С четырьмя зависимостями вероятность того, что вас не посадят за столик, составляет не 25%, а 93% (15 из 16). Высока вероятность того, что кто-то все-таки опоздает. Лучше сразу откланяться и отправиться в бургерную.

Рисунок 3 помогает визуально представить расчеты по трем зависимостям, где вероятность получить столик вовремя составляет 12,5%. Если добавить еще одну зависимость, шанс получить столик всего один из 16, или 6,25%. Если, конечно, ваши гости не работают в IT-отделе — в таком случае они ни за что не уйдут с работы пораньше, чтобы приехать в ресторан вовремя.

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

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

Когда пиццерия доставляет больше двух единиц по одному адресу, в один конференц-зал, к примеру, будьте внимательны. По правилу двух пицц команда должна быть такой, чтобы ее можно было накормить двумя пиццами — примерно от пяти до семи человек, хотя все зависит от аппетита. Если три такие группы должны провести общую встречу, чтобы обсудить свои зависимости друг от друга, расходы на координацию будут высоки. От 15 до 21 человека, отстаивающих свою точку зрения, могут занять много времени. Когда на вашей памяти последний раз 15 человек приходили к соглашению? Если координационные требования высоки, люди недоступны, когда они вам нужны.

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

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

Наконец, вспомните общие характеристики слишком большого WIP: дорогостоящее переключение контекста и прерывание работы. Все, что отвлекает от дела, — одно из самых серьезных препятствий к качественному результату умственного труда, и это стоит примерно один триллион долларов в год [2].

1.3.

НЕЗАПЛАНИРОВАННАЯ РАБОТА

Деловой центр, США, утро вторника

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

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

Людей оторвали от важной работы. Заминка (незапланированное дело) застала всех врасплох. Это непредусмотренное последствие благих намерений управляющего негативно отразилось на первоочередной задаче, которая теперь отложена из-за помехи. Время, отнятое от работы над изначальным приоритетом, просто вычеркнуто. Это проблема незапланированной работы — она тормозит запланированную, усиливает нестабильность системы и в итоге делает ее менее предсказуемой.

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

Подчеркиваю: я не говорю, что все следует планировать. Это безответственно (возможно, даже неадекватно) — верить, что, намечая сложный проект, вы все сможете предусмотреть. Напротив, мы многого не знаем о том, чего еще не знаем. Иногда приходится резко менять направление, когда по мере работы над проблемами появляется новая информация. Основная ценность гибких методов — умение реагировать на изменения, следуя определенному сценарию. В жизни полно неопределенности. Изменения неизбежны. Это закон (а если точно, второй закон термодинамики).

Почему незапланированная работа так опасна

Незапланированная и срочная работа крадет время у дела, создающего ценность. По данным отчета State of DevOps Report 2016, результативные люди тратят на запланированную работу на 28% больше времени [1]. Незапланированная считается показателем качества (точнее, его отсутствия), потому что чем ее больше, тем меньше времени на создание ценности. Ситуации по типу «Свистать всех наверх!» сокращают производительность и увеличивают нестабильность.

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

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

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

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

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

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

1.4

КОНФЛИКТУЮЩИЕ ПРИОРИТЕТЫ

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

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

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

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

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

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

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

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

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

Почему конфликтующие приоритеты так опасны

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

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

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

Если все задачи одинаково приоритетны, ни одну нельзя назвать реально важной и каждая требует слишком много времени. Как говорит Росс Гарбер: «Многое может быть важным, но самое значимое — лишь одно» [1]. Возможно, наибольшая ценность в бизнесе — помочь коллеге закончить работу, вместо того чтобы приступать к новым делам.

Вы поймете, что конфликтующие приоритеты крадут ваше время, если слышите от людей примерно следующее:

• «Когда будет выполнена моя задача?»
• «Моя задача приоритетная!»
• «Если мою задачу не выполнить к такому-то сроку, то…»

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

1.5

ЗАБРОШЕННАЯ РАБОТА

Когда я работала в Corbis, мы использовали приложение по планированию ресурсов предприятия под названием JD Edwards (JDE). Это была старая, кастомизированная и довольно уязвимая версия. Как только JDE переводили в офлайн, чтобы сделать резервное копирование или восстановить базу данных, это влияло на функции выплаты и получения денег, а обновление от вендора сбивало настройки таблиц базы данных. Так что мы, как ни странно, делали то, что и многие IT-магазины, — ставили кратковременные цели и продолжали пользоваться десятилетней неподдерживаемой версией. Что могло случиться? Неавтоматизированный процесс билда и развертывания JDE регулярно переписывал конфигурационные файлы во время развертывания, из-за чего новые заказы просто исчезали. Все боялись трогать сервер JDE, и в результате его оставили в покое примерно лет на десять, пока не сменили на SAP. В некотором смысле устаревший софт похож на старый автомобиль, которому нужно регулярно менять масло и возить на станцию техобслуживания, чтобы он нормально функционировал. Старый софт сам по себе не проблема. А вот если он без сопровождения, если не стал частью автоматизированного билда, тестирования и развертывания, — вот это проблема.

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

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

Если бы меня попросили определить, какая работа самая заброшенная, я бы назвала ту, что связана с улучшением качества, включая отложенное сопровождение, баги, технический долг и код без прокрытия тестами (унаследованная система, по словам Майкла Фезерса7) [1]. Время и расходы часто решают все, когда люди торопятся выпроводить продукт в открытый мир («Обойдемся без тестов. Нам нужно отправить продукт. К этому вернемся позже»). Сегодняшняя корпоративная культура, нацеленная на то, чтобы люди были постоянно «заняты», просто абсурдна. Работа не получает должного внимания, когда сотрудники озабочены массой вопросов. Причем показателем продуктивности служит не сама занятость, а созданная ценность.

Две важные области, где процесс буксует, — это работа, ожидающая обратной связи, и работа, признанная важной, но не срочной. Третий фактор — то, что Дональд Рейнертсен8 называет зомби-проектами [2]. Это задачи с низкой ценностью, едва живые. Они бродят неприкаянно, ждут внимания и не получают ни капли любви. Они изголодались по деньгам, ресурсам и людям.

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

Некоторым людям нелегко убивать проекты — им жаль потраченного времени и денег. Чем больше мы вкладываем, тем сложнее бросить, даже когда более рациональное решение, продиктованное будущей ценностью, принесет больше пользы. Это называется ошибкой невозвратных затрат. В книге The Principles of Product Development Flow («Правила разработки продукта») Дональд Рейнертсен предлагает учитывать лишь инкрементальные инвестиции, необходимые для завершения проекта, и сравнивать их с экономической выгодой [3]. Выпалывать задачи с низкой ценностью из рабочего потока разумно в тех ситуациях, когда накапливается избыток дел с высокой ценностью. Иными словами, у вас есть полное право убивать зомби-проекты. Если они действительно нужны, легко восстанут из мертвых. То, что важно больше всего, не должно уступать место тому, что значимо меньше всего.

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

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

Почему заброшенная работа так опасна

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

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

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