Как мы почти не заходим в Кайтен руками — и при этом живём в нём весь день

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

Привет, я Катя Берестовая из агентства Loft. С 2008 года мы делаем контент‑маркетинг для компаний. За каждым текстом — интервью с инженером, который «на встрече всё расскажет», фактчекинг, согласования с юристами клиента и редактура. Кайтен попросил рассказать, что мы про них думаем. История получилась нетривиальная: мы очень активно используем сервис управления процессами Кайтен — и почти не заходим в него руками. Туда ходят наши боты, а боты уже разговаривают с редакторами, там где им удобнее — в привычных чатах в Телеграм. Расскажу, как мы к этому пришли.

Как выглядит производство одной статьи

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

И это короткий счастливый путь — без «клиент передумал про третий раздел» и без второго круга правок. На нашей основной доске в Кайтене 19 колонок, и во многих статья может спокойно зависнуть на 3–4 недели. Один текст за свою жизнь проходит через руки шести‑восьми человек: главред, редактор, интервьюер, корректор, верстальщик, клиентский менеджер, пиарщик заказчика, спикер. Таких текстов в работе одновременно — десятки, в месяц мы выпускаем порядка 100–300 материалов. Каждая передача между людьми — это место, где задача может упасть и лежать.

Где всё это болело

Боль номер один — версии файлов. Редактор внёс правки, но файл на Я.Диске не менялся с прошлого вторника. Правки ушли куда‑то — в другую копию, в голову, в планы на завтра. В творческих коллективах это случается чаще, чем можно подумать.

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

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

И фоновая боль, которая объединяет всё: реальная жизнь команды идёт в Телеграме. Решения, файлы, «глянь вёрстку» — всё в чатиках. Сообщение в рабочем чате живёт минут двадцать, потом уезжает вверх — и всё, упс.

Почему трекеры у нас не работали

С Кайтеном поначалу было непросто: мы занесли все данные и начали настраивать автоматизации под свои процессы — а они специфические. Например, нам нужно было, чтобы комментарии и файлы переносились с дочерних карточек на родительскую. Из коробки часть сценариев не закрывалась. Зато пространства и дорожки сразу дали развести клиентов и направления, а дочерние карточки устроены как полноценные задачи, связанные с родительской — на этом строится вся наша схема «у статьи есть мастер‑карточка, а у каждого исполнителя своя задача на своей доске».

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

Почему мы сделали ставку на API

У Кайтена обнаружилось на редкость взрослое API. Карточки, дочерние задачи, чеклисты, теги, комментарии, кастомные поля, файлы, внешние ссылки, вебхуки на события — всё открыто и документировано, ничего не спрятано за тариф «Энтерпрайз» и фразу «обратитесь в отдел продаж». Это редкость: у многих систем API выглядит как чулан, куда вынесли то, что жалко выбросить.

Отдел разработки из одного гуманитария

Я не разработчик. По образованию — журналист‑редактор. Всех ботов, о которых пойдёт речь, я написала в Claude Code. Выглядит это так: я подробно описываю процесс («когда редактор закрывает вот эту задачу, надо проверить вот это и передвинуть вот то»), модель пишет код, я тестирую на живом процессе и возвращаюсь с багами. Главным навыком оказалось умение исчерпывающе объяснить собственный процесс — то есть навык менеджера, а не программиста. Если вы можете написать внятный регламент, вы можете написать бота.

Чтобы это не звучало несерьёзно: у каждого бота есть документация, changelog, журнал инцидентов и регрессионные тесты. Без этого ИИ‑ассистент на третьей неделе начинает чинить одно и ломать другое. Хостится всё на Railway, внутри Python, под данными Postgres и Redis. Полтора года назад я эти слова знала, но не знала, чем они отличаются друг от друга.

Четыре бота, которые ходят в Кайтен вместо людей

Мост — интеграционный помощник. Раз в минуту днём и раз в 5 минут ночью обходит колонки доски и смотрит, что изменилось; вебхуки использует там, где они есть. Начинался как скромный скрипт для одного редактора, сейчас в нём 25 блоков автоматизации — по блоку на каждый шаг конвейера. Закрыл редактор задачу — Мост сам проверяет файл, пишет комментарий в родительскую карточку и двигает её дальше. Поставил главред тег готовности — карточка едет, исполнителю появляется следующая задача. Файл не менялся, а задачу закрыли — Мост сверяет имя и время изменения и не пропускает дальше. Комментарии между родительской и дочерними карточками синхронизирует автоматически. Каждое утро приносит в чат дайджест, в нерабочие дни людей не трогает.

Добби — заводит и ведёт карточки. На каждое клиентское событие создаёт папку проекта на Я.Диске, заводит карточку в Кайтене, прикрепляет ссылки и вписывает артикул в таблицу. Редактор просто кладёт готовый.docx в папку — Добби сам замечает новый файл, считает знаки, проставляет объём в кастомное поле и отправляет текст на корректуру. С картинками так же. Карточка живёт пять‑семь дней, около 50 шагов с ней делаются автоматически.

Фея — рутина и тексты. Собирает черновик брифа интервьюеру по истории постов заказчика и теме, пишет шаблоны дипломатических писем про правки, следит за важными комментариями и собирает фирменные PDF‑паспорта проектов. Редакторы общаются с ней голосовыми, она прогоняет их через Whisper.

Писец — редактор‑душнила и корректор. Появился раньше остальных. Вычитывает текст на сомнительные утверждения, логические дыры и формулировки, за которые потом будет стыдно или дорого: категоричные обещания, медицинские и финансовые заявления без оговорок. Ищет пиар- и ИБ‑риски, разбирает качество языка по трём десяткам критериев. Основной формат — DOCX с правками в режиме рецензирования. В нём сидит около 60 активных живых пользователей, по большей части из издательств и контент‑агентств; мы же работаем через API.

Что мы учли в работе с API

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

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

Что получилось в итоге

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