В Russian Business меня позвали, чтобы я наладила процессы внутри команды.

До перезапуска проект много лет существовал под брендом Rusbase. В сентябре 2024 года Альфа-Банк стал стратегическим партнёром RB.RU и приобрёл долю в компании, а 7 августа 2025 года медиа перезапустилось под новым брендом Russian Business.

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

Очень быстро у этой системы обнаружились четыре больных места.

— Главред не видела реальную загрузку редакции. Один редактор мог одновременно вести пять больших материалов, а у другого в этот момент было заметно меньше задач. Чтобы понять реальную картину, приходилось постоянно пинговать людей — а времени на это ни у кого не было.

— Никто не понимал, на каком этапе находится материал. Статья уже на вычитке? Ждёт визуалов? Зависла у автора? Чтобы выяснить это, снова приходилось поднимать переписки.

— Хорошие темы терялись. Редактор мог предложить сильную идею, начать собирать фактуру, отвлечься на срочную задачу — и через месяц тема оказывалась погребена под сообщениями.

— Горизонт планирования сузился примерно до недели. Мы хорошо понимали, что выйдет прямо сейчас, но дальше начиналась неразбериха. Любая срочная задача ломала планы, потому что общего бэклога с актуальными статусами просто не существовало.

Держать всё это в голове невозможно. А увидеть полную рабочую картину, если она разбросана по чатам, — тем более.

Как редакция жила до масштабирования

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

Изначально редакция была небольшой: главред, шеф-редактор, арт-директор, несколько редакторов и дизайнеров. Потом команда выросла: появился коммерческий отдел со своим продакшеном, продуктовая команда, новые редакционные направления.

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

Но команда и объём задач выросли — и эта схема перестала работать.

Да и сами Telegram-чаты мы воспринимали скорее как перевалочный пункт. Было понятно, что вечной системой управления они не станут. Оставалось понять, куда переезжать.

Идеи тухли из-за неразберихи

Сначала мы работали в Google Таблицах.

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

Следующим шагом стала Figma.

С ней всё стало интереснее. Мы сделали доску с бэклогом, куда авторы набрасывали темы, и организовали две линии стикеров — для сайта и Telegram. Всё можно было свободно перемещать, а арт-директор ставил на темы метки вроде «сделано», «в работе» и «не сделано».

Визуально система выглядела отлично. Но довольно быстро проявились ограничения.

Во-первых, нам не хватало нормальной фильтрации по рабочим признакам. Мы выпускаем материалы день в день и на сайте, и в соцсетях. Чтобы понять, сделали ли мы уже Telegram-пост по большой статье, мне приходилось глазами проходить по доске и сопоставлять карточки.

Во-вторых, возник вопрос отчётности.

Совету директоров нужно понимать, сколько контента мы выпускаем и как распределяется работа. Кто пишет лонгриды, на которые уходит много времени? Кто и в каком объёме занимается соцсетями? Как загружен дизайн? Сколько вообще единиц контента производит команда?

Из нашей системы в Figma эти ответы автоматически не получались.

В-третьих, процессы начали расходиться между отделами. Редакция работала в Figma, дизайнеры забирали оттуда задачи и переносили их в Notion. В результате единой картины снова не было.

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

Страх и ненависть в таск-трекерах

От хаоса устали все, поэтому главред поддержала идею перенести рабочий процесс в таск-трекер.

Можно было перенять опыт коллег из Альфа-Банка, но Jira мне для нашей редакции не нравилась. Для больших технических команд этот инструмент может быть отличным, но нам хотелось более лёгкой системы, которую не придётся долго объяснять редакторам и дизайнерам.

Следующим кандидатом стал Яндекс Трекер.

На бумаге всё выглядело логично: рабочие почты у нас были на Яндексе, сервис российский, можно было собрать всё в одной экосистеме. Я несколько недель тестировала Трекер, но интерфейс оказался для меня довольно тяжёлым.

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

Посмотрела ещё WEEEK и Битрикс24 — тоже не подошли.

И тут вспомнила, что на одном из проектов в SETTERS мы пользовались Кайтеном. Я написала бывшим коллегам и попросила показать их рабочую доску. Доступ внутрь давать не стали, зато предложили созвониться и расшарить экран.

На созвоне я посмотрела, как у них всё устроено, и решила: это как минимум стоит попробовать.

