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

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

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

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

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

Прозрачное управление задачами

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

Формирование бэклога

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

Реализация задач

Мы работаем спринтами и регулярно отгружаем результаты в ходе проекта. Длительность спринта выбирается в зависимости от среднего объема задач и составляет от 1 до 2 недель.

Техническая схема работы

Мы используем трёхступенчатую структуру поставки изменений dev—stage—prod.

Разработку ведём на dev-площадках, закрытых от сторонних наблюдателей. Тестирование и сдача задачи происходит на stage-площадке — копии боевого сайта, доступ к которой есть у клиента. После приёмки работ происходит публикация на production-среду, с которой работает пользователь.

Настроенные процессы DevOps позволяют реализовать автоматический деплой изменений на боевую и тестовые площадки, автоматическую сборку frontend, версионирование и быстрый откат в случае сбоев, минимизацию времени простоя при релизе.

Протокол релиза

Релиз — это не действие, а процесс. Помимо непосредственно загрузки кода, релиз предполагает другие обязательные шаги и процедуры:

• составление плана релиза (состав и последовательность действий, например, запуск миграций, перезапуск микросервисов, сброс кэша и т.п.);
• публикация результатов спринта на stage;
• тестирование результатов спринта;
• релиз на боевой сайт согласно плану;
• smoke-тестирование проекта;
• актуализация документации и макетов;
• актуализация тест-кейсов.

Управление инцидентами

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

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

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

План реагирования на инциденты

Отчётность и контроль расходов

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

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

План подключения нашей команды к проекту