Les startups doivent montrer que leur produit peut apporter une traction pour pouvoir attirer des investisseurs afin d’avoir les fonds nécessaires à la stabilisation de leur produit et à leur développement. Il n’est pas surprenant donc que la majorité des premières versions des logiciels de nos startups soient réalisées à l’arrache. 

Le développement rapide à l’arrache.

La méthode “à l’arrache” à ses limites, la situation peut rapidement être problématique. En effet, dans la quête du product market fit, la startup va faire, ou faire faire son logiciel, dans des délais courts, avec des itérations courtes pour proposer rapidement de nouvelles configurations au marché, et pouvoir les tester jusqu’au Graal.

Ces itérations courtes laissent généralement peu de place à la documentation, oubliez vos cours UML, BPM … l’établissement du besoin s’effectue par le langage naturel entre le product manager et le développeur, méthode la plus rapide pour obtenir un résultat rapidement.

Une fois le Graal atteint, le logiciel et son architecture ne ressemblent plus à rien et c’est normal. Certains parleront à tort de dette technique, à tort parce que la production de cette dette technique est un mal nécessaire à l’obtention du product market fit, préliminaire à la traction.

A la reconquête de la maîtrise de la solution logicielle. 

Dans cette phase de début de traction, il convient de s’assurer que le produit développé à l’arrache va tenir la route, jusqu’à la prochaine station, comprenez levée de fonds. Comment s’y prendre pour reconquérir la maîtrise ?  

Le reverse engineering est un passage obligé pour les applications développées par un travail informel direct entre le créateur et le développeur. Sans respect d’une phase de sédimentation et de représentation des processus fonctionnels et des règles de gestion, il est difficile d’asseoir la stratégie d’entreprise sur un processus de développement fiable. En effet, dans cette configuration, la traçabilité processus fonctionnel / fonctionnalités du logiciel n’est pas identifiée, pas plus que les règles métiers pourtant centrales.  

Le reverse engineering est bidirectionnel ; il est mené au travers de l’interview du référent fonctionnel pour identifier BUSINESS PROCESS, CAS D’UTILISATION de la plateforme, stories (appelez ça comme vous voulez). Dans un second temps, le reverse engineering logiciel permet par une relecture du code d’identifier les fonctions techniques répondant aux cas d’utilisation :

La stabilisation du produit et la roadmap.

La réconciliation des 2 visions fonctionnelles et technique permet une remise à niveau de l’actif informationnel. Cette remise à plat de la plateforme est nécessaire à la remise en place d’une vision fonctionnelle des évolutions du produit logiciel et de pouvoir repartir sur une roadmap plus « pro ».

Une fois le reverse engineering réalisé, les outils d’un cycle de vie traditionnel peuvent être désormais mis en place. La startup peut préparer sa croissance fonctionnelle et embaucher de nouvelles ressources de développement sans risque.   

En effet, si cet actif n’est pas construit, les nouveaux arrivants dans les équipes de développement auront une tendance naturelle à vouloir repartir de zéro pour la moindre raison. Une bonne partie des développeurs sont victimes du syndrome NIH . Ils auront tendance à vouloir tout refaire parce que sans support informationnel il ne comprendront pas ce qui a été mis en place.

Cette phase d’appropriation de l’architecture logicielle est nécessaire. Elle rend plus simple, plus rapide les évolutions. De plus, elle permet d’intégrer facilement les nouvelles ressources de développement qui vont assurer la suite de la roadmap fonctionnelle. Voilà la startup remise sur les rails pour adresser ses objectifs “dans un fauteuil”. 

Couplée à une bonne stratégie de recrutement des personnes en charge du développement, le dirigeant est libéré des considérations techniques, des casse-têtes du “faut refaire from scratch” … et peut se concentrer sur la roadmap, le produit, le marché, les clients.

A propos.

Créée pour répondre spécifiquement aux besoins des éditeurs de solution qui ne sont pas professionnels de l’informatique et qui veulent développer leurs solutions :  

RECOVERY CASE intervient en amont des projets, pour la mise en place d’une méthodologie adaptée à la taille du projet, pour réaliser les contrôles qualité à réception des produits, des livrables (tests fonctionnels externalisés, qualimétrie logicielle).  

En aval des projets et en cas de difficultés majeures d’exploitation, RECOVERY CASE vous redonne la maîtrise de votre logiciel par des missions de reverse engineering, reconstruction du patrimoine informationnel de votre solution, et opère des forfaits de Tierce Maintenance Applicative et Tierce Maintenance d’Exploitation. 

Crédit photo : Technologie photo créé par pvproductions – fr.freepik.com