IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 :

Projets informatique : les bonnes pratiques


Sujet :

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

  1. #141
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    Je lis beaucoup de choses très juste, mais je pense aussi à certains contextes de l'informatique.
    Où l'on exerce son métier, gagne pain ou art, les attentes sont différentes.

    Ca dépend aussi du service :
    Une SSII qui vend du dev pur et généraliste ne peux pas avoir les mêmes methodologies qu'une SSII qui vend du développement spécialisé.
    C'est souvent là qu'est le problème d'ailleurs : les responsabilités ne sont pas clairement définies.
    Je ne vois pas trop par ex souvent le fait qu'une SSII mette un chef de projet alors que le client en face pose une équipe de MOA --> Un commercial est suffisant, surtout que la plupart du temps, il va s'agir de border la relation et d'éviter les débordements

    En revanche, si la ssii vend et le dev et la culture métier du client, il va avoir tendance à poser un chef de projet, ou tout autre diminutif disponible à la sensibilité du tiers qui va être globalement le garant de l'expertise vendu.

    En fait, la meilleure pratique reste le pragmatisme : si on pose une méthode dès le début sans s'attacher au contexte dans lequel le projet s'inscrit, la démarche pourra être plus ou moins heureuse.

    D'autant que l'effet pervers de beaucoup de méthodes et davantage de garantir la couverture de responsabilité que le résultat.

    Voilà la réalité est aussi que beaucoup d'entreprises qui pensent savoir gérer des projets sont complêtements ignorantes sur les domaines de gestion de la qualité et donc sont peu outillées pour tirer des leçons du passé.

    Beaucoup de projet échouent aussi parce qu'il n'y a pas de management de haut niveau (soit de décision et d'arbitrages) et le projet finit en lettre au pére noël.

    Pour moi, CMMI et consors, ce sont au mieux des caches misére dans la culture projet de la plupart des entreprises.

    On assiste encore aujourd'hui à des projets qui sont bien gérés sur le papier, et un plus tards, on se rend compte que personne n'a travaillé le déploiement.

  2. #142
    Membre expert
    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2005
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 473
    Points : 3 283
    Points
    3 283
    Par défaut
    Citation Envoyé par chaplin Voir le message
    Le Crédit Agricole est passé sur Cobol.NET
    Avec du mainframe en site central ?

  3. #143
    Inactif  
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 58
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par chaplin Voir le message
    Pas tout à fait, car c'est la réaction "inespérée" q[...]
    Je suis vraiment tomber sur la bonne personne pour mon illustration
    Je ne suis pas sûr d'avoir compris ton point. Mais je suis content d'être la bonne personne

  4. #144
    Membre chevronné Avatar de chaplin
    Profil pro
    Inscrit en
    Août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 1 215
    Points : 1 819
    Points
    1 819
    Par défaut
    Citation:
    Envoyé par chaplin
    Le Crédit Agricole est passé sur Cobol.NET

    Avec du mainframe en site central ?
    Je me base sur un numéro de 01 Informatique de 2006 ou 2007 dont le Crédit Agricole avait fait la couverture me semble-t-il.

    Autrement, je ne peux parler guère plus du sujet qui tient en quelques mots. B.A.F a réagit positivement sur ma remarque. En tout cas, je ne l'ai pas rêvé cet article, je n'ai plus la main dessus, donc mes commentaires s'arrêtent là sur ce sujet.

    Si j'ai dit une bétise ou fait une remarque érronée, j'invite les spécialistes a etayer le sujet.

    J'ai payé une fois pour mon franc parlé, pas une deuxième fois pour faire allusion à Garulfo dont je subodore un interêt pour l'histoire ... des guerres plus précisement.

    EDIT:

    Citation Envoyé par B.A.F
    D'autant que l'effet pervers de beaucoup de méthodes et davantage de garantir la couverture de responsabilité que le résultat.
    ...
    Beaucoup de projet échouent aussi parce qu'il n'y a pas de management de haut niveau (soit de décision et d'arbitrages) et le projet finit en lettre au pére noël.
    En fait, de ce que j'ai vu, les projets informatiques induisent une part juridique non négligeable car elle engage la responsabilité à la fois du client et du chef de projet. Donc certaines frilosités de part et d'autre peuvent conduire à des situation qui paralysent le projet.

    Le management de haut niveau, une solution peut être le coaching, c'est à dire un intervenant exterieur qui à un point de vu neutre pour justement faire l'arbitrage.

  5. #145
    Membre averti Avatar de ZeRevo
    Inscrit en
    Avril 2007
    Messages
    302
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : Avril 2007
    Messages : 302
    Points : 342
    Points
    342
    Par défaut
    Citation Envoyé par B.AF Voir le message
    Je lis beaucoup de choses très juste, mais je pense aussi à certains contextes de l'informatique.
    Où l'on exerce son métier, gagne pain ou art, les attentes sont différentes.

    Ca dépend aussi du service :
    Une SSII qui vend du dev pur et généraliste ne peux pas avoir les mêmes methodologies qu'une SSII qui vend du développement spécialisé.
    C'est souvent là qu'est le problème d'ailleurs : les responsabilités ne sont pas clairement définies.
    Je ne vois pas trop par ex souvent le fait qu'une SSII mette un chef de projet alors que le client en face pose une équipe de MOA --> Un commercial est suffisant, surtout que la plupart du temps, il va s'agir de border la relation et d'éviter les débordements

    En revanche, si la ssii vend et le dev et la culture métier du client, il va avoir tendance à poser un chef de projet, ou tout autre diminutif disponible à la sensibilité du tiers qui va être globalement le garant de l'expertise vendu.

    En fait, la meilleure pratique reste le pragmatisme : si on pose une méthode dès le début sans s'attacher au contexte dans lequel le projet s'inscrit, la démarche pourra être plus ou moins heureuse.

    D'autant que l'effet pervers de beaucoup de méthodes et davantage de garantir la couverture de responsabilité que le résultat.

    Voilà la réalité est aussi que beaucoup d'entreprises qui pensent savoir gérer des projets sont complêtements ignorantes sur les domaines de gestion de la qualité et donc sont peu outillées pour tirer des leçons du passé.

    Beaucoup de projet échouent aussi parce qu'il n'y a pas de management de haut niveau (soit de décision et d'arbitrages) et le projet finit en lettre au pére noël.

    Pour moi, CMMI et consors, ce sont au mieux des caches misére dans la culture projet de la plupart des entreprises.

    On assiste encore aujourd'hui à des projets qui sont bien gérés sur le papier, et un plus tards, on se rend compte que personne n'a travaillé le déploiement.
    Oui voilà des chefs de projets font le travail d'un commercial alors que le but du chef de projet c'est plutôt d'écouter les développeurs et de les manager.

    Si les choses étaient réalisées dans les règles de l'art, un projet informatique serait estimé à sa juste valeur ce qui n'est bien sur pas le cas. Pour le déploiement la solution du moment est de créer des applications avec un client léger. C'est pour ca qu'on voit l'explosion de projets en GWT et consors et qu'on voit des développeurs se plaindre des normes des navigateurs (merci Microsoft pour IE 6 )


    Mais c'est extrêmement facile de planter des étudiants avec des petits pièges sémantiques, des incohérences dissimulées, des comportements trompeurs — ce qui est odieux bien sûr et qui ne se fait pas . C'est comme un bug. Si celui-ci fait exploser ton ordinateur à tous les coups, je suis convaincu que tu le verras et le corrigera. Mais si c'est un bug qui n'apparaît qu'une fois toutes les 100 000 exécutions statistiquement parlant, le verras-tu ? Probablement pas. Même un excellent plan de test pourrait te le faire échouer, et encore faudrait-il que celui-ci puisse le faire apparaitre simplement.
    Sauf que créer des tests performants et costauds ca prend de l'énergie, du temps et de la maintenance...

  6. #146
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par ZeRevo Voir le message
    Oui voilà des chefs de projets font le travail d'un commercial alors que le but du chef de projet c'est plutôt d'écouter les développeurs et de les manager.
    On sent l'image toute faite...

    NON ce n'est pas le seul rôle d'un chef de projet.

    Il doit aussi (entre autres) :
    • assurer le suivi (et la gestion) vis-à-vis de sa hiérarchie supérieure
    • respecter les délais
    • être le garant de la conformité du soft par rapport à ce qui est demandé
    • et pour ce faire être en lien avec les utilisateurs ET le marketing


    Et ce n'est qu'une petite partie...

    Nous te répétons depuis le début qu'un projet informatique n'est rien en tant qu'informatique pure. Il correspond à une demande ou à un besoin, il a déjà ou potentiellement des clients, des utilisateurs.

    L'équipe n'est qu'un moyen pour arriver au but.

    Le but du chef de projet n'est certainement pas d'écouter les développeurs, mais de les diriger...
    "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. #147
    Membre chevronné Avatar de chaplin
    Profil pro
    Inscrit en
    Août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 1 215
    Points : 1 819
    Points
    1 819
    Par défaut
    Le but du chef de projet n'est certainement pas d'écouter les développeurs, mais de les diriger...
    Oui, si le chef de projet maîtrise la technologie.

    Je fairais une nuance, en disant que le chef de projet dirige le projet en insistant sur son rôle de manager.

    Mais bon, les cas idéaux n'existent pas.

  8. #148
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par chaplin Voir le message
    Oui, si le chef de projet maîtrise la technologie.

    Il n'y a pas de "si"..

    C'est son rôle au sein de l'entreprise...


    Et c'est la même chose pour tous les "chefs" : du personnel, des finances, du marketing, de la production, etc etc..
    "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

  9. #149
    Membre confirmé
    Inscrit en
    Janvier 2009
    Messages
    598
    Détails du profil
    Informations forums :
    Inscription : Janvier 2009
    Messages : 598
    Points : 628
    Points
    628
    Par défaut
    Pour moi un chef qui ne prend pas en compte l'avis de ceux qu'il dirige et qui connaissent leur spécialité aussi bien que le chef sinon mieux, est un mauvais chef car il peut passer à coté de certaines choses, et en plus ça met une mauvaise ambiance un chef qui fait juste que dire fais ça fais ci

    NB : Prendre en compte ça ne veut pas dire "suivre à la lettre" mais au moins écouter et décider en conséquence^^
    Cliquez ici et reprenez le pouvoir !
    A bas IE !, Google, et le pistage du net, testons DuckDuckGo.com
    Lords Of The Realm II Download : Lords of the realm 2
    Infos en anglais :Ici

  10. #150
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par dragonno Voir le message
    Pour moi un chef qui ne prend pas en compte l'avis de ceux qu'il dirige et qui connaissent leur spécialité aussi bien que le chef sinon mieux, est un mauvais chef car il peut passer à coté de certaines choses, et en plus ça met une mauvaise ambiance un chef qui fait juste que dire fais ça fais ci

    NB : Prendre en compte ça ne veut pas dire "suivre à la lettre" mais au moins écouter et décider en conséquence^^
    Qu'il soit bon ou mauvais c'est un autre point.

    Mais la phrase sur laquelle je réagissais était :

    le but du chef de projet c'est plutôt d'écouter les développeurs et de les manager.
    et la tienne :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    Oui, si le chef de projet maîtrise la technologie.
    C'est ton point de vue, mais cela n'est pas son rôle ni but.

    Quelle que soit sa manière et sa connaissance, si il est bon il se débrouillera. Si il est mauvais non.

    C'est pareil pour un développeur. Il y en a des bons et des mauvais.

    Mais le rôle du Chef de Projet est de diriger son équipe et d'assurer la livraison de ce qui lui est demandé. Point final.

    La manière avec laquelle il atteint ce but c'est autre chose.

    C'est pareil pour le PDG : si il est mauvais, la boîte finira par couler. Mais son rôle c'est de diriger la boîte.
    "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

  11. #151
    Membre confirmé
    Inscrit en
    Janvier 2009
    Messages
    598
    Détails du profil
    Informations forums :
    Inscription : Janvier 2009
    Messages : 598
    Points : 628
    Points
    628
    Par défaut
    Mais le rôle du Chef de Projet est de diriger son équipe et d'assurer la livraison de ce qui lui est demandé. Point final.
    Oui encore d'accord avec toi
    C'est son rôle principal sinon il ne serait pas embauché
    Cliquez ici et reprenez le pouvoir !
    A bas IE !, Google, et le pistage du net, testons DuckDuckGo.com
    Lords Of The Realm II Download : Lords of the realm 2
    Infos en anglais :Ici

  12. #152
    Membre chevronné Avatar de chaplin
    Profil pro
    Inscrit en
    Août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 1 215
    Points : 1 819
    Points
    1 819
    Par défaut
    Aussi vrai qu'un chef de projet est dirigé par sa direction, mais quand on cumule les eccueuils de l'un et de l'autre, ça n'arrange pas les choses sur le moment. La différence, c'est qu'un salarié au bas de l'échelle est vite remplacé ou éliminé. Pour les hierarchies, ça met un plus de temps mais personne n'est à l'abris sur le long terme.

    On dira que le projet est réussi avec des ralonges budgétaires non prévus initialement. C'est là que l'argent a un rôle énorme dans les chances de réussite d'un projet même pour ceux qui battent de l'aile à priori.

  13. #153
    Membre habitué Avatar de rakakabe
    Développeur informatique
    Inscrit en
    Août 2007
    Messages
    124
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2007
    Messages : 124
    Points : 174
    Points
    174
    Par défaut
    Si j'ai bien suivi, un bon projet c'est :
    - un projet qui satisfait les besoins et attentes du client (pour tout le reste -> a la poubelle ou ce n'est que des methodes et outils destines a aider les informaticiens bossant sur le projet);

    Et le meilleur moyen d'atteindre cet objectif est de bien analyser les besoins du client, si je ne me trompe pas (faut pas m' pour cela).

    Ok, mais on plante souvent a l'analyse des besoins (du moins dans mon cas) : soit, (1) l'informaticien croit comprendre le besoin du client (ce qui m'est arrive une fois, et mon collegue apres), (2) soit le client ne sait meme pas ce qu'il veut (parce qu'il n'a pas de temps pour ces questions stupides qu'inutiles et il te apres).

    dans le (1)er cas, le produit est un "a la poubelle " alors que l'informaticien y a mis tout son talent, ou une "usine a gaz" bourre de fonctions inutiles depassant les budgets, parrait-il ...
    dans le (2)nd cas, a la livraison du produit, le Dieu CLIENT va dire que c'est pas ce qu'il a demande auparavant et qu'il faut mettre un truc ici et la et qu'il faut enlever cette maudite confirmation a chaque fois qu'il veut faire quelque chose (a la maniere d'un certain vista). Le pire c'est que c'est l'informaticien l'incompetent ....

    Il y un truc etonant quand meme, si on fait un truc stupide (je veux dire GUI laid, code pourri ...) dont on n'est pas fier du tout mais qui fonctionne (surtout par peur d'etre traite d'amateur et d'incompetent pas son futur remplacant), le client il s'eclate ....
    Ma question est : comment bien mener l'analyse alors ? (etre dans le commercial tout en etant technicien ou se foutre de la technique (ou de ses collegues clients) et parler business a son Dieu Client).

    C'est un peu exagere mais a vous de voir ...

    PS: j'utilise un clavier qui ne parle pas francais alors desole pour l'accent

  14. #154
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par rakakabe Voir le message
    Si j'ai bien suivi, un bon projet c'est :
    - un projet qui satisfait les besoins et attentes du client (pour tout le reste -> a la poubelle ou ce n'est que des methodes et outils destines a aider les informaticiens bossant sur le projet);
    exact


    Citation Envoyé par rakakabe Voir le message
    Et le meilleur moyen d'atteindre cet objectif est de bien analyser les besoins du client, si je ne me trompe pas (faut pas m' pour cela).
    re-exact


    Citation Envoyé par rakakabe Voir le message
    Il y un truc etonant quand meme, si on fait un truc stupide (je veux dire GUI laid, code pourri ...) dont on n'est pas fier du tout mais qui fonctionne (surtout par peur d'etre traite d'amateur et d'incompetent pas son futur remplacant), le client il s'eclate ....
    c'est ce qu'on dit depuis quelques pages


    Citation Envoyé par rakakabe Voir le message
    ..
    Ok, mais on plante souvent a l'analyse des besoins (du moins dans mon cas) : soit, (1) l'informaticien croit comprendre le besoin du client (ce qui m'est arrive une fois, et mon collegue apres), (2) soit le client ne sait meme pas ce qu'il veut (parce qu'il n'a pas de temps pour ces questions stupides qu'inutiles et il te apres).
    ..
    Ma question est : comment bien mener l'analyse alors ? (etre dans le commercial tout en etant technicien ou se foutre de la technique (ou de ses collegues clients) et parler business a son Dieu Client).
    • Primo, il n'y a pas à utiliser d'ironie et parler de Dieu. Le Client est effectivement roi, au même titre que toi quand tu achètes quelque chose.

      Ton entreprise ne vit que si elle vend, et ton salaire ne tombe que si elle a des sous...

      Et si on te livre une voiture qui a un GPS, une aide au diagnostic en ligne, un WII, etc etc.. , mais dont le levier de vitesse est au milieu du siège arrière et le rétro au niveau de la boîte à gants , tu serais content ?? Non. Donc le Client en informatique est comme le client partout...



    • Secondo, c'est bien pour ça qu'on parle d'ergonomie, qui n'est pas juste l'apparence, mais les tests "d'utilisabilité" et la définition des besoins. En effet, dans la grande majorité des cas, les utilisateurs savent en gros ce qu'ils veulent, mais pas forcément dans le détail (voir ce qui a été dit plus haut : "court-circuits" mentaux dûs à la pratique, l'expérience, les formations, choses qui pour eux sont inimagniables mais seraient facile avec l'informatique et nécessaires dans le boulot, etc etc). C'est tout le rôle justement de la définition des besoins qui doit être faite a) par quelqu'un compétent techniquement, mais sans idées préconçues, b) parlant un langage non technique, et c) capable de s'affranchir totalement du technique et d'écouter/soutirer/presser les utilisateurs pour éclairer toutes les zones d'ombre potentielles.

      C'est pour ça que, dans les premiers messages du thread, il était souhaité une étude exhaustive et profonde des besoins, y compris justement par des "ergonomes", et de préférence la présence d'un utilisateur (compétent et reconnu par ses pairs) en tant que personne ressource tout au long du projet, plus éventuellement les gens du marketing (si ils veulent avoir tel ou tel avantage sur la conccurence)

      En gros en AUCUN CAS l'analyse des besoins ne doit être faite par un informaticien programmeur dans le projet. En tant que règle de conduite c'est ce qu'on devrait suivre. Ce n'est malheureusement pas le cas souvent, mais c'est à vous, développeurs, de pousser/exiger de vos chefs à établir ce type de relations. Ce qui de surcroît élimine la fin de ton paragraphe, car en ayant un interlocuteur priviliégié, l'utilisateur ne discute pas avec toute l'équipe, et par conséquent ne se sent pas perdu parmi des demandes ou des langages techniques.
    "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

  15. #155
    Membre averti Avatar de ZeRevo
    Inscrit en
    Avril 2007
    Messages
    302
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : Avril 2007
    Messages : 302
    Points : 342
    Points
    342
    Par défaut
    NON ce n'est pas le seul rôle d'un chef de projet.

    Il doit aussi (entre autres) :

    * assurer le suivi (et la gestion) vis-à-vis de sa hiérarchie supérieure
    * respecter les délais
    * être le garant de la conformité du soft par rapport à ce qui est demandé
    * et pour ce faire être en lien avec les utilisateurs ET le marketing
    j'ai dit que le job d'un chef de projet ne consiste pas à se mettre du côté du client et à se considérer comme étant en dehors de l'équipe. C'est ce que j'entend lorsque je dis que certains chef de projet font le travail d'un commercial.

    souviron34 une chose que tu oublies c'est qu'en faisant du spécifique, tu rends un seul client heureux, tu lui colles des patchs à la va-vite, tu lui livres son application très vite alors que si tu structurais ton logiciel d'un manière plus "professionnelle" (pas de patch, ...), tu pourrais revendre ton logiciel à plein d'autres clients sans coûts monstueux. Et dans cette affaire le gagnant ca serait ton entreprise.


    Et le meilleur moyen d'atteindre cet objectif est de bien analyser les besoins du client, si je ne me trompe pas (faut pas m' pour cela).
    Des fois on a pas la main sur ce genre de paramètre. On fournit au développeur une analyse bidon et ils doivent se débrouiller avec.

    En gros en AUCUN CAS l'analyse des besoins ne doit être faite par un informaticien programmeur dans le projet. En tant que règle de conduite c'est ce qu'on devrait suivre. Ce n'est malheureusement pas le cas souvent, mais c'est à vous, développeurs, de pousser/exiger de vos chefs à établir ce type de relations. Ce qui de surcroît élimine la fin de ton paragraphe, car en ayant un interlocuteur priviliégié, l'utilisateur ne discute pas avec toute l'équipe, et par conséquent ne se sent pas perdu parmi des demandes ou des langages techniques.
    J'ai déjà demandé sur un projet d'avoir de meilleure spéc. J'ai eu le droit à un sermon, un développeur est là pour faire ce qu'on lui demande pas plus.

    C'est pour ça que, dans les premiers messages du thread, il était souhaité une étude exhaustive et profonde des besoins, y compris justement par des "ergonomes", et de préférence la présence d'un utilisateur (compétent et reconnu par ses pairs) en tant que personne ressource tout au long du projet, plus éventuellement les gens du marketing (si ils veulent avoir tel ou tel avantage sur la conccurence)
    Tout ça c'est beau, mais dans beaucoup de projets on a pas ces possibilités.

  16. #156
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par ZeRevo Voir le message
    souviron34 une chose que tu oublies c'est qu'en faisant du spécifique, tu rends un seul client heureux, tu lui colles des patchs à la va-vite, tu lui livres son application très vite alors que si tu structurais ton logiciel d'un manière plus "professionnelle" (pas de patch, ...), tu pourrais revendre ton logiciel à plein d'autres clients sans coûts monstueux. Et dans cette affaire le gagnant ca serait ton entreprise.
    Qui a dit de faire du spécifique ????

    Ce qu'on dit c'est d'analyser le besoin... Si tu trouves une manière plus générique de le faire tout en respectant les besoins initiaux, tant mieux pour toi.


    Citation Envoyé par ZeRevo Voir le message
    J'ai déjà demandé sur un projet d'avoir de meilleure spéc. J'ai eu le droit à un sermon, un développeur est là pour faire ce qu'on lui demande pas plus.
    D'où l'intérêt d'avoir un interlocuteur privilégié ET côté client ET côté informatique.

    Mais le manque de specs n'est pas à rejeter sur le client, comme tu le faisais plus haut, mais sur ton management et ta boîte..


    Citation Envoyé par ZeRevo Voir le message
    Tout ça c'est beau, mais dans beaucoup de projets on a pas ces possibilités.
    As-tu lu le titre du thread ?

    "Projets informatiques : les bonnes pratiques"...

    Ce sont les conseils pour réussir.

    Pas "Tout le reste n'existe pas".
    "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

  17. #157
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    En gros en AUCUN CAS l'analyse des besoins ne doit être faite par un informaticien programmeur dans le projet. En tant que règle de conduite c'est ce qu'on devrait suivre. Ce n'est malheureusement pas le cas souvent, mais c'est à vous, développeurs, de pousser/exiger de vos chefs à établir ce type de relations. Ce qui de surcroît élimine la fin de ton paragraphe, car en ayant un interlocuteur priviliégié, l'utilisateur ne discute pas avec toute l'équipe, et par conséquent ne se sent pas perdu parmi des demandes ou des langages techniques.
    Oui mais ça c'est une chimére, ou alors sur des métiers simples et des softs simples.
    Un intermédiaire, c'est forcément quelqu'un qui a la capacité de comprendre en détail et de traduire.
    de la technique vers du non technique --> remontée de contrainte de dev
    du métier vers du "non initié" --> remontée de contrainte utilisateur

    Un un mec qui a suffisamment de compêtence dans les deux, il a souvent l'intelligence n'est pas de passer sa vie à jouer le go between entre tout le monde mais bien de vendre sa double expertise.

    C'est aussi aujourd'hui ce que l'on appelle les AMOA, les business analystes, les experts fonctionnels, enfin pleins de noms barbares, mais souvent, c'est pas vraiment le haut du panier qu'on trouve.

    C'est aussi ça les différences entre la beauté des diagrammes et la réalité.

    C'est bien de mettre de l'intermédiation partout, mais souvent quand le client dit B, c'est B'' qui arrive aux oreilles du développeur, qui passe des mois à finir.

    Et c'est dangereux, parce que finalement toute la connaissance repose sur une personne, et la plupart du temps, ca finit en guéguerre de responsabilités partagées.

    Un développeur formé aux métier d'un client, c'est du temps, des ressources et donc du pognon gagné.
    Et quand je parle de ressource c'est primordial, car passé 15 développeurs, il est impossible de développer correctement du métier complexe.

  18. #158
    Membre averti Avatar de ZeRevo
    Inscrit en
    Avril 2007
    Messages
    302
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : Avril 2007
    Messages : 302
    Points : 342
    Points
    342
    Par défaut
    Un développeur formé aux métier d'un client, c'est du temps, des ressources et donc du pognon gagné.
    Et quand je parle de ressource c'est primordial, car passé 15 développeurs, il est impossible de développer correctement du métier complexe.
    Oui mais il peut y avoir l'effet inverse c'est à dire que l'information est dispersée entre les développeurs et le chef de projet perd sa légitimité

  19. #159
    Inactif  
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 58
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par B.AF Voir le message
    Oui mais ça c'est une chimére, ou alors sur des métiers simples et des softs simples.[...]
    Non ce n'est pas une chimère. Je peux te trouver des paquets d'exemple, dans des projets très complexe (Matra, Siemens, Nasa, Hydro Québec... ) qui s'étalent sur des années, où les analystes besoins sont bien distinct des autres informaticiens qui font la suite du développement.

    Ce n'est pas une question d'intelligence de la personne, ni même de compétence. Il y a des problèmes de fond qui mène à vouloir une situation où les deux groupes sont bien distincts.

    Ça peut être des informaticiens, et en fait il faut qu'il y en ait pour que ce soit fait correctement, mais il ne faut pas que ce soit ceux qui travaillent dans les autres équipes.

    Par contre tes deux derniers paragraphes me semblent bizarre... c'est clair qu'on ne parle pas d'une personne mais d'une équipe. Et ceci est particulièrement valide justement pour les équipes où il y a bien plus de 15 personnes. Peut-être ai-je mal compris ?

  20. #160
    Inactif  
    Profil pro
    Inscrit en
    Septembre 2008
    Messages
    357
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2008
    Messages : 357
    Points : 637
    Points
    637
    Par défaut
    Y'en a certain qui devraient ouvrir les yeux et se renseigner sur ce qu'est le monde du travail. L'informatique n'est qu'un job comme un autre. Certes on y prend plus son pied quand on aime ça, mais ça reste un boulot : satisfaction du client, livrer un bon produit, et rien à foutre des ouvriers (nous, même si on nous affuble du qualificatif de "cadre").
    Ca me fait penser à la discussion sur les ingénieurs, évidemment centrée sur l'ingénieur informaticien. Les ingénieurs informaticiens n'ont pas grand chose à voir avec les ingénieurs dans les autres domaines (vous connaissez des ingénieurs en mécanique qui passent eux même sur la fraiseuse ou le tour ? moi pas).

Discussions similaires

  1. [Article]Les bonnes pratiques projet, demande d'aide
    Par elitost dans le forum Contribuez
    Réponses: 2
    Dernier message: 05/02/2008, 15h34
  2. [C#/ASP.Net/DAL] Quelles sont les bonnes pratiques ?
    Par fouhaa dans le forum Accès aux données
    Réponses: 4
    Dernier message: 14/07/2006, 00h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo