Что нужно знать перед заказом разработки

«То, что не записано – не существует.» Главный бухгалтер Почему так важно всё обговорить в мельчайших деталях? Чтобы не остаться в лошках с говносайтом. Как дить видит погремушку, так и заказчик – свой будущий сайт. Или приложение. Что-то цветное, с кнопочками, и чтобы «вот отсюда вот туда переходить». Хотите прибыльный сайт? Читайте статью о том, что нужно знать перед заказом разработки.
опубликовано
14 Августа 2019
читать
6 мин.
комментарии
понравилось
1
На что стоит обратить перед заказом разработки

 

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

 

Итак, какой же минимум знаний вы должны получить?

 

Основа процесса

Представление проекта 

Обычно у заказчика бывает только основной замысел и требования к функционалу сайта. Этого недостаточно и поэтому нужна целостная разработка. В таком случае весь процесс ведется с чистого листа и включает в себя несколько основных этапов.

 

Дизайн

Этап 1 – Дизайн

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

 

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

 

Здесь рассматриваются требования заказчика, определяется функционал и обозначается фронт работ. Требования сводят в таблицу, которая служит основой для разработки интерфейса.

 

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

 

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

 

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

 

Прототип

 Этап 2 – Прототип

Теперь осуществляется разработка прототипа для мобильных устройств. Уточняется информационное наполнение и юзабилити.  

 

Обращаться к разработчику и кодить пока рановато. Только теперь подключается арт-директор, для презентации заказчику интерфейса и логической составляющей проекта. 

 

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

 

Чаще всего, компании для проектирования применяют Sketch, а готовый прототип запускают в Invision. С его помощью можно создать частично рабочий прототип и запустить его на смартфоне либо в интернете.  С его помощью можно подробнее представить визуал проекта.

 

Команда разработки рассматривает объект с позиции архитектуры, а потом корректирует и вносит улучшения в его функционал.

 

Проработка концепции дизайна

 

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

 

Варианты концепции лучше предоставлять последовательно. То есть: выполнили один вариант, получили обратную связь, доработали, отправили снова (до трёх вариантов). 

 

Только теперь можно обрисовать все остальные части проекта, подготовить дизайн, описать функциональное наполнение в ТЗ.

 

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

 

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

 

Разработка приложения

 Разработка приложения

Чаще всего используют два метода: Waterfall (последовательная работа) и Agile (гибкая работа).  Если работать последовательно, то разработка проекта делится на несколько частей.  В конце каждой из них проводится промежуточное тестирование.

 

Если проект разрабатывается гибким методом, то результаты показывают после 2-х недельной работы. 

 

Тестирование и отзыв клиента

 

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

 

 

Что стоит запомнить

 

Если этот проект — первый, то всегда надо быть готовым к рискам. Это лучше учитывать при планировании сроков. 

 

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

 

Нужно помнить, что на этапе составления концепции дизайна возможно понадобится адаптация под различные ОС.

 

Проект вносится в Play Market и App Store, для которых требуются дополнительные опции, только после обсуждения с заказчиком. Это стоит заранее обсудить с разработчиком.

 

Android-приложения проходят обзор почти в этот же день, а ревью IOS может длиться более недели. 

 

Какие риски

 

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

 

Увеличение расходов

Увеличение расходов 

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

 

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

 

Разочарование в результатах

 

Задачи, поставленные перед разработчиками могут быть не выполнены по разным причинам. Например, недоговоренность в ключевых моментах ТЗ.

 

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

 

Задержка дедлайна

 

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

 

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

 

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

ТЕГИ

Похожие записи