Ответы на вопросы: часть 4. Параллельная работа над приложением и сайтом

Мы продолжаем отвечать на вопросы наших клиентов. Все ответы можно посмотреть по ссылке. Сегодня мы отвечаем на такой вопрос: «Как проводятся работы, если, кроме приложения, есть еще и веб-сайт?», а также на исходящие из него вопросы.

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

В плане параллельной веб- и мобильной разработки обычно клиентов интересует несколько вещей:
1. Если есть две версии (мобильная и веб), какая из них должна быть главной?
2. Можно ли их разрабатывать параллельно?
3. Если сайт уже существует, а мы хотим, чтобы вы занимались поддержкой и сайта, и будущего приложения, как вы будете это делать?

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

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

  1. Если технического описания веб-версии нет, то оно составляется в обязательном порядке аналитиком.
  2. Аналитик документирует различия между версиями и составляет предложение с обоснованием, какую часть функциональности стоит переносить, а какую — нет, и стоит ли переносимую функциональность каким-нибудь образом модифицировать, учитывая особенности веб как платформы. Финальное решение согласуется с владельцем продукта.
  3. Если у текущей веб-версии нет схемы страниц, то она составляется в обязательном порядке веб-проектировщиком.
  4. Веб-проектировщик вносит изменения в текущую схему, дополняя ее новой функциональностью. Финальное решение согласуется с владельцем продукта.
  5. Если у текущей веб-версии нет UI-кита, то он составляется в обязательном порядке веб-дизайнером.
  6. Веб-дизайнер вносит оформляет измененные схемы страниц в соответствии с решением, использованным в мобильной версии и со существующим UI-китом для веб-версии.
  7. Веб-дизайнер делает подборку графических материалов, необходимых верстальщику.
  8. Аналитик обновляет техническое описание веб-версии, добавляя в него новые материалы и комментарии по их внедрению.
  9. При необходимости серверный программист вносит изменения в бек-енд.
  10. Верстальщик вносит изменения во фронт-енд веб-версии и, при необходимости, административную часть.
  11. При необходимости контент-менеджер осуществляет наполнение веб-версии контентом.
  12. Тестировщик проверяет готовое решение на соответствие с техническим описанием веб-версии.
  13. При необходимости верстальщиком проводится отладка.

Шаги 1, 3 и 5 необходимо проводить только один раз. В последующих итерациях эти документы уже будут готовы для редактирования.