Pourquoi j'ai construit ma première application pour moi-même

J'avais ma propre équipe de développement, mais elle croulait sous les projets clients. Quand j'ai eu besoin d'un outil pour reprendre la main sur ce qui se passait dans l'entreprise, je n'avais personne à qui en confier la construction. Alors je m'y suis mis moi-même.

En apparence, c'était un choix dicté par la nécessité. Au fond, c'était la meilleure chose qui pouvait m'arriver en tant que futur développeur. Car cela m'a appris quelque chose qu'aucun cahier des charges ne peut enseigner.

J'étais à la fois le client et le constructeur

Quand vous construisez un logiciel pour vous-même, la boucle de retour est immédiate et impitoyable. Chaque mauvaise décision de conception me rattrapait le lendemain matin, à mon propre bureau. Un écran mal pensé - j'y perdais mon propre temps. Un champ oublié qui s'avérait important - je ressentais moi-même le manque. Il n'y avait aucun « client » pour soulever un point deux semaines plus tard en réunion de suivi. Le client, c'était moi, et la réunion de suivi se tenait chaque matin dans ma tête.

Ce système avait quatre fonctions, et chacune répondait à une douleur précise que je connaissais de l'intérieur : savoir sur quoi les commerciaux travaillaient vraiment ; prévoir quand une machine installée chez un client allait commencer à poser problème ; mesurer si quelqu'un ouvrait vraiment nos e-mails ; tenir les budgets et les délais. Il n'y avait pas une seule fonction « au cas où », parce que personne ne me payait pour ajouter des fonctionnalités. Je me payais moi-même - avec un temps dont je manquais cruellement.

Un logiciel écrit par celui qui l'utilise est différent

Un programme construit par une personne qui s'en sert elle-même a une autre densité. Il ne contient aucune fonctionnalité ajoutée pour faire meilleure impression dans une présentation commerciale. Il n'a pas deux cents paramètres dont vous n'utilisez que cinq. C'est la réponse à un processus réel, éprouvée sur le terrain par quelqu'un qui connaît ce processus sur le bout des doigts.

C'est la différence que les dirigeants perçoivent immédiatement, même s'ils ne savent pas la nommer. Entre un logiciel que quelqu'un vous a adapté après deux conversations, et un logiciel né d'une compréhension intime de votre problème.

Pourquoi cela a changé ma façon de travailler aujourd'hui

J'ai aujourd'hui derrière moi plus de dix ans de construction de systèmes pour d'autres entreprises. Pourtant, je commence toujours chaque projet de la même façon : je me place du côté du dirigeant et j'essaie de ressentir son processus comme s'il était le mien. Avant de proposer quoi que ce soit, je veux comprendre ce qui le gêne le matin à son bureau - parce que je n'ai pas oublié cette douleur de 2008.

Je construis pour mes clients comme j'ai construit pour moi : exactement ce qu'il faut, avec un code et des données qui restent chez eux. Les plus importants d'entre eux travaillent avec moi sans interruption depuis de nombreuses années, et chaque collaboration a commencé par un seul problème opérationnel qui leur pesait vraiment.

Ce que cela signifie pour vous

Si vous cherchez quelqu'un pour vous construire un système, soyez attentif à un point. Voyez si cette personne vous interroge sur votre processus avant de parler de la solution. Si elle cherche à comprendre ce qui fait mal avant d'esquisser un écran. Un bon système commence par quelqu'un qui comprend vraiment ce que vous cherchez à atteindre et qui le ressent comme son propre problème - la technologie vient ensuite.

J'ai construit mon premier système pour sauver ma propre entreprise. Depuis, je construis ceux des autres avec le même soin. Si vous le souhaitez, parlez-moi de votre processus pendant trente minutes - je commencerai par le comprendre.