Антикейс: Сапожник с сапогами, или как мы свой сайт полгода делали

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

• Предыстория
• Кто виноват, и что делать
• Как решали ошибки
• Чему это нас научило
• Что имеем сейчас

Аспирити — студия разработки из Сибири. За создание сайтов и приложений на фреймворках нам платят деньги. До 2023 года внутренние проекты мы собирали на Tilda Publishing.

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

В 2022 решили практически с нуля выйти на рынок РФ. Свой русскоязычный сайт мы не поддерживали с 2018 года.

За короткий срок необходимо было не только воскресить его, но и адаптировать под новую целевую аудиторию и позиционирование, обновить дизайн и добавить актуальные кейсы.

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

Так выглядел изначальный план:

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

Прежде чем разбираться в ошибках покажем таймлайн разработки:

«Джунами за месяц»

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

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

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

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

Когда ожидания по срокам не сошлись с реальностью, мы добавили в проект ещё пару джунов. А лидить оставили ветерана этого проекта. Джун-тимлид, что же могло пойти не так?

Примерно всё.

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

Недооценили дизайн

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

Визуально такой дизайн смотрится просто, но это обманчивое впечатление, ведь множество микроанимаций нужно прописать в коде. А мы хотели использовать довольно ограниченное количество библиотек, чтобы ускорить загрузку и улучшить показатели Core Web Vitals.

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

Если бы мы серьёзнее проанализировали дизайн-макеты перед отправкой в разработку, этого бы не произошло. Можно было отдать макет на оценку опытным разработчикам, которые проверили бы соответствие выбранного нами стека с дизайном. И сказали:

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

Не отследили проблемы с коммуникацией

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

Как упоминали выше, мы мечтали сделать быстрый сайт с минимумом библиотек. Техлид заметил, что если хотим, чтобы всё грузилось за секунды, то писать нужно на чистом JS, CSS и HTML’e.

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

Как итог:

Изменили подход

Мы вернулись к тому, с чего стоило начать, если бы проект был коммерческим — определили ресурсы, ответственных, бизнес-задачи и уже под них делали решение.

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

Отдел маркетинга планировал купить нулевую строку в Рейтинге Рунета на три месяца начиная с 1 апреля (спойлер: мы её купили). Это означало, что появился чёткий дедлайн, привязанный к бизнес-задаче, а не сферическое «давайте закончим до Нового года» потому что так захотелось.

Решили делать первую итерацию простой и адаптивной, а потом уже накручивать фичи.

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

Пересобрали команду и наладили коммуникацию

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

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

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

Пересмотрели стек

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

Так мы избавились от множества багов при попытке внедрить поэкранный скролл.

Отдел маркетинга самостоятельно прописал все необходимые для SEO схемы и метатеги, а разработчики добавили возможность управлять контентом через Strapi.

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

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

Если совсем просто, то нужно подходить к внутренним проектам максимально серьёзно, как если бы за них кто-то платил. Потому что по факту мы сами за них и платим.

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

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

Частичное выделение сотрудников (например, 20%) не подходит для сложных проектов, так как потребует большого количества времени на коммуникацию и распределение задач, а на рабочие таски ничего не останется.

Скажем честно, сайт мы ещё недоделали. Поэтому на aspirity.ru можно увидеть первую итерацию — симбиоз Тильды с кастомной разработкой и прикрученным Strapi для удобства работы с контентом. Пишите в комменты, если хотите узнать про использование Strapi подробнее.

Прямо сейчас в Jira висят 43 таски. Они ждут команду, которая сможет доверстать всё, что мы к MVP не успели. А также исправить баги, перевезти лендинги из Тильды на сервер, и, возможно, освежить дизайн.

И да, мы учли все ошибки, и новый внутренний проект разрабатываем уже как коммерческий. Но об этом расскажем как-нибудь потом.

Все иллюстрации с Котибором любезно предоставила наш Senior Frontend Developer Жанна. Больше артов можно найти в телеграм-канале.