Des conseils pour chiffrer dans une mission au forfait ?

Salut tout le monde!

J'aurais besoin de conseils venant de personnes expérimentés car je suis sur une mission au forfait depuis quelques mois et je galère pour donner les chiffrages suffisants.

Le chef de projet ne connaît pas très bien le projet sur lequel je travaille (voire pas du tout) et ne m'aide pas beaucoup (voire pas du tout) sur les chiffrages. Le management est en revanche très répressif au moindre dépassement.

C'est un peu pour ça que je demande des conseils ici. Je me sens livré à moi-même et je me rends bien compte que j'aurais pas d'aide de l'ESN pour monter en compétence sur comment travailler pendant une mission au forfait.

Parfois je demande des chiffrages trop élevés et le client se braque complètement et refuse de payer la tâche. Sinon le reste du temps je chiffre trop court et je dois travailler 10h-11h/jour.

J'essaie de demander de l'aide auprès de mes collègues mais ils ont également du mal à bien chiffrer. Il y a beaucoup de démissions.

Si vous avez des conseils où des retours d'expérience à me donner, n'hésitez pas. ;)

Cette mission commence un peu à me frustrer parce que techniquement je n'ai aucun problème et je n'arrête pas de speeder. Mais comme je ne demande pas assez en jour je crois que je passe pour une brêle.

De comme globalement je termine à l'heure je confirme d'une certaine manière qu'un système où le management a des failles peut fonctionner du moment que des petits jeunes acceptent de bosser comme des malades.

Salut,

Alors le chiffrage est rarement une science exacte et même avec beaucoup d'expérience tu ne feras probablement jamais de chiffrage juste. Le but c'est de faire un chiffrage assez large pour se laisser du temps pour les imprévus mais sans que ce soit abusif pour que ce soit acceptable par le client.

Citation:

---

Parfois je demande des chiffrages trop élevés et le client se braque complètement et refuse de payer la tâche. Sinon le reste du temps je chiffre trop court et je dois travailler 10h-11h/jour.

---

De ce que je comprends de cette phrase c'est que tu sais faire un chiffrage globalement juste, c'est juste que ton client n'accepte pas et par conséquent tu le diminue quitte à faire des heures sup' non rémunérés.
Pour moi ton client sait très bien ce qu'il fait, il refuse tes chiffrages pour baisser ses coûts et comme tu es encore junior , tu te laisse marcher sur les pieds. Ne t'inquiète pas, beaucoup de développeurs sont passé par ce genre de projets (moi aussi dans une certaine mesure). Pour moi la seule vraie solution, c'est de bien détailler tes chiffrages pour que tu puisse argumenter chaque tâche chiffré, si il refuse tant pis pour le client, tu ne feras pas la tâche. C'est toi qui a les mains dans le code, donc c'est toi "l'expert" sur la technique donc normalement il ne pourra pas t'opposer d'arguments (après y a des clients de mauvaise fois partout).

Après, normalement le fait de vendre les chiffrages au client ce n'est pas un travail de dév, est-ce que ce n'est pas ton chef de projet qui s'en occupe ? Si oui, n'hésite pas à faire un point avec lui pour parcourir les détails de ton chiffrage pour qu'il puisse argumenter face au client.

Citation:

---

J'essaie de demander de l'aide auprès de mes collègues mais ils ont également du mal à bien chiffrer.

---

Ils sont probablement dans le même cercle vicieux que toi.

Citation:

---

Il y a beaucoup de démissions.

---

Peu étonnant, ça ne doit pas aider la qualité du projet.
C'est un cercle vicieux :
- les personnes qui ont la connaissance du code partent à cause des conditions de travail pourris
- de nouvelles personnes arrivent et on leur demande un chiffrage sans la connaissance complète du projet
- le temps qu'ils comprennent le projet , ils se sont déjà engagé sur des délais
- ils font du travail gratuit
- Revenir à l'étape 1

Citation:

---

Le chef de projet ne connaît pas très bien le projet sur lequel je travaille (voire pas du tout) et ne m'aide pas beaucoup (voire pas du tout) sur les chiffrages. Le management est en revanche très répressif au moindre dépassement.

---

La je pense qu'il faut que tu prenne un peu de hauteur car tu es visiblement dans une entreprise où tu auras rarement du soutien. Tant que la boîte gagne de l'argent, tout vas bien pour elle.

Pose toi la question si cette mission t'apporte réellement quelque chose car travailler 10h-11h pour tenir des délais, ce n'est pas normal. Ce projet n'est pas le tiens donc diminue ta charge de travail sauf si tu le fait dans ton propre intérêt (tu te forme sur une techno que tu pourras valoriser plus tard par exemple, heures sup' compensé, etc ...).

N'hésite pas à voir avec ta boîte si elle n'as pas d'autres mission à te proposer.
Si tu as déjà acquis un ou deux ans d'expérience peut être se renseigner sur d'autres boîtes dans ton coin, pour voir quels sont tes autres options.

Je me souviens d'une regle qu'on appliquait, c'etait toujours multiplie le temps prevu par 1.7 environ. C'etait plus ou moins correct.

Pikachu-67 a parfaitement resume la situation.

Tu as combien d'annees d'experience ?

Citation:

---

Envoyé par champomy62

Je me souviens d'une règle qu'on appliquait, c'était toujours multiplie le temps prévu par 1.7 environ. C'était plus ou moins correct.

---

Pour ma part j'ai entendu 2,2. Cela prend également en compte la charge du chef de projet qui pilote ton activité.

Sinon, comme indiqué dans ton autre post @Roysköpp, non seulement tu te fais arnaquer/marcher sur les pieds, mais ta SSII aussi. Mais ça à la rigueur, elle s'en fiche, au final le plus grand gagnant ça doit être le commercial.

Un forfait ne se fait pas morceau par morceau. C'est une enveloppe globale qui se joue sur l'ensemble.
Quand je fais des chiffrages alors que je suis en mission, c'est plus pour calculer l'enveloppe budgétaire de la DSI ou de la service qui gère (qui pour le coup est souvent contente quand on gonfle, ça lui permet 1/ de pas faire des trucs qu'elle a pas envie de faire 2/ de bien caler un budget pour un projet qui pourrait être plus simple).

Donc encore une fois je trouve que ta situation est plutôt très étrange - ou alors j'ai tout faux et que j'ai toujours bossé dans des structures qui font les choses différemment. Cela pourrait expliquer les départs d'autres consultants moins junior qui trouvent ça n'importe quoi.

Et sinon... je me dis : ce serait quoi le problème si le client refuse au fur et à mesure tes chiffrages ? Tu seras pas pour autant licencié ? Ta SSII va te fouetter ? Elle n'a qu'à envoyer aussi en secours des personnes pour t'assister (c'est toujours les arguments déployés quand t'es tout seul chez un client... "t'inquiètes, t'es pas tout seul, un coup de fil et GrandMaster JavaCéPlusPlus va venir t'aider un soir")

Le coeff dépend aussi des conditions. En partant d'un "parfait si tout va bien", je multipliais par trois chez tel assureur, et par quatre chez telle banque, aux mauvaises surprises plus nombreuses. Ici, je suis à 1,5 (et je dépasse souvent, il va me falloir repenser...)

Citation:

---

S'il refuse tant pis pour le client, tu ne feras pas la tâche. C'est toi qui a les mains dans le code, donc c'est toi "l'expert" sur la technique donc normalement il ne pourra pas t'opposer d'arguments (après y a des clients de mauvaise fois partout).

---

Le problème c'est que souvent je dois commencer les tâches avant les chiffrages pour réellement comprendre ce qu'il faut faire. Les fiches ne sont pas très détaillées. Donc si j'analyse une tâche, je passe pas mal de temps dessus et en fin de compte je suis bien obligé de la prendre car j'y ai déjà passé du temps.

Citation:

---

Après, normalement le fait de vendre les chiffrages au client ce n'est pas un travail de dév, est-ce que ce n'est pas ton chef de projet qui s'en occupe ? Si oui, n'hésite pas à faire un point avec lui pour parcourir les détails de ton chiffrage pour qu'il puisse argumenter face au client.

---

Oui c'est le chef de projet qui s'en occupe et je détaille bien ce qu'il y a à faire dans les tâches mais ça ne suffit pas toujours pour que le chef de projet puisse défendre le chiffrage. Cela dit, dernièrement j'ai surtout eu des difficultés à tenir mes propres chiffrages. J'ai dû mal à voir tout ce que je dois faire dans une tâche et du coup je chiffre trop court.

Citation:

---

Pose toi la question si cette mission t'apporte réellement quelque chose car travailler 10h-11h pour tenir des délais, ce n'est pas normal. Ce projet n'est pas le tiens donc diminue ta charge de travail sauf si tu le fait dans ton propre intérêt (tu te forme sur une techno que tu pourras valoriser plus tard par exemple, heures sup' compensé, etc ...).

