Читать «Мобильное приложение как инструмент бизнеса» онлайн - страница 93

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

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

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

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

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

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