30-07-22, 15:51
Cette discussion est étrange, à la fois inquiétante et rassurante pour l'avenir de Darktable.
J'ai 20 ans d'expérience dans mon métier. Je ne travaille pas dans l'informatique mais dans un domaine où je suis amené à utiliser de nombreux logiciels spécifiques. Et pour certains, j'ai assisté de loin ou de près à leur mise en place.
Absolument tous ont eu des difficultés similaires à celles exposées ici.
Et finalement, je vois toujours un schéma similaire dans la mise en place de ces logiciels:
1. une personne a une idée d'utiliser un logiciel pour faire telle tache métier. Il imagine souvent un truc simple de type une entrée, une sortie.
2. elle en parle à son chef qui trouve que c'est une bonne idée et lance le développement.
3. l'informatique commence à travailler et demande un cahier des charges décrivant ce que doit faire le logiciel. Là ça se complique car la personne qui a eu l'idée parle avec les termes de son métier comme si les informaticiens savaient exactement de quoi elle parle.
4. s'organisent alors des réunions réunissant plusieurs personnes du métier pour définir ce qu'ils veulent. Sauf que la plupart de ceux qui sont désignés, en fait, n'y sont sont pas intéressés.
5. tant bien que mal, le cahier des charges est fait par 2 des 10 personnes ayant assisté aux réunions, et la conception du logiciel avance.
6. une première version est fournie au métier pour la tester. Elle correspond techniquement à peu près au cahier des charges, sauf que l'interface n'est pas comme l'utilisateur l'avait imaginé, mais surtout l'utilisateur avait oublié de prendre en compte les cas particuliers dans le cahier des charges initial.
7. on révise le cahier des charges, toujours peu de gens du métier se sentent concernés.
8. Nouvelle version à tester, ça commence à être pas mal. Là les gens du métier qui s'en foutaient jusque là s'y intéressent, trouvent ça bien et commencent à avoir plein d'idées pour l'améliorer.... et la hiérarchie dit banco.
9. BADABOUM! les nouvelles fonctionnalités non prises en compte dès le départ s'intègrent mal, le budget et le calendrier restent les mêmes... Le logiciel finalement lancé irrite tout le monde, développeurs comme utilisateurs. Dans le meilleur des cas, le budget et le calendriers sont allongés mais ça n'empêchent pas les catastrophes industrielles (2 ans de retard, budget multiplié par 4, fonctionnalités de bases à peine fonctionnelles, certaines fonctionnalités critiques pour le métier qui ne fonctionnent pas... mais il faut y aller quand même, ça nous a couté trop d'argent).
10. dans certains cas, il faut des patchs et mises à jour pendant plusieurs années par la suite pour ne serait-ce qu'aboutir au cahier des charges.
11. dans le pire des cas, 3 ans après, on développe un nouveau bidule pour remplacer celui-là.
C'est un résumé mais c'est à peu près ça.
Là je donne l'exemple de la mise en place d'un nouveau logiciel, mais le même scénario existe pour des projets purement métiers. Il y a toujours des égos dans un projet pour profiter de l'opportunité de se faire mousser, quitte à desservir l'intérêt général. Et la hiérarchie est souvent aveugle à cela. Mettre en place des nouveaux process qui n'apportent pas de plus values voire ralentissent le travail, ça existe partout. Je me méfie toujours, par expérience, des gens qui parlent trop et qui sont trop enthousiastes. Et j'écoute particulièrement les gens discrets ou les râleurs constructifs.
Darktable ne semble pas très différent donc. Mais de ce que j'observe, Darktable fonctionne mieux (d'un point de vue utilisateur final) que certains logiciels métiers que j'utilise. Donc tout ne va pas si mal.
Néanmoins j'invite les développeurs à ne pas ignorer certaines alertes comme Aurélien Pierre peut en faire. Il me semble que la longévité d'un projet informatique nécessite une certaine "propreté du code". Ceci permet à la fois les développements au fil de l'eau et minimiser la puissance nécessaire à faire tourner le logiciel sur tout type de machine (pour DT, mon ancien portable avec un i5, 4 Go de Ram et une carte video correcte soufflait tout ce qu'il pouvait quand je bougeait les curseurs. Mon pc actuel avec un i7, 12 Go de Ram et une bonne carte vidéo a toujours un temps de latence avant d'afficher un résultat).
Enfin, pour calmer le débat et faire en sorte que tout le monde regarde dans la même direction, je ne vous conseillerais qu'une chose basique, que je répète sur tous les projets pro auxquels je participe: Revenez aux définitions et appelez un chat un chat.
Au fil du temps, on peut être amené à oublier ou mal interpréter les définitions des mots qu'on utilise, à tel point que 2 personnes pensant discuter d'une même chose en arrive en fait à parler de 2 choses différentes en utilisant le même mot.
- Si Darktable est par définition un logiciel tout en un, alors il est tout en un.
- Appeler un chat un chat, je ne sais pas si c'est le cas dans le projet DT, mais dans ma boîte, on aime bien donner 2 ou 3 noms différents à une même chose. C'est débile mais personne ne trouve rien à y redire (on a un logiciel qui a un nom métier, une url pour y accéder qui n'a absolument rien à voir avec le nom métier, et un autre nom quand on doit appeler l'assistance informatique). Je vous déconseille de nommer plusieurs fois une même chose ;-).
Je ne sais pas si ça aidera le développement de Darktable dans le futur, mais les similitudes me semblaient tellement évidentes avec d'autres de mes expériences qu'il me semblait utile de vous les partager.
J'ai 20 ans d'expérience dans mon métier. Je ne travaille pas dans l'informatique mais dans un domaine où je suis amené à utiliser de nombreux logiciels spécifiques. Et pour certains, j'ai assisté de loin ou de près à leur mise en place.
Absolument tous ont eu des difficultés similaires à celles exposées ici.
Et finalement, je vois toujours un schéma similaire dans la mise en place de ces logiciels:
1. une personne a une idée d'utiliser un logiciel pour faire telle tache métier. Il imagine souvent un truc simple de type une entrée, une sortie.
2. elle en parle à son chef qui trouve que c'est une bonne idée et lance le développement.
3. l'informatique commence à travailler et demande un cahier des charges décrivant ce que doit faire le logiciel. Là ça se complique car la personne qui a eu l'idée parle avec les termes de son métier comme si les informaticiens savaient exactement de quoi elle parle.
4. s'organisent alors des réunions réunissant plusieurs personnes du métier pour définir ce qu'ils veulent. Sauf que la plupart de ceux qui sont désignés, en fait, n'y sont sont pas intéressés.
5. tant bien que mal, le cahier des charges est fait par 2 des 10 personnes ayant assisté aux réunions, et la conception du logiciel avance.
6. une première version est fournie au métier pour la tester. Elle correspond techniquement à peu près au cahier des charges, sauf que l'interface n'est pas comme l'utilisateur l'avait imaginé, mais surtout l'utilisateur avait oublié de prendre en compte les cas particuliers dans le cahier des charges initial.
7. on révise le cahier des charges, toujours peu de gens du métier se sentent concernés.
8. Nouvelle version à tester, ça commence à être pas mal. Là les gens du métier qui s'en foutaient jusque là s'y intéressent, trouvent ça bien et commencent à avoir plein d'idées pour l'améliorer.... et la hiérarchie dit banco.
9. BADABOUM! les nouvelles fonctionnalités non prises en compte dès le départ s'intègrent mal, le budget et le calendrier restent les mêmes... Le logiciel finalement lancé irrite tout le monde, développeurs comme utilisateurs. Dans le meilleur des cas, le budget et le calendriers sont allongés mais ça n'empêchent pas les catastrophes industrielles (2 ans de retard, budget multiplié par 4, fonctionnalités de bases à peine fonctionnelles, certaines fonctionnalités critiques pour le métier qui ne fonctionnent pas... mais il faut y aller quand même, ça nous a couté trop d'argent).
10. dans certains cas, il faut des patchs et mises à jour pendant plusieurs années par la suite pour ne serait-ce qu'aboutir au cahier des charges.
11. dans le pire des cas, 3 ans après, on développe un nouveau bidule pour remplacer celui-là.
C'est un résumé mais c'est à peu près ça.
Là je donne l'exemple de la mise en place d'un nouveau logiciel, mais le même scénario existe pour des projets purement métiers. Il y a toujours des égos dans un projet pour profiter de l'opportunité de se faire mousser, quitte à desservir l'intérêt général. Et la hiérarchie est souvent aveugle à cela. Mettre en place des nouveaux process qui n'apportent pas de plus values voire ralentissent le travail, ça existe partout. Je me méfie toujours, par expérience, des gens qui parlent trop et qui sont trop enthousiastes. Et j'écoute particulièrement les gens discrets ou les râleurs constructifs.
Darktable ne semble pas très différent donc. Mais de ce que j'observe, Darktable fonctionne mieux (d'un point de vue utilisateur final) que certains logiciels métiers que j'utilise. Donc tout ne va pas si mal.
Néanmoins j'invite les développeurs à ne pas ignorer certaines alertes comme Aurélien Pierre peut en faire. Il me semble que la longévité d'un projet informatique nécessite une certaine "propreté du code". Ceci permet à la fois les développements au fil de l'eau et minimiser la puissance nécessaire à faire tourner le logiciel sur tout type de machine (pour DT, mon ancien portable avec un i5, 4 Go de Ram et une carte video correcte soufflait tout ce qu'il pouvait quand je bougeait les curseurs. Mon pc actuel avec un i7, 12 Go de Ram et une bonne carte vidéo a toujours un temps de latence avant d'afficher un résultat).
Enfin, pour calmer le débat et faire en sorte que tout le monde regarde dans la même direction, je ne vous conseillerais qu'une chose basique, que je répète sur tous les projets pro auxquels je participe: Revenez aux définitions et appelez un chat un chat.
Au fil du temps, on peut être amené à oublier ou mal interpréter les définitions des mots qu'on utilise, à tel point que 2 personnes pensant discuter d'une même chose en arrive en fait à parler de 2 choses différentes en utilisant le même mot.
- Si Darktable est par définition un logiciel tout en un, alors il est tout en un.
- Appeler un chat un chat, je ne sais pas si c'est le cas dans le projet DT, mais dans ma boîte, on aime bien donner 2 ou 3 noms différents à une même chose. C'est débile mais personne ne trouve rien à y redire (on a un logiciel qui a un nom métier, une url pour y accéder qui n'a absolument rien à voir avec le nom métier, et un autre nom quand on doit appeler l'assistance informatique). Je vous déconseille de nommer plusieurs fois une même chose ;-).
Je ne sais pas si ça aidera le développement de Darktable dans le futur, mais les similitudes me semblaient tellement évidentes avec d'autres de mes expériences qu'il me semblait utile de vous les partager.