Préparation du développement Web et workflow complet du projet

Je travaille en tant que programmeur solitaire sur des projets de développement Web (front et back-end) - J'ai terminé quelques projets, donc je suis assez nouveau dans ce domaine, j'ai lu et essayé quelques approches et j'ai trouvé un moyen d'aller à propos d'eux. La question et ma description sont assez longues, alors soyez patient.

Ce que je recherche, c'est:
1. Préparation / planification qui serait généralement effectuée avant de commencer le développement, une fois que vous savez exactement ce qui doit être construit.
2. D'après votre expérience, veuillez me faire part de vos commentaires / suggestions sur le processus que je suis en train de suivre.

Les clients avec lesquels je travaille sont généralement des startups et ont des budgets limités, je ne peux donc pas les facturer à l'heure (je pense que c'est ainsi que les grandes entreprises facturent généralement leurs clients [sur l'homme / heures] pour les projets de développement) et doivent travailler avec un budget fixe.

Voici le processus que je suis actuellement en train de suivre:
1. Évaluez la portée du projet et essayez de comprendre ce qu'ils essaient d'accomplir dans quelques réunions.
2. Donnez-leur un chiffre approximatif avec une citation qui décrit en général ce qu'ils attendent du projet, j'essaie d'être précis sur les fonctionnalités, mais je n'y mets pas trop de temps parce que je connais le le client peut simplement demander des devis et ne pas réellement convertir.
3. Je suis la suggestion de Jeff Atwood pour le paiement et le travail:

Paiement de 15% - à l'avance avant de commencer tout travail
Au cours de cette phase, une maquette HTML du site Web final est réalisée, un organigramme (avec yEd ) décrivant le site Web de manière aussi détaillée que possible et un document mentionnant d'autres fonctionnalités qui ne figurent pas dans l'organigramme. . Cela se fait en entrant dans tous les détails du projet et en finalisant les bits qui s'intégreront et les trucs qui sont trop de travail à mettre en œuvre pour le prix convenu. Parce que les détails ne sont pas discutés plus tôt, des parties de ceux-ci sont également plus ou moins une négociation sur ce qu'ils obtiendront réellement. Parce que c'est un projet à budget fixe, il doit y avoir des exigences fixes, sinon, mon prix continue de baisser à mesure que de nouvelles fonctionnalités sont ajoutées.
Un schéma de couleurs, une conception filaire et une conception PSD sont également finalisés.

Paiement de 35% - Démarrer le développement
Le projet est fixe, commencer le développement. J'héberge le site sur mon serveur, où le client peut accéder au front-end, mais n'a accès à aucun code.

Paiement de 30% - Déplacez le code sur le serveur du client / donnez au client les détails d'accès au serveur
Rendez le site vivant.

Paiement de 20% - Quelques semaines après la mise en ligne du site, une fois tous les bugs corrigés.

Questions:
1. Une fois que vous savez exactement ce que vous allez construire, quel type de planification feriez-vous avant de commencer à coder?

2. D'après votre expérience, quelles parties de l'ensemble du processus feriez-vous différemment?

Grands points de discussion!

Pour me qualifier - Je travaille dans de GRANDS projets de développement Web dans l'industrie de la défense. Nous avons généralement une équipe de 10 à 40 personnes soutenant un seul client, les projets des dernières années, et le client a à la fois de l'argent et des exigences élevées. Le kilométrage peut donc varier - vous ne voulez pas trop planifier!

1 Une fois que vous savez exactement ce que vous allez construire, quel type de planification feriez-vous avant de commencer à coder?

C'est après la section des 15%, au début des 35%, non?

• Décidez du serveur Web cible et de la langue
• Décidez du stockage des données - XML, base de données, quelle base de données?
• Décidez des principales API - persistance des données, interface graphique, journalisation, injection de dépendance, etc.
• Décidez des mécanismes de connexion - en tenant compte des risques et des informations que vous essayez de protéger. Peut inclure des mécanismes de paiement.
• Planifier une architecture de haut niveau et des conventions de dénomination
• Choisissez un ordre de déploiement des fonctionnalités, vous savez donc par où commencer
• Décider d'une stratégie de test et mettre en place un cadre de test automatisé le cas échéant
• Configurer le système CM

2 D'après votre expérience, quelles parties de l'ensemble du processus feriez-vous différemment?

Je ne planifierais pas trop. Je concentrerais mon travail de planification sur les choses à faire - comme l'environnement de construction, le serveur, le banc d'essai, le CM - et ne passerais que peu de temps à planifier une architecture, à choisir des outils et à décider par où commencer. J'ai l'impression que, quoi qu'il arrive, l'étape de la planification amorphe implique toujours beaucoup plus de temps à errer dans un désert sans aucune idée qu'il ne le devrait vraiment.

Si vous avez affaire à des frais fixes et à des clients qui ne font pas de demandes techniques (comme la langue ou les API que vous utilisez), je planifierais en 1 article qui est toujours une poussée pour vous, techniquement. Juste 1 et gardez le reste le même. Je pense que sur chaque projet, vous voulez élargir vos compétences, mais vous ne voulez pas devenir si sauvage que vous ne travaillez pas dans quelque chose que vous connaissez ou comprenez bien.

Mon plus grand conseil est d'être extrêmement prudent avec un travail de développement à prix fixe. Si vous ne maîtrisez pas bien les exigences avant le début du travail, l'une des deux choses pourrait se produire.

1. Les estimations sur la portée se sont révélées insuffisantes et vous avez perdu votre chemise.
2. Le client ne connaît pas ou ne peut pas connaître toute la portée avant de commencer, ce qui les rend insatisfaits du résultat final.

Pour vous, le numéro 2 est une meilleure situation, car s'ils approuvent la portée et changent d'avis plus tard, vous pouvez renégocier pour plus d'argent. Assurez-vous simplement que VOUS comprenez la portée avant d'estimer et qu'ILS comprennent la portée et ce que vous livrerez.

Assurez-vous qu'ils approuvent la portée! Les entreprises qui insistent sur un prix fixe et refusent de signer sur le périmètre sont de MAUVAIS CLIENTS et vous ne voulez pas perdre votre temps avec cela. Vous perdrez toujours.