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

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

Поиск ценности в неопределенности

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

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

ПРЕДОСТАВЛЕНИЕ УСЛУГ

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

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

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

СНИЖЕНИЕ РИСКА

Если вы следите за новостями, то наверняка слышали о крупных технологических проектах, которые терпят неудачу. Недавний заголовок на CIO.com был весьма прямолинейным: «Успешность корпоративного программного обеспечения остается расплывчатой»[7]. Аналитики The Standish Group, изучающие результативность технологических проектов, уже много лет проводят сравнительной анализ отрасли. Самое последнее исследование показывает, что частота неудач ИТ-компаний составляет около 70 %, что, конечно, лучше, чем 80 % в 1990-х годах, но все же.

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