Визуализируйте работу - страница 4

Босс спросил меня: «Не возьмешь ли ты на себя управление командой 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-разработки с межфункциональными, коллективными и ограниченными во времени методами создания функций. Как пишет Даррен Дэвис в блоге «Тайная история Канбан», методы Дэвида «…исключали из процесса однозначные расчеты и опирались на конкретные данные, чтобы прогнозировать, когда вероятнее всего будет завершена работа над продуктом»[3]. Дэвид провел с нами обзоры операций и объяснил, насколько важно оценивать прогресс (или его отсутствие). Когда я поняла, что именно нужно анализировать, мой мир изменился. Нытье не помогает, а вот оценка cycle time (времени, требующегося для выполнения работы) и представление этих данных руководству очень даже эффективны. Я смогла повлиять на начальство и получить одобрение на наем новых сотрудников для нашей команды.

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