Discussion :

[FMaz]

Bonjour,

Actuellement, je dois admettre que je ne suis pas vendeur. Je suis programmeur (à mon compte). Récemment, j'ai un client qui me donne un peu de fil à retordre.

Mais je comprend: Ce client a toujours développée elle-même en php procédural avec des bases de données MySQL/MyISAM simples, ce qui lui permettait une certaine cadence de développement, mais surtout une constance dans l'avancement de son développement.

Ce client étant surchargée, j'ai recu le mandat d'un de ces projets. Dans les grandes lignes, il s'agit d'une boutique en ligne.

Donc je commence à programmer mes Objets, mes Factory, modéliser la base de données. Puis soudain, elle voit les heures augmenter, mais ne constate que bien peu de progrès "visible".

Pris de panique, on me demande d'arrêter le projet.



J'ai beau lui donner des arguments, rien à faire: C'est trop long, et les craintes que je dépasse son budget ou les échéances (que j'ai toutes deux acceptés pourtant) deviennent trop grandes.


Exemple d'arguments/réponses:

L'orienté objet est plus facile à maintenir:
- Je n'ai pas de problème à maintenir mes autres sites

La gestion des erreurs est meilleure:
- PHP log les erreurs de mes autre sites.

Le code sera testable unitairement
- J'ai jamais eu besoin de ca

La base de données supportera les transactions et l'intégrité référentielle, ce qui donnera une boutique beaucoup plus sécuritaire.
- Sur mes autres sites, j'ai des "statut" (?) qui m'indique ce qui s'est mal passé.

L'orienté objet c'est comme la peinture: c'est plus long de poser le ruban-masque, et pendant qu'on pose ca, la peinture avance pas, mais après l'application de la peinture est plus rapide.
- Ca la convaincu une fois, mais le projet à été interrompu une seconde fois.

Le code sera en grande partie ré-utilisable pour de futur projet.
- Ca n'appaise en rien ses inquiétude pour le projet actuel.



... donc comme vous pouvez vous imaginez, je passe presqu'autant de temps à la rassurer qu'à avancer. Ce qui n'est pas pour aider.

Là je viens de simplement lui dire quelque chose dans la veine de:
"Vous recherchiez un programmeur d'expérience, ce n'est pas mon premier projet et je sais où je m'en vais. Je suis en mesure de respecter les budgets et les échéanciers, à condition que vous n'interrompiez pas le projet sans arrêt."




Bref, comment faites-vous pour gérer des clients qui:
- ont assez de rudiment pour saisir le langage PHP et s'intéresser à l'avancement technique
- n'ont pas assez de connaissances pour bien comprendre les fondements de l'orienté objet pour les projets ayant une certaine ampleur, et qui en reviennent toujours à comparer avec le procédural.


Merci pour vos commentaires et suggestions, car je commence vraiment à trouver mon travail de plus en plus frustrant et désagréable.

[sabotage]

Elle a cependant raison sur une partie : puisqu'elle n'a pas de compétences suffisante, elle ne pourra pas maintenir elle même ton application.

[FMaz]

C'est un point, sauf que cette personne fait appels à plusieurs sous-traitants.
Et on parle d'un site transactionnel, qui sera assurément attaqué.

As mon avis lorsqu'il s'agit de la sécurité financière des autres, il n'y a pas place à négociation. Déjà que j'ai du oublier les tests unitaires...

Je n'ai jamais caché vouloir y aller par objet. Donc si la personne voulait faire de l'auto-maintenance, ca aurait du ressortir avant même le début du mandat.

----

Et ouais, j'ai vraiment l'impression qu'il y a un sévère manque de confiance au niveau des prévisions budgétaires.

[Mr N.]

Donc je commence à programmer mes Objets, mes Factory, modéliser la base de données. Puis soudain, elle voit les heures augmenter, mais ne constate que bien peu de progrès "visible".

A mon avis, tout est dit. A toi de modifier ton développement pour montrer que ça avance. Fixe-toi des itérations de 2, 3 semaines et montre les nouvelles fonctionnalités apportées à ton client à la fin de chaque itération. Si ton client a de la visibilité sur ton avancement alors il aura confiance et alors importera moins la méthode de développement, objet ou procédural...

Un peu de lecture: http://agilemanifesto.org/principles.html

[FMaz]

Tu as tout à fait raison. Et c'est ce que j'essaie de faire. Mais en même temps j'ai même pas encore les maquettes de design...

Mais s'en est rendu à un point ridicule: Hier j'ai du donner 2 compte rendu sur mon avancements. Le deuxième après seulement 54 minutes de travail "compté" du premier.

Alors vous imaginez bien que dès que j'arrive devant un "gros" morceau abstrait, exemple: modéliser et créer l'objet "Produit", ca fait un bloc de temps que le client ne comprend pas: ca n'avance pas.

Mais là tu travaille sur quelle page ? Visiblement aucune ... Moi cette page la elle m'aurais pris 2h à faire, et depuis 3h tu n'a rien fait.

Bref, je crois que c'est un cas désespéré. Heureusement que j'ai d'autres clients un peu plus confiant.


Note:
Ouep, je connais le développement AGILE, j'ai aussi fait un atelier SCRUM... Deux chose que le développeur connais et que le gestionnaire ignore totalement. dommage.
Dire que je suis plus de 40% en avance sur ma SFT (Structure de Fractionnement des Travaux, je sais pas si vous utilisez cet outil de gestion en France)... Vu comment tourne les choses, je vais probablement perdre le projet, que j'aurais terminé bien en dessous du budget. C'est beau la vie.

[marcha]

L'objet ? Un tank pour tuer une mouche. Allez trouver un tank au
prix d'un tape mouche :-)

C'est une manière de voir les choses et je peux comprendre ta cliente.

Je pense que pour justifier l'utilisation de la POO, il faut qu'il y aie un réel
besoin de POO, et pour moi cela signifie entre autres:

1) Plusieurs programmeurs qui travaillent en coopération (la POO aide à
séparer les choses et limiter les risques)

2) Une stratégie de modélisation qui vise à réutiliser du code dans d'autre
projet.

3) La nécessité (et non la possibilité) de faire des tests unitaires.

Faire de la POO parce que la POO est potentiellement plus robuste n'est
pas un argument économiquement défendable pour un projet.

[ABCIWEB]

Si tu as accepté son budget et ses délais... ta méthode de développement ne devrait pas être un problème côté client si ce n'était pas explicitement prévu dans le cahier des charges.

Il y a peut-être une raison cachée : peut-être voulait-elle pouvoir mettre le nez dans le code pour des évolutions futures et elle comprend qu'elle ne pourra plus le faire...

Sinon, c'est apparemment plus un problème de confiance que de technique. A mon avis ce n'est pas le mode objet qu'il faut appuyer mais ta capacité à mener ce projet à bien dans les délais impartis.