Engagé sur le Product-Driven Design

Pourquoi le Product-Driven Design ?

Pendant des années, nous avons constaté un gaspillage massif dans les organisations informatiques. Et pourtant, de nombreuses innovations sont apparues depuis la douloureuse ère du Waterfall.

Aujourd'hui, nous disposons d'un ensemble de pratiques et d'approches pour délivrer en continu des logiciels à la fois fiables et désirables.

Chez 42skillz, nous sommes engagés dans la conception de produits ou de services solides et désirables. Nous analysons toutes nos recherches auprès des leaders mondiaux sur les thèmes suivants: Product Management, Domain-Driven Design, Team-Topologies, Behavior-Driven-Development et Test-Driven Development. Notre objectif est vous accompagner, depuis vos objectifs stratégiques jusqu'à la livraison de vos produits en production.


Quelques mots du CEO - Bruno BOUCARD

Nous sommes convaincues que la construction d'un produit est avant tout une affaire de collaboration et d'apprentissage collectif.

Apprendre le contexte du métier afin de s'acclimater au contexte fonctionnel, aux usages des utilisateurs, tout en s’appropriant les mots utilisés par les experts du métier. On combinera différents types d'ateliers collectifs afin d'en apprendre davantage sur les potentiels usages des utilisateurs, tout en restant aligné avec les OKR de l'entreprise. Comprendre et de les partager les besoins métier à travers des conversions avec son équipe est essentiel. Envisager une nouvelle technologie n’est jamais facile.

Un bon produit se doit d'avoir une parfaite connaissance de son segment de marché. Sur le plan technologique nous faut aussi choisir une approche technique qui nous permettra de ne pas être disrupté par un concurrent partageant les mêmes ambitions. L’apprentissage est donc essentiel, à la fois sur les approches pour comprendre les usages des utilisateurs, mais aussi sur l’UX pour offrir une expérience des usages désirés des utilisateurs. Coder tous ensemble afin de partager et comprendre collectivement permettra d’aborder cette nouvelle technologie sereinement. Pour que le code puisse s’adapter aux erreurs d’appréciation inhérente à l’apprentissage des usages de nos utilisateurs, l’équipe de développement choisira l’approche Domain-Driven Design et la pratique des deux écoles du TDD, afin que le produit ne souffre pas des périodes de calibrage des besoins. Afin de ne pas négliger la sphère technique, nous préférons utiliser le terme Product-Driven Design, pour nommer explicitement la combinaison entre Product Discovery et le Domain-Driven Design.