Эсборд — российская онлайн-доска для бизнеса. Мы разрабатываем отечественный аналог Miro, который не боится санкций и блокировок, а ещё его можно разместить на серверах заказчика. Мы помогаем командам визуализировать идеи и строить схемы.
Поделюсь, как мы перенесли работу в WEEEK после блокировки ClickUp.
Почему для команды Эсборд важен таск-трекер
Таск-трекер нужен для всех процессов. Мы в основном используем WEEEK для разработки, ещё есть направления продукта и поддержки. Отдел продаж тоже сидит в WEEEK — на бесплатном тарифе в другом пространстве.
История переезда в WEEEK
Мы хотели перейти в WEEEK ещё в 2022 году, когда начали разработку нового продукта, но тогда не получилось, и мы пошли в ClickUp.
С командой WEEEK мы хорошо знакомы: в 2021 году мы были в одном акселераторе с Иваном Мараховкой (покойный основатель WEEEK — Прим. ред.). С удовольствием наблюдали за ростом вашего стартапа, радовались успехам. Когда ClickUp нас забанил, сразу поехали в WEEEK.
Переезд происходил болезненно из-за отсутствия интеграции с ClickUp — задачи переносили вручную. Мне очень помогло, что в какой-то момент мы созвонились с Ингой (Инга Скерсь, CEO WEEEK — Прим. ред.). Она на примере показала, как это работает и как планировать разработку.
О команде Эсборд
В команде у нас 18–19 человек, из них 15 работают в WEEEK: это разработка и продукт. Команды удалённые, распределены по стране от Санкт-Петербурга до Новосибирска. Команда продаж работает в своём пространстве на бесплатном тарифе.
О методиках работы или почему Канбан лучше Scrum
Мы около двух лет работали по Scrum с соблюдением всех церемоний, но после ухода Miro планировать даже двухнедельный спринт стало невозможно — работа происходила в режиме «здесь и сейчас». Так мы перешли на Канбан и остались.
По гибкости методики похожи. Мы оставили Scrum-ритуалы оставили, но ушло чувство гнетущего дедлайна, из-за которого приходилось что-то выкидывать.
Scrum бил по качеству, а Канбан меньше давит на психику и позволяет также часто выпускаться — а релизы у нас раз в две недели. За неделю до релиза мы смотрим, какие задачи из колонки Готово к этому моменту можно выпускать.
Об обновлениях сообщаем через всплывающие окна, Телеграм-канал и рассылки.
Как настроили рабочие процессы
В основном мы используем WEEEK для разработки. Здесь у нас три проекта: разработка, продукт, поддержка.
В поддержке мы ведём тикеты. Их заводят вручную сотрудники поддержки.
Выглядит это так: пользователь сообщает о проблеме, мы заводим соответствующий тикет, ранжируем и работаем с ним. Далее его подхватывают разработчики и перемещают.
У нас есть две системы ранжирования. Одна для оценки клиентов, другая для оценки проблем — она помогает разработчику понять критичность проблемы и насколько срочно нужно её решить.
Второй проект — продуктовая разработка. Здесь мы ведём Канбан-доски.
Эпики у нас в первой доске — это верхнеуровневые задачи. Из них мы выбираем те, которыми будем заниматься в ближайшие четыре месяца, планируем, отбираем нужное и проставляем теги.
Описание задачи обычно состоит из двух ссылок — одна на Figma с макетом, вторая на Эсборд с описанием задачи. Подзадачи с эпиков мы распределяем по разным проектам и людям, затем декомпозируем их на User Story.
Тегами мы отмечаем эпики, чтобы понимать, к какому из них относится конкретная User Story. Помечаем две вещи:
- Суть задачи: это фича, добавляющая возможности, фича для улучшения работы или User Mad — исправная, но раздражающая фича, которая мешает быстро выполнить задачу
- Принадлежность задачи: к каким фичам, доске, личному кабинету она относится
Затем задачи перемещаются в аналитику. Там мы их декомпозируем, то есть разбиваем на User Story — приоритизируем, описываем, прорабатываем, собираем референсы и так далее.
Для сбора User Story используем четыре источника:
- Техподдержка, которая собирает запросы
- Отдел продаж, который напрямую контактирует с пользователями
- Общение в продукте — проводим исследования, чтобы понять, что именно нужно аудитории
- Сервис «Предложить фичу» — пользователи сами голосуют, а мы только проставляем задаче статус
Декомпозиция происходит на доске на Эсборде. Она нужна для оценки сроков реализации. Это выглядит как мини-гант, где в первой колонке написаны этапы реализации задач, затем она закрашивается.
Следующий этап — дизайн. Дизайнер делает макет задачи и отправляет её в колонку Готово.
Задачи из колонки Готово мы сразу отдаём разработку или отправляем в тим-ревью: созваниваемся с разработчиками команды-исполнителя и обсуждаем задачу. Обсуждение происходит в чатах или на созвонах. Сложные или новые задачи обычно приходится дорабатывать, поэтому задача находится в этой колонке до успешного завершения тим-ревью.
В проекте Разработка у нас задачи по QA, связанные с автоматизацией. Это задачи не по новым фичам, а коммерческие и технические долги.
Здесь одна колонка — К работе, в ней регистрируются баги. Внутри задачи прописываем условия возникновения багов у пользователя и другие данные, затем приоритизируем по специальной матрице. Потом задачи из этой колонки отправляются в доску «Канбан», в работу.
Основная работа происходит в «Канбане». В первой колонке неприоритизированный бэклог: туда мы отправляем задачи, которые хотим сделать в ближайшее время. В следующей колонке Берём уже приоритизированный бэклог — чем выше задача в колонке, тем она приоритетнее.
На еженедельных созвонах мы рассматриваем эти колонки и проставляем исполнителей. Затем задачи двигаются по статусам разработки: декомпозиция, технический дизайн, реализация, накопительная доска для колонки Готово.
Далее задача отправляется в dev QA, потом либо возвращается с тестирования, либо идёт дальше. Релиз у нас идёт сначала в облачную версию, потом в коробочную.
База знаний
Здесь у нас инструкции по работе — управление командами, добавление участников, удаление подписки и так далее.
Мы хотим сделать ультимативную базу знаний: пользовательскую и внутреннюю. Сейчас мы в активном поиске такого решения. Хотим оставить инструкции для онбординга наших сотрудников и открыть доступ для B2C-клиентов.
Нужно совместить пользовательскую и внутреннюю базу знаний, потому что большой большой пласт информации важен и для пользователей, и для новых сотрудников. Поэтому важно, чтобы часть документов была доступна всем, а часть — не всем. И чтобы это можно было опубликовать в интернет, это индексировалось и было на нашем домене.
Чего не хватает в WEEEK
Хочется, чтобы можно было выделить несколько задач сразу. Сейчас ситуация выглядит так: я беру карточки и закидываю их в аналитику — получается 15 User Story. И все эти 15 штук нужно переносить, назначать исполнителя или менять доску по одной. Выделение нескольких задач поможет ускорить эту работу или проставить теги всем задачам.
Что ещё неудобно: нельзя сгруппировать задачи по статусу. Было бы здорово, если бы я мог сгруппировать их по статусу, — тогда в списке будет удобно смотреть, что в каком статусе находится вне зависимости от команды.
Подписаться 
