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

Для большинства людей за пределами технологической индустрии «программные операции» являются невидимой и неясной функцией. Однако за операциями стоят люди, которые создают и поддерживают операционную среду, в которой работают программные сервисы и продукты. Они настраивают серверы, сети и базы данных, устанавливают и поддерживают программное обеспечение, которое обеспечивает работоспособность всей инфраструктуры, справляется с перебоями, и (что наиболее важно для обсуждения) задействуют новые версии для программного обеспечения, создаваемого командами по разработке продуктов.

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

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

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

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

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

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

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

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

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

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