Но эти придирки не должны отвлекать нас от основного направления этой книги. Эти исследования и их тщательный анализ дают одно из лучших объяснений методов, которые могут значительно продвинуть вперед большинство ИТ-компаний. Каждый руководитель ИТ-группы должен внимательно изучить эти методы и работать над их использованием для улучшения своей деятельности. Любой, кто работает с ИТ-группой – либо внутри компании, либо из компании, которая занимается доставками ИТ (такой как наша), – должен искать возможности применить эти практики на месте и выработать устойчивую программу непрерывного совершенствования, чтобы развиваться вместе с ними. Форсгрен, Хамбл и Ким нарисовали картину того, как эффективно ИТ выглядит в 2017 году, и практикующие специалисты в сфере ИТ должны использовать ее как карту, чтобы присоединиться к высокоэффективным лидерам.

Мой путь начался летом 2011 года. Я работала в Nordstrom, и мы приняли стратегическое решение сосредоточиться на цифровом секторе как двигателе роста. К этому моменту наша ИТ-компания прошла через оптимизацию расходов. В своей презентации на DevOps Enterprise Summit 2014 я поделилась информацией о том, что для меня одним из моментов прозрения был переход к оптимизации скорости. Я сделала много ошибок на этом пути, и хотела бы я тогда иметь доступ к этой книге и изложенной в ней информации. Я наступила на все классические грабли. Например, в попытке взять и внедрить Agile сверху вниз, думая, что он подходит всем, не фокусируясь на измерениях (или правильных параметрах измерений). При этом лидерское поведение не меняется и рассматривает трансформацию как программу вместо создания обучающейся организации (чего никогда не делалось).

На протяжении всего пути мы фокусировались на командных структурах, основанных на результатах: мы знали наше время цикла (понимали нашу карту ценностей), ограничивали «радиус взрыва» (начинали с 1–2 команд вместо того, чтобы пытаться «вскипятить океан»), использовали данные для управления действиями и решениями и признавали, что работа – это работа (цель – отсутствие недоработок и отставаний по функционалу, техническому обеспечению и операционной работе; вместо этого иметь только одно отставание, потому что NFRs (Nonfunctional Requirements – нефункциональные требования. – Прим. ред.) тоже являются функциями, а сокращение технических недоработок повышает стабильность продукта). Ничто из этого не было достигнуто в одночасье, а процесс потребовал множества экспериментов и корректировок.

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

Несмотря на то, что путь будет нелегким, я могу сказать, что он определенно того стоит, и вы не только увидите результаты, но и ваша команда станет счастливее. Например, когда мы начали измерять eNPS