Discussion :

[Geralds]

Bonsoir à tous,

Je développe seul depuis 3 mois une grosse application de gestion interne (stocks, clients, devis, etc.) pour un client qui avait des besoins très très spécifiques, le développeur maison n'ayant pas le temps de s'en occuper. Mes développements sont basés sur le Zend framework. Ils possèdent une quinzaine d'outils plus ou moins complexes développés en interne et écrits en PHP procédural, que mon application doit remplacer. Voilà pour le contexte.

Mon problème avec ce client : je me heurte régulièrement à son mécontentement. Il me reproche de travailler moins vite que son développeur qui, selon lui, peut intégrer rapidement des modifications dans les outils actuels. J'ai beau lui expliquer que l'outil qu'il me demande de développer n'a absolument rien à voir avec ceux qui existent (on est très très loin en terme de fonctionnalités), que la plupart des modifications dont il a l'habitude sont plutôt du genre "rustine" temporaire, avec beaucoup de code redondant et très peu de contrôles sur les saisies (mais bon je veux pas trop allumer son développeur) ... il persiste. Il ne veut pas non plus comprendre que certaines de ses demandes de dernière minutes m'obligent parfois à remettre en question un certain nombre de choses pour ne pas se retrouver au final avec un outil difficile à maintenir. C'est d'ailleurs un autre point de divergence : il me reproche d'avoir écrit un programme trop compliqué à comprendre pour son développeur (effectivement on passe de PHP procédural à du full Objet, avec du Zend, des centaines de fichiers, une grosse base de données où tout est normalisé), et voudrait quelque chose d'aussi "simple" que ce qu'il a mais en "mieux".

J'avoue que je ne sais plus comment lui expliquer que ce n'est pas possible, qu'il y a un monde entre l'existant et le projet en cours, et qu'il faut se faire à l'idée que ce sera forcément plus complexe.

Que feriez-vous à ma place ?

[Jean-Philippe André]

Salut,

une bonne façon de voir les choses est de faire un bilan de l'outil existant, et de réaliser un cahier des charges des évolutions souhaitées. Tu blindes les objectifs à atteindre d'une part, tu lui "imposes" un GO/NO GO pour les changements à effectuer.

Le "mieux en moins de temps", c'est une constante dans les changements de développeurs. L'élément à faire valoir est le "plus complet" ou "plus robuste" de ton développement.

Question toutefois, quel est ton statut vis à vis de lui ? Es-tu en intervention chez lui ou bien télétravailleur ?

Ma logique pour ces clients là, c'est de faire le gros dos, et de faire ce qu'il souhaite, même si ce n'est pas la "bonne" méthode ou que l'appli n'est pas idéale.

[Mat.M]

J'avoue que je ne sais plus comment lui expliquer que ce n'est pas possible, qu'il y a un monde entre l'existant et le projet en cours, et qu'il faut se faire à l'idée que ce sera forcément plus complexe.

Que feriez-vous à ma place ?

ne pas s'inquiéter je travaille sur ce genre de projet.
Il faut mettre dans le crâne des gens qui veulent développer un projet en codant aussi vite qu'on respire que le projet coûtera financièrement le double au minimum parce qu'un projet sans analyse, développé avec "les pieds" en un temps minimum c'est pas du tout réutilisable, le code est difficilement maintenable donc une fois le projet en production ça entraîne une maintenance énorme ; et par conséquent que les programmeurs qui ont fait le projet vont passer un temps fou à déboguer ; ou bien à mettre beaucoup de temps à modifier le code lorsqu'il s'agira de faire évoluer le progiciel en rajoutant des fonctionnalités.

que la plupart des modifications dont il a l'habitude sont plutôt du genre "rustine" temporaire, avec beaucoup de code redondant et très peu de contrôles sur les saisies (mais bon je veux pas trop allumer son développeur) ... il persiste.

mettre des rustines c'est une solution à court terme ; mais sur le long terme le projet sera totalement bancal, totalement hétérogène donc difficilement maintenable et difficilement évolutif
D'où des coûts financiers en maintenance élevés

[phili_b]

Il me reproche de travailler moins vite que son développeur qui, selon lui, peut intégrer rapidement des modifications dans les outils actuels. J'ai beau lui expliquer que l'outil qu'il me demande de développer n'a absolument rien à voir avec ceux qui existent.

Mouais je me souviens d'un entretien où j'ai été refusé car on me disait que pour ce poste de développeur, en Delphi, il fallait savoir développer rapidement c'est-à-dire à l'arrache. Je reformule à peine leurs propos.

