Как сделать свой продукт небольшой командой и без опыта в разработке. Часть 1

Осенью 2020 года Xsolla впервые попробовала организовать “Гараж” — мероприятие, на котором мы собрали заинтересованных ребят, готовых учиться новому прямо на практике. В течение месяца они делали настоящие проекты и приобщались к командной разработке.

Со стороны звучало просто отлично, но из-за того, что всё происходило впервые, возник вопрос — как небольшой команде без опыта в разработке сделать прототип продукта, который было бы не стыдно показать миру? Правильного ответа, само собой, не было, но мы постарались сделать всё возможное.

Эта статья будет полезна начинающим тимлидам и Scrum-мастерам. В ней я расскажу о своём опыте организации небольшой команды в рамках Xsolla Garage — с какими трудностями мы столкнулись, как пришли к тем или иным решениям и что планируем делать дальше.

Процесс подготовки

Начну издалека — каждый год в Xsolla проходит Летняя школа (кстати, набор в шестую уже начался!), в которой студенты обучаются прикладным знаниям. В 2020 году направления были следующие: Analytics, Frontend, Backend, Documentation, Quality Assurance и Data Science.

После Школы было много положительных отзывов

Несмотря на отличные отзывы, хотелось улучшений. Это натолкнуло нас на следующие мысли:

1. Студентам однозначно не хватает практического опыта — да, в конце большинство потоков предлагали сделать итоговое задание, которое отчасти закрывало проблему, но этого было недостаточно.
2. Так как Xsolla постоянно развивается, в её стенах постоянно возникают новые идеи. Каким образом эти идеи можно проверить и создать MVP продукта без значительных временных и денежных затрат?

Если объединить эти два пункта, появляется достаточно очевидное решение — что если продолжить Летнюю школу и предложить её участникам объединиться в команды, чтобы разработать полезный продукт? Это закрыло бы потребности как студентов (они бы смогли получить нужный опыт), так и Xsolla (она бы смогла проверить самые смелые гипотезы). Так и начался “Гараж” — именно так мы назвали мероприятие, в котором объединили студентов Школы.

Так как основа “Гаража” — разработка MVP продуктов, для начала в рабочем чате Xsolla был запущен опрос на предмет возможных тем, которые мы бы могли вести. Ответов было немного, так как не было опыта в подобных мероприятиях и не все понимали, зачем это нужно, но в итоге получился список проектов для пяти команд. В дальнейшем, чтобы избежать подобной ситуации, имеет смысл четко описать, для чего это и какая цель у всего этого стоит. Кроме того, можно попробовать другой формат, например, организовать некоторую встречу, на которой все желающие могли бы заняться брейнштормингом.

Полученный список с темами можно было условно поделить на две категории:

• Категория 1: выбор за командой. Идея заключалась в том, чтобы дать команде максимальный простор для творчества, ни в чём её не ограничивая. Важная мысль — тема не обязательно должна быть связана с нашей компанией.
• Категория 2: темы, связанные с Xsolla. В этом случае хотелось создать решение, которое можно было бы интегрировать в существующие сервисы и продолжить разработку в стенах компании — в случае успеха даже с приглашением оригинальных участников.

Также было решено придерживаться следующих правил:

• Каждая команда будет работать по фреймворку Scrum.
• Каждая команда будет включать двух человек из Xsolla — один из них исполнит роль владельца продукта (Product Owner), другой — Scrum-мастера.
• Длительность итерации — 1 неделя, общая длительность разработки — 1 месяц.
• Как и подобает в Scrum, каждая команда в начале итерации проводит планирование, а в конце — демонстрацию и ретроспективу.

На этапе обсуждений мы сразу же столкнулись с основной проблемой: не все из наших сотрудников были заинтересованы тратить своё время на подобную “авантюру” — стоит понимать, что Гараж, как и Школа, организовываются на добровольных основах во внерабочее время. Тем не менее, для 4 из 5 команд был найден полный комплект, что мы посчитали результатом, с которым можно работать. В одной из таких команд я оказался Scrum-мастером: для себя я понял, что в дальнейшем хочу развиваться именно в этом направлении, поэтому сомнений не было. К тому же, незадолго до этого я поучаствовал в программе менторства на эту же тему: о том, как это происходило, можно узнать в одной из предыдущих статей блога.

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

На сайте мы описали, что ждёт студентов Школы

