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

ALM Discussion :

Des retards dans les délais de livraison d'un projet ? Oui, mais à qui la faute ?


Sujet :

ALM

  1. #21
    Membre actif Avatar de DotCertis
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    janvier 2012
    Messages
    51
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : janvier 2012
    Messages : 51
    Points : 281
    Points
    281
    Par défaut
    En plus des causes évoquées par l'auteur, j'en ajouterais une plutôt propre à la France qui est culturelle et qui n'est pas forcément mauvaise : le choix de la qualité au détriment des délais.
    Chez nous la tendance est souvent à minimiser au maximum les risques identifiés quitte à décaler une MEP par exemple, notre fameux "ceinture + bretelle". Au delà des simples développements, on demande aussi aux dévs d'avoir un regard critique, d'être capable de remonter des alertes et si alerte il y a alors il faut prendre le temps de résoudre cela en amont, ce qui forcément prend du temps.
    Et ça a du sens par rapport aux attentes des clients et des utilisateurs : une appli livrée en retard sera préférable à une appli pas bien finie. Une appli livrée à temps mais buguée dans sa première version sera très rapidement laissée de côté ou définitivement jugée "pourrie" par les utilisateurs.
    Pour avoir bosser avec des Américains ou même des Suédois, la deadline a beaucoup d'importance et assez souvent l'idée est de "tant pis on y va comme prévu, et s'il le faut on blindera post go live" quitte à mettre à plein de ressources après la MEP pour rattraper la situation.
    L'urgent est terminé, l'impossible est en cours, pour les miracles prévoir un délai.

    Pour toute question de méthodologie : http://www.la-rache.com/

  2. #22
    Membre confirmé Avatar de tpericard
    Homme Profil pro
    Ingénieur validation
    Inscrit en
    octobre 2006
    Messages
    119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur validation
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : octobre 2006
    Messages : 119
    Points : 611
    Points
    611
    Par défaut Au risque de me prendre une volée de bois vert ...
    Bonjour,

    En plus de tous les arguments avancés par les uns et autres, pour lesquels j'ai moi même constaté la véracité au cours des projets auxquels j'ai participé, il y a aussi une raison + technique sur le délai repoussé de certains projets : - la composition des équipes de DEV.

    Trop souvent dans les SSII il y a des équipes de dev constituées, pour faire baisser les coûts, d'une majorité de purs débutants (soit débutant tout court, soit débutants sur les technos employées) avec un petit nombre de "sachants" confirmés. Et trop souvent les estimations sont faites en ne tenant pas compte de cet aspect.
    Mais là encore, ce ne sont pas les développeurs qui sont en cause, mais plutôt les financiers qui sont fautifs de tout retard, en n'accordant pas les moyens humains pour un projet !

    Au final le développeur fait en grande majorité tout son possible pour satisfaire la demande des clients, mais il n'est pas un faiseur de miracles pour autant

    Et un dernier point qui m'a un peu hérissé, si le développeur doit comprendre la fonctionnalité qu'il a à implémenter, et est en droit d'exiger cette explication, ce n'est pas à lui, sauf cas simples ou très pointus, à discuter avec le client final. C'est le rôle de la maîtrise d'ouvrage (MOA et AMOA).

  3. #23
    Expert éminent sénior
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2012
    Messages
    2 975
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 2 975
    Points : 15 881
    Points
    15 881
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    "A qui la faute" n'est certainement pas la bonne question à se poser, ça revient à trouver un bouc-émissaire et à ne pas se remettre en question soit-même. C'est tellement plus facile de rejeter sur la faute sur autrui que de reconnaître ses erreurs.
    Entièrement d'accord avec toi. Mais hélas...

    Nom : gdp_grandes_phases1.gif
