Documenter une base FileMaker (1)

Donner des indices de ce que l’on fait…

Dans la chronique que j’ai envoyé aux membres et aux abonnés ce lundi (1), j’écrivais qu’il est bien de savoir que l’on peut travailler à plusieurs lorsqu’on est indépendant, mais que c’est encore mieux de savoir comment !

La semaine dernière (2), nous avons vu assez longuement ce « comment », à travers trois formes de travail collaboratif.

Dans cet article, je précise qu’il est nécessaire de s’accorder sur une nomenclature commune, pour que la base soit cohérente et utilisable facilement par tous les développeurs.

Dans le même ordre d’idée, je souhaite souligner aujourd’hui un autre aspect important favorisant une communication fluide entre développeurs : celui de documenter sa base !

Documenter, en quoi cela consiste ?

Cela consiste, partout où cela est possible et nécessaire, à donner des indications concrètes sur le « pourquoi du comment » : faire un commentaire dans un calcul (mais oui, c’est possible !) pour décortiquer une fonction un peu compliquée, dans un script indiquer en en-tête d’un groupe d’actions ce que ces actions sont censées faire, etc.

Est-ce bien nécessaire ?

Pris par l’urgence d’un délai, ou encore restreint dans un budget qui ne lui permet aucune fantaisie, le développeur indépendant est parfois tenté de passer outre cette recommandation.

Commenter ou ne pas commenter sa base ne change rien en effet à la performance de cette dernière. Lorsqu’il exécute un script par exemple, FileMaker « saute » les lignes qu’il trouve précédées d’un #. Les commentaires ne lui sont pas destinés, elles le sont au développeur. Par exemple :

Or, le développeur a deux présupposés :

• Commenter une base prend du temps, et du temps, il n’en a pas. Il doit aller droit au but, et ne pas s’égarer vers des choses non indispensables.
• Puisque c’est lui qui l’a développée, il se souviendra de ce qu’il a fait et pourquoi lorsqu’il reprendra cette solution pour par exemple la mettre à jour…

Le temps consacré à la documentation…

C’est vrai que commenter une solution prend du temps. Cependant, il ne faut pas non plus exagérer : quelques minutes suffisent à noter une information. Et ces précieuses minutes nous en font gagner tant !

Pourtant, c’est quand même une question, notamment d’un point de vue commercial.

Car il y a des présupposés, tant du côté du développeur que de celui du client.

• Le développeur pense que documenter une base n’apporte pas de valeur ajoutée. Autrement dit, ne vaut rien. De son point de vue, c’est un travail qu’il effectue éventuellement pour gagner du temps ultérieurement, mais qu’il ne pourra jamais vendre au client.
• Le client quant à lui, s’attend, parce qu’il s’adresse à un indépendant, à être moins facturé que s’il l’était par une entreprise. Dans son esprit, un indépendant a moins de frais qu’une entreprise et donc coûte moins cher. Et le développeur indépendant fait tout pour correspondre à cette image et répondre à l’attente du prospect ou du client, pour le gagner ou le conserver. D’où ses réticences à passer du temps à faire quelque chose qu’il ne pense pas devoir facturer.

Or, d’une part le travail que fait le développeur pour augmenter la qualité d’une solution a valeur et peut être facturé comme tel.

Et d’autre part, il n’est pas certain que vendre en-dessous d’un seuil de rentabilité pour obtenir de nouveaux clients soit la bonne stratégie ! Beaucoup d’indépendants l’ont appris à leur dépens…

Vendre son temps, y compris celui non productif

Pour vous faire comprendre comment et pourquoi vendre le temps que l’on passe à documenter sa base, je vais vous raconter une petite histoire.

Cette histoire, triste mais qui se termine malgré tout pas trop mal, s’inspire de cas réels.

Elle vous illustre sans doute mieux qu’un long discours ce qui pourrait arriver à vos clients si vous vous trouviez un jour en incapacité de suivre ce que vous avez développé pour eux.

Bien entendu, je ne vous souhaite pas de connaître une telle situation. Mais il est de votre responsabilité de poser la question de la pérennité de votre développement. Surtout si celui-ci est vital pour l’entreprise de votre client ! Or, le seul moyen de l’assurer est d’en anticiper la transmission, même à un développeur inconnu !

Se donner les moyens d’une transmission concerne bien entendu la communication des codes d’accès – login et mots de passe administrateur et/ou développeur – mais également les procédures de développement, c’est-à-dire tout ce que nous avons appelé jusqu’à présent « documentation » de la base (3).

Anticiper ceci est alors comme proposer une « assurance » à laquelle souscrirait votre client pour la pérennité de sa solution et des données qu’il y saisit. Ceci est une réelle valeur ajoutée. Que vous pouvez donc deviser et facturer 😉

Investir dans l’avenir

Allons plus loin encore…

Lorsque le développeur documente sa base « pour lui », c’est-à-dire parce qu’il sait que cela lui rendra service à terme, il fait un investissement pour l’avenir.

Je m’explique.

À l’inverse de son présupposé n°2 énoncé ci-dessus (il se souviendra plus tard de ce qu’il a fait), l’expérience montre que le plus souvent, dès qu’un calcul ou un script est un tant soit peu complexe, le développeur a oublié ce qu’il a fait ou voulu faire. S’il a pris soin de documenter sa base, même partiellement, cela lui fera gagner du temps et donc de l’efficacité pour la poursuite ou la reprise du développement.

Cet argument est d’autant plus important qu’aujourd’hui, les développements sont le plus souvent réalisés en « méthode agile », module après module. On réalise un module A, puis un module B, puis un module C, avec toutes les allées et venues nécessaires entre le maître d’oeuvre et maitre d’ouvrage… Tout ceci prend énormément de temps, plusieurs semaines, voire plusieurs mois… Si, pour utiliser des données du module A, le développeur a besoin d’y accrocher le module C, il doit pouvoir trouver dans le module A une documentation suffisamment précise pour comprendre comment cela fonctionne et y développer les extensions nécessaires au module C !

Je suis sûre que vous avez bien des exemples en tête permettant de montrer comment une documentation peut représenter un gain de temps appréciable et donc être un réel investissement gagnant-gagnant pour vous comme pour votre client !

Et si vous présentez les choses sous cet angle, je suis sûre que votre client vous écoutera 😉

Alors, si vous êtes prêt, je vous dirai demain COMMENT on documente, après vous avoir exposé aujourd’hui POURQUOI !

Marie-Charlotte Potton

(1) : Vous ne savez pas à quoi correspondent visiteurs, membres et abonnés de ce blog ? Vous ignorez ce à quoi ils ont droit ? Lisez l’article Visiteur, membre, abonné…

(2) : voir article Travail collaboratif sur FileMaker (2)

(3) : l’exemple donné ci-dessus est bien entendu un exemple extrême. On peut aussi anticiper une succession dans le cadre d’un départ à la retraite ou d’un changement d’activité 😉

Article suivant

Tags: Développement FileMaker, Documenter