Dans le développement de logiciels indépendants, quel type de sanctions les entreprises devraient-elles appliquer en cas de dépassement des délais? [fermé]

Je parlais avec un co-développeur.

Il a un client qui voulait s'assurer de livrer à temps. Le client veut des répercussions sur les délais manqués.

Bien que je ne fasse pas de travail indépendant, je n'ai pas pu répondre.

Donc, ma question est:

Quelles répercussions convenez-vous (pigistes) avec votre client si vous manquez des délais sur vos livrables (en plus d'être licencié)?

L'une des plus efficaces: pénalité par jour de retard. C'est aussi ce qui se fait pour les grands projets, la sanction étant parfois de milliers de dollars par jour.

Si un délai précis est important (par exemple, si l'on développe pour les Jeux Olympiques une application web qui gérera la diffusion de l'événement en 2014, le délai serait le début des Jeux Olympiques en 2014), alors la mesure efficace pourrait être celle de un cas où le projet est en retard, l'entreprise n'est pas du tout payée, et devrait également payer une pénalité.

Si de telles mesures drastiques ne sont pas appropriées, le seul fait qu'un client bien payé partira si le projet est en retard peut faire l'affaire.

Remarque pour le client:

1. De nombreux retards sont la faute des clients eux-mêmes. Les causes peuvent être multiples:

   • Pas de SRS, mais plutôt deux paragraphes décrivant à tort ce que le client imagine être ses besoins (et bien sûr, le client ne veut pas payer pour la collecte des exigences, considérant cette étape comme une perte de temps).

   • Venir deux semaines avant la date limite finale et dire que peu importe que le projet ait été fait en Java jusqu'à présent et utilisé Oracle: il est impératif qu'il soit réécrit en Python et utilise MySQL, car le client a lu un magazine hier dire que ces technologies sont l'avenir.

   • Venir avec un nouvel ensemble d'exigences à chaque réunion. Des points bonus lorsque ces exigences contredisent presque toutes les exigences données jusqu'à présent.

2. Une bonne communication est essentielle pour un bon projet.

   De nombreux autres retards sont dus au manque de communication. Les pratiques où le client n'a aucune communication depuis des mois avec l'entreprise et s'attend à être contacté uniquement une fois le produit terminé et poli invitent à une catastrophe.

3. En avoir pour son argent.

   Il existe des procédures spécifiques qui aident à maintenir le projet organisé et, en fait, la programmation ne devrait prendre que 10 à 15% du temps pour les grands projets et 15% à 20% du temps pour les projets moyens. Ces projets devraient également être réalisés par des gens qui savent ce qu'ils font.

   En pratique, les clients ne sont pas disposés à payer 800 $ / jour à un analyste qui créera l'architecture et la conception de logiciels, et ils ne veulent pas non plus payer pour d'autres étapes. Un programmeur albanais débutant qui est heureux de travailler pour 50 $ / jour semble beaucoup plus avantageux.

   Ne vous plaignez pas que le projet est un désastre lorsque vous n'êtes prêt à payer que pour des projets désastreux.

4. Ne négociez pas le temps requis pour faire le travail.

   Je rencontre souvent des discussions comme ça:

   Développeur: compte tenu des exigences, je peux livrer cela en quatre mois.
   Client: c'est impossible. Le projet devrait être réalisé en deux mois.
   Développeur: eh bien, à moins que vous ne supprimiez certaines fonctionnalités ...
   Client: je ne peux pas! Toutes les fonctionnalités sont nécessaires. Pourquoi ne pouvez-vous pas faire le travail en deux mois? J'ai contacté un programmeur indien, un de mes amis, il peut livrer ça en un mois et demi, et ne demande que la moitié du prix!

   La négociation du temps est une recette pour un désastre.

5. Connaissez vos priorités.

   Tenez compte de la règle des 90%. Lorsque le projet n'est pas géré correctement, il n'est pas rare de voir des développeurs dire qu'ils ont fait 90% du projet un mois après le démarrage du projet. Puis, un mois plus tard, c'est toujours 90%. Et un mois plus tard.

   Cela peut avoir deux causes:

   • Lorsque le projet n'est pas fait correctement, c'est-à-dire que 100% du temps est consacré à la programmation, ce qui laisse 0% pour la collecte des exigences, l'architecture, la conception et les tests, ce qui se passe est que les programmeurs n'ont aucune idée du travail à faire et découvrent de nouvelles tâches pendant toute la durée de vie du projet. La préparation du projet aiderait à mieux comprendre toutes les tâches à accomplir.

   • Lorsque le client est pressé, il n'est pas rare que certaines entreprises livrent rapidement de la merde, puis passent énormément de temps à résoudre des bogues. Certaines entreprises ne fonctionnent que comme cela, ce qui les aide à rester compétitives et à dire qu'elles ont accompli un projet donné en trois semaines, même si plus tard, elles ont passé trois ans à résoudre le désordre.

   En redéfinissant les priorités et en exigeant que le projet soit réalisé correctement, cela permet d'éliminer ces entreprises de la liste des candidats.