Dessine-moi un CTO

Dans le dernier billet, nous avons parlé de la malédiction de la V2.
Un mal profond qui met en péril la plupart des éditeurs de logiciels.
Cette semaine, place aux remèdes possibles.

Résumé des épisodes précédents
Après une version 1 à succès, cet éditeur de logiciel se retrouve comme beaucoup d'autres incapable de sortir la V2 qui devait lui apporter un relais de croissance. L'entreprise n'est pas loin de déposer le bilan.

sevyc64 ajoute avec beaucoup de justesse :

Et ce que tu oublies de dire, c'est que, en réponse au succès de la V1, les concurrents, eux, ont fait la "V2" et sont même sur le point de sortir la beta de ce qui aurait pu être la "V3"

C'est bien de se retrouver leader à moment donné, et de prendre tout le marché aux concurrents, mais il faut pas perdre de vue, que la place, quand on la veut, il faut dore et déjà prévoir qu'il faudra tout faire, ensuite, pour la garder. Et que la concurrence ne restera pas les bras croisées.

J'ai comme la sensation de vivre cette histoire, en ce moment dans ma boite.

Un nouvel espoir
Si votre entreprise est dans cette situation, que faire pour redresser la barre ?
Les mesures de redressement financier ne suffiront pas. Diminuer les effectifs, c'est aussi hypothéquer l'avenir. Avec quelles ressources trouverez-vous des relais de croissance ?

Trouver un pivot marché
J'ai travaillé chez un éditeur qui ne trouvait plus de relais de croissance.
Face à un client lourd vendu à des grands comptes, un concurrent SAAS prospérait en vendant à des clients plus petits des abonnements pour une application web. Nous étions sur un marché en consolidation, tandis qu'eux avaient découvert une océan bleu.
Dans le même temps, un marché proche était également en croissance, celui des logiciels vétérinaires.
Il y avait donc 2 possibilités de pivot qui pouvaient être testées :

