Кто нужен для создания приложения

Каких тех. специалистов необходимо нанять в стартап для разработки мобильного приложения?

Здравствуйте. Подскажите, пожалуйста, сколько и каких именно специалистов обычно нанимают стартапы для разработки мобильного приложения под iOS и Android, если в команде нет CTO? Функционал приложения напоминает гео-мессенджер. Как я понимаю, для разработки нужен obj-c, java программисты и человек, который напишет серверную часть? Или обычно всё пишут только 2 программиста?
Заранее спасибо!

• Вопрос задан более трёх лет назад
• 12031 просмотр

Комментировать
Решения вопроса 1

Дмитрий Энтелис @DmitriyEntelis
Думаю за деньги

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

В общем же случае (если речь идет про нативные приложения), роли в команде такие:

1. тот кто будет писать тз (product manager)
2.1 тот кто будет делать дизайн (ux дизайнер)
2.2 тот кто будет делать графику/иконки (дизайнер-иллюстратор)
3. разработчик серверной части (язык по вкусу, мейнстрим php/ruby/java )
4. разработчик мобильной java для приложения под android
5. разработчик objective c / swift для приложения под ios
6. тот кто будет тестировать приложения/сервер

Как это все ложится на живых людей — зависит от их квалификации, сроков и объема задач.

Ответ написан более трёх лет назад
Нравится 11 4 комментария
danyakov @danyakov Автор вопроса
Спасибо за ответ!

Как и 1,3,4,5 — вполне жизненная ситуация.

Дмитрий Энтелис @DmitriyEntelis

Ситуации когда один и тот же человек делает тз, сервер и мобильные приложения на 2х платформах — бывают конечно, но заставляют вспомнить старый анекдот:

Встречаются два друга:
— Как дела?
— Да вот, основал новый стартап, очень быстро растём, развиваемся.
— Круто! А в чём суть стартапа?
— Я провёл исследование рынка и решил публичный дом открыть.
— Ого, интересно, и какие цены?
— Анал — $100, орал — $50.
— А классический секс?
— Понимаешь, с этим труднее. это ж стартап. В общем, я пока один работаю…

А если серьезно, если это все делает один человек — то априори:
а) квалификация в каждой из областей ниже чем у узкого специалиста
б) там где 3 програмиста потратят 2 календарных месяца (6 человекомесяцев), широкий специалист потратит минимум 9,- получится и дольше и дороже.

Одна голова хорошо, а 3 лучше (c)Змей горыныч

Дмитрий Энтелис: Априори, если только ограничиваться крупным проектом и примерно одинаковой квалификацией команды. Если есть разница, то это правило не работает. Моя практика показала, что в некоторых ситуациях найм дополнительных разработчиков только затягивает проект. То что одним могу сделать X часов, выходило X +- 30% и не за счет постановки задачи, а из-за неэффективности нанятого человека. Ситуация повторялась 4 раза, в итоге отказался от такой затеи. Можете возразить, что надо нанимать более квалифицированных людей. Да, конечно. Только вот тогда для меня проект становится финансово не интересным. Да и опять таки практика показала, что таким людям больше интересен Enterprise и делают они маленькие проекты для развлечения с соответствующим отношением. Опробовано на 3 людях.

Ответы на вопрос 4

full stack developer

В решении вам правильно про СТО и роли рассказали.

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

Как я вижу, например:
2 дизайнера будут стоить например, 1500*2 = 3к в месяц
1 дизайнер, но со всеми овертаймами = 1500 + (8 * 1500/20 * 2) = 2.7к в месяц.

Конечно нельзя овертаймить много и долго, люди перегорают, поэтому нельзя 2.7к умножить на 12 месяцев :), но для начала, почему бы и нет. (И как всегда не забываем, что помимо сухих цифр, есть еще куча факторов)

Поэтому реальный минимум можно сократить до:
1. СТО, он же программист (неважно куда его бекенд\под платформу)
2. еще один программист (на него основная нагрузка по разработке, СТО просто закрывает «дыры»)
3. Дизайнер (все будет делать, иконки — вообще купить можно)
4. Тестировщика, можно брать подешевле, но это уже решит СТО (если все покрыто модульными, интеграционными, системными, [ненужное выкинуть] тестами, то можно экономить)

