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