Свяжитесь с нами
Используйте форму для связи с нами
Колонка для cossa.ru о том, как правильно выбрать подрядчика для разработки мобильного приложения

Дмитрий Желнин
CEO
Заказывать мобильное приложение нужно в регионах
На волне моды и роста интереса к мобайлу многие компании заказали себе приложения. И почти все они сегодня нуждаются в обновлении или переделывании с нуля. Иногда причина в ужасном качестве; в некоторых случаях продукт устарел, изменились технологии и требования бизнеса.

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

Выбираем студию

В целом найти кандидата в подрядчики на мобильную разработку довольно просто — можно изучить популярные рейтинги вроде RUWARD, «Рейтинга Рунета», «Тэглайна», или просто кинуть клич в Facebook (например, в группе «Ищем подрядчика»). Желающих поучаствовать в проекте наберётся прилично. Но как выбрать из них лучших? Вот несколько советов.

1. Идите в регион

Если у вас небольшой бюджет, то работа с московскими студиями, скорее всего, не ваш вариант. Это дорого по вполне понятным причинам. Наши столичные друзья-конкуренты в беседах часто жалуются на свою сложную жизнь и необходимость продавать свои услуги «очень дешево» — за 2500-2800 рублей в час. В регионе можно найти студию не хуже и с аналогичным рейтингом, но по цене в два раза меньше. Пример из нашего опыта — мы сделали приложение для крупной страховой компании в 6 раз дешевле, чем просил крупный московский игрок из топа.

2. Никаких мелких лавочек

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

Мы регулярно сталкиваемся с жертвами таких разработчиков (подчас, к тому же, не вполне добросовестных). Недавний пример: к нам обратилась владелица сети салонов красоты из Москвы. До этого она работала с небольшой рязанской студией, внесла предоплату около 3 млн рублей (80% стоимости всего проекта!). Готовое приложение ей обещали сделать за три месяца.

В итоге студия тянула время полгода. Затем ещё три месяца. А затем разработчики окончательно «слились». Дело дошло до обращения в суд и привлечения юристов. Здравый смысл и наш опыт говорят о том, что даже если в итоге заказчик и получит некий релиз, он будет ужасен и потраченные 3 млн рублей придётся списать в убытки.

Иногда такие вымученные приложения попадают в наши руки. От увиденного часто волосы встают дыбом — фатальные ошибки в архитектуре, небрежная работа с кодом, вплоть до мата в комментариях к нему, полное отсутствие покрытия автотестами и другие немыслимые в 2016 году вещи.

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

3. Слишком крупные компании — тоже плохо

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

«Без ТЗ результат ХЗ»

Если выбранный подрядчик предлагает сразу приступить к работе, а не уделяет время написанию технического задания (ТЗ) — с ним нужно немедленно прощаться. ТЗ — это первый шаг на пути создания приложения, его нельзя пропускать. Студия должна выделить вам аналитика, совместно с которым такой документ и будет создан. Обычно это стоит недорого — от 30 до 100 тысяч рублей, а на выходе за эти деньги вы получите внятное описание того, что за продукт вообще заказываете.

Несколько требований, которым должно удовлетворять техническое задание:

  • документ должен быть создан человеком с техническим бэкграундом, а не лириком, оперирующим общими фразами;
  • в ТЗ должны быть мокапы или карта экранов;
  • должны быть внятно описаны как функциональные, так и нефункциональные требования (подробнее о тех и других можно прочитать здесь).
Что вам даст проработанное ТЗ:
  • общее с подрядчиком понимание объёма работ;
  • возможность точно оценить стоимость и, как следствие, выбить более низкую цену;
  • процесс совместной с разработчиками подготовки ТЗ даёт понимание, комфортно ли с ними будет работать в будущем;
  • вы получите последний шанс без ущерба для проекта провести мини-тендер и сменить подрядчика. Адекватное ТЗ можно дать и другим разработчикам;
  • драматически снижаются риски пошлых историй вида «знаете, тут всё оказалось сложнее, чем мы думали, так что придется доплатить»;
  • принимать приложение по чётко прописанным критериям гораздо легче.
