Avertissement : Les points de vue et opinions exprimés dans cet article sont uniquement les miens et ne reflètent pas nécessairement les points de vue d'une institution ou d'une organisation.
Introduction
La complexité des systèmes logiciels oblige souvent les ingénieurs logiciels ou les managers à rédiger des propositions pour aligner les équipes, les organisations ou les parties prenantes (équipes partenaires, services dépendants, etc.) sur les changements. Ces propositions aident à communiquer la motivation, les recommandations ou les jalons de manière concise, tout en obtenant des commentaires et en alignant toutes les parties prenantes.
Ces documents servent également de points de référence passés pour les nouveaux employés qui s'approprient les systèmes logiciels et comprennent le processus de réflexion sur la façon dont les décisions ont été prises dans le passé. Cet article fournit un modèle générique pour écrire des pages uniques ; bien qu'il ne se limite pas aux systèmes logiciels, il s'est avéré utile dans les organisations de génie logiciel.
Modèle
Aperçu
Ce sera le résumé du document, idéal pour capturer la motivation et ce que vous proposez aux lecteurs pour qu'ils s'intéressent à votre document.
Introduction
Fournissez des détails sur le contexte/la motivation du changement. Des métriques/données peuvent être incluses pour expliquer le problème et fournir des informations supplémentaires.
Objectifs
Exigences liées à la portée de ce projet.
Non-objectifs
Signalez toutes les tâches qui ne sont pas des objectifs ou qui sont hors de portée de ce projet. Cela peut vous distraire de la résolution du problème sur lequel vous souhaitez vous concentrer.
Possibilités
Résumez une liste d'options/alternatives que vous avez envisagées pour résoudre le problème, de préférence avec les avantages et les inconvénients de chacune.
Recommandation
Sur la base des alternatives évoquées dans la section précédente, fournissez des recommandations de solutions stratégiques avec des explications ou des arguments à l’appui.
Approche tactique en option – En fonction des défis et du calendrier associés à la réalisation de l'approche recommandée, envisager de proposer une solution tactique ; cela peut potentiellement constituer une étape progressive vers une solution stratégique ou un changement minimal pour résoudre le problème à court terme.
Essai
Décrivez comment vous vérifierez que la fonctionnalité fonctionne comme prévu ; que vas-tu tester ? Comment allez-vous le tester ? Y aura-t-il une période de validation gamma ou de pré-production ? Qu’est-ce que cela impliquera ? Assurez-vous d'inclure des cas de test qui vérifient que la fonctionnalité s'applique uniquement aux événements pour lesquels elle doit s'appliquer
Jalons
Répertoriez les tâches/jalons de haut niveau pour les solutions recommandées avec des estimations en jours de développement. Pour fournir cette liste en dehors des changements fonctionnels, pensez à :
- Stratégie de tests avant release (tests unitaires, d'intégration, etc.)
- Besoin/stratégie de remplissage
- Toute modification apportée aux métriques/scripts/outils de reporting
- Nouvelles mesures/étapes de validation après la publication (canaris, workflows d'approbation du pipeline)
- Examen de sécurité
- Mini revue de préparation opérationnelle
Les références
Les références qui, selon vous, pourraient aider les lecteurs à approfondir l’espace du problème ou les alternatives présentées.
FAQ
Répondez de manière proactive à toutes les questions ou questions anticipées qui auraient pu être soulevées lors de discussions consécutives liées à cette proposition.
annexe
Ajoutez toute information supplémentaire à la proposition, à laquelle les lecteurs pourront se référer si nécessaire.
Réunion # Notes
Conservez le résumé ci-dessous pour les réunions au cours desquelles la proposition est examinée.
Participants
Liste des personnes ayant assisté à la réunion.
MoM (procès-verbal de la réunion)
Résumez le procès-verbal de la réunion pour référence future.