Comment façonner l'impact des logiciels lors de la définition du système

Table of Contents

1. Introduction
2. Importance of System Definition Stage
3. Identifying the Core Part of the Software
4. Building a Business Case
5. Approaching the Core Part with a Product Mindset
6. Anticipating Changes to the Core
7. Separating Business Problems from Technical Concerns
8. Boundary around Legacy Systems
9. The Role of the Domain Model
10. Best Practices for Creating a Domain Model
11. Conclusion

📝 Introduction

Dans cette série de vidéos sur l'impact commercial de l'utilisation de logiciels, je m'appelle Sandeep Sabat, PDG d'io labs. Chez io lab, nous développons des solutions d'entreprise pour des clients de diverses industries, de diverses origines et de différentes tailles. Nous constatons un nombre croissant de mortalité infantile des logiciels, ce qui nous a inspiré à créer cette série de vidéos. Dans cette vidéo, nous parlerons des meilleures pratiques à adopter lors de la phase de définition du système du projet, qui permettent de générer un impact commercial avec les logiciels.

❤️ Importance of System Definition Stage

Toutes les parties de l'espace des problèmes ne sont pas égales et certaines parties de l'application sont plus importantes que d'autres. C'est pourquoi elles nécessitent plus d'attention et d'investissements. Répartir également les efforts et la qualité sur l'ensemble du système entraîne une perte de concentration sur la partie impactante réelle. Dans la vidéo précédente, nous avons expliqué comment identifier les zones du logiciel qui doivent être mises en avant. Grâce à la connaissance de où se concentrer, nous pouvons modéliser en profondeur ce qui est essentiel au logiciel, de manière à faire la différence.

🎯 Identifying the Core Part of the Software

Pour comprendre ce qu'il faut modéliser en profondeur, il faut identifier ce qui est essentiel à l'entreprise. Ce qui est essentiel n'est pas toujours évident à identifier. Il faut comprendre quelle partie de l'application est critique pour son succès, pourquoi elle est importante et pourquoi elle ne peut pas être achetée en externe. Il est nécessaire de construire un argumentaire commercial autour de la valeur de cette partie centrale afin de démontrer le retour sur investissement du logiciel. Cet argumentaire doit être socialisé auprès des sponsors du logiciel pour valider son importance et obtenir un soutien à long terme.

💡 Building a Business Case

En cas d'absence de consensus sur la criticité commerciale de la partie centrale identifiée, l'accent doit être mis sur la réduction des fonctionnalités, des efforts et du coût du logiciel. Cela permettra d'obtenir rapidement des résultats et de valider l'idée ou de pivoter si nécessaire. Lorsque le logiciel est développé selon une approche de projet, peu d'attention est accordée à la maintenance du code, aux considérations architecturales et à la qualité. Cela entraîne une lourdeur pour les modifications futures.

🏭 Approaching the Core Part with a Product Mindset

En adoptant une approche de produit pour la partie centrale de l'application, celle-ci reçoit des soins et une attention constants et évolue mieux avec le temps. Il est important de ne pas être obnubilé par la recherche de la perfection dès la première fois, mais plutôt de permettre une amélioration itérative jusqu'à ce qu'il ne soit plus possible de l'enrichir davantage. Au lieu de s'attacher à la solution, il est conseillé de prévoir que la partie centrale évoluera avec le temps en fonction de la compréhension de l'espace des problèmes. Il est donc important de laisser de la place pour les changements futurs lors de la définition des exigences.

🚧 Separating Business Problems from Technical Concerns

Concentrez tous les efforts sur la résolution des problèmes commerciaux et évitez de les mélanger avec les préoccupations techniques telles que les audits de sécurité ou les journaux d'audit. Si le système nécessite une intégration avec un système hérité mal conçu, planifiez la création d'une frontière claire autour du système hérité pour éviter que ses imperfections ne se propagent aux nouvelles zones de l'application.

🗃️ Boundary around Legacy Systems

La partie centrale du système est la raison pour laquelle le logiciel est développé. Il est essentiel qu'elle offre la valeur attendue par l'entreprise grâce à une collaboration et une analyse entre les spécialistes métier et les experts techniques. Une compréhension partagée est développée, puis capturée sous la forme d'un modèle de domaine appelé le modèle de domaine. Le modèle de domaine représente la logique complexe et les politiques dans l'espace des problèmes pour résoudre différents cas d'utilisation métier. Il relie toutes les analyses abstraites autour de l'espace des problèmes à la mise en œuvre concrète du code.

