Мобильное приложение как инструмент бизнеса

Создание практически любого приложения начинается с чистого листа. Разработчик может использовать готовые элементы из прошлых работ, но их очень мало и они редко подходят для других типов проектов (если только речь не идет о сотнях похожих приложений, как у нас было с салонами красоты). Весь программный код, дизайн, звуки – все создается заново. Отчасти поэтому сложно не только определить сроки выполнения заказа, но и установить цены за работу. Разработчик, даже несмотря на детальное ТЗ, все еще плохо представляет, какими способами получится все это реализовать и что получится на выходе. Многие из пунктов ТЗ и договора заказчик обязательно будет трактовать так, как ему выгодно или захочется, что в результате приведет к изменениям в приложении.

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

«А как же фреймворки, библиотеки и готовые куски кода из прошлых работ?» – спросит опытный заказчик. А так, что это все равно придется приспосабливать под нужды нового проекта. Да, готовый код облегчает разработку, но вы не сможете использовать фреймворк без тщательной подгонки под проект, то есть разработчику все равно придется изрядно потрудиться.

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

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

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

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

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

Многие используют user story, тщательно разбирая поведение пользователя, порядок его действий, перемещений и функции, которыми он будет пользоваться. Для этого создаются несколько выдуманных пользователей, каждый из которых хочет решить конкретные проблемы. Разработчики продумывают весь путь пользователя от загрузки приложения до решения своих проблем и пытаются понять, как его можно улучшить с точки зрения простоты для пользователя и реализации целей заказчика. Лучше сразу подключать к работе заказчика или его представителя, отлично знающего целевую аудиторию и результат, которого заказчик ожидает от выпуска приложения. Также необходимо подключать разных специалистов, в том числе программиста и дизайнера.