---

C'est pour ça que je m'accroche, cette ESN m'a permis de commencer dans le domaine qui m'intéressait. En particulier sur des technos où je n'avais pas d'expérience.

Citation:

---

Tu as combien d'annees d'experience ?

---

Je suis junior.

Citation:

---

Et sinon... je me dis : ce serait quoi le problème si le client refuse au fur et à mesure tes chiffrages ? Tu seras pas pour autant licencié ? Ta SSII va te fouetter ? Elle n'a qu'à envoyer aussi en secours des personnes pour t'assister (c'est toujours les arguments déployés quand t'es tout seul chez un client... "t'inquiètes, t'es pas tout seul, un coup de fil et GrandMaster JavaCéPlusPlus va venir t'aider un soir")

---

Si je ne fais pas l'affaire je peux quand même me faire annuler ma période d'essai et ça va me salir mon CV... C'est ça qui est injuste, un bon CV vaut de l'or donc un junior est près à faire n'importe quoi pour avoir des expériences longues avec peu de trous sur le CV.

Citation:

---

Envoyé par Röyksopp

Parfois je demande des chiffrages trop élevés et le client se braque complètement et refuse de payer la tâche. Sinon le reste du temps je chiffre trop court et je dois travailler 10h-11h/jour.

J'essaie de demander de l'aide auprès de mes collègues mais ils ont également du mal à bien chiffrer. Il y a beaucoup de démissions.

---

Est-ce que tu es en contacte avec le client pour discuter du projet et etablir le cahier des charges?

Tu avais ouvert une discussion il y a deux mois et ce n'etait pas le cas https://www.developpez.net/forums/d2...-faire-taches/


Quelle est la duree typique des projets? jours? semaines? mois? annees?
Pour combien de developpeurs?


Je dois etre la seule personne qui ne multiple pas par 2 ou 3, et obtient des estimation juste la plupart du temps. Mais c'est parce que je prends plein de petites choses de manière deliberee.
On estime combien de jours de developpement (ca demande de l'experience), puis on comptabilise que le vendredi ne compte pas comme un jour de travail (reunion et planification obligent), qu'il y a 3 semaines de vacances a prendre avant la fin de l'annee, plus 2 semaines pour ouvrir un port sur le parefeu (c'est lent par ici :\ ), et que je ne peux travailler que la moitie du temps parce que le reste est sur un second projet et de la production.
Et enfin quand on parle de livraison, on vise la date ou le projet a ete teste et livre en production (avec de vrais utilisateurs), qui est bien plus tard que la date ou le code a ete ecrit.
Le moindre projet de quelques semaines de codage a plein temps prends facilement un trimestre entier en realite.