Далее, еще варианты посокращать:
Дизайнера аутсорсим, в команде не держим (конечно зависит от специфики, сколько вам графики нужно)
Тестировщика тоже можно аутсорсить, перед релизом. (опять же depends on)

П.С. готового рецепта нет, я работал в коммандах с 2 Бизнес-аналитиками, и с более чем десятью. На что прежде всего «давить» — решаете вы, и лучше после того как наймете СТО.

Команда для разработки мобильного приложения

Мобильные приложения — незаменимый инструмент для роста и развития бизнеса, сегодня это уже не приходится никому доказывать. Для создания качественного приложения стоит обратиться к толковым разработчикам, это очевидно. Но кто же конкретно будет задействован в реализации вашего проекта? Какова ваша роль в этом процессе? И кто за что отвечает? Давайте же разберемся, кто входит в команду разработки мобильного приложения.

Состав команды и роли участников

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

Со стороны компании-разработчика:

• бизнес-аналитик;
• маркетолог;
• менеджер проекта;
• дизайнеры;
• программисты;
• тестировщики.

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

Со стороны компании-заказчика:

• собственник компании;
• технический директор;
• директор по маркетингу;
• менеджер по диджитализации.

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

Распределение ролей в современной IT команде

Но какая сторона за что ответственна? Если максимально упростить структуру, то заказчик отвечает за идею, а разработчик — за ее реализацию. Но на самом деле все не так просто. Давайте последовательно рассмотрим все этапы разработки и то, кто какую роль выполняет на каждом из этапов.

1. Исследование. Прежде, чем приступить непосредственно к разработке, нам нужно изучить бизнес клиента. Это помогает глубже понять потребности и задачи, которые нужно решить с помощью будущего инструмента. Только так клиент может получить максимально ценный продукт. Роль команды разработчика здесь — максимально погрузиться в бизнес клиента, разобраться в нем, понять потребности, преимущества, слабые стороны и определить, какое решение необходимо. Роль команды заказчика — помочь разработчику, предоставляя всю необходимую информацию, знакомя с процессами, отвечая на вопросы и участвуя в мозговом штурме по генерации решений и идей.
2. Составление технического задания. Этот этап позволяет оформить все задумки и идеи так, чтобы разработчикам было максимально конкретно понятно, что и как нужно реализовать. По поводу ролей на этом этапе мнения расходятся: некоторые считают, что ТЗ полностью предоставляет сторона заказчика, другие же, наоборот, оставляют создание этого документа своим бизнес-аналитикам. Мы же всегда помогаем нашим клиентам на этом этапе, поскольку здесь точность требований важна также, как и техническая достоверность, которой иногда может не хватать клиентам.
3. Проектирование. Здесь создается структура, архитектура, логика работы будущего приложения, продумывается пользовательский опыт и проектируются все пути взаимодействия. На этом этапе важно учесть все задачи и цели приложения, сделать их реализацию максимально удобной для пользователей. Это по большей части техническая задача, потому ложится на плечи разработчиков. Ваша роль в этом этапе — утвердить окончательный вариант, а также вносить правки, если какой-то элемент вас не устраивает.
4. Дизайн. Пришло время оформления внешнего вида вашего будущего приложения. И здесь ваша роль чрезвычайно важна. В первую очередь вам необходимо предоставить примеры и антипримеры для дизайнеров команды разработки, чтобы им было от чего отталкиваться. Постарайтесь максимально точно описать, каким именно вы видите будущее приложение. Дизайнеры создают несколько вариантов оформления интерфейса, а вы выбираете из них понравившийся и вносите правки в случае необходимости.
5. Разработка. Это этап непосредственной реализации приложения, который полностью ложится на плечи команды компании разработчика.
6. Тестирование. Этап проверки качества и соответствия всем требованиям программного продукта. Каждая компания-разработчик привлекает своих QA специалистов прежде, чем отдавать продукт заказчику, и ваша задача в этом случае — только проверить отчетность и принять продукт. Но также возможно привлечение сторонних тестировщиков, а также бета-тестирование с участием сотрудников компании заказчика. В таком случае организация этих процессов ляжет на ваши плечи.
7. Запуск приложения — это тоже зона ответственности разработчиков.
8. Продвижение и маркетинг. Этот этап не является необходимым элементом разработки, поэтому здесь распределение ролей зависит от ваших решений. Возможно, у вас в компании есть специалисты по маркетингу, которые займутся продвижением продукта. Если же нет, мы всегда предлагаем такую услугу нашим клиентам. Если же в компании, которая разрабатывает вам приложение, такой услуги нет, для этого всегда можно найти еще одного подрядчика.

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

Техническая команда для разработки мобильного приложения

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

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

Бизнес-аналитик

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

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

Маркетолог

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

Также маркетологи задействуются для построения стратегии развития вашего продукта и, возможно, всей компании, а также для пострелизного продвижения приложения.

Дизайнер

Над проектом может работать как один дизайнер, так и целая команда. На плечи таких специалистов ложатся целых два этапа разработки: и проектирование, и непосредственно дизайн. Задача дизайнера — обеспечить безупречный опыт пользователя, а также транслировать ценности бренда через дизайн, способствовать тому, чтобы пользователи приложения совершали целевые действия.

Команда программистов

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

Тестировщики

Количество людей в этой команде также варьируется в зависимости от масштабов проекта, но задачи остаются неизменными: убедится в отсутствии ошибок и “косяков”, обеспечить качество продукта, удостовериться, что все требования клиента выполнены. Многие ошибочно полагают, что тестировщики вступают в игру уже после окончания разработки. На самом же деле гораздо рациональнее тестировать продукт по ходу разработки: это сокращает общие затраты времени, упрощает устранение ошибок.

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

Последний, но не по значимости, участник процесса разработки — руководитель, или менеджер проекта. Это человек, который контролирует все процессы, следит за выполнением обязанностей каждого из специалистов, а также за графиком, чтобы команда укладывалась в согласованные сроки разработки. Также руководитель ответственен за организацию коммуникации между разработчиками и представителями компании заказчика. Часто менеджер проекта, помимо организационных функций, помогает или выполняет функции других участников процесса, чаще всего — аналитические.

Риски и их устранение

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

1. Нехватка коммуникации. Коммуникация между членами команды — ключевая часть процесса, ведь только так можно собрать все разрозненные блоки работ в единое целое. И чтобы это целое работало правильно, коммуникация должна быть своевременной, эффективной и понятной. Последствия, как и уровень их критичности, могут быть разными: дублирование задач, недостаток знаний или снижение продуктивности. Решить такие проблемы помогут регулярные собрания, где будут подводиться итоги текущего этапа или спринта, а также разобраны все вопросы, которые есть у каждого из членов команды.
2. Слабая коммуникация между клиентом и разработчиками. Как бы эффективно не велась разработка, без связи с клиентом есть риск того, что продукт в итоге не попадет в цель. Как минимум, он не будет сдан вовремя из-за медленного принятия решений, или мотивация и вовлеченность команды существенно снизится. Чтобы этого избежать, мы всегда заранее планируем два типа встреч с клиентом: регулярные, для ведения отчетности и сверки актуальности всех данных; и целевые, для решения конкретных задач: составить ТЗ, выбрать вариант дизайна и так далее.
3. Незапланированное отсутствие члена команды. При определении сроков на разработку всегда закладывается определенное время на возможные отпуски и больничные сотрудников. Но всегда существует риск того, что кто-то из команды сойдет с дистанции на более продолжительный срок, или по какой-либо причине вообще покинет проект. В таком случае важно предусмотреть возможность замены сотрудников. В первую очередь, это взаимозамена внутри команды, чтобы при отсутствии одного сотрудника, остальные подхватывали его задачи. В нашей компании мы предусматриваем возможность замены сотрудника другим, чтобы в случае ухода члена команды проект не пострадал.
4. Недостаточная вовлеченность. Эта проблема грозит задержками при разработке, снижением качества продукта, и возможно даже уходом сотрудника. Такая проблема может возникнуть, если сотрудники не видят отклика от руководства и клиента, а также при плохой коммуникации. Что делать с последней — мы уже разобрались. Что касается отклика, здесь важно будет ваше понимание того, что вы также являетесь частью команды. Ведь ваша вовлеченность — наилучший пример и стимул для остальных участников.

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

Создание мобильного приложения

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

• Команда. Для разработки качественного мобильного приложения нужна команда из 4–7 человек, в отличие от сайта, который сегодня можно сделать самому. Большая команда требует умного управления.
• Конкуренция. В мире выпускается сотни миллионов приложений ежегодно. И команды, и проекты с каждым годом становятся все сильнее.
• Финансирование. Высокая конкуренция требует постоянной и кропотливой работы по выводу мобильного приложения в топ в тех или иных категориях. Умножьте это на стоимость команды из 5 человек и вы получите немаленький бюджет. Разумное распределение бюджета — один из ключей собственного спокойствия.

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

И так, у вас есть идея мобильного приложения. С чего начать, чтобы не потерять все свои деньги, настроение, работу?

Друзья мои! Это 30 минут вашего времени, которые спасут вашу работу, ваших близких и вашу жизнь. Ваши нервы скажут вам спасибо, ваши родные будут счастливы и не сдадут вас в больницу. В общем, 30 минут вашего времени и вы узнаете ответы на множество вопросов. Эта финансовая стратегия вашего мобильного приложения — ваш первый документ. Поздравляю!

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

Финансовая стратегия

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

Поехали. Открываем файл MS Excel и записываем в строчках:

1. Измеряем объем целевой аудитории:

• страны, на которых стартуем, в штуках (например, если вы решили стартовать в Ботсване, а потом захватить остальной мир — ставьте true);
• общее население, человек (себя можно не учитывать);
• целевая аудитория, % от населения (самый простой способ — проанализировать поисковые запросы);
• целевая аудитория, человек (можно общее количество поисковых запросов разделить на 10).

2. Затраты на привлечение (сами к вам придут только в случае революционного изобретения):

• планируемое количество пользователей, через органический трафик (это когда пользователи сами нас находят, но для этого надо попотеть — конкуренция, помните?), человек;
• стоимость органического трафика (учитываем стоимость оптимизации названия и описания по поисковым запросам, это примерно 300 USD), USD;
• планируемое количество пользователей, через платное привлечение (стоимость покупки трафика — быстрая проверка гипотез), человек;
• стоимость платных пользователей (исходите из примерной 0,5 USD за одного), USD;
• партнерские программы (если у вас есть партнеры, которые не отвернуться от слова стартапер), USD;
• итого бюджет привлечения пользователей (это первая статья расходов), USD.

3. Бюджет на разработку:

• дизайнер, часы (тут надо учесть больше вначале и меньше в дальнейшем);
• разработчик серверной части, часы (это если у вас чат, или вы хотите обновлять содержание приложения);
• разработчик мобильного приложения Android, часы;
• разработчик мобильного приложения iOS, часы;
• тестировщик, часы;
• управление проектом, часы;
• аналитик, часы;
• цены за человеко-часы специалистов (лучше на отдельном листе);
• итого бюджет на разработку (часы умножить на цены), USD.

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

4. Объем поступлений (если у вас модель — заработка, а не продажи проекта):

• выручка от одного пользователя, USD (помним, что только 2% ваших пользователей захотят заплатить за сервис);
• итого выручка, USD ().

5. Воронка активации пользователей (это все действия от мысли о вас до ключевой/целевой активности пользователя):

• объем целевой аудитории, человек;
• заходов на страницу, человек;
• конверсия в зашедших на страницу, %;
• установивших мобильное приложение, человек;
• конверсия в установивших, %;
• активация (зарегистрировались, оплатили, добавили в друзья, написали в чат и др.), человек;
• конверсия в активацию, %.

6. Показатели проекта (руководствуемся правилом «ни много ни мало»):

• однодневная конверсия, %;
• тридцатидневная конверсия, %;
• количество регистраций, пользователей;
• среднее количество сообщений на одного пользователя;
• количество сессий;
• средняя длина сессии.

Это все первая колонка. Следующие колонки должны содержать этапы: проектирование, разработка, запуск, сопровождение по месяцам. Показатели план/факт. В итоге у вас должна получится вот такая таблица:

Рисунок 1. Финансовая стратегия мобильного приложения.

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

Ах да. Где взять деньги? В первую очередь ищите среди знакомых — друзья, дураки, семья. Не забывайте составлять акционерное соглашение. Если у знакомых нет — вот ссылка на фонды посевных инвестиций.

Появилась идея для проекта? Мы хотим узнать о том, что важно для вас

Разработка мобильных приложений на заказ — профессиональное воплощение ваших идей

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

Почему стоит заказать разработку приложения у профессионалов?

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

Фрилансер — для тех, для кого главное — низкая стоимость

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

В профессиональной разработке приложения на заказ участвует от трех до пяти типов специалистов:

• менеджер проекта (тот, с кем заказчик общается непосредственно, кто ведет документальное сопровождение проекта, занимается финансовыми вопросами, вопросами соблюдения сроков и условий договора. Тот, кто разговаривает с заказчиком на его языке, а с командой — на их)
• дизайнер (как правило, приложение на заказ имеет уникальный брендированный дизайн)
• верстальщик (корректное отображение на различных типах устройств и операционных системах)
• программисты (создание серверной части, интеграция, программирование интерфейсов)
• маркетолог (разработка концепции продвижения)

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

Конструкторы готовых приложений — для тех, у кого простой прооект и нет требований к уникальности

Если да, то это значит, что

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

Так, что если вы видите предложение по разработке, типа «всего 14990 рублей» — скорее всего, это что-то совсем простое (не исключено, что вам подходит).

Веб-студии неполного цикла — для несложных типовых решений

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

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

Веб-студии полного цикла — для сложных ответственных объемных проектов

Здесь стоимость разработки начинается от 150 тысяч (сервер + 2-3 типа экрана) и доходит до нескольких миллионов рублей. Порядок стоимости зависит от сложности проекта, от репутации и местонахождения компании-разработчика и от размера бизнеса заказчика. Большие бюджеты — высокий уровень сложности программирования, искусный дизайн, скрупулезная проработка деталей и большая ответственность. Вашим приложением будет заниматься профессиональная команда, к которой вы сможете предъявлять высокие требования и ожидать самого высокого качества исполнения. Такое мобильное приложение будет разительно отличаться от тех, что представлены на маркетплейсах, привлекая к вашему бизнесу сонмы лояльных клиентов.

Что входит в профессиональную разработку приложений на заказ?

Профессиональная разработка мобильных приложений на заказ состоит из следующих этапов:

1. Анализ бизнес-идеи заказчика. Сведение всех его требований и пожеланий в техническое задание.
2. Проектирование полноценных прототипов интерфейсов. Распределение функций по экранам, подготовка макетов, определение элементов управления.
3. Разработка дизайна приложения, создание графики, сочетание стиля и удобства использования.
4. Утверждение с заказчиком сетки, цвета, шрифтов, фона. Изготовление чистовых макетов.
5. Верстка, программирование. Тестирование и отладка до получения запланированного результата.
6. Если заказ включает разработку приложения под iOS и Andriod, адаптация проекта под сторую платформу.
7. Техническая поддержка приложения. При желании клиента может производиться доработка проекта по новым функциям.

Почему мы советуем обратиться за разработкой приложений на заказ к нам?

1. Работаем в Екатеринбурге с 2013 года: за пять лет успешно выполнено более 50 различных проектов.
2. У нас молодая, но уже достаточно профессиональная команда. Опыт, навыки и эстетический вкус наших специалистов позволяют прекрасно справляться с поставленными задачами.
3. Предлагаем актуальные решения по разработке мобильных приложений на заказ. Используем в работе принципиально новые подходы и передовые технологии.
4. Ответственно работаем с каждым клиентом, предлагая в итоге тщательно продуманный и хорошо отлаженный продукт.
5. Не завышаем цены и гарантируем качественный результат.

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