Колонка для 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». Но теперь решить эту задачу вам будет гораздо проще — просто возвращайтесь к своему с таким трудом выбранному вендору. Он всегда с радостью вас примет!