Как разработать цифровой продукт, который будет приносить деньги
Мы работаем на рынке заказной разработки уже больше 12 лет. За это время мы аккумулировали знания о том, как клиенты подходят к тому или иному проекту. Ряд клиентов хорошо разобрались, как создаются ИТ-продукты, и как управлять этим процессом. Эти клиенты — лидеры рынка, они давно занимаются цифровизацией процессов и построили внутри отличные ИТ-компании. По нашим данным, таких клиентов немного, порядка 5%. Остальная же доля клиентов из среднего бизнеса сталкивается с проблемами при разработке ИТ-продуктов и управлении ИТ-командами.

Сегодня мы хотим поделиться с читателями советами, основанными на нашем опыте, — как избежать ошибок при планировании разработки, уберечь себя от слива бюджета и разочарования в подрядчиках при разработке цифровых продуктов, которые призваны приносить деньги.
В чем проблема рынка?
В 2020 году рынок IT начал активно подниматься: были инвестиции, покупались стартапы, расширялись команды, появлялись новые игроки. Пандемия кратно ускорила цифровизацию и решения принимались в экстренном режиме, у множества бизнесов, ориентированных на офлайн, поток клиентов упал до минимума, а с ним и продажи. Яркий пример — повсеместное появление мобильных приложений. Их разрабатывали все, просто чтобы они были. Повезло тем, у кого уже была готовая бизнес-модель в онлайне — они понимали, в какую сторону двигаться. Остальные столкнулись с масштабной перестройкой процессов, которую невозможно качественно выполнить в короткие сроки, а риски для бизнеса были максимально высоки, особенно в b2c сегменте.

После пандемии тренд на цифровизацию не потерял своей актуальности, но в 2022 году возникли новые ограничения и санкции, средние чеки упали, возникла необходимость экономить ресурсы. Пришло время оценивать имеющиеся на руках активы. Оказалось, что результатов или не появилось, или они были сомнительного качества, а огромные бюджеты были потрачены практически впустую. Возник ряд сложных вопросов. Что с этим всем делать? Как отчитаться о потраченных бюджетах? Стоит ли хоронить продукт, если не ясно, как его оптимизировать? Как сделать прибыльным то, что получилось?

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

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

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

Решение: выберите задачу, которую решит цифровой продукт. Этот выбор должен опираться на исследования вашего бизнеса и вписываться в общую стратегию. Если вы не знаете, как будете на нем зарабатывать, как вы его планируете развивать, и какое конкурентное преимущество оно дает, сделайте шаг назад и найдите ответы на эти вопросы.
Большая часть этой информации есть в сети, но тем, кто хочет глубже разобраться в вопросе, советуем программу «Digital shift» Московской школы менеджмента Сколково. Там вы научитесь управлять цифровой трансформацией бизнеса, узнаете как разработать экономически эффективную стратегию и сможете реализовать ее в своих проектах. Наш ТОП-менеджмент обучался на одном из первых потоков этой программы.
Ошибка 2: Отсутствие конкретной цели
Когда мы отталкиваемся от задач бизнеса, появляется конкретика. Она позволяет выделить ключевую функцию цифрового продукта и решить все технические вопросы, от выбора инструментов и стека до системы метрик и аналитики. Так рождается стратегия, которая становится опорой для ключевых решений, у проекта появляется логика.

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

Решение: отталкивайтесь от цели при выборе инструментов, главное — не цифровой продукт, а конкретная и измеримая польза для бизнеса. Разберитесь, как будете измерять прогресс движения к цели и видеть результаты в цифрах, например, количество новых клиентов, транзакций и обращений в минуту.
Ошибка 3: Нет понимания сколько проект может/должен стоить
Пока не сформулированы конкретные цели и польза для бизнеса, сумма не скажет ничего — вы просто не поймете, за что платите деньги. Допустим, вы услышали стоимость в 20 млн рублей. Если продукт не вписан в глобальную стратегию компании, если его стоимость не бьется с прогнозом прибыли, не ясно, какой результат даст эта сумма и оправданы ли такие вложения. Но когда вы понимаете, что вложенные 20 млн принесут вам 700 млн, это становится разумной инвестицией.

