Deux produits, une petite équipe, et un besoin simple : planifier des sprints d'une semaine sans y passer ma vie. En trois mois, j'ai écrit Kandesk.
Je suis Head of Product & Engineering. Je décide ce qu'on construit, je manage une petite équipe et je continue à coder. Avec deux produits à piloter, un site web et une application mobile, il me fallait un outil de pilotage. Pas un de plus : le bon.
Ce dont j'avais besoin
De la simplicité. Pouvoir monter des sprints d'une semaine en quelques minutes, et donner de la visibilité aux équipes non techniques, qui n'ont ni l'envie ni le temps d'apprendre un outil de développeur.
Aujourd'hui, mes sprints sont planifiés. Quand un ticket monte en priorité, je le réorganise en deux clics. C'est ça que je voulais : un outil pragmatique et instinctif.
Ce que fait Kandesk
un kanban par produit, avec des sprints d'une semaine
une roadmap en frise : les dates d'un epic suivent celles de ses sous-tickets
le suivi des bugs, avec capture d'écran, signalés par n'importe qui dans l'équipe
la charge de chacun, pour répartir le travail avant que quelqu'un coule
une boîte à idées, nourrie par la réunion hebdomadaire
une veille technique et produit, alimentée par des flux RSS
une data de production : l'effort par produit mois après mois, les bugs (arrivés, corrigés, délai médian) et le rythme de livraison semaine par semaine
La gestion de projet et celle des bugs vivent au même endroit. Ce n'est pas un outil générique, ni lourd à mettre en place : il est fait pour nos façons de travailler, et seulement pour elles.
Ce qu'en pense l'équipe
Ils le trouvent plus facile d'accès et plus dynamique. La veille, que j'ai ajoutée, est un petit plus apprécié.
Une décision : couper GitHub
Au début, Kandesk se posait au-dessus d'un GitHub Project : il le lisait et y réécrivait mes décisions. Ça marchait, mais j'avais deux sources de vérité, avec leurs cas bizarres. Le 2 octobre, j'ai coupé le lien. Les tickets naissent maintenant dans Kandesk. GitHub ne garde que le code et les pull requests, dont Kandesk lit l'état (CI, review, conflits).
Je l'aurais fait plus tôt. Certains cas tordus m'ont coûté du temps pour rien.
Sous le capot
Rails, Hotwire pour l'interface, PostgreSQL pour tout, y compris la file de jobs : pas de Redis, pas de serveur en plus. Un seul dyno Heroku. Environ 350 commits et 880 tests, et rien ne part sans qu'ils soient au vert.
Je pourrais le faire évoluer pour tester Inertia et React avec Rails, mais ce n'est pas une urgence.
Ce que j'en retiens
Pour faire un produit apprécié et efficace, il faut se heurter aux difficultés des utilisateurs. Le terrain est toujours la source de vérité.
Et j'aurais dû construire cet outil bien plus tôt : le gain de temps et de productivité est réel, pour tout le monde.
