В сильно упрощённом варианте разработка мобильного приложения выглядит следующим образом: придумать классную идею, воплотить классную идею, наслаждаться результатом. А команда разработки состоит из одного универсального специалиста, который умеет всё.
Увы, это не имеет ничего общего с реальным положением вещей. От момента, когда вам в голову приходит идея, до момента, когда можно будет спокойно греться в лучах собственного великолепия, — целая жизнь, со своими взлётами, падениями и сложностями.
Кстати, греться в лучах собственного великолепия тоже придётся с ноткой тревоги. Потому что работа над приложением — если вы, конечно, хотите, чтобы оно жило долго и счастливо — не заканчивается никогда.
Но пока не об этом. Пока — о том, как собрать команду, которая будет способна поддержать проект (и лично вашу веру в его успех) на каждом этапе реализации.
Основные этапы разработки мобильного приложения
1. Оценка идеи и определение стратегии
Хорошая идея — та, которая предполагает ответ на какую-либо существующую проблему или потребность.
Хорошая стратегия — та, которая включает в себя:
- анализ конкурентов (с особенным вниманием к недочётам);
- анализ потенциального интереса к вашему приложению;
- план работы над проектом;
- план монетизации и продвижения приложения;
- дорожную карту — путь вашего приложения от минимального жизнеспособного продукта (MVP) до попадания в топы магазинов.
На этом этапе имеет смысл подумать обо всём, о чём вы боялись думать, и предусмотреть всё, что может пойти не так. Справиться с подобной задачей в одиночку практически невозможно.
На этом этапе вам понадобятся:
- product-менеджер,
- аналитик,
- маркетолог.
2. Работа над UX и UI-дизайном
Этот этап будет определять, насколько приятно будет смотреть на ваше приложение и пользоваться им.
В UX-части важно учесть максимально возможное количество вариантов пользовательского поведения, а желательно ещё и сразу протестировать на живых пользователях.
В UI необходимо предусмотреть сценарии использования и адаптировать дизайн под поставленные задачи. Например, подумать о том, как в интерфейс впишутся более длинные или более короткие текстовые конструкции — если предполагается, что приложение будет выходить в разных странах на разных языках. Короткие английские слова и предложения позволяют легко и ёмко передать суть. Но для подачи той же информации на русском или французском, потребуется больше слов, а значит, и больше места под их размещение.
На этом этапе обязательно нужно полностью собрать визуальный прототип и протестировать его на потенциальной аудитории. Потому что то, что работает в теории, может оказаться нежизнеспособным на практике — и чем раньше вы это поймёте, тем лучше. Usability тесты — залог сохранения ваших нервов и средств.
На этом этапе вам понадобятся:
- product-менеджер,
- UX/UI-дизайнер,
- подопытные пользователи для usability тестов (в идеальном раскладе).
3. Переход от дизайна к разработке: Mobile и Backend
Этот этап многие считают вообще единственным этапом во всей работе над приложением. Но в реальности он, как видите, занимает всего лишь почётное третье место.
Для того чтобы продуманный до мелочей и многократно протестированный дизайн превратился в удобное приложение, нужен чёткий план и современный подход к разработке. Следование методологии Agile на этом этапе позволит эффективно взаимодействовать внутри команды друг с другом и с заказчиком, быстро реагировать на изменения и уделять внимание работе над продуктом, не отвлекаясь на вспомогательные задачи.
Худшее, что можно сделать на этом этапе, — нанять junior специалистов и использовать непопулярные или устаревшие технологии. Потому что в результате придётся переписывать код, доплачивать за переработки, срывать сроки и очень много нервничать.
На этом этапе вам могут понадобиться:
- техлид или СТО,
- product-менедежер,
- project-менеджер,
- mobile-разработчики,
- backend-разработчики,
- девопсы.
4. Тестирование перед запуском
Нет, этим этапом нельзя пренебречь.
Да, даже если вы нашли для предыдущих трёх пунктов специалистов, которые справились со своей работой на 10 из 10.
Финально проверять приложение на ошибки — не так больно, как получать токсичные отзывы от пользователей уже после релиза.
На этом этапе вам понадобятся:
- QA-инженеры,
- подопытные пользователи.
5. Запуск и внедрение на рынок
Самое важное, о чём нужно позаботиться перед тем, как представить своё мобильное приложение миру — надёжный API-сервер и соблюдение правил Google Play Store и Apple App Store.
Также этот этап включает в себя отслеживание всевозможных метрик, поиск и устранение ошибок, оценку производительности и пользовательского поведения, работу с репутацией и регулярные обновления. То есть он начинается от момента, когда вы «выпускаете» приложение в свободное плавание, и продолжается практически бесконечно.
На этом этапе вам могут понадобиться все, кто уже был задействован в проекте до этого:
- product-менеджер,
- аналитик,
- маркетолог,
- UX/UI-дизайнер,
- подопытные пользователи для usability тестов (в идеальном раскладе),
- техлид или СТО,
- project-менеджер,
- mobile-разработчики,
- backend-разработчики,
- девопсы.
а также непоколебимая вера в успех и всё ваше терпение.
Основные сложности связаны с желанием пропустить парочку промежуточных этапов в работе над мобильным приложением. Например, проигнорировать анализ конкурентов или оценку востребованности вашей идеи на рынке, пренебречь UX-дизайном или тестированием в фокус-группах.
В результате такой «оптимизации» можно получить приложение, которым никто не захочет пользоваться, впустую потраченные бюджеты и нешуточных размеров разочарование.
Поэтому важно, во-первых, соблюсти последовательность всех этапов, и, во-вторых, определить конкретных людей для работы на каждом этапе.
Три причины для того, чтобы определить ключевых ответственных за каждый этап разработки приложения
- Если на одного человека свалится и разработка, и дебаггинг, и поддержка пользовательского интереса, в обозримом будущем он банально выгорит дотла и сбежит. Да и качество работы при такой многофункциональности обычно довольно спорное.
- Когда за каждую часть отвечает конкретный человек, всегда можно именно к нему прийти с вопросом «Почему вот здесь не работает?». Когда непонятно, кто за что отвечает, то вопрос останется без ответа, а приложение — в конечном счёте — без лояльной аудитории.
- Для того, чтобы выдавать адекватный результат, нужен релеватный опыт. Если человек безупречно разбирается в UX-дизайне, это не значит, что он сможет и анализ конкурентов провести, и к публикации в магазинах приложение подготовить. И если у автора идеи нет ни малейшего представления о том, как продвигать её на рынке, команде нужен в первую очередь не разработчик, а эксперт в этой области.
Найм, фриланс, аутсорс, аутстафф: как отличить одно от другого и что выбрать
Существует несколько способов формирования команды. Каждый из них — само собой — имеет свои фичи и баги.
Найм
Классическая схема.
Вы обращаетесь к эйчару (допустим, он у вас есть), формулируете описание идеального кандидата и ждёте. Потом встречаетесь с потенциальным членом команды вживую, моментально находите с ним общий язык, берёте его в штат и живёте долго и счастливо.
Надеемся, вы уловили оттенок грустной иронии: на самом деле это — идеальный расклад и большая редкость.
Найм сотрудников занимает очень много времени и обходится очень недёшево. Особенно сложно найти, к примеру, тимлида. Хорошими тимлидами не рождаются — ими становятся особенно талантливые разработчики, которые в процессе приобретают невероятную разборчивость в вопросах трудоустройства.
А ещё нет никаких гарантий, что специалисты, которых вы наймёте, быстро сработаются и смогут выдать качественный продукт.
Сотрудники на фрилансе
Этот вариант, конечно, значительно дешевле, чем найм в штат. Но в остальном — минусы те же: потребность в специально обученном человеке, который будет заниматься подбором специалистов, сроки поиска и сомнения в том, что новые сотрудники смогут быстро сработаться.
Плюс намного меньше уверенности в профессионализме кандидатов и постоянный страх, что сотрудник на фрилансе в какой-то момент просто пропадёт с радаров, оставив вас с наполовину собранным приложением.
Аутсорс
Предполагает, что вы не берёте сотрудника в штат, а заключаете договор с некой компанией, которая и выполняет всю работу. У такой компании есть в штате все нужные вам специалисты, которые уже сработались и смогут быстро влиться в работу над проектом.
Из минусов — пожалуй, то, что специалисты в такой компании обычно работают параллельно сразу над многими проектами, и не факт, что ваше приложение получит столько внимания, сколько бы вам хотелось.
С другой стороны, если вы не планируете делать что-то невероятно уникальное, аутсорсинг подойдёт идеально.
Аутстафф
Аутстаффинг предполагает найм сотрудника через агентство, которое является его официальным работодателем. И даёт вам возможность собрать команду под свои цели и задачи, а значит, больше возможностей для реализации чего-то уникального и крутого. Кроме того, в этом случае вы платите специалисту только за то время, когда он работает над проектом.
Как раз по этому принципу работает Skipp — мы ищем талантливых разработчиков по всему миру, чтобы потом помочь им встретиться с вами и вашим проектом.
При этом можно нанять как одного недостающего сотрудника, так и сразу целую команду.
Напоследок — небольшая памятка
- Не забывайте о том, что команда мобильной разработки включает в себя не только разработчиков.
- Чётко следуйте по этапам работы над приложением, не упуская ни одну мелочь.
- Определяйте на каждую роль конкретного человека с релевантными скиллами и опытом.
- Будьте готовы тратить время и силы, идти на компромиссы и работать над приложением гораздо дольше, чем изначально планировалось; это всё нормальные части процесса.