Oui, je trouve aussi.Envoyé par ProgVal
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Oui, je trouve aussi.
Si tu ne sais pas faire, apprends. Si tu fais, fais bien. Si tu sais bien faire, enseigne.
Mieux vaut paraître stupide quelques temps que rester stupide toute sa vie.
Je pense aussi toujours que l'utilisateur est un idiot, et s'il y a une connerie à faire, il la fera. Donc en croisant ce constat avec l'autre règle qui est : le travail de l'utilisateur est sacré, on arrive à faire des applications que je nomme "idiot-proof". Le genre d'application ou tu ne PEUX pas perdre une heure de travail parce que tu as fais un ctrl-A et ensuite espace
La loi de moore est un très bon compagnon dans le développement applicatif.
D'ailleurs, étant donné qu'en ce moment même je travaille sur une bibliothèque destinée à d'autres développeurs de la boîte, je pourrais même étendre à "Le développeur est un con". Eh oui, car après tout si on lui donne la possibilité de faire une connerie (ou plutôt une incohérence), il y en a bien un qui la fera, même si c'est documenté et qu'on dit clairement : "ATTENTION, si foo = bar et que foo' = bar', il y aura de terribles conflits dévastateurs".
D'ailleurs ca me fait sourir ce genre de situations
C'est de la bureautique, pas de l'informatique. Après, ce n'est que mon avis.
Bureautique / Informatique est-ce que l'un fait partie de l'autre et/ou vice versa, difficile je dirai..
La bureautique nécessite l'Informatique.. C'est donc lié, en faisant de la bureautique, on utilise des logiciels de traitements de texte etc.. Ce qui donne une base de connaissances minimale (bien qu'insuffisante pour prétendre maitriser les outils informatiques) d'utilisation de l'informatique..
Mais est-ce qu'on peut dire pour autant que faire de la bureautique c'est faire de l'informatique ? J'n'en suis pas si sur car dans ce cas, jouer sur le PC c'est aussi faire de l'informatique ! Puisque les jeux sont aussi des programmes, fait par des développeurs..
@squelos : Le probleme est qu'un scenario, qui peut-être catastrophe dans certain moment, est parfois obligatoire a implémenter.. On ne peut pas prendre trop de précaution a demander des validations a tout bout de champ, car l'utilisateur final sera content lorsque ca lui aura sauve ses heures de travail, mais ca va bien l'enquiquiner quand il voudra réellement utiliser ce scenario..
Le juste milieu est difficile a trouver alors parfois on se dédouane de la perte du travail en affirmant que tout est documente et que la prochaine fois, il lira et ne refera pas la même erreur !
RTFM !
Je me suis peut etre mal exprimé, mais je suis totalement d'accord avec toi (a moins que c'est moi qui ai mal compris ton message).
Il faut effectivement le moins possible se dire que c'est écrit, et donc qu'il doit savoir. Il devrait savoir, mais en pratique il ne sais pas. Il faut toujours partir comme tu dis du scenario catastrophe, où s'il y a une connerie qui peut etre faite à un moment, et bien elle sera faite.
C'est pour ca que ma règle d'or est : l'utilisateur est un con, s'il y a une connerie à faire, elle sera faite.
Et si les scenarios sont bien pensés, on peux realiser quelque chose de bien sans trop gener l'utilisateur (en principe au pire j'utilise une case à cocher, mais c'est vraiment dans le pire des cas)
Un exemple qui prouve que l'utilisateur peut être un informaticien...
Et que donc "la connerie de l'utilisateur" est applicable à tous, nous et vous y compris...
Je fais un soft devant être distribué sur environ 25 sites (soft critique demandé ET par la base ET par la Direction, et imposé dans tous les sites par la Direction).
Je fais une doc d'nstallation de 1 page 1/2 (dont 1/2 page en caractères 24), c'est à dire environ 35 lignes au total....!!!), à destination des admins des sites..
1 an après j'ai des coups de fil "ça marche pas, ça rame..".
Je vais sur le(s) site(s), je regarde...
La dernière ligne en 24 (et donc en première page) était "SUIVEZ LES INSTRUCTIONS CI-DESSOUS POUR ADAPTER A VOTRE SITE".
Les admins n'avaient rien adapté du tout, donc les imprimantes était celles définies par défaut (donc celle du bureau central), de même que les faxs, de même que la région visualisée... (par exemple au lieu de modifier pour avoir la RP ils avaient laissés la France)
Il n'y avait que 12 lignes à lire...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Nous partageons la même règle, je pense donc que nous partageons le meme point de vue
@souviron34 : Dans ce cas, l'utilisateur EST tout simplement un développeur/admin/webmaster ! Il entre dans la partie des 90% donc
Bon, certains sont assez futés pour soit chercher dans la doc, soit chercher sur Google (pour les programmes connus) soit chercher eux-même comment résoudre le probleme en bidouillant un peu partout (culture Geek).. Mais d'autres doivent être trop bornés pour utiliser une de ces méthodes, et demande a l'aide a tout bout de champs..
Pardonnez-moi, mais je trouve cela quand même intolérable de la part d'un 'informaticien' (j'ai horreur de ce mot !) de ne pas savoir lire une telle doc.
Je ne les insulte pas, je ne les juge pas, je n'ai pas la doc sous les yeux ni ton programme pour donner un avis plus pertinent, mais comme tu le décris laisse penser qu'il y a quand même du laisser-aller..
Je ne trouve pas ça "intolérable", c'est la nature humaine..
C'est une des raisons (et la plus "forte") pour laquelle je me bat ardemment contre toutes les métologies/environnements demandant de tout mettre (absolument tout) sur papier...
Pour des gros softs, quel informaticien va commencer par lire 270 pages de description de l'architecture d'un soft ???
Une présentation succinte de 2 pages max (et encore !!!) et il va aller fouiner dans les répertoires, regarder les noms des répertoires, des fichiers, etc etc...
Et il aura raison, car il ira sans doute 20 000 fois plus vite tout en ayant compris en gros...
Qu'il faillent des traces papiers et des documents, c'est normal. Que cela soit un aspect vital est ne pas tenir compte de la réalité...
Un code bien commenté et bien structuré est déjà à 98% ré-utilisable et maintenable...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
La oui, je suis tout a fait d'accord, moi-même je préfère bidouiller chercher de moi-même avant de vraiment demander si je n'ai vraiment plus d'espoir/temps que de lire des centaines de page de doc, mais dans le cas que tu cites juste avant il n'y avait que 35 lignes en tout..
Je suis d'accord pour chercher soi-même, mais avant de demander, on cherche dans la doc via les mot-clés (quel 'informaticien' ne connait pas la fonction rechercher par mot-clé dans une doc ?) ou on la lit entierement si elle est si courte (une page et demi disais-tu)..
Il faut savoir aussi de quelle type de donc on parle, utilisateur ou développeur ? Celle pour utiliser le programme ou celle pour reprendre/maintenir le code ?
Dans ce deuxième cas, il est impératif, je trouve, que ce soit complet si le code est complexe.. Il n'y a rien de pire que de se plonger dans un gros projet dans lequel on a pas tape une seule ligne de code, aussi simple et clair soit-il car on ne sait pas qui reprendra le code..
Certaines choses peuvent paraitre évidente pour certains développeurs, que d'autres mettrons plus de temps a comprendre.. (exemple typique : les fonctions récursives)
Pour la doc d'installation et donc utilisateur final, comme celle que tu as fourni, je pense qu'il ne faut pas la surcharger pour ne pas le décourager de lire ce dont il a besoin, de bien séparer les catégories, permettre la recherche ou la navigation facile (cf table des matières automatique dans un doc Word..) etc..
Le piège serait de faire une doc utilisateur final tellement complète (dans le sens trop d’évidences), que celui qui le lit se sente pris pour un c*n (ce qu'on est pourtant censé faire, a son insu a priori) et arrête de la lire ou lise en diagonal en loupant les aspects essentiels..
Pour résumer je paraphraserai les inconnus en disant:
"Ne jamais prendre les utilisateurs pour des cons, ... mais ne jamais oublier qu'ils le sont"
Si tu ne sais pas faire, apprends. Si tu fais, fais bien. Si tu sais bien faire, enseigne.
Mieux vaut paraître stupide quelques temps que rester stupide toute sa vie.
Pour résumer je paraphraserai les inconnus en disant:
"Ne jamais prendre les utilisateurs pour des cons, ... mais ne jamais oublier qu'ils le sont"oui oui
J'imagine que pour un utilisateur "90% des développeurs sont des idiots"
En réalité, très peu de développeurs programment pour des utilisateurs finaux qu'ils ont ensuite en face d'eux.
Mais je dois avouer que c'est une expérience parmi les plus salutaires.
L'utilisateur est un imbécile dès qu'il s'agit d'informatique. Mais quand je dis imbécile, ça prend des proportions bibliques.
Quelques cas que j'ai eus ou entendus dans ma boite :
"Outlook, c'est nul, gmail, c'est mieux..."
" - Peut-on émettre plusieurs devis pour une facture. - Cela n'a pas été prévu, et c'est désormais physiquement impossible pour notre base de données. - Mais j'ai un ami informaticien qui me dit que si, c'est possible! - ..."
" - Je comprends pas, votre intranet n'accepte pas ma date, alors qu'elle est juste (suite à de nombreuses erreurs, du genre mois 24 on a mis des masques de saisie qui bloquent la validation sur les dates erronées) - c'est à dire que le 31 juin n'a pas encore été validé"
" - La page s'affiche lentement - Normal, il y a trop de données dessus, il faut segmenter - oui, mais non, on veut toutes les données sur la même page, mais que ce soit rapide - en même temps, vous n'utilisez pas la moitié de ce qui est affiché à l'écran - oui, mais au cas où... - et créer une nouvelle page? - cliquer sur un bouton? Ah! non! ça fait une opération en plus! Donc, du temps de perdu - Parce qu'attendre qu'une page mette 30 secondes à s'afficher, c'est mieux? - ..."
Au départ nous mettions des champs de texte pour permettre d'introduire du texte et le mettre en forme avec des balises html, et nous avions sciemment désactivé le validateRequest. GROSSIERE ERREUR!!! ils nous copiaient-collaient le code html du client sans même le vérifier. Résultat, une balise comment et la moitié des données qui ne s'affichaient plus, plus tard, on revenait en arrière.
Bref, voilà. Ne jamais faire confiance à l'utilisteur. Le brider au maximum pour éviter de le voir réfléchir. Et surtout! prévoir une bonne dose de doliprane...
Nan, absolument pas -_- (pour ne pas dire n'importe quoi...).
Utiliser un outil c'est complètement différent que de le créer.
C'est aussi différent que manger et cuisiner...
Concernant le besoin en doc, je remarque que c'est bien plus demandé dans les boites ou toute la connaissance est aux mains des prestas; le plus classe étant bien sûr quand aucune GED n'existe et que tous les docs sont transmis par mail ou sur le réseau. Au final, deux ans après leur rédaction, c'est le meilleur moyen de les perdre !
=> et puis le doc ne rempalce pas l'humain. Les docs ultra détaillée pour les installations en prod suivies par des "pousse-bouton" y'en a marre ! (j'en fais depuis des semaines et que j'en peux plus, surtout que ça les empêche pas de se planter et t'apeller au moindre pépin juste parcequ'ils n'ont pas suivit à la lettre le doc...)
Oui, dur de dialoguer avec les utilisateurs.. surtout quand ils pensent tout savoir mieux que toi en terme d'ergonomie des interfaces...
A leur décharge, ils veulent le moins de changement possible par rapport à leurs "repères" ne serait-ce que pour ne pas perdre en productivité.
Si le client est trop rigide, à part se blinder au max, y'a rien à faire : "vous voulez toutes les données en mêmes temps ? Vraiment ? bah alors on s'engage pas sur les performances/temps de réponse" ect.
Tout de suite la solution extrême ! moi je pense qu'il faut au contraire au maximum former les utilisateurs et être pédagogues avec eux. Sinon ils n'amélioreront jamais leurs usages... et on continuera d'en souffrir !Bref, voilà. Ne jamais faire confiance à l'utilisateur. Le brider au maximum pour éviter de le voir réfléchir. Et surtout! prévoir une bonne dose de doliprane...
Le problème est que sur tous les utilisateurs il y en aura toujours quelques uns qui sont plus bas de plafond que les autres qui confondent l'informatique et la magie.
Et les plus pénibles sont souvent les plus gradés
Si tu ne sais pas faire, apprends. Si tu fais, fais bien. Si tu sais bien faire, enseigne.
Mieux vaut paraître stupide quelques temps que rester stupide toute sa vie.
Et le technicien qui va chez Mme Michu pour dépanner son ordinateur ? À ma connaissance, il ne crée pas, et il peut être qualifié d'informaticien (même si je n'aime pas non plus ce terme).
En allant dans ce sens, tout le monde est informaticien en se servant régulièrement d'appareils électroniques. C'est toujours une entrée, un traitement de bits et une sortie.
Disons en gros que c'est de la communication assistée par ordinateur. Assistée par ordinateur un peu comme abstraction de notions d'informatique, ce qui donne "aide-moi à communiquer" (notez l'absence de mentions de technologies) et non "j'envoie un mail pour communiquer".
Génréralisations et empathie
Il ne faut pas généraliser et juger trop vite.
Un utilisateur ne comprend pas toujours le métier de développeur et l'inverse est malheureusement vrai.
Alors pourquoi ne pas demander l'avis de l'utilisateur lorsqu'il faut faire un choix qui impactera sa perception du logiciel?
L'utilisateur sais ce qu'il veux, le programmeur n'a parfois aucune compréhension du métier de l'utilisateur et là c'est moche... Comment peut-il faire de bons choix ?
Pour la partie technique, je ne suis pas sur qu'il faille lui poser les questions.
Mettons nous un instant à la place de l'utilisateur et on se rendra compte (expérience perso) que parfois on fait des interfaces à la c**
Il suffit parfois de se servir pendant quelques heure de ce qu'on vient de créer pour comprendre que c'est ni pratique ni efficace et souvent beaucoup trop compliqué...
Moi je suis d'accord avec DrHelmut
Et je pense que c'est ce qu'il manque dans nos formations, des cours de communication, mais pas au sens marketing. Apprendre à être plus pédagogue avec les utilisateurs, et sortir de ce rôle de "gros geek" d'informaticien.former les utilisateurs et être pédagogues avec eux. Sinon ils n'amélioreront jamais leurs usages... et on continuera d'en souffrir !
Peut-être qu'il serait temps également de proposer à l’école des cours d'informatique...
J'ai intérêt à devenir développeurs pour ne pas compter parmi les idiots alors !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager