Ну нет, настолько сильно диверсификацией продуктовой линейки компании мы еще не занялись :) Но сделать все то же самое своими руками, согласитесь, вполне реально.
Потому и пишу, что это прямо в крайнем случае. Хотя навести порядок в коммуникациях у себя в команде — вполне тимлидская задача.
Часто именно с небольших команд начинается глобальная инициатива по работе со знаниями.
Но полностью согласен с тем, что все же лучше профильных специалистов звать
***
Деврел — это профессия Development Relations. Можно подробно почитать вот здесь, например. В принципе, это человек, который делает ровно то, что я описал: отвечает за контакты разработчиков между собой и с остальной частью компании и внешним миром на понятном разработчикам языке.
Можно еще почитать вот эту полезную книгу.
Кстати, если вы тимлид, то могу еще вот этот доклад посоветовать посмотреть.
На вопрос про лейблы ответ, судя по этому таску, «нет». Производители не планируют реализовывать такую функцию. Сам я тоже нигде не нашел такой опции. Чтобы увидеть все материалы, содержащие данный тег, можно нажать на него под любой из статей.
Насчет всех своих подписок — «да». Можно нажать на иконку профиля в правом верхнем углу и выбрать в меню Watches.
Да, разные команды подчиняются разным руководителям, и их KPI непосредственно связаны с KPI их больших департаментов: обучения, поддержки, и т.д. Но т.к. цели департаментов привязаны к общей стратегии компании, то все частные KPI так или иначе влияют на выполнение общих KPI. Понятно, что цели и задачи у внешнего и внутреннего КМ, например, будут немного отличаться, но мы все завязаны в единую цепочку перемещения знаний внутри компании.
Взаимодействуем достаточно просто — созваниваемся раз в две недели, обсуждаем трудности и новости, договариваемся. Операционно — постоянно на связи в чатах. Менеджеры информируют команды о том, о чем договорились, собирают от них пожелания, и идет новый цикл обсуждения. Никакого рокет саенс нет — просто это все делается систематически.
По поводу зон ответственности, нельзя сказать, что они пересекаются, мы просто все завязаны в общий процесс. Информацию для клиентской базы знаний менеджер внешнего КМ узнает из внутренней базы, например. И если ее не обновить вовремя внутри, то она и снаружи останется старой. Или тренер в поддержке, который обучает сотрудников в смене на основе новостей от внутреннего КМ — если до него вовремя не донести информацию, то он продолжит доносить до сотрудников старые данные, а это скажется на качестве сервиса. И в то же время, если тренер не проинформирует внутренний КМ о том, что кто-то в поддержке столкнулся с новым типом обращений, на который в базе знаний не нашлось ответа, то мы не обновим внутренние материалы, и цепочка сработает в обратную сторону. Можно это назвать пересечением зон ответственности? Мне кажется, это просто взаимосвязанные процессы.
nerazzgadannaya Лана, привет! Спасибо за вопросы :)
1. Если говорить об одном человеке, который покроет все активности, то я бы поместил его во внутренние коммуникации. Потому что, если он один, то времени на постоянное обновление и создание контента, переговоры, анализ потребностей и еще массу смежных задач у него будет всегда не хватать. Значит, нужно будет поработать над созданием сети помощников в отдельных командах и департаментах, которая будет помогать именно с контентом, продвигать шеринг среди своих коллег. Проще всего, на мой взгляд, это сделать из интеркома, потому что тогда менеджер по знаниям будет как раз таки и заниматься выстраиванием внутренних коммуникаций, и можно будет и административный ресурс свободно применять, и KPI адекватно поставить.
2. Первое, что я бы порекомендовал — изучить текущую обстановку. Не лезть со своим видением в первую же неделю, не строить далекоидущие планы, основываясь только на своем опыте и предпочтениях в плане инструментов КМ. Нужно понять, чем занимается компания, как она этим занимается, послушать. что говорят сотрудники, выяснить, что уже делали до тебя, и почему этим перестали пользоваться. Месяца через 2 паззл сложится, и можно будет создавать стратегию по управлению знаниями внутри компании. Но сначала нужно иметь реальные цифры, мнения, предыдущий опыт на руках.
Из моего личного опыта в Exness, про всеобщий онбординг я уже рассказал в статье. Из последующего — через 1,5 месяца мы с командой провели опрос среди основных, очевидных целевых аудиторий касательно их удовлетворенности текущим состоянием базы, каналов информирования и портала для вопросов-ответов, а также их предпочтений по этим вопросам.
Еще через 2 недели внедрили средства веб-аналитики на портал базы знаний, чтобы оценивать популярность контента, строить карту наших посетителей, искать взаимосвязи между популярностью разных статей и нашими остальными действиями (анонсами, например). И вот только сейчас, имея первые цифры, начинаем работать над планом дальнейших действий.
Им это оказалось настолько жизненно важно, что они стали этим системно заниматься. То есть, именно в поддержке поняли, что издержки от отсутствия базы выше, чем если ее вести. А дальше просто люди, которые ее вели, прокачались в этом настолько, что вполне смогли заниматься этим и в масштабированном варианте.
Почему поддержке так была нужна база знаний? Это тоже тема для целого доклада — можно вот тут послушать www.youtube.com/watch?v=7-wstE0l8bQ.
А кто, по-вашему, должен этим заниматься?
Интересная история. У меня вот только есть два вопроса: а как шарятся знания, полученные на этих тренингах, внутри компании? Т.е. можно просто понять из матрицы, что изучали до тебя люди на твоей должности, и пойти изучить, потратить деньги компании на тот же курс и т.д. А можно одному обучиться, а потом пошарить полученный опыт внутри компании так, что новичкам не потребуется идти на платный тренинг — достаточно будет обратиться к уже обучившемуся.
И второй вопрос: кто и насколько подробно должен описать материал, лежащий по ссылкам на обучающие материалы? Нужна ли оценка самого обучавшегося, его впечатление? Ссылки сами по себе мало что могут сказать. Непонятно, что там внутри, насколько полезны материалы?
Есть где почитать подробнее?
Согласен полностью. Из ушедшей головы знаний не вытянешь. автобусный фактор никто не отменял. Работа со знаниями — это такой способ обезопасить себя от изобретения велосипеда.
Да я не про фиксацию на благо компании. Я про свое личное удобство. То есть вот есть конкретно вы, и у вас есть знания, которые у вас кто-то постоянно спрашивает. 5 раз. 10 раз и т.д. В почте, в слаке, в каких-то еще чатиках. И вам приходится каждый раз писать ответ, рассказывать на встрече и т.д.
Мне в какой-то момент, например, становится лень каждый раз одно и то же расписывать. Я себе в бложек ответ забрасываю, и когда меня опять о том же спрашивают, я просто ссылку даю.
Это не про ресурсы, а про мою личную лень и комфорт :)
Самые больные места обозначили :)
А не возникало желания где-нибудь зафиксировать ответы на самые часто задаваемые вам вопросы (возможно, на разных уровнях детализации), и потом просто шарить ссылку на пост в корп.блоге или что у вас используется для корп.коммуникаций?
Полезная штука — не надо много раз расписывать одно и то же и терять на этом время.
Логично, ок :) А продукт потом сам себя продает и поддерживает? А анализ решений конкурентов вообще не проводится? Я о том и говорю, что инженеры и новички создают продукт, у них текучка, и наставничество для сохранения знаний тут хорошо заиграет.
но ведь не инженеры занимаются обслуживанием клиентов, раскаткой продукта, маркетингом. А без понимания того, как продукт работает, продавть не так-то просто.
А как принять решение, в какую сторону дальше развивать продукт? Какие фичи туда добавлять? Это же нужно собрать обратную связь, проанализировать, оценить в деньгах, спланировать. Потому и странно, что разработка часто себя отгораживает от остальных и пытается что-то у себя внутри запилить самостоятельно, но не ввязаться в кросс-командную историю про обмен знаниями и опытом.
А еще интересный момент с тем, что пилить внутренние инструменты как-то не очень хочется — они же не продаются. Но без эффективного взаимодействия «под капотом» компании надолго на рынке удержаться не получится.
Это если мы разработкой ограничимся. Я вот не из разработки, а из техподдержки изначально. И знания с разработчиков начал собирать именно по запросу техподдержки, потому что по запросу скорость ответов разраотчиков была неприемлема для клиентского сервиса. клиенту просто очень долго ждали решения своих проблем. То есть вполне осязаемая пробема с довольно логичным решением: если реактивно получать информацию долго, надо обеспечить наличие этой информации 24/7 на постоянной основе. Но и при такой постановке проблемы с каждой новой командой разработчиков приходилось достаточно долго переписываться и объяснять, зачем нам от них нужна информация. Потому что «мы внутри себя пошарили, а остальным это зачем?»
Зачем же закидывать?) Это, кстати, очень важная тема. У разработчиков довольно часто можно встретить непонимание, кому еще, кроме них, может пригодится инфа об их работе. Разработка в вакууме :) Это интересное и удивительное явление. Есть мысли, почему так происходит?
О да :) тут вообще цикличность процессов, так любимая нынче в бизнесе. Спланировал-сделал-проанализировал-снова спланировал. Если это ещё фиксировать систематически, то можно и по другим проектам принимать решения с учетом прошлого опыта по всему портфолио.
Формат зависит от роли, но да, прямо экзамен.
Тренинг - на две недели. Он blended, а не просто онлайн.
Вот это я себя узнаю в первые несколько месяцев на новом месте :)
Даже боялся что-то предложить поначалу, потому что не понимал, насколько это вообще про наш рынок.
Часто именно с небольших команд начинается глобальная инициатива по работе со знаниями.
Но полностью согласен с тем, что все же лучше профильных специалистов звать
***
Деврел — это профессия Development Relations. Можно подробно почитать вот здесь, например. В принципе, это человек, который делает ровно то, что я описал: отвечает за контакты разработчиков между собой и с остальной частью компании и внешним миром на понятном разработчикам языке.
Можно еще почитать вот эту полезную книгу.
Кстати, если вы тимлид, то могу еще вот этот доклад посоветовать посмотреть.
На вопрос про лейблы ответ, судя по этому таску, «нет». Производители не планируют реализовывать такую функцию. Сам я тоже нигде не нашел такой опции. Чтобы увидеть все материалы, содержащие данный тег, можно нажать на него под любой из статей.
Насчет всех своих подписок — «да». Можно нажать на иконку профиля в правом верхнем углу и выбрать в меню Watches.
Если считать Confluence специальным софтом, то да, используем.
В общем, в процессе задействованы:
На данный момент вроде всё. Думаем в сторону активного использования корп.почты.
Да, разные команды подчиняются разным руководителям, и их KPI непосредственно связаны с KPI их больших департаментов: обучения, поддержки, и т.д. Но т.к. цели департаментов привязаны к общей стратегии компании, то все частные KPI так или иначе влияют на выполнение общих KPI. Понятно, что цели и задачи у внешнего и внутреннего КМ, например, будут немного отличаться, но мы все завязаны в единую цепочку перемещения знаний внутри компании.
Взаимодействуем достаточно просто — созваниваемся раз в две недели, обсуждаем трудности и новости, договариваемся. Операционно — постоянно на связи в чатах. Менеджеры информируют команды о том, о чем договорились, собирают от них пожелания, и идет новый цикл обсуждения. Никакого рокет саенс нет — просто это все делается систематически.
По поводу зон ответственности, нельзя сказать, что они пересекаются, мы просто все завязаны в общий процесс. Информацию для клиентской базы знаний менеджер внешнего КМ узнает из внутренней базы, например. И если ее не обновить вовремя внутри, то она и снаружи останется старой. Или тренер в поддержке, который обучает сотрудников в смене на основе новостей от внутреннего КМ — если до него вовремя не донести информацию, то он продолжит доносить до сотрудников старые данные, а это скажется на качестве сервиса. И в то же время, если тренер не проинформирует внутренний КМ о том, что кто-то в поддержке столкнулся с новым типом обращений, на который в базе знаний не нашлось ответа, то мы не обновим внутренние материалы, и цепочка сработает в обратную сторону. Можно это назвать пересечением зон ответственности? Мне кажется, это просто взаимосвязанные процессы.
1. Если говорить об одном человеке, который покроет все активности, то я бы поместил его во внутренние коммуникации. Потому что, если он один, то времени на постоянное обновление и создание контента, переговоры, анализ потребностей и еще массу смежных задач у него будет всегда не хватать. Значит, нужно будет поработать над созданием сети помощников в отдельных командах и департаментах, которая будет помогать именно с контентом, продвигать шеринг среди своих коллег. Проще всего, на мой взгляд, это сделать из интеркома, потому что тогда менеджер по знаниям будет как раз таки и заниматься выстраиванием внутренних коммуникаций, и можно будет и административный ресурс свободно применять, и KPI адекватно поставить.
2. Первое, что я бы порекомендовал — изучить текущую обстановку. Не лезть со своим видением в первую же неделю, не строить далекоидущие планы, основываясь только на своем опыте и предпочтениях в плане инструментов КМ. Нужно понять, чем занимается компания, как она этим занимается, послушать. что говорят сотрудники, выяснить, что уже делали до тебя, и почему этим перестали пользоваться. Месяца через 2 паззл сложится, и можно будет создавать стратегию по управлению знаниями внутри компании. Но сначала нужно иметь реальные цифры, мнения, предыдущий опыт на руках.
Из моего личного опыта в Exness, про всеобщий онбординг я уже рассказал в статье. Из последующего — через 1,5 месяца мы с командой провели опрос среди основных, очевидных целевых аудиторий касательно их удовлетворенности текущим состоянием базы, каналов информирования и портала для вопросов-ответов, а также их предпочтений по этим вопросам.
Еще через 2 недели внедрили средства веб-аналитики на портал базы знаний, чтобы оценивать популярность контента, строить карту наших посетителей, искать взаимосвязи между популярностью разных статей и нашими остальными действиями (анонсами, например). И вот только сейчас, имея первые цифры, начинаем работать над планом дальнейших действий.
Почему поддержке так была нужна база знаний? Это тоже тема для целого доклада — можно вот тут послушать www.youtube.com/watch?v=7-wstE0l8bQ.
А кто, по-вашему, должен этим заниматься?
И второй вопрос: кто и насколько подробно должен описать материал, лежащий по ссылкам на обучающие материалы? Нужна ли оценка самого обучавшегося, его впечатление? Ссылки сами по себе мало что могут сказать. Непонятно, что там внутри, насколько полезны материалы?
Есть где почитать подробнее?
Мне в какой-то момент, например, становится лень каждый раз одно и то же расписывать. Я себе в бложек ответ забрасываю, и когда меня опять о том же спрашивают, я просто ссылку даю.
Это не про ресурсы, а про мою личную лень и комфорт :)
А не возникало желания где-нибудь зафиксировать ответы на самые часто задаваемые вам вопросы (возможно, на разных уровнях детализации), и потом просто шарить ссылку на пост в корп.блоге или что у вас используется для корп.коммуникаций?
Полезная штука — не надо много раз расписывать одно и то же и терять на этом время.
но ведь не инженеры занимаются обслуживанием клиентов, раскаткой продукта, маркетингом. А без понимания того, как продукт работает, продавть не так-то просто.
А как принять решение, в какую сторону дальше развивать продукт? Какие фичи туда добавлять? Это же нужно собрать обратную связь, проанализировать, оценить в деньгах, спланировать. Потому и странно, что разработка часто себя отгораживает от остальных и пытается что-то у себя внутри запилить самостоятельно, но не ввязаться в кросс-командную историю про обмен знаниями и опытом.
А еще интересный момент с тем, что пилить внутренние инструменты как-то не очень хочется — они же не продаются. Но без эффективного взаимодействия «под капотом» компании надолго на рынке удержаться не получится.
О да :) тут вообще цикличность процессов, так любимая нынче в бизнесе. Спланировал-сделал-проанализировал-снова спланировал. Если это ещё фиксировать систематически, то можно и по другим проектам принимать решения с учетом прошлого опыта по всему портфолио.