+ Répondre à la discussion Actualité déjà publiée
  1. #141
    Modérateur

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    10 356
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 10 356
    Points : 16 946
    Points
    16 946

    Par défaut

    Citation Envoyé par pseudocode Voir le message
    Faut vraiment avoir du temps/argent à perdre pour développer un soft sans demande du client (ou etude marketing).
    Les cas ou cela peut faire sens sont par exemple dans les activités d'évaluation.

    On sait que dans X mois la boite aura besoin de... et on cherche les moins mauvaises technos qui pourraient être utilisables.

    Il ne fait pas y jeter beaucoup d'argent mais bien construite ce genre de démarche permet (parfois) de mieux formuler ses besoins: définir ce qu'on veut ou pas en se mettant en situation... quitte à tout jeter plus tard.
    C'est souvent préliminaire à un POC (proof of concept).

    Ça craint lorsque les objectifs ne sont pas communiqués aux bonshommes qui grattent: ils y croient, ils font de leur mieux mais les objectifs fluctuent en fonction des retours sans qu'ils sachent vraiment quel rôle ils jouent.

    Ceci dit, pour un projet dont la réalisation prend 6 à 12 mois - moment ou les prestataires d'une SSII réalisent - vous pouvez avoir 1 à 3 fois ce temps passé en phase d'avant-projet...

    Et le nombre de 'projets' qui meurent dans cette étape est monstrueusement supérieur à ceux qui passent en réalisation.
    (et c'est normal)

    -W

    PS: j'insiste mais... tant qu'on ne saura pas mieux délimiter les contours d'un projet informatique, il sera difficile voire illusoire de parler de réussite ou d'échec. Et je reste convaincu que, dans la majorité des cas, ces contours ne peuvent qu'être "flous" car ils sont relégués à n'être que les instruments de dessins qui leurs sont étrangers.

    Derrière, bien caché, il y a peut être matière à débat sur la maturité des technologies et des savoirs faire pour réaliser de façon sûre.
    Et la réponse est non, nous ne savons pas encore... et nous sommes loin d'avoir acquis la maturité atteinte dans d'autres industrie pour que cela change rapidement.

    Note: Un avion s'écrase et toute l'industrie aéronautique profite des découvertes faites pour améliorer la qualité et les procédés de fabrication.
    => existence d'agence gouvernementales qui collectent et transforment les informations pour qu'elles puissent être utilisables.

    Si on doit échanger 200000 simulateurs cardiaques parce que 'bug' dans le soft, on fera cela en catimini histoire de ne pas affoler les foules mais globalement la collectivité en profitera peu.
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  2. #142
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 542
    Détails du profil
    Informations personnelles :
    Âge : 60
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 542
    Points : 17 022
    Points
    17 022
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par wiztricks Voir le message
    PS: j'insiste mais... tant qu'on ne saura pas mieux délimiter les contours d'un projet informatique, il sera difficile voire illusoire de parler de réussite ou d'échec. Et je reste convaincu que, dans la majorité des cas, ces contours ne peuvent qu'être "flous" car ils sont relégués à n'être que les instruments de dessins qui leurs sont étrangers.
    C'est d'ailleurs en gros ce qu'on avait dit dans le thread "Les bonnes pratiques"...


    • Le vrai succès d'un projet est quand les utilisateurs finaux l'utilisent et en sont contents..

    • Le vrai échec est quand ils ne s'en servent pas, ou, si ils y sont obligés, n'arrêtent pas de râler contre...
    "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

  3. #143
    Rédacteur
    Avatar de benwit
    Profil pro
    Inscrit en
    septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 1 676
    Points : 3 673
    Points
    3 673

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    Le vrai échec est quand ils ne s'en servent pas, ou, si ils y sont obligés, n'arrêtent pas de râler contre...
    Quand un développeur râle après un framework et traîne des pieds pour l'utiliser, c'est ?
    A) qu'il est incompétent et devrait suivre une formation à l'utilisation de ce framework.
    B) qu'il est utilisateur de cette boite noire non intuitive et donc que ce framework est un échec ?

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  4. #144
    Membre confirmé
    Avatar de william44290
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    juin 2009
    Messages
    400
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Responsable de service informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 400
    Points : 591
    Points
    591

    Par défaut

    un informaticien n'est pas un utilisateur. (il n'est même pas normal )

  5. #145
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 909
    Points : 3 103
    Points
    3 103

    Par défaut

    Citation Envoyé par pseudocode Voir le message
    ??

    Faut vraiment avoir du temps/argent à perdre pour développer un soft sans demande du client (ou etude marketing).
    ou alors anticiper l'avenir.
    il faut savoir par exemple que certaines entreprise/personnes reflechissent déjà la téléphonie de dans 5/10 ans....

    que certaines technos qui sont "hype" aujourd'hui ont vu les premiers bout de specs les concernants il y'a plus de dix ans.
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  6. #146
    Membre éprouvé
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 705
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 705
    Points : 1 247
    Points
    1 247

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    • Le vrai succès d'un projet est quand les utilisateurs finaux l'utilisent et en sont contents..
    • Le vrai échec est quand ils ne s'en servent pas, ou, si ils y sont obligés, n'arrêtent pas de râler contre...
    Mouais... j'ai un collègue qui dit ça aussi, mais je suis pas d'accord...

    Lorsque le projet est en production et qu'il a évolué, sous pression constante, de la part du producteur comme du client, se faisant sans cesse la guerre des mails parapluies (avec toujours 10 milles copies), c'est un succès juste car il est en prod ?
    Je sais pas, si tu mets 2 ans avec autant de déboire (procédures juridiques, la moitié des employés du constructeur qui se barre, ta femme qu'en peut plus à force de t'entendre ruminer etc...) pour acheter une voiture car la transaction se passe au plus mal, même si le prix est bon, les performances au rendez-vous, pour toi, ce sera une bonne vente ? Un bon coup ?

    Qui plus est, nous sommes chez un éditeur de logiciel, et non une SSII au forfait, ce qui impose comme objectif supplémentaire de pérenniser nos production "à l'extérieur" pour les réintégrer "à l'intérieur", un objectif supplémentaire qui n'est pas rempli si l'on se contente de "faut que le client soit content"...

    A ce compte là, on a perdu 600 000€ et on a aggravé notre réputation sur le marché, tout en augmentant le turn over, mais bon, le client il est content, donc on est des boss, objectif(s) atteint(s).

    Bref, on a tout à y gagner à faire les choses correctement, arrêtons de s'aveugler avec des trucs piochés à droite à gauche pour se convaincre qu'on est bon, que ce qu'on a fait était irréprochable, ça nuit à la remise en question qui, dans l'informatique, et surtout dans les boîtes en difficultés, est un outils indispensable, voire décisif.
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  7. #147
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 542
    Détails du profil
    Informations personnelles :
    Âge : 60
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 542
    Points : 17 022
    Points
    17 022
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par mister3957 Voir le message
    Lorsque le projet est en production et qu'il a évolué, sous pression constante, de la part du producteur comme du client, se faisant sans cesse la guerre des mails parapluies (avec toujours 10 milles copies), c'est un succès juste car il est en prod ?

    ....
    si l'on se contente de "faut que le client soit content"...

    A ce compte là, on a perdu 600 000€ et on a aggravé notre réputation sur le marché, tout en augmentant le turn over, mais bon, le client il est content, donc on est des boss, objectif(s) atteint(s).

    Je n'ai pas parlé de clients


    J'ai parlé d'utilisateurs


    Ne pas confondre....

    J'ai rarement été dans des SSII, une ou 2 fois chez des éditeurs (certains avec clientèle captive (leurs employés ou les employés du client) , d'autres non), et la plupart du temps chez des industriels, et en général dont les machines contiennent et sont basées sur des logiciels pour plus de 50%... (machines d'imageries médicales (IRM, radio, scanners, etc), ou machines d'entraînement de pilotes, de controleurs aériens, etc)

    Et la raison du succès (ou de l'échec) d'entreprises industriellles vendant du matériel avec un logiciel qui est au moins 50% du produit, ou d'éditeurs de logiciels dont la clientèle n'est pas captive (et a une voix), c'est que les utilisateurs soient contents (ou non)..

    Tu peux faire la meilleure machine du monde, si le mec qui la manipule fait des erreurs et peste en permanence contre "ce foutu logiciel", tu ne dépasseras guère le stade de la démo... ou du premier exemplaire vendu...


    Citation Envoyé par mister3957 Voir le message
    Bref, on a tout à y gagner à faire les choses correctement, arrêtons de s'aveugler avec des trucs piochés à droite à gauche pour se convaincre qu'on est bon, que ce qu'on a fait était irréprochable, ça nuit à la remise en question qui, dans l'informatique, et surtout dans les boîtes en difficultés, est un outils indispensable, voire décisif.
    Remise en question que visiblement tu ne sembles pas prêt à faire...

    Je ne sais pas qu'est-ce que tu penses qui "aveugle" ??

    Les méthodologies agiles et l'ergonomie des logiciels sont les pièces centrales pour arriver à la prise en compte de l'utilisateur (bien que certains projets menés avec d'autres choses réussissent aussi).

    Mais au vu de ton âge, je te pardonne je ne sas pas si dans ta boîte vous avez des test d'utlisabilité, des labos et des études d'utilisabilité et d'ergonomie avant de démarrer l'édition d'un logiciel..

    Mais aussi le fait que , que ce soit les dernières technos ou non, tout n'est pas bon à prendre.. Et la remise en question doit se faire dans ce sens-là AUSSI....


    Mais ces démarches sont bien basées sur le fait que le plus important est que l'utilisateur final soit content..

    Le client n'est que le maillon financier..

    Il est nécessaire, mais il n'achétera QUE si les utilisateurs sont contents (ou alors ils sont captifs).
    "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

  8. #148
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 542
    Détails du profil
    Informations personnelles :
    Âge : 60
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 542
    Points : 17 022
    Points
    17 022
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par benwit Voir le message
    Quand un développeur râle après un framework et traîne des pieds pour l'utiliser, c'est ?
    A) qu'il est incompétent et devrait suivre une formation à l'utilisation de ce framework.
    B) qu'il est utilisateur de cette boite noire non intuitive et donc que ce framework est un échec ?
    Je dirais un peu comme l'a dit william44290

    Disons que normalement la conclusion est B, mais qu'il est possible que cela puisse être A

    Car notre métier est d'utiliser ces outils.

    Cependant, quand on fait des logiciels pour d'autres métiers, ce n'est pas nous qui devons dicter la formation métier..

    Je l'ai déjà dit ailleurs, mais pour moi un logiciel correct doit être intuitif et demander zéro formation.


    Dans la pratique, surtout de logiciels complexes avec des retombées critiques (vies en jeu), il est bon d'avoir un minimum de formation.. Mais pour la plupart, de l'ordre d'une 1/2 heure à 1/2 journée devrait suffire... (pour des gens qui n'ont jamais touché ce genre de logiciels, par exemple, mais qui connaissent leur métier)

    Mais de toutes façons , la base est que cela soit intuitif...


    Dans le cas que tu présentes, je dirais que dans 90% des cas, ce sera B....
    "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
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 039
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 039
    Points : 15 615
    Points
    15 615

    Par défaut

    Citation Envoyé par jabbounet Voir le message
    ou alors anticiper l'avenir.
    il faut savoir par exemple que certaines entreprise/personnes reflechissent déjà la téléphonie de dans 5/10 ans....

    que certaines technos qui sont "hype" aujourd'hui ont vu les premiers bout de specs les concernants il y'a plus de dix ans.
    Oui mais là tu as une étude marketing (ou l'équivalent), donc tu as un "client" a qui tu peux demander des choses pendant le développement (confirmations, détails, ... )

    C'est différent de faire un CDCF à l'aveugle, partir en développement et livrer le logiciel a quelqu'un qui n'a rien demandé.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  10. #150
    Membre régulier
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    64
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2008
    Messages : 64
    Points : 78
    Points
    78

    Par défaut

    - Quand vous êtes embauché comme l'architecte principal et qu'après 4 semaines dans le projet vous ne comprenez toujours pas ce qu'ils veulent que vous fassiez. Finalement vous découvrez qu'ils ne savent pas non plus.

    Vécu

  11. #151
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 015
    Points
    2 015

    Par défaut

    La principale cause d'échec est la suivante :
    - L'utilisateur est une b*t* en informatique. Bien qu'il ne puisse rien faire au quotiden sans utiliser l'informatique (d'un virement bancaire à ses mail pros) et qu'il passe son temps à vouloir un plus petit portable et un blackberry, il ne veut surtout pas assumer sa technophilie.
    - La moa est un fourre tout mélangeant les placardisés hargneux avec les jeunes diplomés qui forment les experts fonctionnels. Le hargneux explique que de toutes façons, les utilisateurs sont mauvais et que c'est à cause de ça qu'il fait de la moa. Le jeune diplomé voit le monde en UML et en Java.
    Le patron de l'ensemble est un illusioniste de première qui passe son temps à alimenter un stock de 'spécification fonctionnelles' inutiles, est à rejeter toute responsabilité des retards sytèmatiques.
    - Quelques génies qui à force de se faire ch*** tous les jours à utiliser un SI qui ne fonctionne pas et qui ont développé aux mêmes des applis non documentées, dans des technos toujours obscures, et qu'il préservent jalousement de la MOA. D'ailleurs, ça les fait beaucoup rire de voir la MOA ramer pour comprendre.
    - La moe est une équipe de bons développeurs mais traités comme des être sous intelligents, qui ne comprennent jamais rien, mais assuments les responsabilités de tous les échecs. Ils finissent toujours par faire du reverse engineering chrono des applis des génies après que les specs de la moa soit considérées inutilisables.(mais ça ira ieux après avoir explosé le budget formation)
    - La direction business, elle veut pas entendre parler d'IT sauf pour justifier son incapacité à produire de chiffres. Elle a des besoins, mais en fait, elle compte sur la moa pour comprendre à sa place. Elle préfére toujours acheter un logiciel pour 'bénéficier' des connaissances des autres.Entre 3 poncifs dignes d'un manager américain, elle se dérobe des comités stratégiques (pour pas dire informatique, hein, c'est sale) pour aller jouer au golf.

    Tous les projets sont toujours à la base un échec, qui est celui d'obtenir de la qualité unitaire au niveau du business. C'est à dire que le motif d'échec principal aujourd'hui, c'est d'industrialiser des processus inconnus.

  12. #152
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 542
    Détails du profil
    Informations personnelles :
    Âge : 60
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 542
    Points : 17 022
    Points
    17 022
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par B.AF Voir le message
    La principale cause d'échec est la suivante :
    - L'utilisateur est une b*t* en informatique. Bien qu'il ne puisse rien faire au quotiden sans utiliser l'informatique (d'un virement bancaire à ses mail pros) et qu'il passe son temps à vouloir un plus petit portable et un blackberry, il ne veut surtout pas assumer sa technophilie.
    - La moa est un fourre tout mélangeant les placardisés hargneux avec les jeunes diplomés qui forment les experts fonctionnels. Le hargneux explique que de toutes façons, les utilisateurs sont mauvais et que c'est à cause de ça qu'il fait de la moa. Le jeune diplomé voit le monde en UML et en Java.
    Le patron de l'ensemble est un illusioniste de première qui passe son temps à alimenter un stock de 'spécification fonctionnelles' inutiles, est à rejeter toute responsabilité des retards sytèmatiques.
    - Quelques génies qui à force de se faire ch*** tous les jours à utiliser un SI qui ne fonctionne pas et qui ont développé aux mêmes des applis non documentées, dans des technos toujours obscures, et qu'il préservent jalousement de la MOA. D'ailleurs, ça les fait beaucoup rire de voir la MOA ramer pour comprendre.
    - La moe est une équipe de bons développeurs mais traités comme des être sous intelligents, qui ne comprennent jamais rien, mais assuments les responsabilités de tous les échecs. Ils finissent toujours par faire du reverse engineering chrono des applis des génies après que les specs de la moa soit considérées inutilisables.(mais ça ira ieux après avoir explosé le budget formation)
    - La direction business, elle veut pas entendre parler d'IT sauf pour justifier son incapacité à produire de chiffres. Elle a des besoins, mais en fait, elle compte sur la moa pour comprendre à sa place. Elle préfére toujours acheter un logiciel pour 'bénéficier' des connaissances des autres.Entre 3 poncifs dignes d'un manager américain, elle se dérobe des comités stratégiques (pour pas dire informatique, hein, c'est sale) pour aller jouer au golf.




    Excellent

    à garder sous le coude...

    Et tellement vrai...





    Citation Envoyé par B.AF Voir le message
    Tous les projets sont toujours à la base un échec, qui est celui d'obtenir de la qualité unitaire au niveau du business. C'est à dire que le motif d'échec principal aujourd'hui, c'est d'industrialiser des processus inconnus.


    je rajouterais "avec des techniques dont on n'a pas la moindre idée de savoir si c'est utile"...
    "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

  13. #153
    Nouveau Candidat au Club
    Profil pro
    Inscrit en
    juillet 2008
    Messages
    1
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2008
    Messages : 1
    Points : 1
    Points
    1

    Par défaut


    c est vécu par tout le monde, c est certaint, mais l'essentiel c est d'essayer de nettoyer un peut ce bordel quand on a les moyens.

  14. #154
    Membre habitué
    Profil pro
    Inscrit en
    juin 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 112
    Points : 183
    Points
    183

    Par défaut

    Citation Envoyé par B.AF Voir le message
    Le jeune diplomé voit le monde en UML et en Java.

    Tellement vrai.... tu as travaillé avec moi y'a 2-3 ans ? .

    J'ajouterais:
    Quand le patron vient voir le développement tout les jours et demande d'ajouter une fonctionnalité mineure qui change radicalement le prog (mon projet actuel )

    Quand ton stagiaire te dit que dans sa fac,école d'ing etcetc on fais comme ça et pas autrement et que ça marche pas : le programme est planté et aucune copie de sauvegarde à était faite pas ce génie qui ne se souvient pas de ce qu'il a changé
    Et que çà fais au moins 10 fois qu'il te fais çà
    (Vécu hier )
    YuKoN_42
    Ni dieu, ni chronomètre.
    Joe-bar Team

  15. #155
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 909
    Points : 3 103
    Points
    3 103

    Par défaut

    Citation Envoyé par yukon_42 Voir le message
    Quand ton stagiaire te dit que dans sa fac,école d'ing etcetc on fais comme ça et pas autrement et que ça marche pas : le programme est planté et aucune copie de sauvegarde à était faite pas ce génie qui ne se souvient pas de ce qu'il a changé
    Et que çà fais au moins 10 fois qu'il te fais çà
    (Vécu hier )
    normalement il y'a une gestion de conf, si c'est bien utilisé ça évite les problèmes.

    si y'en a pas tu es quasiment certain de te planter.
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  16. #156
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 039
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 039
    Points : 15 615
    Points
    15 615

    Par défaut

    Citation Envoyé par B.AF Voir le message
    Le patron de l'ensemble est un illusionniste de première qui passe son temps à alimenter un stock de 'spécifications fonctionnelles' inutiles, et à rejeter toute responsabilité des retards systématiques.
    Tiens, moi c'est l'opposé. Le demandeur ne donne spécification fonctionnelle et repousse la date de sortie du produit.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  17. #157
    Membre habitué
    Profil pro
    Inscrit en
    juin 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 112
    Points : 183
    Points
    183

    Par défaut

    Citation Envoyé par jabbounet Voir le message
    normalement il y'a une gestion de conf, si c'est bien utilisé ça évite les problèmes.

    si y'en a pas tu es quasiment certain de te planter.
    Si si y'en a une... le problème c'est qu'il ne l'utilise pas ( son ecole d'ing lui as pas appris )

    Et quand le stagiaire est le fils du patron, bah tu peux rien dire
    Ça aussi c'est un signe d'échec
    YuKoN_42
    Ni dieu, ni chronomètre.
    Joe-bar Team

  18. #158
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 015
    Points
    2 015

    Par défaut

    Citation Envoyé par pseudocode Voir le message
    Tiens, moi c'est l'opposé. Le demandeur ne donne spécification fonctionnelle et repousse la date de sortie du produit.
    C'est kif kif. Soit les mauvais ou les ingérables invirables finissent invariablement MOA. Juste là à la place d'être auvais à la MOA, il est toujours au business.

    C'est qu'une question de temps !!!

  19. #159
    Membre habitué
    Profil pro
    Inscrit en
    mai 2009
    Messages
    101
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : mai 2009
    Messages : 101
    Points : 126
    Points
    126

    Par défaut

    Anecdote vécu :

    Petite PME qui gère un SI au niveau régional (nous l'appellerons GR), cette institution n'a pas été centralisée à la capitale.
    Le client lui est le groupe National (nous l'appellerons GN) qui souhaiterais intégré dans son SI un outil de gestion développé dans ce centre regional.
    Premier obstacle le national peine à définir un cahier de charges global qui satisferait toutes les parties, mais soit un CdC est quand même pondu.
    Second obstacle qui dit centralisation dit bcp de points de vues. Du coup sur le projet il y a une vingtaine d'interlocuteurs qui pour une simple réunion technique d'une demi-journée nous arrivons à 11 jours hommes/réunion (en comptant les 2 interlocuteurs coté MOE) le budget fond à vu d'œil alors que rien n'est encore fixé. Mais soit un premier cadre de dev est pondu et une première maquette est réalisée, les délais de livraison sont fixés ...
    Troisième obstacle, le GN se découvre des besoins, untel veut ci untel veut ça pour finalement ne plus le vouloir quelques semaines après ...
    Résultat l'analyse commence à partir d'un CdC qui change à chaque réunion, la MOE essaie de fixer des interlocuteurs mais ce sont les grandes gueules qui se proposent ...
    L'analyse n'est pas encore fini, le CdC change encore mais les délais étant courts le dev commence ... manque de temps manque de personnel la MOE a besoin de main d'œuvre pas cher, ils prennent le pari de prendre un stagiaire pour palier a leurs besoin en esperant qu'il soit pas trop mauvais ... le budget lui fond comme neige au soleil à chaque réunion de la MOA.
    Il reste un mois avant la fin du projet, la phase de recette devrait être en cours mais seulement 50% du dev est fait ... cause ? pleine période de vacances les devs techniques sont partis .. reste le stagiaire et un ou 2 prestataire. Les SFD elles bougent encore, même les SFD IHM ne sont pas encore fixée.

    Viens alors la date du rendu, le dev n'est pas encore fini, les tests passé sur le code révèle de grosses anomalies fonctionnelles. La MOA qui n'est toujours pas fixé sur ses besoins exigent des têtes. Les chefs de projet ont fait ce qu'ils ont pu avec le budget qu'il avait. L'enveloppe attribué a la MOA pour ce projet est partit a 70% en réunion pour finalement ne rien donné. Le stagiaire s'en va sucé jusqu'a la moëlle en ne souhaitant plus jamais bossé dans l'informatique. Les chefs de projet/equipe en ont eu mort, l'un à demandé sa mutation, un autre a démissionné pendant le projet et enfin le dernier cadre qui a tout pris dans la tronche à la fin lui est partit en dépression.
    Au final, le client national songe à incorporer directement ce dernier centre régional pour faire sa tambouille en interne, l'équipe de dev est détruites et la MOE dégouté. De son côté la MOA s'en est mis plein les poches pour finalement ne rien donné de concret et en reportant la faute sur la MOE qui est incapable de comprendre ses besoins (ce qui est vrai cela dit tellement ils ne savent pas eux non plus ce qu'ils veulent).

    et c'est comme ça depuis 2 ans dans ce centre informatique, perso je songe à donner ma démission avant qu'un projet comme ça me tombe dessus ...

  20. #160
    Membre habitué
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    223
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 223
    Points : 196
    Points
    196

    Par défaut

    Je croyais que jetais le seul dév. à subir ce genre de chose.
    A vous lire, je crois que finalement, c'est pour tout le monde pareil. Ça me rassure un peu dans le fond ...
    Quand c'est trop, c'est pas bon !

Discussions similaires

  1. Un URL qui ressemble a un GET alors que c'est un POST
    Par neoncyber dans le forum Formulaires
    Réponses: 2
    Dernier message: 27/05/2007, 19h20
  2. Réponses: 5
    Dernier message: 14/04/2007, 19h47
  3. Réponses: 10
    Dernier message: 21/03/2007, 19h11
  4. Réponses: 4
    Dernier message: 17/10/2006, 09h46

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