Pull to refresh

Comments 14

Я сомневаюсь, что в крупных компаниях будут честно вести такие блоги.
Например, как написать в блоге "Админы задолбали - уже второй месяц не могут подготовить сервер", не нарвавшись потом на ответную реакцию?
Или как написать в блоге "начальник заставил меня использовать эту тупую формочку, потому что он её делал сам и так тешит своё самолюбие", не оставшись потом без премии?
БОльшая часть такой информации хранится только внутри отдела или передаётся по "сарафанному радио".

Скажу больше: на работе просто НЕКОГДА вести такие блоги. Или просто лень, потому что читать хабр не лень...

У нас есть что-то типа "профессиональных блогов" на работе. Там их всего два: один тестовый и второй с одной записью от HR за какой-то 2018-ый год.

  1. Действительно некогда. И обычно чем выше ты по лесенке - тем больше некогда. Только если это не зашито в какой-нибудь kpi))

  2. Если рассматривать блоги как инструмент передачи знаний, пусть даже и неформальных, то с ростом количества сотрудников (читай блогов) получаем большую фрагментацию данных. У меня, например, честно нет желания отработать 8-10 часов а потом еще сесть бложики коллег почитать. В итоге есть шанс, что это будет пустая работа и трата времени. Хотя возможно (!) в командах это сработает

  1. Тут смотря с какой стороны подойти. Например, приходит к тебе подчиненный и спрашивает: "Тут такая проблема. Как решать?". А я-то помню, что месяц назад мы уже такой кейс с другой командой решили. Я-то знаю как, а он нет. И вместо того, чтобы копаться в своей памяти, можно один раз написать в блог и кидать всем ссылку. Ну и если записал в блог например, самому потом проще вспомнить, что там именно за решение было. "Некогда" - это правда проблема, но тут вопрос философский: какая разница сейчас потратить время или потом на объяснение одного и того же?

  2. Это да, поэтому нужен человек, который задавал бы редполитику и следил за ней

Очень круто, что вы подняли эту тему, спасибо! Я как раз собирался рассказать в следующих статьях, как реально наладить управление знаниями, чтобы они передавались не только по сарафанке внутри отдела. На том этапе развития компании делиться разными знаниями в блогах было вполне приемлемо и даже прогрессивно. Это сейчас для управления знаниями появилось специальное ПО и культура изменилась.
Но есть один момент: те примеры, которые вы приводите, не совсем про управление знаниями. Про админов - это вопрос распределения задач и бизнес-процессов. А про начальника - это вопрос о том, можно ли высказывать свое мнение, и в какой форме.

Любой каприз за ваши деньги...платят за блог - буду вести блог (но не пойду на такую работу)...плятят за выяснение проблемы-прананализирую код

Блоги с описаниями решений не прогеры должны вести...а поддержка 1-ой, 2-ой,...N-ой линии...если до прогеров докатились до значит на сработала уже поддержка N-й линии

Допустим, у себя в голове заказчик уже нарисовал идеальный дизайн будущего сайта, но не говорит какой. Менеджер-новичок не знает, что эти ожидания вообще надо выявлять. Менеджер среднего уровня уже понимает, как узнать у клиента, что он хочет, может импровизировать с каждым новым заказчиком, выявлять эти идеальные образы и говорить «нет». Очень опытный менеджер не только может все это делать, но и может четко объяснить даже новичку,  как выявлять эти ожидания и работать с ними. 

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

Возможно по причине того, что статья вводная и подразумевается продолжение, не понял в чём уникальность вашего решения? Пока выглядит неструктурированным. Блоги? У них отдельная функция. Базы знаний? Тоже уже существует множество готовых решений; бери и пользуйся. Системного подхода из статьи пока не прослеживается.

Но тема интересная и нужная. Если не затруднит, ответьте в следующих материалах (если они будут) как заставить сотрудника делиться своими знаниями (на мой взгляд - совсем нетривиальная задача)? Как научить грамотно излагать и документировать? Или для этого нужен отдельный персонаж?

Спасибо за обратную связь! Согласен, я тоже считаю, что тема управления знаниями интересная и нужная. Поэтому решил поделиться своим опытом и начал с самых истоков. Это была вводная статья, чтобы сделать заход в тему.
А в следующих статьях я уже дам конкретные инструменты и раскрою её подробнее.

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

Вы абсолютно правы. Обязательно в такой ситуации, особенно на старте выстраивания процессов и системы УЗ должен быть драйвер. Заинтересованное лицо, так сказать.
Также в команде может быть так называемый knowledge manager, который и помогает выстраивать весь процесс.
Я обязательно затрону эту тему чуть дальше.

Я всё-таки настаиваю, что этот драйвер нужен постоянно. Само работать не будет

Очень интересно, как вы управляете актуальностью. Очень сложно поддерживать гигантское количество материала.

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

Sign up to leave a comment.

Articles