Fin
8 ans d’existence officielle, 10 ans que nous nous sommes retrouvés dans un bar avec quelques collègues pour démarrer des discussions qui allait amener à la création d’Arpinum…
Nous mettons un point final à l’aventure Arpinum, et nous nous sommes dit que ça méritait tout de même à la fois une petite explication, et à la fois une petite rétrospective sur ces 8 dernières années.
Début
C’est bien entendu un cliché, mais nous démarrons en fait une nouvelle aventure. La totalité de l’équipe Arpinum devient legolas, avec comme mission, en plus bien sûr de fabriquer la plate-forme, de reproduire toute notre culture. Oui toute, ne vous attendez pas à ne plus entendre parler de nous dans les années à venir.
Pourquoi
Nous avons tout de même pas mal cogité bien sûr avant d’accepter. Pour être tout à fait transparent, Arpinum ne souffre pas vraiment de soucis financiers, nous travaillons sur des produits que nous choisissons, dans les conditions qui nous semblent nécessaires pour réussir. Nous allons aux conférences qui nous plaisent, nous avons tous nos vendredis pour faire ce qui nous plaît… Bref, ça ressemble à la vie idéale non ?
Nous n’avions cependant jamais fermé la porte à la possibilité un jour de nous concentrer à nouveau sur un seul projet, car on ne va pas cacher que la vie d’un atelier logiciel sans concession est parfois… rude. Comment gérer le flux des projets sans léser personne ? Comment aménager des pauses dans les produits qui en ont besoin ? Ok nous arrêtons de coder sur ce produit, mais il faut donc en démarrer un autre. Mais quand reprendre le travail sur le premier ? Comment faire grossir Arpinum quand nous travaillons autant à flux tendu ? Nos expériences mitigées en recrutement nous ont montré que nous n’avions pas le temps de former convenablement : 1 jour de perdu sur un projet de startup est un jour impossible à rattraper (sauf bien sûr, en travaillant soir et week-end, et en annulant nos vacances, ce que nous avons du faire un peu trop de fois).
Ce manque de temps chronique fait que nos chers vendredis étaient souvent utilisés à faire le commercial ou l’administratif de la boîte, et que nos projets annexes qui nous tenaient à cœur (les formations, via arpinum.school, écrire un livre…) n’avaient juste pas l’opportunité de voir le jour.
Donc, quand Ouziel nous a approché pour embarquer toute l’équipe dans son aventure, nous n’avons pas rejeté l’offre d’un revers de main, surtout que nos visions respectives sur le monde des cryptos sont plus qu’en phase. Le test ayant été concluant, voilà donc un peu la proposition qu’il y avait sur la table :
Venir prendre la tête d’une startup crypto bien pensée (pas un scam…), bien financée, y apporter notre culture, notre connaissance du domaine, du DDD, d’XP, le tout en gardant notre autonomie et nos bâtons de pèlerin.
Je ne vois pas comment dire non à ça personnellement. Comme toute décision chez Arpinum, elle a été prise de manière collégiale, et vous connaissez le résultat.
Rétrospective
Je pense que je ne vais pas avoir la place ici de m’étendre autant que je voudrais sur cette décennie Arpinum. Faisons une version courte, et peut-être que cela méritera une suite d’articles après, on verra.
Quel était notre but ? Nous avions un plan, irréaliste, en trois étapes :
- Se former sans concession à pratiquer l’eXtreme Programming, et le DDD
- Prouver que cela fonctionne parfaitement, via la réussite commerciale de notre premier produit : Tiron
- En s’appuyant sur ces connaissances, faire de la formation, du consulting, conférences, ateliers, pour petit à petit diffuser ce savoir faire, et faire en sorte que de moins en moins de personnes souffrent dans le monde du développement.
Notre chemin n’a pas exactement ressemblé à ça au final. Tiron n’a jamais vraiment été un succès commercial, mais nous avons à peu près fait tout le reste, et notamment, prouver que oui, bon dieu, c’est possible de faire ce travail autrement. Oui c’est possible de prendre du plaisir à faire ce métier, sans pour autant tomber dans le cliché du développeur qui veut juste coder pour se faire plaisir dans son coin. Oui c’est possible de faire le plus simple qui fonctionne, et de l’améliorer par refactorings successifs. Oui c’est possible de se tromper, et de survivre à ça. Oui c’est possible de faire du TDD et du pair-programming à longueur de journée. Oui c’est possible de refuser des cahiers des charges irréalistes, décrivant des solutions rocambolesques inventées par des personnes n’ayant jamais codé de leur vie. Oui c’est possible de convaincre des clients de travailler sans ce fameux cahier des charges, sans s’engager sur un périmètre, un coût et un délai. Oui c’est possible de faire ça avec des startups comme avec des grands comptes. Oui un monde ou les SSII/ESN ne contrôlent pas et ne distordent pas le marché est possible. Oui il est possible de faire tout ça sans être un individualiste forcené, mais en partageant gratuitement ses découvertes à chaque étape, en participant à la vie d’une communauté comme Okiwi.
Cette aventure a été incroyablement jouissive pour ça, ainsi que pour toutes les rencontres, tous les débats, toutes connaissances apprises et oubliées, et nous comptons bien faire en sorte que les 10 prochaines années soient exactement pareilles, mais en fois 10.
