Чувствуй и реагируй. Как создавать продукты, нужные людям именно сейчас - Джош Сейден Страница 42

То же самое произошло и с операционными рабочими потоками. В условиях менее частых выпусков программного обеспечения команды довольствовались медленными неавтоматизированными процессами. Запуск нового программного обеспечения можно было запланировать на вечер пятницы, чтобы избежать любого риска для систем, использующихся в рабочее время. Неважно, что этот запуск в пятницу вечером мог затянуться на выходные: если они закончат к утру понедельника, это все еще будет считаться достаточно быстрым.

Как только выпуски стали более частыми, операции по запуску перестали за ними не поспевать. Операционные команды также начали автоматизировать свои процессы, менять рабочий поток и оптимизировать сотрудничество с разработчиками. Эти новые подходы – суть идеологии DevOps, и они привели к феноменальным изменениям. Компании когда-то были рады выпускать новое программное обеспечение несколько раз в год, но сейчас мы видим компании, которые приняли подходы DevOps и, выпускают новое программное обеспечение несколько раз в день.

ПОНИМАНИЕ ТОГО, ЧТО ПОТОК ЯВЛЯЕТСЯ НЕ (ПРОСТО) ТЕХНИЧЕСКОЙ ПРОБЛЕМОЙ

Команда из AutoTrader UK знала все о DevOps. Компанию возглавлял генеральный директор Тревор Мэзер, который ранее руководил одной из ведущих инженерно-консалтинговых фирм, использовавшей agile-подход.

Технический директор AutoTrader Крис Келли пояснил: «[Наша цель] – представить платформу, которая способствует постоянному внедрению функций по видам продуктов, а также предоставляет инструменты и механизмы, позволяющие командам измерять и контролировать свои приложения, в процессе производства»[73]. Иначе говоря, AutoTrader UK нацелена предоставить своим командам возможность как можно скорее передавать свои идеи в руки клиентов, а затем отслеживать производительность этих функций, чтобы понять, насколько они успешны.

«КУЛЬТУРА ОБСЛУЖИВАНИЯ» НЕ СОЗДАЕТ ДВУСТОРОННИЙ РАЗГОВОР. ЭТО УСТАРЕВШИЙ И РИСКОВАННЫЙ СПОСОБ РАБОТЫ В МИРЕ, УПРАВЛЯЕМОМ ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ.

Однако вследствие более частых выпусков программного обеспечения организация столкнулась с другими проблемами. Компания являлась, по определению операционного директора Натана Коу, «цифровой в плане доходов, а не по своей природе». И действительно, на протяжении тридцати шести лет организация функционировала в качестве печатного издательства. Сложилась определенная культура. Структура команд, механизмы поощрения и повседневные рабочие потоки были сформированы в рамках печатного бизнеса. Как отметил Коу, руководители осознавали, что компания нуждается «в первую очередь, в изменении культуры. А затем уже в изменении бизнеса и, наконец, технологий».

Управление непрерывным всем

В Главе 6 мы говорили о важности небольших многофункциональных и самостоятельных команд. Однако в любой организации, независимо от ее размера, ни одна из команд по-настоящему не является самостоятельной. Команды полагаются на руководителей в формировании своих задач, предоставлении финансирования и установлении границ, в пределах которых они могут работать. Они опираются на маркетинг и продажи для определенных видов взаимодействий с рынком. Короче говоря, существует много точек координирования, и не все функции могут быть делегированы команде. Поэтому, несмотря на то, что «самостоятельность» является важным ориентиром для команд, они редко когда являются самостоятельными на 100 %, а еще реже они становятся экономически рентабельными.

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

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

КОНТРОЛЬ ОПЫТА КЛИЕНТОВ: НАБЛЮДАЙ И ЧУВСТВУЙ

Распространенный страх, который испытывают менеджеры относительно перехода к непрерывному производству, имеет отношение к клиентскому опыту. Менеджеры опасаются, что постоянные изменения разрушительно скажутся на опыте клиентов, которые доверяют привычной продукции. Как вы получите преимущества от потока, постоянно и хаотично меняющего опыт клиентов?

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

Такие компании, как GE и Westpac, обладают общедоступными системами проектирования, что позволяет командам по разработке быстро продвигаться вперед, не переписывая внешний код и не заботясь о таких вещах, как цвет кнопки. Эти системы проектирования по существу являются полноценными платформами, созданными для облегчения повседневной работы группы управления. Используя данные платформы, команды могут использовать предварительно утвержденные элементы: им не нужно обсуждать незначительные решения о том, как должен выглядеть продукт. Это позволяет командам сосредоточиться на инновационных, уникальных и сложных составляющих системы, а также двигаться в том темпе, который способствует содержательному разговору с рынком. Один из менеджеров отметил, что система проектирования «это то, что позволяет нам так быстро продвигаться вперед. Мы никогда не увязнем в разговорах о том, что уже было решено».

КОНТРОЛЬ ОПЫТА КЛИЕНТОВ: ФУНКЦИИ И ЭКСПЕРИМЕНТЫ

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

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