En SSII ou consultant, c'est pas tant le temps passe au projet qui est important, mais la gestion du client.
Tout d'abord on se met d'accord sur le scope et sur le budget disponible.
Quand le projet se rapproche de la fin (en gros passé la moitie) il s'agit de s'assurer avec le client que ce qui a ete fait correspond aux attentes (cahier des charges ou besoins reels selon l'environment ;) ) et de bien faire comprendre au client que ce serait le moment de se concentrer sur les aspects les plus importants parce que l'echeance arrive a grand pas et le projet se terminera a la date prevue de maniere subite et irrémédiable... sauf renouvellement de contrat (les contrats sont souvent renouvelles quand on delivre quoi que ce soit qui satisfasse le client).

Citation:

---

Envoyé par yento

Je dois etre la seule personne qui ne multiple pas par 2 ou 3, et obtient des estimation juste la plupart du temps. Mais c'est parce que je prends plein de petites choses de manière deliberee.
On estime combien de jours de developpement (ca demande de l'experience), puis on comptabilise que le vendredi ne compte pas comme un jour de travail (reunion et planification obligent), qu'il y a 3 semaines de vacances a prendre avant la fin de l'annee, plus 2 semaines pour ouvrir un port sur le parefeu (c'est lent par ici :\ ), et que je ne peux travailler que la moitie du temps parce que le reste est sur un second projet et de la production.
Et enfin quand on parle de livraison, on vise la date ou le projet a ete teste et livre en production (avec de vrais utilisateurs), qui est bien plus tard que la date ou le code a ete ecrit.
Le moindre projet de quelques semaines de codage a plein temps prends facilement un trimestre entier en realite.

---

Alors micro-aparté, là on parle de charge et de planning. La chiffrage de la charge, c'est le nombre de jours pour réaliser la tâche, le planning comment il s'insère avec les besoins et les contraintes indépendantes (autres équipes, matériels, etc.). On peut très bien chiffrer cinq jours, si l'AMOA qui valide part en congés maternité sans remplaçant à la fin de la semaine, si les équipes de prod freezent l'environnement de production en décembre janvier le temps qu'on fasse l'arrêté comptable annuel fin d'année, on s'attendra pas à une mise en production fin octobre...

Pour la blague, j'ai bossé avec une cheffe de projet qui n'avait pas parlé du projet auprès des équipes de production, alors qu'elle gérait depuis un an. Non seulement ils n'avaient plus de créneau, mais en plus elle n'avait pas poussé la commande d'un serveur (donc la veille de la mise en production "Ha bon, il faut un serveur pour faire fonctionner ?" ce qui m'a valu mon best fou rire 2017).

C'est le rôle du chef de projet aussi de se coordonner avec les autres équipes pour que les ressources et disponibilités soient présentes, et cela permet d'exercer un chemin critique. Donc notamment du GANTT/PERT, ou autre méthode plus moderne ou efficiente. Suis pas CP, mais depuis 10 ans je pense pas que les autres CP promus par Peters savent également ce que c'est :mouarf:

Cela dit, vu comment @Royksöpp parle de sa SSII et de son chef de projet, j'ai l'impression que c'est sous-entendu qu'il gère aussi bien le chiffrage que le planning. Chef de lui-même quoi. Alors que, puisqu'il a un CP, son rôle c'est juste de chiffrer le RTU, Réalisation et Tests Unitaires, éventuellement compléter de la doc, et son CP de caler tout ça.

Citation:

---

Envoyé par yento

En SSII ou consultant, c'est pas tant le temps passe au projet qui est important, mais la gestion du client.
Tout d'abord on se met d'accord sur le scope et sur le budget disponible.
Quand le projet se rapproche de la fin (en gros passé la moitie) il s'agit de s'assurer avec le client que ce qui a ete fait correspond aux attentes (cahier des charges ou besoins reels selon l'environment ;) ) et de bien faire comprendre au client que ce serait le moment de se concentrer sur les aspects les plus importants parce que l'echeance arrive a grand pas et le projet se terminera a la date prevue de maniere subite et irrémédiable... sauf renouvellement de contrat (les contrats sont souvent renouvelles quand on delivre quoi que ce soit qui satisfasse le client).

---

C'est le plus important. Mais ça, Royksöpp le comprendra, une fois la fin de mission finie et digéré, et grâce à dieu, d'autres missions où il pourra comparer. En attendant le plus important est qu'il monte en compétence en dev, et en parallèle subisse et contre-attaque.

C'est pour ça que je pense que la SSII s'est bien gavée : c'est flou, c'est un forfait, c'est une régie, c'est une régie forfaitisée ou forfait régifié, un centre de compétences ou de service, whatever. Mais là où il émet des lacunes et un besoin qu'on le supporte, la SSII n'a pas l'air de bouger son cul. Donc certainement qu'elle n'a pas forcément envie de capitaliser sur le client, et si le projet capote, une raison de plus pour pas l'augmenter dans un an.

Concernant ton cahier des charges, c'est bien quand il est défini. Mais il sera invariablement discuté sur la fin, de toute façon c'est le client qui paie. Donc s'il veut un gros bouton rouge qui fait du calcul actuariel la veille de la MEP, souvent la SSII baisse son froc (et à défaut, ceux de ses employés). Ma compagne bosse pour des petits projets web, les agences intermédiaires font des cahiers des charges post-it, le client veut rajouter un truc pendant la phase de recette, ma compagne veut rajouter ça sur le devis, le client dit qu'il paiera pas de toute manière s'il a pas ça gratis. On fait comment ? Le temps de monter ça en juridique et tout, faut bien qu'on gagne de quoi manger le lendemain...

Personnellement je ne m'engage pas sur un projet sans cahier des charges. Ca peut etre une seule page pour decrire l'objectif du projet et les livrables et les contraintes.

Si le client refuse de payer et veut un gros bouton rouge la veille de la mise en production, c'est clairement que quelque chose a foire avant (ou que le client n'est pas raisonable), sinon il n'y aurait pas de modifications en heures sup le dernier jour.

On en revient a l'importance d'avoir une discussion solide au depart (la phase de "cahier des charges") et de rencontrer regulierement le client. Ca evite ce genre de surprises de derniere minute.

De mon experience, la grosse catastrophe qui tue les projets et le morale, c'est quand il y a erreur d'un ordre de grandeur. On a un mois mais il faudrait bien une annee complete. Ce type d'erreur n'arrive plus quand on a suffisamment d'experience et qu'on discute avec le client en amont.
Le reste est negotiable en cour de route. Si on est court, on fait un peu plus d'effort pour identifier ce qui est vraiment important et le mettre en avant, ca passe.
Ce qui m'a peut etre surpris le plus en debut de carriere, c'est qu'il ne faut pas necesairement grand choses pour satisfaire un client. Les autres developeurs/SSII ne font pas mieux et pas plus vite. Le client a souvent l'experience de projets entiers qui ont ete abandonnes sans resultats.

> les agences intermédiaires

Ca veut dire que ta compagne n'est pas en contact avec le client? Elle etait presente quand le cahier des charges a été rédigé avec le client?
Je pense que ca rejoint le probleme de Röyksopp. Il est responsable du projet mais seulement quand il s'agit de qui doit faire les heures sups. Il doit donner un delai mais il ne peut pas rencontrer le client et ses estimations sont refusees sans explications par la SSII (le chef de projet dit que le client a refuse mais est-ce que c'est vrai et qu'il a vraiment essayé de defendre la facturation?).

Enfin bref, toutes ces problematiques d'estimations n'ont pas lieu d'etre en tant que simple developpeur de SSII. On est paye un salaire fixe, sans aucun lien avec le client ou le projet, la SSII a un service juridique pour etablir les contrats et poursuivre le client si necessaire. Il n'y a aucun raison pour faire des heures sup.

> Donc certainement qu'elle n'a pas forcément envie de capitaliser sur le client, et si le projet capote, une raison de plus pour pas l'augmenter dans un an.

Je vois pas en quoi le projet capote? Pour moi, son projet est un succes total pour la SSII.
La SSII facture le client et a un employe qui se demene 10+ heures par jour soir et week end pour realiser l'impossible. C'est tout benef.

Dans les faits, je suis plus que 300% d'accord avec toi yento. La base, c'est le cahier des charges, ce qui est en dehors n'a pas lieu d'être, sinon tu commandes une allumette et tu exiges d'avoir une fusée.

Mais je ne suis pas dans cette situation, et apparemment ça se présente souvent sur des développeurs web qui se lancent dans une activité, sans trop de connaissance. On parle souvent de "développeurs super-stars, vous vous faites des couilles en or, vous êtes malin vous gérez trois clients en même temps" mais dans les faits, j'ai l'impression que c'est toujours le client qui dirige tout.

Assez étonnamment, ils souvent d'ailleurs peu dispo, repoussent ou annulent les call hebdomadaires (génial quand tu organises ta journée en tant que freelance à la maison autour de ça), ne veulent pas d'accompagnement pour les recettes mais attendent que ce soit mis en prod. Comme ils ont le portefeuille...

C'est plus simple pour des profils comme le mien (peut-être le tien si tu te mets en freelance) avec des structures plus solides, des chefs de projet qui savent un peu mieux gérer le projet, et des gros portefeuilles pour arroser qui on veut.

Citation:

---

Ca veut dire que ta compagne n'est pas en contact avec le client? Elle etait presente quand le cahier des charges a été rédigé avec le client?

---

J'essaie de me rappeler d'un exemple précis mais il y en a plusieurs. Mais pour ce cas-là, le chef de projet n'était pas là lors du cahier des charges. Et c'est pas sûr qu'il en ait organisé un.

Dans les web agencies, j'ai l'impression qu'il y a beaucoup de CP qui n'ont jamais suivi un cursus voire une formation de gestion de projet. On leur file le téléphone et c'est "vas-y, gère avec le client". J'ai perso bossé avec des CP passe-plats qui faisaient office de commercial, et encore très honnêtement je serai meilleur vendeur (par contre, au pied du mur, ils ont le talent qu'il faut : ils s'accrochent aux basques, chose que je ne sais pas faire).

Un peu plus de précision là. C'est ce que j'ai essayé de savoir mais je n'ai pas eu beaucoup de retour. Mais typiquement ma compagne voulait que les CP suivent des abaques basiques pour détourer le premier plan, mais qu'ils n'ont jamais cédé.

Citation:

---

Je vois pas en quoi le projet capote?

---

Oh non, je ne dis pas ni ne souhaite que le projet capote. Je dis juste que si la SSII n'a pas envie de capitaliser chez le client, une perte n'est pas une perte, et un gain sera toujours un gain. Si un seul consultant peut mettre en péril les missions de 40 prestas et que le commercial n'a que ce compte-ci, là par contre ce dernier peut être vénère.

>>> j'ai l'impression que c'est toujours le client qui dirige tout.

Si tu relis tous les postes, tu verras que c'est toujours des commerciaux qui disent toujours oui sans se preocupper de la faisabilite et des disponibilites ET des developpeurs qui travaillent soir et week end pour realiser le projet dans des delais insoutenables.

Les deux sont inséparables. Ca va ensemble. L'attitude de l'un n'existe pas sans l'attitude de l'autre.

La situation atteint naturellement un equilibre. Les commercieux vendent et font de l'argent donc ils continuent, les developpeurs livrent les projets donc ils continuent.
Il n'y a pas de probleme. C'est une entreprise qui tourne et qui fonctionne. Les horaires et les conditions de travail sont deplorables, et alors?

Pour changer ca, il suffit que l'equilibre se casse. C'est a dire que le client arrete de payer (typiquement parce que le projet est pas livre ou mal livre, quand on a promit beaucoup trop).
Et la d'un coup l'entreprise commence a se questionner (et des tetes tombent).

En tant que developpeur, si on veut des meilleurs conditions de travail, c'est tres simple, il suffit d'arreter de bosser le soir et le week end pour compenser la mauvaise gestion.
Peut etre commencer un planning pour marquer quels jours on travaille sur quel projet (et si un commercial prevoit double c'est pour sa gueule). Les gens s'adaptent tres vite quand ils n'ont pas le choix, on bien ils sautent (et ca peut etre le developpeur qui saute, ou le commercial, ou le client).


Les agences web font des projets courts, donc il y a une enorme pression de vendre et de trouver de nouveaux clients tout le temps.
Tu me pardonneras mais c'est vraiment le dernier endroit ou travailler en tant que developpeur. Je pense que ta compagne peut trouver un meilleur poste que ca. ^^
Les SSII ont generalement des projets longs et s'en sortent beaucoup mieux.

>>> C'est plus simple pour des profils comme le mien (peut-être le tien si tu te mets en freelance) avec des structures plus solides, des chefs de projet qui savent un peu mieux gérer le projet, et des gros portefeuilles pour arroser qui on veut.

En tant que Freelance, on parle et on negocie directement avec le client. On a pas le probleme qu'on doit etre chez 3 clients differents demain, parce qu’évidemment on ne s'engage pas la dessus.

Et on le voit venir quand le client ne veut pas ou ne peut pas payer. Un client a eviter? (Les agences web qui disent toujours oui recuperent facilement des projets et des clients cheap et difficiles dont personne d'autre ne voudrait).

>> Assez étonnamment, ils souvent d'ailleurs peu dispo, repoussent ou annulent les call hebdomadaires (génial quand tu organises ta journée en tant que freelance à la maison autour de ça), ne veulent pas d'accompagnement pour les recettes mais attendent que ce soit mis en prod. Comme ils ont le portefeuille...

Une petite parenthese legal. C'est comme ca que les SSII gagnent leurs pains.

C'est de la jurisprudence, le client ne se presente pas, ca veut dire qu'il n'a pas realise sa part du contrat.
Quand le dossier ira au tribunal, ce sera un cas facile ou le client a tort, il va devoir payer le contrat en entier meme si rien n'a ete livre (c'est par sa faute), les penalites sont nulles, l'obligation de resultat est annule.

Le projet de deux ans capote et le client refuse de payer? On deploie le service legal.
Comme par hasard ca fait 1 an qu'on essaye de rentrer en contact avec le client, en vain. :scratch:

Citation:

---

Envoyé par yento

En tant que developpeur, si on veut des meilleurs conditions de travail, c'est tres simple, il suffit d'arreter de bosser le soir et le week end pour compenser la mauvaise gestion.
Peut etre commencer un planning pour marquer quels jours on travaille sur quel projet (et si un commercial prevoit double c'est pour sa gueule). Les gens s'adaptent tres vite quand ils n'ont pas le choix, on bien ils sautent (et ca peut etre le developpeur qui saute, ou le commercial, ou le client).

---

La seule fois où j'ai bossé plus que je n'en devrai, c'était parce que j'apprenais pas mal (je faisais du management à la journée, et du dev le soir en mode optimisation ce qui permettait d'aller loin dans les limites de l'outil).

Après, y a deux types de cheffaillon qui fait faire n'importe quoi : ceux où tu peux comprendre leur point de vue (parer au plus urgent, mais par contre vous pourrez en débattre des heures) et ceux qui veulent juste que tu fasses d'excellents résultats genre +200% de tickets résolus pour qu'ils puissent pavaner auprès du top management. Ceux-là donc c'est facile, tu fais ce que tu dis, et ça les calme immédiatement :mouarf:

Citation:

---

Envoyé par yento

Les agences web font des projets courts, donc il y a une enorme pression de vendre et de trouver de nouveaux clients tout le temps.
Tu me pardonneras mais c'est vraiment le dernier endroit ou travailler en tant que developpeur. Je pense que ta compagne peut trouver un meilleur poste que ca. ^^
Les SSII ont generalement des projets longs et s'en sortent beaucoup mieux.

---

Faut bien commencer quelque part. Mais oui, j'étais curieux de voir l'envers du décor. Comme tu dis, on a beau dire que les SSII c'est pas forcément mieux, au moins le côté longue haleine permet de mieux se recentrer (un peu) sur son code.


>>> C'est plus simple pour des profils comme le mien (peut-être le tien si tu te mets en freelance) avec des structures plus solides, des chefs de projet qui savent un peu mieux gérer le projet, et des gros portefeuilles pour arroser qui on veut.

En tant que Freelance, on parle et on negocie directement avec le client. On a pas le probleme qu'on doit etre chez 3 clients differents demain, parce qu’évidemment on ne s'engage pas la dessus.

Et on le voit venir quand le client ne veut pas ou ne peut pas payer. Un client a eviter? (Les agences web qui disent toujours oui recuperent facilement des projets et des clients cheap et difficiles dont personne d'autre ne voudrait).

>> Assez étonnamment, ils souvent d'ailleurs peu dispo, repoussent ou annulent les call hebdomadaires (génial quand tu organises ta journée en tant que freelance à la maison autour de ça), ne veulent pas d'accompagnement pour les recettes mais attendent que ce soit mis en prod. Comme ils ont le portefeuille...

Une petite parenthese legal. C'est comme ca que les SSII gagnent leurs pains.

C'est de la jurisprudence, le client ne se presente pas, ca veut dire qu'il n'a pas realise sa part du contrat.
Quand le dossier ira au tribunal, ce sera un cas facile ou le client a tort, il va devoir payer le contrat en entier meme si rien n'a ete livre (c'est par sa faute), les penalites sont nulles, l'obligation de resultat est annule.

Le projet de deux ans capote et le client refuse de payer? On deploie le service legal.
Comme par hasard ca fait 1 an qu'on essaye de rentrer en contact avec le client, en vain. :scratch:[/QUOTE]



Sinon, on peut en débattre longuement sur ce qui est bien ou pas bien, où il faut s'arrêter de se battre ou pas. La vie de développeurs freelance c'est souvent courir derrière les factures. Au moins, quand le projet est fini il y a toujours des moyens de se retourner facilement. Quand le projet est en cours, à moins de planter le client exigeant qui veut une fusée, ça finit en juridique. Malheureusement, le freelance seul est souvent désemparé face à une structure qui a elle-même un service contentieux/juridique.

Bonjour Röyksopp,

J'avais partagé mon expérience sur le sujet 4 jours plutôt sur le forum (sans trouver grand succès d'ailleurs :aie:).

Ça ne correspondra pas à ton cas, mais cela pourrait peut-être te conforter sur certains points.

Le thread en question : https://www.developpez.net/forums/d2.../#post11770145

(oui, je fais de la pub pour mon thread ^^)

Citation:

---

Envoyé par Glutinus

Dans les faits, je suis plus que 300% d'accord avec toi yento. La base, c'est le cahier des charges, ce qui est en dehors n'a pas lieu d'être, sinon tu commandes une allumette et tu exiges d'avoir une fusée.

---

bref c'est ce que j'ai écris quelques fois déjà sur ce forum..:mouarf:

un projet logiciel de gestion c'est peut-être 70-80% de conceptuel le reste à partager entre le codage, tests unitaires et livrables.
Si votre projet est mal conçu au départ eh bien évidemment tout va partir en vrille et ça va coûter une ruine à produire.
Si vous devez utiliser le théorème de Pythagore et au lieu d’utiliser racine carrée de (x^2 + y^2)= racine de z^2 eh bien les calculs seront faux