Зачем студиям развивать свои проекты? Опыт “сапожника с сапогами” в мобильной разработке
Недавно, заполняя информацию о нашей студии в личном кабинете одного из рейтингов, мы столкнулись с тем, что собственные проекты не учитываются при ранжировании. Площадка объяснила, что ее целевой аудиторией являются бизнес-заказчики, и поэтому портфолио должно быть только из клиентских кейсов. Нам показалось это не совсем справедливым и логичным решением, потому и родился этот лонгрид.
«Но вы же приходите в бизнес, чтобы работать для клиента!»
Парадокс в том, что именно это и мотивирует разрабатывать и развивать свой продукт. В этой модели мы сами для себя становимся заказчиком. Мы вкладываем ресурсы— материальные, временные, моральные, в конце концов. Это несёт за собой риски и потери — всегда несёт, не бывает так, чтобы идея моментально взлетела и показала ROI в 300%. Зачем?
Невозможно делать что-то хорошо, если не тренироваться. Чтобы IT-студии развиваться, нашей команде нужно расти и прокачивать навыки: клиентский сервис, ux, разработку, саппорт. Нужно давать дизайнерам и разработчиком поле для экспериментов с новым видением, разными технологиями, чтобы делать качественные клиентские кейсы. Тренироваться на проектах клиентов — дорого для обеих сторон и не играет на руку профессиональной репутации.
Чтобы классно делать мобильные приложения... нужно их делать. Но под этим имеется в виду не просто умение писать отличный код, создавать нужно рабочий, жизнеспособный и востребованный продукт. Мы не будем скрывать, что изначально целью развития наших проектов было получение прибыли. Это ведь, в конечном итоге, основная задача бизнеса. А после того, как поэкспериментировали, поняли, что полученную внутри экспертизу можно передавать заказчику. С одной стороны, мы помогаем себе, проверяя гипотезы, идём дальше, учимся на ошибках, с другой — помогаем клиенту найти лучшее решение. При разработке внутреннего проекта у каждого участника команды есть возможность побывать в роли заказчика и посмотреть на вопросы, проблемы и вызовы с другого ракурса. Подобный подход позволяет иначе реагировать на непростые ситуации при коммерческой разработке и эффективнее добиваться целей. И здесь уже любой член команды задается вопросом: «А зачем мы это делаем? Зачем здесь делать такую кнопку? С чего вы взяли, что люди будут так поступать?»
Это не выбор стратегии позиционирования, а следствие понимания, что вряд ли хороший продукт можно получить как-то по-другому.
Окей, а можно конкретнее, как ваши проекты помогают бизнесу?
Сценариев, когда клиент уверен в чем-либо, а мы уже попробовали это и знаем, что это не работает, — на самом деле достаточно много. Часто мы стараемся обозначить острые моменты, узкие места проекта или бизнес-модели, побудить клиента задуматься о них. Но при этом у нас нет права принимать решение за него.
На базе своих стартапов нам удалось проверить различные гипотезы, и полученные инсайты уже передаём клиентам.
Например, заказчик часто хочет, чтобы в регистрации был номер телефона. На первый взгляд, логично — маркетинг будет их собирать, это ценная информация для использования, можно возвращать и вовлекать аудиторию. На практике же, сколько бы мы ни пытались работать с номерами телефонов, они никак не монетизируются. Затраты не окупаются: sms-ки дорогие, рассылки дорогие, конверсия примерно никакая, в отличие от представления заказчика.
Или возьмем этап публикации: казалось бы, такой максимально нетрудозатратный элемент — скринкаст, размещенный на странице приложения в сторах, поднимает конверсию в установку приложения на 20-30%. Скринкаст — это своего рода часть онбординга. На своих проектах мы как раз отладили грамотный процесс онбординга новых пользователей: как сделать так, чтобы он понял функции продукта, сразу ими воспользовался и быстро дошел до ключевых возможностей. А скринкаст в дополнение к этому ключевые возможности заранее демонстрирует. Зарубежные коллеги, занимающиеся маркетингом приложений, говорят о том, что рост конверсии в установку при размещении скринкаста может достигать даже 40%. Или про развитие. Есть такой важный момент, как виральность продукта. Сюда входит, например, расшаривание. Почти каждый архитектор идеи хочет, чтобы пользователи имели возможность что-то расшарить. Но на практике это не работает. И мы это уже знаем. Люди не пользуются этим функционалом. Они идут по проверенному пути, когда, если хочется чем-то поделиться, человек делает скриншот и делится. Или копирует и делится. Но привязываться к какому-то социальному сервису, авторизовываться для этого — это плюс один дополнительный шаг, который многие делать не хотят. Кроме того, в виральность часто вкладывают понимание бесплатного трафика. То есть сделали мы очень крутой продукт, который людям нравится, они хотят о нем рассказывать в своих социальных сетях, и мы за это, собственно, ничего не платим. Но не все задумываются на старте, как получить первых пользователей, которые будут продукт рекомендовать другим. Клиенты часто думают, что если опубликовать приложение в сторы, сразу начнутся установки (и мы не шутим и не иронизируем, далеко не каждый понимает, как это работает, и именно поэтому нужны подрядчики, продающие свою экспертизу). Установки, конечно, не начинаются, потому что требуется реклама. Аудитория не приходит сама по себе, нужно считать, сколько стоит каждая установка. Так, средняя стоимость одного пользователя, загрузившего себе приложение на iOS — $3,6, на Android — $1.22 (по данным платформы Liftoff). Само собой, следует учитывать, что эта статистика показывает цифры глобального масштаба, в то время как они достаточно сильно разнятся по странам, и самая высокая стоимость привлечения относится, например, к США и другим странам Северной Америки ($5,28, а для сравнения в Азиатско-Тихоокеанском регионе, куда входит Россия — $0,93, по данным Liftoff) — не только ввиду объема рынка, но и из-за высокой стоимости медиатрафика вообще. Да, при наличии такой доступной статистики несложно посчитать хотя бы примерный, грубый бюджет на маркетинг, который необходимо закладывать для того, чтобы познакомить аудиторию с новым продуктом (в надежде, что часть трафика впоследствии будет виральным) — но мы регулярно сталкиваемся с тем, что при продуктовой проработке клиент это не учитывает вообще. С течением времени, получив много опыта (как позитивного, так и негативного) с продвижением своих стартапов мы создали в студии отдельное подразделение c экспертизой в мобильном маркетинге. Это, конечно, больше история про продукт в целом — аналитика, UX, развитие, продвижение. Но, прежде всего, мы разработчики, и без технической составляющей даже идеальная бизнес-модель работать не будет. Что хочет клиент? (Кроме случаев, когда он не знает, чего хочет) Классный код, ноль багов, быстродействие на уровне световых скоростей, и чтобы при нагрузке в n тысяч юзеров ничего не упало. И, само собой, за минимальные сроки с минимальным бюджетом. Утопическая ситуация, в которой нужно лавировать и предлагать какие-то жизнеспособные решения. Копилку таких решений нам пополнил, например, наш собственный проект Beeo. Нам хотелось оптимизировать затраты ресурсов при разработке сервера, и здесь мы потестили low code решение. Серверной части у проекта не было в привычном виде, разработка велась с использованием Airtable, который заменил нам базу данных и серверную часть. Тест удался — оптимизация сэкономила достаточно много времени, которое можно конвертировать в деньги. Этот опыт стал полезен в первую очередь для заказчиков, которые приходили к нам за созданием MVP продуктов. Для проработки гипотез в собственных проектах мы нередко используем сервисы для быстрой сборки приложений — Bubble или Glideapps. К их помощи прибегаем и для того, чтобы в кратчайшие сроки получить прототипы сервисов, которые мы планируем разрабатывать и развивать. Проще говоря, когда клиент обращается с запросом на реализацию максимально быстро и максимально дешево, то, чтобы проверить, насколько его гипотеза жива, мы предлагаем собрать ему low код решение. Если же ему такой вариант не подходит, то мы прорабатываем и оптимизацию бюджета и сроков для нативной или кроссплатформенной разработки с применением базовых решений. На этапах развития своих стартапов, когда пользовательская аудитория наших проектов становилась свыше 10, 20, потом 50 тысяч человек активной недельной аудитории, мы научились быстро масштабироваться и выстраивать системы из нескольких серверов. Это, с одной стороны, распределяет нагрузку, с другой — позволяет экономить. А в одном из внутренних проектов компании мы начали работать с сервисами Intercom, которые сейчас очень популярны для интеграции чата и обратной связи. Мы его обкатали у себя внутри, а потом стали применять в коммерческой разработке. Это еще один пример, когда мы проводим эксперименты за свой счет, и впоследствии ведем оценку проекта, закладывая минимальные риски. Опробовав на своих проектах вебвью компоненты, мы стали применять их и в заказной разработке. Ведь разработка нового функционала — это практически всегда долго и дорого. Считаем, сколько рабочих дней потратят на это дизайнеры и разработчики, потом переводим в деньги, закладываем сюда еще то, что не всегда может всё пойти по плану, и то, что по итогу функционал может вообще не зайти и не использоваться. Потом еще проходит время, чтобы все пользователи обновились до версии с новыми фичами, поиспользовали их в течение какого-то периода, чтобы накопилась информация об их поведении. А потом снова нужны правки, и начинается новый цикл. Вебвью компоненты в разы экономят время и деньги, давая возможность править в реалтайм, так как в рамках приложения открывается веб-страница. А если гипотеза подтверждается, то с заказчиком уже определяем целесообразность полноценной разработки новой фичи. И напоследок еще такой важный для всех момент — фидбэк пользователей. Именно от них мы узнаем, чего в приложении не хватает или что реализовано неудобно. Конструктивной обратной связи добиться довольно тяжело. Как правило, комментарии в сторах падают в две крайности — гипервосторженные или резко негативные. Поэтому для своих и впоследствии клиентских приложений мы используем дополнительные системы для сбора обратной связи. Так, в уже реализованном заказном проекте при определенных условиях Fabula пользователю предлагалось пройти небольшой опрос, и, если он соглашался, то открывался typeform — по сути продвинутые гугл-формы. Там были сформулированы вопросы — либо с выбором варианта ответа, либо с кратким ответом, выстроена логика перехода к вопросу, то есть при определенном ответе далее задавался определенный вопрос. А вопросы можно было менять в реал-тайм режиме (еще один пример реализации вебвью-компонента), собирая конструктивный фидбэк, направляемый на дальнейшее развитие продукта. Мы не будем тут кривить душой и говорить, что все тотально в восторге от нашего опыта разработки своих проектов. Обычно крен идёт в позитивную сторону. Например, говорят: я видел Gymmy, пользовался, устанавливал, классный дизайн, хочу так же. Или говорят: я увидел у вас вот такой продукт, идея крутая, я вижу, что у вас есть представление о рынке, проконсультируйте меня. Ссылаются на обзорный Telegram-канал, который мы ведем, со словами, что знают о нашей насмотренности индустрии и хотят взять от нас какую-то экспертизу. И это тоже важный момент для любого разработчика цифровых продуктов — смотреть, что делают другие, как работают законодатели трендов в диджитале, и желательно не только соотечественники. Вместе с тем, важно понимать, что не в каждом пресейле играют роль свои стартапы. Прикладные сложные решения требуют конкретных навыков, не все из которых можно продемонстрировать собственными проектами. Мы не делаем упор на них, когда с запросом приходит условный авиаперевозчик или туроператор. Ему закономерно следует показывать свою экспертизу, например, в работе с высоконагруженными серверами под сотни тысяч MAU или в разворачивании хадупов, работе с базами данными, с тем, как они синхронизируются. Безусловно, здесь над опытом своих стартапов будет превалировать техническая экспертиза наших специалистов и накопленные кейсы уже из коммерческой разработки. А вот для клиентов из малого и среднего бизнеса оказывается очень востребованным то, что мы, по сути своей, уже побывали на их месте в роли заказчика, проверяющего гипотезы и прокладывающего путь новому продукту. Это отмечают в своих отзывах наши клиенты, которые приходят за продуктовой экспертизой, например, автор проекта Posignal: «Вы умеете не только слушать, но и слышать и понимать всё то, что клиент не всегда может чётко сформулировать из-за отсутствия каких-то определенных знаний специфики вашей работы. Ваши советы всегда уместны и полезны для проекта. Благодаря вашему опыту в создании собственных продуктов вы хорошо понимаете многие подводные камни и можете предвидеть различные аспекты будущего проекта. Вы сразу и честно предупреждаете о возможных сложностях на пути создания проекта, что помогает клиенту максимально подготовиться и правильно оценить свои силы и возможности. При необходимости, вы не чураетесь бесплатно проделать чуть больше оговоренного, особенно, если это сделает проект только лучше.» Любой IT-продукт — это инструмент, с помощью которого реализуется некая бизнес-идея. Ее важно правильно спроектировать, как можно быстрее реализовать и валидировать, потратив как можно меньше ресурсов. И опыт набивания шишек и наступания на грабли в виде собственных проектов здесь как нельзя кстати, потому что мы свои деньги и время уже потратили, «набив» этот опыт. И о нём нужно не бояться говорить: пусть вы расскажете клиенту о каком-то своем факапе, но зато он его избежит, свои деньги не потеряет, лояльность к вам обретет и, может быть, даже другим расскажет.
А как реагирует заказчик?
