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


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

    QIWI 75,19
    Ведущий платёжный сервис нового поколения в России
    Поделиться публикацией
    Похожие публикации
    Комментарии 16
    • +2
      Мы построили подземный бункер, но нам нужен балкон. Есть сервис balkon.io, но у него есть ограничения, поэтому сделаем сами.

      Ох уж этот безумный мир с его SPA…
      • 0
        Каждому бункеру, свой балкон!
        • 0

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

          • 0
            В плане бизнеса вы описали все верно, спасибо!
            Но я думаю речь шла о Prerender.io, тут мы действительно сделали, потому что могли, так как это не затрагивало напрямую продукт и существует только для роботов.
        • 0
          Зашёл по ссылке в конце статьи, хочу посмотреть как это выглядит с примерами. Просит ввести свой телефон, ушёл. Вероятно, так поступлю не только я.
          • 0
            Это, в общем-то, логично: чтобы получить деньги на киви-кошелёк, нужно ввести номер этого кошелька.
            • +1
              Это понятно, но до того как пользоваться, я хочу посмотреть как это будет выглядеть глазами обычного пользователя, который увидит форму на сайте. Загляните в Яндекс.Кассу — там нужно ввести номер телефона, чтобы понять как будет выглядеть форма?
              • +1
                Яндекс касса немного другое, копилка призвана упростить сбор денег на общие покупки, например, а не на прием платежей. Но за идею прикрутить демо-режим, спасибо, подумаем.
          • 0

            +353… не регестрируеися — печалька :(

            • 0
              Пользователей из Ирландии мы даже как-то не ожидали ))
              Но будем стараться и расширять зону покрытия ))
            • 0
              В очередной раз столкнувшись с проблемой сбора денег
              — типичная беда стартапов, решение проблем которых не существует.
              • 0
                если бы это был стартап, возможно вы были бы правы, но это расширение возможностей одного из основных продуктов компании.
                • Суть моего комментария не в слове стартап)

                  Ок, по существу, что не нравится:

                  1) Слабая кастомизация страницы приема денег.
                  2) Совершенно не понятно как построена отчетность по взносам.
                  • 0
                    Я так и не смог связать ваши оба комментария :)
                    Но по существу:
                    1) На MVP взяли минимальный функционал и кастомизация страницы приема денег в нее не вошла, но идея такая есть и мы над ней активно думаем.
                    2) Если есть возможность поподробнее, в личку или сюда, что именно не понятно? Но дополнительно я подсвечу дизайнерам этот момент.
              • +1
                Вы хорошо поработали. Взяли и сделали, вместо того чтобы просто сидеть и мять мягкое.

                Но своих денег я бы вам не доверил.
                • 0
                  Спасибо за комментарий!
                  Доверять или нет, ваше право.

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

                Самое читаемое