Как мы пробовали Кайтен

Первым активно внедрять трекер начал коммерческий отдел.

На коллег сильнее давила ответственность перед клиентами: им было особенно важно видеть, где находится задача и что с ней сейчас происходит. Они первыми пришли в Кайтен и начали перестраивать пространства под себя.

Следом подключилась я и занялась процессами редакции и дизайна.

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

На старте с редакцией и дизайном я сама допустила архитектурную ошибку.

Я создала два параллельных пространства: одно для текстов, второе для визуала. Схема выглядела так: редактор отмечает арт-директора в своей карточке, тот переносит задачу к дизайнерам и распределяет её внутри команды.

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

Поэтому редакцию и дизайн мы объединили в одном рабочем пространстве. Коммерческий отдел оставили отдельно — у него свои потоки задач.

Готовые шаблоны Кайтена под наш процесс не подошли, поэтому структуру я собирала сама. Сделала несколько досок — в том числе отдельные для редакционных и дизайнерских этапов — и настроила движение карточек между ними.

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

С Figma мы, правда, расстались не сразу.

Ещё примерно полтора месяца там продолжала жить визуальная сетка контент-плана по дням недели. Стандартное календарное представление в Кайтене не решало именно нашу задачу: мне нужна была очень конкретная недельная сетка, которую команда привыкла видеть целиком.

В итоге я собрала её иначе: обычные колонки стали днями недели, а связанные материалы мы выводили туда через дочерние карточки.

Получился не «календарь из коробки», а наша собственная конструкция. Зато команде она была понятна.

Команда упиралась изо всех сил

Переезд, разумеется, прошёл не идеально.

Я понимала, что просто объявить: «С завтрашнего дня все работаем здесь» — не получится. Поэтому никаких ультиматумов не ставила.

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

С тегами был отдельный разговор. Мне было важно, чтобы они не просто делали карточки красивее, а помогали разделять задачи и фильтровать аналитику.

Например, по тегу дизайнер сразу понимает тип материала и примерный визуальный язык. А я потом могу посмотреть, контента какого типа мы выпустили больше.

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

На второй — аккуратно перетащили туда остальной бэклог.

Это оказалось правильным решением. Пересадить творческую команду в новый инструмент за один день было бы нереально.

При этом сопротивление полностью никуда не исчезло.

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

Есть и редакционное направление, которому Кайтен не нужен, — новости.

Новостной поток слишком быстрый: заводить отдельную карточку под каждый инфоповод было бы дороже по времени, чем продолжать работать через оперативные чаты. Поэтому новости остались там.

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

Но и это зашло не всем. Некоторым редакторам проще дважды в день открыть доску, чем заводить ещё один источник уведомлений.

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

При этом даже сейчас в Кайтене находится не вся команда Russian Business.

Например, разработка использует Яндекс Трекер. Наш Product Owner зашёл в Кайтен, посмотрел на него и решил, что для его задач привычная система подходит лучше.

Из-за этого остаётся слепая зона: продуктовый бэклог живёт в другом трекере, а мы как заказчики фич не всегда сразу видим, взяли нашу задачу в работу или нет.

Формально доступ к Яндекс Трекеру у нас есть. Но необходимость постоянно переключаться между двумя системами всё равно создаёт трение.

Теперь я вижу загрузку редакции — хотя бы там, где раньше был хаос

Главное изменение для меня — появилась наблюдаемость.

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

Суета не исчезла совсем — редакция всё-таки остаётся редакцией. Срочные задачи случаются, дедлайны двигаются, люди иногда забывают обновлять карточки.

Но теперь это происходит поверх понятной системы, а не вместо неё.

Контекст по большинству задач больше не растворяется в переписках, а статус материала можно проверить без отдельного расследования.

Изменился и горизонт планирования.

Во времена Telegram-чатов мы уверенно видели примерно неделю вперёд. Сейчас у нас есть структурированный бэклог и понимание контент-плана примерно на два месяца.

И, пожалуй, это главный результат переезда.

Кайтен не заставил редакторов полюбить таск-трекеры, не отменил срочные задачи и не решил проблему двух разных систем у контента и продукта.

Он сделал другое: превратил большую часть работы из набора переписок и договорённостей в процесс, который наконец можно увидеть целиком.