Кейс из России: Как организовать работу над SaaS-проектом в Trello | Цифровой журнал | about digital

Команда платформы для общения и управления пользователями на основе их поведения Carrot quest рассказала о том, как они построили процесс разработки SaaS-продукта при помоши инструментов Trello.

Решил поделиться нашим опытом разработки сервиса carrotquest.ru. Мы долго искали удобную для себя форму работы. Пробовали Scrum-доски на стене, пользовались Asana с todo-листом, даже в Google Docs на первых порах писали задачи и отмечали цветом их выполнение. Как и любой проект — искали удобную для себя методологию.

Кажется, что-то нащупали. Об этом и хочу рассказать.

Вводные

У нас несколько программистов, аналитик, контент-маркетинг, дизайнер. Все работают в одном офисе, хотя иногда приходится работать удаленно.

Все задачи делились на части:

• разработка продукта (бэкэнд, фронтэнд);
• верстка лэндингов;
• разработка мобильного приложения;
• дизайн продукта;
• дизайн лэндингов;
• контент-маркетинг (статьи, обновления в сервисе, кейсы и т.п.);
• аналитика (сбор метрик о том, как изменения повлияли на ключевые показатели: CPA, Активация, Cрег, С1, LTV).

Как мы организовали управление проектом

Перепробовав много инструментов и подходов, мы остановились на
Trello.

Потому что:

• он оказался самым простым инструментом для управления задачами;
• легко освоил каждый боец в команде;
• использование не занимает много времени;
• он бесплатный.

Его гениальная простота — это то, за что не жалко отдать деньги. Хотя почему-то они их не требуют.

Вы можете создать неограниченное (наверное) количество бордов, каждый из которых состоит из листов:

Карточки на листах легко и просто перетаскиваются из одного листа на другой. Ctrl+v добавляет в карточку фоточку. В общем, прикольно.

Scrum в Trello

Любой стартап, да и вообще SaaS, должен разрабатываться по agile. Так что мы изначально использовали методологию Scrum:

• у нас недельные спринты;
• каждую субботу подведение итогов спринта и планирование следующего;
• релизы запускаются по готовности.

Вот какие мы создали борды в Trello по проекту:

Борд HADI

HADI (Hypothesis, Action, Data, Insights) — это методология, которую
продвигает ФРИИ. Суть методологии очень проста.

• в начале Agile-цикла (у нас в начале недели) поставить измеримые гипотезы. Гипотеза должна относится к какой-то метрике;
• произвести действие (выполнить гипотезы, реализовать задачи, сделать уже что-нибудь);
• собрать данные о том, как каждая гипотеза повлияли на ключевые метрики;
• сделать выводы.

Например, в начале недели вы ставите гипотезу: добавление видеоинструкции на лэндинг увеличит конверсию в регистрацию на 2%. В течение недели вы добавляете видео и измеряете, как изменилась конверсия. В конце недели вы делаете выводы — сработала гипотеза или нет, и если нет, то почему.

У нас была постоянная проблема с HADI циклом. У нас куча задач, которые надо делать, какие на какую метрику влияют — забываем. У каждого в команде появляются свои идеи, куда их девать. Бардак, короче.

Вот что мы сделали:

Мы сделали борд, который разбит на следующие листы:

• Запланировано (или идеи) — это лист с нераспределенными задачами. Они просто есть. Либо появились у нас в голове, либо нам написали клиенты.
• Не влияет на метрику, но важно — не каждая задача влияет на какую-то метрику. Или определить зависимую метрику очень сложно. Например: «собрать и модифицировать все jscss». Вообще без понятия, на что это повлияет, но это надо сделать.
• CPA — сюда входят все задачи, которые влияют на CPA.
• Срег — задачи, влияющие на конверсию в регистрацию.
• Активация — метрика, которая определяет, насколько пользователь «понял» продукт. У нас есть отдельный способ ее расчета. В общем, тут задачи, влияющие на активацию.
• С1 — конверсия в регистрацию и задачи, влияющие на нее.
• С2-Сn — это повторные продажи и задачи, влияющие на них.

По сути, это воронка продаж. Мы видим сколько задач, и на какой этап воронки они влияют. Если юнит-экономика нам подсказывает, что поднимать надо активацию и C1 — мы берем задачи из этих листов.

Важно, чтобы в комментариях к задаче были текущие показатели метрики (возможно, это должно быть в заголовке листа — еще пробуем). У каждого типа задачи свой цвет. Так задумано неспроста. Шесть секунд, расскажу.

В начале HADI-цикла берем нужные задачи и запуливаем их в другой борд.

Спасибо
lpmotor.ru — пару идей взял у них.

Борд про продукт



Именно тут отражается ежедневная работа над проектом. Вот как он устроен:

• «Задачи на неделю» — сюда попадают все задачи, которые мы запланировали на текущую неделю;
• «В процессе» — если кто-то берет задачу в работу, он перетаскивает ее на это лист;
• «Сделано за неделю» — как только задача закончена, она отправляется сюда;
• «Баги» — сюда записываются найденные нами или пользователями баги. Они здесь, а не в борде HADI, потому что некоторые из них важно сделать быстро. Хотя не все баги значительные.
• «Сделано на март» (или другой месяц). В конце недели мы не удаляем законченные задачи, мы их перекидываем на этот лист. Польза в том, что в конце месяца мы можем легко восстановить в памяти обновления, сделанные в сервисе. Написать новость с обновлениями в сервисе теперь не проблема.

Как видите, у каждой задачи свой цвет. Цвет тот же самый, что и на доске HADI. Это помогает всей команде видеть, на какую метрику влияет задача. Как только мы собираем данные по изменениям каждой из метрик, мы добавляем их в комментарии к задаче. Потом в конце недели делаем выводы, как задача повлияла на нашу экономику. Может стоит вернуть как было, или, наоборот, продолжить гнуть линию.

Вот так мы сегодня работаем. Нам это помогает делать процесс контролируемым и понятным. И видеть, как наши изменения влияют на продукт.

Присылайте собственные кейсы, в результате которых вам удалось заметно улучшить (или, наоборот, ухудшить) показатели проекта. Интересные эксперименты обязательно попадут на страницы рубрики Growth Hacks.



About the author