Comment naît une fonctionnalité?

Comment naît une fonctionnalité et le temps de son développement

Une solution SaaS, telle que proposée par Regiondo, développe et améliore continuellement ses fonctionnalités pour répondre aux besoins actuels du marché. Les différentes niches du marché des loisirs nécessitent différentes fonctions et modifications. Les clients demandent souvent de nouvelles fonctionnalités ou alors c’est le changement du cadre juridique qui l’exige. Ce qui pourrait paraître facile d’un point de vue personnel, peut comporter de nombreux pièges cachés et s’avérer beaucoup plus compliqué que prévu.

Alors, combien de temps faut-il pour développer une nouvelle fonctionnalité pour votre système de réservation? C’est ce que nous allons voir aujourd’hui.

Savez-vous ce que signifie SaaS – Logiciel en tant que Service? Lisez notre article expliquant SaaS vs. Sur Site !

 

Exemple d’un processus de développement

01. Idée

Au sommet de la pyramide, une idée, ou la nécessité d’une nouvelle fonctionnalité ou même la mise à niveau d’une fonction existante. Elle peut provenir d’exigences juridiques, de clients ou du département produit. Avec de multiples demandes simultanées, il faut fixer les priorités car le nombre de programmateurs n’est pas infini. La priorité de la fonctionnalité a donc également un impact sur le temps de développement.

Lorsque nous développons une solution-tout-en-un pour le secteur des loisirs, nous rassemblons les demandes des clients pour de nouvelles fonctionnalités avant le développement de celles-ci et évaluons leur impact potentiel. Ainsi, nous nous assurons que les demandes d’un seul client (important) ne sont pas prioritaires mais sont adaptées aux besoins du marché.

02. Caractéristiques

Admettons qu’une demande a atteint la priorité numéro 1.

Quelqu’un doit alors émettre un ticket pour les développeurs. Le rédacteur de ce ticket peut faire partie du service clients ou de la gestion produit. Le ticket doit contenir toutes les instructions et caractéristiques dont les développeurs ont besoin pour coder la nouvelle fonctionnalité. Il ne s’agit pas de décrire juste une approximation de la fonctionnalité, mais l’exacte fonctionnalité avec tous les détails et les interdépendances.

Certaines fonctions ayant un énorme impact sur de nombreuses autres fonctions, cette étape du processus peut signifier beaucoup de travail et de temps pour le créateur du ticket.

Une requête peut également impliquer des sous-tickets supplémentaires. Quand la nouvelle fonctionnalité affecte différentes parties du système, des tickets distincts pour chaque nouvelle tâche s’imposent.

Le ticket pourrait aussi être le fruit d’une simple idée. Ce qui signifie que le créateur doit comprendre comment obtenir le résultat espéré avant que toutes les interdépendances soient appréhendées.

Un test est fait en interne et avec des clients sélectionnés, afin d’être plus confiant avec une nouvelle fonctionnalité et de recevoir un retour rapide.

Pour éviter un long processus de développement, nous essayons de réduire la complexité de nouvelles fonctionnalités à un minimum sensé. Il est plus facile et efficace d’étendre une fonction existante que d’en créer une nouvelle très complexe. L’investissement de temps et le risque encouru sont très élevés pour des fonctionnalités complexes et, de plus, il n’y a pas de retour d’information pendant le processus.

La plupart du temps, nous impliquons la partie prenante qui a suggéré la fonctionnalité, afin qu’elle apporte sa contribution et garantisse ainsi que différents points de vue sont inclus dans le processus. Après cela, il y a deux options:

  1. La partie prenante est d’accord avec la spécification.
  2. La partie prenante n’est pas d’accord et la spécification doit être révisée.

 03. Développement

Donc, une fois que la demande/idée a son ticket avec les spécifications, le développement peut commencer!

On continue parce que tout le monde est d’accord avec le résultat recherché. Le ticket est désormais avec le développeur.

Le temps requis varie selon le ticket. Après la création du code, un deuxième développeur analyse le code pour éviter les erreurs de logique, avant qu’elles ne puissent affecter quoi que ce soit.

Une fois le code analysé, le ticket part chez le testeur. Pour s’assurer que les processus de test n’endommagent pas la version actuelle de la solution de réservation, nous utilisons des tests d’environnement. Cela nous permet dans le cas de bugs (problèmes avec des fonctionnalités nouvelles ou existantes) de pouvoir les corriger avant de publier la nouvelle fonctionnalité.

 04. Tester et recueillir des retours d’information

Le testeur recueille des bugs potentiels et teste plusieurs scénarios (qui sont toujours nombreux et variées à devoir être testés pour être sûr que tous soient opérationnels).

Après la première session de test dans le premier environnement, il y en a un deuxième pour s’assurer que la nouvelle fonctionnalité opère correctement.

Quand il n’y a plus aucun bug dans les deux tests d’environnement, la fonctionnalité est prête à être publiée!

Normalement tout fonctionne bien, mais le testeur vérifie quand même la version publiée, juste au cas où.

Maintenant que la fonctionnalité est en ligne et que tous les clients peuvent l’utiliser, nous commençons à en recueillir les feedbacks. Ces retours d’information permettront de nouvelles mises à jour pour cette fonctionnalité ou la correction d’éventuels bugs précédemment inconnus.

Comment des bugs pourraient-ils survenir lorsqu’une nouvelle fonctionnalité est en ligne après des tests dans différents d’environnements?

La raison en est la diversité du secteur des loisirs. Les utilisateurs de Regiondo ont trouvé d’innombrables façons de présenter leurs offres de loisirs dans leur billetterie et il y a d’innombrables scénarios associés à ces présentations.

La qualité nécessite du temps

Comme vous pouvez le constater, nous effectuons un contrôle de qualité complet avant d’introduire de nouvelles fonctionnalités.

Ceci, bien sûr, requiert temps et main-d’œuvre.

Si vous attendez une nouvelle fonction, nous vous prions d’excuser la longueur du développement ou la nécessité de retravailler certaines fonctions. Cela fait partie d’un système complexe tel que peut l’être Regiondo.

Nous nous efforçons chaque jour de vous fournir les meilleures fonctionnalités dans les meilleurs délais.

Regiondo travaille en continu sur de nouvelles fonctionnalités et extensions. Consultez nos nouvelles fonctionnalités et mises à jour. 

 

À propos Alexander Bechte
Alex is Regiondo's Product Marketing Manager and passionate about traveling and digitalization. He is from Hamburg and studied tourism management in Munich. His aim is to inform you about the product side of Regiondo to improve your business!
Tous les articles par Alexander Bechte

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *