Travailler avec des contraintes

Récemment, une page s'est tournée, car l'une de mes premières boites a fermé : Lateral-Thoughts, ou LT pour les intimes, petite entreprise dont j'ai participé à la fondation en 2011 et qui a été un catalyseur pour moi.

Je pourrais citer les nombreuses personnes qui y sont passées et qui m'ont marqué. Celles avec qui j'ai continué de travailler chez Malt. Je pourrais passer un temps fou à expliquer le fonctionnement de cette boite, sans aucun management, avec que des devs et qui a contribué à semer les jalons d'un nouveau rapport au travail.

Mais pour ce billet, j'ai envie d'aborder une leçon, parmi beaucoup d'autres, que j'ai tiré de LT lorsque j'y étais : l'importance des contraintes.

Sans contraintes, pas d'alignement

L'un des objectifs de LT c'était de faire du soft. Enfin, je reformule, l'un des objectifs de certaines personnes chez LT, c'était de faire du soft.

C'était une entreprise collaborative basée sur les principes de la sociocratie. Donc il n’y avait pas un big boss qui disait que LT devait créer un software. Mais il y avait un consensus, discuté et voté et nous souhaitions financer le développement logiciel par la prestation de service.

Nous mettions donc de côté des sous pour financer des projets internes.

Et il en est sorti plusieurs, certains plus proches de sides projects que de vrais produits mais il y a eu de superbes idées qui ont fusé. L'un de ces sides projects, ce fut Malt. Mais ceci est une autre histoire.

Toujours est-il que LT n'est pas devenu Atlassian ou Basecamp. Mais pourquoi donc ?

Je me rappelle encore des timeoffs incroyablement productifs et d'une session de travail en particulier chez l'un d'entre nous.

A l'époque, l'un des constats, c'était que nous avions trop de side projects. Il existait plus d'un side project par membre de la boîte ! Si on voulait aller plus loin, il fallait réussir à fédérer plusieurs personnes sur le même side project.

Chacun est venu présenter un lean canvas, inspiré en cela par le format découvert grace à Camille Roux.

La journée a été super sympa, très productive. Et vous savez quoi ? A l'opposé du plan prévu, de nouveaux projets ont germé :)

En fait, ce jour-là, je me suis rendu compte d'une chose, pour faire ce fameux produit commun, il fallait qu'on ait faim.

En réalité nous n'avions pas l'inconfort, les contraintes qui nous poussent à aller plus loin.

Le modèle financier de LT redistribuait la quasi-totalité des revenus aux membres donc si vous prenez un TJM moyen entre 500 et 1000 pour la plupart des personnes, tout le monde s'en sortait très bien.

A quel moment, quand tu gagnes entre 5 et 10k par mois net, tu te dis que tu vas prendre un risque sur un side project ?

Pourquoi se mettre dans une situation inconfortable dans ces conditions ?

J'ai des éléments de réponse puisque j'ai choisi de le faire pour Malt. Mais, ce n'est pas si évident que ça de franchir le pas. Ces projets dans LT ne pouvaient rester qu'un jeu et un très bon moyen de veille malgré tout.

Finalement, aucun de ces softs n'a vu le jour au sein de LT. Des produits sont nés avec les membres de LT, mais en dehors.

Ce fut donc la première fois que je voyais l'importance de ces contraintes.

Sans contraintes, pas de réelle innovation

Plus tard, dans une mission de prestation et toujours avec LT, j'ai rejoint un projet chez un grand groupe industriel. Le projet était très ambitieux, avec des finances très importantes (pas mal financé par la BPI). Il regroupait de multiples sociétés au sein d'un conglomérat, des universitaires etc...

À partir de là, je vais donner un point de vue d'une personne parmi des centaines d'autres donc sans doute qu'il me manque beaucoup d'éléments pour être objectif.

Ce projet semblait n'avoir aucune contrainte. Pas de date particulière fixée, pas de limites budgétaires, pas de limitations sur le scope, on en rajoutait sans arrêt avec des idées assez farfelues bien souvent. La boite pour laquelle je travaillais avait même racheté une startup US pour le soft et le contenu qu'elle avait produit. Bref, une débauche de moyens.

Et ce projet, eh bien, il n'a été nulle part. La boite US rachetée n'a pas apporté de valeur et le produit a été tué. Plusieurs partenaires du conglomérat se sont progressivement désengagés.

Le problème principal, tout du moins ressenti par les équipes, c'était une direction totalement floue. Car qui dit absence de contraintes, dit éparpillement. Beaucoup de prestataires sont passés, on a bossé sur des problèmes très complexes qui en réalité n'existait pas, parce que pour avancer on se fixait nous même des contraintes, complètement hors sol.

Ce projet n'avait aucune chance d'aboutir.

Ce fut la seconde fois que je voyais nettement en quoi l'absence de contrainte peut tuer un produit.

Poser des contraintes dans une organisation engineering

Les contraintes sont donc bénéfiques. Elles forcent à faire des choix, à définir là où on investit ou pas. Ne pas faire de choix, ne se poser aucune limite, c'est l'assurance de s'éparpiller.

Si je ramène ça au développement logiciel, c’est crucial de se donner des contraintes. Une date est une contrainte, un scope est une contrainte, un niveau de qualité est une contrainte, un objectif business chiffré est une contrainte.

Cela peut générer du stress, mais cela va aussi provoquer l'émergence de solutions intelligentes pour tenir les contraintes.

Mais, en réalité, sauf cas exceptionnel, toute organisation a déjà des contraintes. Le rôle des Tech Leaders c'est de les faire ressortir. C'est justement parce que certaines organisations tech n'en ont pas conscience qu'elles finissent par échouer.

Elles n'ont pas conscience des contraintes financières, des attentes des utilisateurs ou des attentes du marketing. Et tout cela mène systématiquement vers une situation désastreuse dont les symptômes ressemblent plus ou moins à cela :

• perte de confiance des équipes marketing (et produit parfois), qui prennent le contrôle complet sur la définition du produit
• perte de confiance de l'entreprise qui préfèrent se tourner vers des partenaires externes (agences de développement)
• manque d'investissement dans la tech qui n'est pas vu comme sérieuse dans sa gestion financière etc...

Alors, qu'est-ce que j'entends par "poser des contraintes" ?

Le ou la Tech leader doit aider à clarifier les contraintes, les rendre visibles.
Est-ce qu'il y a une contrainte temporelle forte ?
Quelles sont les contraintes technologiques ? De quel budget dispose-t-on ?

Clarifier c'est aussi être capable de confronter et d'expliquer que telle contrainte n'est pas compatible avec telle autre. Par exemple la contrainte du mois prochain n'est pas compatible avec le contenu demandé et/ou le budget alloué.

L'organisation tech qui réussit à faire émerger ces contraintes, les formaliser et les partager, est une organisation qui instaure une relation de confiance et qui se met dans de bonnes conditions pour créer de l'impact.

Pour conclure et parce que je trouve le lien avec ce billet plutôt pertinent, je vais citer un passage du livre "Rework".

Send people home at 5

When people have something to do at home, they get down to business. They get their work done at the office because they have somewhere else to be. They find ways to be more efficient because they have to. They need to pick up the kids or get to choir practice. So they use their time wisely

Questions

Comment définiriez-vous les contraintes de votre organisation ? Sont-elles financières, temporelles, techniques, business, humaines ?

Plutôt de les voir comme une contrainte, quelle est la dernière fois que ces contraintes vous ont forcé à trouver des solutions intelligentes ?

Ressources

• Accepter l'ennui
• Choisissez vos batailles
• Rework
• side projects vs real products
• le lean canvas