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

Этот переход может показаться незначительным изменением процесса, однако сложно переоценить, насколько значителен сдвиг парадигмы, который он собой представляет. Почему? Все потому, что производственный процесс (копирование программного обеспечения на дискеты, CD- или DVD-диски) больше не является частью процесса распространения программного обеспечения. И исключив этот шаг, мы создали принципиально новую модель.

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

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

Рассмотрим один потрясающий факт: Amazon выпускает очередное обновление программного обеспечения каждые 11,6 секунд [6] Jon Jenkins, “Velocity Culture,” 2011, https://www.youtube.com/watch?v=dxk8b9rSKOo. . Возможно, это происходит благодаря набору приемов, называемому непрерывным развертыванием . По сути, непрерывное развертывание позволяет разработчикам программного обеспечения поддерживать системы в состоянии постоянной готовности и вносить в них дополнительные изменения. Amazon занимает лидирующие позиции в этой сфере, но для других крупных компаний ежедневное обновление программного обеспечения стало обычным делом, а во многих компаниях это происходит по несколько раз за день.

Что это означает в плане управления? Мы считаем, что не будет преувеличением сказать, что это меняет всё. В цифровом мире больше нет никакого «промышленного производства». В мире с зафиксированными стадиями производственного процесса цена изменений высока: всякий раз, когда вы вносите изменения в продукт, вам нужно снова проходить через весь процесс производства, а это влечет за собой расходы. Таким образом, есть смысл ограничивать частоту изменений в производимых товарах. Однако, освобожденные от производственной стадии процесса, мы устраняем этот сдерживающий фактор. Ограничения на изменения существуют в других частях системы – например, сколько изменений может «переварить» пользователь или сколько изменений мы можем внести без ущерба качеству или увеличения других затрат. Но как демонстрируют лидеры отрасли, такие как Amazon, эти ограничения гораздо менее жесткие, чем мы могли бы представить. На практике теперь можно представлять новые функции, возможности и услуги клиентам и собственным сотрудникам на постоянной основе и в удивительно быстром темпе.

Почему Amazon так часто выпускает обновления? Не просто потому, что он это может. Нет, выпуск программного обеспечения зачастую является единственным индикатором подхода «почувствовать и отреагировать». Такой подход к работе подразумевает оперативные циклы чувствования того, что нужно рынку, и быстрое реагирование на эти потребности. Как вы убедились на примере с Facebook, этот подход позволяет командам понять всю сложность продукта, уменьшить неопределенность и найти новые конструктивные решения.

Давайте рассмотрим некоторые преимущества такой работы.

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

Представьте, что вы звоните, например, в колл-центр, чтобы узнать о своем телефонном счете. Как часто вы слышали, чтобы оператор колл-центра не справляется со своей компьютерной системой? В прошлом часто приходилось подстраивать бизнес-процессы и поведение клиентов под то, как работает программа, поскольку скорость, с которой мы могли изменить программу, была медленной. Как-то раз мы подслушали беседу группы руководителей производства пластмассы, сравнивающих контрольные показатели в процессе обслуживания клиентов. Они оценивали, сколько заказов каждая из компаний обрабатывала ежедневно. Средним значением, кажется, было тридцать заказов в день. Затем один из руководителей сказал: «Мы обрабатывали около тридцати заказов в день. Потом мы установили новую систему приема заказов. Теперь мы обрабатываем примерно два заказа в день».

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

Если вы следите за новостями, то наверняка слышали о крупных технологических проектах, которые терпят неудачу. Недавний заголовок на CIO.com был весьма прямолинейным: «Успешность корпоративного программного обеспечения остается расплывчатой» [7] Chris Doig, “Enterprise Software Project Success Remains Elusive,” CIO.com, October 23, 2015, http://www.cio.com/article/2996716/enterprise- software/ why- is- success- with-enterprise-software-projects-soelusive.html . Аналитики The Standish Group, изучающие результативность технологических проектов, уже много лет проводят сравнительной анализ отрасли. Самое последнее исследование показывает, что частота неудач ИТ-компаний составляет около 70 %, что, конечно, лучше, чем 80 % в 1990-х годах, но все же.

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