В 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‑чатов мы уверенно видели примерно неделю вперёд. Сейчас у нас есть структурированный бэклог и понимание контент‑плана примерно на два месяца.
И, пожалуй, это главный результат переезда.
Кайтен не заставил редакторов полюбить таск‑трекеры, не отменил срочные задачи и не решил проблему двух разных систем у контента и продукта.
Он сделал другое: превратил большую часть работы из набора переписок и договорённостей в процесс, который наконец можно увидеть целиком.