📐 Best Practices for Creating a Domain Model

• Passez autant de temps dans l'espace des problèmes que dans l'espace des solutions.
• Affinez de manière itérative l'espace des problèmes pour révéler la véritable intention derrière la vision des parties prenantes. Cela permettra d'offrir une meilleure solution en évitant de perdre du temps sur les besoins qui n'intéressent pas vraiment l'entreprise.
• Utilisez une carte de contexte pour diviser l'espace des problèmes en différentes parties et sous-modèles. Définissez les limites ainsi que les points de contact entre les différentes parties.
• Montrez à la fois la relation organisationnelle et l'intégration technique entre les parties.
• Mettez en évidence les problèmes de communication et de flux de travail dans l'espace commercial pour la modélisation.
• Concentrez-vous sur la partie centrale qui est complexe, difficile et intéressante, et où l'entreprise a de grandes attentes.
• Utilisez des scénarios concrets pour construire la compréhension et communiquez le modèle avec les spécialistes métier en utilisant la terminologie et la définition commerciale.
• Assurez-vous qu'il y a un consensus entre les experts métier et techniques sur toute la terminologie utilisée dans le modèle.
• Exprimez toute la logique métier dans le modèle avec un nom explicite et assurez-vous qu'elle est intégrée au modèle mental des spécialistes métier.
• Les éléments que les spécialistes métier ne disent pas ou seulement évoquent à peine sont souvent la clé pour découvrir des aspects profonds du modèle.
• Implémentez rapidement et fréquemment le modèle en code en utilisant la terminologie, le langage et les concepts métier.
• Gardez le modèle simple et concentré en évitant toute complexité inutile.
• Divisez le modèle en plusieurs contextes métier lorsque sa complexité et sa taille augmentent, afin de minimiser les dépendances entre les contextes et de créer une frontière claire et solide entre eux.
• Au lieu de se fixer sur un modèle parfait, concentrez-vous sur l'apprentissage et la découverte de nouveaux concepts dans l'espace commercial grâce à l'itération, à l'exploration et à l'expérimentation.
• Validez les bonnes idées en les comparant aux mauvaises et soyez ouvert aux erreurs, car la connaissance de l'espace des problèmes dépend de l'apprentissage continu.
• Mettez à jour en permanence les règles, la terminologie et la nomenclature du modèle pour refléter des abstractions plus pertinentes, répondre au nouveau comportement des parties prenantes et simplifier le modèle.

🔚 Conclusion

Dans cette vidéo, nous avons vu comment façonner l'impact commercial à travers les logiciels en approfondissant les parties centrales et en exprimant le logiciel sous la forme d'un modèle simple. Dans la prochaine vidéo, nous parlerons de la création d'un impact commercial après la sortie d'un logiciel. Merci de votre attention !

FAQ

Q: Pourquoi est-il important d'identifier la partie centrale d'un logiciel ? R: Il est important d'identifier la partie centrale d'un logiciel car c'est cette partie qui apporte une valeur différenciatrice à l'entreprise. En se concentrant sur ce noyau, on peut développer un logiciel qui répond aux besoins critiques de l'entreprise et qui génère un impact commercial significatif.

Q: Qu'est-ce qu'un modèle de domaine ? R: Un modèle de domaine est un modèle qui représente la logique complexe et les politiques de l'espace des problèmes d'une entreprise. Il lie les analyses abstraites à la mise en œuvre concrète du code. Il permet de capturer la compréhension partagée entre les spécialistes métier et les experts techniques.

Q: Quelles sont les meilleures pratiques pour créer un modèle de domaine ? R: Certaines des meilleures pratiques pour créer un modèle de domaine sont : passer autant de temps dans l'espace des problèmes que dans l'espace des solutions, utiliser une carte de contexte pour diviser l'espace des problèmes, mettre en évidence les problèmes de communication et de flux de travail, se concentrer sur la partie centrale complexe et intéressante, utiliser des scénarios concrets pour communiquer avec les spécialistes métier et mettre à jour régulièrement le modèle pour refléter les nouvelles découvertes et abstractions.

Resources:

• io labs