1. déployer des logiciels web open source concurrents ou louer des accès à notre logiciel à travers une prise en main à distance, pour vérifier si nous pouvions nous positionner face à ce concurrent SAAS
2. ajouter à un logiciel open source ou à notre base de données la notion de "propriétaire du patient" (propriétaire de l'animal) pour vérifier si nous pouvions nous positionner sur ce marché proche, celui des logiciels vétérinaires.

En guise de MVP, une page web décrivant l'offre, quelques coups de téléphone pour démarcher en complément, et nous aurions pu vérifier si nous étions en capacité d'attirer des prospects.
Dans les 2 cas, une fois la demande validée par ce MVP, pour satisfaire pleinement ces nouvelles demandes, nous pouvions déployer des logiciels open source concurrents de notre offre, en les remodelant juste ce qu'il faut.

Pendant ce temps, faute de croissance sur son marché principal, le CEO positionnait l'entreprise sur d'autres marchés connexes (prise de rdv, prise en charge d'autres spécialités médicales). Cela nous amena à financer le développement de plusieurs autres logiciels. Ces pivots n'amenèrent pas la croissance espérée. Aucun ne trouva de débouchés, sauf un développement rapide et bon marché, celui du rappel de rdv (envoyer un sms pour éviter les rdv non honorés par les patients).

Le CEO était proche de la retraite. Bien que le marché soit en consolidation, nous avons remporté un appel d'offre. Notre situation financière saine permit de trouver un repreneur.

Avant la catastrophe

Le repreneur ne réalisa pas de chiffre d'affaires significatif l'année suivante. Les abonnements de support logiciel finançaient les frais fixes, mais il ne trouva pas de nouveau client.
Face à cette situation, il pouvait décider de tester les deux pivots SAAS/vétérinaire à peu de frais, mais il ne vit probablement pas ces opportunités.
Face à une situation bouchée, il reste cependant toujours une dernière possibilité :

• faire l'inventaire des compétences disponibles en interne, et les proposer en prestation.

En effet, nos équipes étaient particulièrement aguerries sur les technologies Oracle. Et d'autre part, l'entreprise entretenait un service support, qui aurait pu être proposé pour compléter celui d'autres entreprises ou apporter du support sur des solutions open source concurrentes. Ainsi, les compétences seraient restées en interne et nous aurions eu du temps pour conduire d'autres tests marché.

Réussir sa V2
Dans le billet précédent nous avons vu que dédier une équipe distincte pour développer la V2 ne produisait pas les résultats escomptés. Pourquoi ?

Nouveau produit = nouveau MVP
Parfois, remanier l'architecture ou recopier la V1 dans une nouvelle technologie peut marcher. Je l'ai déjà réussi, dans un contexte où un client pensait tirer un avantage concurrentiel à travers notre solution. Et c'est d'ailleurs ce client qui s'est engagé à financer intégralement 1 an de développement pour cela.

Comme l'a souligné sevyc64, le marché a probablement changé depuis l'introduction de notre logiciel : les concurrents se sont mis à niveau, et il peut maintenant être difficile de convaincre face à eux.
Il est donc vital de réduire les risques en testant à nouveau notre proposition de valeur via un MVP.
Ce nouveau test marché sera peut-être l'occasion de découvrir des besoins actuellement non satisfaits par les offres disponibles. Ces besoins pourraient constituer des relais de croissance intéressants (cf le logiciel de rappel de rdv vu précédemment).

Structurer les équipes pour scaler
Les entreprises se structurent souvent d'une façon un peu naïve, en copiant un modèle hiérarchique répandu.
Or, dans le cas d'un éditeur l'activité de production logicielle est critique, et s'accommode mal de ces structures classiques : une organisation centrée sur les produits est nécessaire.


Lutter contre l'entropie logicielle
Nous avons vu dans le billet précédent que, au fil du temps, le logiciel devient de plus compliqué à maintenir. Cela se reflète dans des métriques Sonar telles que la complexité cyclomatique.
Repartir à zéro sur un nouveau développement semble la seule solution du point de vue des développeurs.
Mais si l'on se place du point de vue financier il n'y a pas là une réelle création de valeur. Après tout, l'ancienne version fait déjà le job.
Alors, comment procéder pour remettre le code d'équerre ?

Réduire la complexité
Pour rendre le code plus facile à maintenir et évoluer, il sera probablement nécessaire de :

• se séparer des clients qui refusent de monter sur la dernière version et préfèrent rester sur des versions plus anciennes (pour lutter contre la complexité engendrée par la fragmentation des versions)
• se séparer des clients qui veulent des garder des fonctionnalités sur mesure spécifiques, que nous ne pouvons pas intégrer dans notre offre globale (pour lutter contre la complexité cyclomatique).

- Nous verrons dans un prochain billet que la valeur ajoutée d'un logiciel "sur étagères" repose justement dans cet alignement sur les meilleurs process. -

Découper verticalement
Pour faciliter l'évolution du code et de l'architecture, nous pouvons profiter des demandes d'évolution de fonctionnalités existantes.
En s'appuyant sur la démarche eXtreme Programming, l'équipe de développement va refactoriser le code.

Il sera important que le Product Owner découpe verticalement les évolutions ou fonctionnalités. En applicant la technique du hamburger, l'équipe découvrira des opportunités de refactoring sur certaines couches logicielles. La roadmap devra intégrer ces changements : on répartira le coût de refactorisation d'un composant sur les sprints à venir. Ainsi, tout en livrant de la valeur, l'équipe pourra procéder à la refonte complète d'une couche logicielle.



Refactoriser la couche de stockage
La généralisation des ORM amène souvent à un usage assez pauvre des SGBD.
Il serait pourtant dommage de se priver des possibilités que les vues SQL nous amènent pour favoriser le refactoring.
Une première étape dans le refactoring peut donc être de ne plus requêter directement sur les tables, mais de s'astreindre à passer systématiquement par une vue. On peut ainsi ajouter ou modifier des champs dans la base de données, sans mettre en danger le code existant.

Pour les insertions et mises à jour de données, passer par des procédures stockées va également aider à découpler le SGBD du code qui y accède (couche modèle dans le pattern MVC). C'est le concept de bases de données épaisses.

Amener du découplage dans un client lourd
La généralisation des environnements RAD comme Visual Studio a amené à fusionner les couches présentation et métier.
Pour découpler ces couches, il peut être intéressant de transformer l'application pour obtenir une interface graphique qui exécute des applications en ligne de commande. C'est d'ailleurs un standard dans le logiciel médical, notamment pour les applications qui utilisent le toolkit DICOM DCMTK.

Micro services, maxi complexité
Les patterns des grands du web inspirent souvent les refontes logicielles. Mais ils ont un coût, notamment en termes de complexité.
Combien d'équipes s'aperçoivent après coup qu'elles ont succombé au hype-driven development ?

Les logiciels sur étagère héritent souvent d'une architecture monolithique. C'est loin d'être un anti-pattern.
Il est tout-à-fait possible de rendre un monolithe adaptatif, et c'est souvent le meilleur choix pour un client lourd.

Amener du découplage dans une application web
Le web est devenu une sorte d'enfer des dépendances, particulièrement dans l'éco-système javascript.
La dette technique et les coûts de maintenance explosent, tirés par les fréquentes et indispensables mises à jour de composants.

Une application web peut bénéficier d'une ré-écriture qui va diminuer la taille du graphe de dépendances, en rationalisant l'usage qui est fait des frameworks.
Les frameworks comme Angular proposent maintenant des fonctionnalités qui permettent de ne charger que les composants correspondant aux fonctionnalités réellement utilisées.
Il peut également être intéressant de s'intéresser sur l'usage qui est fait de ces frameworks dans notre application. Beaucoup de sites ecommerce ou institutionnels utilisent des frameworks conçus pour des applications web. Si votre application n'est pas un tableur, il y a fort à parier que vous n'avez pas besoin d'Angular. De même, si votre application n'est pas un réseau social, il y a peu de chance que React soit un choix rentable.
KISS (Keep It Simple Stupid) : utilisez les fonctionnalités natives HTML5/CSS3, revenez à des librairies plus simples (Jquery), abandonnez des effets graphiques inutiles, et vous diminuerez vos coûts.

Tirer partie de la JAMstack
Utiliser l'approche JAMstack permet de refactoriser rapidement une application web, en bénéficiant d'un scalabilité quasi infinie.
il peut être intéressant de démarrer notre V2 en remplaçant certaines fonctionnalités natives de notre solution SAAS par des API tierces (paiement, panier, emailing, etc.). Cela peut permettre de rénover rapidement et à peu de frais des portions de code devenues fragiles ou coûteuses à maintenir. Et donner du temps pour les rénover en profondeur.