Кейс сервиса WEEEK.

Команде Эсборд, российского разработчика интерактивных досок для совместной работы, требовалось гибкое решение для управления проектами. Нужно было совместить строгость Scrum и гибкость Kanban — методологию Scrumban — чтобы ускорить разработку новых функций и улучшить взаимодействие между отделами.Владимир Гладун, директор по продукту сервиса интерактивных досок Эсборд, поделился опытом использования Канбан-досок в WEEEK для координации распределённых команд.

Когда ClickUp заблокировали в России, команда столкнулась с риском потери управления проектами. Оперативно приняли решение перейти на отечественный аналог — WEEEK. Вот как прошёл переход и какие результаты получили.

Изображение предоставлено сервисом WEEEK с сайта https://weeek.net/ru

Важность таск-трекера для команды Эсборд

WEEEK используется как единая платформа для управления задачами во всех отделах компании. Основное применение — в разработке, где он поддерживает полный цикл создания продукта по гибким методологиям. Также в WEEEK работают продуктологи, поддержка и отдел продаж — для продаж выделено отдельное бесплатное пространство с воронкой и управлением сделками.

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

История перехода в WEEEK

Компания изначально планировала перейти на WEEEK еще в 2022 году при запуске нового продукта, но в тот момент выбрала ClickUp. Руководство было знакомо с командой WEEEK с 2021 года по совместному участию в акселераторе с основателем сервиса Иваном Мараховкой и продолжало следить за развитием платформы.

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

В текущей реализации WEEEK используется как единая платформа для управления задачами across всех отделов компании.

Почему Канбан лучше Scrum

Команда около двух лет работала по методологии Scrum с соблюдением всех церемоний, однако после ухода Miro планирование даже двухнедельных спринтов стало практически невозможным — работа перешла в режим «здесь и сейчас». Это побудило коллектив перейти на Канбан, где команда осталась до настоящего момента.

Оба метода показались команде схожими по гибкости. Было решено сохранить Scrum-ритуалы, но при этом исчезло чувство гнетущего дедлайна, которое ранее заставляло жертвовать качеством или исключать некоторые задачи.

Scrum негативно сказывался на качестве продукции, тогда как Канбан оказал меньшее давление на психику сотрудников, сохранив при этом частоту выпусков — релизы по-прежнему происходят каждые две недели. За неделю до релиза команда анализирует задачи из колонки «Готово» и определяет, какие из них можно включить в предстоящий выпуск.

Настройка рабочих процессов

Компания использует WEEEK для трёх ключевых направлений: разработки, продукта и поддержки.

Изображение предоставлено сервисом WEEEK с сайта https://weeek.net/ru
  1. Поддержка
    Тикеты создаются вручную сотрудниками службы поддержки после обращения пользователей. Для оценки применяется двойная система ранжирования:
  • Одна определяет ценность клиента
  • Другая оценивает критичность проблемы, помогая разработчикам определить срочность решения
  1. Продуктовая разработка
    Работа строится на Канбан-досках:
  • Эпики (верхнеуровневые задачи) отбираются на 4 месяца вперёд
  • Каждая задача содержит ссылки на макет в Figma и описание в Эсборд
  • Эпики помечаются тегами, указывающими:
    • Тип задачи (новая функция, улучшение, исправление раздражающего поведения)
    • Принадлежность к конкретному функционалу или модулю
Изображение предоставлено сервисом WEEEK с сайта https://weeek.net/ru

Декомпозиция на User Story происходит с учётом данных из четырёх источников:

  • Запросы от техподдержки
  • Обратная связь от отдела продаж
  • Пользовательские исследования
  • Голосования через сервис «Предложить фичу»

Оценка сроков выполняется на мини-диаграмме Ганта в Эсборд.

  1. Разработка
  • Дизайнеры подготавливают макеты и передают задачи в колонку «Готово»
  • Перед передачей в разработку проводится тим-ревью (обсуждение с командой-исполнителем)
  • Сложные задачи могут возвращаться на доработку после обсуждения
  • QA и автоматизация работают с отдельной доской для багов и технического долга
  • Баги регистрируются с детальным описанием условий возникновения и приоритизируются по матрице критичности