C'est d'ailleurs un autre point de divergence : il me reproche d'avoir écrit un programme trop compliqué à comprendre pour son développeur (effectivement on passe de PHP procédural à du full Objet, avec du Zend, des centaines de fichiers, une grosse base de données où tout est normalisé), et voudrait quelque chose d'aussi "simple" que ce qu'il a mais en "mieux".

Nan mais là c'est n'importe quoi. J'ai fait du Delphi jusqu'en 2003, et je me suis mis au php l'été dernier, en continuant toujours à programmer un peu pendant que je faisais de la BI, et si je n'ai pas acquis le niveau pour créer un logiciel POO ni Zend, en revanche de lire un source, de le comprendre et de le maintenir est toujours possible avec une formation adéquate, surtout si leur développeur connait déjà le php depuis des années. Donc leur développeur interne php doit pouvoir faire en théorie la maintenance au moins. Par contre continuer le développement c'est une autre paire de manche s'il n'a pas ces 2 compétences.

Je ne serais pas surpris que ton client soit quand même un peu le porte-parole du développeur interne php qui prend peur.

Mais il y a un truc que je ne comprends pas. Le principal sujet c'est le périmètre et les délais. Tu as annoncé des délais ? Dans les 3 mois que tu as fait tu es proche de la livraison ou pas ? Ou alors c'est prévu pour durer un an mais tu dérapes sur tes premiers jalons ? C'est toi qui a chiffré ? Ou alors le client l'a fait mais pour du php procédural au kilomètre ?

Ou alors tu auras fini quand tu auras fini et ton client a l'impression d'être victime d'un effet tunnel ?

Au bout du compte:
- tout va s'arranger car tu vas leur annoncer que c'est conforme en terme de délai et fonctionnalité ?
- ils veulent ta peau car ils ont l'impression que tu n'avances pas et que ça ne sera pas maintenable en interne ?
- ou alors tu es complétement hors délai et là ils ont raison ? (mais encore faut-il que les charges aient été bien fixées au départ).

[el_slapper]

Impossible de se faire une idée précise avec juste un point de vue. En gros, par contre, je sens une lutte de pouvoir. Exemples de possibilités (qui peuvent être toutes vraies, ou toutes fausses, ou partiellement):

_le gars qui te gueule dessus a promis monts et merveilles à la direction pour se faire mousser, et a peur de passer pour un clown.
_le développeur interne a les jetons parcequ'il se sent soudainement moins indispensable, et il grenouille pour te faire discréditer et retrouver sa position de pouvoir.
_le big boss demande à la hiérarchie intermédiaire de faire des économies, ou de mettre la pression.
_le développeur interne est un flambeur qui arrive à faire passer des petits trucs pour des évolutions de fou.
_le client a eu plus grands yeux que grand ventre, et essaye de te faire porter le chapeau.
_Tu as du mal à développer rapidement.(bon; d'accord, ça n'est pas politique; mais c'est une possibilité aussi). Ou alors, tu ne sais pas communiquer sur tes succès(l'effet tunnel évoqué plus haut).

impossible pour nous, de loin, de valider ou d'invalider toutes ces possibilités

[Geralds]

Merci pour vos réactions.

Je travaille à distance pour ce client (géographiquement il n'est qu'à 10 mn en voiture :-) ), on se rencontre toutes les semaines. Ce qui se passe je pense, c'est qu'il ne se rendent pas compte de la complexité qu'impliquent certaines de leurs demandes. Forcément, mon application n'a pas d'équivalent dans leurs outils actuels pour beaucoup de fonctionnalités. C'est difficile de donner un exemple car c'est une activité spécifique avec des produits spécifiques, avec des processus de gestion un peu tordus aussi mais, que je comprends et que je dois intégrer.
Pour donner un ordre d'idée : il se peut que là où ils se contentent actuellement d'ajouter une case à cocher dans un formulaire, je sois de mon côté obligé de créer une table, de nouvelles liaisons, mettre à jour des modèles, reprendre mes formulaires voire créer de nouveaux éléments personnalisés, réécrire des requêtes AJAX, mettre à jour les contrôles d'accès, etc. C'est une autre manière de travailler, leurs outils actuels génèrent trop d'erreurs, sont peu sécurisés, pas du tout conviviaux ...

Alors forcément en terme de délais je suis toujours à la ramasse parce que le délai que j'indique est obsolète aussitôt qu'on me demande de modifier quelque chose que je n'ai même pas encore finalisé. En gros, effectivement, je finirai quand je finirai si on peut dire.

@phili_b : je suis plutôt dans le cas "ils veulent ta peau car ils ont l'impression que tu n'avances pas et que ça ne sera pas maintenable en interne". Pourtant la liste des fonctionnalités s'allonge, comme les demandes et/ou contraintes, et répond aux besoins exprimés. C'est le paradoxe : je ne termine pas parce qu'on ne me laisse pas terminer.

