«А где это зафиксировано?»: как мы начали строить базу знаний там же, где ведем задачи

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

Отсюда всё и началось.

Когда маркетинг готовит анонс новой фичи, им важно понимать не только, что выходит, но и почему. Как было раньше: мы обсуждали что-то на встречах, часть проговаривали в комментариях к задаче в трекере, что-то еще оседало в чатах. Базы знаний у нас не было. Точнее, она была — но в голове у одного человека: у меня. Почти каждый день я слышал: «А где это зафиксировано?». Особенно от новичков — им было сложно понять, почему мы пришли к текущим решениям.

В общем, у нас не было системы. Была лишь привычка решать вопросы быстро — в чате, на созвоне, в комментариях к задачам.

Для больших договоренностей мы заводили Google Docs: план запуска, распределение ответственности, правила работы продукта и маркетинга. Пока таких файлов было немного, это все работало.

Проблемы начались, когда таких документов стало много. Появлялись версии с похожими названиями — и было неясно, какая из них реально актуальная. Плюс, документы жили отдельно от задач: продукт работал в одном инструменте, маркетинг — в другом, а Docs — где-то сбоку. Чтобы понять контекст, нужно было сначала найти нужный файл. Как вы понимаете, часто было проще спросить меня.

Сначала мне казалось, что дело в дисциплине: надо просто чаще напоминать фиксировать договоренности. Мы пробовали — на встречах, в чатах, в личных сообщениях. Иногда работало, но ненадолго. 

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

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

В один момент это просто стало очевидно.

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

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

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

Процесс поменялся: решения начали фиксировать прямо на встречах. 

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

Со временем появилась понятная структура. Документы раскладывались по папкам внутри рабочих пространств: отдельные — для продукта, отдельные — для маркетинга, общие — для совместных процессов. Контекст перестал разрастаться в хаотичный набор файлов.

Плюс мы перестали держать рабочие документы «в отдельном облаке». Всё оказалось внутри Kaiten — там же, где команда ведёт задачи и проводит обсуждения.

Документы в Kaiten не решили все проблемы автоматически. Часть вопросов закрылась сразу, с частью пришлось разбираться отдельно.

Быстрее всего улучшился доступ к контексту: решения перестали теряться между чатами и файлами. Если вопрос касался задачи или проекта, ответ обычно был рядом — в документе в том же пространстве или по ссылке из карточки.

Но дальше магии не произошло.

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

Чаты остались частью процесса. Telegram остался основным местом для быстрых вопросов. Разница была в другом: если обсуждение приводило к решению, его нужно было зафиксировать в документе. Первое время за этим приходилось следить.

Документы подходят не для всего. Например, технические спецификации с диаграммами, сложными схемами и визуальными сценариями удобнее хранить в специализированных инструментах: Figma для интерфейсов и пользовательских флоу, Miro или draw.io — для архитектурных схем и связей.

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

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

• решения принимаются быстро, а возвращаться к их контексту приходится спустя недели или месяцы;

• контекст важен для новых участников, и онбординг тормозится из-за переписок и устных договорённостей;

• задачи уже ведутся в таск-трекере, и команда проводит в нём большую часть рабочего дня;

• есть готовность фиксировать договорённости, а не надеяться, что все всё запомнят.