En poursuivant votre navigation sur ce site, vous acceptez nos CGU et l'utilisation de cookies afin de réaliser des statistiques d'audiences et vous proposer une navigation optimale, la possibilité de partager des contenus sur des réseaux sociaux ainsi que des services et offres adaptés à vos centres d'intérêts.
Pour en savoir plus et paramétrer les cookies...

De l'audace et de la méthode

De l'audace et de la méthode
 

Le seul truc vraiment excitant dans nos métiers, c'est le projet. Mais a-t-on vraiment la bonne méthode ?

Newsletter Actualités

A voir aussi

Votre opinion

Postez un commentaire

7 opinions
  • S. Vida
    S. Vida     

    Si quelqu'un a trouvé la solution pour spécifier un objet futur qui doit être en adéquation avec un environnement qui n'existe pas encore : je suis moi aussi très curieux. En attendant je vais quand même continuer à rédiger mon cahier des charges. Plus sérieusement, je pense que le problème ne se situe pas au niveau de la gestion de projet. Comme le suggère l'article, le problème est le manque de vision globale de l'environnement dans lequel s'insert un projet. Pour cela, il suffit d'y penser ! Par contre, là où le problème demeure = la stratégie de l'entreprise est-elle suffisamment bien définie et a-t-elle tenue compte des influences futures du projet? Si oui, alors pas de pb ! Il restera je vous l'accorde une part d'inceritude et de risque. Je pense qu'il est inévatable que le cahier des charges oriente la réponse formelle et matérielle aux objectifs du projet de manière imparfaite. La boulle de cristale n'existera jamais !! Et puis, par pitié, n'enlever pas la part de risque dans la rédaction de cahier des charges : où serait alors le challenge qui nous fait tous avancer ?

  • Traroth
    Traroth     

    La spécification detaillée préalable à un projet RAD ressemble fort à un cahier des charges sur lequel on revient periodiquement. Mais encore une fois, il est indispensable de definir un minimum ce qu'on veut faire si on ne veut pas se retrouver en train de realiser un projet qui fait AUSSI le café...

  • Matthieu_
    Matthieu_     

    Des phases de developpement de 6 mois au bout desquelles on fait le point. Les changements d'avis des utilisateurs peuvent etre pris en compte, et quelque chose est livre tous les 6 mois. C'est sur que ca marche mieux pour un project informatique que pour un hopital, mais ca marche.

  • Traroth
    Traroth     

    LE probleme de l'article, c'et qu'on a l'impression qu'il existe une alternative à ce principe de cahier des charges. Mais on peut appeller ça comme on veut, il y a bien un moment où il va falloir definir ce que le projet doit faire, et ce, AVANT la réalisation. Sinon, l'echec est tout simplement programmé. Ce qui ne veut pas dire qu'on ne peut pas revenir dessus, entre partenaires honnetes, comme quelqu'un l'a dit dans un autre commentaire. Mais croire qu'on peut commencer un projet sans etude préalable, en rentrant directement dans la réalisation, est ridicule, et ce principe n'a rien de purement "hexagonal".
    L'objectif est justement de permettre un meilleur ROI en definissant precisemment les choses, en particulier le perimetre du projet. De nombreux clients croient en effet qu'on rase gratis : un projet avec un perimetre mal defini, c'est la garantie que le client va en rajouter, et que les couts/delais du projet ne seront pas respectés.
    Plutot que des critiques gratuites ce principe, j'aimerais mieux entendre des alternatives. J'avoue etre très curieux...

  • loubeyre
    loubeyre     

    Le problème n'est pas tant les modifications du cahier des charges. En effet iterations, prototypage, formalisations des choix, avenants et esprit de collaboration permettent aux partenaires honnetes de suivre des "inflexions" du cahier des charges.
    Le plus grave problème -évoqué dans l'article- est la non adéquation du cahier des charges par rapport à une problématique globale d'entreprise. Quoi de plus navrant qu'un projet informatique réussi, mais qui ne donne pas le retour sur investissement escompté.
    Problème d'organisation, de maitrise d'ouvrage? Oui peut-être... Mais parfois aussi problème de compétence voire de méthode : qualité des préétudes?

  • HereItIs
    HereItIs     

    Ce qu'essayait d'exposer le journaliste de cet article (en tout cas je pense), c'est que justement, l'idéal n'existe pas.

    Le cahier des charges parfait n'est qu'une utopie.
    Le client qui ne change pas d'avis en cours de développement n'est qu'un leurre.
    Le développeur qui n'est pas confronté à un problème de dernière minute est un mirage.

    La vision "à priori" tel que définit par la méthodologie française est veritablement un problème.

    Dans les faits, je ne l'ai jamais vu être applicable.

    A moi d'être Gérard Majax, tout processus de développement, voir tout processus tout court, doit prendre en compte sa propre "fluidité". C'est ce concept que tentait de soumettre, je pense, Mr le journaliste.

    Evidement, ca choque beaucoup dans l'hexagone...

    Encore une exception culturelle je suppose...

  • Traroth
    Traroth     

    Le chaier des charges n'est pas un element obtenu au debut d'un projet. Il est issu d'un processus d'analyse, et sa redaction est une des etapes majeures d'un projet. Definir de quoi a besoin le client afin de pouvoir le realiser est une evidence ! Quant aux changements eventuels à apporter au cahier des charges, ils sont habituellement la preuve qu'une erreur a été commise et que le besoin a mal été analysé, et non que le besoin a changé (il y a evidemment des exceptions). Que pourrait-on penser d'un projet durant lequel le besoin du client evoluerait constamment, ce qui conduirait fatalement à un depassement des couts et des delais ? Ca serait tout simplement un fiasco !

Votre réponse
Postez un commentaire