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. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 386
    Points : 196 504
    Points
    196 504
    Par défaut Des retards dans les délais de livraison d'un projet ? Oui, mais à qui la faute ?
    Des retards dans les délais de livraison d'un projet ? Oui, mais à qui la faute ?
    Une étude en recherche la cause

    Il arrive parfois en entreprise que les délais de livraison d’un projet de développement ne soient pas respectés. Lorsqu’il faut en trouver la cause, il est parfois plus facile de désigner du doigt l’apparente lenteur des développeurs. Mais est-ce que ces « développeurs lents » sont vraiment la raison pour laquelle le projet a pris du retard ?

    Sprintly, spécialiste de la gestion produit, voudrait y répondre à la lumière de la quantité de données sur le temps de chaque cycle de développement qu’il a récoltées via son application phare. Il fait le suivi du temps qu’il faut pour achever différentes tâches (tests, bugs, …) ainsi que de différentes tailles de projets (S, M, L, XL). Alors qu’elles sont ses observations ?

    Tout d’abord, les billets de données montrent que les développeurs qui se servent du système utilisent relativement le même temps dans le cycle : 75% des 147 494 éléments qui ont été à la fois acceptés et validés ont été commencé et achevé en 175 heures en moyenne.

    Ensuite, il remarque que la plupart des variabilités sont observées avant que le billet n’ait commencé : c’est à ce stade que les intervenants essaient de trouver des spécifications et établissent une priorisation du travail. Dans le modèle de Kanban, cette période correspond au temps de réaction (la quantité de temps qui s’écoule entre la création du billet et le moment où il devient une priorité). Pour rappel, Kanban est une méthode de gestion des connaissances relatives au travail, qui met l’accent sur une fourniture ponctuelle de l’information aux membres de l’équipe de sorte à ne pas les accabler. Dans cette approche, le processus – dès la détermination des tâches, jusqu’à la livraison au client – est affiché pour que les participants puissent le voir, et que les membres de l’équipe puissent tirer du travail de la file. Sprintly remarque que beaucoup de temps est perdu à cette étape.


    Ensuite il apparaît que les équipes ont du mal à faire la transition entre les étapes « fait » et « testé et prêt à être déployé » comme le suggère le graphique plus haut au niveau du temps passé sur « Completed to Accepted ». Alors si vous avez l’impression que le travail de votre équipe n’est pas assez rapide, il est fort probable que vos développeurs ne sont pas à blâmer. Mais alors qu’elle pourrait en être la cause ? Un petit indice : votre processus.

    Bien écrire les spécifications est important, car comment un développeur pourrait-il commencer à travailler sur une fonctionnalité s’il ne la comprend pas au départ ? A ce propos, sur StackExchange, l’utilisateur eagerMoose partageait son expérience en disant « la plupart du temps, il s’avère que ceux qui ont écrit les spécifications n’ont pas pensé à la chose en profondeur et c’est souvent quand nous commençons le design et le développement que commencent les ennuis puisque de nombreuses spécifications semblent avoir des lacunes ». Il n’est pas rare de voir que les intervenants ne se sont pas vraiment penchés sur la fonctionnalité eux-mêmes. Un développeur doit comprendre POURQUOI un utilisateur a besoin de cette fonctionnalité, ce qu’elle est censée faire, mais également comment elle sera employée. D’ailleurs, Sprintly a utilisé cette philosophie lorsqu’il a proposé son outil de gestion de projets. En utilisant le formulaire ci-dessous qui répond au ‘pourquoi’ et ‘comment’, Sprintly pense qu’une direction spécifique sera maintenue pour une fonctionnalité spécifique.


    La seconde plainte qui revient le plus parmi les développeurs est le fait que les décideurs changent souvent les spécifications une fois que le travail a commencé. Sprintly y voit un symptôme d’une mauvaise planification des fonctionnalités avant de leur insertion dans la roadmap. Pour éviter cette situation, Sprintly propose d’utiliser des maquettes interactives avant que le développement à proprement parler ne débute.

    Pour Sprintly, le changement de contexte peut également expliquer les retards pris dans vos projets. Il identifie deux formes :

    • le développeur a réalisé 50% de la tâche A quand vous vous rendez à son bureau pour lui demander de changer de tâche et faire plutôt la tâche B
    • le développeur a réalisé 50% de la tâche A quand vous lui demandez de faire AUSSI la tâche B



    « Le problème vient du fait qu’en tant que manager, vous assignez à vos développeurs de nouvelles tâches alors qu’ils sont en plein milieu d’une autre. Si vos priorités sont toujours en train de changer, cela entraînera de gros coûts pour votre équipe » explique Sprintly.

    D’ailleurs Joel Spolsky, un programmeur et écrivain américain auteur de Joel on Software, en parlait dans son blog : « la vraie leçon qu’on peut en tirer est que vous ne devriez jamais laisser les gens travailler sur plus d'une chose à la fois. Assurez-vous qu'ils savent de quoi il s’agit. Les bons managers voient leur responsabilité dans le fait de supprimer les obstacles afin que les gens puissent se concentrer sur une chose et vraiment le faire. En cas d'urgence, pensez à voir si vous pouvez gérer vous-même avant de déléguer à un programmeur qui est profondément immergé dans un projet ».

    Sprintly conclut en s’adressant aux managers et leur rappelant que c’est leur devoir de fournir aux développeurs un environnement dans lequel ils peuvent mener à bien leurs tâches. Aussi, avant de diriger vers eux leur doigt accusateur, il leur recommande une petite introspection. Voici quelques astuces qu’il leur fournit pour qu’ils puissent s’assurer de ne pas être le poids mort de leur équipe :

    • aidez votre équipe à comprendre la vision : travaillez de concert avec votre équipe afin de définir une vision commune de la façon dont vous allez rendre meilleure la vie des utilisateurs. Soyez clair sur les résultats dont vos utilisateurs ont besoin. Il est important d'avoir un développeur motivé ; sa passion pour une fonctionnalité peut devenir un moteur important de vitesse.
    • les développeurs doivent avoir la capacité de refuser une tâche en attendant qu’elle soit mieux fournie en détail
    • réduisez les coûts relatifs aux changements : n’interrompez pas vos développeurs ! Avant de leur envoyer un courriel ou faire une requête, évaluez-en le coût sur la productivité



    Source : blog sprint.ly, Joel on software, stack exchange

    Et vous ?

    Vous retrouvez-vous dans ces statistiques ? Partagez-vous ce point de vue ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    En attente de confirmation mail
    Femme Profil pro
    pape n'aimant pas les censeurs
    Inscrit en
    Janvier 2010
    Messages
    803
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Vatican

    Informations professionnelles :
    Activité : pape n'aimant pas les censeurs

    Informations forums :
    Inscription : Janvier 2010
    Messages : 803
    Points : 1 407
    Points
    1 407
    Par défaut
    Qui est responsable des retards de livraison d'un projet?

    La réponse est simple: Le ou les éléments faibles du dispositif!!!

    Et bien souvent le coupable ne se trouve pas parmi ceux qui réalisent le projet mais parmi ceux qui en définissent les contours: Combien de fois les techniciens sont confrontés à un client final qui modifie le cahier des charges aussi souvent qu'il respire en cours de réalisation?

  3. #3
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 875
    Points : 86 930
    Points
    86 930
    Billets dans le blog
    2
    Par défaut
    Cet article reflète bien la réalité quotidienne de tous les développeurs.
    Malheureusement, les managers et les utilisateurs ne savent pas qu'un élément supplémentaire
    dans le cahier de charges, alors que le développement est déjà en cours, peut tout chambouler.

    Très souvent, ils vous disent :"je veux telle application". Ne les croyez pas! C'est un piège!
    Demandez leur pourquoi il leur faut une telle application et vous verrez que ce n'est pas ce dont
    ils ont besoin. En général, tout ce qu'ils savent, c'est qu'ils ont un problème, mais la solution
    à ce problème, c'est le développeur qu'il a.

    Je me suis déjà fait prendre par ce genre de piège, un client qui me dit, voilà je veux une telle
    application développée à partir de tel logiciel. Je me jette dans le développement et en cours de route,je me rends compte que ce n'était pas le logiciel adéquat pour développer l'application.

    Pour n'avoir travaillé que sur de petits projets, je crois que pour éviter les retards, le développeur doit
    aussi jouer le rôle d' AMOA, ça lui évitera de revenir aux spécifications au cours du développement du projet.

    Il faut surtout éviter la surqualité, il faut s'en tenir strictement au cahier de charges. Et si l'esprit créatif du client l'emmène à demander de nouvelles fonctionnalités, il faut lui proposer un lot 2, dans lequel vous allez ajouter cette fonctionnalité.
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  4. #4
    Expert confirmé

    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Septembre 2006
    Messages
    3 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Septembre 2006
    Messages : 3 580
    Points : 5 195
    Points
    5 195
    Par défaut
    J'en discutais avec un ami justement mercredi soir...

    Les cahiers des charges trop précis, les spécifications écrites par des non développeurs trop précises, c'est un enfer.. car au final, si on produit exactement
    ce qui s'y trouve, on risque de ne pas satisfaire le client...

    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...

    Si le réalisateur parlait directement avec le demandeur, on aurait surement une meilleure adéquation du logiciel au besoin et par là même, on gagnerait surement
    du temps, de l'argent et de l'éfficacité... mais pour celà, il faut faire confiance aux développeurs et supprimés pas mal de poste intermédiaires
    The Monz, Toulouse
    Expertise dans la logistique et le développement pour
    plateforme .Net (Windows, Windows CE, Android)

  5. #5
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    Il faut également se confronter aux réalités du métier et accepter le fait que tout ne soit pas maitrisable.
    Je constate dans mon quotidien de nombreux cas de figures qui rendent difficile le respect de délais :
    - Deadline qui se pose selon les désirs du client sans prendre en compte les réalités du projet. Si le projet ne peux pas avancer parce que le client ne fournit pas des éléments ou le feedback en temps et en heure, la deadline ne bouge pas pour autant.
    - La réalisation de projet utilisant une technologie peu ou mal connue. L'important est de remplir le carnet de commande, les développeurs trouveront bien le temps de se former sur leur temps libre.
    - Le carnet de commande qui d'ailleurs doit être trop rempli plutôt qu'un peu trop peu. Les développeurs n'auront qu'à faire quelques heures supplémentaires gratuites, ils devraient déjà être contents d'avoir du boulot.
    - Le quotidien ne s'arrête pas sous prétexte que l'on travaille selon un timing très serré. Il faut bien faire avec les demandes urgentes qui arrivent plusieurs fois par jour, s'occuper du support technique. Chaque client part du principe que l'on donne 100% des ressources sur son projet.

  6. #6
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    "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 soi-même. C'est tellement plus facile de rejeter sur la faute sur autrui que de reconnaître ses erreurs.
    One Web to rule them all

  7. #7
    Expert confirmé Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2007
    Messages
    1 168
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 168
    Points : 4 654
    Points
    4 654
    Par défaut
    Citation Envoyé par theMonz31 Voir le message
    J'en discutais avec un ami justement mercredi soir...

    Les cahiers des charges trop précis, les spécifications écrites par des non développeurs trop précises, c'est un enfer.. car au final, si on produit exactement
    ce qui s'y trouve, on risque de ne pas satisfaire le client...

    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...

    Si le réalisateur parlait directement avec le demandeur, on aurait surement une meilleure adéquation du logiciel au besoin et par là même, on gagnerait surement
    du temps, de l'argent et de l'éfficacité... mais pour celà, il faut faire confiance aux développeurs et supprimés pas mal de poste intermédiaires
    J'ai l'impression de voir plus souvent l'inverse : des spécifications pas précises du tout... tellement vague que ça peut-être complètement sujet à interprétation. Puis quand j'ai presque fini qu'on vienne me dire qu'un truc ne correspond pas à ce qui est écrit dans un autre document que je n'avais jamais vu, que le calcul n'est pas celui attendu ou diverses autres raisons qui dépasse mes compétences. Ça devient à faire de la conception, de l'analyse et de la chasse au trésor, mais encore faut-il en avoir le temps. Surtout quand il y a des personnes qui sont normalement là pour faire ça dans la boîte. Et j'ai vécu ce genre de choses dans presque toutes les boîtes dans lesquels je suis passé.

    Il y a souvent un manque terrifiant d'organisations. Les priorités qui changent tout le temps. Je commence à bosser sur un truc, on me passe sur un autre en cours de route parce qu'on truc oublié est devenu plus important. Le pire, ça reste d'avoir à générer plusieurs projets exactement en même temps, le meilleur moyen de faire des erreurs. Impossible de vraiment se concentrer sur un seul projet. Puis le pire, c'est que dans le dév, la partie test est souvent complètement oubliée. Faire des tests unitaires, j’aimerai en faire, mais j'ai trop souvent à peine le temps de faire le reste.

    J'ai aussi eu le cas du client qui vers la livraison finale du projet se rend compte qu'un élément ne va pas dans la cinématique, alors qu'il a eu au moins 15 livraisons pour s'en rendre compte avant. Comme il y avait un deadline impossible à revoir, à moins de tout revoir, pour une fois le manager a été obligé de dire au client que ça n'aller pas être possible. Oui, parce que si nous voulions faire ce que le client voulait, les dévs pouvaient oublier leurs soirées et leurs week-ends pendant plusieurs semaines. Et à titre perso, je n'aurais pas accepté. Déjà que la boîte ne payait pas les heures sup. (D'ailleurs, ça existe des boîtes d'infos qui les paies ?)

    Pour moi, le pire problème reste la mauvaise évolution de la difficulté d'une tâche. Souvent parce qu'il y a des imprévus non maîtrisables (à moins d'être soi-même l'auteur du framework sur lequel on bosse). On pense qu'une chose peut-être réalisée dans la journée... puis on y est encore une semaine après parce qu'on s'e rend compte que le framework ne permettait pas de le faire et qu'il faut trouver des solutions de contournement qui demande une connaissance du fonctionnement du cœur du framework. Un pote m'avait parlait d'un projet où pour rajouter un pauvre bouton pour une action relativement simple, ils y ont passé à plusieurs plus d'un mois. Framework ultra mal documenté, support lamentable (payé une fortune par la boîte), une quantité de code énorme à essayer de comprendre. Le truc avait chiffré à 3 jours, il me semble.

    Les erreurs, il y en a tous les niveaux. Mais on oublie souvent que l'informatique c'est pas juste pisser du code sans réfléchir, parce que si ça devient juste ça, je préfère changer de job.

  8. #8
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2011
    Messages
    498
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2011
    Messages : 498
    Points : 1 148
    Points
    1 148
    Par défaut
    La encore j'ai l'impression vous parlez tous de projets récents et fait a partir de zéro.
    Mais dans la réalité on reçoit aussi des projets réalisés par d'autres (autre entreprise, autre personnes partis entre temps, ...) sans documentation. Et que tu dois continuer un truc qui a la moitie de ton age.

    Comme le client était habitue a avoir un certain délai pour ces développements, alors il met les même délais au bout de 10 ans.
    Alors que le projet n'est plus maintenable du tout, ...

    Toi en tant que développeur, ton chef de projet et même par fois ton commercial , tu subis toute cette politique. Leur dire de complètement changer ne fait pas partis de leur culture d'entreprise.
    Apres c'est sure quand ils voient les applications blingue-blingue, ils croient qu'on peut faire pareil a partir de leur existant.

    Je pense qu'il faut arrêter aussi cette culture que l'informatique est un coût. On fait partie intégrante des variables de l'entreprise. Nous somme une source d'eau, nous somme vitales pour votre métier. Nous sommes pas une chaise qu'on achète chez Ikea.

  9. #9
    Expert confirmé
    Avatar de GLDavid
    Homme Profil pro
    Service Delivery Manager
    Inscrit en
    Janvier 2003
    Messages
    2 851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Service Delivery Manager
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Janvier 2003
    Messages : 2 851
    Points : 4 743
    Points
    4 743
    Par défaut
    Bonjour

    Globalement, je suis d'accord avec ce qui est dit.
    Je vais retenir les points suivants:
    1) Un développeur (ou chargé de l'IS) est multi-tâche: c'est vrai quand vous l'informaticien se retrouve seul contre tous face à des départements plus fournis. D'accord, si le core-business de la société n'est pas l'informatique, c'est compréhensible. Mais si vous travaillez sur un projet qui vous demande beaucoup de temps, cela devient très difficile de concilier ce projet avec le support quotidien, les 'fast-projects' (petit projets urgents à faire de suite car l'avenir du monde libre en dépend) et autres impondérables (collègue qui part en vacances-dépression-congés maladies-autres et évidemment, vous le remplacez au pied levé). Finalement, votre gros projet ne peut que prendre du retard.
    2) Les spécifications: ah! Nous touchons un point sensible! Où comment transcrire ce que vos collègues non-informaticiens voudront voir réalisé par un ordinateur. Il faut croire que les spécifications sont en faites un document jamais clos... même quand le projet est terminé. Autrement dit, il n'est rien de plus pénible que de travailler sur un projet où: i) personne ne sait finalement ce qu'il veut, ii) A contrario, le projet pourra résoudre tous les problèmes ainsi que la faim dans le monde, iii) si vous travaillez avec un prestataire externe, vous devez traduire la transcription de vos collègues; sinon, gare aux mauvaises surprises! Pour un projet, tout est question de dead-lines. Les spécifications doivent être closes à un moment donné, jamais en cours de réalisation ou de finalisation.
    3) Les ressources: Abondance de biens ne nuit jamais dit le proverbe. Trop de monde dans un projet revient alors à coordonner tout ce petit monde avec ses individualités mais des back-ups sont possibles. Quand vous êtes peu nombreux et qu'on refuse toute aide parce que "pas d'argent", priez pour que vos collègues ne tombent pas comme des mouches!

    Finalement, le retard dans un projet dépend de l'organisation, de ce que l'on veut et des moyens que l'on se donne. Rien qu'avec cela, on peut déjà adresser des temps raisonnables.

    Mais comme on veut toujours aller plus vite...

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  10. #10
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    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 même souvent pire.
    Un chargé de comm de la boite A contacte le chargé de comm de la boite B qui transmet ce qu'il a compris de ce que le client a compris de la demande à l'équipe technique. Impossible ensuite d'avoir des discussions d'équipe technique à équipe technique

  11. #11
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par Stéphane le calme Voir le message
    Il arrive parfois en entreprise que les délais de livraison d’un projet de développement ne soient pas respectés. Lorsqu’il faut en trouver la cause, il est parfois plus facile de désigner du doigt l’apparente lenteur des développeurs. Mais est-ce que ces « développeurs lents » sont vraiment la raison pour laquelle le projet a pris du retard ?
    Des fois, c'est très simple à comprendre :

    - l'analyste fonctionnel arrive avec une spécification, il demande aux développeurs "combien ça va prendre de temps"
    - le développeur revient avec une estimation, en étant "large"
    - l'analyste fonctionnel valide, le développeur commence son travail
    - en cours de route, l'analyste fonctionnel revient avec des nouvelles contraintes, plein de changements, des trucs pas prévus, des trucs pour lequel il n'a pas encore d'info...
    - le développeur fait ce qu'il peut
    - plus tard, le responsable (style "Pointy-Haired Boss" dans Dilbert) arrive en demandant "pourquoi ça prend du temps ? Pourquoi on est en retard sur les estimations ?"
    - l'analyste fonctionnel, pour ne pas se mouiller, répond que c'est de la faute du développeur

    C'est très souvent le cas dans les boites françaises : c'est tellement plus simple de tout mettre sur le dos du développeur...


    Il y a aussi le cas de l'analyste fonctionnel qui ne sait pas faire la différence entre spécifications fonctionnelles et spécifications techniques.

    Ou même pire : il sait faire la différence, mais vu que les specs fonctionnelles tiendraient sur 3 pages (dont 2 pages de bla-bla administratif), il lui vient une très mauvaise idée :
    - il se sent obligé de faire du "remplissage"
    - ... avec des specs techniques
    - ... sauf qu'il n'est pas technicien et sort un algorithme bancal (long, absolument pas efficace, et ne couvrant pas les cas les plus basiques)
    - ... et le développeur n'ose pas remettre la spec en cause (de peur de se prendre un savon peut-être)
    - ... et passe 2 semaines sur le développement
    - ... sauf que quand on teste, ça ne marche pas et il faut réécrire plus de la moitié du programme

    Mais ça ne s'arrête pas là (et c'est là que ça devient drôle) :
    - un autre développeur (celui chargé de tester la solution) reprend les specs dites "fonctionnelles"
    - il repense la solution et ré-implémente ce qui ne peut pas marcher (avec un algorithme beaucoup plus simple)
    - on fait des tests, ça semble marcher
    - il le tout présente à l'analyste fonctionnel
    - l'analyste fonctionnel, visiblement vexé qu'on ait osé changer sa solution, décide de classifier le tout comme "non prioritaire" (et ça passe aux oubliettes)

    Absolument ubuesque !


    Encore une fois, c'est tellement plus facile de rejeter la faute sur le dos du développeur quand ça va mal... (et de ne pas admettre ses erreurs... et de s'attribuer les lauriers quand tout va bien...)
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  12. #12
    Expert éminent

    Avatar de deusyss
    Homme Profil pro
    Expert Python
    Inscrit en
    Mars 2010
    Messages
    1 659
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Expert Python
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 659
    Points : 8 442
    Points
    8 442
    Par défaut
    D'ou l'importance de tout tracer.

    Dans mon ancienne boite, on avait de gros soucis sur un projet, et pour finir le commercial nous as dit qu'il voulait qu'on trace tout par mail. Il ne savait pas qui disait la verité. Meme une simple discussion orale en direct, on retournait à notre poste, on transcrivait la discussion et on envoyait.

    A partir de là, le client, fort mécontent de cette démarche a eu beau protester (mais on a continué), il s'est rendu compte qu'il pourrait plus nous arnaquer.

    Donc il n'y a pas de solutions miracles, et comme beaucoup dit précédemment, il existe de multiples configurations différentes. Mais dans tous les cas, mieux vaut tout tracer car si quelque chose tourne mal, on peut sortir une copie en disant "j'avais remonté l'info, vous assumez".
    "La connaissance appartient à tout le monde" (Film Antitrust)

    Tout le nécessaire pour Python:
    *News/Accueil *Cours/tutoriels *FAQ
    *Forums *Outils dédiés *Mon espace personnel avec mes Articles, Cours et Tutoriels

  13. #13
    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
    Ce qui est frappant dans cette analyse et dans vos commentaires c'est que vous avez tous raisons et pourtant on se retrouve presque toujours hors délai sur des projets informatiques.

    Avec mes 11 ans d'expérience, j'ai pu me rendre compte de plusieurs paramètres qui peuvent également expliquer (sans doute pas tout expliquer mais il s'agit sans doute de vecteurs non négligeable dans le cycle de vie d'un projet)

    1 - L'expression du besoin n'est pas toujours formulé par écrit. (Le cahier des charges, les spec non plus)
    2 - Vos interlocuteurs en charge de la demande ne sont pas toujours disponibles.
    3 - Le mode forfait présente est généralement sous évalué (et difficile une fois le projet signer de voir votre client en exposant un mauvais chiffrage du projet)
    4 - le chiffrage justement est souvent sous évalué car le projet est souvent calculé sur le temps de conception et de développement, mais il manque très souvent 20% de temps pour les phases de recettes.
    5 - la politique commerciale est souvent celui qui pose les jalons dans un projet informatique souvent au détriment de l'expertise de l'équipe qui sera en charge du projet (ex : commercial demande à l'équipe de projet : combien de temps pour réaliser ce projet ? L'équipe dit : avec tous paramètres pris en compte, et que tout soit au verts, ils faut X jours (et nous savons tous que les paramètres ne sont pas toujours au verts, certains passent même du vert au rouge : effets de bord pour ne citer que celui la) Le commercial lui fait sa mayonnaise pour "gagner le marché" puis dit : le client à un budget de de Y€ ca représente (Y/X) = Z€ en coût journalier... Toutefois Z€ ne permet pas d'être rentable pour la boite informatique. En conséquence pour qu'elle le soit, et en règle général, le commercial demande de réaliser le projet en X-Lambda jours

    Infaisable pour d'équipe de projet, et souvent nous voyons des équipes travaillant 9h, 10h, 12h par jours (et très souvent ces heures supplémentaires ne sont ni payés ni récupérés) mais si nous évaluons 12h sur une journée de 8h, vous avez passé 1H et demi ... Mais sur le plan comptable de votre entreprise est notifié 1 jour...
    Et malgré cela le projet dépasse la durée calculé par votre commercial (ou votre responsable) car l'étude ne tiens pas compte non plus de la baisse de rendement d'un développeur lié à la fatigue physique et mental, occasionné par la pression, le stress, les heures supplémentaires.

    6 - Très souvent dans les SSII, nous sommes également confronté à un problème de compétence non pas à cause des développeurs eux-mêmes, mais à cause des responsables qui vont placer un collaborateurs le qualifiant d'expert dans le domaine alors qu'il n'a que 3 semaines d'expériences dans la techno... (forcément que le rendement de ce collaborateur sera moindre qu'un collaborateurs avec 10 ans d'expérience et une vrai étiquette d'expert sur le front). Pourquoi cette méthode ? simplement pour réduire un maximum les intercontrats, très répandus en SSII (ou ESN).

    7 - La formations des collaborateurs : Absence ou quasi absence de politiques de formations, elle à un double effet : En formation le collaborateurs ne rapporte pas d'argent à sa société car elles n'est pas en prestation de service et donc pas facturé, MAIS en plus le collaborateurs coûte de l'argent à sa société, puisqu'une formation coûte de l'argent... (Et bien souvent on laisse un collaborateur en intercontrat et on va lui demander de monter en compétence par lui même, en autonomie, car ça coûte moins cher, cependant ça ne fera pas de lui un expert)

    Voilà selon moi, les points en plus des votre qui justifie très souvent un retard dans les délai de livraison d'un projet informatique

  14. #14
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    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 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Depuis le temps que tous les développeurs de ce forum réclamaient un article à charge sur les managers, en voilà un beau

    Blague à part, je suis plutôt en phase avec l'étude qui est une excellente occasion de replacer le rôle et les missions du manager de projet
    On a souvent tendance à limiter la visions des missions du CP à la gestion de l'équipe (le terme "gestion de ressources" qui fait hurler les développeurs) alors que c'est très réducteur
    Le manager de projet gère un projet dans son ensemble et la gestion de l'équipe de développement en est un aspect mais au final, très faible en ratio temps par rapport à tout le reste
    D'expérience, hors cas particuliers, une équipe de développement est assez autonome à partir du moment où elle est bien constituée (bon équilibre entre les débutants et les expérimentés. Équilibre qui varie en fonction de la difficulté du projet).
    Un manager de projet est là pour absorber tout les "à côté du dev" : gérer la hiérarchie, gérer le client, gérer les autres équipes (infra, sécu, etc.)
    En pratique, un manager de projet passe 2x plus de temps à gérer le client qu'à s'occuper de l'équipe de développement

    Qu'un client ne sache pas précisément ce qu'il veut est normal et même logique sinon pourquoi ferait il appel à nous ?
    S'il fait appel à des ressources externes c'est justement parce qu'il n'a pas les compétences en interne tant en conduite de projet, qu'en conception et en réalisation
    Le client fait appel à nous pour avoir des conseils
    Nous devons être force de proposition
    Nous devons cadrer le client et avoir constamment un regard critique sur l'intégralité des éléments du projet. Pour rappel, un regard critique, c'est une prise de recul. Ce n'est pas systématiquement négatif, bien au contraire.

    Dire "oui amen" à tout est un profond signe de totale incompétence et de manque de personnalité.
    Le client a besoin qu'on lui dise non.
    Bien sûr, il y a la forme et cela s'apprend avec le temps et c'est un apprentissage très douloureux mais nécessaire.

  15. #15
    Membre éprouvé
    Avatar de landry161
    Homme Profil pro
    C#,PHP,MySQL,Android...
    Inscrit en
    Juillet 2010
    Messages
    423
    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 : 423
    Points : 1 059
    Points
    1 059
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Cet article reflète bien la réalité quotidienne de tous les développeurs.
    Malheureusement, les managers et les utilisateurs ne savent pas qu'un élément supplémentaire
    dans le cahier de charges, alors que le développement est déjà en cours, peut tout chambouler.
    .
    Ils n'ont pas vraiment conscience des difficultés auxquelles les développeurs sont confrontés.

  16. #16
    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
    Citation Envoyé par Saverok Voir le message
    Depuis le temps que tous les développeurs de ce forum réclamaient un article à charge sur les managers, en voilà un beau

    Blague à part, je suis plutôt en phase avec l'étude qui est une excellente occasion de replacer le rôle et les missions du manager de projet
    On a souvent tendance à limiter la visions des missions du CP à la gestion de l'équipe (le terme "gestion de ressources" qui fait hurler les développeurs) alors que c'est très réducteur
    Le manager de projet gère un projet dans son ensemble et la gestion de l'équipe de développement en est un aspect mais au final, très faible en ratio temps par rapport à tout le reste
    D'expérience, hors cas particuliers, une équipe de développement est assez autonome à partir du moment où elle est bien constituée (bon équilibre entre les débutants et les expérimentés. Équilibre qui varie en fonction de la difficulté du projet).
    Un manager de projet est là pour absorber tout les "à côté du dev" : gérer la hiérarchie, gérer le client, gérer les autres équipes (infra, sécu, etc.)
    En pratique, un manager de projet passe 2x plus de temps à gérer le client qu'à s'occuper de l'équipe de développement

    Qu'un client ne sache pas précisément ce qu'il veut est normal et même logique sinon pourquoi ferait il appel à nous ?
    S'il fait appel à des ressources externes c'est justement parce qu'il n'a pas les compétences en interne tant en conduite de projet, qu'en conception et en réalisation
    Le client fait appel à nous pour avoir des conseils
    Nous devons être force de proposition
    Nous devons cadrer le client et avoir constamment un regard critique sur l'intégralité des éléments du projet. Pour rappel, un regard critique, c'est une prise de recul. Ce n'est pas systématiquement négatif, bien au contraire.

    Dire "oui amen" à tout est un profond signe de totale incompétence et de manque de personnalité.
    Le client a besoin qu'on lui dise non.
    Bien sûr, il y a la forme et cela s'apprend avec le temps et c'est un apprentissage très douloureux mais nécessaire.
    Dans la forme vous avez raison, mais dans le fond, c'est autre chose. Pourquoi me diriez-vous ? Car il serait réducteur de faire une généralité des clients ou des demandeurs. J'ai vue certains entreprises ne maîtrisant pas leur domaine fonctionnel, d'autres ne maîtrise pas ni le fonctionnel ni la technique à cause de l'externalisation du service informatique. Toutefois, vous n'agissait plus en tant que force de proposition, ni en tant qu'expert, mais en tant que producteur d'une demande pas toujours calibrée, pas toujours étudiée, pas toujours clairement définie.

  17. #17
    Membre éprouvé
    Avatar de landry161
    Homme Profil pro
    C#,PHP,MySQL,Android...
    Inscrit en
    Juillet 2010
    Messages
    423
    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 : 423
    Points : 1 059
    Points
    1 059
    Billets dans le blog
    1
    Par défaut
    J'ai aussi bossé dans une boîte où on travaillait sur une application.A chaque instant il y avait toujours quelque chose de nouveau.
    "Telle chose,le client veut qu'elle soi comme çi","ce truc là faites plutôt comme cà".
    Au finish, je me trouvais complètement déboussolé et désorienté.

    Je pense donc que la conduite d'un projet doit passer nécessairement par une définition des tâches ,l’établissement de cahier de charge précis , clair et bien détaillé et bien d'autres de sorte que le développement soit beaucoup plus aisé.

  18. #18
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    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 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par landry161 Voir le message
    J'ai aussi bossé dans une boîte où on travaillait sur une application.A chaque instant il y avait toujours quelque chose de nouveau.
    "Telle chose,le client veut qu'elle soi comme çi","ce truc là faites plutôt comme cà".
    Au finish, je me trouvais complètement déboussolé et désorienté.

    Je pense donc que la conduite d'un projet doit passer nécessairement par une définition des tâches ,l’établissement de cahier de charge précis , clair et bien détaillé et bien d'autres de sorte que le développement soit beaucoup plus aisé.
    Je pense que tu as surtout besoin d'un manager de projet qui sache faire tampon avec le client
    Autrement dit, qu'i sache identifier les incertitudes du client et mener le dialogue avec lui (en compagnie du développeur c'est mieux) pour bien clarifier sa demande dans son ensemble avant de donner le GO pour le dev de ladite fonctionnalité

    Un manager de projet a bien mieux à faire que le simple "passe plat" des demandes client.

    Croire qu'en agile on travaille sans spécification est une idée fausse.
    Bien au contraire, on travaille avec des spéc très détaillée mais à chaque fois, sur une seule et unique fonctionnalité
    L'idée est justement de bien identifier les fonctionnalités du projet et de les prioriser et pour chaque fonctionnalité, engager un dialogue avec l'ensemble de l'équipe, ce inclut le client, pour en définir les spécifications en pensant à l'intégralité des cas.
    Cela se fait en direct lors des réunions de planification des itérations.

    Citation Envoyé par sidewolf Voir le message
    Toutefois, vous n'agissait plus en tant que force de proposition, ni en tant qu'expert, mais en tant que producteur d'une demande pas toujours calibrée, pas toujours étudiée, pas toujours clairement définie.
    Et c'est le meilleur moyen de se planter et cela n'a rien à voir avec l'agile
    Mener un projet agile est l'exacte opposée de cette définition du "producteur" au sens strict et limitante du terme.

  19. #19
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2007
    Messages
    185
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

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

    Informations forums :
    Inscription : Janvier 2007
    Messages : 185
    Points : 469
    Points
    469
    Par défaut
    Il ne faut pas oublier qu’avant d'arriver dans l'escarcelle du développeur le besoin du client passe dans beaucoup de mains. Je rajouterai aussi que trop souvent le chef de projet et non technique et sa traduction du besoin ne permet pas par la suite d'implémenter judicieusement le besoin spécifique demandé par le client. Donc le développeur se retrouve finalement en bout de chaîne or la seule personne qui a réellement besoin de comprendre les demandes du client n'a pas participé ni à l'élaboration du besoin ni à sa traduction en terme de composants techniques.

    Je constate que d'année en année le rôle du développeur a été réduit à sa plus simple expression: la réalisation alors que dans le même temps les couches intermédiaires entre le client et lui ont été densifiée massivement. Je le constate sur tous les projets depuis 5 ans au moins. Il y a maintenant une telle distance entre le client et le développeur qu'il y a finalement très peu de chance que ce qui sera livré correspondra au besoin exprimé par le client ...

    Après on ira convaincre le client que c'est bien de cela dont il avait besoin et que ses demandes s'inscrivent dans une démarche d'évolution plus globale du SI qui lui échappe totalement blah blah ...

    Pour résumer:

    Le Client soumet un pb de gestion
    => le MOA imagine ce qu'il faudrait changer du point de vue du fonctionnel (expression de besoin) pour résoudre le pb et fourni une liste d'exigences
    => le chef de projet formalise plus le besoin en terme de fonctions logicielles (use case UML) et liste des composants techniques à réaliser (les specs techniques détaillées)
    => le développeur commence à développer sans véritablement comprendre la finalité ni le contexte métier ...

    Comme déjà souligné, viens aussi s'ajouter des difficultés supplémentaires comme les changements de priorité ou de scope de dernière minute, le manque de visibilité sur les impacts des modules adjacents etc ...

    Les seules fois où j'ai vu un projet fonctionner et donner entière satisfaction au client dans les délai impartis et en générant une rentabilité maximale pour le prestataire, c'est lorsque le développeur était celui qui recueille le besoin du client. Le développeur en étant confronté au métier comprends les tenants et aboutissants des demandes du client et sait du coup ce qui est important pour la personne qu'il a en face (en terme d'ergonomie, de fonctionnalité etc ...) et sais ce qui serait plus pertinent en terme de composants techno pour mieux répondre à la demande et cela il s’en souviendra au moment d’aligner les première lignes de code. Je ne parle même pas de la motivation et la responsabilisation du développeur qui participe grandement à sa réactivité et sa productivité.

    Le client quant à lui sait que toutes ses demandes seront prises en compte car il a en face de lui une écoute attentive qui fera attention au moindre détail y compris les plus anodins, la plupart du temps les moins coûteux à réaliser et qui bien souvent sont la clé de la satisfaction du client.

    Je ne dis pas qu’il faut supprimer toutes les couches intermédiaires mais au moins réfléchir à rapprocher le développeur du client car tout le monde y gagnerait !
    ;)

  20. #20
    Membre éprouvé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Août 2014
    Messages
    476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : Août 2014
    Messages : 476
    Points : 1 042
    Points
    1 042
    Par défaut
    Chez nous le pb c'est en partie du fait que les prestataires ne sont interessés que par la techno (le metier ils s'en tapent completement).
    Du coup ils se font plaisir a faire du code beau, refactoring a gogo, defaire/refaire parce qu'une nouvelle brique logicielle vient de sortir etc. et quand il faut livrer un logiciel qui remplisse des fonctions... ben ca le fait mal ou ca le fait pas.

    Les CDP et autres subissent (un peu la fuite en avant - dire d'arreter mettrait encore plus en peril le projet).
    Au bout de 25 ans d'informatique je me rends compte que c'est le pb des informaticiens - ils se generent du boulot et oublient l'essentiel quelques fois.

Discussions similaires

  1. Réponses: 24
    Dernier message: 03/11/2013, 14h20
  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, 02h55

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