Question

Je travaille sur une application complexe où différentes équipes travaillent sur leurs propres modules avec un certain degré de chevauchement.Il y a quelque temps, nous avons mis en place une instance Mediawiki, en partie à ma demande.J'ai du mal à amener les gens à l'utiliser, et encore moins à y contribuer.

Je vois beaucoup d’avantages dans le partage d’informations.Cela pourrait au moins réduire le temps nécessaire pour réinventer la roue.

Le wiki n'est pas très structuré, mais je ne suis pas sûr que ce soit un problème tant que vous pouvez rechercher ce dont vous avez besoin.

Des indices ?

Était-ce utile?

La solution

Comme je l'ai mentionné avant, un Wiki est très désorganisé.

Cependant, si c'est le seul argument de vos développeurs, investissez des efforts pour créer une page d'index simple et la maintenir à jour (soit faites-le vous-même, soit demandez aux gens de lier leurs contributions à l'index).De cette façon, le Wiki pourrait devenir une collection de documentation très intéressante et assez complète pour tout votre travail.

Autres conseils

Quelques conseils:

Chaque fois que quelqu'un envoie par e-mail des informations qui devraient vraiment figurer dans un wiki, créez une page sur ce sujet et ajoutez ce qu'il a mis dans l'e-mail.Répondez ensuite "Merci pour cette information, je l'ai mise dans le wiki ici afin qu'elle soit plus facile à retrouver à l'avenir."

De même, si vous avez des informations à partager qui devraient figurer dans le wiki, mettez-les là et envoyez simplement un e-mail avec un lien vers celle-ci, plutôt que d'envoyer un e-mail aux gens.

Lorsque vous demandez des informations aux gens, formulez-les de manière à ce que mettre cette documentation dans le wiki soit considéré comme la valeur par défaut ou la norme :"J'ai cherché sur le wiki mais je n'ai pas trouvé.Avez-vous déjà mis cette information là-bas ?"

Si vous êtes le « champion du wiki », assurez-vous que d'autres personnes savent comment l'utiliser, par ex.« Ai-je déjà expliqué comment créer une nouvelle page avec vous ?

Modifiez la barre latérale pour vous assurer qu'elle est pertinente pour votre travail.

Utilisez des modèles de style « boîte de navigation » sur les pages associées pour une navigation plus facile.

Mettez quelque chose comme {{Special:NewPages/5}} sur la première page, ou les modifications récentes, afin que les gens puissent voir l'activité.

Jetez un œil aux modifications récentes tous les quelques jours ou semaines, et si vous remarquez que quelqu'un ajoute des informations sans être incité, envoyez-lui un e-mail ou passez nous voir et faites-lui un petit compliment.

Nous utilisons un wiki sous une forme ou une autre depuis un certain temps maintenant, mais il faut un certain temps pour que les gens s'y joignent.Vous constaterez peut-être que vous serez le seul à écrire des articles pendant un certain temps, mais soyez patient, d’autres personnes finiront par vous rejoindre.

Si quelqu'un envoie un e-mail contenant des informations relatives au projet, dirigez-le utilement vers le wiki - et continuez à le faire - il devrait recevoir l'indice.

Nous avons un portail SharePoint et utilisons le wiki à partir de là - nous l'avons personnalisé avec notre propre marque afin qu'il « ressemble à la pièce » - je pense vraiment que cela a contribué à améliorer son adoption.

Assurez-vous que tout le monde soit conscient que le wiki est encore plus informel que le courrier électronique....parce qu'il y aura un « facteur de peur » selon lequel les gens penseront que tout ce qu'ils ajoutent au wiki sera sur-analysé.

Je pense que la plupart des réponses jusqu'à présent sont exactes : plus vous y travaillez vous-même, plus le corpus d'informations utiles deviendra volumineux, donc lentement mais sûrement les gens commenceront naturellement à les utiliser.

L'autre approche que vous pouvez utiliser est la suivante :Suggérez que chaque fois que quelqu'un pose une question à un autre membre de l'équipe sur le projet, il doit répondre à la question comme d'habitude, mais également ajouter la réponse à une section du wiki.Cela peut prendre quelques minutes supplémentaires, mais cela signifie que la prochaine fois que quelqu'un posera la même question (ce qu'il fera inévitablement), vous pourrez gagner du temps en le dirigeant vers le Wiki.Ceci, à son tour, devrait aider les gens à commencer à utiliser le Wiki comme première source d'information et à favoriser une adoption globale.

