Processus clair.
Meilleur résultat.
Comprendre. Planifier. Construire. Faire grandir. Quatre phases qui font d’une idée quelque chose qui dure – et une conversation honnête au départ, où se décide s’il faut construire tout court.
Pas de magie.
Du travail propre.
Chaque projet passe par les quatre mêmes phases, qu’il s’agisse d’un petit outil interne ou d’un système dont dépend toute une entreprise. La durée de chacune dépend du projet – le fait qu’elle ait lieu, non.
Comprendre
Nous commençons par le problème, pas par la solution. Pour qui est-ce, qu’est-ce qui bloque, et qu’est-ce qui serait réellement mieux ?
Planifier
Périmètre, architecture, budget. Nous traçons l’itinéraire avant que quiconque écrive du code – les surprises restent ainsi petites.
Construire
Itérations courtes, logiciel qui tourne, pas de boîte noire. La chose grandit au vu de tous au lieu d’être dévoilée à la fin.
Faire grandir
La mise en ligne est le début. Nous mesurons, affinons et maintenons le produit en vie longtemps après la première version.
D’abord le problème,
ensuite l’idée.
Lors du premier entretien, nous nous jaugeons mutuellement. De quoi s’agit-il, et sommes-nous les bonnes personnes pour le faire ? Si ce n’est pas le cas, le dire tôt coûte moins cher à tout le monde que de s’en apercevoir tard.
Et nous voulons plus que l’idée – nous voulons les processus derrière. Ce n’est qu’après avoir fait les cent pas proverbiaux dans les chaussures de l’autre que l’on peut dire ce qu’il faut construire et ce qu’il vaut mieux laisser.
Nous contredisons
Dans cette phase, nous sommes des partenaires de réflexion, pas des exécutants. Nous pensons avec toi et nous contredisons quand nous avons une meilleure proposition – et nous retournons l’approche jusqu’à ce que tout le monde soit convaincu d’avoir trouvé la bonne.
Un ordre de prix avant de commencer
Dès que l’enjeu est clair, nous faisons une première estimation pour un ordre de prix. Si la grandeur convient, on continue. Sinon, la conversation aura tout de même servi à quelque chose.
Tracer l’itinéraire
avant de prendre la route.
Lors de l’atelier de lancement, nous clarifions le périmètre, élaborons ensemble les détails, posons des jalons et fixons un calendrier. Ce qui en sort n’est pas un papier pour le classeur, mais la base d’une offre ferme.
L’estimation devient une offre
Avec le cahier des charges établi ensemble, la première estimation se précise, ce qui manque s’ajoute et l’offre définitive se calcule. Deux étapes plutôt qu’un chiffre lancé au jugé – et la seconde tient.
L’architecture aussi, c’est de la planification
Jusqu’où cela doit-il grandir ? Quelle forme ont les données ? Qu’est-ce qui doit être relié ? Ces questions ont leur place ici, et pas en troisième semaine de développement, où la réponse coûte cher.
Grandir à la vue de tous,
pas derrière le rideau.
D’abord des wireframes, puis des maquettes et des prototypes, toujours en étroite collaboration. Ensuite on développe et teste en continu, les nouvelles idées sont discutées et reprises au lieu d’être renvoyées à une deuxième phase qui ne vient jamais.
Il n’y a pas de moment où quelque chose de fini est dévoilé. Il y a beaucoup de moments où quelque chose d’à moitié fini est discuté. C’est plus inconfortable et ça donne de meilleurs résultats.
Vérifié, pas supposé
Quand nous pensons avoir vu juste, nous le vérifions avec de vrais utilisateurs. Nous regardons à chaque étape et voyons où ça coince – le plus souvent à un endroit que personne n’aurait soupçonné, et c’est bien pour ça que regarder en vaut la peine.
Celui qui construit parle aussi
Pas de couche de conseil au milieu, pas de téléphone arabe entre le briefing et le développement. Les questions vont directement à la personne qui écrit le code – la raison principale pour laquelle de petites équipes peuvent être plus rapides que de grandes.
La mise en ligne,
c’est le début.
Après les tests, le produit passe en production. Ensuite nous le maintenons en marche et le faisons évoluer – ce n’est pas une option supplémentaire, mais la partie où se décide si l’investissement en valait la peine.
L’exploitation fait partie du lot
Mises à jour, monitoring, sauvegardes et un numéro où quelqu’un décroche. La plupart de ce que nous construisons tourne sur notre propre infrastructure dans la région de Berne – la réponse à « qui peut aller voir maintenant » est donc rarement compliquée.
Les meilleures extensions viennent de l’usage
Pas d’un atelier de roadmap, mais d’une phrase lancée au détour du travail. Ce sont ces ajouts-là qui sont utilisés, parce que quelqu’un les a d’abord regrettés.
Plutôt montrer une fois
de plus que décrire.
Avant de construire, nous rendons les choses visibles : des croquis, une maquette cliquable, un prototype qui se comporte déjà à peu près comme le produit fini. C’est du travail en plus au début, et nous le prenons volontiers sur nous – une décision prise devant quelque chose que l’on voit vraiment n’est pas la même que devant une description.
Une modification dans le prototype coûte une heure. La même modification dans le logiciel fini coûte une semaine. Tout l’argument est là.
Ce qui en ressort
Le même chemin,
quoi que l’on construise.
Un site web, une application, un système dont dépend toute une entreprise, un bout d’AI dans un processus existant – cela ne change rien aux quatre phases. Seulement à la longueur de chacune.
Ce que nous construisonsCe dont nous nous
occupons aussi.
Tout commence par
une conversation.
Aucune préparation nécessaire, aucun cahier des charges exigé. Décris ce qui te bloque – le reste, c’est notre travail.