Affichages : 4003
Taille : 69,3 Ko

  4. #24
    Membre à l'essai
    Homme Profil pro
    Développeur P.O.O. et web
    Inscrit en
    novembre 2008
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Djibouti

    Informations professionnelles :
    Activité : Développeur P.O.O. et web

    Informations forums :
    Inscription : novembre 2008
    Messages : 36
    Points : 20
    Points
    20
    Par défaut Dans un langage plus cru
    Dans un langage plus cru, dans la majorité des projets, le développeur est sous-payé car le projet est lui aussi sous-payé et la concurrence féroce entre les startups ou les majors sur les projets a dépassé la limite de la régulation (sensé protégé le client contre la hausses des prix par cupidité) pour descendre trop bas en mettant le fournisseur à la merci du client!

    A ce moment, l'industrie du logiciel glisse de secteur pour devenir l'éternel perdant de tout écosystème: le producteur primaire!

    Bref, il faudra découper notre secteur en trois, comme d'habitude:
    • Le producteur primaire chargé de fournir des composants indépendants des projets, peut-être open-source peut-être propriétaire, très souvent pour son propre compte puis à partager ou vendre
    • L'intermédiare chargé de la transformation et de l'adaptation de ces composants
    • Le prestataire capable de connaitre les composants existants et les moyens nécessaires à leurs transformations.


    Très peu réfléchissent de cette manière, et j'éviterai les détails supplémentaires pour prouver qu'une mauvaise transmission entre secteur sera catastrophique.

    Je prendrais juste l'exemple d'un projet ou j'étais du côté du client et que j'ai intégré en milieu de parcours, pour découvrir que le prestataire qui d'ailleurs sous-traitait, n'avait pas une bonne connaissance des composants existants, et avait conduit à la ruine toute la chaine.

    Mon avis personnel est que la solution est entre les mains des intermédiares qui doivent s'imposer devant les prestataires et ainsi équilibrer leurs stupides concurrences qui les poussent à raconter les pires aneries qu'ait connu les marchés.
    J'ai essayé de redire une des thèses soutenues par l'article dans d'autres termes, pour renforcer l'argumentation, qui peut-être sera élaboré pour passer de thèse à preuve.

    Bref, il faut réhausser les prix pour cause de charge supplémentaire de transformation et raréfaction!

  5. #25
    Membre régulier
    Inscrit en
    juin 2009
    Messages
    101
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 101
    Points : 118
    Points
    118
    Par défaut
    Vous savez j'ai croisé un français qui bosse au canada, et chez eux ils y a très peu de SSII ou ESN comme il y a chez nous, car les entreprises n'ont pas confiance en eux. En conséquence, les entreprises préfèrent recruter leur informaticien, et de les faire monter en compétences à la fois sur le plan fonctionnel et sur le plan technique. Ainsi les entreprises conserve une indépendance et une autonomie sur le système d'information.

    En france les entreprises ont tendance à vouloir trop externaliser l'activité informatique, ils perdent en autonomie et en indépendance, et quand il y a un projet à réalisé ils sont souvent tributaire de la prestation de service. La multiplication des interlocuteurs génère des réunionites qui pour certaines sont stériles et font perdre du temps.

    En plus une prestation de services coûte cher à l'entreprise (entre 350€ jusqu'à 1000€ par jour et par homme) en prenant compte du coût mini ça revient à 7000€ (sur 20 jours ouvrés) pour un prestataire... Et la personnellement, je n'arrive toujours pas à comprendre. un salarié et bien moins chère qu'un prestataire de service (salarié entre 4000 (et même moins) et 6000€ charges comprises, prestataire entre 7000€ et 20 000€)
    Bon, je sors du sujet du topic ...

    @tpericard : je voulais dire que tu as tout à fait raison, car bien souvent on qualifie souvent un jeune qui sort d'un bac+5 d'expert... Et pour cause, j'ai formé des jeunes diplômés sur le décisionnel, une semaine après, ils sont en clientèle avec l'étiquette d'expert... et on leur dit pour les rassurer : "Rassure toi, tu en sais plus que le client " MDR quand c'est pas le cas, et c'est déjà arrivé

  6. #26
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    521
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 521
    Points : 1 647
    Points
    1 647
    Par défaut
    Citation Envoyé par sidewolf Voir le message
    Vous savez j'ai croisé un français qui bosse au canada, et chez eux ils y a très peu de SSII ou ESN comme il y a chez nous, car les entreprises n'ont pas confiance en eux. En conséquence, les entreprises préfèrent recruter leur informaticien, et de les faire monter en compétences à la fois sur le plan fonctionnel et sur le plan technique. Ainsi les entreprises conserve une indépendance et une autonomie sur le système d'information.

    En france les entreprises ont tendance à vouloir trop externaliser l'activité informatique, ils perdent en autonomie et en indépendance, et quand il y a un projet à réalisé ils sont souvent tributaire de la prestation de service. La multiplication des interlocuteurs génère des réunionites qui pour certaines sont stériles et font perdre du temps.

    En plus une prestation de services coûte cher à l'entreprise (entre 350€ jusqu'à 1000€ par jour et par homme) en prenant compte du coût mini ça revient à 7000€ (sur 20 jours ouvrés) pour un prestataire... Et la personnellement, je n'arrive toujours pas à comprendre. un salarié et bien moins chère qu'un prestataire de service (salarié entre 4000 (et même moins) et 6000€ charges comprises, prestataire entre 7000€ et 20 000€)
    Bon, je sors du sujet du topic ...

    @tpericard : je voulais dire que tu as tout à fait raison, car bien souvent on qualifie souvent un jeune qui sort d'un bac+5 d'expert... Et pour cause, j'ai formé des jeunes diplômés sur le décisionnel, une semaine après, ils sont en clientèle avec l'étiquette d'expert... et on leur dit pour les rassurer : "Rassure toi, tu en sais plus que le client " MDR quand c'est pas le cas, et c'est déjà arrivé

    La différence entre un prestataire et un interne , c'est que le prestataire on peut le virer quand on veut.
    Je pense que c'est une des raisons majeur de l’attrait des SSII pour les entreprises.

  7. #27
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 616
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 616
    Points : 31 104
    Points
    31 104
    Par défaut
    Citation Envoyé par dfiad77pro Voir le message
    La différence entre un prestataire et un interne , c'est que le prestataire on peut le virer quand on veut.
    Je pense que c'est une des raisons majeur de l’attrait des SSII pour les entreprises.
    C'est l'unique, ou presque. Après, on peut avoir besoin de prestataires pour des besoins ponctuels. Mais c'est 10% de l'activité en France.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  8. #28
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 878
    Points
    7 878
    Par défaut
    Citation Envoyé par sidewolf Voir le message
    Vous savez j'ai croisé un français qui bosse au canada, et chez eux ils y a très peu de SSII ou ESN comme il y a chez nous, car les entreprises n'ont pas confiance en eux. En conséquence, les entreprises préfèrent recruter leur informaticien, et de les faire monter en compétences à la fois sur le plan fonctionnel et sur le plan technique. Ainsi les entreprises conserve une indépendance et une autonomie sur le système d'information.

    En france les entreprises ont tendance à vouloir trop externaliser l'activité informatique, ils perdent en autonomie et en indépendance, et quand il y a un projet à réalisé ils sont souvent tributaire de la prestation de service. La multiplication des interlocuteurs génère des réunionites qui pour certaines sont stériles et font perdre du temps.

    En plus une prestation de services coûte cher à l'entreprise (entre 350€ jusqu'à 1000€ par jour et par homme) en prenant compte du coût mini ça revient à 7000€ (sur 20 jours ouvrés) pour un prestataire... Et la personnellement, je n'arrive toujours pas à comprendre. un salarié et bien moins chère qu'un prestataire de service (salarié entre 4000 (et même moins) et 6000€ charges comprises, prestataire entre 7000€ et 20 000€)
    Bon, je sors du sujet du topic ...
    Ce sujet est régulièrement abordé sur le forum
    En France, le SI a très longtemps été perçu uniquement comme une charge modulable.
    Autrement dit, il doit être possible de très rapidement en réduire le coût lorsque l'activité de l'entreprise décroit.
    D'où une externalisation massive des ressources IT afin d'avoir cette modularité.
    De plus, en France, les charges patronales sont élevées et énormément de dispositifs sont calibrés en fonction de la masse salariale (les fameux effets de seuils)
    Externaliser, c'est aussi réduire sa masse salariale...

    Je dis cela au passé car les choses commencent tout doucement à changer.
    Les entreprises commencent à réaliser que leur métier est de plus en plus porté par le SI et que ce SI, n'est pas juste une charge mais aussi un acteur majeure de leur activité.
    De même, grâce au web notamment et au cross canal, le SI est aussi un vecteur d'innovation dans le cœur de métier de l'entreprise ainsi qu'un axe de croissance.
    Bref, la perception du SI par les entreprises françaises est en train de changer et cela a pour conséquence une internalisation des ressources IT.
    Ce phénomène débute seulement et c'est très timide.
    Mais ça vient, petit à petit et c'est amené à s'amplifier avec le temps.

  9. #29
    Membre éprouvé

    Homme Profil pro
    Développeur PHP/Symfony // Mentor OpenClassrooms
    Inscrit en
    octobre 2014
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hautes Alpes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur PHP/Symfony // Mentor OpenClassrooms
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2014
    Messages : 203
    Points : 1 267
    Points
    1 267
    Billets dans le blog
    3
    Par défaut
    Au fond, on touche une partie sensible de l'informatique, peut-on réellement développer un projet en respectant les délais ? Non.

    J'ai récemment été confronté au soucis du projet qui part mal, l'idée de base semble bonne, on soumet l'idée, on propose d'y travailler afin de présenter un truc intéressant puis se dresse une muraille de problème.

    Premièrement, le projet n'est pas défini correctement, on balance une idée dans le vent, sans réelle but si ce n'est poussé le dév (ma personne) a ajouter des bouts de concept par ci par là en précisant que de toute façon, rien n'est pressé.

    Deuxièmement, on commence à t'affecter à des tâches qui n'ont ni queue ni tête et qui bloque le développement du projet, au fond, tu passe plus de temps à faire tout sauf avancer sur le projet.

    Troisièmement, on te bloque l'accès à certaines données/applications de développement, tout simplement parce que les infras ne veulent pas tester tel ou tel produit (SharePoint pour ne citer que lui), on bride volontairement certains projets et je trouve cela honteux ...

    Dernièrement, le projet sombre dans l'oubli et tu continue sur tes tâches sans queue ni tête, peut-être qu'un jour, il refera surface et sera confié à quelqu'un d'autre, sais t-on jamais ?

    Au fond, la faute n'est pas à tel ou tel personne mais plus à un ensemble de circonstances et personnes qui ne veulent pas se donner les moyens d'y arriver sans rejeter la faute sur des tiers.

  10. #30
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 878
    Points
    7 878
    Par défaut
    Citation Envoyé par Guikingone Voir le message
    Au fond, on touche une partie sensible de l'informatique, peut-on réellement développer un projet en respectant les délais ? Non.
    Tout dépend la taille du projet
    Fort heureusement, il y a des tas de projets qui sortent dans les délais
    Regarde un peu toutes les opérations marketing associées à un portail web et/ou à des applications mobiles

    De même, je bosse actuellement sur des applications magasin qui impliquent la mobilisation d'énormément de monde et pas uniquement des ressources IT.
    Ne pas être au rdv, n'est même pas concevable (formation du personnels, pub, logistique, etc)

    Faut pas trop généraliser non plus
    On parle surtout des projets qui vont mal et on ne s'attarde pas assez sur ceux qui vont bien
    Cela donne une vision assez négative de la situation

    Après, je partage ton point de vu sur les situations décrites (notamment au niveau des équipes sécu avec qui j'ai dû batailler plusieurs mois pour ouvrir une connexion VPN avec le SI d'un prestataire...)

  11. #31
    Membre éclairé Avatar de laloune
    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    mai 2005
    Messages
    474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Consultant en Business Intelligence

    Informations forums :
    Inscription : mai 2005
    Messages : 474
    Points : 801
    Points
    801
    Par défaut
    Pour moi, le plus gros soucis est que celui qui réalise n'est pas toujours (voir pas souvent) celui qui va discuter avec la personne qui émet le besoin...
    c'est parfois nécessaire je pense... parfois celui qui réalise n'a ni l'envie ni les compétences pour discuter avec les gens du métier. Le développeur s'en fout plus ou moins de savoir ce qu'est l'actif ou le passif, ou le compte de résultat, pour lui il y a des tables, des colonnes et des lignes (c'est caricatural mais c'est l'idée)

    selon moi ca devrait être le rôle du CP de faire l'interface entre le client et les développeurs : ou pour les projets plus gros, un CP et un CP technique qui travaillent de concert

    après c'est sûr que tout dépend aussi de la taille du projet
    laloune
    Consultant B.I.
    Spécialité(s): Excel, SQL, Business Intelligence (Jedox Palo, Talend)

    "A problem worthy of attack proves its worth by fighting back." Piet Hein

  12. #32
    Membre éprouvé
    Avatar de landry161
    Homme Profil pro
    C#,PHP,MySQL,Android...
    Inscrit en
    juillet 2010
    Messages
    422
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : C#,PHP,MySQL,Android...

    Informations forums :
    Inscription : juillet 2010
    Messages : 422
    Points : 1 058
    Points
    1 058
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Carhiboux Voir le message
    Entièrement d'accord avec toi. Mais hélas...

    Nom : gdp_grandes_phases1.gif
Affichages : 4003
Taille : 69,3 Ko
    Actuellement je bosse sur un projet et bientôt je serai a la quatrième étape. Je meurs de trouille.

  13. #33
    Membre du Club
    Profil pro
    Dirigeant
    Inscrit en
    juin 2005
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Dirigeant

    Informations forums :
    Inscription : juin 2005
    Messages : 13
    Points : 56
    Points
    56
    Par défaut ça commence mal
    Moi j'aurai commencé cet article en disant "Il arrive parfois en entreprise que les délais de livraison d’un projet de développement soient respectés", tant la tenue des délais est un évènement d'une rareté exceptionnelle, attribuable au hasard et non à la logique.

    Nul besoin d'outils d'analyse pour déterminer les causes :
    1) Le responsable métier ne comprend pas pourquoi il faudrait écrire un cahier des charges puisque selon lui il a déjà tout expliqué dans un mail.
    2) Le chef de projet passe plus de temps à expliquer pourquoi il est en retard plutôt qu'à le résorber
    3) Les architectes prennent un plaisir malsain à complexifier l'architecture technique et fonctionnelle
    4) Les développeurs errent dans les bureaux à la recherche des spécifications du projet
    5) La machine à café est tout le temps en panne

    point barre.

  14. #34
    Membre éprouvé

    Homme Profil pro
    Développeur PHP/Symfony // Mentor OpenClassrooms
    Inscrit en
    octobre 2014
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hautes Alpes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur PHP/Symfony // Mentor OpenClassrooms
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2014
    Messages : 203
    Points : 1 267
    Points
    1 267
    Billets dans le blog
    3
    Par défaut
    Je soutient laloune sur sa vulgarisation de la vision d'un tel, on est tous confrontés à ce genre de personne qui ne comprend rien mais qui dirige, avouons-le, 95 % des gens qui commandent ne savent pas diriger ...

  15. #35
    Membre actif
    Homme Profil pro
    Développeur Web
    Inscrit en
    mars 2012
    Messages
    46
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2012
    Messages : 46
    Points : 205
    Points
    205
    Par défaut Tellement vrai tout ça
    Ce que je lis dans les posts précédents est le vécu de tout développeur.

    Je pense que ce qui pèche c'est le fait que tout le monde s'écrase devant le "client roi" au lieu de discuter (or tout client censé est prêt à écouter et comprendre des arguments). Je m'explique : le client a envoyé le cahier des charges de son projet complet, c'est chiffré, validé et les dév ont démarré. Puis le client demande une modification mineure d'un point de vue fonctionnelle mais qui a un gros impact technique, on lui dit d'accord sans autre négociation et sans rien réétudier des spécs techniques ni du chiffrage (ne surtout pas dire au client qu'on va modifier un budget validé)... et pan!, le mur assuré.

    Autre problème que je juge sérieux : les compétences... et oui ! c'est important. J'ai bossé dans des boîtes où les chefs de projet étaient des stagiaires d'écoles de commerce et qui ne connaissaient de l'informatique que leur profil Facebook... Bonjour la cata !

  16. #36
    Membre habitué
    Homme Profil pro
    Retraité MO
    Inscrit en
    mai 2008
    Messages
    75
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 73
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Retraité MO
    Secteur : Finance

    Informations forums :
    Inscription : mai 2008
    Messages : 75
    Points : 136
    Points
    136
    Par défaut
    Selon mon expérience personnelle, je vois trois points principaux à surveiller :

    1 - La maîtrise d'ouvrage :
    Ca a été mon cas durant plusieurs années. Heureusement, j'avais les deux formations. De nombreuses années dans la profession du client, et des expériences personnelles de développements pour des hobbies de loisirs. J'avais donc plus de facilités pour traduire les besoins clients en logique informatique. Il m'est arrivé de faire traîner un client quand je ne parvenais pas à mettre de l'ordre dans mes idées. Mais ensuite, quand j'ai commencé à lancer les développements, c'est rentré comme dans du beurre. Même les évolutions, quand le client a vu ce qu'on pouvait faire et que ça lui a donné des idées, sont passées sans douleurs.
    La maîtrise d'ouvrage n'est pas juste une fonction, elle demande des compétences spécifiques. Et l'analyse ne se borne pas à écrire ce que le client a demandé, mais plutôt ce dont le client a besoin. J'ai vu un cas où il fallait même lui expliquer son métier.

    2 - La documentation :
    Il est bien connu que les docs ont été archivés et que les archives ont été purgées pour gagner de la place de stockage. Donc les seules infos restantes sont dans le code source. Celui-ci doit alors contenir des infos clients, des motifs, des dates, voir parfois des noms, permettant de retrouver pourquoi on a pris telle option, pourquoi tel enregistrement de telle dimension en tel endroit. Dans des systèmes utilisés par plusieurs services voir plusieurs filiales dans le monde, tout modif peut provoquer des catastrophes. J'ai vu des sources contenant bien plus de commentaires que de code réel, mais c'était bien pratique pour intervenir ou évoluer.

    3 - Ecoutez-vous les uns les autres :
    La machine a café est un outil de travail formidable. On y apprend les obsessions et angoisses des autres. On peut avoir des idées à leur transmettre, des questions idiotes à leur poser. Le coup du document qui descend la cascade, du patron à l'employé, de l'employé à l'analyste, de l'analyste au programmeur, ça plantera toujours. Faut pouvoir remonter, s'expliquer. Ne pas jeter systématiquement en disant que l'autre ne comprends rien : à moins qu'il ne soit complètement débile, il y a sûrement une explication, souvent contournable. Et les mots utilisés n'ont pas toujours la même significations pour l'un et pour l'autre. J'ai vu mon informateuse me poser des questions commerciales. Et le pire, c'est qu'il lui est même arrivé d'avoir raison !
    Soyez ouverts, discutez, comprenez, ce n'est pas du temps de perdu.
    Vous n'êtes pas des martyrs, les autres aussi ; c'est le commerce !
    R.BASILE, 1971 : "Il y a mille et un procédés pour accélérer des particules. Le seul véritablement fondamental restant...le carnet de chèques."

  17. #37
    Membre à l'essai
    Homme Profil pro
    Chargé d'affaire
    Inscrit en
    mai 2014
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Chargé d'affaire
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : mai 2014
    Messages : 7
    Points : 22
    Points
    22
    Par défaut Menfin !!!
    J'ai été développeur, chef de projet dans une société de service.
    J'ai été chef de projet dans une grosse boite pour des développements interne
    Je suis chef de projet dans le même boite mais maintenant les développement sont externe...
    J'ai subi des pressions, des demandes de chiffrages des demandes contradictoires de mes clients et de mes chefs de mes clients externes ou internes. J’ai connu d’excellent développeurs, j’en ai connu qui n’étaient pas fait, d’autres pas formés pour ce métier.
    En gros j'ai tout vu.

    Concernant les problèmes de développement que nous rencontrons aujourd'hui, on peut dire que tout est fait pour se planter:
    1- Dans les formations initiales j’ai l’impression que l’accent est mis sur le WEB et qu’on oublie le Temps réel.
    2- Chez les gros donneurs d’ordre, on a tendance à oublier l’expérience car on considère qu’il faut que les gens bougent pour évoluer et que demander à un « vieux » ce qu’il veut peut aboutir à une sorte de sclérose. Du coup le cahier des charges, en devient approximatif et le suivi indispensable est sous-évalué donc mal fait.
    3- Chez les jeunes informaticiens, je ne sais pas si c’est la conséquence des classes, puis des amphis surchargés, mais plus personne ne pose de question. En cas de problème on fait le canard, on contourne et on continue, quitte à tout refaire, comme si « ne pas savoir » était une marque de faiblesse.
    4- Au niveau organisation il me semble que dans les grosses boites d’informatique on en revient à ce que j’ai connu au début de ma carrière : des analystes, des analystes-programmeurs, des programmeurs et des opérateurs de saisie ! On ne les appelle plus ainsi, mais ça revient au même. Le résultat c’est que ceux qui développent, ne connaissent pas le besoin d’origine et ne savent pas comment ce sera utilisé.
    5- Les processus mis en place pour s’assurer que la chaine de développement permettra de fournir le bon produit sont rapidement court-circuités car trop lent.
    6- Enfin la législation sur le travail qui empêche un donneur d’ordre de monter une équipe hétérogène en sous-traitance interne et de la gérer en direct ne permet pas de monter rapidement en capacité sur les gros projets. Comment, en effet, une seule société Informatique pourrait-elle disposer de toutes les compétences nécessaires et disponibles au jour J sur le bon site ?

  18. #38
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    521
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 521
    Points : 1 647
    Points
    1 647
    Par défaut
    Citation Envoyé par dba01 Voir le message
    3 - Ecoutez-vous les uns les autres :
    La machine a café est un outil de travail formidable. On y apprend les obsessions et angoisses des autres. On peut avoir des idées à leur transmettre, des questions idiotes à leur poser. Le coup du document qui descend la cascade, du patron à l'employé, de l'employé à l'analyste, de l'analyste au programmeur, ça plantera toujours. Faut pouvoir remonter, s'expliquer. Ne pas jeter systématiquement en disant que l'autre ne comprends rien : à moins qu'il ne soit complètement débile, il y a sûrement une explication, souvent contournable. Et les mots utilisés n'ont pas toujours la même significations pour l'un et pour l'autre. J'ai vu mon informateuse me poser des questions commerciales. Et le pire, c'est qu'il lui est même arrivé d'avoir raison !
    Soyez ouverts, discutez, comprenez, ce n'est pas du temps de perdu.
    Vous n'êtes pas des martyrs, les autres aussi ; c'est le commerce !
    Tu parles de la machine à café,
    quand tu te retrouve avec une bande de beauf non passionnés qui ne parlent que de Foot

  19. #39
    Membre à l'essai
    Homme Profil pro
    Chargé d'affaire
    Inscrit en
    mai 2014
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Chargé d'affaire
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : mai 2014
    Messages : 7
    Points : 22
    Points
    22
    Par défaut
    Citation Envoyé par dfiad77pro Voir le message
    La différence entre un prestataire et un interne , c'est que le prestataire on peut le virer quand on veut.
    Je pense que c'est une des raisons majeur de l’attrait des SSII pour les entreprises.
    ça c'est une vue de l'esprit ...
    Comme on tegiverse au démarrage, en général on commence à la bourre, et "le virer" signifiant du retard, cela suppose d'argumenter, plus le temps passe plus ça devient difficile...
    De plus pour pouvoir "argumenter", il faut avoir suivi, le problème c'est qu'à force de sous-traiter on n'a justement plus le potentiel nécessaire pour suivre.

  20. #40
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    2 195
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 2 195
    Points : 7 384
    Points
    7 384
    Billets dans le blog
    3
    Par défaut
    Pour une fois, je vais faire court.

    cf. l'ingénierie des exigences.
    http://fr.wikipedia.org/wiki/Exigenc...C3%A9nierie%29
    http://cms.specief.org/conc/index.ph...des-exigences/
    http://www.techniques-ingenieur.fr/f...omplexe-0270/#

    Et pour ceux qui sont plus intéressés par les techniques, regarder du côté de i* (i star), Tropos, Kaos et autres techniques de goal modelling.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

Discussions similaires

  1. Réponses: 24
    Dernier message: 03/11/2013, 13h20
  2. [EasyPHP] problème de visibilité des variable dans les includes
    Par d1g-2-d1g dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 4
    Dernier message: 23/10/2005, 01h55

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