Корпоративный обмен знаниями?

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

У меня вопрос к группе:

• Какие методы / программное обеспечение вы использовали, чтобы стимулировать более «публичные» дискуссии среди ваших разработчиков?

Некоторые первоначальные идеи, которые у меня были ... любая обратная связь была бы отличной:

• Внутренняя группа новостей
• «лучшее» вики-программное обеспечение (теперь использующее Sharepoint)
• Доска объявлений

(Я хотел бы иметь внутренний экземпляр StackExchange, но не думаю, что это вариант!)

Примечание. Как указано выше, у нас уже есть вики, но мне не нравится идея вики, потому что вещи обычно добавляются в вики только после факта, если вообще появляются .

Благодарность!

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

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

StackOverFlow для предприятия, как описано в статье, которую вы упомянули?

ИМХО это ужасная идея .

Это усилит конкуренцию вместо сотрудничества .

Вам необходимо сотрудничество между отделами и отделами, а не повышение их конкуренции.

Также представьте себе, насколько негативное влияние вашей коллеги (перед другими) может оказать негативное влияние на ваше психическое здоровье.

Не смешивайте все.

Тем не менее, ящик с идеями гораздо больше uservoice.com, где сотрудники могут публиковать идеи (анонимно), а другие сотрудники их оповестить (также анонимно) будет иметь положительное влияние. Несколько лет назад я разработал такую ​​платформу для очень крупного банковского учреждения, и она помогла руководителям определить, что следует улучшить в приоритетном порядке.

Мне действительно нравится идея вики, но вы правы - трудно заставить людей внести свой вклад. И без вкладов никто не будет фактически использовать это, потому что у этого нет достаточно информации. Однако есть «переломный момент», в котором, если бы вы могли заставить людей публиковать сообщения (возможно, через необходимый бизнес-процесс) в какой-то момент, вики просто взлетела бы, как это было бы этим большим хранилищем информации.

Парное программирование - отличный способ распространения неявных знаний.

Проблема с молчаливым знанием состоит в том, что оно по определению не может быть записано или обучено, только опытно. Парное программирование (в частности, Promiscuous Pairing) обеспечивает это.

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

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

В моей компании есть несколько внутренних форумов. Они используются очень редко. По большей части наши знания являются либо слишком общими (общие технологические вопросы / темы, которые так же хорошо обсуждаются в Интернете), либо слишком конкретными (применимы только к нашему приложению, а не к другим командам приложений в той же компании). Это хорошо, потому что это дает людям возможность сказать, как мне выполнить xyz, но это не очень похоже на чувство сообщества.