Рождественский проект
Вместо новогодних подведений итогов я лучше расскажу как релизнул небольшой проект на рождество. История не слишком увлекательная для сторонней публики, но всегда интересно заглянуть за кулисы производства в других компаниях. А мне будет полезно вернуться к этой заметке через год, что бы понять насколько я был наивен.
Что за проект?
Руководство решило попробовать запустить сайт с отзывами на продукты, что бы попробовать лить через него трафик на основной сайт. Нужно было максимально сосредоточиться на контенте и SEO.
На старте проекта мы получили очень примерное ТЗ со списком экранов и заголовками для них. Макеты рисовались прямо по ходу разработки, а структура сайта менялась еженедельно. Данные, нужные для контента, собирались ближе к релизу, по этому приходилось фантазировать и мокать.
Срок сдачи был в январе, но я посчитал сколько времени и трафика мы потеряем на праздниках и решил что лучше пофлексить и запуститься до НГ, оставив менее приоритетные фичи на доработку.
Итого: 7 недель разработки, 2 с половиной разработчика и все на парт тайме, один дизайнер, 4 часовых пояса на одну команду и полная творческая свобода. Звучит как кайфовое приключение перед новым годом.
Как организовали работу?
Выкинули ритуалы и планирование
Из-за полной неизвестности конечного результата я решил что все эти приколы со скрамом, итерациями и анализом требований будут только мешать. У нас был дедлайн, по этому вместо итераций решили играть в канбан: смотришь на доску с задачами и берешь верхний приоритет.
Первое время даже доски с задачами не было. Вместо этого я нарисовал что-то типа "карты" проекта, на которой крупными мазками изобразил путь от нуля до первого релиза.
Выглядело это как то так:
Такая карта помогала быстро видеть состояние проекта: сколько шагов осталось до релиза, какие задачи можно распаралелить, а какие задачи блочат друг друга.
Это неплохо успокаивало, когда мне начинало казаться что мы проебали все сроки. А так казалось перманентно.
Кстати, тут можно прочитать про концептуальные схемы для планирования. Очень советую почитать и походить по ссылкам.
Упрощаем стек
Я достаточно насмотрелся на то как люди делают лендосы на реакте с некстом, усложняя жизнь на ровном месте. По этому с радостью согласился на elixir + phoenix без логики на клиенте. К тому же проект - простая витрина и никакой логики на клиенте там нет.
Главный профит такого подхода в том что мы получили монолит. Нужны какие то данные для страницы? Напиши запрос в БД и вытащи их. Поменялась логика бекенда? Переверстай страницу под новую.
Да, теперь нужны фуллстеки. Но в нашей команде у всех был различный опыт, так что при поддержке друг друга и чата гпт мы довольно легко справились с кроссфункциональностью.
В итоге это позволило избавиться от лишних коммуникаций в команде и сделало каждого разработчика автономным. Бонусом мы получили Web Vitals в зеленой зоне без каких либо усилий и оптимизаций.
Флексили
В начале работы над проектом мы с заказчиком определили минимум, нужный для релиза. Остальные фичи расставили по приоритету - чем больше фича помогает достижению цели, тем выше приоритет. Все что мы не успевали доделать до релиза отбрасывалось на следующий год.
Так мы порезали лайки для отзывов и поиск по продуктам. Важны ли были эти фичи для пользователей? Несомненно. Стоило ли ради них двигать сроки релиза? Нет.
Убрали лишние согласования внутри команды
Как обычно вносятся правки в проекте: меняется спека, затем дизайн, затем создается задача и разработка приступает к правкам. Максимально надежный конвеер, который мы не могли себе позволить из-за его неповоротливости.
Множество решений принималось на ходу, а разработчики были достаточно компетентны, что бы понимать что будет полезно для целей проекта, а что нет. Если были сомнения, мы шли за советам к коллегам из других цехов.
Таким образом мы убрали задержки на согласовании большинства вопросов, дав команде больше власти над продуктом. А где власть, там и ответственность.
Приемочное тестирование
Изначально мы хотели отдать приемочные тесты нашим ручным QA, но для того что бы это сделать нам бы пришлось привести в актуальное состояние все спеки и макеты. Это породило бы кучу бюрократии и затянуло бы релиз минимум на месяц (скоро праздник, помните?).
Вместо этого я решил рискнуть и дать возможность каждому члену команды протестировать свой домен: дизайнер провела "авторскую приемку", СЕОшник прогнал сайт на метрики и разметку, программисты еще раз прогнали сценарии друг друга.
Я подумал, что тот, кто отвечает в проекте за конкретный домен должен лучше всего в нем разбираться. А еще то, что каждый хочет гордится своей работой, по этому заинтересован в том, что бы его вотчина работала хорошо. Это должно мотивировать тестировать внимательнее.
И, в общем то, сработало. Я провел демо, где показал основные пользовательские сценарии. Затем отдал доступы к стенду всей команде и стал ждать. В этот же день получил список исправлений от каждого. Получается теория была правильной. Ура.
Кстати, наши QA таки нашли неприятную багу уже на проде, подтвердив тем самым мою теорию. Бага была в той части проекта, до которой никому не было дела, а значит не критична на этом этапе.
"Fail fast", "You build it, you run it", TBD...
Проект маленький, команда зрелая и кроссфункциональная. Это позволяет избежать лишней духоты при разработке и доставки в прод.
TBD. Мы не делали фича ветки и старались мержить в мастер как можно быстрее. Нас было трое и каждый был занят свой частью системы. Конфликтов минимум, а сломанный мастер быстро чинился любым разработчиком.
You build it, you run it. Инфраструктуру мы поднимали самостоятельно, по этому заделиверить код не было проблемой ни для кого из нас. Это позволяет легко докатывать любые правки за считанные минуты без томительного ожидания девопсов.
Fail fast. Так как трафика на проекте почти нет - мы можем себе позволить ошибаться на проде. Это позволяет не бояться и катить фичи сразу, как только мы уверенны в них.
Все это невероятно развязывает руки и мотивирует сделать какие нибудь мелочи для проекта даже тогда, когда формально можешь отказаться. Потому что программировать прикольно. Помните это чувство?🥲
Да-да. Я знаю, что такими финтами легко положить прод. Не нуди. Я планирую заняться blue green deployment, починить автотесты и сделать все возможное, что бы сохранить это чувство свободы при росте проекта. Если рост вообще будет.
Норм зарелизились?
В день релиза пришлось попотеть на 3х часовом созвоне исправляя часть данных для прода, фиксить все что "можно сделать по быстрому?" и тюнить инфру.
Но разве бывает по другому? Я не видел ни одного релиза, на котором бы все прошло гладко. Более того - эти хотфиксы создали ощущение завершенности. Без них не было бы чувства, что мы затащили.
Что бы я сделал по другому в следующий раз?
Взял бы ответственность за весь проект раньше
Я отвечал только за разработку и пустил работу дизайнера на самотек. В итоге мы потратили время на отрисовку совершенно ненужных экранов и состояний. Всего этого можно было бы избежать, если бы я:
- Провел интервью с заказчиком, на котором услышал бы его ожидания о том как проект выглядит
- Нарисовал бы схему или мокапы со всеми экранами и переходами между ними
- Вернулся бы к заказчику, что бы он подтвердил что я его правильно понял
- Передал бы эту схему дизайнеру
Может быть такие встречи стоит организовывать на всю команду, но я бы предпочел не отвлекать лишний раз людей от работы, пока я могу сам собрать весь контекст в схему и предоставить команде.
Старался бы получить реальные данные как можно раньше
Я бы начал запрашивать данные для прода сильно раньше. Так получилось, что окончательные данные мы получили за неделю до релиза и большинство проблем возникло именно из-за этого