Tool Stack 2026: ежедневные операции команды Roibase

Разговоры о tool stack обычно сводятся к каталогу "мы используем эти приложения". Но главное — не сами инструменты, а паттерн интеграции, стоимость переключения контекста, дисциплина async-first. В Roibase команда из 12 человек работает remote-first с 2018 года. В 2026 году ежедневные операции определяют 5 инструментов: Linear, Notion, Slack, Figma, Granola. В этой статье вместо перечисления приложений мы раскрываем интеграционный слой — где живут данные, какие workflows срабатывают, какие notification слои отключены.

Linear: не спринты, а метрики потока

Linear позиционируется как инструмент управления проектами, но в Roibase это "слой видимости work-in-progress". Планирование спринтов не проводим — циклы и милestоны не используем. Вместо этого каждой задаче присваиваем priority (P0/P1/P2) и estimate (1-3-5-8). Priority определяет система, не человек: P0 = блокирует деплой сегодня, P1 = должна закрыться в спринте, P2 = backlog.

Метрики потока:

Cycle time: в среднем 2,3 дня от открытия задачи до закрытия (данные Q4 2025). Задача, превышившая 5 дней, автоматически повышается до P0.
Лимит work-in-progress: максимум 3 открытых задачи на человека. Чтобы взять 4-ю, нужно закрыть одну или передать другому.
Время merge-to-close: промежуток от merge PR до закрытия задачи в Linear — целевой показатель <30 минут (CI/CD + QA автоматизация).

Интеграция Linear со Slack отключена. Вместо бомбардировки уведомлениями работает система дайджестов: каждое утро в 09:00 в Slack канал отправляется ежедневная сводка (количество P0 задач, средний cycle time, распределение WIP). Никто не тегирует в Linear — все читают утренний дайджест.

Синхронизация Linear → Notion

Завершённые задачи из Linear раз в неделю архивируются в Notion (через Zapier workflow). В Notion'е есть "Retrospective Database" — каждая закрытая задача тегируется по соответствующему сервису. Например, задачи проекта branding отчитываются под услугой Брендинг и идентификация бренда. Эти данные используются раз в квартал для планирования ёмкости: сколько инженерных часов уходит на каждую услугу?

Notion: источник истины, не вики

Notion не используется как вики — это "журнал решений". Каждое стратегическое решение (например, "server-side или client-side tracking в кампании X?") записывается в формате RFC (Request for Comments). Шаблон RFC:

## Решение
[Одно предложение — что делаем]

## Контекст
[Почему нужно прямо сейчас]

## Альтернативы
[Минимум 2 варианта + таблица tradeoff'ов]

## Измерение
[Как узнаем через 4 недели, правильно ли решили]

## Ответственность
[Кто собственник решения]

После открытия RFC идёт 48-часовой async период для комментариев. Никто не организует встреч — каждый читает в своё время, оставляет комментарий. Через 48 часов владелец решения пишет финальное решение, переводит в Linear.

Слои данных в Notion:

RFC Database — все решения
Retrospective Database — завершённые задачи из Linear
Client Playbook — операционные заметки по клиентам (где какой dashboard, где какой API key)
Brand Assets — ссылки на Figma, документ tone-of-voice

Поиск в Notion работает плохо, это верно, но мы не ищем — каждая база фильтруется и тегируется. Необходимость поиска обычно означает "я положил данные не туда".

Slack: асинхронность сначала, синхронность вторая

Notification система в Slack отключена для всей команды. Только @channel и @here включены — и есть правило: кроме P0 incidents запрещено. Сообщения разделены на 3 канала:

#daily-digest: сводки Linear/Notion, логи CI/CD деплоев
#async-questions: вопросы, на которые не ждут мгновенного ответа (24 часов достаточно)
#sync-now: нужна координация в реальном времени (production incident, оптимизация живой кампании)

Ожидания по времени ответа:

#sync-now → 15 минут
#async-questions → 24 часа
DM → 48 часов (DM культуры нет, используются каналы)

Использование threads в Slack обязательно. Ответ в основной канал запрещён — каждое сообщение открывает thread. Так параллельные разговоры не перекрывают друг друга.

Интеграция Slack → Granola

Granola — инструмент заметок о встречах, но в Roibase используется только для клиентских звонков. Internal встреч нет (0-1 sync call в неделю). После звонка с клиентом Granola отправляет AI-транскрипт в Slack, команда читает асинхронно. Action items автоматически преобразуются в Linear задачи (Zapier trigger).

Killer feature Granola: в транскрипте выделяет числовые обязательства ("результаты A/B теста через 2 недели", "CTR должен вырасти на 15%"). На них автоматически ставятся напоминания — никто не забывает.

Figma: не handoff дизайна, а живая спецификация

Figma не просто инструмент дизайна — это слой "frontend spec". Каждый UI компонент задан в Figma как вариант. Разработчик не копирует CSS из Figma — но читает логику поведения компонента именно там. Например, состояния button'а (hover, active, disabled) в Figma представлены как фреймы. В коде реализуется та же логика состояний.

Связь Figma → Linear: В каждом Figma файле установлен плагин Linear Issue. Когда дизайн одобрен, дизайнер открывает Linear issue прямо из Figma, вставляет ссылку на дизайн в description задачи. Когда разработчик берёт issue, он уже знает дизайн — реализует без вопросов.

Комментарии в Figma не текут в Slack (чтобы не было бомбардировки). Вместо этого раз в неделю "Figma Digest" — открытые комментарии превращаются в Linear задачи.

Паттерн интеграции: где живут данные?

Разговоры о tool stack обычно начинаются с "какой инструмент используешь". Но правильный вопрос: "какие данные где canonical?" В Roibase ownership данных распределён так:

Тип данных	Источник истины	Синхронизируется в
Активная работа (WIP)	Linear	Slack daily digest
Завершённая работа	Notion	Linear (archive)
Стратегические решения	Notion (RFC)	Linear (action items)
Заметки о клиентских звонках	Granola	Slack thread
UI спецификация	Figma	Linear issue description
Brand assets	Notion	Figma (embed link)

Dual source-of-truth не допускается. Если данные выглядят canonical в двух местах — одно из них неправильно.

Дисциплина уведомлений: когда молчать, когда шуметь

Главная опасность современного tool stack — notification creep. Стратегия уведомлений в Roibase:

Полностью отключено:

Mentions в Linear (используется Slack thread вместо комментариев)
Комментарии в Figma (еженедельный дайджест)
Обновления страниц в Notion (никто не смотрит)

Как дайджесты:

Linear ежедневная сводка (09:00)
Figma открытые комментарии (пятница 17:00)
CI/CD логи деплоев (сводка после каждого деплоя)

Real-time:

@channel (только P0 incidents)
Granola сводка по клиентскому звонку (в течение 5 минут после звонка)
Production ошибки (Sentry → Slack, но только в #sync-now)

При подключении любого инструмента первый вопрос: "это notification должен быть real-time или в дайджесте?" Ответ по умолчанию — дайджест.

Что делать сейчас?

В разговорах о tool stack вместо рефлекса "давайте добавим ещё один инструмент" спроси: "где должны жить эти данные в canonical виде?" Stack Roibase в 2026 году — Linear/Notion/Slack/Figma/Granola, но инструменты могут меняться. Важны паттерн интеграции, дисциплина уведомлений, культура async-first. Если в команде слышишь "я не получаю уведомление из tool X" — проблема не в инструменте, а в нечётком ownership данных.