В очередной раз столкнувшись с проблемой сбора денег, мы решили посмотреть, какие существуют готовые решения на рынке. Провели анализ существующих продуктов, выявили их недостатки и решили сделать свой продукт (ведь в IT свои "велосипеды" всегда ближе).
В этой небольшой статье мне бы хотелось поделиться опытом сбора команды, взаимодействия со смежными подразделениями в рамках большой компании и попыткой использовать готовые решения, на первый взгляд подходящие под наши нужды.
Сбор команды:
После утверждения проекта на верхах и появления product owner’а, встал вопрос "а кто же будет делать?". По имеющимся процедурам, задачи должны были разлететься по разным группам: front-end, back-end, database. С разными очередями задач, приоритетами и владельцами. О каждой понемногу.
Front-end — нужна была интеграция в сайт небольшой формы, и проблем по началу не было — сказали, что ресурс есть и все сделают за пару недель. Но радость длилась недолго — видимо, по совокупности парада планет, полнолуния и прочих мистических событий (точно мы так и не узнали) в "закрытый клуб" нас не пустили. Ресурс не выдали и отложили задачу на потом.
Back-end — тут было проще, нам сразу сказали, что ресурса нет и в ближайшее время не будет.
У Product owner пропало желание ходить дальше и узнавать "а когда будет ресурс?", "а может выделите пару спринтов?". После чего она пожаловалась нам, в общем — тлен.
Но, после удачно подвернувшегося Agile-тренинга, на котором нас зарядили энергией на успех и рассказали, что можно делать любой проект любой командой, мы решили создавать проект силами команды, которая косвенно связана с web-разработкой. Так началась история одной маленькой, но гордой команды.
Начало:
Получив добро на верхах попробовать новый формат ведения проекта, мы стартовали.
Собрали backlog, завели доску, обсудили MVP, начали распределять роли.
С последними вышел курьез, поскольку каждый участник должен иметь роль, полезную для команды. Это, на мой взгляд, является плюсом такого подхода, так как в команде остаются только "нужные" люди. Менеджеры, например, стали тестировщиками.
Выбрали недельные спринты, несмотря на то, что обычно в компании они двухнедельные. Как потом оказалось, не зря — короткий спринт положительно сказался на проекте, и команда чаще была в курсе хода работ, было проще учитывать и влиять на изменения вокруг проекта.
Неожиданно, одной из сложностей стало заставить людей вовремя приходить на утренние ежедневные встречи. Для чего даже был введен налог на опоздания в виде сладостей, в результате команда немного прибавила в весе :)
Технологии:
Продукт очень хорошо попадал в общую концепцию продуктов в компании, и мы хотели по максимуму использовать уже готовые решения и архитектуру. Но в итоге основная боль от использования готовых "велосипедов" сводилась к тому, что зачастую это был моноцикл, ехал он только направо, а как крутить его педали, знала от силы пара человек.
Front-end:
Чтобы не ждать ресурса для внедрения в сайт, оптимальным для нас вариантом оказалось сделать собственный сайт для продукта.
Для разработки сайта за основу архитектуры была взята связка SPA, React JS, Redux.
От isomorphic-приложения решено было отказаться, дабы не связываться с NodeJS (хотя без ноды не обошлось), в этом плане SPA выгодно выделялся.
Поначалу все шло хорошо. Приложение обретало все больше функционала, придавая команде уверенности. Проблемы начались после пентестов ИБ. Оказалось, что схема авторизации содержала в себе архитектурную ошибку. Это заставило нас побегать по нескольким подразделениям и попутно забраковать похожую схему в соседнем проекте. Но решение в итоге было найдено.
Следующие грабли, на которые мы наступили — это SEO. Роботы не умеют работать с javascript рендерингом. В итоге было два варианта:
- Prerender.io — сторонний сервис, и у него есть некий интервал для создания кешированных страниц. Нам же нужно было получать статику в режиме реального времени.
- Свой пререндер — bingo!!!, свои "костыли" всегда лучше
Для раздачи статики роботам был использован NodeJS.
Back-end:
От бэкэнда требовалось немного: принимать запросы от фронта, работать с базой, общаться с другими сервисами в контуре QIWI. Нагрузку заложили как у основного сайта. Проект пришелся на волну активного внедрения в компании микросервисной архитектуры, что позволило нам уменьшить время разработки, так как часть функционала окружения на себя брали уже готовые микросервисы.
После оценки требований и возможностей встал вопрос "на чем же писать?". Среди претендентов были Java, NodeJS, Golang.
- Java — основной язык разработки back-end в компании, который нам активно советовали потому что его многие "умеют". Однако поизучав один проект, пришли к выводу, что многие "умеют" его по-своему. Кроме того, вариантов решения одной задачи за годы существования и смены трендов в Java существует очень много.
- Node.js — тренд, достаточно легкий в понимании и освоении. Обсудив этот вариант, мы пришли к выводу, что очень просто отстрелить себе ногу, попутно повредив еще что-нибудь. JS есть JS, со всеми своими плюсами и минусами.
- Golang — Из коробки в Go доступны все необходимые инструменты, включая легковесную многопоточность, тестирование и бенчмарки. Также есть внушительный список сторонних библиотек на все случаи жизни. Выгодно смотрится и заявленная поддержка обратной совместимости версий Golang. Смутили лишь каналы, которым не смогли найти применение в коде, да и к автоформатированию с синтаксисом пришлось привыкать некоторое время.
В итоге выбор пал на Golang, что нам аукнулось в дальнейшем в организационном плане, так как админы не умели собирать и разворачивать приложения, а у ИБ не было инструментов для анализа кода. Но, конечно, все проблемы в результате были решены.
В качестве базы выбрали PostgreSQL — с задачей хранения данных она справляется, и нам этого хватило.
Тестирование:
В команде не было изначально профессионального тестировщика, поэтому в какой-то момент скопилось очень много задач для тестирования, и это стало напрягать. По сути, это была классическая для начинающих в agile ситуация — завал задач в одном месте, который нужно разгрести, прежде чем продолжать разработку. Но мы нашли выход: забили отступили от Agile и продолжили работать.
В итоге мы не стали брать тестировщика в команду, а использовали команду QA как сервисное подразделение, отдавая задачи на тестирование. Неожиданно для нас, подход оказался удачным: ребята-аутсорсеры очень быстро и хорошо прошерстили наш продукт, найдя кучу багов и прибавив новых стикеров на доску. Это приносило радость и понимание, что проект движется к продакшену.
Как запускались:
Пилотный запуск произошел внутри компании, что позволило нам собрать предложения, пожелания, баги, но в целом отзывы были положительные. Исправив все критичные баги прямо в проде, направили небольшой трафик с основного сайта, проведя тестирование уже на реальных пользователях. После чего был произведен обзвон пользователей и проведен небольшой опрос о продукте. Выяснили, что продукт пользователям понятен и полезен. Они к тому же подкинули нам еще несколько хороших идей в бэклог, и мы решили масштабироваться и сразу же запускать второй этап проекта с доработками, которые сделают жизнь юзеров еще проще.
Итог:
По ходу выполнения проекта были как положительные так, и отрицательные моменты. Пройдя этот путь вместе с командой, я получил для себя бесценный опыт и сделал некоторые выводы:
- Agile оказался очень удобным набором инструментов для запуска продукта.
- Но для внедрения agile менеджер подразделения должен признаться в своей ненадобности.
- В смежных командах работают тоже люди.
- Но чаще на этих людей начинаешь смотреть по-другому, несмотря на то, что они работают в компании уже давно.
- ИБ находится в своем контексте и не всегда понятно, что и зачем надо сделать, поэтому лучше лишний раз переспросить и уточнить.
- Не стоит бояться нового и делать то, что никогда не делал.
- SPA, React, Redux — хорошо и модно, но без NodeJS никуда.
- Go легок, быстр и стабилен, для некритичных продуктов подходит отлично.
- Регулярные стендапы — хорошая практика "держать руку на пульсе".
- Когда решения обсуждаются и принимаются коллективно, каждый участник команды чувствует свой вклад.
- Груминг — это не только стрижка собак, но и отличный способ планирования активностей.
P.S.
О чем вообще пишет этот человек и при чем тут "свинья"? Я о нашем новом продукте. Встречайте QIWI Копилка — сервис для простого и удобного коллективного сбора денег. Вам достаточно только создать тематическую копилку и делиться ссылкой со своими друзьями для ее пополнения. Никаких лишних реквизитов.
Автор: QIWI
