- PVSM.RU - https://www.pvsm.ru -
В очередной раз столкнувшись с проблемой сбора денег, мы решили посмотреть, какие существуют готовые решения на рынке. Провели анализ существующих продуктов, выявили их недостатки и решили сделать свой продукт (ведь в 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 рендерингом. В итоге было два варианта:
Для раздачи статики роботам был использован NodeJS.
Back-end:
От бэкэнда требовалось немного: принимать запросы от фронта, работать с базой, общаться с другими сервисами в контуре QIWI. Нагрузку заложили как у основного сайта. Проект пришелся на волну активного внедрения в компании микросервисной архитектуры, что позволило нам уменьшить время разработки, так как часть функционала окружения на себя брали уже готовые микросервисы.
После оценки требований и возможностей встал вопрос "на чем же писать?". Среди претендентов были Java, NodeJS, Golang.
В итоге выбор пал на Golang, что нам аукнулось в дальнейшем в организационном плане, так как админы не умели собирать и разворачивать приложения, а у ИБ не было инструментов для анализа кода. Но, конечно, все проблемы в результате были решены.
В качестве базы выбрали PostgreSQL — с задачей хранения данных она справляется, и нам этого хватило.
Тестирование:
В команде не было изначально профессионального тестировщика, поэтому в какой-то момент скопилось очень много задач для тестирования, и это стало напрягать. По сути, это была классическая для начинающих в agile ситуация — завал задач в одном месте, который нужно разгрести, прежде чем продолжать разработку. Но мы нашли выход: забили отступили от Agile и продолжили работать.
В итоге мы не стали брать тестировщика в команду, а использовали команду QA как сервисное подразделение, отдавая задачи на тестирование. Неожиданно для нас, подход оказался удачным: ребята-аутсорсеры очень быстро и хорошо прошерстили наш продукт, найдя кучу багов и прибавив новых стикеров на доску. Это приносило радость и понимание, что проект движется к продакшену.
Как запускались:
Пилотный запуск произошел внутри компании, что позволило нам собрать предложения, пожелания, баги, но в целом отзывы были положительные. Исправив все критичные баги прямо в проде, направили небольшой трафик с основного сайта, проведя тестирование уже на реальных пользователях. После чего был произведен обзвон пользователей и проведен небольшой опрос о продукте. Выяснили, что продукт пользователям понятен и полезен. Они к тому же подкинули нам еще несколько хороших идей в бэклог, и мы решили масштабироваться и сразу же запускать второй этап проекта с доработками, которые сделают жизнь юзеров еще проще.
Итог:
По ходу выполнения проекта были как положительные так, и отрицательные моменты. Пройдя этот путь вместе с командой, я получил для себя бесценный опыт и сделал некоторые выводы:
P.S.
О чем вообще пишет этот человек и при чем тут "свинья"? Я о нашем новом продукте. Встречайте QIWI Копилка [1] — сервис для простого и удобного коллективного сбора денег. Вам достаточно только создать тематическую копилку и делиться ссылкой со своими друзьями для ее пополнения. Никаких лишних реквизитов.
Автор: QIWI
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/224797
Ссылки в тексте:
[1] QIWI Копилка: http://qiwi.me
[2] Источник: https://habrahabr.ru/post/318300/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.