Partage des connaissances d'entreprise?

J'ai récemment lu cet article sur le partage des connaissances et j'ai immédiatement reconnu le même problème au sein de ma propre organisation. Mon objectif principal est maintenant de «tuer la collaboration entre pairs» comme méthode de communication par défaut pour les discussions non privées liées au système. Sinon, vous vous retrouvez avec toutes les connaissances historiques vivant dans la tête des individus, ou perdues dans un système de messagerie massif.

Ma question pour le groupe est la suivante:

• Quelles méthodes / logiciels avez-vous utilisés pour encourager des discussions plus «publiques» entre vos développeurs?

Quelques idées initiales que j'avais .. toute rétroaction serait formidable:

• Groupe de nouvelles interne
• «meilleur» logiciel wiki (en utilisant Sharepoint maintenant)
• Tableau de messages

(J'adorerais avoir une instance interne de StackExchange, mais ne pense pas que ce soit une option!)

Remarque: Comme indiqué ci-dessus, nous avons déjà un wiki, mais je n'aime pas l'idée du wiki car les choses ne sont généralement ajoutées au wiki qu'après coup, le cas échéant .

Merci!

Nous avons un grand site Sharepoint interne et un site de support client, qui prend beaucoup de documents du site Sharepoint interne. Il s'agit moins de détails de mise en œuvre et plus de support certes, mais comme je travaille en grande partie en tant que support, nous avons besoin d'accéder à de nombreuses informations de mise en œuvre et nous finissons donc par être des pilotes pour l'équipe d'ingénierie pour documenter ce qu'ils font et pourquoi. Un système de suivi des bogues détaillé est également utile pour suivre la façon dont les problèmes ont été résolus.

Dans notre entreprise, en partie parce que le développement est réparti sur plusieurs sites, de nombreuses discussions sur les nouvelles fonctionnalités et les problèmes de support se produisent par e-mail. Plutôt que d'essayer de changer cela, l'approche la plus simple est un système d'archivage des e-mails qui rend les discussions consultables et traçables - efficacement une approche de type newsgroup. Nous sommes en mesure de le faire via Sharepoint, bien que l'on doive être conscient des limites de la taille des listes, car bien qu'il atteindra des millions d'éléments, vous ne pouvez pas faire grand-chose en termes de tri de très grandes listes ou de modification des vues sans il s'est écrasé de façon spectaculaire.

StackOverFlow pour entreprise comme expliqué dans l'article que vous avez mentionné?

À mon humble avis, c'est une idée terrible .

Il renforcera la concurrence plutôt que la collaboration .

Vous avez besoin d'une collaboration entre divisions / départements, sans augmenter la concurrence.

Imaginez également l'impact négatif extrêmement élevé du vote négatif de votre collègue (devant les autres) peut avoir sur votre santé psychique.

Ne mélangez pas tout.

Cependant, une boîte à idées beaucoup plus uservoice.com où les employés peuvent publier des idées (anonymement) et d'autres employés les votant (également de manière anonyme) aura un impact positif. J'ai développé une telle plateforme il y a quelques années pour une très grande institution bancaire, et elle a aidé les dirigeants à identifier les points à améliorer en priorité.

J'aime vraiment aussi l'idée du wiki, mais vous avez raison - il est difficile d'amener les gens à contribuer. Et sans contributions, personne ne l'utilisera réellement car il ne dispose pas de suffisamment d'informations. Il y a cependant un "point de basculement" dans lequel si vous pouviez amener les gens à poster (peut-être à travers un processus métier requis) à un moment donné, le wiki décollerait tout simplement comme ce serait ce grand référentiel d'informations.

La programmation par paires est un excellent moyen de diffuser des connaissances tacites.

Le problème de la connaissance tacite est qu’elle ne peut, par définition, pas être écrite ou enseignée, mais seulement expérimentée. La programmation par paire (en particulier le couplage promiscuité) le permet.

Les connaissances importantes pour l'entreprise devraient être intégrées au projet lui-même, sous la forme d'un code bien écrit, de commentaires de haut niveau sur l'architecture et d'une documentation exceptionnelle sur les objectifs du projet et la manière dont ils sont atteints grâce à la technologie.

Je ne pouvais pas être plus en désaccord avec les conclusions de l'auteur lié. Encourager la capture des connaissances en décourageant la collaboration d'équipe? Désolé, mais ce n'est pas comme ça que ça fonctionne. C'est la collaboration elle-même qui produit la richesse des connaissances, et non pas la séquestration des ingénieurs dans les cellules.

Mon entreprise a des forums de discussion internes. Ils sont très rarement utilisés. Pour la plupart, les connaissances que nous avons sont soit trop générales (questions / sujets technologiques généraux qui sont tout aussi bien discutés sur Internet) ou trop spécifiques (s'applique uniquement à notre application et non aux autres équipes d'application de la même entreprise). C'est bien dans la mesure où cela donne un endroit pour que les gens disent comment accomplir xyz ici, mais ce n'est pas vraiment le sentiment d'une communauté.