@el_slapper : je ne pense pas qu'il y ait de réelle volonté de m'évincer (tout au plus un peu les jetons), surtout que je ne suis que de passage. D'ailleurs la qualité (ou selon les jours la complexité :-) ) de mon travail est reconnue. Je ne dois probablement pas communiquer assez bien sur mes succès. C'est sur ce point que j'ai besoin de conseils et sur la manière de faire comprendre à quelqu'un qui s'obstine qu'à un certain niveau de fonctionnalité correspond un certain niveau de complexité.

[el_slapper]

(.../...)C'est une autre manière de travailler, leurs outils actuels génèrent trop d'erreurs, sont peu sécurisés, pas du tout conviviaux ...

Voilà ton point fort : tu dois indiquer, clairement, systématiquement, à chaque livraison, toutes les petites astuces que tu as mis en place pour leur faciliter la vie. La mauvaise nouvelle : ils ne te donneront aucun budget supplémentaire pour les faire. La bonne nouvelle : ils vont adorer ça - si ils s'en rendent compte.

Alors forcément en terme de délais je suis toujours à la ramasse parce que le délai que j'indique est obsolète aussitôt qu'on me demande de modifier quelque chose que je n'ai même pas encore finalisé. En gros, effectivement, je finirai quand je finirai si on peut dire.

Question à cent balles : QUI décide des délais? Du périmètre?

@phili_b : je suis plutôt dans le cas "ils veulent ta peau car ils ont l'impression que tu n'avances pas et que ça ne sera pas maintenable en interne". Pourtant la liste des fonctionnalités s'allonge, comme les demandes et/ou contraintes, et répond aux besoins exprimés. C'est le paradoxe : je ne termine pas parce qu'on ne me laisse pas terminer.

Le paradoxe, c'est que tu vas devoir perdre du temps à te justifier(ça me fait toujours râler, moi aussi). Mais si tu listes de manière exhaustive tout ce qui a été ajouté, ça devrait t'enlever un peu de pression. Tu dois te garder de l'effet iceberg. Ce que tu développes est pour l'essentiel sous l'eau, mais personne ne le voit.

@el_slapper : je ne pense pas qu'il y ait de réelle volonté de m'évincer (tout au plus un peu les jetons), surtout que je ne suis que de passage. D'ailleurs la qualité (ou selon les jours la complexité :-) ) de mon travail est reconnue. Je ne dois probablement pas communiquer assez bien sur mes succès. C'est sur ce point que j'ai besoin de conseils et sur la manière de faire comprendre à quelqu'un qui s'obstine qu'à un certain niveau de fonctionnalité correspond un certain niveau de complexité.

