Чувствуй и реагируй. Как создавать продукты, нужные людям именно сейчас - [9]
Давайте рассмотрим некоторые преимущества такой работы.
Первое поколение потребительского программного обеспечения изменило методы нашей работы. Электронные таблицы и текстовые программы обеспечили резкий рост в личной производительности. При этом программное обеспечение первого поколения также было гибким. Это выражалось в том, что, когда организации пытались предоставлять цифровые услуги, зачастую результат был плачевным. Неэффективным. Сбивающим с толку. Сложным в использовании.
Представьте, что вы звоните, например, в колл-центр, чтобы узнать о своем телефонном счете. Как часто вы слышали, чтобы оператор колл-центра не справляется со своей компьютерной системой? В прошлом часто приходилось подстраивать бизнес-процессы и поведение клиентов под то, как работает программа, поскольку скорость, с которой мы могли изменить программу, была медленной. Как-то раз мы подслушали беседу группы руководителей производства пластмассы, сравнивающих контрольные показатели в процессе обслуживания клиентов. Они оценивали, сколько заказов каждая из компаний обрабатывала ежедневно. Средним значением, кажется, было тридцать заказов в день. Затем один из руководителей сказал: «Мы обрабатывали около тридцати заказов в день. Потом мы установили новую систему приема заказов. Теперь мы обрабатываем примерно два заказа в день».
Благодаря новой возможности изменять программу на постоянной основе, у компаний также появились новые возможности – предоставлять клиентам услуги, основанные на электронных способах. Программное обеспечение, которое может быть весьма гибким, теперь оправдывает свой «программный» потенциал, и эта гибкость предоставляет нам новую общую маневренность, когда дело касается предоставления услуг рынку. Если раньше мы порой внедряли недостаточно востребованные услуги, то теперь мы можем корректировать их до тех пор, пока они не станут эффективными. И если нам нужно изменить стратегию или процесс, мы можем внести коррективы в программное обеспечение, которое легко их поддержит.
Если вы следите за новостями, то наверняка слышали о крупных технологических проектах, которые терпят неудачу. Недавний заголовок на CIO.com был весьма прямолинейным: «Успешность корпоративного программного обеспечения остается расплывчатой»[7]. Аналитики The Standish Group, изучающие результативность технологических проектов, уже много лет проводят сравнительной анализ отрасли. Самое последнее исследование показывает, что частота неудач ИТ-компаний составляет около 70 %, что, конечно, лучше, чем 80 % в 1990-х годах, но все же.
В Массачусетсе, например, правительство штата потратило более девятнадцати лет и больше 75 млн долларов на систему, которая соединяла суды штата друг с другом. Создание этой системы должно было занять пять лет. Однако спустя девятнадцать лет многие обозреватели считают проект незавершенным и бесполезным. И это очень дорогостоящая неудача.
Методы «почувствовать и отреагировать» могут в этом случае помочь. Традиционные ИТ-проекты склонны придерживаться подхода «большого взрыва» (Метод тестирования «большой взрыв» – вид интеграционного тестирования, в котором элементы программного или аппаратного обеспечения, или они оба, собираются в компонент или в целую систему сразу, а не по этапам – перев.), при котором программное обеспечение не предоставляется пользователям до тех пор, пока оно не будет готово «под ключ». Это означает, что до самого завершения проекта трудно сказать, находится ли построение системы на правильном пути. В то же время agile-подход, лежащий в основе метода «почувствовать и отреагировать», позволяет решить эту проблему путем частого запуска рабочих вариантов системы с самых ранних дней проекта. Это уменьшает риск того, что команда разработчиков отклонится от курса, и позволяет наблюдать за тем, что делает команда, поскольку она постоянно делится результатами своего труда.
Эта прозрачность является ключевым фактором, поскольку подразумевает наличие обратной связи. Работает ли программное обеспечение? Отвечает ли оно потребностям пользователя? Отвечает ли оно целям, которые преследует компания? Зачем тогда ждать до конца проекта?
Представьте на мгновение, что вы являетесь исполнительным директором компании Amazon. Вы владеете огромной интернет-компанией, и, когда люди что-то у вас покупают, вы зарабатываете на этом деньги. Чтобы потребители могли что-нибудь у вас купить, они должны завершить процесс оформления заказа на вашем сайте. Таким образом, в ваших интересах оптимизировать процедуру оформления заказов так, чтобы люди могли успешно с этим справляться. Вы не хотите запутывать их. Не хотите отвлекать их. Вы хотите вести их по течению до тех пор, пока они не завершат транзакцию.
Один из приемов, который использует Amazon и похожие компании, направленный на очень быструю оптимизацию процесса, заключается в выпуске различных версий какой-либо части веб-сайта (например, процедуры оформления заказов) и направлении входящего трафика в разные версии для сравнения их производительности. Это научный метод в действии. Он получил название
