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.