exemple(qui date, mais on va faire comme si c'était hier) de communication de ma part :

"En raison des nombreux incidents sur les rattrapages, j'ai développé un tableur de controle. Il permet de saisir facilement l'ensemble des données pertinentes au rattrapage, et possède de nombreux controles internes :
_vérification de la longueur du code banque, du code agence, du numéro de compte, et de la validité du code banque
_liste déroulante comprenant l'intégralité des opérations possibles. Celà permet même de faire des annulations
_liste déroulante des catégories de produit, activant la liste déroulante des produits possible.
_saisie controlée des montants et des quantités
_saisie des UC seulement sur les produits concernés - avec controle du montant et affichage du pourcentage.
_Validation possible seulement si toutes les données sont OK
_référentiel des opérations et des produits sur les onglets annexes
_génération automatique, sous controle de la MOE, des binaires de rattrapage à injecter"

ça représente 10 heures de boulot. Si j'avais dit "j'ai fait une grille de saisie" sans autre forme de procès, j'aurais été flambé. En listant les features développées, j'ai fait prendre conscience aux gens du travail effectué.

[phili_b]

Alors forcément en terme de délais je suis toujours à la ramasse parce que le délai que j'indique est obsolète aussitôt qu'on me demande de modifier quelque chose que je n'ai même pas encore finalisé.

A mon avis, d'une part tu dois plus communiquer sur l'avancement de projet, sur les jalons, et d'autre part, ne pas accepter de modifier tout le temps le cahier des charges. Autant il faut être souple et accepter les changement de cap de 10%, autant il ne faut pas accepter les brusques coup de volant tout le temps. S'ils veulent rajouter trop de choses non prévues, tu leur dis que ça sera en version 2.

En gros, effectivement, je finirai quand je finirai si on peut dire.

Oui mais là y'a un souci. Si j'étais client ça me ferait vraiment peur même tu étais Linus Torvalds ou John Romero. Autant pour un projet solo on peut éviter 75% de la bureaucratie des gros projets, mais il faut quand même que tu annonces des délais.

Et pour ta case à cocher ben tu la refuses et tu la remets à plus tard.

Même dans les assistances techniques que j'ai fait, c'est-à-dire non contractuellement forfaité, je devais m'engager sur une durée et un délai au minimum à la louche. Est-ce que tu as des versions béta ou des parties du projet qui sont utilisables pour montrer que tu avances ?

Pour moi tu as raison de vouloir développer tout cela de façon propre et dans les règles de l'art, mais là tu risques d'aller dans le mur car le souci n'est pas technique mais sur la conduite de projet. Ou bien il faut que tu gères davantage la conduite de projet, mais ça va te bouffer du temps, ou bien il faut qu'il y ait un pilote de projet qui t'aide. A moins que tu arrives toi même à donner des délais et à geler pendant un temps le périmètre.

Dans combien de temps est censé se finir le projet ? Dans 3 mois ? Dans 6 mois ? Dans un an ? Si tu ne sais pas répondre à cette question, au moins à la louche, en tant que client je serais très inquiet. Même si je rajoute des choses. A toi de me dire que ce n'est pas possible. Ou alors tu dis que c'est dans n mois pour CE périmètre.

edit:
Et dans l'absolu pour l'instant, même si ce n'est pas propre, mets toi à leur place, ils préfèrent compte-tenu de l'avancement avoir un site en php procédural pour un délai connu et pas trop lointain, qu'un site fait au petits oignons en POO et Zend dans un délai inconnu. Il faut donc que tu les rassures, que le temps "perdu" maintenant sera gagné plus tard par sa maintenabilité et son évolutivité.

[Geralds]

La deadline, toujours trop proche, est décidée par la direction. Les délais sont estimés par moi-même et me semblent réalistes au moment où je les annonce. Entre temps ...

Ton exemple est très intéressant. Je fais exactement le contraire , un peu obligé je dois dire car la direction n'est pas très réceptive lorsque je rentre dans les détails. Du coup je dis souvent "j'ai fait une grille de saisie" et je montre comment ça fonctionne. Peut-être que je dois insister ...

[Geralds]

@phili_b : je suis en mesure de leur communiquer des délais. Mais ces délais changent parce qu'entre temps on m'a demandé autre chose.
Tu as raison sur la conduite du projet, je dois tout simplement faire preuve de plus de fermeté et refuser des choses sinon on me reprochera toujours ces retards. En figeant fermement les fonctionnalités, j'arriverai probablement enfin à tenir un délai que j'annonce

[el_slapper]

@phili_b : je suis en mesure de leur communiquer des délais. Mais ces délais changent parce qu'entre temps on m'a demandé autre chose.
Tu as raison sur la conduite du projet, je dois tout simplement faire preuve de plus de fermeté et refuser des choses sinon on me reprochera toujours ces retards. En figeant fermement les fonctionnalités, j'arriverai probablement enfin à tenir un délai que j'annonce

C'est donc ça le problème. C'était Phili_b qui avait raison. Je n'avais pas compris ça(donc tu peux oublier mes autres conseils...en tous cas dans ce contexte précis).

Donc, à chaque fois qu'on vient te voir pour changer la couleur de l'écran, c'est "+2jours", "+5 jours", "+10 jours". Face à un "feature creep", il faut jouer au con et ne rien accepter sans contrepartie. C'est lourdingue, mais nécéssaire. L'agile, c'est quand les 2 parties jouent le jeu. Si tu est tout seul à le faire, tu est condamné.

[Geralds]

J'ai beaucoup apprécié les conseils de chacun. el_slapper ton anecdote sur la grille de saisie était intéressante, je reproduirai
Merci à tous.

[phili_b]

Mais donc, si ce n'est pas indiscret, la deadline imposée est pour quand ?
Et toi tu estimes à combien de temps restant ? (pour le périmètre tel qu'il est connu aujourd'hui).

A la louche

[Geralds]

J'ai 1 mois pour faire ce qui m'en prendra 2 si rien ne change. Je vais faire en sorte que ça ne change pas !

[phili_b]

ok

[Johnny P.]

Moi ce que je lis c'est que votre contrat a été mal conçu à la base.
Ton patron il aurait dû t'imposer une architecture interne et te fournir un exemple ou te faire un débriefing alors que là il te raconte que son développeur pige pas le code POO , etc...

Cela sent la boîte mal géré où on fait tout à la n'importe comment.

Par ailleurs qu'il n'est pas content du fait que tu ne codes pas vite cela sent aussi le gars qui n'y connait rien programmation travailler pour un client pareille c'est énervant.