« Bref … mon développeur se fout de ma gueule ! »

C’est ce que j’aurais pu me dire compte tenu de la situation ! Mais 1) Paul n’était pas « mon » développeur et 2) il n’avait aucune mauvaise intention à mon égard, enfin .. je crois !

Je venais de reprendre un projet. Le chef de projet avait été envoyé en mission longue durée chez un client et le projet se retrouvait sans pilote. Fort de ma première expérience de chef de projet (vous comprendrez l’ironie …), on m’affecta le rôle de chef de projet pendant cette phase si délicate qu’est la phase de recette.

Je n’étais pas complètement étranger au projet puisque j’avais participé à l’analyse fonctionnelle, la modélisation de la base de données et la reprise de données.

Phase de recette donc. Celle-ci est assez difficile. Les tickets remontés par le client sur le gestionnaire de bugs s’accumulent et les livraisons successives n’arrivent pas à satisfaire le client. Difficile de reprendre un projet au forfait dans ce contexte mais quand il faut y aller, faut y aller …

Parmi les symptômes, plusieurs tickets reviennent d’une livraison à l’autre. Ce qui est sensé être corrigé ne l’est finalement pas. Le client commence à en avoir marre de retester la même chose et il commence à le faire savoir.

La correction d’anomalies : l’histoire sans fin

Je refais donc une passe sur les tickets, je les qualifie, je tâche de les reproduire et les renvoie éventuellement chez le client avec une demande de précisions. Pour les anomalies avérées, je les affecte aux personnes de l’équipe pour correction. Une fois corrigées, les tickets prennent un statut pré-recette. Et avant de livrer, je vérifie que la correction est bien en place pour chacun de ces tickets.

Et heureusement ! je tombe sur des tickets soi-disant corrigés qui ne passent pas les tests. Je vérifie un peu le cas de test, je reboucle avec Paul, le développeur pour le contenu de la spécification et le résultat attendu et je rebascule le ticket à « En cours de traitement ».

Je bascule sur un autre projet. Je reviens en fin d’après-midi sur cette liste de tickets.  Rebelote, je passe en revue les corrections, vérifie que c’est conforme et valide la plupart. Sauf un !

Je fais la remarque à Paul. Je l’aime bien Paul, il est toujours de bonne humeur, souvent prêt à lancer une blague et à rire à celles des autres. Mais là, cela fait 2 fois qu’il travaille sur cette anomalie et je n’ai pas envie d’y passer la nuit. Mon ton est très légèrement agacé mais prudent, sait-on jamais, je ne teste peut-être pas comme il faut … :

« C’est toujours pas bon, Paul, pour le ticket #913, je passe toujours pas le contrôle du formulaire, tu peux vérifier, s’il te plaît ? »

Sans rentrer dans des considérations techniques, il s’agit simplement d’un formulaire web, certes complexe mais sur lequel on applique de simples contrôles pour valider les données saisies par l’utilisateur. Par exemple, un code postal doit contenir 5 chiffres, sinon c’est qu’il y a un problème. Et je n’arrive pas à passer le contrôle avec une donnée pourtant « bonne » d’après ce que je comprends.

Je sens que Paul s’active au bureau de l’autre côté. Ca tapote fortement sur le clavier, la souris s’agite un peu et au bout de 30 secondes, j’entends :

« Ah oui, ça devrait être bon maintenant ! »

Je lui réponds : « T’es sûr hein ? » avec un sourire en coin pour lui faire comprendre que ça fait 3 fois qu’il repasse dessus quand même …

« Oui oui ! » qu’il me dit avec le même sourire ..

Développeur trop confiant pris en flagrant délit !

http://owni.fr/Ok ! Je reprends mes tests, j’ouvre le formulaire, je saisis à nouveau mes données de test et … ça ne marche pas ! Rrrrrrrrrh ! la règle est quand même simple, c’est juste une condition, Paul assure bien techniquement d’après ce que je « sais », ça devrait pas lui échapper, je pense.

