Чтобы все получилось
Сначала - функциональные требования. Список того, что и как должно делать приложение. Пишем пользовательский сценарий, рисуем UI, проектируем и реализуем API, создаем бэкенд, тестируем его, делаем админку, разрабатываем мобильные клиенты, снова тестирование и подготовка к публикации.

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

Плохая новость состоит в том, что работать все-таки придется.
1
Начать придется со скучного. С описания функций приложения сухим протокольным языком. Если описать функции не получается - можно просто описать действия пользователя в стиле "нажал - получил".
В результате должен получиться текст или блок-схема, которая описывает главные функции приложения.
Крайне важно зафиксировать этот документ, поскольку именно на основании его вы будете принимать выполненную работу. А для нас он основа чек-листа функционального тестирования.
2
После того, как вы (или мы вместе) составили и утвердили документ, можно переходить к техническим требованиям. Если вы планируете развивать проект своими силами логично указать требования к инструментам разработки, платформам, фреймворкам, и тд.
3
А теперь мы возьмем проектировщика и дизайнера и поставим им задачу нарисовать UI - собственно интерфейс приложения. Главный экран, меню, структуру, основные функции, предупреждения, алерты..
Самое главное помнить, что мы не просто рисуем кнопочки, мы ведем диалог с пользователем. Каждый экран и каждое взаимодействие должны создавать или продолжать историю, в которую мы погружаем пользователя.
Виктория Кисельник
Дизайнер
4
После того, как мы нарисовали основные экраны и сделали блок-схему - мы начинаем проектировать API. Только теперь нам понятно, что, в каком виде и в какой последовательности мы должны получать от сервера, что ему отдавать и что делать, если что-то пойдет не так, например, пропадет сеть.
5
После того, как мы реализовали API и проверили его работоспособность мы можем собирать собственно мобильные клиенты. То, что сделал дизайнер теперь уходит клиентскому разработчику.
Собирать мобильный клиент без подключения к серверу не имеет смысла.
Денис Прокопчук
iOS разработчик
Собственно, разработка мобильного приложения и интеграция его с сервером в большинстве случаев - одно и то же. Именно тут происходит интеграция с внешними сервисами - социальными сетями, платежными системами, системами аналитики и трекинга. И с внутренними - собственным сервером.
6
ЕСли вам нужно сделать приложения для 2-х платформ - iOS и Android - лучше вести разработку последовательно. Как это ни странно выглядит, но срок разработки увеличивается незначительно, а стоимость падает.
Неправильно одни и те же ошибки править дважды.
Артем Кириллов
Android разработчик
8
И наше любимое: статистика и трекеры. Когда вы выпустите приложение, крайне важно понять, что именно будут делать в нем пользователи, откуда они будут приходить, в какие деньги обходиться, как долго оставаться, как часто использовать его. На эти и другие вопросы нам ответят Crashlitycs, AppsFlyer, Installtracker, Google Analitycs.
Если вы ничего не знаете о ваших пользователях - вы зря тратите деньги.
Константин Кононов
Директор
9
И наконец, тестирование. Оно бывает 2-х видов - функциональное и нефункциональное. Если коротко и просто - мы делаем с приложениями все, что может прийти в голову пользователю и то, что прийти не может. Начинаем с функционального, опираясь на документ, который сделали в самом начале, потом переходим к нагрузочному, проверкам стабильности и надежности и др.
И вот теперь, по завершении этого этапа ваше приложение готово к публикации в сторах, можно завоевывать мир и зарабатывать миллионы, как вы и собирались.
Made on
Tilda