Когда компания с миллиардным оборотом собирается открывать новый канал продаж и вырастить в нем условно до 30% выручки, тогда нативная разработка мобильного приложения становится оправданным, как и обеспечение высоконагруженных сервисов, моделирования данных и детальная проработка UI/UX.

Решение: когда вы разобрались с целями и поняли, как работать с результатом, посчитайте выгоду, причем не только в деньгах. Учитывайте увеличение скоростей, повышение эффективности, вовлечение аудитории, удобство в использовании и так далее. Что-то из этого получится перевести в деньги и увидеть дополнительную выгоду. Сделайте это до того, как вы пойдете к подрядчику, и тогда разговор про деньги будет для вас значительно проще и понятнее.
Ошибка 4: Нет приоритетов
Допустим, глобальные цели понятны, бюджет выделен, осталось решить с чего начать. Здесь мы часто сталкиваемся с проблемой приоритетов. Многие двигаются интуитивно и делают ставку на то, что им кажется эффективным. Опираться на «кажется» без аналитики нет смысла — у такой ошибки может быть высокая цена, об этом ниже.

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

Вот, например, ошибка в выборе приоритетов и решение, основанное на «кажется».

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

Еще один пример. Другая компания согласилась на изменения в проекте, предложенные подрядчиками. Цель — ускорить дальнейшую разработку. Заказчик не оценил экономического эффекта, не задался вопросами «на сколько сократиться ТТМ? Сколько будет потрачено на реализацию изменений? Оправдан ли сейчас бюджет на эти изменения? А действительно ли текущий ТТМ для меня проблема, а не что-то другое, например, стабильность приложения? И решит ли это изменение правильную проблему для бизнеса, а не просто реализует хотелку команды?». Бюджет на эти работы составил 1,5млн рублей, но не принес пользы. Кроме потери времени и денег у менеджмента есть проблемы с отчетностью за потраченный впустую бюджет.

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

Эффективный цифровой продукт дает понятные результаты
А вот наш кейс с «Детским миром» — хороший пример. Клиент хотел не всё, везде и сразу, быстрее и дешевле, а четко понимал, какую потребность он закрывает в моменте, и как будет развивать свой цифровой актив далее.

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

Мы начали с разработки мобильного приложения с электронной системы лояльности в 2018 году, благодаря чему «Детский мир» отказался от пластиковых карточек и смс-оповещений и в долгосрочной перспективе в масштабах всего бизнеса это принесло абсолютно счетную экономию. После в 2019 году мы доработали приложение и сделали полноценный интернет-магазин с каталогом товаров и понятными метриками, что дало клиенту возможность развивать новый канал продаж в рамках общей e-comm стратегии компании. Приложение было готово прямо перед началом пандемии, выдержало все нагрузки и хлынувший в него поток пользователей.

Сейчас клиент развивает проект самостоятельно и ежегодно публикует отчеты. С 2021 года мобильное приложение — ключевой приоритет Группы компаний «Детский мир», оно обеспечивает до 80% всех онлайн-продаж.

Как эффективно разрабатывать цифровые сервисы?
Переходим к решениям, которым наши специалисты доверяют при разработке мобильных приложений.

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

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

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

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

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

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

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

Первый случай — большая редкость, если у вас такая команда есть, то вы счастливчики. И, скорее всего, эта статья не для вас.

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

Остается третий вариант: понять, что это за команда, и как ее сформировать.

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

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

  • Владелец продукта: смотрит метрики, создает роадмэп, приоритезирует бэклог, делает исследования аудитории, понимает УТП продукта и знает, как его правильно продавать потребителю. Работы тут будет много, особенно на старте, когда вы должны будете определить весь ваш продукт с нуля.

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

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

Коротко о главном

  • Сформируйте план цифровой трансформации компании и только потом вписывайте в него цифровой продукт.

  • Поставьте четкую цель — зачем продукт вашему бизнесу и какие задачи оно решит?

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

  • Знайте свой бизнес досконально, умейте смотреть метрики и аналитику, делать исследования.

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