Vous ne pouvez pas forcer les développeurs à faire quelque chose pour lequel ils ne sont pas incités à l'utiliser ;malheureusement les wikis, comme la documentation (enfin, en fait les wikis sont documentation) ont rarement une valeur "intéressante" pour les développeurs.De plus, ils sont déjà plongés dans le travail de développement – ​​pourriez-vous vraiment les déranger avec un wiki ?

Cela étant dit, les personnes qui ont poussé pour le wiki (par exemple, vous) devraient être principalement responsables de sa mise à jour, et vous auriez vraiment beaucoup de travail à faire si vous êtes sérieux à ce sujet.

Vous pouvez aussi essayer le ff :

  • Ce n'est pas très structuré, dites-vous -- beaucoup de gens sont rebutés par les wikis mal structurés (difficiles à rechercher/à parcourir).Alors peut-être que tu peux résoudre ça d'abord
  • Vous pouvez peut-être demander aux principaux développeurs/chefs de projet de le remplir avec des éléments qui posent problème pour eux :des choses comme les conventions de code et la conception d'API pour votre projet particulier
  • Mener par l'exemple:documenter religieusement ton partie du système.Créer un précédent peut encourager d’autres à faire de même

Vendez l’idée d’utiliser le wiki aux développeurs.Vous avez identifié certains avantages, partagez-les avec les développeurs.S’ils voient qu’ils en tireront quelque chose de précieux, ils commenceront à l’utiliser.

Exemples d'avantages de Qu'est-ce qu'un wiki

  • Idéal pour écrire des idées rapides ou plus longues, vous donnant plus de temps pour la rédaction et l'édition formelles.
  • Collaborez instantanément sans envoyer de documents par courrier électronique, ce qui permet de garder le groupe synchronisé.
  • Accessible de n'importe où avec une connexion Web (si cela ne vous dérange pas d'écrire dans des formulaires texte de navigateur Web).
  • Vos archives, car chaque révision de page est conservée.
  • Passionnant, immédiat et stimulant : tout le monde a son mot à dire.

J'ai fait de la vente et j'ai même animé des séances de formation.Je pense que certaines personnes sont découragées par le manque d'édition WYSIWYG et la possibilité de coller du texte formaté à partir de Word ou d'Outlook.Je sais qu'il existe des outils pour contourner ces problèmes, mais ils restent des obstacles.

Il y a certaines zones dans lesquelles le wiki est utilisé pour enregistrer certaines zones, mais les personnes qui les mettent à jour ne font rien d'autre avec.

J'utiliserai le wiki pour documenter mon domaine de spécialisation, car il agit comme une extension cérébrale pratique.Lorsque je démarre un nouveau développement, je l'utilise comme bloc-notes pour des idées que je peux développer au fur et à mesure de sa progression.

Il serait utile que la direction lui apporte un soutien vocal, même si cela n'est pas rendu obligatoire.

J'ai du mal à amener les gens à l'utiliser, et encore moins à y contribuer.

L'un des moyens les plus simples d'amener les gens à contribuer à un wiki est de leur demander de fournir du contenu d'une manière adaptée au wiki, c'est-à-direde sorte que tout ce qu'ils publient en utilisant leurs canaux de communication habituels (groupes de discussion, listes de diffusion, forums, suivi des problèmes, chat) peut fondamentalement être inclus sur le wiki.

Pour que d'autres (utilisateurs/bénévoles) puissent simplement prendre ces contenus et les mettre sur le wiki.

Cela semble plus compliqué qu'il ne l'est en réalité, il s'agit principalement de généraliser des questions et des réponses, afin qu'elles ne fassent pas nécessairement partie d'une conversation, mais puissent être compréhensibles, significatives et utiles de manière autonome.

Par exemple une question comme celle-ci :

comment puis-je demander à git de cloner un référentiel distant ???

On peut répondre comme ceci :

Bonjour, utilisez simplement Git Clone Git: // ...

Mais les questions peuvent également recevoir des réponses de manière moins personnelle :

Afin de cloner un dépôt git, vous souhaiterez utiliser le paramètre clone pour git :git clone git://....

Ce que j'essaie de dire, c'est que la plupart des discussions dans un projet peuvent et doivent être facilement utilisées pour devenir éventuellement de la documentation.Avec ce type d’état d’esprit, votre documentation peut se développer assez rapidement.Il vous suffit d'amener les gens à garder à l'esprit que les informations utiles doivent idéalement être fournies d'une manière adaptée à l'inclusion dans le wiki.

