Мобилизация. Как создать приложение, которым будут пользоваться

На этот вопрос нет единственно верного ответа. Для некоторых приложений более подходящей будет гибридная разработка, для других – натив. В любом случае каждый вариант потребует от вас некоторого компромисса.

Важный критерий выбора – бюджет. Иногда мы предпочитаем потратить немного больше на разработку трех совершенно разных версий, чтобы создать оптимальный UX.

В других случаях важнее выпустить первую версию продукта быстро и недорого.

Несмотря на множество возможностей, предлагаю чек-лист, который вы сможете использовать для выбора предпочтительного метода разработки.

Задайте себе следующие вопросы:

1. Является ли UX неотъемлемой частью приложения?

2. Важна ли скорость выхода на рынок? (Например, попытка попасть в Арр Store перед потенциальными конкурентами)

3. Нужны ли вам различные уникальные функции?

4. Ограничен ли бюджет разработки?

5. Будут ли пользователи и приложение много взаимодействовать, что потребует высокой производительности?

6. Должен ли я начать с MVP, а затем разработать версию с другими функциями?

Если вы ответили «да» на четные вопросы, для вас подойдет гибридный способ. С другой стороны, если вы ответили «да» на нечетные вопросы, выбирайте нативную разработку.

Делать самому или выбрать исполнителя?

Это замечательно, если у вас уже есть слаженная техническая команда, обладающая нужными знаниями. Но что делать, если такой команды нет?

Вариантов всего два: набрать свою команду или обратиться к стороннему исполнителю.

Вариант первый. Набираете команду

Для разработки мобильного приложения нам нужны следующие специалисты:

1. Дизайнер UX

2. Графический дизайнер

3. 1 или 2 клиентских программиста (зависит от выбора гибридной или нативной платформы)

4. Программист серверной части

5. QA-менеджер – тот, кто отвечает за качество продукта (quality)

6. Руководитель проекта

7. Технический руководитель (может быть одним из программистов)

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

На первых порах не все специалисты нужны на полную ставку. Так, обычно дизайнер UX и графический дизайнер полностью заняты в начале проекта, но их время освобождается через несколько месяцев. Занятость руководителя проекта и QA-менеджера в небольших проектах не превышает 30 %. Например, проверка качества на первых этапах не нужна. По-разному заняты серверные и клиентские программисты.

Недостаточно набрать профессиональных сотрудников, нужно сформировать из них команду. Группу, связанную общим интересом, который превалирует над личными интересами. Создание такой команды займет от нескольких месяцев до года, нередко за это время происходит ротация кадров, неподходящие люди уходят.

Часто для создания команды нужен HR-специалист, что еще увеличивает бюджет проекта.

И все же у работы с собственной командой есть плюсы. Вот они:

• вы полностью контролируете разработчиков, а значит, и бюджет проекта;

• команда находится в одном офисе с маркетологами, бизнес-девелоперами, техподдержкой и «чувствует» ваш бизнес;

• команда болеет за свой продукт, что лучшим образом сказывается на качестве. Все члены команды являются амбассадорами приложения. Для них это приложение – их младенец, они спят и видят, как это приложение становится качественным, полезным, удобным. Они живут своим продуктом.

Теперь рассмотрим минусы.

• Сложности, связанные с набором и оптимизацией работы команды, откладывают выпуск первых версий продукта на много месяцев и дают преимущество вашим более быстрым конкурентам. Создать из разных людей команду, у членов которой взяло бы верх не собственное эго, а желание создать правильный продукт – это сложная задача, и не всем она под силу.

• бюджет разработки увеличивается во много раз за счет простоя некоторых сотрудников из команды;

• бюджет разработки увеличивается также из-за неправильного подбора персонала и времени, которое тратится на обучение специалистов.

• Предприниматель, руководитель должен быть на 100 % вовлечен в разработку. Но чаще всего у руководителя несколько разных бизнесов или направлений, и поэтому он не в состоянии тратить все свое время только на работу с набранной командой, на один продукт. Это может сказаться на сроках, бюджете и качестве итогового приложения.

Вариант второй. Обращаетесь к подрядчику