Мы очень активно используем Кайтен — и почти не заходим в него руками. Туда ходят наши боты.
У нас на основной доске 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 Кайтена сейчас покрывает всё: за всё время не нашлось ни одного сценария, который мы хотели бы построить и не смогли из-за ограничений. Для трекера это лучший комплимент, который я знаю. Несколько нюансов мы заложили в архитектуру:
Вебхуки приходят без повторов — событие отправляется один раз, поэтому вебхук у нас работает ускорителем, а источником правды остаётся регулярный обход карточек;
Важные значения кастомных полей мы на всякий случай дублируем текстом в описании карточки;
Дочерняя карточка создаётся в два шага, между ними нужна небольшая пауза — мы её заложили;
История карточки не отдаёт перемещения между колонками, поэтому текущее положение читаем напрямую из её состояния;
Чеклисты разворачиваются при запросе одной карточки, а не в списочных запросах — чуть больше запросов, но архитектурно решаемо.
Что получилось в итоге
Кайтен у нас — хранение данных. Все карточки, статусы, дедлайны, ссылки на файлы там, и только там. Спор «где финальный файл» не стоит — он там, куда ведёт ссылка из карточки. Вопрос «что с этой статьёй» больше не надо задавать человеку: он задаётся доске, и его видно. Или можно спросить бота — и бот ещё подскажет, если будет задержка.
В интерфейс Кайтена руками заходят менеджеры — на планировании, когда нужна вся картина целиком. Остальная команда трекер почти не открывает. Рутина сжалась в разы, ни один текст не уходит без машинной проверки, процессы соблюдаются. Раньше заметная часть работы менеджера состояла из перекладывания: файл — из чата на диск, статус — из головы в трекер, задачу — от редактора к бильду. Теперь транспортом работает бот, а правила передачи описаны в документации, а не живут в головах. Новый человек получает задачи с инструкциями прямо в личку, и длинный онбординг в хитрую схему досок ему уже не нужен.