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

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.

ЧАСТЬ 2

КАК ВЫЯВИТЬ РАСХИЩЕНИЕ ВРЕМЕНИ, ЧТОБЫ ОПТИМИЗИРОВАТЬ РАБОЧИЙ ПРОЦЕСС

Наши школы и офисы недаром снабжены интерактивными досками. Мы поглощаем больше информации через зрительные рецепторы, чем через другие органы чувств, вместе взятые [1]. Из ста миллиардов нейронов мозга примерно 20% анализируют визуальную информацию [2]. Люди, у которых хорошо развито зрительно-пространственное восприятие, мыслят в основном образами, картинками. Исследование, проведенное психологом и основателем Института перспективных исследований Линдой Сильверман, показало, что две трети населения предпочитают зрительно-пространственное восприятие [3]. Левое полушарие — последовательное, аналитическое и ориентированное на время. Правое воспринимает целое, синтезирует и схватывает движения в пространстве. Если у людей с визуально-пространственным восприятием правое полушарие не активировано, их внимание будет низким, а обучение пройдет из рук вон плохо.

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

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

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

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

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

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

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

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

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

Итак, приступим.

2.1

КАК ВИЗУАЛИЗИРОВАТЬ РАБОТУ

Взгляните на рис. 4, иллюстрацию Филиппа Крачтена [1]. (Я перерисовала ее от руки и использовала другие цвета.) Это блестящий визуальный пример, демонстрирующий, чем видимая работа отличается от невидимой работы. Достаточно взглянуть на этот рисунок, и все сразу станет понятно. Считайте, что это визуальный язык, который показывает соотношение между незримой и видимой работой с точки зрения отрицательной и положительной ценности. Выделенная синим цветом «Архитектура» излучает положительную ценность. Если, конечно, это не древняя, кастомизированная, уязвимая версия JDE, в таком случае она попадет в желтый раздел технического долга.

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

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

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

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

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

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

Приведем пример одной из наших самоочевидных досок.

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

Как же применять канбан-доску?

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

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

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

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

1. Только один человек знает, как выполнить задачу (неизвестные зависимости). Если визуализировать работу, это стимулирует необходимое взаимообучение.
2. Работа влияет на другие команды (неизвестные зависимости). Как мы говорили в первой части, межкомандные зависимости могут принимать довольно масштабные размеры. Вы потратите всего пару минут на создание карточки для канбан-доски, зато выстроите грамотное взаимодействие групп.
3. Одному из сотрудников поручаются задачи, выполнение которых требует максимум 15 минут, то есть если работа этого человека не отслеживается, она невидима (слишком большой объем WIP). Если большие объемы работы остаются невидимыми, то очень легко нагрузить этого человека огромным количеством дополнительных задач, помимо стандартного объема его обязанностей.

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

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

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

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

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

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

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

Приведем несколько примеров трудностей команды:

Перечислим основные трудности, которые повторяются снова и снова на моих воркшопах по анализу требований (конфликтующие приоритеты во всей красе):

• Слишком часто отвлекают — не могу выполнить работу.
• Конфликтующие приоритеты — все задачи приоритетны.

Если это основные причины мучений вашей команды, то вы не одиноки.

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

Важно визуализировать трудности внутренних клиентов, и тому есть несколько причин.

1. Вам нужна поддержка внутренних клиентов, чтобы сократить WIP. Если игнорировать ограничение WIP, на вашу команду возложат больше требований, чем она в состоянии выполнить. Цикл перегруженности продолжится, и вы не сможете воспользоваться преимуществами потока. Недовольные люди реже участвуют в поиске решений. Добиться поддержки, чтобы ограничить объем WIP, намного проще, если вы облегчаете жизнь клиентам и в то же время своей команде.
2. Вы не центр вселенной. Нужно все воспринимать через системное мышление, чтобы оптимизировать рабочий процесс во всех командах и создать бизнес-ценность. Оптимизируя работу в интересах одной группы, вы можете навредить результативности компании. Организационное здоровье предполагает умение выявлять, чем недовольны наши клиенты.

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

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

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

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

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

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

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

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

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

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

• ID-карточки;
• заголовок;
• название;
• описание;
• ответственное лицо (лица);
• комментарии;
• пояснительные метки;
• иконки для особой видимости;
• приоритетность;
• подзадачи, или связанные поля карточек;
• отдельное поле для обозначения сроков.

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

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

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

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

А пока перейдем к параграфу 2.2 и устроим охоту на расхитителей времени.

2.2

ЗАСАДА НА ГЛАВАРЯ

Офис на заднем крыльце, 8:35

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

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

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

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

Вы поймете, что у вас слишком большой объем WIP, если:

• переключение контекста стало частым явлением;
• вы приступаете к новым задачам до того, как выполните старые, — другими словами, говорите: «Да, я сделаю это», хотя еще не закончили целую гору другой работы;
• работе не уделяется внимание и она «стареет».

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

Но надежда есть! Если отслеживать объем текущих задач, удастся не отвлекаться и не позволить слишком большому объему WIP поглощать ваши вечера и выходные.

