Как известно, мобильные приложения – это потенциал роста для многих компаний. А сейчас еще весна – время, когда все думают о всестороннем созидании и развитии, а годовые бюджеты еще позволяют желаниям занимать все свободное пространство.
Обладая хорошим портфолио, добрыми отзывами от клиентов и уже друзей, почта начинает заполняться заявками на оценку. У всех разная политика по ценообразованию и характеру продуктов, но каждый находит своего клиента. А вот на пути от знакомства к оценке, от оценки к договору, от договора до релиза есть ряд препятствий, проблем и расхождений, которые могут встретить стороны. Особенно это заметно при общении с компаниями, которые впервые заказывают мобильные приложения. И вот этим постом ниже я хочу уменьшить количество скрытой информации, показать важные и часто забытые аспекты, чтобы общение между клиентов и разработчиком было открытым и приятным.
Из чего же складывается оценка мобильного приложения?
Аналитика
Большинство клиентов приходит лишь с общими мыслями о том, что им хотелось бы получить в итоге.
Иногда у клиента есть не только видение, но и ТЗ:
Мобильное приложение для iOS и Android для возможности пользователям в режиме голосового управления вести учёт того что они едят, как питаются, выполнять контроль своего питания без необходимости регулярного ручного занесения данной информации. Есть ТЗ и макеты дизайна.
Порой мы видим конкретные, но не глубокие желания:
Добрый день! В нашей компании сейчас есть интернет-магазин (URL) работающий на cms XYZ, а также приложение, собранное через конструктор, не удовлетворяющее нашим требованиям, которое мы хотели бы заменить (URL). Функции, которые мы хотели бы иметь в приложении: - возможность оплатить товар картой - личный кабинет, с историей заказов - привязка индивидуальной скидки к клиентам, у которых она есть - система накопительных бонусов - ежедневно пересчитывать цены, в зависимости от курса Евро
А иногда люди сами все чувствуют и ставят улыбочку в конце:
Облачный многофункциональный сервис интегрированных бизнес приложений с привязкой к платформе Битрикс24...)
Большая часть таких проектов получает письмо с рядом вопросов, которые необходимы разработчику для осознания, насколько глубоко и/или широко планируется развить функционал помимо описанного ключевого функционала. В голове у клиента есть гораздо больше, чем он излагает в первом письме.
У разработчика есть определенная дилемма. Чтобы дать точную и хорошую оценку, надо погрузиться в проект. А для этого надо тратить ресурсы на осознание и анализ, предлагать что-то клиенту, исходя из собственного опыта.
Мы эмпирически решили, что если проект интересный, или потенциальный клиент вызывает самые лучшие чувства – мы погружаемся и выдаем клиенту то, что может сделать его продукт интереснее. Мы делаем эту extra mile не из соображений повышения конверсии, а от души. Потому что приятно помогать хорошим начинаниям.
Справедливо ради, далеко не все компании делают это. При наличии строгих KPI отдела продаж и других факторах, которые действительно важны, не всегда получится выкатить клиенту хорошие для его задумки или бизнеса идеи.
По результатам двухсторонних уточнений, разработчик очерчивает границы планируемого продукта и делает предложение по цене и срокам.
Если всем всё нравится, заключается сделка. Этот процесс, вероятно, уже знаком читателю.
Старт проекта
Здесь все действуют с учетом своих процессов и понимания эффективного процесса.
Некоторые разработчики сначала делают детальное техническое задание, подписывают его кровью, потом и любовью – и переходят к дизайну с осознанием конкретного скоупа. Это хорошая практика, которая снимает с разработчика множество рисков. Тем не менее, по моему личному мнению, это элемент защиты – важный, но не обязательный. С одной стороны, можно не работать с мудаками и делать отличные продукты, а с другой стороны – в любой компании может неожиданно поменяться политика, руководство, PM и всё что угодно. Мы на такое попадали, и это всегда неприятно, если у тебя нету чёткого ТЗ.
Есть также популярный в США, но не очень любимый в России вариант оплаты пост-фактум, каждые две недели по часовой ставке специалистов. У нас в стране в целом и в разработке в частности есть большая проблема с доверием. Что является гарантом, что разработчик не выставит на любую задачу 1.3Х часов? Или 2Х? Репутация? А как проверить правдивость? Ведь есть наукоемкие задачи, а есть ресурсоемкие. Первые объективно оценить достаточно сложно.
Поэтому методика работы по Agile/SCRUM с оплатой по итерациям в наших реалиях мутирует в сторону обычной разработки, где разработчик понятийно подтверждает +- сроки на +- функционал. А вот когда доверие уже появляется в конкретном проекте между конкретными людьми, все становится проще.
Мы в Bongo R&D исповедуем совмещенный подход. Наша цель – делать хороший продукт. Делать его при высокой выработке, но с максимальным комфортом для клиента. Нередко мы не делаем первоначального ТЗ, ограничиваясь лишь общим описанием продукта.
Мой личный опыт дает два факта:
- Можно заранее представить прикладной функционал, который клиент захочет к тому или иному блоку – и сразу заложить это в оценку. Чтобы потом не тратить время на допники.
- За более чем десять лет в IT не было ни одного проекта, который бы прошел от начала и до конца без изменений.
Работа по Agile с частыми релизами вне зависимости от формата сделки позволяет клиенту и нам заранее "пощупать" продукт и увидеть его слабые места и зоны роста. И быстро сориентироваться на месте.
Дизайн
Опасайтесь компаний, который закидывают вас терминологией и спецификой. Всё (sic!) в айти можно объяснить простыми словами. А если не можете – значит не знаете.
Недавно видел конкурентное нам предложение на разработку мобильных приложений – так там компания давила на то, что везде будет полный google material design, а цена в два раза ниже нашего предложения. Посмотрев сайт и портфолио ребят, я осознал суть – коллеги просто используют стандартные элементы средств разработки. Если мы на кончиках пальцев создаем каждый элемент интерфейса, обдумываем положение деталей, их взаимодействие между собой и с клиентом, делаем приятную, но не избыточную анимацию... То они просто набрасывают стандартные списки и иконки, прямолинейно выводя данные с сервера. Конечно, кому-то это подойдет. Но клиент хотел премиум, и слова о material design, разработанный самим Google, его заметно дезориентировали.
В моем понимании, отличный User Experience (UX) и дизайн – это не сложная, всячески анимированная и прыгающая конструкция. Это интерфейс, который кристализует основную ценность приложения для клиента. И этого не так-то просто достичь. Недавно мы делали UX & дизайн приложения с 200+ экранами – много труда, а в результате – предельное простое (в лучшем понимании этого слова) приложение.
Не всё, что выглядит просто, просто сделать.
Важно отметить, что в мобильных приложениях дизайн очень заметно влияет на стоимость разработки. Если клиент пришел на простой и чистый стиль разработчика, а в процессе захотел, чтобы летали ракеты и поля ходили ходуном – это рост по стоимости дизайна и разработки, а не только дизайна.
Подумайте, нужны ли вам дикие анимации? Добавят ли они ценность продукту? Исходите из того, что продуктов будут пользоваться каждый день. Не будет ли это отвлекать? Впечатлить клиента можно, но важно не потерять за этим ценность.
Бэкенд / сервер
Backend – не лидер по неупоминанию, но о нем редко говорят и думают клиенты. Что это такое?
Серверная часть – это место, где функционирует вся бизнес-логика приложений. Когда клиент авторизуется через Facebook, оформляет заказ, просматривает фотографии – всё это происходит в связке с сервером. Сервер "отгружает" на мобильные клиенты все необходимые данные для отображения и указывает "что делать дальше".
Компании по-крупнее понимают, что бэкенд будет интегрироваться со внутренними и внешними системами: АБС, CRM, смс-шлюз и прочие. Таким образом, это еще и промежуточное звено или маршрутизатор в некоторых аспектах.
У хорошего разработчика бэкенд должен быть покрыт тестами. Тесты – это тоже программирование. Именно они позволят вам при развитии приложения не натыкаться на постоянные ошибки. Обратная совместимость – чтобы старое не ломалось, когда создаешь новое. Цените разработчиков, которые делают это – это хороший тон и залог технической адекватности.
Стоит сказать, что не нужно удивляться сравнительно высокому ценнику на серверную часть. Это ядро вашей системы. Можно сказать, что сервер несет бизнес-ценность, а мобильные приложения – коммуникацию с конечными клиентами.
Иногда клиент берет разработку backend на себя. Это хорошо, если внутри темный лес. У разработчика пропадает необходимость тратить много времени на разбор рудиментарного кода – ведь порой верстка может быть внутри базы данных. Такое еще встречается, да. А за осознание наследия заказчика оный платить не очень любит. Программируйте, а не разбирайтесь (с)
Но местами это и плохо вне зависимости от того, насколько все хорошо или плохо в технологиях заказчика. С его стороны должен быть выделен человек, который разбирается в теме, которого не будут отвлекать на другие задачи, с которыми нужно сформировать атмосферу любви и взаимопонимания. Не всегда это сбывается, а в результате уезжают сроки создания продукта, а разработчик попадает на простой специалистов.
Бывает и недопонимание по конечным технологическим аспектам. Небольшие современные компании находятся в зоне более широких компетенций, делали многое и многим. Разработчик со стороны клиента нередко разбирается в "своей теме" и своем наборе технологий. Важно понимать, что плохой сервер может не только замедлить работу приложений, но и сделать какие-то решения по дизайну невыполнимыми. Это касается крупных компаний и банков в частности – стоимость изменений для них очень высока, риски введения "новых штук" также не всегда вызывают исключительно позитивный настрой у айти-департамента. Бизнесу хочется, а айти колется. А конечный разработчик мобильных приложений выкручивайся как хочешь. Либо пиши четкое ТЗ изначально. Хотя помню, как в роли сервера для нас выступал текстовый (.txt) файл, обновляемый постоянной выгрузкой из 1С специалистами клиента. Вопреки, кстати, ТЗ, но во имя запуска продукта. Работало на удивление прилично.
Админка / Система управления
Вот это уже действующий лидер забытых аспектов мобильной разработки.
А я думал, что написать админку для мобильных приложений – это как поставить wordpress. И все сортировки и прочее есть из коробки.
Вообще, надо сказать, что хорошая система управления – это серьезный труд. Причем совместный. Клиент должен делиться своими бизнес-процессами, а хороший разработчик – искать пути их оптимизации и эффективной реализации для конечного потребителя, сотрудников заказчика.
Админка нужна для чатов поддержки в приложении, управлении каталогом товаров, просмотра заказов, создания акций, настройки маркетинговых кампаний, просмотра и блокировки пользователей и многого другого. Фактически, клиент захочет если не управлять, то просматривать объекты каждой сущности. То есть, если в приложении есть пользователи и заказы чего-либо, то в админке мы должны увидеть всех этих пользователей, их данные, контакты, а также их заказы с информацией о доставке, методах оплаты и много другом.
Бывает печальный момент, когда клиент предполагает, что не важны форматы и структура того, что он планирует в будущем добавлять в админку. Так могут пересечься или конфликтовать Типы Объектов, их характеристики и все что угодно. Да даже интерфейсно какие-то вещи могут не вписаться. Очень важно, чтобы клиент рассказал о своих товарах и услугах в начале проекта, иначе риск встать на путь расхождения ожиданий очень велик. Искреннее непонимание "почему это не добавляется в админке" будет знатно сдобрено искренним непониманием "как это можно было не сказать изначально".
Есть еще варианты, когда клиент готов экономить на админке, но тут он экономит (или идет на компромисс) с внутренними пользователями. Либо админкой может выступать уже существующий у клиента backend с админкой, например, движок интернет-магазина.
Разработка мобильных клиентов
В данном вопросе очень много нюансов, тут скорее нужны вопросы из зала для отдельной статьи. Я всегда был про развенчание мифов на локальном рынке IT, где говно продается задорого. Бывает даже не со зла, а из-за дикой неэффективности процессов разработчика.
Внутри Bongo R&D мы используем Slack для единого центра коммуникации, Pivotal Tracker для agile-процесса управления задачами (user stories), GitLab на своих серверах для хранения исходных кодов, тестирования и непрерывной интеграции.
Тестирование
И это немаловажный аспект. Устройств становится все больше, операционные системы обновляются, а в мире все еще ходит не мало устройств с устаревшим ПО. Чего стоит один Android в одной только России. А если делать проект на западный, европейский или азиатский рынок – там вообще все иначе. Вы сможете познакомиться с чудным миром устройств от Huawei на Android, в которых вообще всё живет своей жизнью.
Компании по-разному подходят к тестированию. Некоторые тестируют каждый этап и каждый мини-релиз, некоторые делают массовый заход на множестве устройств ближе к готовности.
Обязательно уточняйте о подходе разработчика к тестированию.
Формирование любви
Очень важно, чтобы каждый занимался тем, что ему нравилось. Хотя бы 50% времени. Поэтому старайтесь придумывать для вашего бизнеса нечто такое, что будоражило бы умы и руки разработчиков. Нам нравится делать амбициозные продукты. Хороший настрой всегда позволяет сделать немного больше, чем было оговорено.
Старайтесь работать с командами, которые дополняют вас. Я не вижу смысла, когда банк работает с крупными разработчиками. Да, это надежность – но не путь вперед. Пока две дико забюрократизированные структуры будут согласовывать каждый чих, рынок уже уйдет вперед. Рисков-то, конечно, минимум, но и развития так будет крайне мало.
Найдите точки опоры для создания доверия. Задавайте правильные вопросы в начале. Поговорите открыто. Старайтесь закрывать слабые места разработчиков своим ресурсом, чтобы они больше занимались разработкой.
Ведь в один день к вам может подойти акционер и сказать на давно утвержденный дизайн, который уже почти запущен в бой, что "вот эта черная плашка выглядит депрессивно, уберите". Не всегда удается доказать обратное, несмотря на его любовь к своему недепрессивному черному Bentley. :) Это такой момент, когда разработчик может ответить благодарностью за помощь и содействие, придумав что-то быстро и без существенных потерь.
Публикация приложений в маркетплейсах
Маркетплейсы – это, например, Appstore, Google Play. Каждый разработчик покупает годовое участие в этих маркетплейсах: 100$ для AppStore, 25$ для Google Play.
Разработчик может выложить приложение либо из-под своего аккаунта, что и будет написано в соответствующей строчке. В целом, в этом нет ничего страшного, если вы доверяете разработчику.
Если же вы хотите, чтобы у вас были собственные аккаунты – необходима регистрация. В Apple это займет от 10 дней до месяца, а в Google – 1 день. Цены уже были выше. Даете доступ разработчикам на публикацию, они все делают сами. Никакой сложной науки тут нет.
Заключение
Получилось описать в большей мере то, о чем забывают при разработке мобильных приложений. Не забывайте, обсуждайте, делитесь и создавайте. Нет ничего невозможного.
Я верю в открытость и искренность. К сожалению, они не всегда побеждают. Но когда побеждают – это того стоит.
Если есть желание узнать о каких-то нюансах подробнее – пишите в комментариях. Отличного вам дня!
