Доминика Деграндис - Визуализируйте работу

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

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

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

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

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

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

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

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

Рис. 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-методы влились в процесс и заставили задуматься о более эффективном подходе к работе.