Bonjour
à tous,
Cela
fait un bail que je n'ai pas écrit un article sur mon blog. Et je vous propose
d'aborder le monde des startups et spécifiquement de la relation entre le
porteur de projet (CEO) et le futur CTO, dans le cadre d’une collaboration passionnante.
Je
voudrais au travers de cet article aider les futures CTO et CEO, à mieux se
comprendre, se préparer à leur rencontre sous un angle que je maitrise bien :
Qu'est ce qu'il se passe dans la tête d'un
CTO ?
Le
future CTO se situe dans le bon côté, c'est à dire là où les très nombreux
porteurs de projet se battent pour s’accaparer les peu de ressources techniques
disponibles. Le rapport de force est tellement fort que certains CEO se forment
à la programmation pour palier à la dure loi de la concurrence.
Avant
de commencer, il faut préciser que le focus se porte sur les CEO qui n’ont pas
encore levé de l’argent. En effet, la levée de fond est plus contraignante que la
recherche d’un CTO. Et avec une levé de fond, il est plus simple de trouver son
CTO, si on ne l’a pas déjà …
Je
vais donc traiter de différents aspects qui sont :
1-
Montage d’un dossier
2-
L’affinité entre un projet et le CTO
3-
La sagesse et l’honnêteté
4-
Le produit en lui-même
5-
Le temps, la contrainte principale
6-
Les startups sur un nuage
LE DOSSIER
L'analogie
entre la recherche d’un CTO avec celle d'un appartement pour un jeune au milieu
de Paris est intéressante et pertinente.
Donc, le future CEO se doit de préparer un dossier en béton, sans faille
! Et quand on parle de dossier, cela suppose le dossier papier. En effet, la
qualité de ce dernier démontre le travail fournit par le porteur de projet. Lorsqu’on
m’a sollicité pour une projet, on ne m’a jamais présenté un dossier, et cela me
laisse vraiment perplexe quant au sérieux de le personne…
Voici
ci-dessous les principaux points sur lesquels il faut répondre :
1-
Constitution de la société
L’étape
de la cherche du CTO suppose que la société soit déjà créée, avec le compte
bancaire et KBis associés. Ainsi, le future CEO est déjà prêt pour faire la
répartition des parts, et s’est débarrassé de la paperasse. Il est étrange de
s’apercevoir que beaucoup de porteur de projet n’ont pas encore créé leur
startup au sens juridique.
2-
Le business plan
C'est
l'un des documents principaux pour le CTO. S'il est cohérent et bien ficelé,
alors il donnera de la visibilité pour le CTO, et l'aidera à mesurer les
risques, par rapport au travail fournir pour la livraison du produit. Beaucoup
d’ateliers ou de tutoriels existent pour rédiger ce genre de document.
3-
Le cahier des charges
Il
est impossible de faire une description du produit final car il évolue en
fonction du feelback des utilisateurs et il est en général enrichi. Cependant
pour la V1, il est tout à fait possible de réunir un ensemble de fonctionnalités
qui ensemble créée le killer feature et qui rend le produit et le
positionnement de la startup intéressant. Enfin, si le CTO est bon, le CEO obtiendra
le produit qui a aura été définit dans le CDC.
Sous
le terme cahier des charges 3 aspects sont très importants :
a-
le design : faire un PSD, c'est 3-5 jours de travail
pour un graphiste. C'est un peu d'argent, mais c'est rien par rapport à la
phase du développement. Un CTO, n'est pas un graphiste et ce n'est pas son
métier. Si le PSD est prêt, le CTO n'a plus qu'à l’intégrer, et cela fait
gagner du temps.
b-
Définissez au mieux l'environnement du
business. En effet, ce point permet simplement de déterminer l'architecture
technique et logiciel ainsi que les contraintes sous-jacentes. Par exemple,
dans le case study de 'mon produit va révolutionner les réseaux sociaux en
Chine... ', on peut en déduire l'environnement dans lequel le produit
fonctionnera :
a. la
gestion du million d'utilisateurs.
b. sur
performer la recherche de l'information de notre réseau.
c. le
contenu éditorial est faible.
d. l'information
disponible appartient aux utilisateurs...
e.
Il faut que cela fonctionne sur IE7-IE8 ...
A partir de ces points, l’architecture est définie dans les
termes suivants :
f.
Il doit être scalable (plusieurs serveurs
derrière un loadbalancer),
g. une
redondance des données,
h. probablement
une DB noSQL,
i.
l'impossibilité de mettre en place un proxy
cache ...
Bref, un joli bordel pour le future CTO...
c-
Faire un cahier des charges fonctionnel. Si le
CEO est capable de rédiger un CDC, alors cela montre parfaitement que le
produit a été réfléchit (même si elle ne correspondra pas au produit final),
point par point, bouton par bouton ... c’est-à-dire de manière très précis. Par
conséquent, le CTO n'a plus qu'à définir le CDCT (cahier des charges
techniques) et réaliser le produit. De mon point de vu, méthodes Agiles sont
des méthodologies inappropriées dans le développement informatique en général.
La rédaction d'un CDC possède 2 vertus importantes :
a- se
poser le temps nécessaire pour définir un bon produit, le meilleur produit
b-
quantifier la masse de travail à fournir et déterminer
une deadline raisonnable (et cela est primordial pour une startup qui vie à
crédit ...)
4-
Toutes informations du future CEO (Diplôme,
certificat, CV , Bulletin de paie ...). De la même manière, le CTO doit avoir
la même démarche, pour plus de transparence. Au premier abord, cela peut
vraiment paraitre exagéré, mais il faut savoir que monter une boite avec un
inconnu (même s’il y a un très bon feeling), est extrêmement risqué. Une startup,
c'est 99% de galères, vaut mieux donc s'assurer que son partenaire ait les
reins solides et idem pour le CTO. Avoir une personne qui a fait ses preuves
dans son domaine est réellement rassurant. De plus, il faut savoir que le
parcourt du porteur de projet permet d'évaluer la pertinence du projet. Une
personne qui a travaillé 15 ans dans la communication, a plus de crédits si son
projet concerne son domaine, que moi même qui veut ouvrir une chaine de clubs
de Yoga. Deux types de profiles CEO
intéressants se semblent être pertinents parmi la tendance générales. Il y a
les jeunes d’Hec, et ceux qui connaissent leur domaines d’activité depuis
longtemps.
5-
Toutes informations attestant la participation (financière
ou autre) d'acteurs dans le projet. Cela peut être des comptes rendu, des
échanges de mails, des attestations, des documents administratifs ... Je
reviendrai ultérieurement sur ce point.
L'affinité du projet avec le CTO.
Minimiser
le risque et la pertinence d'un dossier ne doit pas être le seul facteur pour
choisir le projet. Le CEO et CTO vont collaborer durant plusieurs années pour accoucher
dans la douleur un produit, et si le produit (ou le domaine d’activité) n'intéresse
pas (ou peu) le CTO, il y a alors un réel risque d'abandon de projet de la part
du CTO. Malheureusement, les abandons sont très fréquents.
Le
domaine d’activité ou le produit en lui-même doit permettre de susciter la
curiosité du CTO en dehors des aspects purement techniques et financiers, voir
même l’envie d’apprendre un nouveau métier, de rencontrer les acteurs
économiques...
Etre humble et honnête face à son partenaire.
Il y
a quelques mois, j'ai rencontré un porteur de projet qui voulait améliorer la
notoriété de grands groupes en vendant une prestation au département
communication. Même si théoriquement l'opération est viable et intéressante, je
me suis permis de lui dire que les départements de communication sont les plus
mal lotis, est qu'ils n'ont pas de budget pour ce genre d'opération (en gros
pour être cash, il ne trouvera jamais de client).
A
vrai dire, je ne sais pas si j'ai raison ou pas, mais je sais que dans une
précédente expérience, un gérant d'une startup, n'a jamais trouvé de clients
pour mettre en place ce type d'opération (peut être qu'il manquait d'expérience
malgré son âge). Mais dans ce cas là, il faut avoir un réseau très qualifié, et
que ce n'est pas à la portée de tous. Bref, au fil de la discussion, j'ai été
considéré comme un simple développeur qui ne connait rien au business.
Au
travers de cet exemple, 2 points sont intéressants à analyser :
a- L'expérience
de 2 personnes qui provient de mondes différents ne peut pas créer une réelle
synergie par le respect des champs d'action de chacun. En effet, son collaborateur
peut apporter un éclairage pertinent sur certains points dans la compréhension
et sa vision de certaines problématiques. Les exemples se situent dans la
reformulation du problème par son partenaire, qui n'hésite pas à titiller les
faiblesses de raisonnement.
b- Un
projet ne peut se construire que si chacun fait l'effort écouter l'autre. Ce
qui veut dire in fine que le projet appartient au CEO et au CTO ! Ce sont par
des exemples/contre exemples et arguments/ contre arguments que le produit et
le business model s'affinent. Dans le domaine technique, les développeurs/ lead
développeurs / architectes qui me sollicitent pour mettre en place de nouvelles
technos/ nouveaux langages, nouveaux processus de développement. Ce type de
démarche est une très bonne chose car il est possible de remettre en cause des arbitrages
qui aujourd’hui ne sont plus forcément pertinentes. Cependant rares sont les
propositions qui sont finalement acceptées et mise en place. Pourquoi ? La réponse
est simple, il faut démontrer par A+B, que la technologie est meilleure que ce
qui est mise en place. Et pour qualifié la notion de 'meilleur', il faut
prendre en compte (la performance, la robustesse, la maintenabilité, l'affinité
du langage auprès des développeurs en interne et externe ...) Bref, il faut
écrire un livre blanc, et produire un énorme travail de fond, pour qualifier la
réelle pertinence d'une technologie et éventuellement l’adoptée. Dans cette
situation, le fait d’être l'avocat du diable permet de sélectionner les
meilleurs choix pour le projet.
L'honnêteté
n’a pas encore été abordée et pourtant, elle est une qualité essentielle pour
le CTO et CEO. On a tous droit à l'erreur, voir la succession d'erreurs en
cascade. Par contre, la malhonnêteté même si elle se porte sur un aspect
insignifiant, possède le vers destructeur de casser la confiance à jamais.
Le produit n'est pas un jouet ...
Au
fil de discussion sur une possible collaboration, le CTO peut avoir l'impression
que le porteur de projet n'attend qu'une chose : le produit. D'un côté c'est
normal, car il doit le vendre ou le viabiliser, le monétiser... Cependant, le
CTO ressent une étrange impression, cette impression que le porteur ne sera pas
quoi en faire. Je rencontre quelques CTO dans les meetup, qui me font part de
leur exaspérations de voir leur CEO, ne pas faire les efforts nécessaires dans
son domaine. Et en général, les CEO se plaignent de la mauvaise qualité du
produit, et évoque cette raison pour justifier la déroute du projet. Bref,
c'est le début d'un divorce ...
De
mon point de vue, ce sentiment étrange provient du manque de lucidité de la
part du CEO. En effet, ces derniers sont doués pour vendre un concept, mais peu
sont capable d'expliquer une stratégie commercial/marketing pour viabiliser le
projet à court terme. Car finalement, si le CTO livre une version du produit et
s'occupe des problématiques techniques, le CEO se doit de réussir le projet au
niveau financier et commercial.
La course contre la montre, tic-tac ...
Dans
un projet, il faut partir du principe que l'on peut compter uniquement que sur
soi même. Qui dit soi même veut dire uniquement les associés de la startup.
Si
un investisseur possède des parts dans la startup, alors, on peut compter sur
lui, même s'il a décidé de ne plus mettre un rond, son aide peut se
matérialiser par l'ouverture de son réseau par exemple ou sur d’autre forme.
Donc
en considérant que les CEO ont en général un capital limité (un fond propre),
ces derniers doivent faire le nécessaire pour commercialiser le produit avec
les moyens du bord, ou maintenir une croissance constante et élevée.
Côté
CTO, ce dernier doit tout mettre en œuvre pour que les coûts de développement
soit les plus faibles, tout en restant robuste.
Par
conséquent, les marges de manœuvres sont généralement faibles pour pondre un
produit rapidement et le rendre rapidement commercial. De ce que j'observe, le
meilleur couple (CEO/CTO) est composé de personnes matures, c’est-à-dire que la
maturité d’une personne n'est pas proportionnelle avec son âge, mais plutôt
avec sa capacité à connaitre et maitriser les moyens dont il dispose pour
arriver à ses fins.
Ainsi,
un développeur connaitra sera capable de déterminer la meilleur infra et
architecture logiciel ainsi que les technos associées pour développer le
produit. Idem pour le CEO au niveau marketing.
Au
vu du contexte exposé, le temps est compté pour réussir et les marges de
manœuvres sont faibles. Cependant, le succès tient en un déclic, et pour être
plus précis à une succession d’améliorations minimes, permettant un décollage
de l’activité. En réalité, c’est une décision (en générale anodine) qui viabilise
d’un coup l’activité de la startup. Cette décision sur le business peut autant
provenir d'une idée du CEO que du celle CTO, mais le succès provient du travail
acharné de chacun !
Le rêve n'est pas la réalité.
Dans
la section I.5, je parlais de la nécessiter de présenter, si c'est possible des
documents attestant la participation d'acteurs, ou de partenaires. Alors
pourquoi ? Parce que malheureusement un CEO, pour draguer un CTO, il lui vend
du rêve et que un CTO a une approche pragmatique du fait de la nature de son
travail. Finalement, le mieux est de lui présenter des éléments tangibles.
De
nombreuses personnes se prennent pour Steeve ou Markus, et s’exclament qu’ils
connaissent le directeur machin de mac do ou que mon oncle est le directeur truc
d’Orange ... De plus il faut savoir qu'une rencontre débouche en générale sur
pas grand chose, et surtout qu'une rencontre sur 500 mène éventuellement sur une
quelque chose de concret. Accompagner ses associés pour vendre un projet à un
partenaire/future associé, participer à une levée de fond sont des tâches
difficiles à réaliser, et il faut être acharné pour obtenir de résultats
intéressants. Il y a nulle besoin d’ajouter de la fioriture pour être crédible
aux yeux des autres.
Conclusion
Si t’es donc un CTO, alors tu dois pouvoir :
-
Lire un bon gros dossier bien fournit
-
Choisir un CEO d’expérience et qui a fait ses
preuves.
-
Avoir un bon feeling avec le CEO
-
Aimer le projet et le domaine d’activité.
-
Etre respectueux en vers l’autre.
-
Ne pas être considéré uniquement comme un
développeur
-
Ne pas écouter les bobards
-
Se donner à 200% pour trouver le déclic