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

Без проекта разработчики не будут точно знать, что им и как делать. Если вам встретится разработчик, утверждающий, что «им это не нужно» или «это пустая трата денег», сразу с ним прощайтесь. Можно ли создать автомобиль, самолет или даже смартфон без проекта и продумывания всех этапов работы и взаимодействия специалистов? Конечно, нельзя. В этом плане разработка мобильного приложения не исключение.

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

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

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

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

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

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

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

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

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

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

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

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