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

Начало

Начало

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

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

Техническое задание описывает только то, как должно выглядеть приложение и что оно должно делать, но не объясняет разработчику, как необходимо разрабатывать приложение – это объясняет описание проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оглавление книги