Минимум, в котором лучше разобраться перед заказом разработки

Общий процесс разработки проекта

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

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

Первый этап - проектирование и разработка дизайна. При произнесении слова “проектирование”, в голове клиента часто возникает картинка, в которой команда разработчиков, надев каски, стоит над чертежами здания с глубокомысленным видом. На этом обычно понимание этапа и заканчивается. На самом деле все обстоит несколько сложнее.

Рассказывая клиенту про проектирование, всегда стоит упоминать, что именно на этом этапе закладывается самый приоритетный и сложный для разработки функционал. Если не вгрызаться в эту тему глубже сейчас, то она так и останется только красивыми словами, - что, естественно, не нужно ни разработчику, ни клиентам.

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

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

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

Для салона красоты модель Убера может и не сработать.

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

Прототип

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

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

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

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

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

У нас в компании для проектирования мы используем Sketch, а готовый прототип заливаем в веб-сервис Invision, который позволяет создать кликабельный прототип, установить его на телефон или открыть в вебе и более подробно визуально представить идею клиенту. Этот набор сервисов в данном случае не обязателен, но мы бы рекомендовали работать с ними, - функционал простой и удобный.

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование и ревью клиента

Но и окончание разработки - это еще не все!

По завершению процесса разработки проект переходит в стадию тестирования и отладки, которая может занимать от недели и больше. И только после тестирования проект передается на ревью клиенту.

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

Важно помнить!

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

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

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

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

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

Важно помнить, что Android-приложения проходят ревью практически в этот же день, iOS ревью занимает больше времени - от 1 недели и выше. Только после этого приложение появляется в сторах. В декабре время публикации приложения может увеличиться из-за новогодних каникул, поэтому этот момент лучше планировать заранее.

Какие риски могут возникать на проекте по разработке

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

Некоторые риски со стороны заказчика:

1. Расходы растут

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

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

2. Полученный результат не устраивает.

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

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

3. Сроки выполнения.

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

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

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

Если вы прошли все пункты, что перечислены выше - вы уже вышли на нужную дорогу. Предотвращение рисков всегда начинается с детального планирования и нахождения слабых сторон проекта.