Подход к работе

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

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

Принципы работы

До начала проекта

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

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

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

Сначала бизнес-задача и данные

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

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

Диагностика текущего состояния

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

• структура сайта, шаблоны и пользовательские сценарии;
• CMS, версии компонентов и индивидуальные доработки;
• база данных, каталог и правила хранения информации;
• интеграции с 1С, CRM, оплатой, доставкой и внешними API;
• хостинг, резервные копии, доступы и тестовая среда;
• аналитика, индексация, ценные URL и поисковый трафик;
• известные ошибки, технический долг и ограничения;
• процесс обновления контента и выпуска изменений.

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

Архитектура и требования

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

Требования фиксируются в объёме, достаточном для текущего этапа. Документ не должен быть формальностью, которую никто не использует, но критичные правила нельзя оставлять только в переписке.

SEO до дизайна и разработки

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

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

Прототипирование

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

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

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

Дизайн-система вместо набора макетов

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

Компонент проверяется в разных состояниях и размерах экрана. В дизайн закладывается реальный объём текста и данных, а не только удобный демонстрационный пример. Редактор должен понимать, какие варианты ему доступны, а разработчик — как компонент ведёт себя при ошибке и отсутствии данных.

Разработка и интеграции

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

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

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

Контроль качества и приёмка

Проверка начинается не в последний день. Критерии готовности определяются при постановке задачи, а тестирование идёт вместе с разработкой. Состав проверок зависит от риска и функции.

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

Контент и перенос данных

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

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

Запуск без потери накопленного

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

1. Проверка готовности. Закрываем критичные замечания и подтверждаем участие ответственных.
2. Резервная точка. Сохраняем данные и состояние, необходимое для восстановления.
3. Выпуск. Переносим код, конфигурацию и актуальные данные в согласованном порядке.
4. Быстрая проверка. Контролируем доступность, формы, заказ, оплату, интеграции и ключевые страницы.
5. Наблюдение. Отслеживаем ошибки, индексирование и реальные операции после запуска.
6. Следующий план. Отделяем дефекты релиза от новых улучшений и расставляем приоритеты.

После запуска

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

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

Роли и ответственность

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

Если участвуют интегратор 1С, хостинг, SEO-команда или другой подрядчик, их зона ответственности и контактные лица также фиксируются.

Коммуникация и решения

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

Количество встреч подбирается под проект. Цель коммуникации — своевременно принимать решения, а не создавать отчётность ради отчётности.

Как управляем изменениями

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

Так проект остаётся гибким, но не теряет границы. Фраза «мы работаем гибко» не должна означать, что результат, ответственность и бюджет меняются незаметно.

Чего мы стараемся не делать

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

Частые вопросы

Нужно ли готовое техническое задание?

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

Можно ли подключиться к проекту, который уже начат?

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

Обязательно ли проходить все этапы?

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

Когда можно назвать срок и бюджет?

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

Как заказчик видит прогресс?

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