Существует множество подходов к разработке цифровых продуктов, будь то сайты, мобильные приложения, CRM или ERP-системы. Мы в Terabit Digital, придерживаемся подхода, согласно которому работа над проектами делится на несколько крупных этапов:
— подготовка;
— проектирование;
— разработка и тестирование;
— внедрение и сопровождение.
Что это дает, как позволяет экономить время и деньги заказчиков —рассказываем в этой статье.
Подготовка
На подготовительном этапе проводится работа по погружению команды разработчика в вашу предметную область. Она должна понять все бизнес-процессы, оценить рынок и конкурентов, понять, что вы, как заказчик, хотите от продукта. На основе собранной информации определить высокоуровневые требования к продукту, а затем детализировать их: определить какая команда понадобится, какой стек технологий и так далее.
Важно понимать, что закрывать данный набор компетенций может разное количество сотрудников: иногда достаточно сильного project-менеджера, а иногда не обойтись без полноценного маркетолога-аналитика.
Проектирование
Этап проектирования — самый важный. Он подразумевает наибольшую вовлеченность и высокий уровень коммуникации со стороны заказчика. Именно здесь идея впервые становится осязаемой. Пропустив его, можно совершить много ошибок в дальнейшем, которые в общем виде будут сводится к:
— отсутствию понимания, куда идет проект;
— кратному увеличению стоимости разработки конечной версии продукта, из-за необходимости внесения каскадных изменений в проект;
— отсутствию контроля за сроками вывода продукта на рынок;
— высокому риску получить продукт, который никому не нужен.
Этап проектирования включает в себя:
— формирование структуры проекта;
— разработку формализованного прототипа;
— дизайн;
— написание технического задания.
Разработать проект, также как и построить дом — невозможно без плана. Как архитектор закладывает в плане здания высоту стен, количество этажей, так и разработчики определяют то, как будет выглядеть будущий сайт или мобильное приложение через структуру и прототип.
Прототип — это эскиз, схематичное изображение структуры вашего сайта. Он помогает создать некий каркас, который будет наглядно демонстрировать все необходимые разделы будущего проекта, блоки страниц и так далее. Он также может частично или полностью имитировать работу интерактивных элементов.
Этап прототипирования позволяет учесть все важные блоки и функционал, и если чего-то не хватает — тут же внести. Если этот этап пропущен, то вносить изменения приходится уже на этапе разработки, а это всегда намного дороже. Таким образом, прототип не увеличивает объём работ, а уменьшает его, экономит ваше время и деньги.
Все работы по дизайну начинаются с главной страницы — она ключевая. После того как сформировано понимание, как будет выглядеть общая стилистика дизайна главной страницы, визуальное решение переносится на внутренние. Обязательно для сайта адаптируются элементы фирменного стиля клиента.
Техническое задание часто путают с описанием функциональных требований.
На самом деле, составление технического задания включает в себя все процессы: создание прототипа и описание его логики, дизайна и анимации, описание, того как весь функционал должен работать.
Техническое задание — сложный, многосторонний документ, объем которого может достигать 100 страниц и более, в зависимости от сложности проекта. Его сложно подготовить человеку, без соответствующих компетенций. Поэтому мы никогда не требуем его от заказчика, а составляем сами.
В течение всего этапа проектирования заказчиком готовится контент и необходимые базы данных — с ними можно переходить к этапу разработки продукта.
Разработка и тестирование
На данном этапе происходит разработка frontend и backend-частей проекта. Теоретически лучше, когда обе части разрабатывает один человек, так как при таком подходе коммуникации становится меньше. Но проблема в том, что если проект большой – то один человек будет делать его очень долго, кроме того, ему может не хватать компетенций по одному из направлений. Чем сложнее проект, тем больше компетенций требуется от сотрудника, а сильных full stack-разработчиков найти сложно.
Frontend – это браузерная часть, то, что видит пользователь и с чем взаимодействует. Если говорить простыми словами, не углубляясь в технические детали, то frontend включает в себя интерфейс и некую промежуточную часть, которая связывает интерфейс и backend-часть.
До начала работ вам важно познакомиться с командой и с ее внутренними процессами: спросить, где и как ведется разработка, попросить показать систему управления проектами, и так далее. Если команда не может даже рассказать, как выстроен процесс работы над проектом – стоит задаться вопросом, а можно ли с такой командой работать? Или если, например, выясняется, что команда не использует средства версионирования кода (например, Git) – то от нее вообще лучше сразу бежать.
Как заказчику понять, что frontend-часть реализована качественно? Есть несколько способов:
– ручное тестирование – самый очевидный способ, заказчик сам оценивает интерфейс, с позиции пользователя;
– автоматизированные средства анализа. Например, сервис PageSpeed Insights от Google, где можно вставить ссылку на интересующий вас ресурс и получить рекомендации по его оптимизации.
– сторонние аудиторы – нормальная практика на больших проектах и сильная команда разработки только приветствует их.
Верстка и дизайн должны совпадать максимально – обратная ситуация сигнализирует о проблемах. В целом, плохая практика, когда верстальщик меняет дизайн на свое усмотрение, так как ему со своей стороны сложно оценить, как изменения в итоге отразятся на всем проекте. Если вас пытаются убедить в обратном – имеет смысл настаивать на доработках.
Время, которое занимает разработка frontend-части, сильно варьируется от проекта к проекту. У одного проекта может быть простой визуал, но сложный backend, у другого наоборот красивый нестандартный дизайн, при простом функционале. В целом, уникальный, сложный дизайн всегда будет разрабатываться дольше.
Backend – это часть, где содержится бизнес-логика и хранятся данные проекта.
Что в данном случае подразумевается под бизнес-логикой? В любом проекте, так или иначе, мы реализовываем какие-то пользовательские сценарии.
Пример: покупатель в интернет-магазине бронирует заказ – далее система проверяет, есть ли товар на складе – если да, то формируется заказ, если нет, то пользователю направляется соответствующее уведомление.
Такие сценарии являются по сути бизнес-правилами, которые определяет сам бизнес и по которым в итоге будет работать вся система проекта.
Как определить качество backend-разработки? Сделать это труднее, так как напрямую вы эту часть не видите, но есть косвенные признаки, на которые можно ориентироваться.
До начала работ вам стоит:
– посмотреть, как составлено техническое задание;
Если оно составлено как попало, с ошибками и нарушением логики, то и проект по нему будет реализован также.
– посмотреть кейсы разработчика;
Если у команды нет релевантных кейсов, то это несет дополнительные риски. Нет кейсов – нет соответствующего опыта у сотрудников, которые будут работать над проектом.
– расспросить про внутренние процессы;
Задавать вопросы – нормальная практика заказчика. Если вам не могут рассказать, какая команда будет работать над вашим проектом, почему выбран тот или иной язык программирования и так далее, то это триггер, который должен насторожить. Помните, в хороший процесс разработки ввести заказчика в качестве наблюдателя не сложно.
Важный параметр – выбор стека технологий, на котором будет реализовываться проект. Важно выбирать тот, который максимально подходит под задачи заказчика. Например, мы в Terabit Digital никогда не делаем на конструкторах уникальные проекты, с перспективой дальнейшего развития. Мы понимаем, что в противном случае рано или поздно упремся в ограничения в виде:
– сложности реализации доработок;
– сложности поддержки.
Любой проект нужно поддерживать и, будем честны, команды меняются. Если проект написан на непопулярном языке, то найти для него новую команду будет сложнее. Также нужно смотреть среднюю стоимость часа разработки по выбранному языку: чем она выше, тем выше стоимость проекта в целом и его поддержки в дальнейшем.
Иногда для сложных проектов приходится использовать сложные языки, так как просто нет другого выбора – но это скорее исключение из правила.
Оценить качество разработки на финальном этапе поможет тестирование.
Тестирование
Объем тестирования определяется исходя из того, какой функционал главный. В этом смысле в обязательном порядке нужно покрыть главные сценарии.
Необязательно для тестирования нужен полноценный отдел, но на масштабных проектах сложно представить работу без него. Количество тестировщиков зависит от проекта и его качества. Например, у финтех проектов и прочих отраслей, работающих с деньгами – высокий уровень тестирования, на котором заказчики не экономят.
В зависимости от масштаба продукта время на этот этап составляет 10-15% от времени разработки frontend и backend-частей.
Внедрение и сопровождение
Важно отметить, что веб-студии и digital-агентства должны использовать DEV-серверы и только на завершающем этапе работ переносить весь проект на рабочий домен клиента.
Также на данном этапе можно заключить договор с компанией-разработчиком на дальнейшее техническое сопровождение уже реализованного проекта.
