Comment aborder l'ol '"ce ne sera qu'une petite application"? Oui en effet?

D'accord, je l'ai rencontré plusieurs fois, mais voici le pire des cas légèrement exagéré.

Un client dit "hé pouvez-vous nous faire ce petit module pour faire cette petite tâche"?
Moi: "Bien sûr pas de problème".

Donc, en fonction des budgets et des contraintes, etc., je saute une partie de l'architecture et je plonge directement et je ne fais pas de sueur.

Ensuite, ils demandent un autre module. Et un autre. Et quelques améliorations. Et tout cela se passe très lentement, au fil des ans. Et avant de le savoir, vous avez cette application monstre horriblement architecturée.

Que faites-vous quand on vous demande de faire quelque chose de petit? Vous ne savez pas si cela continuera de croître ... si le client continuera à demander des ajouts (et eux non plus).

Vous ne pouvez pas sur-architecturer la chose, car ce n'est qu'une petite application après tout, et ils iront ailleurs si vous dites (en ce que je connais toute la voix) "Eh bien juste au cas où, architecturons cette chose en couches avec top -sécurité en ligne et séparation des préoccupations. En fait, allons-y avec un outil d'injection de dépendances qui rendra vraiment cette chose fantastique bla bla bla ".

Ils diront "ouais bien" et iront voir quelqu'un d'autre.

Le budget, le temps et la perception sont aussi importants que l'architecture de l'application elle-même.

Comment cela devrait-il être abordé?

Je suppose que la question se résume vraiment à "Lorsque vous ne disposez pas de toutes les informations pour le résultat final de ce qui semble être une petite application, comment éviter (ou atténuer) de prendre des décisions architecturales et de conception dès le début qui seront complètement innaproprié plus tard?

J'en ai rencontré un certain nombre et ce que je fais normalement, c'est exactement ce que vous avez fait, plongez et faites-le.

Quand ils reviennent pour plus, cela signifie que leur modèle d'affaires fonctionne et qu'ils devraient être prêts à investir un peu plus. C'est à ce moment-là que je les asseoir (généralement le 3e module en fonction de la complexité) et leur dire la mauvaise nouvelle.

Je vais tout mettre sur la table, proposer de refaire le tout, y compris le dernier module et lui dire combien cela coûtera. Ils auront généralement un choc autocollant au début, mais si vous avez une bonne relation de travail et que vos affaires fonctionnent, cela ne devrait pas être un problème majeur.

Assurez-vous cependant qu'ils comprennent trois choses:

1. S'ils ne veulent vraiment pas s'embêter avec une réécriture complète, vous ferez toujours le 3e module. Cela peut vous prendre quelques heures de plus et vous les facturerez. Rappelez-leur qu'ils devraient vraiment penser à faire une réécriture à l'avenir, car plus ils attendent, plus cela coûtera.

2. Ça va vraiment leur coûter plus cher pour que quelqu'un d'autre le fasse. La nouvelle personne doit tout repenser avec une compréhension minimale de ses besoins et de ses caprices, ce qui signifie un temps de réécriture supplémentaire et le risque de ne pas faire un aussi bon travail.

3. Que vous n'essayez pas de gagner rapidement de l'argent. La chose a besoin d'une refonte.

BTW, si votre habitude de facturation est à peu près la moitié maintenant, la moitié une fois terminée, vous pouvez envisager de leur proposer des conditions de paiement étendues. Modifiez-le à moitié maintenant et divisez le solde sur la période pendant laquelle vous y travaillerez. Cela pourrait réduire le pincement s'ils ont des problèmes budgétaires.

Faites-lui simplement une petite application et soyez payé pour cela.

D'après mon expérience, il est impératif d'investir plus de temps au début que nécessaire, juste au cas où le client en voudrait plus. Mais vous devez peser l'effort en le faisant (êtes-vous payé pour cela) par rapport à la probabilité que tous ces changements supplémentaires se produisent vraiment. L'application entière pourrait être remplacée complètement après un an.