Изображение предоставлено сервисом WEEEK с сайта https://weeek.net/ru

Такой подход обеспечивает сквозное управление задачами — от идеи до реализации — с сохранением прозрачности на всех этапах.

Основной рабочий процесс выстроен через систему Канбан-досок. В первой колонке («Неприоритизированный бэклог») накапливаются задачи, запланированные к выполнению в ближайшее время. Во второй колонке («Приоритизированный бэклог») задачи располагаются в порядке убывания важности — чем выше позиция, тем выше приоритет.

Еженедельно на планировочных созвонах команда анализирует задачи из приоритизированного бэклога, назначает исполнителей и перемещает задачи в следующие статусы:

  • Декомпозиция
  • Технический дизайн
  • Реализация
  • Накопительная доска для готовых задач

После завершения разработки задача проходит этап dev QA, где либо принимается, либо возвращается на доработку. Выпуск функционала осуществляется в два этапа: сначала в облачную версию продукта, затем в коробочную версию.

Такой подход обеспечивает:

  • Чёткую визуализацию приоритетов
  • Регулярное планирование работ
  • Контроль качества на каждом этапе
  • Поэтапный вывод функционала к пользователям
Изображение предоставлено сервисом WEEEK с сайта https://weeek.net/ru

База знаний

Компания планирует разработать комплексную систему документации, объединяющую:

  • Внутреннюю базу знаний для сотрудников (онбординг, управление командами, административные инструкции)
  • Пользовательскую базу знаний для B2C-клиентов (руководства, FAQ, troubleshooting)

Ключевые требования к системе:

  1. Гибкое управление доступом:
    • Разделение контента на публичный и внутренний
    • Возможность настройки прав доступа для разных групп пользователей
  2. Публикация в интернете:
    • Размещение на собственном домене
    • Поддержка SEO и индексации поисковыми системами
  3. Единая платформа:
    • Совмещение пользовательской и внутренней документации
    • Исключение дублирования информации
  4. Структурирование контента:
    • Интуитивная навигация и поиск
    • Категоризация материалов по темам и аудиториям

Пример реализации:

  • Публичный раздел: инструкции по использованию продукта, FAQ
  • Внутренний раздел: процессы онбординга, административные руководства
  • Гибридные материалы: техническая документация (доступна обоим сегментам)

Такой подход позволит:

  • Сократить время на обучение новых сотрудников
  • Уменьшить нагрузку на службу поддержки
  • Обеспечить единый источник достоверной информации
  • Повысить прозрачность и доступность знаний о продукте
Изображение предоставлено сервисом WEEEK с сайта https://weeek.net/ru

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

Чего нет в WEEEK

Проблемы текущего workflow и предложения по улучшению

  1. Массовые операции с задачами
  • Проблема: Отсутствие функции массового выделения задач. Пользователь вынужден вручную перемещать 15+ User Story, назначать исполнителя или менять доску для каждой карточки по отдельности.
  • Решение: Реализовать функцию множественного выбора задач (через чекбоксы или клавишу Ctrl/Cmd). Это позволит:
    • Массово перемещать группы задач между статусами или досками.
    • Назначать одного исполнителя на несколько задач.
    • Проставлять общие теги для группы карточек.
    • Изменять сроки или приоритет для выбранных элементов.
  1. Группировка задач по статусам
  • Проблема: Невозможно сгруппировать задачи по статусу, чтобы получить сводную картину по всем командам. Текущее отображение требует ручного анализа каждой доски.
  • Решение: Внедрить представление типа “Группировка по статусу” в дополнение к текущим канбан-доскам. Это даст возможность:
    • Видеть все задачи в определенном статусе (например, “В работе”, “На тестировании”) across different projects.
    • Быстро находить “бутылочные горлышки” и зависшие задачи.
    • Сравнивать нагрузку между командами в разрезе статусов.

Выгода от внедрения:

  • Экономия времени: Сокращение рутинных операций на 60-70%.
  • Повышение прозрачности: Мгновенное получение сводной информации о ходе работ.
  • Улучшение планирования: Возможность быстро перераспределять ресурсы между задачами.

Данные улучшения существенно повысят эффективность работы с большими объемами задач в WEEEK, особенно для проектов с кросс-функциональными командами.