Use One Knowledge Base for End-to-End Product Delivery
Є реальні бізнес-ризики, пов’язані з роботою в ізоляції. Дивіться, чому вашій компанії потрібна справжня централізована база знань для забезпечення ефективності.
“Я знаю, що вони щось роблять, я просто не зовсім впевнений, що це щось.”
Скільки разів ви чули (або, давайте будемо чесними, сказали) ці слова з одного з ваших колег на адресу іншої команди або департаменту? Нам легко загубитися в своїх куточках компанії у повсякденній роботі, що іноді призводить до нестачі розуміння того, що наші колеги з іншого боку допомагають нашому бізнесу функціонувати. І це недаремно: залишатися зосередженим на своїх власних сферах експертизи та відповідальності допомагає всім зростати у своїх функціях. Але що трапляється, коли цей погляд стає таким вузьким, що команди не можуть бачити, як їхня робота впливає на решту компанії?
Знання компанії прагнуть бути крос-функціональними
Коли команди бачать свої функції в ізоляції, вони часто також бачать знання своєї команди в ізоляції. Для команд з маркетингу це може означати персонажі покупців або описи позиціонування функцій. Для інженерних команд це може означати технічну документацію або інструкції з налаштування середовища. А для команд підтримки це може означати відповіді на запитання, що часто задаються, або посібники з усунення несправностей для помилок функцій. Ці ресурси можуть бути присутніми у будь-якій кількості інструментів, на які покладаються окремі команди, таких як Google Drive, GitHub, Intercom тощо, і можуть належати як колективно, так і одному лідеру/спеціалісту в команді, який зосереджується на документації.
На поверхневому рівні має сенс, що різні команди потребують різних інструментів документації, щоб найкраще відповідати своїм робочим процесам, але в міру заглиблення ми виявляємо реальні бізнес-ризики, пов’язані з ізоляцією.
Як ізоляція знань впливає на операції
Більшість документації передбачає крос-функціональну співпрацю у якомусь вигляді. Давайте розглянемо приклад агента підтримки, який оновлює статтю центру допомоги про функцію. Агент може почати з популярних запитань, які були зібрані його командою, а потім йому потрібно буде співпрацювати з інженерною командою, щоб отримати відповіді. Деякі з цих відповідей документуються в GitHub, але більшість з них відповідно до знань одного експерта.
Після того, як агент підтримки отримав ці відповіді, йому можливо, також потрібно буде порадитися зі своєю командою маркетингу продуктів, щоб переконатися, що вони використовують правильну термінологію для переваг цієї функції. Команда маркетингу продуктів тоді може надіслати односторінковий документ зі свого Google Drive, у якому міститься деяке повідомлення з минулорічного запуску функції, яке може бути застарілим. Нарешті, агент підтримки зв’язується з командою продажів, щоб подивитися, чи є в них додаткові запитання для додавання, і якщо вони є, то їм також потрібно буде ще раз перевірити з інженерами.
На той час, коли агент підтримки підготував свою нову статтю центру допомоги, він поспілкувався з колегами по всій компанії, які всім довелося звертатися до своїх окремих каналів знань, щоб знайти підтримуючу інформацію. І це, якщо все проходить гладко. Що може статися, якщо інженер, який є експертом з цієї функції, у відпустці цього тижня? Або якщо команда продажів усвідомлює, що у них є додаткові запитання, але вони розкидані по різних каналах Slack? З кожною перешкодою терміни подовжуються, і все більше можливостей для витоку знань та непорозумінь виникає.
Організуйте інформацію компанії. Отримуйте до неї доступ в будь-якому місці.
Тепер давайте розглянемо альтернативний сценарій - такий, де всі команди ділять місце для документування та доступу до важливої актуальної продуктної інформації. Коли агент підтримки звертається до інженерної команди спочатку з питаннями, інженерній команді не потрібно хвилюватися, якщо експерт у відпустці цього тижня — вони раніше поділилися своєю експертизою з рештою команди через спільну базу знань.
Замість того, щоб команда маркетингу продуктів надсилала можливо застарілу інформацію, написану рік тому, вони отримують свою актуалізовану інформацію про повідомлення та позиціонування, яку вони перевіряють на точність щоквартально. І замість того, щоб команда продажів бурякових каналів Slack шукала запитання, на які вони раніше шукали відповіді, у них все це документується в спільній платформі, яку потім легко надіслати.
Що краще в цьому всьому процесі, так це те, що агент підтримки може навіть знайти багато цієї інформації самостійно, не відволікаючи інших від їх робочих процесів, просто стежачи.
Коли вся ця інформація зберігається в специфічних для команди ізольованих інструментах, самостійне отримання знань просто неможливе.
Ролі реального часу співпраці між колегами ніколи не буде усунуто; зрештою, саме ці взаємодії допомагають нам встановлювати зв’язки один з одним та співпереживати. Але на багатьох етапах протягом циклу доставки продукту і надання послуг існують завдання, які можуть бути виконані значно ефективніше, коли знання демократизовані між усіма командами. Як знання, так і експерти в предметній області можуть продовжувати свою роботу без перерв, і можуть зберегти свої ресурси для співпраці у реальному часі на більш значної та креативної роботи.
“Я знаю, що вони щось роблять, я просто не зовсім впевнений, що це щось.”
Скільки разів ви чули (або, давайте будемо чесними, сказали) ці слова з одного з ваших колег на адресу іншої команди або департаменту? Нам легко загубитися в своїх куточках компанії у повсякденній роботі, що іноді призводить до нестачі розуміння того, що наші колеги з іншого боку допомагають нашому бізнесу функціонувати. І це недаремно: залишатися зосередженим на своїх власних сферах експертизи та відповідальності допомагає всім зростати у своїх функціях. Але що трапляється, коли цей погляд стає таким вузьким, що команди не можуть бачити, як їхня робота впливає на решту компанії?
Знання компанії прагнуть бути крос-функціональними
Коли команди бачать свої функції в ізоляції, вони часто також бачать знання своєї команди в ізоляції. Для команд з маркетингу це може означати персонажі покупців або описи позиціонування функцій. Для інженерних команд це може означати технічну документацію або інструкції з налаштування середовища. А для команд підтримки це може означати відповіді на запитання, що часто задаються, або посібники з усунення несправностей для помилок функцій. Ці ресурси можуть бути присутніми у будь-якій кількості інструментів, на які покладаються окремі команди, таких як Google Drive, GitHub, Intercom тощо, і можуть належати як колективно, так і одному лідеру/спеціалісту в команді, який зосереджується на документації.
На поверхневому рівні має сенс, що різні команди потребують різних інструментів документації, щоб найкраще відповідати своїм робочим процесам, але в міру заглиблення ми виявляємо реальні бізнес-ризики, пов’язані з ізоляцією.
Як ізоляція знань впливає на операції
Більшість документації передбачає крос-функціональну співпрацю у якомусь вигляді. Давайте розглянемо приклад агента підтримки, який оновлює статтю центру допомоги про функцію. Агент може почати з популярних запитань, які були зібрані його командою, а потім йому потрібно буде співпрацювати з інженерною командою, щоб отримати відповіді. Деякі з цих відповідей документуються в GitHub, але більшість з них відповідно до знань одного експерта.
Після того, як агент підтримки отримав ці відповіді, йому можливо, також потрібно буде порадитися зі своєю командою маркетингу продуктів, щоб переконатися, що вони використовують правильну термінологію для переваг цієї функції. Команда маркетингу продуктів тоді може надіслати односторінковий документ зі свого Google Drive, у якому міститься деяке повідомлення з минулорічного запуску функції, яке може бути застарілим. Нарешті, агент підтримки зв’язується з командою продажів, щоб подивитися, чи є в них додаткові запитання для додавання, і якщо вони є, то їм також потрібно буде ще раз перевірити з інженерами.
На той час, коли агент підтримки підготував свою нову статтю центру допомоги, він поспілкувався з колегами по всій компанії, які всім довелося звертатися до своїх окремих каналів знань, щоб знайти підтримуючу інформацію. І це, якщо все проходить гладко. Що може статися, якщо інженер, який є експертом з цієї функції, у відпустці цього тижня? Або якщо команда продажів усвідомлює, що у них є додаткові запитання, але вони розкидані по різних каналах Slack? З кожною перешкодою терміни подовжуються, і все більше можливостей для витоку знань та непорозумінь виникає.
Організуйте інформацію компанії. Отримуйте до неї доступ в будь-якому місці.
Тепер давайте розглянемо альтернативний сценарій - такий, де всі команди ділять місце для документування та доступу до важливої актуальної продуктної інформації. Коли агент підтримки звертається до інженерної команди спочатку з питаннями, інженерній команді не потрібно хвилюватися, якщо експерт у відпустці цього тижня — вони раніше поділилися своєю експертизою з рештою команди через спільну базу знань.
Замість того, щоб команда маркетингу продуктів надсилала можливо застарілу інформацію, написану рік тому, вони отримують свою актуалізовану інформацію про повідомлення та позиціонування, яку вони перевіряють на точність щоквартально. І замість того, щоб команда продажів бурякових каналів Slack шукала запитання, на які вони раніше шукали відповіді, у них все це документується в спільній платформі, яку потім легко надіслати.
Що краще в цьому всьому процесі, так це те, що агент підтримки може навіть знайти багато цієї інформації самостійно, не відволікаючи інших від їх робочих процесів, просто стежачи.
Коли вся ця інформація зберігається в специфічних для команди ізольованих інструментах, самостійне отримання знань просто неможливе.
Ролі реального часу співпраці між колегами ніколи не буде усунуто; зрештою, саме ці взаємодії допомагають нам встановлювати зв’язки один з одним та співпереживати. Але на багатьох етапах протягом циклу доставки продукту і надання послуг існують завдання, які можуть бути виконані значно ефективніше, коли знання демократизовані між усіма командами. Як знання, так і експерти в предметній області можуть продовжувати свою роботу без перерв, і можуть зберегти свої ресурси для співпраці у реальному часі на більш значної та креативної роботи.
Досвідчіть силу платформи Guru особисто – пройдіть наш інтерактивний тур продуктом
.webp)
