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

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

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

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

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

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

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

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

Рис. 1. Билды требуют не так уж много времени

Я отметила, что архитектурная катастрофа – система с нераспознаваемой структурой – делала развертывание и поддержку сред проблематичными. Ручные