В итоге желающие были найдены, хоть и в небольшом количестве: на каждую команду в среднем приходился 1 Backend-разработчик, 2–3 Frontend-разработчика, 2 специалиста Data Science, 1 QA и 2 аналитика. Из направления Documentation нам удалось набрать суммарно двух людей на все команды, поэтому в некоторых командах эту роль совмещали аналитики.

Начало разработки

В первый день “Гаража” мы собрали всех заинтересованных в нашем офисе и провели небольшую презентацию, в которой рассказали о том, что ждёт ребят: формат, проекты, ритуалы. Часть людей были из разных городов и подключились к нам в режиме онлайн — это накладывало определенные ограничения, но проблемой в итоге не стало. Наши переговорные комнаты позволяют подключать людей из любой точки мира — для этого мы используем плотную интеграцию с Google Meet.

В одной из таких команд автор статьи оказался Scrum-мастером: в нашем случае необходимо было разработать аналог существующего продукта из Xsolla — удобный конструктор каталогов игр. Для того, чтобы погружение ребят в тему прошло максимально быстро, мы с владельцем продукта совместно подготовили небольшой документ, который состоял из следующих ключевых моментов:

• Название команды
• Цель продукта
• Ожидаемый результат
• Основные возможности (по сути — функциональные требования)
• Возможности, которые хотелось бы видеть, но продукт может жить и без них

Документ потом был распечатан и выдан каждому участнику во время встречи

После короткой вводной для ребят, фокус сместили на них самих: мы познакомились друг с другом — каждому из участников было предложено ответить на базовые вопросы вроде “как тебя зовут и где ты работаешь/учишься”. Параллельно я написал свой ник в Telegram — планировалось, что дальнейшая коммуникация будет происходить именно там.

Так как ребята были ещё не совсем уставшие, а представление о продукте уже начало формироваться, мы начали проводить первый ритуал — Sprint Planning. Многим не хватало опыта работы в команде, поэтому пришлось объяснять основы почти с нуля:

• Какие ритуалы включает Scrum, какие есть роли.
• Что такое User Story и зачем это нужно.
• Что такое User Story Mapping (заполнять бэклог начали именно с помощью этого метода совместно всей командой).
• Способы оценки сложности User Story: в часах, в story points.

Несмотря на то, что общепринятой практикой в Xsolla является оценка в story points, сходу применять её было нельзя, так как она требует некоторый сравнительный анализ задач (хотя бы на предмет “сложнее-проще”) и статистику того, как команда делает задачи. Именно поэтому на первой неделе было решено выбрать оценку в часах. Однако, с этим подходом было совершено несколько ошибок:

1. Ребята ранее не практиковались в подобных временных оценках, поэтому я подталкивал их фразами вроде “исследования делаются примерно N времени опытным разработчиком”. Казалось, что это рабочая схема.
2. Время, которое предлагали разработчики, умножалось на 1.5.

По результатам первого спринта достаточно много задач оказались незакрытыми. Как бы я поступил, если бы пришёл на планнинг сейчас? Скорее всего, предложил бы ребятам выписать последние задачи, которые они делали, и попросил написать затраченное на них время. Таким образом можно было бы делать сравнительный анализ, а не выдумывать время с потолка. Как со мной поделились после сами разработчики — их силы были очень переоценены, а умножать стоило далеко не на 1.5 (точную цифру назвать сложно, но, вероятно, стоило сделать её хотя бы равной двум).

Итоговой фотографии результатов планнинга не осталось, но так как вся наша команда была в офисе, то и делали мы это на доске — так и визуально понятно, и удобно для кооперации

В итоге планнинг был закончен, ребята разошлись по домам до понедельника, именно тогда нас ждало следующее мероприятие — Daily Scrum. О времени проведения договорились довольно просто: обсудили, когда все могут выделить 15 минут и обозначили старт.

Инструменты, ритуалы, выводы

Планнинг — это только начало. После него вопросы стали сыпаться один за другим:

• Какие инструменты выбрать для взаимодействия друг с другом? Для разработки?
• Почему у команды не сложилось единое понимание конечной цели и как это исправить?
• Как провести демонстрацию результатов?
• Один из фронтендеров заболел, как мы всё успеем?!

… и это ещё не конец! Ответ на то, что мы со всем этим делали, будет в следующей части статьи. А пока она готовится — можно поделиться своим опытом организации начинающих команд. Расскажите, с какими трудностями вы столкнулись? Как вам удалось их решить?