Pull to refresh
0
QIWI
Ведущий платёжный сервис нового поколения в России

Как мы подложили компании «свинью»

Reading time 5 min
Views 16K

В очередной раз столкнувшись с проблемой сбора денег, мы решили посмотреть, какие существуют готовые решения на рынке. Провели анализ существующих продуктов, выявили их недостатки и решили сделать свой продукт (ведь в 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 как сервисное подразделение, отдавая задачи на тестирование. Неожиданно для нас, подход оказался удачным: ребята-аутсорсеры очень быстро и хорошо прошерстили наш продукт, найдя кучу багов и прибавив новых стикеров на доску. Это приносило радость и понимание, что проект движется к продакшену.


Как запускались:


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


Итог:


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


  1. Agile оказался очень удобным набором инструментов для запуска продукта.
  2. Но для внедрения agile менеджер подразделения должен признаться в своей ненадобности.
  3. В смежных командах работают тоже люди.
  4. Но чаще на этих людей начинаешь смотреть по-другому, несмотря на то, что они работают в компании уже давно.
  5. ИБ находится в своем контексте и не всегда понятно, что и зачем надо сделать, поэтому лучше лишний раз переспросить и уточнить.
  6. Не стоит бояться нового и делать то, что никогда не делал.
  7. SPA, React, Redux — хорошо и модно, но без NodeJS никуда.
  8. Go легок, быстр и стабилен, для некритичных продуктов подходит отлично.
  9. Регулярные стендапы — хорошая практика "держать руку на пульсе".
  10. Когда решения обсуждаются и принимаются коллективно, каждый участник команды чувствует свой вклад.
  11. Груминг — это не только стрижка собак, но и отличный способ планирования активностей.

P.S.


О чем вообще пишет этот человек и при чем тут "свинья"? Я о нашем новом продукте. Встречайте QIWI Копилка — сервис для простого и удобного коллективного сбора денег. Вам достаточно только создать тематическую копилку и делиться ссылкой со своими друзьями для ее пополнения. Никаких лишних реквизитов.

Tags:
Hubs:
+18
Comments 16
Comments Comments 16

Articles

Information

Website
qiwi.com
Registered
Employees
1,001–5,000 employees
Location
Россия