Выбора технологий не существует

Обычно разработчики предлагают заказчикам выбор — создавать их приложение на «нативных», то есть родных для платформ языках программирования (Swift для iOS, Java для Android) или кроссплатформенных фреймворках вроде Xamarin, PhoneGAP, ReactNative и т.п.

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

Выбора методологии разработки тоже не существует!

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

Также по релизам должна осуществляться и оплата — спринт принят, деньги ушли. Никаких предоплат по 50% от стоимости проекта делать не нужно. Если же вам предлагают работать именно по такой схеме — все разговоры с таким подрядчиком нужно сворачивать.

API и тестирование должны быть

Старт разработки без интерфейса доступа к системам, с которыми должно работать приложение (API), просто невозможен. К моменту начала проекта API или как минимум его спецификация уже должны быть готовы. Если это не так — беды не избежать.

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

Пример кейса из нашей практики, когда это правило не было соблюдено заказчиком:
На старте работ мы получили обещание создать «крутое API», после подписания контракта выяснилось, что за его разработку отвечает один программист без тестировщиков и менеджмента. Этот специалист пишет код в стиле «разработка на ошибках», бэкенд толком не тестируется, всё проверяется на работе (или не-работе) мобильного приложения.
Когда мобильные разработчики начинают развитие определенной функциональности (2-3 экрана), и уже в процессе внезапно выясняется, что кое-каких данных для расчётов не хватает — бэкенд-инженер заказчика начинает в режиме ужаленной кошки писать код, чтобы хоть что-то работало. (Срыв сроков не нужен никому.)

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

Если бы спецификация API была готова заранее, то в сервисах вроде apiary.io или swagger.io можно было бы разработать тесты, а бэкенд-разработчик знал бы, где у него ошибки. Это бы сильно снизило общее количество боли на проекте.

Так выглядит спецификация API для одного из наших проектов
Еще одна аксиома — нельзя выпускать приложение с багами. Цена ошибок сейчас крайне высока — пользователи начнут «отваливаться», и вернуть их назад будет невозможно. При этом ошибки в разработке присутствуют всегда, а значит, на их поиск и исправление может уходить от 30% до 50% всех ресурсов проекта. С этим нужно просто смириться.
Вот несколько советов, которые помогут повысить качество процесса тестирования:

1. У подрядчика должен быть выделенный отдел тестирования (QA) и масштабный парк устройств, на которых запускаются приложения. Если услышите истории про «у нас разработчики тестируют на своих личных устройствах» — сразу до свидания. Мы держим в парке как самые слабые и бюджетные устройства, так и все самые популярные флагманские смартфоны. Удовольствие недешёвое, но без этого никак.
Это примерно треть парка наших устройств для тестирования приложений
2. Необходимо запросить тест-кейсы специально под ваш проект, после старта работ нужно запрашивать отчёты по тестированию.

3. Также не стоит забывать интересоваться аналитикой сервисов вроде Crashlytics (сервис для отслеживания «крашей», доступен и разработчику, и заказчику).

Ура, релиз! А что дальше?

Наконец, все сложности преодолены, ваше предложение опубликовано в магазинах. Можно выдохнуть? Как бы не так — теперь работы меньше не станет. Прежде всего, вам придётся познать все радости продвижения своего приложения (ASO и вот это всё), сбора аналитики по его использованию, работы с пожеланиями пользователей, а также стрессы от выхода новых версий iOS или Android.

Всё это ненавязчиво приводит к мысли о том, что «пора делать версию 2.0». Но теперь решить эту задачу вам будет гораздо проще — просто возвращайтесь к своему с таким трудом выбранному вендору. Он всегда с радостью вас примет!