Лого vc.ru

Кейс из России: Как организовать работу над SaaS-проектом в Trello

Кейс из России: Как организовать работу над SaaS-проектом в Trello

Команда платформы для общения и управления пользователями на основе их поведения 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 циклом. У нас куча задач, которые надо делать, какие на какую метрику влияют — забываем. У каждого в команде появляются свои идеи, куда их девать. Бардак, короче.

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

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

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

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

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

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

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

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

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

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

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

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


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

Хорошая статья. Также могу порекомендовать Agile Board Plugin для Redmine: www.redminecrm.com/projects/agile/pages/1

Ребят, ну серьёзно. Какое отношение имеет опыт работы в простейшем продукте к gh? Вот ещё идея— как сервис создания посадочных страниц с целью увеличения конверсии оформлял опыт работы с уборщичей по ГПХ.
Очень махрово.

Tom, да прямое отношение.
Мы разбирали подробно западный кейс в этом ключе siliconrus.com/2014/10/trello-gh/ и тоже с trello,
а здесь ребята описывают свой опыт, и он кажется нам интересным.

0

Погодите. Вместо Трелло могла быть 1С. Это просто инструмент.

Правильная работа с инструментами - это хороший кейс.

Всё за уши тянете.
С другой стороны, что изменится? Вы говорите, что правильную махру гоните, я— нет.

0

У нас равные права в плане возможности высказаться в комментариях, что мы и сделали.

Мы не пытались написать про то, как перетаскивать листочки в трелло.
Мы нашли для себя решение как делать работу над продуктом Измеримой. Чтобы HADI цикл вписывался в наш производственный процесс, чтобы вся команда знала над какой метрикой мы сейчас работаем, чтобы результат изменений продукта был в одном месте и всем доступен.
Трелло лишь инструмент для этого, так же как гугл аналитика - инструмент для измерения.

Статья по теме рубрики— Как мы повысили retention, Как мы узнали Х и заработали У, используя когортный анализ.
А выше— полотенце из мохры.

Не, молодцы что про трелло написали. Хорошая вещь, только некоторым трелло из-за своей простоты кажется слишком сложной.

Как-то так получилось, что статья оказалась про трелло.
Хотя мы пытались рассказать про то, как мы управляем HADI циклом и как связываем его непосредственной разработкой. В трелло оказалось удобнее всего, вот и все.

На мой взгляд вполне удобная и прозрачная структура для ведения материалов и работы над проектом. Уверен, что решает 80% потребностей в организации совместной работы.

Полезный материал, но не по теме рубрики, на мой взгляд!

0

Всё в Трелоло хорошо, но, если абстрагироваться от типичных методологий, не хватает связанных и/или подзадач. Есть чеклисты внутри задачи, но это неудобно, потому что приходится сканировать визуально каждый раз содержимое карточки, и на это уходит много времени.
Может кто-нибудь это решил для себя?

С большими задачами уходим в Google Docs, который привязан, разумеется. Чтобы не растить в trello.

0

Kanbanflow - с учётом времени по помидоркам и подзадачами.

Там аналогично — подзадачи чекбоксами

0

Мы, чтобы не сканировать глазами текст, добавляем картинки. Куски интерфейса или типа того. Намного быстрее объясняют задачу.
А вообще, длинные задачи очень редкие, стараемся не делать короткие итерации.

0

Как картинки решают мою задачу?
Вопрос не в длительности итераций, но во взаимосвязях между задачами.
Недавний пример: решили вопрос отображения дополнительных данных в строке таблицы, но таким образом, что следующая задача по анимации этого отображения существенно усложнилась из-за способа реализации предыдущей. Произошло по причине того, что разработчик банально не соотнёс две карточки друг с другом.

0

А почему вы мой коммент удалили? А комментарии со спамом о курении висят?))) Забавный кейс правда?

Я могу еще раз написать:
Видимо совсем не о чем писать, тут пост о трелло, в другом содержимое сумки сотрудника Яндекс, фу....

0

Сделаю пожалуй скриншоты этих комментариев,
похоже что это с руки администрации судя по проыилю спамера siliconrus.com/users/18114/comments/

0

я бы еще посоветовал завести доску Archive, куда перекидываются старые листы За Февраль, За Январь, За Декабрь и т.д.

Так и сделали ))
Чтобы видеть какие метрики были несколько месяцев назад

0

А что значит, чтобы видеть какие метрики было несколько месяцев назад?

Вы туда как-то текущие метрики еще вносите?

0

Да, в каждую (стараемся в каждую) задачу записываем как она отразилась на метриках

0

Здесь самое ценное не сам Трелло, а как организовать работу с управлением метрик и чтобы всем было удобно. Использовать можно все что угодно для этого, хоть тетрадь.

Мы используем подход, который описали UserVoice 2 года назад - community.uservoice.com/blog/trello-google-docs-product-management/

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

0

"Любой стартап, да и вообще SaaS, должен разрабатываться по agile." - не, не должен. Просто мог бы.

0

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
Sasha Zivers

Мы ещё и яиц сами не несём, но пригорелую яичницу враз распробовать можем.

«Никому не выгодно, чтобы у вас скапливались деньги»
0
Sasha Zivers

*паталогически собирает

«Никому не выгодно, чтобы у вас скапливались деньги»
0
Sasha Zivers

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

«Никому не выгодно, чтобы у вас скапливались деньги»
0
Sasha Zivers

Ну вот об этом как раз и много говорит и повторяет Кийосаки.
Но до многих так и не доходит и продолжают твердить как заводные: "его книжки не работают в россии!!"
Рилли? Не работает экономить на пассивах и умножать активы?)

«Никому не выгодно, чтобы у вас скапливались деньги»
0
Sasha Zivers

Ну да, лучше послушайте гипнотезёра, лол.

(уточнил, т.к большинство не знает, кто это вообще)

«Никому не выгодно, чтобы у вас скапливались деньги»
0
Показать еще