PQFORCE est utilisé quotidiennement par de nombreux utilisateurs dans divers environnements clients et sur de nombreux sites. PQFORCE est utilisé pour planifier des projets, rechercher et allouer des ressources, gérer les absences et bien plus encore. Chaque utilisateur a des fonctions et des vues de données différentes dans son rôle. Il est donc logique que des idées surgissent régulièrement sur la manière de rendre l'application encore meilleure, encore plus rapide, encore plus conviviale. Comment devons-nous, en tant que fournisseur, faire face à cette situation ?

Chez INTRASOFT, nous maintenons une ligne très directe avec le client. Pour nous, les clients ne sont pas simplement des entités abstraites et payantes, mais une multitude d'utilisateurs individuels ayant des besoins individuels. En particulier dans la phase actuelle de développement du marché, nous prenons très au sérieux les besoins de ces clients. Mais qu'est-ce que cela signifie concrètement ?

Jetons simplement un coup d'œil à notre processus de développement. Fondamentalement, nous développons PQFORCE comme un produit standard le long d'une voie de diffusion. Il n'existe pas de branches spécifiques aux clients (voir aussi cet article). Les nouvelles versions de PQFORCE sont développées toutes les quelques semaines - en fonction de leur portée - et mises à la disposition de nos clients. Le développement d'une version se déroule selon les phases suivantes.

Capturer les exigences : Au commencement est l'idée

Les nouvelles exigences découlent presque toujours des idées des utilisateurs. Notre principe est le suivant : seuls ceux qui utilisent PQFORCE au quotidien peuvent réellement déterminer ce qui manque encore ou comment on pourrait tirer encore plus de l'application. Nous prenons en compte ces idées et ces souhaits - généralement dans le cadre de projets pilotes avec les clients. C'est la période pendant laquelle une équipe sélectionnée d'utilisateurs pilotes utilise PQFORCE et teste la meilleure application possible pour le client. Nous sommes présents sur place lors de ces projets pilotes, formons et conseillons les utilisateurs, écoutons attentivement et recueillons ainsi de nouvelles idées. Ces idées sont ensuite inscrites dans une liste. Ils y sont formulés sous forme d'exigences commerciales aussi neutres que possible par rapport à la solution, sous forme de cas d'utilisation.

Consolidation et hiérarchisation : des solutions largement applicables pour tous les clients.

Au cours de cette phase, le grand pot de nouvelles exigences est soigneusement examiné. Les exigences individuelles sont formulées de la manière la plus neutre possible en termes de solutions, et dans certains cas, elles sont également regroupées et consolidées. Ensuite, à partir de cette liste, un paquet est constitué avec les exigences qui seront mises en œuvre ensemble dans une nouvelle version. Des propositions concrètes de mise en œuvre sont également élaborées. Il peut s'agir de conceptions d'écran, par exemple, qui représentent une interface graphique à réviser. Ces concepts de mise en œuvre sont développés en tenant compte d'un haut degré de flexibilité et de durabilité et, si nécessaire, également soumis au client (fournisseur d'idées) pour examen. L'objectif ici n'est jamais de créer une solution précise pour un seul fournisseur d'idées, mais plutôt une solution qui apporte une valeur ajoutée à tous les clients, qui est "adaptée aux masses" et qui s'intègre dans la norme.

La liste des exigences commerciales et l'ensemble des exigences à mettre en œuvre sont comparables au backlog de produit ou au backlog de sprint de la méthodologie de développement agile Scrum. Contrairement à Scrum, cependant, le propriétaire du produit ne décide pas seul, mais toujours en communication avec les clients concernés. Nous considérons notre clientèle comme un cercle élargi de propriétaires de produits, pour ainsi dire. Afin de satisfaire les demandes différentes et parfois contradictoires des clients en matière d'urgence, il faut beaucoup de tact et une bonne communication de notre part, et de la part des clients, une volonté de compromis et de compréhension. Il est cependant toujours possible de trouver ce dernier, car nos clients reçoivent les nouvelles fonctionnalités dans le cadre de l'abonnement normal au produit standard et ne paient pas de supplément pour celles-ci.

Développement et test : la mise en œuvre concrète est programmée dans le temps.

Il s'agit d'une phase purement interne du processus de développement, c'est-à-dire sans participation du client. La nouvelle version est maintenant effectivement mise en œuvre par l'équipe de développement. C'est ici qu'intervient le développement de PQFORCE au sens étroit du terme. Un calendrier concret avec trois dates clés est défini à cet effet :

• Provision pour les tests internes(Release Candidate)
• Fourniture de la version stable pour le marketing et les ventes(Release for Marketing)
• Mise à disposition de la version stable pour l'usage productif du client(Release for Production)

Ces trois déploiements ont généralement lieu sur une base hebdomadaire. Ce rythme élevé est possible parce que nous nous efforçons de définir des sorties régulières et plutôt petites. De cette façon, nos clients bénéficient d'un développement continu avec des innovations gérables. De cette façon, nous pouvons continuellement adapter PQFORCE aux nouvelles exigences et garder le doigt sur le pouls du temps.

Construction et déploiement de la version : La livraison a lieu rapidement.

La version pour la production est finalement générée dans un processus de construction final et déployée sur les différents serveurs de production. Les clients du cloud partagé reçoivent automatiquement la version à la date annoncée précédemment. Les clients disposant de serveurs dédiés ou d'abonnements sur site recevront la version à l'heure de leur choix. Les notes de mise à jour correspondantes sont communiquées à tous les clients en temps utile.

La livraison boucle le cercle de l'idée originale de l'utilisateur à la fonctionnalité finale mise en œuvre en quelques semaines !