Vite, un knowledge base/wiki avant qu'on nous force de nouveau à utiliser confluence

Alors, je suis dans un petit groupe de dev, moins de 10.
Notre knowledge base/wiki actuel c’est google drive. Le résultat évident, c’est que personne n’a envie d’y aller chercher des infos, personne à envie d’en rajouter, c’est lent, c’est l’horreur.

Bonne nouvelle on change. Mauvaise nouvelle, c’est Confluence. Pour donner un peu de contexte, on est sur Jira depuis quelques temps, et j’ai développé un haine, une véritable haine pour cette boite. Jira est lent, tellement tellement lent. L’interface est horrible, ça me rends fou.
Ducoup, hors de question qu’on continue vers Confluence. J’ai tempêté comme j’ai pu, rien à faire, mais coup du destin, confluence nous a fait en quelques jours une facture salée alors que la version d’essai gratuite était sélectionnée :smiley:
Ducoup j’ai le droit à quelques jours pour trouver une alternative :slight_smile:

Je cherche un genre de wiki, rapide, fluide et agréable à utiliser, pas prise de tête, avec recherche textuelle qui fonctionne, et possibilité d’y mettre des blocs de code/json. Bref, du workflow simple.
Genre je crée une page pour documenter les type de donnée en sortie d’un programme, je fait des liens entre les page, je met de tags, et je recherche dans les pages de l’équipe.

Est-ce que vous auriez quelquechose d’agréable à utiliser ?

En option si jamais il y a une fonction ticketting/gestion de sprints qui puisse me servir de cheval de troie pour virer Jira, c’est un plus, mais rien d’obligatoire, l’important c’est la partie wiki.

Notion?

3 « J'aime »

Notion ça peut le faire, mais en fonction du public, le premier contact peut désarçonner.

Sinon Github et Gitlab offrent les fonctionnalités que tu cherches (wiki, tickets, board). Ça reste basique et pas comparable à des outils dédiés, mais peut-être que dans ton contexte c’est le plus adapté.

2 « J'aime »

Désolé si je réponds a côté de la plaque, mais un Dokuwiki ?
https://www.dokuwiki.org/dokuwiki

1 « J'aime »

Je viens de passer sur Gitlab pour mes clients et ça fait le taf. Git, suivi de bugs, wiki en markdown, rôles des utilisateurs, etc.

2 « J'aime »

Je dirais aussi un repo GitHub avec que du Markdown, ça devrait être gérable pour des devs.

2 « J'aime »

Notion à 100%, c’est un outil pour faire SON outil, donc oui ça s’improvise pas complètement (même à titre perso quand on passe la vitesse supérieure) mais c’est godlike.

Link vers des usecases de sociétés diverses.

2 « J'aime »

Sinon, t’as vraiment essayé Confluence ou tu te bases juste sur ton experience de Jira pour juger ?
Parce que c’est loin d’etre le pire truc de la terre. Enfin, comparé a Jira, c’est meme plutot pas mal :slight_smile:

Pour être franc, du peu qu’on a utilisé confluence, c’était ok. Pas extraordinaire, pas au point que je le trouve bien, rapide, ou que ça se détache du reste niveau qualité. Mais effectivement, c’était pas manifestement en dessous de la concurrence ou des autres web app que je dois m’infliger au quotidien.

Par contre, j’avoue, j’ai la vraiment haine concernant Jira. Celui-ci est manifestement en dessous de tout, et c’est le deuxième taf où ça m’est imposé. Alors je ne sais pas comment cette horreur à fait pour devenir si ubiquitaire, je sais pas quels moyens ils ont mis en oeuvre pour faire oublier aux décideurs à quel point ils sont mauvais mais manifestement, je peux pas lutter. Alors ducoup je me rattrape sur Confluence.

Tant qu’ils auront pas fait de Jira un bon logiciel (trop tard pour juste passable), je freinerai des quatre fers contre tous les outils de cet éditeur qui a un manque de respect manifeste pour ses utilisateurs.
Et au passage, si jamais je peux découvrir un bon Wiki/KB, c’est bon à prendre

Jira est un bon logiciel . Le souci c’est qu’il est tellement configurable que 99% des boites que je connais qui l’utilisent font de la merde avec .

6 « J'aime »

est-ce que finalement un progiciel qui permet de s’auto détruire, n’est pas un mauvais progiciel? Qui devrait limiter sa config à des choses exploitables?

1 « J'aime »

Après c’est toujours la même chose, on adore tordre le cou des soft pour qu’ils collent au process plutôt que de réfléchir à faire coller le process aux outils.
Tu te retrouves avec une multitude de workflow débiles au lieu d’un ou 2 correct.
Mais bref, on dévie du sujet.

