Faire développer un logiciel à la semaine
DÉVELOPPEMENT DE PRODUIT AU MODÈLE HEBDOMADAIRE
DU TEMPS DE DÉVELOPPEMENT CONCENTRÉ. DES PRIORITÉS MOBILES. UNE DÉCISION DE SEMAINE EN SEMAINE.
De cette logique découle le modèle hebdomadaire. La collaboration ne commence pas par la tentative d'arrêter entièrement un périmètre fonctionnel de long terme. Elle commence par une idée de produit concrète ou une question technique, et par une période de développement clairement délimitée.
Avant la semaine de développement
Nous déterminons quelle question promet, en l'état, le plus grand gain de connaissance ou de valeur produit. Ce qui compte n'est pas la plus longue liste de fonctionnalités, mais la question dont la clarification technique améliore la prochaine décision d'entreprise.
Ce peut être une tranche verticale cohérente d'une application, le noyau d'une nouvelle architecture logicielle, un concept d'interaction exigeant, une simulation, un environnement de travail visuel ou un premier noyau de produit complet.
Pendant la semaine de développement
On développe de façon concentrée. De nouveaux enseignements peuvent modifier les priorités. Si une approche se révèle faible ou si une meilleure direction apparaît, on peut y réagir immédiatement.
Cette mobilité n'est pas un défaut de planification. Elle est la conséquence assumée du fait que les informations pertinentes sur un produit ne peuvent naître qu'au cours du développement réel.
À la fin de la semaine de développement
L'état de développement atteint est là. Sur cette base, on décide si l'on poursuit, approfondit, modifie ou arrête.
Ce qui est réservé, c'est du temps de développement. Ni un périmètre fonctionnel défini à l'avance, ni un résultat d'ouvrage déterminé.
UNE SEMAINE · 4 900 € HT
Chaque semaine supplémentaire fait l'objet d'un accord distinct. Il n'y a pas de reconduction automatique.
Un prix forfaitaire pour un produit nouveau, c’est parier qu’on sait d’avance ce qu’on n’apprend qu’en construisant.
Une semaine de développement n'est pas une unité de mesure pour un nombre fixe de fonctions. Les produits logiciels diffèrent trop, pour cela, en complexité, en point de départ et en dépendances techniques.
Sur des tâches qui s'y prêtent, un système applicatif cohérent peut toutefois voir le jour en peu de cycles : avec une véritable interface, une logique métier centrale, un modèle de données, de la visualisation et une structure technique solide.
Sur des systèmes de bureau, temps réel ou de visualisation complexes, une semaine peut produire une tranche verticale qui ne contient pas toutes les fonctions ultérieures, mais possède assez d'architecture et de fonctionnalité réelles pour prendre les décisions produit centrales.
Lorsque les bases techniques sont déjà bien comprises, le périmètre peut aller nettement plus loin.
En cas de risques de recherche, d'intégration ou de performance, en revanche, c'est la clarification d'un seul problème technique critique qui peut avoir la plus grande valeur économique.
Le périmètre n'est pas standardisé. L'exigence, elle, l'est : le plus de réalité produit solide possible dans le temps de développement le plus court possible.
Qui ne possède pas le code source à l’issue d’un projet logiciel a loué un logiciel.
LE CODE SOURCE. LA POSSIBILITÉ DE POURSUIVRE. LA CONFIDENTIALITÉ.
La collaboration est conçue pour l'indépendance technique.
Après paiement intégral, le donneur d'ordre reçoit le code source du projet correspondant à l'état de développement obtenu, ainsi que les fichiers de projet utiles à la poursuite du travail, pour autant qu'ils fassent partie du développement et puissent être cédés juridiquement.
L'état de développement doit pouvoir être poursuivi par le donneur d'ordre lui-même ou par des tiers.
Les informations commerciales et techniques confidentielles sont traitées de façon confidentielle.
Il n'existe aucun attachement stratégique à une plateforme de développement propriétaire de CUBE4DEV.
Vous achetez du temps de développement et vous recevez l'état de projet qui en résulte.
Si vous avez seulement besoin de plus d’heures de développement, vous n’êtes pas au bon endroit.
L'approche convient particulièrement aux entreprises où existent des idées de produit substantielles dont le potentiel n'est pas encore suffisamment clarifié.
Ce peut être une nouvelle application autonome, un produit numérique, un système métier spécialisé, une simulation, un environnement de visualisation, un outil interactif complexe ou une extension logicielle importante d'un produit existant.
Le modèle est surtout pertinent lorsqu'un état de développement technique réel promet plus d'enseignements qu'une planification abstraite supplémentaire, et lorsque l'idée de produit est encore assez mobile pour réagir à de nouveaux enseignements.
Il convient moins lorsqu'il s'agit d'acheter un périmètre fonctionnel entièrement spécifié à un prix d'ouvrage fixe, lorsqu'une grande équipe de développement est nécessaire, ou lorsqu'il s'agit simplement d'intégrer des ressources de développement supplémentaires à une organisation existante.
L'approche ne vise pas la réalisation la moins chère possible de tâches informatiques existantes. Elle vise les idées de produit pour lesquelles le développement technique peut rendre visibles de nouvelles options entrepreneuriales.
QUELLE IDÉE DEVRIONS-NOUS ESSAYER EN PREMIER ?
La plus longue liste de fonctionnalités est le pire départ pour un nouveau produit.
Toute idée de produit pertinente n'appelle pas immédiatement un grand projet.
Souvent, une question précise suffit d'abord : quelle idée de produit faudrait-il porter à un niveau technique réel avant de décider d'un investissement plus important ? Quelle application n'existe jusqu'ici que comme concept ? Quelle possibilité technique est assez intéressante pour qu'on cesse d'en débattre seulement en théorie ?
Une semaine de développement peut être le début d'un produit plus vaste. Elle peut tout aussi bien fonder la décision assumée de ne pas poursuivre une idée, ou de la développer dans une autre direction.
Le premier pas n'a pas à arrêter le produit tout entier. Il doit rendre meilleure la décision suivante.
UNE SEMAINE · 4 900 € HT
Projets exemples
3
Poser une question à ce sujet
DÉVELOPPEMENT DE PRODUIT AU MODÈLE HEBDOMADAIRE