Як ми підклали компанії «свиню»


В черговий раз зіткнувшись з проблемою збору грошей, ми вирішили подивитися, які існують готові рішення на ринку. Провели аналіз існуючих продуктів, виявили їх недоліки і вирішили зробити свій продукт (адже в IT свої "велосипеди" завжди ближче).
У цій невеликій статті мені б хотілося поділитися досвідом збору команди, взаємодії з суміжними підрозділами в рамках великої компанії і спробою використовувати готові рішення, на перший погляд підходять під наші потреби.

Збір команди:
Після затвердження проекту на верхах і появи product owner'а, постало питання "а хто ж буде робити?". За наявними процедурами, завдання повинні були розлетітися по різним групам: front-end, back-end, database. З різними чергами завдань, пріоритетів і власниками. Про кожного потроху.
Front-end — потрібна була інтеграція в сайт невеликий форми, і проблем по початку не було — сказали, що ресурс є і все зроблять за пару тижнів. Але радість тривала недовго — мабуть, за сукупністю параду планет, повні та інших містичних подій (точно ми так і не дізналися) в "закритий клуб" нас не пустили. Ресурс не видали і відклали завдання на потім.
Back-end — тут було простіше, нам відразу сказали, що ресурсу немає і найближчим часом не буде.
У Product owner пропало бажання ходити далі і дізнаватися "а коли буде ресурс?", "а може виділіть пару спринтів?". Після чого вона поскаржилася нам, в общем — тлін.

Але, після вдало подвернувшегося Agile-тренінгу, на якому нас зарядили енергією на успіх і розповіли, що можна робити будь-проект будь-якою командою, ми вирішили створити проект силами команди, яка побічно пов'язана з веб-розробкою. Так почалася історія однієї маленької, але гордої команди.
Початок:
Діставши згоду на верхах спробувати новий формат ведення проекту, ми стартували.
Зібрали 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 Скарбничка — сервіс для простого і зручного колективного збору грошей. Вам достатньо лише створити тематичну скарбничку і ділитися посиланням зі своїми друзями для її поповнення. Ніяких зайвих реквізитів.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.