Метод для проверки новых идей: используем для роста эффективности бизнеса

Современную цифровую экономику отличает высокий уровень конкуренции. Чтобы развиваться, компаниям нужны новые идеи, которые будут эффективно работать и принесут прибыль. Лучший способ найти такую прорывную идею — проверить как можно больше гипотез за как можно меньшее время с минимальными затратами. Как это сделать, используя метод проверки концепции (Proof of Concept), рассказывает Станислав Мешков, CEO Umbrella IT.

Бизнесу необходимо быстро двигаться вперед — гораздо быстрее, чем 5—10 лет назад. Потребности пользователей меняются стремительно. Скорость реакции на такие изменения определяет не только успех конкретного продукта, но и позицию компании на рынке в целом.

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

Анализ опыта крупных игроков рынка

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

Вариантов поиска вдохновения существует множество:

• досконально изучить рынок и рассмотреть под микроскопом предложения конкурентов;

• заказать или провести собственное исследование трендов в своей индустрии;

• вспомнить идеи, которые были спрятаны в долгий ящик в период предыдущего всплеска вашей исследовательской активности;

• провести хакатон с участием представителей стартапов, которые выгодно отличаются от сотрудников внутри компании свободой мышления, отсутствием страхов и предрассудков относительно собственных идей.

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

В таком случае универсальным решением становится проверка концепции (PoC). Она позволяет свести на нет неопределенность, которая существует на раннем этапе реализации идеи, и успешно запустить процесс разработки.

Первое упоминание о данном методе проверки концепции относят еще к 1967 г. В 1969 г. в Комитете по науке и космонавтике США проверка концепции была определена как «фаза разработки, на которой создается экспериментальное оборудование для демонстрации осуществимости технологии». С того момента понятие PoC уже прочно вошло в обиход в самых различных отраслях, от инженерии до фармацевтики.

Например, в кинематографии, чтобы понять, можно ли посредством технологии хромакей (от англ. chromakey — технология совмещения двух и более изображений или кадров в одной композиции) передать исходный художественный замысел, для фильма «300 спартанцев» сначала были отсняты отдельные эпизоды, а только затем полноценный фильм.

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

Поставщик ИТ-услуг, IBA Group, проводил проверку концепции для международного банка¹. Задача состояла в том, чтобы подтвердить, что технологии RPA и AI пригодны для решения задач по выводу и сравнению данных в разных форматах, которые выполнялись вручную работниками банка. Проект охватывал большую часть типовых бизнес-процессов, таких как классификация входящих данных, автоматизация выгрузки данных, сравнение входящих данных с данными, имеющимися в системе. Работа над проектом длилась три месяца. В результате было определено, что степень автоматизации процесса выгрузки данных составляет 73% при средней точности 94%. Снижение усилий сотрудников по сравнению с ручной работой составило 63% на транзакцию. При этом для данных в формате Excel точность и степень автоматизации составили 100%. На основании положительных результатов проверки проект был запущен в работу.

В рамках создания программных продуктов PoC означает проверку практической возможности создания того или иного продукта. Результатом применения метода PoC становится демонстрация доказательства такой возможности (или невозможности): отчет, математический расчет, простой прототип. Результат не будет полноценным продуктом, как, например, в случае с со­зданием MVP (минимального жизнеспособного продукта), но будет подтверждать, что техническая реализация возможна и затраты на эту реализацию целесообразны.

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

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

Сегодня метод проверки концепции становится особенно актуальным на фоне того, как быстро развиваются новые технологии.

Согласно прогнозам IDC² расходы на когнитивные системы и системы искусственного интеллекта в 2022 г. достигнут 77,6 млрд долл. США, а среднегодовой темп роста в период с 2017 по 2022 г. составит 37,3%. Это означает, что будет расти количество пилотных проектов, а следовательно, и востребованность PoC как инструмента проверки выполнимости инновационных идей.

При этом речь совсем не обязательно идет о продуктах, создаваемых с нуля. PoC эффективно работает, когда у компании есть собственные ИТ-продукты, которые уже используются, но не обеспечивают постоянное увеличение ауди­тории, а оценки, которые приложения компании получают в магазинах, не устраивают бизнес. Возникает потребность внедрить эффективные точечные изменения, однако перед этим необходимо быстро проверить, возможно ли такое изменение и даст ли оно результат. Иначе высок риск того, что бизнес просто «сольет» бюджет на решение, внедрение которого не принесет желаемого результата.

Основное противоречие, с ­которым сегодня приходится сталкиваться бизнесу: есть желание сделать инновационный ИТ-проект, но хочется быть уверенным, что это осуществимо или даст реальный ­результат.