Есть множество способов отслеживать WIP. Приведем пример (см. рис. 10), который поможет выявить WIP и разделить его на три основных категории в зависимости от источника задачи.

• «Серебряные пули» — задачи, которые нужно выполнить сразу; обычно запросы поступают от начальства. Для них выделена особая категория, поскольку они срочны и приоритетны (по реальным или надуманным причинам).
• Бизнес-задачи, включая функции продукта, контент и дизайн, то есть работа IT, которую продвигает, контролирует и активно отслеживает «бизнес».
• Командная работа — задачи IT, инициированные группами, например устранение багов, технического долга, а также безопасность, обновление платформ и поддержка.

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

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

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

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

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

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

Простая доска с тремя дорожками (как на рис. 10) вводит ограничения WIP по каждой дорожке.

Итак, «серебряные пули» исходят напрямую от начальства. Эту дорожку иногда называют «вице-президентской зоной». Директора по информационным технологиям и вице-президенты часто не осознают, какие заминки создают, прося о том, что выходит за рамки рабочего процесса. Если четко обозначить на доске все «серебряные пули», это поможет показать, какие затраты связаны с этими задачами. Вся работа, включая невидимый объем WIP, сопряжена с определенными расходами, так что нужно сделать ее видимой! «Серебряные пули» могут быть достаточно важными, чтобы потратить на них время и силы, и в таких случаях мы говорим: «Мы знаем, что эта задача важна, и решим ее, но только в порядке очереди». Последовательное выполнение — один из вариантов ограничения WIP.

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

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

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

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

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

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

Если хотите прогнозировать работу, ограничьте объем WIP до реальных возможностей вашей команды. А как их определить? Хороший вопрос. Они не должны составлять 90–100%. Подробнее об этом поговорим в третьей части.

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

Ограничение WIP дает еще одно преимущество: вы будете реже отвлекаться. У меня есть крошечная дровяная печь, которая выручает нас, когда электричество отключается. Зимой, чтобы экономить энергию, я пользовалась печкой каждый день независимо от того, было электричество или нет. К сожалению, необходимость следить за огнем каждые 30–45 минут — слишком большой минус и очень отвлекает от работы. Вот если бы огонь поддерживался 90–120 минут, меня бы это устроило, потому что это достаточно длительное время, чтобы я доделала сложную задачу.

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

2.3

ВЫЯВИТЬ ЗАВИСИМОСТИ

Сан-Франциско, 2012 год

Крупная организация запускает третью аgile-трансформацию. Приезжает группа консультантов. Новые аgile-команды делят на подгруппы по пять-девять человек. Они поглощают неимоверное количество пиццы. (Помните задачку с пиццей из параграфа 1.2?) Они слышали, какого успеха добился Google с помощью небольших команд, которым хватает всего двух пицц, поэтому крупная организация решила, что в ее случае этот метод тоже сработает. Такая разветвленность повлияла и на другие группы. Они назвали это «выездной проблемой», потому что для решения любой задачи приходилось обращаться к коллегам. В таком режиме работали примерно 92% команд. И многие сотрудники «выезжали» часто.

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

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

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

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

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

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

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

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

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

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

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

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

Обратите внимание на последнюю колонку схемы на рис. 12 — «АРХ»; имеется в виду обзор архитектуры. Его цель — получить рекомендации и поддержку эксперта для эффективного функционирования организации. Это не должно быть формальным одобрением.

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

Спроектируйте свои доски так, чтобы неизвестные зависимости даже носа не показывали (рис. 14).

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

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

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

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

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

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

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

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

Напротив, организация и управление вокруг продукта создают условия, чтобы одна и та же группа сотрудников с необходимыми экспертными знаниями постоянно участвовала в процессе. Разработчики функций продукта не уходят; они остаются до конца — чтобы внести изменения и обеспечить поддержку. Проектные группы оцениваются по статистическим параметрам (например, тестировщики — по количеству багов в программе), в то время как команды продукта рассматриваются по итоговой бизнес-ценности. Старший технический директор Pivotal Корнелия Дэвис отметила в обсуждении на форуме DOES 2017: «Архитектура неотъемлемо связана с тем, как мы работаем. Предпочтительная архитектура представляет собой слабосвязанные компоненты, отдельные микросервисы, разработанные конкретными группами — автономными командами продукта, а не проектными» [1].

2.4

ИДЕАЛЬНОЕ ПРЕСТУПЛЕНИЕ — НЕЗАПЛАНИРОВАННАЯ РАБОТА

Лос-Анджелес, 2013 год

Я спросила у двух IT-проект-менеджеров, ответственных за поддержку команды из 41 инженера, что мешает им выполнить работу. Они ответили не задумываясь: нас постоянно отвлекают. Другие группы и владельцы продуктов буквально бомбардируют их вопросами о статусе проекта. И мы провели эксперимент (он длился одну неделю), чтобы отследить все эти помехи и заминки. Каждый раз, когда кто-то отвлекал их, они записывали это на желтом стикере и прикрепляли к верхней строке мобильной доски на колесах размером 1,2 на 1,8 м (см. рис. 17).

