Если вы следите за новостями, то наверняка слышали о крупных технологических проектах, которые терпят неудачу. Недавний заголовок на CIO.com был весьма прямолинейным: «Успешность корпоративного программного обеспечения остается расплывчатой»[7]. Аналитики The Standish Group, изучающие результативность технологических проектов, уже много лет проводят сравнительной анализ отрасли. Самое последнее исследование показывает, что частота неудач ИТ-компаний составляет около 70 %, что, конечно, лучше, чем 80 % в 1990-х годах, но все же.
В Массачусетсе, например, правительство штата потратило более девятнадцати лет и больше 75 млн долларов на систему, которая соединяла суды штата друг с другом. Создание этой системы должно было занять пять лет. Однако спустя девятнадцать лет многие обозреватели считают проект незавершенным и бесполезным. И это очень дорогостоящая неудача.
Методы «почувствовать и отреагировать» могут в этом случае помочь. Традиционные ИТ-проекты склонны придерживаться подхода «большого взрыва» (Метод тестирования «большой взрыв» – вид интеграционного тестирования, в котором элементы программного или аппаратного обеспечения, или они оба, собираются в компонент или в целую систему сразу, а не по этапам – перев.), при котором программное обеспечение не предоставляется пользователям до тех пор, пока оно не будет готово «под ключ». Это означает, что до самого завершения проекта трудно сказать, находится ли построение системы на правильном пути. В то же время agile-подход, лежащий в основе метода «почувствовать и отреагировать», позволяет решить эту проблему путем частого запуска рабочих вариантов системы с самых ранних дней проекта. Это уменьшает риск того, что команда разработчиков отклонится от курса, и позволяет наблюдать за тем, что делает команда, поскольку она постоянно делится результатами своего труда.
Эта прозрачность является ключевым фактором, поскольку подразумевает наличие обратной связи. Работает ли программное обеспечение? Отвечает ли оно потребностям пользователя? Отвечает ли оно целям, которые преследует компания? Зачем тогда ждать до конца проекта?
Представьте на мгновение, что вы являетесь исполнительным директором компании Amazon. Вы владеете огромной интернет-компанией, и, когда люди что-то у вас покупают, вы зарабатываете на этом деньги. Чтобы потребители могли что-нибудь у вас купить, они должны завершить процесс оформления заказа на вашем сайте. Таким образом, в ваших интересах оптимизировать процедуру оформления заказов так, чтобы люди могли успешно с этим справляться. Вы не хотите запутывать их. Не хотите отвлекать их. Вы хотите вести их по течению до тех пор, пока они не завершат транзакцию.
Один из приемов, который использует Amazon и похожие компании, направленный на очень быструю оптимизацию процесса, заключается в выпуске различных версий какой-либо части веб-сайта (например, процедуры оформления заказов) и направлении входящего трафика в разные версии для сравнения их производительности. Это научный метод в действии. Он получил название A/B-тестирование и стал стандартным приемом в онлайн-мире. Например, этот метод был использован командой Facebook для тестирования своих решений относительно проблемы жалоб на фотографии. Такие компании, как Amazon, ежедневно осуществляют множество тестирований для оптимизации своих потоков. И хотя может показаться, что эти процессы оптимизации не очень ценны, на самом деле все наоборот. В одном хорошо известном случае крупный онлайн-ритейлер запустил годовой объем продаж в 300 млн долларов, изменив текст для одной из кнопок в процедуре оформления заказа[8].
В 2012 году команда предвыборной кампании Обамы использовала этот метод почти для всех опций, что они запускали на своем веб-сайте. В одном случае команда пыталась оптимизировать страницу пожертвований. Члены команды испробовали множество вариантов, прежде чем решили попробовать добавить цитату президента на страницу. По сравнению со страницей без цитаты, эта страница принесла увеличение пожертвований на 11,6 %. Эта цифра может показаться не особо большой, но, учитывая сам объем, это простое изменение за все время кампании увеличило сумму пожертвований на миллионы долларов[9].
Такой подход к процессу оптимизации обусловлен двумя важными факторами. Во-первых, вам нужна техническая инфраструктура, чтобы осуществить эти тестирования, собрать результаты и быстро отправить их нужным адресатам. Более важным является второй фактор: отношение руководства. Менеджеры должны быть в состоянии признать, что у них нет всех ответов, и они должны быть готовы в правильных обстоятельствах представить свои идеи для тестирования на рынке. Этот новый менталитет менеджмента является лишь первым элементом из числа важных управленческих инноваций, которые необходимо внедрить, если компании хотят добиться успеха в цифровую эпоху.
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
8
Jared M. Spool, “The $300 Million Button,” User Interface Engineering, January 14, 2009, https://articles.uie.com/three_hund_million_button/.