Стратегия работы
Основная стратегия работы была выстроена по методологиям Agile и Scrumfall. Изначально планировали реализацию конкретных задач и этапов, не делили на спринты. Но учитывая, что постоянно происходили изменения, которыми необходимо было гибко управлять, мы каждый раз пересматривали планы работ, их реализацию и вносили изменения в проект, основываясь на том, что новое решение будет гораздо лучше, чем предыдущее. Похожий опыт случился у команды дизайнеров на этапе разработки внутренних страниц, когда они увидели, что изначально сделанная Главная страница сайта значительно уступает последующим и приняли решение о ее редизайне.
Если при review предыдущих шагов оказывалось, что новые решения гораздо круче уже реализованных, мы возвращались к этим этапам и совершенствовали их.
Плюс выбранной стратегии:
- для клиента – четкое понимание что получит и в какие сроки;
- для исполнителя – легкое внедрение любых изменений на любом этапе продакшена.
Этапы работы
Разделили нашу работу на три основных этапа
Верстка
Начали с верстки, пока не набрали критическую массу страниц
Анимация
Отсеяли с заказчиком сложную для восприятия клиентом анимацию и ту, которую сложно адаптировать под разные устройства
Back-end и интеграции
Реализовали 2-х этапную call to action форму, сделали интеграцию с CRM и внедрили записи на звонок
Нельзя сказать, что эти этапы шли друг за другом, скорее двигались параллельно. Например, в какой-то момент мы пришли к тому, что нельзя откладывать реализацию анимации, потому что уже было необходимо начинать back-end разработку.
В процессе верстки мы параллельно запустили back-end, разработку архитектуры и конструктора внутри проекта. Также на протяжении всей работы много внимания уделялось вопросам реализации хранения данных и управления контентом в админке сайта.
По мере роста страниц и понимания как должна измениться архитектура хранения данных внутри админки, мы оперативно обсуждали с клиентом и с командой, какие новые сущности нам нужно определить, а какие дополнить. Одна из сложностей – невозможность изначально запланировать архитектуру проекта. Поэтому мы постоянно занимались рефакторингом архитектурного решения.
Бытовой пример. Возьмем ситуацию, когда к вам пришли строители и сказали: «Вот вам одна комната. Мы предполагаем, что это будет 3-этажный дом, поэтому подготовьте соответствующий фундамент, а мы вам будем отдавать проект по одной комнате».
В какой-то момент комнату вы уже обустроили, а потом оказалось, что там должна появится лестница на 2 этаж или спуск в подвал.
Поэтому на каждом этапе, когда у нас появлялись новые «комнаты», новые «этажи», мы пересматривали подход к архитектуре сайта и вносили точечные изменения. Подготовка на старте позволила нам выбрать такое техническое решение, которое было гибким и легко масштабируемым. Мы изначально организовали внутри конструктор, который вне зависимости от того в этой комнате у нас выход на 2 этаж или в другой, помогал нам быстро вносить изменения. Вместо классической лестницы мы создали трап на колесиках, который при необходимости можно легко передвигать из одной комнаты в другую.
Челленджи проекта
Смена project manager
Проблема: новый человек – новые правила.
Суть. Когда мы узнали, что тот человек с которым мы вели первичную коммуникацию уходит из проекта и приходит другой PM, мы осознавали, что могут возникнуть трудности. С новым человеком в команде нужно заново договариваться, объяснять какие решения уже приняты и какие планы составлены.
Решение. Решение пришло само собой. Новый project manager оказался крутым человеком и классным командным игроком. Также нам повезло, что к тому моменту мы только приступили к разработке ТЗ и успели учесть все моменты.
Техническая адаптация дизайна
Проблема: привлекательные дизайны интерфейсов сложно реализуемы в реальности.
Суть. Когда мы поняли, что дизайнерские идеи сложно реализовать технически, мы искали возможность угодить дизайнерам в их идеях, которые очень нравились клиенту, и при этом подобрать наилучшее техническое решение для реализации. Решение должно быть легким в исполнении, удобным для пользователей и не должно влиять на показатели и скорость работы сайта.
Решение. Мы реализовали несколько вариантов того, как все идеи могли бы выглядеть. Показали их клиенту, обсудили и в итоге от многих вещей решили отказаться. При этом постоянно шла коммуникация с командой дизайнеров. Было необходимо понять, насколько наше решение ломает их видение того каким в итоге должен получиться проект. Мы смогли достаточно быстро и легко договориться и принять общее финальное решение, которое и реализовано по итогу на сайте.
Смена SEO-команды
Проблема: сохранить достигнутые результаты по SEO сайта.
Суть. Самый сложный челлендж – смена SEO-команды. SEO и разработчики редко бывают лучшими друзьями в рабочем процессе. Основная причина раздора – требования по SEO часто кажутся разработчикам вычурными и избыточными. Опытный ПМ должен исключать такие проблемы еще на старте проекта. В нашем случае было подготовлено огромное ТЗ вместе с SEO-командой для клиента и мы от него отталкивались. Но ближе к концу проекта оказалось, что заказчик меняет подрядчика.
Решение. Заново обсуждали и переделывали ту реализацию, к которой мы уже были готовы. Опыт позволял какие-то решения исключать из новых требований по договоренности. Какие-то моменты решились легко и быстро, так как мы предполагали какие запросы будут у новой команды. А вот с некоторыми вещами нам пришлось повозиться. Но в итоге команда заказчика и команда по SEO остались довольны.
Что было важно для клиента
Для клиента очень важна была обратная связь, а также экспертиза специалистов. Ему было необходимо, чтобы его слышали, понимали поставленные задачи, находили решения для их реализации либо предлагали лучшую альтернативу. Поэтому каждый этап работы обсуждался с клиентом: что конкретно он хочет, как это должно выглядеть, как мы можем это реализовать.