Как мы в Carrot Quest организуем работу в SaaS-продукте?

Решил поделиться нашим опытом разработки сервиса Carrot Quest. Мы долго искали удобную для себя форму работы. Пробовали scrum доски на стене, пользовались asana с to-do листом, даже в гуглдоке на первых порах писали задачи и отмечали цветом их выполнение. Как и любой проект — искали удобную для себя методологию.

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

Для начала вводные

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

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

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

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

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

Потому что:

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

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

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

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

Scrum в trello

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

1. У нас недельные спринты;
2. Каждую субботу подведение итогов спринта и планирование следующего;
3. Релизы запускаются по готовности.

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

Рассказываю HADI и продукт, в порядке эволюции задачи.

Борд HADI

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

Суть методологии очень проста.

1. В начале agile цикла (у нас в начале недели) поставить измеримые гипотезы. Гипотеза должна относится к какой-то метрике;
2. Произвести действие (выполнить гипотезы, реализовать задачи, сделать уже что-нибудь);
3. Собрать данные о том, как каждая гипотеза повлияли на ключевые метрики;
4. Сделать выводы.

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

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

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

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

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

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

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

У каждого типа задачи свой цвет. Так задумано неспроста. 6 секунд, расскажу.

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

З.ы. Спасибо lpmotor.ru— пару идей «подтырили» у них;)

Это борд про продукт

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

1)      Задачи на неделю — сюда попадают все задачи, которые мы запланировали на текущую неделю;

2)      В процессе — если кто-то берет задачу в работу, он перетаскивает ее на это лист;

3)      Сделано за неделю — как только задача закончена, она отправляется сюда;

4)      Баги — сюда записываются найденные нами или пользователями баги. Они здесь, а не в борде «HADI», потому некоторые из них важно сделать быстро. Хотя не все баги значительные.

5)      Сделано на март (или другой месяц). В конце недели мы не удаляем законченные задачи, мы их перекидываем на этот лист. Польза в том, что в конце месяца мы можем легко восстановить в памяти обновления, сделанные в сервисе. Написать новость с обновлениями в сервисе теперь не проблема.

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

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

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