Compartilhamento de conhecimento corporativo?

Li recentemente este artigo sobre compartilhamento de conhecimento e reconheci imediatamente o mesmo problema em minha própria organização. Meu principal objetivo agora é 'matar a colaboração ponto a ponto' como o método padrão de comunicação para discussões não privadas relacionadas ao sistema. Caso contrário, você terá todo o conhecimento histórico vivendo na cabeça dos indivíduos ou perdido em um sistema de email massivo.

Minha pergunta para o grupo é a seguinte:

• Quais métodos / softwares você usou para incentivar mais discussões 'públicas' entre seus desenvolvedores?

Algumas idéias iniciais que eu tive .. qualquer feedback seria ótimo:

• Grupo de notícias interno
• software wiki 'melhor' (usando o Sharepoint agora)
• Quadro de mensagens

(Gostaria muito de ter uma instância interna do StackExchange, mas não pense que é uma opção!)

Nota: Como afirmado acima, já temos um wiki, mas não gosto da ideia do wiki, porque as coisas geralmente são adicionadas ao wiki apenas depois do fato, se é que existem .

Obrigado!

Temos um site interno grande do Sharepoint e um site de suporte voltado para o cliente, que recebe muitos documentos do site interno do Sharepoint. Isso tem menos a ver com detalhes de implementação e mais com suporte, mas como eu trabalho em grande parte em uma capacidade de suporte, precisamos acessar muitas informações de implementação e, portanto, acabamos sendo motivadores da equipe de engenharia para documentar o que estão fazendo e por quê. Um sistema detalhado de rastreamento de bugs também é valioso para acompanhar como os problemas foram resolvidos.

Em nossa empresa, em parte porque temos desenvolvimento espalhado por alguns locais, muitas discussões sobre novos recursos e problemas de suporte acabam acontecendo por e-mail. Em vez de tentar mudar isso, a abordagem mais fácil é um sistema de arquivamento de email que torna as discussões pesquisáveis ​​e rastreáveis ​​- efetivamente, uma abordagem do tipo grupo de notícias. Podemos fazer isso por meio do Sharepoint, embora seja necessário estar ciente dos limites do tamanho da lista, como se ele aumentasse para milhões de itens que você não pode fazer muito em termos de classificação de listas muito grandes ou edição de visualizações nelas sem desabando dramaticamente.

StackOverFlow para empresas, como explicado no artigo que você mencionou?

IMHO é uma péssima ideia .

Reforçará a concorrência em vez da colaboração .

Você precisa de colaboração entre divisões / departamentos, sem aumentar a concorrência.

Imagine também o impacto negativo extremamente alto de ser votado pelo seu colega (na frente de outras pessoas) na sua saúde psíquica.

Não misture tudo.

No entanto, uma caixa de ideias muito mais uservoice.com, na qual os funcionários podem postar idéias (anonimamente) e outros funcionários votá-las (também anonimamente) terá um impacto positivo. Desenvolvi uma plataforma desse tipo há alguns anos para uma instituição bancária muito grande e ajudou os executivos a identificar o que melhorar em prioridade.

Eu também gosto muito da idéia do wiki, mas você está certo - é difícil conseguir que as pessoas contribuam. E sem contribuições, ninguém vai realmente usá-lo porque não possui informações suficientes. Existe um "ponto de inflexão" no entanto, se você pudesse levar as pessoas a postar (talvez através de um processo de negócios necessário) em algum momento, o wiki decolaria, pois seria esse grande repositório de informações.

A programação em pares é uma ótima maneira de disseminar conhecimento tácito.

O problema do conhecimento tácito é que ele pode, por definição, não ser escrito ou ensinado, apenas experimentado. A programação em pares (especificamente emparelhamento promíscuo) fornece isso.

O conhecimento que é importante para a empresa deve ser incluído no próprio projeto, na forma de código bem escrito, comentários de alto nível sobre a arquitetura e documentação excepcional sobre os objetivos do projeto e como eles são alcançados com a tecnologia.

Eu não poderia discordar mais das conclusões do autor vinculado. Incentivar a captura de conhecimento desencorajando a colaboração da equipe? Desculpe, mas não é assim que funciona. É a colaboração em si que produz a riqueza do conhecimento, não sequestrando engenheiros em cubículos.

Minha empresa possui alguns fóruns de discussão internos. Eles são usados ​​muito raramente. Na maioria das vezes, o conhecimento que temos é muito geral (questões / tópicos gerais de tecnologia que são discutidos na Internet) ou muito específico (aplica-se apenas ao nosso aplicativo e não a outras equipes de aplicativos da mesma empresa). É bom, pois dá um lugar para as pessoas dizerem como realizo xyz aqui, mas não é um sentimento de comunidade.