Устраняем противоречие с помощью метода PoC

Umbrella IT предлагает бизнесу возможность проверить идею с помощью PoC. В основе концепции PoC лежит принцип разумной достаточности, то есть фактически исключаются затраты ресурсов на дизайн, создание большого набора функций или сложных технических решений. Все усилия команды сосредотачиваются на достижении такого минимального состояния продукта, при котором можно проверить жизнеспособность и целесо­образность. При этом бюджет на проверку фиксируется в самом начале пути и не ­меняется.

Стоимость услуги составляет 450 тыс. руб. За фиксированную цену клиент избавляется от головных болей из-за согласований дополнительных бюджетов в условиях нарастающей спешки. Кроме того, известные заранее цена и временные рамки позволяют проверять сразу несколько идей и ускорять экспансию в новые рыночные ниши. В соглашении с клиентом прописывается фиксированный срок — для PoC он составляет максимум один месяц.

Это в корне отличается от распространенного подхода в разработке — «оценить затраты, когда все спланируем». Мы предлагаем изменить подход к созданию инновационных продуктов. Разрабатывать их не последовательно, как в случае с обычными ИТ-проектами, а начинать с разработки и тестирования наиболее сложного решения или функции.

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

Отправляясь на WebSummit в Португалии, мы взяли с собой огромное количество визиток. Носить их с собой в больших количествах было не очень удобно, и в какой-то момент во время конференции мы поняли, что впереди еще полдня, а визитки уже закончились. В итоге приходилось обмениваться контактами, используя все подручные средства. И в основном, конечно, смартфон.

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

И вот приложение готово, загружено в AppStore, и на следую­щую конференцию мы отправились, чтобы проверить его на практике. В результате выяснилось, что не все функции востребованы в равной степени. По-настоящему полезной оказалась функция создания личной сети бизнес-контактов, которую мы и начали дорабатывать позже по результатам первого «полевого тестирования».

Опыт оказался полезным, так как позволил нам прочувствовать необходимость и преимущества PoC. Если бы при реализации проекта приложения мы начали с проверки концепции, то смогли бы раньше выделить главную функцию и отсеять лишнее, а значит, сэко­номили бы время и деньги.

Мы выработали следующий алгоритм проверки концепции для своих внутренних продуктов и для проектов клиентов.

Изучаем предложенную идею

После подписания договора мы приглашаем клиента, чтобы обсудить его идею. С этой установочной встречи начинается этап подготовки к разработке, так называемый предеве­лопмент (от англ. predevelopment), который включает в себя подготовительные работы и не превышает двух недель. Непосредственная реализация проекта ограничена сроком в один месяц, в течение которого необходимо проверить концепцию.

В связи с такими временными ограничениями в обсуждении участвуют только основные стейкхолдеры, то есть те, кто максимально заинтересован в воплощении идеи в жизнь. Как правило, в больших компаниях эти задачи ложатся на плечи директоров по инновациям (CIO), владельцев продуктов (РО), директоров по маркетингу (СМО), а в стартапах и небольших компаниях — непосредственно на основателей.

На начальном этапе важно четко зафиксировать основную потребность клиента: какой именно функционал нужен. Мы тщательно документируем все функции и берем паузу. Это время также относится к двухнедельному подготовительному этапу. Основная задача — найти самое важное в идее и проверить, можно ли это реа­лизовать техническими средствами.

Компания Pendo³, на платформе которой работает 850 клиентов, таких как Salesforce, Coupa, Gainsight, BMC и Sprinklr, провела исследование, и результаты показали, что около 80% функций в типичном облачном программном продукте используются пользователями очень редко или не используются вообще. А это означает, что около 29,5 млрд долл. США тратятся напрасно.

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

По сути, результаты PoC  призваны ответить на два первоначальных вопроса:

• возможно ли техническими средствами реализовать саму суть идеи;

• целесообразно ли эту идею реализовывать именно в таком формате.

Согласовываем ожидания

Ситуация «все известно заранее» в традиционной разработке приложений граничит с фантастикой. В случае реализации подхода PoC за месяц — это обычная практика.

Для создания PoC мы фиксируем срок и бюджет. Временные и финансовые ограничения являются дополнительным стимулом для всех участвующих сторон.

Для клиента такой вариант предпочтительней, потому что вместо того, чтобы тратить деньги и время на шесть месяцев (в среднем) разработки полноценного продукта, он получит ответ на основные вопросы уже через месяц, заплатив за него подъемную сумму.