Желтые стикеры заполонили верхнюю дорожку. Зеленые листочки, которые обозначали внутреннее совершенствование команды, и разноцветные, которые показывали другую работу, воздействующую на проект-менеджеров, расположились на средней. А стикеры на нижней дорожке отражали различные проекты, которыми они занимались. В конце недели мы насчитали 92 желтых стикера. Девяносто два! Большинство — вопросы по статусу проекта. Внутренние клиенты проект-менеджеров, владельцы продукта, ничего не знали о статусе и количестве проектов.

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

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

Розовые точки мгновенно визуализируют, насколько отвлекающие моменты влияют на другие стратегии, и играют функцию символов, заменяющих нецензурные выражения (#8%*@!), то есть довольно увлекательный способ отразить помехи.

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

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

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

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

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

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

Знать соотношение незапланированной и запланированной работы полезно, когда вы намечаете производственные мощности. Почему? Потому что вы поймете, как ограничить WIP, чтобы распределить важную, неожиданную и срочную работы. Если каждую неделю у вас по 25–50% не внесенных в график дел, выделите под это 25–50% текущих задач. Вот как это сделать.

1. Рассчитайте соотношение запланированной и незапланированной работы, разделив количество неожиданных задач, выполненных в прошлом месяце, на общий объем всех дел в прошлом месяце. К примеру, если вы решили 100 задач и 40 из них были неожиданными, получается 40% незапланированной работы.
2. Продолжим пример: 40% из всех текущих задач следует выделить под незапланированную работу и вопросы с низким приоритетом. Задачи с низким приоритетом — важные, но не первоочередные. Такая стратегия дает возможность справиться с незапланированными делами и/или отложить задачи с низким приоритетом до «лучших времен». Это также помогает выполнить важную работу, которая иначе превратится в критическую (например, когда сервер достигнет максимальной мощности) в ближайшем будущем и выйдет из-под контроля. В любом случае она будет выполнена.
3. Каждый месяц пересматривайте соотношение запланированной и незапланированной работы, чтобы проверить тенденцию — вверх или вниз, и распределяйте WIP соответственно.

Обратите внимание: мы говорим об объеме незавершенных задач, а не о времени. Распределение времени — совершенно другое дело. Иногда менеджеры говорят сотрудникам: «Уделите 50% вашего времени этому и 25% времени тому». Но как это сделать? Вам крупно повезло, если вы можете отдать полдня (допустим, четыре часа) одной задаче и четверть дня (допустим, два часа) другой. Так как большая часть дня обычно уходит на рабочие встречи, просмотр почты и переключение контекста между задачами, два часа непрерывного занятия (причем любого!) — роскошь.

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

Как бороться с тем, что отвлекает от работы

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

• Вратарь. Один из членов команды берет на себя все отвлекающие моменты. Роль переходящая и служит двойной цели — не отрывать других от работы и обучить членов команды.
• Часы приема. Как учителя в школе, запланируйте определенное количество времени, к примеру пару часов в неделю, и сообщите, когда вы доступны. Часы приема дают коллегам возможность обращаться с просьбами и вопросами, когда это удобно именно вам.
• Часы, когда отвлекать нельзя. Противоположность часам приема. Повесьте на дверь или на другое видное место табличку «Вернусь через час», чтобы сообщить людям, когда вы будете доступны. Я выделяю для себя время с 6 до 8 утра каждый день. В эти часы я пишу и занимаюсь йогой. Однажды босс попросил меня прийти на рабочую встречу в 6:30. Я отказалась. Мне было жутко неудобно, но, чтобы выполнить важную задачу, нужно ревностно охранять свое время. Кстати, отказав боссу, я ввела прецедент. Теперь уже никто не ждет, что я появлюсь на встречах, которые проходят в 6:30.
  
• Pomodoro. Метод тайм-менеджмента, когда с помощью таймера работа разбивается на равные интервалы с небольшими перерывами [1]. Поставьте таймер на 25 минут и работайте над своей задачей, пока он не зазвенит. Как только раздастся сигнал, делайте пятиминутный перерыв. После четырех заходов позвольте себе перерыв подольше (20–30 минут). Pomodoro дает возможность сосредоточиться. Я использовала именно этот метод, чтобы дописать книгу.

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

В 1960-е годы каждое утро в 10:15 тележка с кофе катилась по коридорам HP. Все инженеры пили кофе и периодически обсуждали животрепещущие темы. Это было идеальное время для спонтанного рождения гениальных идей. Многие проблемы решались именно у тележки с кофе. В 1970-е было решено сократить расходы и тележку с кофе заменили кофейником в мини-кухне и самообслуживанием. Инженеры, конечно, прерывались на кофе, но уже не одновременно. Больше не было общих кофе-пауз, не было спонтанного мозгового штурма. Исчезли незапланированные совместные дискуссии — и все ради экономии. Кое-кто решил, что это начало конца золотых дней исследований и разработок HP [2].

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