Nous on avait un wiki qui fonctionnait plutôt bien et qu’ils ont décidé de remplacer par Jive (https://www.jivesoftware.com/). Dieu que c’est de la merde.

2 « J'aime »

Ça dépend du type de logiciel et du type de client.
Et puis Jira à la base c’est pas non plus super compliqué si tu ne commence pas à le tweaker dans tous les sens.

2 « J'aime »

yep mais je me bas tellement au quotidien, pour que le process s’adapte au logiciel, comme le dis @vylsain .
Et t’a toujours un mec qui fait le forcing auprès de la direction, et m’impose le dev pour tordre le logiciel.
« ca va foutre la merde, je vous l’aurais dit! » je devrait le coller sur ma porte :slight_smile:

Nous on est sur docuwiki et c’est l’enfer.

Run, you fools !

1 « J'aime »

Je voudrais bien enfoncer le clou pour jira.
Jira il fait du ticketting. Son boulot premier c’est juste de gérer des post de quelques kilo-octets et de faire de la recherche textuelle sur une base de d’a peine quelques Méga-octets. Comment est-ce qu’ils font pour en faire un logiciel aussi lent. Si je passe du board au backlog, il faut entre 3 et 4 secondes ! C’est ridicule pour une app si simple. En temps de transmission du signal c’est aux environ de deux fois la distance Terre-Lune. Et j’étais sur fibre optique au boulot, et je suis sur fibre optique chez moi.

Et en plus tu voie qu’il essaie très fort, genre au bout de deux secondes ils te chargent le squelette de la page sans aucune information puis deux secondes plus tard enfin des trucs commencent à s’afficher.
C’est comme si j’étais dans un jeu type unreal engine, sauf qu’au lieu de prendre plusieurs secondes pour charger des textures de plusieurs centaines de Mo avec gestion de la lumière et effets transparence, ça affiche juste 4 paragraphe de texte pour une taille totale de 4.2 Ko.

Et c’est comme ça partout dans l’application. Créer un nouveau ticket, tiens une seconde de latence. Oups, tu as oublié de regarder quelque chose sur un autre ticket, tiens encore une seconde de latence pour cacher la popup de création de ticket, encore une seconde complète pour ouvrir le ticket que tu voulais vérifier, encore une pour fermer le ticket, et encore dernière une pour retourner à la création de ticket.

Sans rire, avec des lenteurs pareil ils pourraient au moins avoir la gouaille de miner du bitcoin sur mon pc, au moins je souffrirai par leur appât du gain, pas par leur incompétence.

Bon, je parle même pas de la recherche, j’ai trop de mal à garder mon calme

C’est pas juste que leurs workflow peuvent être pourris si on les tords, c’est surtout que le logiciel est horriblement mauvais, et que plus on y passe de temps plus on souffre. Le meilleur workflow c’est celui ou l’on passe le moins de temps possible sur jira.

Mon client actuel (une GROSSE banque) utilise Confluence et on ne note pas de grosses lenteurs dessus. Je n’ai pas du tout été impliqué dans son implémentation donc je ne sais pas s’ils l’ont installé sur un supercomputer de la NASA, s’ils ont sacrifié 100 jeunes vierges ou s’ils ont tout simplement fait appel à un expert pour l’installer, mais c’est peut-être juste un problème de configuration? :slight_smile:

non ils ont utilisés de vieilles vierges, c’est bien plus rare !

2 « J'aime »

Il y a doc et doc, même avec les contraintes que tu donnes.

Les bonnes questions à te poser avant de faire le choix :

  • qui va s’en servir ? qui va lire la doc ? qui va l’écrire ?
  • quel niveau de compétence pour s’en servir (très lié au point précédent) ?
  • usage 100% interne ? ou exposé à des partenaires ? voire public ?
  • quelle organisation ? est-ce qu’il y a besoin de gérer des droits/habilitations fines ?
  • quel volume de documentation ?
  • quels rythmes de changement de la documentation ? (cycle de vie s’il y en a un, et si oui à quoi il est lié…)
  • 100% texte / hyperliens et images ? sinon quoi d’autre ?
  • quel niveau d’intégration avec les suites bureautique (Office généralement) ? c’est en complément de Word/Excel/Powerpoint ? ça les remplace ?
  • quel niveau d’intégration avec d’autres outils ? (ticketing, dépôt de sources, revue de code si c’est pour des dévs…)

Le champion toutes catégorie pour son universalité c’est le Wiki (avec par exemple XWiki).

Pour des dévs je conseillerais de mettre la doc en markdown sous git, au sein des sources (ou en tout cas au sein de l’orga de dépôts existante). Ma philosophie : la doc doit être versionnée et tenue à jour avec les sources, et ce qui concerne le déploiement/l’exploitation doit être inclus dans le packaging applicatif pour être sous les yeux de n’importe qui ayant à bosser avec.

Mais comme dit par d’autres ci-dessus, Confluence c’est quand même très fort pour faire des tableaux automatiques de reporting, des releases notes qui incluent des commits logs par exemple. Bien configuré, c’est juste génial de pouvoir lier les tâches, les commits dans BitBucket, les code reviews dans Crucible… C’est la force d’Atlassian. Il faut juste casser les rotules de l’admin système et des ITIL qui les rendent inutilisables avec leurs workflows bidons.

2 « J'aime »
  • Alors c’est les devs (moins de 10 personnes) plus le PO.
  • C’est essentiellement pour les techos, mais il faut qu’un non-dev puisse aussi la lire et l’éditer.
  • C’est pour un usage 100% interne.
  • Pas besoin de gestion de droit fine, free for all !
  • Petit volume de données, quelques dizaines de pages au final je pense. Peut-être qu’on atteindra la centaine au bout de plusieurs années.
  • Pas de process sur le cycle de vie ou quoi que ce soit, on doit juste marquer les décisions qu’on a prise, les présuposés pour plus tard, un peu de donc sur les type de donnée qu’on a en entrée du programme. C’est quand on en a besoin, donc pour un dev c’est une fois toutes les 3 semaine grosso-modo.
    *On a besoin de texte, image, hyperlien. C’est un plus de rajouter de la vidéo
    *Pas d’intégration avec les suite bureautique est attendue
    *L’intégration avec d’autres outils pourquoi pas, mais pour moi un hyperlien suffit. Après je loupe peut-être quelque chose que je ne connais pas. On utilise gitlab, Jira et slack

(au passage je retiens la doc en Markdown pour d’autres contextes :slight_smile: )