“Я знаю, что они что-то делают, я просто не совсем уверен, что именно это что-то.”

Сколько раз вы слышали (или, давайте будем честными, говорили) эти слова от одного из коллег в адрес другой команды или отдела? Нам легко потеряться в своих уголках компании в повседневной работе, что иногда приводит к недостатку понимания того, что делают наши коллеги по ту сторону, чтобы помочь нашему бизнесу функционировать. И на то есть хорошие причины: сосредоточение на своих собственных областях экспертизы и ответственности помогает всем развиваться в своих функциях. Но что происходит, когда этот взгляд становится настолько узким, что командам трудно видеть, как их работа влияет на остальных в компании?

Знания компании хотят быть межфункциональными

Когда команды видят свои функции в пустоте, они часто также видят знания своей команды в пустоте. Для маркетинговых команд это может означать прообразы покупателей или описания позиционирования функций. Для инженерных команд это может означать техническую документацию или инструкции по настройке окружения. А для команд поддержки это может означать ответы на часто задаваемые вопросы или руководства по устранению ошибок функций. Эти ресурсы могут находиться в любом числе инструментов, которые используют отдельные команды, таких как Google Drive, GitHub, Intercom и т. д., и могут находиться в общем пользовании или принадлежать лидеру/специалисту команды, который сосредоточен на документации.

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

Как изолированные знания влияют на операции

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

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

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

Организуйте информацию компании. Получите доступ к ней в любом месте.

Выберите план

Преимущества взаимосвязанного знания

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

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

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

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

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