Je m’apprête donc à faire la remarque à Paul .. et finalement décide de ne rien dire pour le moment. J’aimerai d’abord jeter un coup d’oeil au code source. Après tout, c’est une simple condition à implémenter, je dois bien pouvoir comprendre si je teste bien ce qu’il faut.

Je trouve l’endroit exact où ça se situe. Et là, je tombe sur une condition qui, manifestement, ne peut être jamais vraie, le résultat sera toujours faux quelles que soient les conditions. C’est comme contrôler que le champ « code postal » doit contenir que des lettres : quelque soit le code postal numérique que je rentre, ça ne marchera jamais.

Je vérifie mon hypothèse en modifiant le code. Effectivement, cela fonctionne maintenant. Je remets le code comme il était avant et me laisse 10 secondes pour décider quoi faire …

« Paul, tu l’as testé le ticket #913 ? »

« Oui oui pourquoi ? »

« Tu peux venir voir ? je comprends pas un truc là … »

Paul se lève et vient à côté de moi.

Il m’a regardé. J’ l’ai r’gardé. J’lui ai montré l’écran avec mon doigt. Il a regardé mon doigt sur l’écran.

J’lui ai dit : « Y’a un truc que je ne comprends pas, explique-moi comment cette condition peut être vraie. »

thegazettepowa.blogspot.com

Il m’a dit : « Ah ben … jamais apparemment .. »

Il m’a regardé. J’ l’ai r’gardé.

J’lui ai dit : « Et comment il peut marcher alors le ticket #913 ? »

Il m’a dit : « … »

5 secondes de silence. Tout est dit. Il est déjà reparti à sa place pour corriger. Je lui lance une remarque pour qu’il teste cette fois avant de me dire que c’est corrigé. Il me sourit. Je lui souris. On s’est compris … Ajouté à cela que la moitié du plateau a entendu la conversation, Paul a été un peu plus rigoureux ensuite … mais je veillais au grain.

La confiance, ce n’est pas une question de politesse

Alors je mets fin directement au potentiel débat que les développeurs sont des fainéants qui ne testent pas, ce n’est pas l’objet de cet article, ce n’est bien sûr pas vrai et je respecte complètement la difficulté du métier. Alors bien sûr, ils doivent tester. Mais tout le monde doit tester et vérifier son travail quel qu’il soit, chef de projet, développeur, commercial … soi-même ou avec l’aide de quelqu’un d’autre d’ailleurs.

Je souhaite simplement mettre en évidence que par défaut, il ne faut pas faire confiance. Si vous ne connaissez pas la personne, si vous n’avez jamais travaillé avec et même si vous avez entendu beaucoup de bien de cette personne, ne faites pas confiance par défaut. Testez cette personne dans le contexte particulier où elle évolue pour vous faire votre propre opinion.

Si j’avais fait confiance et que je n’avais pas vérifié, j’aurais effectué une livraison en disant au client que c’était corrigé alors que ça ne l’était pas. Et pour remonter la satisfaction client, ça n’aide pas …

La confiance, ça se gagne petit à petit, au fur et à mesure que vous déléguez des tâches. Bien sûr, il peut y avoir des loupés, cela arrive à tout le monde. Mais, pour éviter les problèmes, mieux vaut éviter la solution de facilité de faire confiance par défaut. Ensuite à vous de voir à partir de quel moment vous décidez d’accorder votre confiance.

NB: sur le même sujet, je vous explique pourquoi j’ai une confiance très limitée envers les agences immobilières : le remboursement de ma caution locative

Et vous ? faites-vous confiance facilement ?

Mise à jour : je précise que cette histoire s’est déroulée en 2006 ..

