Les non-informaticiens peuvent-ils gérer un wiki? [fermé]


35

Mon entreprise cherche à améliorer la gestion des données de ses études de marché.

Style actuel de gestion des données:

  • "Hé Jimbo, où est cette photo de notre WhatZit 2.0?
  • "Oui, je me souviens de l'e-mail concernant cette société de ce type, donne-moi quelques minutes pour rechercher mes perspectives"
  • "qui a la copie la plus récente du catalogue de produits de l'important concurrent? Le mien date de 2009." ... "Colleen l'a fait et elle est en congé de maternité. Vous devrez l'appeler pour obtenir le mot de passe de son poste de travail ..."

Style de gestion de données souhaité:

  • données classées par sujet (juridique, économique, industriel, concurrent)
  • pour chaque sujet, plusieurs types de supports stockés ensemble (images de produits de la société, communiqués de presse, informations de contact) mais toujours soigneusement triés par type
  • historiques d'édition de données
  • accès communal (pas de silos de données)

Je pensais à la mise en place d'un wiki de département accessible à tous les utilisateurs. Il semble satisfaire aux quatre critères ci-dessus, mais je suis un peu préoccupé par la convivialité (lire: déchiffrable par des non-spécialistes), il est destiné aux fonctionnalités plus avancées telles que les galeries d'images, le formatage d'articles, etc.

Est-ce que quelqu'un ici a créé un wiki pour des non-informaticiens et ne l'a pas pris feu, n'est-il pas devenu une ville fantôme ou ne ressemble-t-il pas à Geocities?

Question bonus: pouvez-vous voir des inconvénients évidents à mon choix de MediaWiki (ou de tout autre wiki) pour résoudre ce problème?

(J'espère que certains d'entre vous auront déjà rencontré ce problème et pourront vous donner des idées ...)


3
Il me semble que vous avez besoin d'un système de gestion de contenu, car les problèmes que vous avez fournis sont le symptôme d'une mauvaise gestion du contenu. Les wiki sont raisonnables dans la gestion du contenu, mais peuvent ne pas fournir les détails affinés qui pourraient être importants dans un contexte commercial. MediaWiki, par exemple, n’est pas conçu pour gérer les autorisations des utilisateurs. Si vous avez des documents sécurisés , ou si vous avez besoin de savoir qui peut voir / éditer quoi, vous devez utiliser un CMS; Si vous avez juste besoin d' une édition rapide, ouverte et versionnée de documents partagés , utilisez un wiki.
zzzzBov

5
Données! = Documents. Vous aurez peut-être besoin d'un système de gestion de documents plutôt que d'un système de gestion de contenu
Pekka prend en charge GoFundMonica le

2
Hou la la! J'espérais avoir une ou deux bonnes réponses et j'ai eu un test complet, ET près de 30 votes positifs, ET 2 votes serrés (ha!). Merci tout le monde. J'ai donné +1 à gauche et à droite. Quelques commentaires géniaux ici.
Drew

Ils pourraient, mais ils ne le feront pas.
Tulains Córdova

Réponses:


46

Réponse directe à votre question: oui. Wikipedia a des tonnes d'éditeurs non-informaticiens.

Réponse plus longue: votre distinction entre informatique et non-informatique est ici un clin d'œil . Tout le monde, qu’il soit informatique ou non, ignorera tout de même un wiki s’il ne leur est pas présenté comme un élément important. L'introduction d'un nouveau système de gestion de données est toujours non triviale à vendre aux gens, car il faut toujours leur donner envie de changer. Par exemple, si les programmeurs ne voient pas trop de problèmes avec le système de suivi de bogues actuel et / ou pensent que passer à la nouvelle est un problème, ils ne passeront pas.

Vous devez vendre le nouveau système en expliquant comment il améliore tout, en expliquant les problèmes liés au système actuel et en prenant des mesures pour que les gens sachent que ce n’est pas une fantaisie passagère et que le nouveau système est là pour rester. Après tout, si les gens pensent que c'est un projet condamné, alors ce sera un projet condamné.


4
+1 Pour un commentaire perspicace et prophétique! J'ai vu comment des décrets de gestion forcés imposés à une main-d'œuvre non consentante se terminent généralement par un mécontentement généralisé ou par l'abandon du nouveau système pour l'ancien. Vous devez vendre l'idée aux utilisateurs, sinon elle ne collera pas. Si vous pouvez le vendre au plus conservateur des utilisateurs, vous aurez du succès. Il y a des années, j'ai vendu ma grand-mère à l'idée des
eReaders

Wikipédia compte 7 milliards de visites par mois et seulement 300 000 contributeurs / mois, dont la plupart ne font qu'une édition. Je ne suis donc pas sûr que ce soit un si bel exemple d'accessibilité pour l'édition.
vartec

