Мобилизация. Как создать приложение, которым будут пользоваться - Вадим Файнштейн Страница 10

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

Разница в зарплате отличных программистов и начинающих или плохих достигает порой 500 %. А вред от плохого программного кода можно расхлебывать много лет (если вообще продукт попадет на рынок).

Порой решающим фактором в выборе подрядчика является цена.

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

Хотя правильнее все же смотреть не на бюджета на ROI – возврат инвестиций.

Есть множество способов проверки компаний – от интуиции до создания тендеров. Мне же импонирует проверка опыта: если подрядчик не смог создать до сих пор ничего дельного, скорее всего, у него в штате нет достаточно сильных специалистов, и с вашим продуктом у него тоже ничего не выйдет. С другой стороны, если подрядчик создал несколько успешных продуктов, он сам себе поставил планку, ниже которой не может позволить себе спуститься, и желание побеждать собственные рекорды, которое руководит многими из нас, будет гнать его вперед и в вашем проекте. Кроме того, если вы заглянете в рейтинг компаний-разработчиков, он, скорее всего, там окажется.

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

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

В конечном итоге все зависит от непосредственных исполнителей: от программиста, от дизайнеров, от дизайнера UX. Если они создают хороший продукт раз за разом, а не единожды, – значит, у них есть какой-то рецепт. Рецепты могут быть разными.

Например, у нас есть несколько десятков таких разработок. Более 200 миллионов человек в мире пользуются нашими приложениями.

Количество скачиваний – критерий, к которому апеллируют многие подрядчики. Но он важен в первую очередь для коммерческих продуктов b2c, которые предназначены для конкретного пользователя, таких как Moovit, Instagram, Facebook и так далее.

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

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

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

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

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

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

Как можно найти такие компании? Изучите сайт подрядчика. Здесь, как правило, всегда много логотипов в разделе «Наши клиенты».

Рейтинг, отзывы клиентов и прямое общение с кандидатами, пожалуй, самые главные инструменты для выбора.

Итак, очередной чек-лист: как выбрать разработчика мобильного приложения, на какие именно критерии обращать внимание?

• Опыт разработки приложений на нужной операционной системе;

• Опыт разработки приложений схожей тематики и функционала;

• Временной прогноз на реализацию проекта;

• Ценовая ниша разработчика;

• Участие и победы в отраслевых конкурсах.

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

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

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

Если вы не можете проследить за правильностью разработки, вы можете проследить за исполнением всех протоколов в процессе.

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

Торопиться или не спешить?

Один из самых часто задаваемых вопросов после размера бюджета: как долго создается приложение.

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

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

Это и есть та самая кочерыжка, MVP.

И только после первой версии постепенно добавляются фичи: оплата с помощью кредитной карты, квитанции об оплате, рейтинг таксистов.

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

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

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

Минимальный срок – 4 месяца, но он не всегда именно такой. Случается делать сложные приложения, у которых даже минимальный сет фичей достаточно велик. Но через полгода наш продукт обязан выйти на рынок.

Когда предприниматели спорят и хотят выпустить доведенный до идеала продукта не «полуфабрикат», я всегда привожу один и тот же пример.

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

Другая компания через 4 месяца выпускает минимальную версию, через месяц добавляется еще что-то, потом еще. В это время проводится АВ-тестирование.