Et en investissant du temps dans l'architecture initiale, vous pourriez avoir l'impression de vous rendre service. Mais vraiment, vous rendez service au client en lui rendant les autres modules moins chers.

Il vous suffit de facturer un peu plus à votre client pour chaque module réussi et de remanier le projet initial étape par étape, mais toujours juste pour répondre aux besoins du client.

Les réponses précédentes sont bonnes et, si je suis honnête, ce que je ferais probablement. Cela dit, je suis légèrement mal à l'aise dans cette approche en ce que vous prenez des décisions qui appartiennent correctement au client, en fonction de l'hypothèse de ce qu'il veut (et du désir de décrocher le poste)

Je ne peux pas aider sentiment que l' on doit faire est d' être honnête avec le client et de donner leur choix: 1. Je peux le faire rapidement et (relativement) bon marché maintenant. Ce sera génial - cela fonctionnera - mais les améliorations futures coûteront progressivement un peu plus 2. Je peux y passer plus de temps à l'avance, ce qui coûtera un peu plus et n'apportera aucun avantage réel pour les utilisateurs, MAIS cela vous fera économiser de l'argent à long terme si vous avez besoin d'ajouter de nouvelles fonctionnalités.

Idéalement, vous pourrez leur donner des chiffres approximatifs de temps / coûts - sinon la conversation pourrait être trop académique - mais j'apprécie qu'arriver à ces chiffres peut également prendre des efforts. Au moins, cadrer la discussion en termes de projets précédents rendrait la vie plus facile pour le client (et faciliter la vie du client devrait être une priorité absolue :-))

Les commentaires des autres concernant une bonne relation de travail sont parfaits, mais vous pouvez commencer ce processus en étant honnête vous-même. Si le client est du genre avec lequel vous ne pouvez même pas avoir cette conversation, le moment est peut-être venu de vous demander combien vous avez besoin de ce travail ...

Je traiterais chacune de ces "itérations" comme un projet distinct. Vous devez fermer ces projets lorsque chaque petit module ou ajout est terminé. Ensuite, quand ils veulent autre chose, rédigez les documents. Et avec le temps, le logiciel devient plus cher ... ce qui signifie que vous facturez plus pour chaque petit projet.

C'est une façon de voir les choses, au lieu d'une ... Projet LONGGGGGG.

Comment évitez-vous (ou atténuez-vous) de prendre des décisions architecturales et de conception dès le début qui seront complètement inappropriées plus tard?

Tu ne peux pas . Les programmeurs ne sont pas des médiums. Bien que nous puissions prédire des choses simples ou voir des améliorations de l'interface utilisateur, nous ne pouvons pas vraiment coder au-delà de ce que nous ne savons pas que le client pourrait vouloir plus tard (voyez-vous la folie là-bas?).

Votre question mentionnait qu'il y avait des processus opérationnels, mais je ne sais pas s'ils sont de bons processus. Voici quelques conseils:

• Exiger que tous les changements et ajouts soient signés par écrit et avec un budget.
  • Parce que vous avez des factures à payer
  • La partie écrite et signée garantit que c'est vraiment ce qu'ils veulent et réduit 90% des choses frivoles que les clients changent d'avis à mi-chemin pendant le projet

Votre produit envahi

Cela nous arrive à tous. La reconstruction à partir de zéro est généralement une idée terrible, surtout si l'on considère qu'elle sera refaite à l'avenir.

Au lieu de cela, je contracterais les modifications demandées par l'utilisateur. Ajoutez du temps supplémentaire pour chaque fonctionnalité, en utilisant le temps d'origine pour travailler sur la fonctionnalité, et le temps supplémentaire pour améliorer l'architecture globale, une petite amélioration à la fois. Le but n'est pas de «réparer» complètement l'architecture en un seul contrat, mais plutôt de l'intégrer lentement au fil du temps.

Améliorez lentement l'itération du code par itération, en vous concentrant sur les parties qui comptent vraiment.