1
Je dirais qu'une majorité d'éditeurs qui n'effectuent qu'un seul montage est un excellent exemple d'accessibilité du montage, car cela signifie que les personnes ne doivent pas nécessairement devenir des experts pour effectuer des travaux d'édition. Mais le vrai problème, c’est que les obstacles techniques n’empêcheront pas les gens d’apporter des modifications s’ils pensent qu’il est important d’y apporter des modifications.
route le

1
moins de 0,1% des utilisateurs modifient, ce qui est acceptable sur Wikipedia grâce à un trop grand nombre d'utilisateurs, mais cela n'est pas acceptable pour le wiki d'un petit projet et encore moins pour le wiki interne.
vartec

3
je vais donc devoir commercialiser l'idée du wiki auprès du département marketing ... en les battant à leur propre jeu, hein? drums fingertips together slowly and dramatically... oui, oui cela fonctionnera, yesssssssssssss :-) +1
Drew

11

Cela dépend du logiciel wiki. Généralement, les non-informaticiens préfèrent un wiki avec un éditeur WYSIWYG et peuvent ne pas aimer les wikis nécessitant une édition de balisage, même si le balisage est très simple.

Pour votre question complémentaire: MediaWiki ne fournit pas d'éditeur WYSIWYG natif. Vous pouvez voir lesquels font dans Comparaison du logiciel wiki .


7
Il h. "Consultez wikipedia pour les wikis avec les éditeurs."
Michael K

@Michael: check! = Edit :-P
vartec Le

4
+1 Mon expérience avec Media Wiki (l'un des wikis les plus populaires) m'amène à penser qu'il n'est pas parfaitement adapté aux personnes non techniques.
Dan Diplo

return false;
Joe la personne

4
Je suis un informaticien et je déteste passionnément les wikis qui ont besoin de balises exotiques. Ma tête est déjà tellement pleine de choses que je ne veux pas gaspiller les cellules cérébrales en apprenant un langage de balisage. Laisse-moi tranquille! (Et si c'est ce que je ressens, pense à quel point les personnes non techniques se sentent.)
quickly_now

6

Dans mon organisation, l'implémentation du wiki est très réussie. Il est basé sur MoinMoin, qui est un paquet wiki Python.

Cependant, pour réussir, il a fallu des années de travail dévoué à la formation du personnel et à son éloge. Pour une organisation d'environ 80 employés à temps plein, j'ai dû organiser un certain nombre de sessions de formation initiale et avancée, ainsi que de passer beaucoup de temps à répondre à des questions.

Les deux obstacles les plus difficiles étaient:

  1. Apprendre aux gens à ne pas penser au wiki comme un document Word et utiliser les titres de manière appropriée pour l'organisation
  2. Convaincre les gens de migrer leur contenu existant vers le wiki, où il serait consultable et modifiable, plutôt que de simplement joindre d'anciens documents au wiki.

Après environ deux ans, cela a commencé à prendre forme. Après quatre ans d'utilisation, le wiki pilote le fonctionnement interne de notre organisation.

Cela n'aurait pas été possible sans beaucoup de travail de ma part, et sans la volonté de travailler en tête-à-tête avec les utilisateurs de wiki, en fournissant des réponses rapides ou immédiates à leurs questions.


3
Prendre des années pour vendre un système de gestion de données à seulement 80 personnes peut sembler extrême si vous ne l'avez jamais fait auparavant, mais pour moi, cela sonne comme la fin la plus longue de la normale.
Jhocking le

2
@jhocking Nous avons tenu le coup car nous avions un problème majeur en matière de partage de documents et de résolution des problèmes des ministères. Nous avions un site Web intranet qui ne contenait qu'une infime quantité d'informations sur les ressources humaines, mais une pile de documents opérationnels empilée dans des documents Word non versionnés. Les cadres supérieurs sont les derniers à adopter (utilisateurs en lecture seule) et, malheureusement, sans soutien par exemple, je pense que le taux d'adoption a été ralenti. Au lieu d'un mandat descendant, il devait être basé sur la base, dirigé par les personnes les plus jeunes et les plus techniques de notre bureau.
Michael

5

Je pense qu'un wiki peut être une excellente approche du problème organisationnel auquel vous êtes confronté. Je crois également que les utilisateurs non techniquement orientés sont très capables d'apprendre les fonctionnalités du wiki avec certaines réserves.

Je suis tout à fait d’accord avec le commentaire selon lequel l’acceptation des utilisateurs est vitale. Vous êtes plus susceptible de faire face au «je ne vais pas l'utiliser» ou au «projet animalier du mois d'Andrew» qu'au «je ne peux pas apprendre à l'utiliser». Prenez le temps d'expliquer comment cela va sauver le travail des gens plutôt que d'en créer de nouveaux.

Vous voudrez peut-être commencer par organiser certaines des données que vous avez dans des courriels, sur votre bureau, etc., en quelques pages simples pour illustrer votre objectif. Notez le temps que cela prend, y compris l'apprentissage, et tous les points que vous avez trouvés difficiles.

Au début, je m'attendrais à ce que vous ayez des problèmes de mise en forme, et je pense que vous feriez probablement mieux de recruter un comité de rédaction que de tenter de réglementer la création de contenu. Après la surabondance initiale des informations, elles devraient devenir très gérables.

Vous pouvez également configurer un wiki wiki avec un e-mail "help" pour vous aider à démarrer.

Juste mes 2 ¢, j'espère que ça aidera.


C’est une excellente façon de formuler quelque chose que j’avais du mal à verbaliser: expliquez en quoi cela va permettre d’économiser du travail et non de créer davantage de travail.
route le

4

Oui, Wikipédia l'a prouvé. Quoi qu'il en soit, les utilisateurs sont tenus de s'y conformer, ce qui n'est pas toujours facile, même si c'est dans leur intérêt. Les gens vont résister au changement.


3

Je vois un inconvénient à utiliser MediaWiki: cela peut devenir assez compliqué et prendre un certain temps à apprendre. Il peut être exagéré pour vos besoins de documentation.

Mon entreprise utilise le wiki fourni avec Google Apps, très simple à utiliser et doté d'une interface WYSIWYG. Cependant, vous perdez une partie de la catégorisation fournie avec MediaWiki, de l'historique de révision et des discussions de page, ainsi que la possibilité d'intégrer des modèles. Mais le wiki de Google Apps a été relativement facile à adopter par tous les employés du bureau.


3

Il existe une base de données de modèles wiki et d'anti-modèles wiki sur les modèles Wiki .

Malgré tout, mon expérience avec l'utilisation du wiki dans les projets n'a pas été un tel succès. Au début, les utilisateurs étaient rapidement frustrés par l'utilisation du wiki, car il fallait déployer des efforts considérables pour maintenir et mettre à jour les articles. Ensuite, il y avait des disputes sur qui devait organiser la structure du wiki, ou devenait-il une sorte de corbeille pour les liens.

D'après mon expérience, la façon dont cela a fonctionné a été de dire: "J'ai posté / mis à jour cet article wiki (lien)" et j'envoie ce lien vers l'article dans un courrier électronique. Cependant, les capacités de recherche de MediaWiki atteignent rapidement leurs limites (comme la recherche de courriels).

Sur une note positive: une fonctionnalité très utile de MediaWiki est de conserver des catégories pour les articles et d’avoir une sorte de page avec des acronymes utilisés dans les projets et d’enseigner aux nouveaux venus dans les wikis. Les nouveaux employés du wiki l’aimaient souvent, car cela avait des effets directs sur leur courbe d’apprentissage.


3

En plus de tout ce qui est mentionné ici, je crains que vous ne preniez du temps pour mettre en place la structure, collecter les documents, les télécharger, les trier et les étiqueter.

J'avais l'habitude d'essayer de convaincre les gens d'utiliser tel ou tel logiciel ou technologie, comme les conférences Jabber , les règles adblock, du code JavaScript, certains gestionnaires de fenêtres, etc.

Je n'y ai réussi que lorsque j'ai montré à quel point cela pouvait être utile pour les gens et à démontrer comment il pouvait faire des «trucs cool» au lieu d'expliquer en quoi un logiciel Aest techniquement supérieur.

Personne n'écouterait "fvwm a une petite empreinte mémoire, est hautement configurable et possède des liaisons Perl", mais une courte vidéo ou une capture d'écran vous permet de "dérouler n'importe quelle fenêtre et de placer la barre de titre de chaque côté de la fenêtre". pour une raison quelconque s'avère très convaincant.

Vous devrez donc tirer le meilleur parti de la configuration et télécharger jusqu'à 60% des informations là-bas. Assurez-vous qu'il ne jette aucun message d'erreur cryptique sur les utilisateurs et veillez à montrer une astuce intéressante.

En d'autres termes, vous devrez le vendre et vous ne devrez pas utiliser uniquement des arguments rationnels.


0

Oui, ils le peuvent, mais ils doivent apprendre à l'utiliser. Vous devez assurer aux personnes que des actions accidentelles, telles que la suppression de paragraphes, peuvent être inversées. Nous avons également dû aider un peu avec le formatage.

Malheureusement, cela ne fonctionne que s'il n'existe pas d'autre moyen facile d'accéder aux informations souhaitées. Et vous devriez encourager les gens à utiliser le système. Certaines personnes peuvent même cesser de participer à l'échange d'informations, car elles n'ont pas du tout envie d'utiliser le nouveau système et savent en même temps que l'ancienne méthode de partage de l'information est désormais indésirable.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.