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

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

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

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

Методы «почувствовать и отреагировать» могут в этом случае помочь. Традиционные ИТ-проекты склонны придерживаться подхода «большого взрыва» (Метод тестирования «большой взрыв» – вид интеграционного тестирования, в котором элементы программного или аппаратного обеспечения, или они оба, собираются в компонент или в целую систему сразу, а не по этапам – перев.), при котором программное обеспечение не предоставляется пользователям до тех пор, пока оно не будет готово «под ключ». Это означает, что до самого завершения проекта трудно сказать, находится ли построение системы на правильном пути. В то же время agile-подход, лежащий в основе метода «почувствовать и отреагировать», позволяет решить эту проблему путем частого запуска рабочих вариантов системы с самых ранних дней проекта. Это уменьшает риск того, что команда разработчиков отклонится от курса, и позволяет наблюдать за тем, что делает команда, поскольку она постоянно делится результатами своего труда.

Эта прозрачность является ключевым фактором, поскольку подразумевает наличие обратной связи. Работает ли программное обеспечение? Отвечает ли оно потребностям пользователя? Отвечает ли оно целям, которые преследует компания? Зачем тогда ждать до конца проекта?

ОПТИМИЗАЦИЯ ЦЕННОСТИ

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

Один из приемов, который использует Amazon и похожие компании, направленный на очень быструю оптимизацию процесса, заключается в выпуске различных версий какой-либо части веб-сайта (например, процедуры оформления заказов) и направлении входящего трафика в разные версии для сравнения их производительности. Это научный метод в действии. Он получил название A/B-тестирование и стал стандартным приемом в онлайн-мире. Например, этот метод был использован командой Facebook для тестирования своих решений относительно проблемы жалоб на фотографии. Такие компании, как Amazon, ежедневно осуществляют множество тестирований для оптимизации своих потоков. И хотя может показаться, что эти процессы оптимизации не очень ценны, на самом деле все наоборот. В одном хорошо известном случае крупный онлайн-ритейлер запустил годовой объем продаж в 300 млн долларов, изменив текст для одной из кнопок в процедуре оформления заказа[8].

В 2012 году команда предвыборной кампании Обамы использовала этот метод почти для всех опций, что они запускали на своем веб-сайте. В одном случае команда пыталась оптимизировать страницу пожертвований. Члены команды испробовали множество вариантов, прежде чем решили попробовать добавить цитату президента на страницу. По сравнению со страницей без цитаты, эта страница принесла увеличение пожертвований на 11,6 %. Эта цифра может показаться не особо большой, но, учитывая сам объем, это простое изменение за все время кампании увеличило сумму пожертвований на миллионы долларов[9].

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

РАСПОЗНАВАНИЕ ВОЗНИКАЮЩЕЙ ЦЕННОСТИ

Чтобы понять, что мы называем «возникающей ценностью», необходимо оглянуться назад и оценить характер товаров и услуг, появившихся благодаря технологиям.

В ранние дни компьютерной революции, когда на рынке появлялись первые персональные компьютеры, люди говорили об «убойном приложении» – приложении, которое было бы настолько полезным и убедительным, что стимулировало бы масштабную покупку этих машин. Можно утверждать, что программы для обработки электронных таблиц (сначала VisiCalc, а затем Lotus 1-2-3) были движущей силой большей части первых покупок ПК. Для других убойным приложением являлся текстовый редактор. Но в любом случае, использование этих программ было схожим: человек, сидя за компьютером, взаимодействует с программным обеспечением и генерирует большую производительность с помощью более эффективного инструмента.

Теперь подумайте об убойном приложении нашей эпохи. На секунду представьте себе компьютер без подключения к интернету. Или, что еще хуже, представьте себе смартфон, который постоянно находится в режиме полета. Без подключения наши устройства практически бесполезны – они теряют большую часть своей ценности. Это происходит потому, что все чаще наши гаджеты подключают нас к услугам и, что еще важнее, к другим людям в интернете. Мы используем Twitter и Facebook, чтобы делиться новостями и информацией. Для покупок мы используем Amazon. Мы используем Uber, чтобы вызвать такси, а Google Maps и Waze – для навигации и получения информации о дорожной обстановке, собранной другими пользователями системы, в режиме реального времени. Наши приложения больше не являются автономными программами, работающими на наших персональных компьютерах.

И дело не только в том, что пользователи занимаются чем-то новым, что связано с этими технологиями. Компании все чаще предоставляют свои основные услуги с помощью связанных технологий. К примеру, Simple Bank – это банк, который доступен только через программу, несмотря на то, что там есть реальные люди, работающие за кадром. Компания Weight Watchers (компания, разработавшая методики для снижения веса – ред.) пополняет свои традиционные каналы, позволяя клиентам связаться с тренером через приложение в смартфоне.

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