Для команды разработчиков, которая в зависимости от характера идеи состоит из менеджера проекта, разработчика, дизайнера, аналитика и QA-специалиста, такой формат служит дополнительной мотивацией. У них нет возможности расслабляться, так как уже через месяц необходимо продемонстрировать результат проверки, который будет давать ответ на вопрос о жизнеспособности идеи.

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

Например, одно из мобильных приложений, которое мы создали, начиналось именно с PoC, и будущее проекта зависело от результата этой проверки. Идея заключалась в том, что пользователь приложения социальной сети мог находить вокруг людей, у которых тоже есть такое приложение и с которыми он еще не знаком. Приложение как ­узконаправленный радар должно было определять, какие пользователи попадают в выбранный сектор. Основная техническая сложность проекта заключалась в том, что приложение должно было очень точно определять направление сектора (куда направлен телефон) и точно позиционировать пользователей.

Так как это была основная привлекающая пользователей функция приложения, то от возможности (или невозможности) ее воплощения зависело, будет проект приложения запущен в работу или нет.

Мы с клиентом проработали и определили главный критерий успеха PoC. Результатом проверки в этом случае стал прототип приложения, который доказал, что техническая реализация возможна.

Ищем подтверждение

После согласования с клиентом сценария использования предполагаемого продукта и ожидаемых результатов формируется список дальнейших шагов, которые нужно выполнить. Шаги группируются по промежуточным этапам разработки, так называемым майлстоунам (от англ. milestones) — отрезкам времени, в которые должен быть выполнен определенный объем задач. Обычно каждый такой период длится одну-две недели.

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

Работа над проверкой концепции представляет собой своего рода дерево решений.

Например, в случае с PoC по социальной сети с точным геопозиционированием проверка состояла из следующих шагов-гипотез:

• проверяем, какую информацию мы должны собирать для приложения;

• проверяем, какие сторонние приложения (карты, сервисы логирования данных) нам нужны для трекинга позиций пользователей;

• определяем, с какой точностью мы можем отобразить координаты всех пользователей приложения в радиусе 5—10 м (по MAC-адресам) в статичном режиме, то есть когда пользователи стоят/сидят;

• определяем, с какой точностью мы можем отобразить координаты пользователей приложения в радиусе 5—10 м в процессе движения внутри помещения/на открытом воздухе и т.д.

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

Когда все промежуточные этапы в рамках создания PoC завершены (в среднем таких промежуточных периодов разработки насчитывается от двух до четырех), результат передается стейкхолдерам для принятия дальнейшего решения о судьбе потенциального ­продукта.

Стоит отметить, что востребованность идеи на уровне самого бизнеса зачастую становится понятна уже в процессе проверки. Речь в этом случае идет о том, нужно ли это самому бизнесу: не рынку и не ­клиенту, а стоит ли идея того, чтобы продолжать в нее вкладываться.

Последующие действия в отношении проверенной концепции будут зависеть от характера проекта: это может быть создание MVP (минимального жизнеспособного продукта), custdev (тестирование идеи или прототипа на реальных пользователях), начало непосредственной разработки ­продукта.

В случае с описанным выше мобильным приложением по результатам проверки был создан прототип, который доказал возможность технической реализации идеи. Приложение было успешно доработано до конечного продукта и загружено в AppStore.

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

Результат для бизнеса

Наша практика показывает, что использование проверки концепции дает бизнесу следую­щие преимущества:

• за счет того, что нежизнеспособные и нецелесообразные идеи отсеиваются на раннем этапе, повышается процент успешно запущенных и эффективных инновационных ­проектов;

• экономятся время и ресурсы, выделяемые на инновации, которые можно перераспределить на реализацию проверенных инновационных идей;

• подход PoC  за один месяц позволяет «обмануть» привычную схему запуска новых продуктов, поставить процесс на поток в прямом смысле слова. Количество проектов внутри компании увеличивается как минимум в два раза;

• создаются условия определенности, которая помогает начать проект: заранее определены относительно небольшой срок и сумма. Согласование старта проекта происходит в три раза быстрее.

к сведению

RPA (Robotic Process Automation) — технология, позволяющая автоматизировать бизнес-процессы за счет имитации действий пользователя посредством программного обеспечения.

AI (Artificial Intelligence) — технология, позволяющая создавать интеллектуальные машины, выполняющие операции, которые обычно связывают с человеческим мышлением.

¹ https://ibagroupit.com/cases/rpa-ai-proof-of-concept-implementation-at-internationalbank/.

² https://www.idc.com/getdoc.jsp?containerId=prUS44291818.

³ https://www.idc.com/getdoc.jsp?containerId=prUS44291818.