платит дважды» действует с непреодолимой точностью.
Даже если приложение не является важной частью вашего бизнеса, оно часто является лицом вашей компании, интерфейсом между вами и вашим клиентом или сотрудником.
Разница в зарплате отличных программистов и начинающих или плохих достигает порой 500 %. А вред от плохого программного кода можно расхлебывать много лет (если вообще продукт попадет на рынок).
Порой решающим фактором в выборе подрядчика является цена.
Помимо операционной системы, на размеры бюджета влияют следующие факторы: месторасположение разработчика, категория/функционал приложения, необходимость всевозможных интеграций.
Хотя правильнее все же смотреть не на бюджета на ROI – возврат инвестиций.
Есть множество способов проверки компаний – от интуиции до создания тендеров. Мне же импонирует проверка опыта: если подрядчик не смог создать до сих пор ничего дельного, скорее всего, у него в штате нет достаточно сильных специалистов, и с вашим продуктом у него тоже ничего не выйдет. С другой стороны, если подрядчик создал несколько успешных продуктов, он сам себе поставил планку, ниже которой не может позволить себе спуститься, и желание побеждать собственные рекорды, которое руководит многими из нас, будет гнать его вперед и в вашем проекте. Кроме того, если вы заглянете в рейтинг компаний-разработчиков, он, скорее всего, там окажется.
Поэтому главный и чуть ли не единственный критерий, по которому можно вообще что-то проверить, – это количество успешных разработок, выполненных компанией-исполнителем.
Иногда случается, что у компании есть 1–2 известных продукта, а остальные никто не знает. Это уже большой плюс, но не всегда однозначно хорошо говорит о компании. В идеале нужно найти такого подрядчика, у которого раз за разом получается создать что-то интересное.
В конечном итоге все зависит от непосредственных исполнителей: от программиста, от дизайнеров, от дизайнера UX. Если они создают хороший продукт раз за разом, а не единожды, – значит, у них есть какой-то рецепт. Рецепты могут быть разными.
Например, у нас есть несколько десятков таких разработок. Более 200 миллионов человек в мире пользуются нашими приложениями.
Количество скачиваний – критерий, к которому апеллируют многие подрядчики. Но он важен в первую очередь для коммерческих продуктов b2c, которые предназначены для конкретного пользователя, таких как Moovit, Instagram, Facebook и так далее.
Для продуктов b2b не столько имеет значение количество пользователей, сколько вовлеченность клиента, финансовые обороты.
Здесь стороннему наблюдателю будет трудно определиться, не зная сути бизнеса. Например, у нас есть компания, которая занимается продажей бриллиантов по всему миру. Это продажи b2b: бриллианты продают не физическому лицу, а предприятию, которое вставляет эти бриллианты в изделия.
Это одна из самых больших компаний в мире по продаже бриллиантов. Приложение очень успешное, но у него всего несколько тысяч скачиваний. Хотя финансовые обороты приложения – гигантские.
Следующий шаг при выборе подрядчика – найти реальных заказчиков и собрать их рекомендации.
Если подрядчик сообщает, что разработал ранее замечательное приложение, у которого очень большой спрос, найдите компании, с которыми работал этот подрядчик.
Причем желательно обращаться не к тем, которых порекомендовал ваш будущий подрядчик, а другим. Разве кто-нибудь посоветует вам компанию, которая будет его рекомендовать не с лучшей стороны? Найдите заказчиков самостоятельно, в этом случае шансы, что вы получите объективную оценку работы исполнителя, значительно выше.
Как можно найти такие компании? Изучите сайт подрядчика. Здесь, как правило, всегда много логотипов в разделе «Наши клиенты».
Рейтинг, отзывы клиентов и прямое общение с кандидатами, пожалуй, самые главные инструменты для выбора.
Итак, очередной чек-лист: как выбрать разработчика мобильного приложения, на какие именно критерии обращать внимание?
• Опыт разработки приложений на нужной операционной системе;
• Опыт разработки приложений схожей тематики и функционала;
• Временной прогноз на реализацию проекта;
• Ценовая ниша разработчика;
• Участие и победы в отраслевых конкурсах.
Что делать, если вы все же попали на недобросовестного разработчика? Уходить. По моему опыту, попытки дать недобросовестному разработчику исправиться приводили только к затягиванию сроков и увеличению бюджета.
Часто до последних этапов разработки кажется, что работа никогда не закончится. Количество багов только увеличивается, а сроки поджимают.
Это не всегда говорит о проблеме. Количество багов может расти из-за того, что перед окончанием работ большие силы направлены на тестирование. Починка одного бага может привести к созданию новых. Однако даже если есть временные скачки, тенденция должна вести к понижению количества багов.
Если вы не можете проследить за правильностью разработки, вы можете проследить за исполнением всех протоколов в процессе.
Еще раз убедитесь, что в команде подрядчика есть человек, который является вашим адвокатом, задачей которого является отстаивание ваших интересов. Часто этим занимаются аккаунт-менеджеры, сейлы.
Торопиться или не спешить?
Один из самых часто задаваемых вопросов после размера бюджета: как долго создается приложение.
Есть два подхода. Первый из них: компания-подрядчик делает все самостоятельно, включая самые мелкие, даже не самые нужные фичи. Этот процесс занимает большее время.
Другой подход. На рынок выпускается приложение только с самой необходимой функцией. Помните кейс про заказ такси? Первая версия приложения позволяла только заказать такси: без оплаты через приложение, без квитанций. Вызвали такси – машина приехала.
Это и есть та самая кочерыжка, MVP.
И только после первой версии постепенно добавляются фичи: оплата с помощью кредитной карты, квитанции об оплате, рейтинг таксистов.
Я люблю выпускать такой продукт на рынок через 4 месяца после того, как мы начали работать.
У нас с начала работы есть список заданий, которые мы хотели сделать, но они не вошли в первую версию. Как пример – оплата кредиткой. Это нужно всем, мы знаем, что эта фича зайдет в приложение. Когда мы только заканчиваем первую версию, еще до тестирования, до проверки того, что действительно нужно пользователю, мы уже начинаем разрабатывать фичу с кредиткой.
Чаще всего заказчик знает, какие именно функции он хотел бы сделать в течение первого года.
Минимальный срок – 4 месяца, но он не всегда именно такой. Случается делать сложные приложения, у которых даже минимальный сет фичей достаточно велик. Но через полгода наш продукт обязан выйти на рынок.
Когда предприниматели спорят и хотят выпустить доведенный до идеала продукта не «полуфабрикат», я всегда привожу один и тот же пример.
Есть две компании. Одна в течение двух лет разрабатывает свой идеальный продукт. После этого выпускает его на рынок, ноль пользователей, можно начинать маркетинг.
Другая компания через 4 месяца выпускает минимальную версию, через месяц добавляется еще что-то, потом еще. В это время проводится АВ-тестирование.