Navigation

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

Débats sur le développement - Le Best Of Discussion :

Quelles idées avez-vous de l'utilisateur final lors du développement d'une application


Sujet :

Débats sur le développement - Le Best Of

  1. #181
    Membre chevronné
    Citation Envoyé par souviron34 Voir le message
    Si un CP exigeait cela, il n'y aurait pas un patron de TPE/PME qui y verrait quoi que ce soit à redire... Qu'est-ce que 3 semaines sur la plupart des temps de devs d'applis "centrales" au fonctionnement de la boîte ???
    On doit vraiment pas vivre dans le même monde !
    Tu tiens comme acquis que les patrons de TPE/PME prennent toujours leurs décisions sur des arguments rationnels ?!

    Dis moi, t'as déjà travaillé en TPE/PME ? Parce que si oui t'es un sacré veinard
    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.

  2. #182
    Membre habitué
    La question n'est pas de savoir si 90% ou 10% des utilisateurs sont des idiots, mais d'être conscient qu'il y a toujours au moins 10% d'idiots. Il faut donc que la prise en main et l'utilisation basique soit simple, tout en gardant des options avancées rangées dans un coin pour les utilisateurs compétents.

  3. #183
    Expert éminent sénior
    Citation Envoyé par Virgil Scipion Voir le message
    tout en gardant des options avancées rangées dans un coin pour les utilisateurs compétents.
    La question n'est pas que les utilisateurs soient compétents ou pas..

    Elle est est-ce que cela fait couramment partie du travail/de l'utilisation ou peu ?
    "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

  4. #184
    Expert éminent sénior
    Citation Envoyé par zeyr2mejetrem Voir le message

    Tu tiens comme acquis que les patrons de TPE/PME prennent toujours leurs décisions sur des arguments rationnels ?!
    Non, je ne tiens pas pour acquis puisque j'avais mentionné si le CP exigeait


    (en argumentant et chiffrant, bien entendu)
    "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

  5. #185
    Membre chevronné
    Citation Envoyé par souviron34 Voir le message
    Non, je ne tiens pas pour acquis puisque j'avais mentionné si le CP exigeait


    (en argumentant et chiffrant, bien entendu)
    C'est bien ce que je disais. Dans la plupart des TPE/PME où j'ai bossé:

    - Le CP ne pouvait rien "exiger" du tout, sans quoi il était remis à sa place ou "vidé"

    - Le CP pouvait effectivement avancer des arguments et des chiffrages mais le patron n'était pas forcément "rationnel".

    Exemple qui m'est arrivé et qui a dû arriver à pas mal de monde:

    CP: Si on prend l'option A on en a pour 2 semaines de boulot mais au premier bug on est coincé et y en a pour 5 semaines de réparation.
    Si on prend l'option B on en a pour 4 semaines de dev mais on est tranquille derrière

    Boss: J'ai pas de budget (Ce qui était faux car on avait vendu 8 semaines mais c'est trop tentant d'"empocher le differentiel"). On prend l'option A et on vendra une prestation de maintenance derrière

    Conclusion:
    Au lieu de rentrer une licence en récurrent tous les ans on a rentré 1 seule licence annuelle + 1 presta de réparation + 1 client mécontent qui nous a sorti dès qu'il a pu. Bonjour la vision à long terme !
    C'est pas pour rien que certaines PME avec un super concept RESTENT des PME
    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.

  6. #186
    Expert éminent sénior
    Citation Envoyé par zeyr2mejetrem Voir le message
    On prend l'option A et on vendra une prestation de maintenance derrière
    Ah mais tu parles de PME/TPE de type SSII...

    Moi je parlais de TPE/PME industrielles...


    Pour le type SSII, qu'elles soient petites ou grandes, leur but est de faire du fric en louant ses services...

    Donc bien entendu...
    "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

  7. #187
    Rédacteur

    Si il existe des ergonomes et de designers ce n'est pas pour rien.
    Faire une bonne IHM (car la on parle bien d'IHM) c'est difficile.

    "90% des utilisateur sont des idiots" c'est très dégradant pour l'utilisateur.

    Mais y as quelque chose de fondamentale (ce que voulais surement souligner l'auteur). Les utilisateurs finaux préfère des IHM jolie, simple et qui se comprend facilement. Ce qui ne veux pas dire pour moi qu'ils sont idiot. Bien au contraire. Plus une IHM est simple, plus les utilisateurs voudront l'utiliser, plus l'application sera robuste (Pourquoi y as un boutton là? je ne sais plus ) et plus se sera gratifiant.
    Combien d'application sont mise à poubelle après un ans pour en re développer une? C'est dû n'importe quoi.

    Je pense que la mentalité change énormément. Avant, l'utilisateur devaient s'adapter au logiciel. Maintenant c'est le contraire.

    Pour moi, une IHM doit être agréable et donner envie. Presque comme une jeux. Si le sujet vous interesse, je vous conseil "L'art du game design". C'est orienté jeux mais, il y as beaucoup des choses vrai pour n'importe quel domaine. Dont les IHM. Vous y comprendrais l'un des mots le plus important : le feedback.

  8. #188
    Futur Membre du Club
    Reponse d'un utilisateur
    En tant qu'utilisateur, je me dis toujours que 90% des développeurs sont des crétins. Peut-être que est-ce parce que ces 90% de développeurs prennent les gens pour des cons!

  9. #189
    Membre à l'essai
    tous les gens intelligents deviennent idiots quand on les prends pour tels

    tous les idiots ne deviennent pas intelligents quand on les prends pour tels,
    mais beaucoup quand même

  10. #190
    Membre du Club
    En tant qu'utilisateur, je me dis toujours que 90% des développeurs sont des crétins. Peut-être que est-ce parce que ces 90% de développeurs prennent les gens pour des cons!
    C'est pour quoi on met toujours des commerciaux et des chefs de projets entre les développeurs et les utilisateurs ! sinon ils s'éttriperaient.

    En tout cas prendre ces clients pour des idiots n'est peut etre pas une bonne approche pour une relation durable... On est pas là pour juger nos clients mais pour leur vendre un service et faire le nécessaire pour qu'ils reviennent vers nous la prochaine fois sans consulter nos conccurents tellement ils sont satisfaits de nous, non?

    Rendre une application métier simple et à la portée de n'importe quel utilisateur est un des moyens les plus gratifiants dans notre métier pour accomplir cet objectif.

  11. #191
    Membre à l'essai
    Je dirais, de manière plus réaliste, et aussi plus aimable, que les utilisateurs ne sont pas des idiots, mais tout simplement des personnes qui n'ont pas appris à développer.

    Il ne faut donc pas s'attendre à ce qu'ils comprennent le fonctionnement de nos logiciels, ni les raisons "logicielles" qui nous poussent à disposer l'interface utilisateur d'une façon plutôt que d'une autre.

    Ainsi un bon codeur ne partira pas du fait que l'utilisateur "doit" savoir programmer pour se servir d'un logiciel, ni qu'il ait le temps d'apprendre des manoeuvres ou des mots-clés abscons.

    Une bonne équipe de programmation comprendra donc forcément un responsable de l'ergonomie, qui fera tester les logiciels par des gens réels, qui ne connaissent pas l'informatique, mais qui sont tout de même compétents dans l'activité concernée.

    Faire tester le logiciel par un paysan assis sur une botte de paille...


    Et puis les "idiots" comptent des gens qui sont très compétents dans d'autres domaines, des gens du Tiers monde qui sont déjà heureux de savoir lire, et des gens extras, qui ne savent pas programmer, mais qui font des choses super... dont nous avons grandement besoin. Rendons-leur donc service, au lieu de les bousculer.

  12. #192
    Membre éclairé
    et si l'application à développer est faite pour les développeurs. le développeur sera donc l'utilisateur, quel sera donc le taux d'idiotie de l'utilisateur?

    sachant que le développeur fait une application pour développeur( ce qui change donc le développeur en utilisateur) ,ça donne un utilisateur qui code une application pour développeur... ce qui rend le problème assez récursif pour devenir un non-problème.

    au final, X % des utilisateurs sont idiots et comme le problème est récursif, X % des développeurs sont idiots.

    pour déterminer la valeur X, il faut une étude complémentaire nécessitant un laboratoire au CNRS et un budget de Y €, Y étant une valeur à étudier de manière démocratique.

    [edit]
    ce post contient 8 fois le mot développeur, dont 2 au pluriel. contre 5 itérations du mot utilisateur.

    ce qui porte à croire que finalement, c'est plus un problème de développeur que d'utilisateur.

    je verrais plus les applications métiers sous forme de simulateur, un peu comme simfarm pour un fermier, simcity pour un maire... avec une interface correspondant à la représentation exacte du métier de l'utilisateur

  13. #193
    Membre à l'essai
    je verrais plus les applications métiers sous forme de simulateur, un peu comme simfarm pour un fermier, simcity pour un maire...

    le comble de l'idiotie, c'est quand le codeur redéfinit le métier de l'utilisateur...


    Les vaches doivent-elles apprendre à coder, pour pouvoir être traites par la trayeuse informatisée???

  14. #194
    Inactif  
    Citation Envoyé par Richard Trigaux Voir le message
    le comble de l'idiotie, c'est quand le codeur redéfinit le métier de l'utilisateur...:
    Ca s'appelle du Business Process Reengineering et c'est fréquent sur des nouveaux projets, surtout quand il s'agit de créer une application spécifique pour améliorer la réponse à un besoin tant bien que mal rempli précédemment via des feuilles Excel, requête BI, etc ..... , mais visiblement vous l'ignorez.

    Content de lire que c'est le comble de l'idiotie. (d'après vous ...... sans commentaire).

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  15. #195
    Membre chevronné
    Citation Envoyé par Bluedeep Voir le message
    Ca s'appelle du Business Process Reengineering et c'est fréquent sur des nouveaux projets, surtout quand il s'agit de créer une application spécifique pour améliorer la réponse à un besoin tant bien que mal rempli précédemment via des feuilles Excel, requête BI, etc ..... , mais visiblement vous l'ignorez.

    Content de lire que c'est le comble de l'idiotie. (d'après vous ...... sans commentaire).
    Dans le BPR, comme tu l'as si bien expliqué, tu améliore la réponse au besoin métier.
    Tu ne dis pas à l'utilisateur de modifier le besoin métier lui même, non ?

    C'était, à mon humble avis, la teneur du propos du précédent posteur ...
    Faut pas prendre la mouche si vite
    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.

  16. #196
    Membre éclairé
    redéfinir une interface utilisateur n'est pas en soi une redéfinition du besoin métier.

    il existe une tonne et demi de moyens de faire une interface utilisateur, de celle pleine de boutons à celle pleine de lignes de commandes.
    entre les deux, il y a une infinité de nuances à prendre en compte.

    c'est d'ailleurs le principal défit de la programmation, d'essayer d'améliorer les interface utilisateur, de les simplifier, de les rendre intuitives. et tant que l'on a pas essayé une solution, on ne peut pas affirmer que c'est la bonne ou la mauvaise.

  17. #197
    Inactif  
    Citation Envoyé par edfed Voir le message
    redéfinir une interface utilisateur n'est pas en soi une redéfinition du besoin métier.

    il existe une tonne et demi de moyens de faire une interface utilisateur, de celle pleine de boutons à celle pleine de lignes de commandes.
    entre les deux, il y a une infinité de nuances à prendre en compte.

    c'est d'ailleurs le principal défit de la programmation, d'essayer d'améliorer les interface utilisateur, de les simplifier, de les rendre intuitives. et tant que l'on a pas essayé une solution, on ne peut pas affirmer que c'est la bonne ou la mauvaise.
    Je ne parlais pas des interfaces utilisateurs.

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  18. #198
    Membre éprouvé
    Citation Envoyé par Bluedeep Voir le message
    Ca s'appelle du Business Process Reengineering et c'est fréquent sur des nouveaux projets, surtout quand il s'agit de créer une application spécifique pour améliorer la réponse à un besoin tant bien que mal rempli précédemment via des feuilles Excel, requête BI, etc ..... , mais visiblement vous l'ignorez.

    Content de lire que c'est le comble de l'idiotie. (d'après vous ...... sans commentaire).
    Comprendre le métier de l'utilisateur pour lui créer les outils appropriés (ce que l'on est sensé faire comme tu dis), ça n'est pas la même chose que réinventer le métier de l'utilisateur (comme trop de développeurs ont tendance à faire, comme l'a souligné Richard)

  19. #199
    Membre à l'essai
    Guilp: Comprendre le métier de l'utilisateur pour lui créer les outils appropriés (ce que l'on est sensé faire comme tu dis), ça n'est pas la même chose que réinventer le métier de l'utilisateur
    C'est exactement ce que je voulais dire.

    C'est malheureusement une prétention de nombreux codeurs que de vouloir plier les gens à leurs besoins de programmation... la tentation du pouvoir, toujours!

    Un exemple emblématique et douloureux est celui de Linden Lab, dont le système génial, Second Life, a permis des initiatives sociales fantastiques. Mais maintenant Linden Lab s'ingénie à pourrir la vie des utilisateurs de Second Life, en leur proposant leur conception étriquée de la vie sociale...


    L'informatique serait bien le seul métier où on ignorerait les besoins de l'utilisateur. Tout le monde fait cela: se renseigner des besoins de l'utilisateur (du client) et fournir un produit adapté. C'est ce qui rend la chose passionnante, soit dit en passant.

  20. #200
    Nouveau Candidat au Club
    quelles idées avez vous de l'utilisateur
    moi, bien ke je ne soit pas encor un grand professionnel de haut rang j e sais juste une chose c'est que les developpeurs doivent mettre sur pied des applications qui devrons venir en aide aux utilisateurs et non pas qui devraient imposer des conditions de vies insupportables pour ces derniers