J'ai été témoin de plusieurs cas où des projets open source ont commencé à utiliser cette approche dans une certaine mesure et, même si certaines personnes (pour la plupart de nouveaux utilisateurs) se plaignaient du fait que les réponses n'étaient pas très personnelles, le corpus de documentation augmentait régulièrement, parce que d'autres personnes surveillaient simplement ces discussions et commencé à copier/coller ces réponses sur le wiki.

Fondamentalement, c'est l'un des moyens les plus simples d'amener les gens à contribuer à un wiki, sans les obliger à l'utiliser eux-mêmes, la seule chose qui leur est demandée est un changement de pensée.

Si les développeurs ont encore besoin de maintenir une « vraie » documentation (par exempledocuments Word), je ne vois aucun moyen de reproduire cela de manière significative sur un wiki.

  • Cela n'a pas de sens que les gens écrivent deux fois
  • Toutes les données dupliquées risquent bientôt de se désynchroniser.

Ce que mon client actuel a fait, c'est déplacer tout cela vers Wiki.Donc je ne documente qu'une seule fois, et je le fais sur le Wiki.

C'est d'accord.Travailler avec Wiki est plus fastidieux qu'avec Word, mais au moins le document est en ligne et d'autres peuvent le mélanger.

Une autre solution efficace (à mon humble avis) serait de stocker les documents à côté de la source, sur Subversion.Mais le système de fusion doit alors être capable de gérer du texte riche, etc.aussi.Je ne sais pas s'il existe une solution pour cela (autre que l'utilisation de HTML ou de LaTex, qui ne seraient en fait pas de mauvais choix).

Trouvez les éléments « collants » (sub-3 p.docs / diagrammes / etc) quelque chose que l'équipe semble créer encore et encore et publiez-le sur le wiki.Assurez-vous que tout le monde a accès au wiki et sait qu'il s'y trouve - mettez en place un mécanisme de notification si possible.Avec un peu de chance, la prochaine fois qu'ils devront y accéder, plutôt que de l'extraire du contrôle de version ou de leurs machines, ils devraient accéder au wiki.S'ils ne le font toujours pas, essayez de voir si l'équipe a suffisamment de temps pour utiliser réellement le wiki. Des problèmes plus subtils peuvent se cacher derrière leur réticence.

Jetez un oeil aux conseils sur http://www.ikiw.org/ Développez votre wiki

Juste pour ajouter à certains des excellents conseils proposés ici...

En tant que développeur dans une petite entreprise qui effectue en grande partie du travail sous contrat avec le gouvernement sur une période de 6 à 24 mois, je trouve que mon temps est souvent partagé entre le développement et la rédaction de rapports d'état (au même titre que la rédaction de la documentation, mais en pire !). un wiki permettant d'annoter les pensées et les notes non organisées au fur et à mesure a rendu la rédaction de rapports beaucoup moins pénible (pas MOINS douloureuse, mais meilleure tout de même).

De plus, si vous êtes déjà dans le monde Mediawiki, vous voudrez peut-être consulter SémantiqueMediawiki.Il vous permet de porter l'organisation de vos données à un autre niveau en les balisant sémantiquement.Cela ne veut pas dire grand-chose en soi, je sais, mais je peux vous dire (par exemple) que cela peut considérablement améliorer la pertinence des données renvoyées par les recherches.Cela vaut vraiment le détour.

Généralement de bons conseils ici.J'aimerais ajouter :

  1. Vous avez vraiment besoin un champion - quelqu'un qui pousse cela auprès des développeurs et de la direction (sans être arrogant - c'est un défi !) et fournir un support et des tutoriels lorsque cela est possible.Cette personne doit également être un pair (donc un collègue développeur, pas quelqu'un dans un service informatique distant) et vraiment axée sur le client, c'est-à-direprêt à apporter des modifications sur demande.
  2. En parlant de changements, certaines personnes ici disent les wikis ne sont pas structurés.Je ne suis pas d'accord.Notre installation MediaWiki est structurée en catégories, notamment avec deux extensions :AvertirAucuneCatégorie (pour obliger les utilisateurs à ajouter une catégorie lors de l'enregistrement d'une page) et CatégorieArbre pour montrer comment toutes les catégories s'emboîtent (cela peut être lié à partir de la barre latérale).J'ai d'autres conseils sur la manière de maintenir ce seuil bas, si cela vous intéresse.
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top