34 réflexions au sujet de “« Bref … mon développeur se fout de ma gueule ! »”

  1. Bonjour JP,

    Ta petite histoire me rappelle des souvenirs ! Comme toi, jeune chef de projet j’avais tendance à trop facilement faire confiance à mon équipe.

    J’ai appris à être vigilant, à vérifier ce qu’ils font et surtout à m’adapter à chacun : on ne gère pas deux personnes différentes de la même manière (c’est quelque chose que mon premier employeur m’avait appris). Certains travaillent mieux quand on leur donne une totale autonomie et d’autres ont besoin d’être relancés quotidiennement : ce n’est qu’en s’y adaptant qu’on pourra leur faire confiance et que eux – très important aussi – pourront nous faire confiance.

    Répondre
    • Tu le soulignes très bien, il s’agit plus de confiance dans la relation que dans la personne. Une fois qu’on est d’accord sur la manière de travailler, on a beaucoup plus confiance dans la manière de collaborer et du coup on est beaucoup plus serein sur le résultat !

      Répondre
    • Bonjour,

      Il faut aussi penser à responsabiliser le développeur… et intégrer les phases de test et de refactoring au quotidien, afin de simplifier toute la complexité accidentelle (non-métier)…

      Rénald

      Répondre
  2. Bonjour Jean Philippe,

    Article sympa mais je ne partage pas la conclusion… Comme tu l’as fait et décrit, je suis plutôt pour faire confiance la première fois avec une personne avec qui ça passe bien. Si les choses ne se passent pas comme prévues, on peut tjrs mettre les choses au point, simplement en le disant.

    Je trouve dommage de commencer une relation sur de la suspicion. Je reste optimiste et je préfère me dire que la personne en face est là pour bosser en bonne entente, chacun faisant son taf et parfois aussi ses erreurs (on en fait tous…).

    Répondre
    • Bonjour Bastien,

      je te rassure je suis d’un naturel optimiste et par défaut, je fais souvent confiance malgré tout … jusqu’à un certain point.

      Ne pas faire confiance ne veut pas dire tomber dans la suspicion mais bien de garder une approche neutre en début de relation et voir .. tester et ensuite construire la confiance ! ou bien devenir très prudent parfois !

      Répondre
  3. Même commentaire pour ma part que Bastien. Faire confiance est une preuve de maturité, il ne s’agit pas d’être suspicieux avec son équipe dès le départ. En somme faire confiance et savoir recadré (comme tu l’as fait) est de loin la meilleure solution et celle qui nous prend le moins de temps. Ensuite, les adaptes du management situationnel te diront qu’il faut veiller à l’envie et l’expérience de ton collaborateur, et adapter ton style de management ce qui , pour l’avoir testé marche très souvent.

    Répondre
    • Comme je le disais à Bastien, ne pas faire confiance ne veut pas dire devenir suspicieux, le curseur se situe au milieu des deux.

      Il ne s’agit pas non plus de tendre un piège ou de ne pas donner tous les éléments pour travailler correctement, il s’agit simplement de tester et vérifier avant de donner plus de responsabilités (communication directe avec le client, prise en charge d’une livraison, pilotage d’un projet …) ou plus d’autonomie.

      Et bien sûr, je partage complètement ton point de vue qu’il faut s’adapter à chacun, ce que j’ai fait avec Paul, je l’ai fait différemment avec d’autres collègues.

      Répondre
      • La différence vient, à mon sens du style de management, ou l’on fait confiance et l’on recadre si besoin, ou l’on délègue petit à petit,, l’essentiel en somme et d’arriver à atteindre l’objectif, le chemin peut être variable à la fois selon les managers et les managés.

        Répondre
  4. Cas de figure assez fréquent quand même. J’ai eu le problème il y a quelques années, en phase de recette aussi, les mecs ne corrigeaient pas les erreurs, pire même, quand je leur envoyais une fiche de bug, ils me la renvoyaient en me disant « hors périmètre, c’est une évolution et non une ano » ou alors « non reproductible »… Et le pire du pire c’est que c’était des prestataires qui n’étaient pas dans nos locaux, rendant la communication et la surveillance beaucoup plus complexe. J’ai du escalader au directeur de projet qui a lui même escaladé au responsable de service pour dialoguer directement avec le directeur de la boite de service en question. Les problèmes ne se sont bien entendu pas résolus… bonheur. 🙂

    Répondre
    • Par confiance, j’entends pouvoir déléguer des responsabilités sans avoir besoin de contrôler les détails et se contenter d’un pilotage à un niveau stratégique. Cela revient à créer un niveau de management intermédiaire.

      Si je pense devoir contrôler le détail, c’est que je n’ai pas confiance ..

      Répondre
  5. Bonjour JP,

    Etant développeur (euse), je me suis intéressée à ton feedback sur la problématique de corrections de bugs qui ne l’est jamais.

    J’ai un peu du mal à concevoir le fait qu’un développeur ne test pas la correction qu’il vient de faire sur une partie de son code pour valider de son côté le bon fonctionnement avant de renvoyer au client ou comme ici le cas, au chef de projet pour test et validation du bon fonctionnement.

    Pour ma part, j’appellerai cela : être rigoureux dans son travail, et comprendre l’implication qu’engendre le fait de prendre un peu « par dessus » la jambe la correction de bugs sur une application.
    Une correction de bugs non correctement contrôlée, client mécontent et au final risque de perte du dis client et de projets potentiels, voir perte financière !

    Alors faut il faire confiance, je dirais de prime abord, rester sur la réserve et tester les collaborateurs. Je devrais prêcher pour ma paroisse, mais depuis quelques années je reprends beaucoup de projets déjà développés pour évolutions ou corrections, et franchement il y a matière à se poser des questions sur l’implication réel d’un développeur dans son travail, sa rigueur et son soucis d’une livraison d’application nickel.
    Cela étant, je suis pour le fait qu’un chef de projet, justement ais une très bonne notion en développement du fait qu’il est facile pour un développeur de mener « en bateau » son chef de projet et son client !

    Répondre
    • Bonjour Jenny,
      tu sembles parfaitement comprendre les enjeux depuis la correction d’un « simple » bug jusqu’à l’impact potentiel sur la santé financière d’une entité, d’une « business unit » voire d’une entreprise, ça me fait plaisir ! Et merci d’abonder dans ce sens !
      J’ai malheureusement rencontré des situations où le discours était de dire que c’était au client de tester … donc il y avait du chemin à parcourir pour arriver à ton niveau de maturité !
      Le chef de projet peut soit avoir des connaissances techniques pour éviter comme tu le dis de se faire mener en bateau, soit il peut avoir quelqu’un sur qui s’appuyer pour le faire mais là aussi c’est une histoire de confiance :-).

      Répondre
    • Développeur depuis une dizaine d’année, j’ai du mal à concevoir qu’un développeur ne teste pas ses applications (à moins qu’il ne soit plus motivé par son travail ou sa paye).

      Répondre
  6. Bonjour JP,

    Le chef de projet doit disparaitre. Il le faut. Cette volonté de hiérarchie implique automatiquement ce que tu décris.
    Plutôt que partir avec un chef qui controle, vois plutôt ton équipe comme des éléments importants de ton projet. Ce n’est pas toi qui le maitrise, mais toute ton équipe.
    Et surtout, dis leur vraiment ça, c’est important.

    Se sentir responsabilisé, se sentir important dans l’équipe, voir souvent supérieur à un chef de projet, le développeur en a besoin.

    Un développeur impregné réellement du projet, avec des points réguliers, avec un sentiment qu’il travaille vraiment pour quelque chose fera moins, beaucoup moins d’erreurs.

    Après, les recettes sont là pour l’aider à bien vérifier ce qu’il dit. Fais-tu des cahiers de recette ?
    Fais tu des livraisons fréquentes ? Pourquoi c’est toi qui le ferais d’ailleurs ?

    Beaucoup de choses sont oubliées quand on pense CdP face à Développeurs .. très grosse erreur selon moi.

    A plus
    Evan, entrepreneur agile.

    Répondre
    • Bonjour Evan,

      pas sûr de te suivre complètement. Pour moi, il n’y a pas de hiérarchie entre chef de projets et développeurs, ce sont des métiers différents, des responsabilités différentes, des compétences différentes au sein d’une même équipe.

      Si le développeur ne fait pas son taf, le chef de projet peut lui dire. Si le chef de projet ne fait pas son taf (défendre l’équipe vis-à-vis du client par exemple), le développeur peut lui dire.

      Qu’un développeur se sente responsabilisé, oui, qu’il se sente supérieur à un chef de projet, non. Au même titre qu’un chef de projet ne doit pas se sentir supérieur ou faire sentir qu’il est supérieur à « ses » équipes. Il n’y a donc pas de « Cdp face à Développeurs » pour moi, mon titre est légèrement provocateur mais d’après moi l’article ne reflète pas cela, sinon c’est une erreur de ma part.

      Je te rejoins sur le fait de faire sentir au développeur qu’il travaille vraiment sur quelque chose d’important. Maintenant c’est souvent beaucoup plus facile à dire qu’à faire .. parfois c’est ennuyeux fonctionnellement pour le développeur, parfois c’est barbant techniquement, tous les projets ne donnent pas le sentiment de changer le monde positivement .. Je suis donc preneur de tes tuyaux :-).

      Merci pour ton retour,
      JP

      Répondre
  7. Hum, ce genre d’erreur ne peut exister si des tests automatisés sont mis en place (unitaires et fonctionnels)… J’aimerais pas être un de vos client.

    Cordialement

    Répondre
    • Clair.

      Avec Selenium/FluentLenium tu fais facilement des tests d’acceptance sur tes IHM, pourquoi pas dirigés via un framework BDD comme Cucmber.
      Cf: http://blog.jetoile.fr/2013/03/fluentlenium-et-cucumber-jvm-sont-sur.html

      Mais même avec des tests d’acceptance automatisés, on detecte les regressions, mais ça n’empêche pas qu’il faille recetter au moins les anomalies et évolutions embarquées dans la livraison.

      Un process facile a mettre en place? Un JIRA -> un test. Si le développeur n’a pas écrit le test, il n’a pas le droit de livrer.

      Je parle en tant que développeur. J’essaie de toujours valider mon travail, au moins par des tests unitaires, d’integration ou d’acceptance. Je fais ça pour éviter de faire perdre son temps au recetteur mais aussi pour moi, pour valider que ce que je développe marche sans avoir a lancer un serveur Websphere pendant 10 minutes, et pour faciliter le refactoring.
      Mais ca n’empeche pas qu’a la fin il y a toujours un recetteur qui passe derrière moi.
      Et je trouverait ça aberrant que le recetteur laisse passer mes correctifs dans la livraison sans même les vérifier!

      Un CDP qui fait confiance a ses développeurs et qui ne planifie aucune recette sur les anomalies? Non mais alloooo quoi
      Il n’y a aucune confiance a accorder au développeur, même si il travaille 90% du temps correctement vous devez recetter… Si vous commencez a faire confiance aux développeurs sans vérifier son travail, ne vous étonnez pas quand le développeur prends confiance dans le code qu’il écrit et vous le livre sans le tester: c’est exactement la même chose.

      J’admet qu’en certaines périodes de forte charge (beaucoup de bugs ouverts par exemple), il m’arrive de parfois envoyer mon code de bugs triviaux sans vraiment les tester. En effet je compte justement sur le recetteur pour effectuer cette tache afin de gagner du temps pour la correction d’autres bugs plus importants.
      Mais dans ce cas la mon message est « tiens regarde ça devrait marcher maintenant » -> le recetteur comprends bien qu’il doit tester.

      Répondre
      • On rentre dans des considérations techniques, ce n’était pas le but de l’article mais merci pour ces retours :-).

        Je me trompe peut-être mais l’automatisation des tests peut également contenir des erreurs … Quand c’est un projet de 2 ou 3 mois, cela me paraît un peu juste pour avoir complètement confiance dans le process, pour être sûr que ce soit rôdé .. surtout si la personne qui l’a mis en place découvrait la techno pendant le projet .. oui parce que ça arrive, parce qu’on n’a pas le choix de la personne .. qu’on ne me dise pas que ça n’arrive jamais ou que ça ne « devrait » pas arriver .. c’est déjà arrivé ..

        Effectivement, le contexte peut jouer dans la qualité des développements, et la pression, la précipitation et le stress font que tout le monde fait des erreurs, seulement certains en ont conscience et re-vérifient ou demandent à faire vérifier comme tu l’indiques, et d’autres non.

        Répondre
    • On s’éloigne du sujet mais bon ..

      Et si le client ne veut pas payer pour des tests automatisés ? et si les équipes sont junior et ne savent pas en mettre en place ?

      Merci pour ce « feedback », je n’aimerais pas vous avoir comme manager 😉

      Répondre
      • En même temps c’est peut-être un peu le problème: les CDP et managers ne comprennent pas que bien tester et automatiser ça fait gagner du temps et ça coûte pas plus cher au final.
        Tu n’as même pas a demander au client: ça doit faire parti de ta méthodologie.
        Tu demandes l’autorisation au client pour faire une recette toi? Tu demandes au client pour faire un test unitaire?
        Bah t’as pas non plus a demander au client pour une recette automatisée.

        Ok il peut y avoir des erreurs mais elles seront remontées par des bugs et tu corrigeras alors ta recette automatisée jusqu’a ce qu’elle soit parfaite ou presque.
        Tu verras que le maigre investissement initial sera trèèèès rapidement rentabilisé.

        C’est a toi de savoir faire remonter a tes supérieurs la stratégie a adapter pour être plus efficace et plus rentable.
        Quitte a demander pendant quelques temps un ingé supplémentaire qui ne sera pas facturé au client: tu perdras 30k au début mais tu en gagneras 30 à chaque recette.

        Exemple tu développez une API, voila le genre de trucs qu’on peut faire aujourd’hui:
        http://2011.arrrrcamp.be/videos/anthony-eden/build-and-test-apis-with-ruby-and-cucumber/

        Toute façon la problématique des tests automatisés est et restera toujours la même: on préfère gagner plus d’argent pendant 6 mois et en perdre pendant 10 ans plutôt que l’inverse… Et c’est normal car le manager qui s’en met plein les poches avec ses commissions va peut-être démissionner dans les 6 mois alors il faut qu’il en profite maintenant et laisse la merde derrière lui 🙂 On fait du quickfix dans tous les sens et on ne refactor jamais etc. Vive la rustine.

        Mettre que du juniors sur un projet c’est voué à l’échec depuis le début.

        « Et si nos devs ne savent pas développer? »
        -> Bin faut pas s’étonner alors si vous prenez des mecs a 30k sur Paris… Les bons devs ont une tête bien faite et savent ce qu’ils valent. Un bon dev ca se paie 45-50k pour 3 ou 4 ans d’expérience. Et la je parle pas du dev star qui a plein de projets populaires sur github mais du bon dev lambda.
        Chez Twitter Facebook et autres les salaires moyens de devs sont de 120k$/an: au dessus de ceux de leurs managers.

        Répondre
        • Ah mais Sébastien, tu prêches un convaincu avec les tests automatisés, ce n’est pas la question et je ne suis de toute façon pas compétent techniquement en la matière.

          On peut toujours essayer de changer le système, c’est du travail de fond, on gagne certaines batailles, on en perd d’autres. C’est du moyen long terme. Dire et faire en sorte qu’on va embaucher à un niveau de salaire 50% supérieur ça prend du temps … et puis, cela a un impact du coup, faudrait essayer d’aligner un peu tout le monde sur ce niveau de salaire parce que sinon ça va vite fiche la grouille mais bon faut du budget et du coup faudrait vendre plus cher mais bon on a déjà du mal à gagner des projets avec une marge correcte alors .. 🙂 . Faire bosser un ingé sans le facturer ? tu n’y penses pas ! 🙂

          Enfin t’as l’air de connaître .. et comme tu le dis très bien, la vision court-termiste l’emporte généralement parce que l’objectif à atteindre il est dans quelques mois et l’investissement à long terme il est généralement réduit ou alors il se fait en sous-marin ..

          La question c’est comment faire en attendant ?

          En attendant, il faut faire avec ce qu’on a sur le moment surtout quand on reprend un projet. Après pour un chef de projet il y a beaucoup à apprendre dans ce genre de contextes (jusqu’à un certain point .. ). Car si tout le monde fait son boulot correctement, en temps et en heure, que techniquement tout roule, que tout le monde est augmenté, que le client est heureux, un chef de projet s’ennuie vite et n’apprend pas grand chose :-).

          Répondre
  8. J’ai l’avantage d’être un gestionnaire de projet, mais je suis en provenance des TI, donc j’ai été concepteur et j’ai été programmeur senior.

    J’ai toujours la manie que regarder les logs SVN quand je gère un projet, c’est fou le nombre de choses qu’on peut apercevoir et qu’on ne devrait pas voir passer quand on est dans ce genre de situation. C’est là que je me dis qu’un gestionnaire en provenance des ressources humaines manque une très grande majorité des informations qui évitent cette situation.

    Répondre
  9. Salut,
    je trouve que cette discussion est intéressante.
    Tant que développeur, je travaille dans ce domaine par passion avant tout
    et je fait face à ces problèmes tous les jours et j’arrive à s’en sortir +/- gagnante !
    en fait, ce qui me pose un problème c’est comment se motiver pour se-corriger soi-même et être à la hauteur des attentes de mon chef ?????

    Répondre
    • Je pense que pour qu’un développeur fasse bien son boulot, il faut en partie que le chef de projet fasse bien le sien aussi et définisse bien ses attentes.

      Me concernant, pour un bug à corriger, si je peux reproduire facilement, j’attends du développeur que quand il me dit que ça marche, ça marche ! en lui ayant bien sûr fourni les infos pour reproduire, si on lui dit simplement « ça ne marche pas », c’est un peu juste ..

      Pour du développement de manière générale, j’attends d’un développeur que ça fonctionne de manière fiable, c’est à dire que quoi que je fasse (cliquer n’importe où, combinaison de touches, mauvaises données en entrée, …) ça fonctionne et intercepte les erreurs proprement. Un développeur sécurise le fonctionnement pour l’utilisateur lambda.

      Pour la partie plus fonctionnelle, j’attends d’un développeur qu’il suive les spécifications et qu’il me dise s’il manque des cas, si ce n’est pas complet, s’il y a des erreurs, des incohérences, … Et si vraiment le niveau est mauvais, un développeur peut recadrer aussi le rédacteur comme un chef de projet peut recadrer un développeur.

      Après, développeur c’est pas un métier facile, les bugs ça arrive, les conditions pour reproduire sont pas forcément faciles à identifier (le fameux « chez moi ça marche » mais pas chez l’autre) donc un peu de patience de tous les côtés facilite les choses ..

      Cela ne reste que mon avis, le plus simple est de prendre 15 minutes et demander à votre chef de vous répondre :-).

      Cela vous aide-t-il ?

      JP

      Répondre
  10. C’est la responsabilité du chef de contrôler. C’est lui qui est responsable et il est payé en conséquence, c’est à dire plus que les grouillos sous ses ordres. Une fois qu’on a bien aidé le chef sur son projet celui-ci fini par évoluer dans la hiérarchie et le grouillo se fait licencier pour refus de mission à l’autre bout de la France…

    Répondre
  11. Salut, j’ai du mal a trouver de l’info de la part de porteurs de projets ou de cdp par rapport aux dev.
    J’ai perdu 2 acomptes et bcp de dev (freelances) abandonnent les projets que je leur confie.
    J’ai également eu le coup des bugs soit disant fixés qui en réalité ne le sont pas et moi qui teste avec patience 4 fois la même chose.
    Mais si ce n’etait que cette histoire de bug « fixé » mais non vérifié par le dev, ca irait.
    Moi ce qui me gave ce sont les dev qui donnent un délais de 2 mois et qui au bout de 5 n’ont pas fini et commence a se faire beaucoup plus discret par email et autre.
    Qui a des ressources en frnacais ou anglais pour sélectionner et manager un bon dev freelance sans perdre son temps SVP ?
    merci

    Répondre

Laisser un commentaire