L'entreprise développe constamment ses produits informatiques. Il n'y a aucun moyen «d'arrêter le moment», sinon même le meilleur programme deviendra inévitablement obsolète. Nous expliquons comment nous avons créé une nouvelle version de l'application médicale pour l'Europe et quels problèmes ont été résolus en même temps.
Hôpital App
Nous travaillons avec une application médicale pour les hôpitaux en Europe. Il aide les médecins à passer plus de temps avec les patients en réduisant les formalités administratives. Les médecins dictent des informations sur les patients et les examens, l'application traduit les enregistrements audio au format texte, remplit un modèle et génère des documents pour les travailleurs médicaux et les patients. À chaque étape du travail, sa propre logique commerciale et son intégration avec plusieurs systèmes externes sont établies.
Le client nous a confié la tâche de développer une nouvelle version de l'application pour démonstration aux investisseurs.
Détails du projet
Audio
Comment enregistrer de l'audio dans la version 2.0:
- Ouverture de l'application.
- Cliquez sur le bouton Ajouter un enregistrement.
- Dans la fenêtre qui apparaît, nous avons sélectionné la version souhaitée de l'appareil d'enregistrement.
- Enregistrement audio dicté.
- Le numéro du patient, la date de la visite, le numéro de la visite (visite = rendez-vous chez le médecin) ont été saisis.
- Ils ont cliqué sur le bouton Terminer pour télécharger l'audio et visiter les données sur le serveur.
Maintenant, dans la version 3.0, moins d'efforts sont nécessaires pour écrire:
- Le médecin ouvre l'application.
- Sélectionne un rendez-vous (par date, heure, numéro ou nom du patient) dans la liste et clique 1 fois pour ouvrir une carte de visite.
- Enregistre l'audio.
- Appuyez sur le bouton Terminer pour envoyer de l'audio au serveur.
Dans la version 3.0, le travail du médecin est aussi automatisé que possible. Le nombre d'opérations a diminué, tandis que le programme lui-même ajoute des données sur les patients.
Travailler avec des lettres
Travailler avec des lettres est également devenu plus facile. Dans la version 2.0, il y avait une file d'attente difficile pour leur traitement. Le médecin n'a pas pu recevoir immédiatement une liste complète des lettres - uniquement en partie et dans un certain ordre. Pour commencer, il fallait:
- faites un clic pour obtenir une liste de vos lettres;
- allez dans une autre fenêtre;
- double-cliquez sur la lettre pour l'ouvrir;
- après avoir traité les lettres de la liste, cliquez à nouveau pour recevoir les lettres suivantes dans la liste.
Dans la version 3.0, le médecin voit toutes les lettres disponibles pour le traitement. Il peut sélectionner un document de deux manières - soit manuellement dans la liste, soit en utilisant des filtres et des tris (vous pouvez les enregistrer pour ouvrir davantage la lettre en un seul clic). Pour ouvrir la lettre, cliquez simplement une fois.
Interface
En général, l'interface de la version 2.0 était encombrante et peu pratique. La tâche initiale de l'application était de gagner du temps aux médecins spécialistes en réduisant le flux de travail papier et en travaillant avec des enregistrements audio. En pratique, l'application n'a pas fait face à cette tâche aussi bien que nous le souhaiterions. Afin d'enregistrer un dossier, le médecin a dû choisir un grand nombre de paramètres dans de longues listes déroulantes.
Nos experts ont travaillé avec l'interface et mis en avant le bouton audio pour que les utilisateurs puissent achever leur tâche en un minimum de clics.
Ensuite, nous donnerons des détails sur la façon dont nous avons développé la nouvelle version.
De nouveaux besoins
Lorsqu'un client nous a contacté pour mettre à niveau la version 2.0, l'application fonctionne depuis environ trois ans. Il était familier aux utilisateurs et présentait certains avantages:
- Il y avait un ensemble de fonctions pour exécuter une logique métier complexe, l'intégration avec des systèmes tiers;
- les clients sont habitués au programme et ne voudraient pas l'abandonner;
- Le personnel du support technique connaissait l'application et a rapidement aidé les utilisateurs;
- Il y avait des paramètres flexibles pour configurer le système pour tous les désirs commerciaux;
- un suivi des problèmes possibles dans les parties serveur du système a été établi, des solutions pour les résoudre étaient connues.
Cependant, lors de l'analyse du fonctionnement de l'application, nous avons constaté de tels problèmes:
- développer et tester de nouvelles fonctionnalités prenait de plus en plus de temps;
- lors de l'ajout de nouvelles fonctions, des erreurs sont apparues dans le système;
- en conséquence, jusqu'à 30% des améliorations complexes ont été abandonnées, ce qui menaçait de surpasser l'application. Par exemple, dans les hôpitaux, des modèles de plus en plus complexes sont apparus, il a fallu ajouter de nouveaux rôles dans Workflow;
- l'architecture des applications ne pouvait pas prendre en charge de nouvelles solutions;
- 40% du temps de développement a été consacré au support;
- il y avait des difficultés lors de l'installation de nouvelles versions et mises à jour du produit de bureau;
- l'interface encombrante des années 2000 a effrayé de nouveaux clients;
- un système de paramètres peu pratique empêchait le système de démarrer rapidement et augmentait également les risques d'erreurs.
Lors de l'évaluation des forces et des défis, nous sommes arrivés à la conclusion que l'application doit être rendue plus mobile (version Web au lieu de bureau) et pratique, compétitive, facilement adaptable aux tâches de l'entreprise.
Exigences de version
Nous avons analysé les fonctions de l'application et identifié les plus importantes qui ont rendu le produit précieux pour l'entreprise. Sur la base de ces données, nous avons déterminé ce que le programme devrait être dans la nouvelle version:
- Des fonctions clés de l'application intuitives pour les médecins et autres utilisateurs sont nécessaires;
- Les utilisateurs - prestataires de soins de santé et personnel de soutien - devraient pouvoir facilement apprendre à utiliser le programme;
- éliminer les pertes de données même dans des conditions extrêmes (pannes de courant, accès Internet instable, etc.);
- les documents générés par le système doivent être conformes aux normes et exigences de la loi;
- lors des mises à jour du système, les éventuels inconvénients pour l'utilisateur et le service d'assistance doivent être minimisés;
- il est nécessaire de créer une architecture modulaire orientée services basée sur des composants distribués et faiblement couplés, qui leur permettra d'être utilisés pour construire des systèmes logiciels complexes;
- Utilisez Active Directory pour configurer uniformément votre environnement de travail.
De plus, il était impossible de permettre à la nouvelle version d'être un «clone compliqué» de l'ancienne. Par conséquent, les fonctions clés ont dû être enregistrées, mais sans surcharger l'application. Nous avons impitoyablement abandonné les paramètres complexes redondants.
Les analystes commerciaux travaillant avec la version 2.0 n'ont pas immédiatement accepté les modifications. Dans les termes de référence, des phrases étaient souvent trouvées: «Il devrait être ici comme dans la version 2.0», «Prendre le schéma de travail dans la version 2.0». La chose la plus difficile à ce stade a été la résistance à la tentation de tout prendre, comme dans la version précédente.
Équipe projet
En règle générale, au début de chaque projet, nous, chez SimbirSoft, nous nous connectons à une équipe d'experts de différents profils - analystes, spécialistes de l'assurance qualité (AQ) et autres. Lorsque nous travaillons sur une application médicale, nous constituons l'équipe suivante:
- les développeurs qui ont écrit du code et adapté les fonctionnalités de la version 2.0;
- Spécialistes en assurance qualité (AQ). Avec les développeurs, ils connaissaient le code hérité, les solutions architecturales et les erreurs de la version 2.0, et ont également testé de nouvelles fonctions;
- Test Automation Engineer (SDET), qui a configuré la vérification automatique des cas de test dans les versions de bureau et Web;
- Intelligence d'affaires. Ils ont discuté avec le client et les médecins, découvert comment les processus métier ont été construits, quelles sont les exigences et les souhaits pour l'application. Après cela, ils ont élaboré des diagrammes de processus métier compréhensibles pour toute l'équipe;
- Designer et expert en ergonomie. Ils étaient chargés de développer une interface conviviale.
- Chef de projet impliqué dans la gestion et la programmation du temps.
Dans le processus, nous avons constamment maintenu des tableaux des risques présumés dans la nouvelle version. Pour les éviter, nous avons pensé à un système flexible de paramètres d'application et automatisé ses tests pour protéger les utilisateurs contre les erreurs. En particulier, notre spécialiste SDET a écrit un framework qui a aidé à vérifier rapidement toutes les modifications du code et à passer moins de temps sur les tests de régression.
Défis et solutions
Lors de la mise à niveau de l'application, nous avons dû faire face à plusieurs étapes difficiles, dont nous parlerons ci-dessous.
Conception d'applications
Comme la version précédente avait une interface encombrante, nous avons repensé la conception de l'application. Nous avons proposé cinq options préliminaires et les avons montrées au groupe de discussion parmi les utilisateurs de l'application, effectué des tests d'utilisabilité. En conséquence, les médecins spécialistes ont choisi une option qui, à leur avis, s'est avérée la plus pratique, la plus attrayante et la plus facile à utiliser.
Développement de plugins pour différents navigateurs
Nous avons fourni divers risques techniques associés à l'application. Par exemple, le plugin choisi pour l'implémentation peut ne pas convenir à certains navigateurs Internet. Pour réduire ce risque, nous avons d'abord développé un plug-in pour le logiciel utilisé dans la plupart des institutions médicales partenaires. À l'avenir, nous avons calmement développé le plugin pour d'autres navigateurs.
Hypothèses commerciales invalides
Notre tâche était de développer une version limitée du produit pour une présentation aux investisseurs. Pour cette raison, nous avons cherché à implémenter dans l'application uniquement les fonctions les plus nécessaires. Nous avons analysé certaines hypothèses du client et refusé de les mettre en œuvre.
Par exemple, le client a suggéré de créer un calendrier pour planifier le travail des médecins spécialistes. Selon l'hypothèse, le calendrier pourrait faciliter le travail des médecins. Cependant, dans des conditions réelles, cette fonction n'a pas réussi, donc elle a finalement été désactivée. Plus tard, le calendrier a été adapté aux besoins d'un autre groupe d'utilisateurs - les patients, pas les travailleurs médicaux. Hypothèses invalides ─ cela fait partie intégrante de l'entreprise et vous devez vous y préparer.
Intégration avec des systèmes externes
Il a fallu beaucoup de temps pour convenir avec notre partenaire de la procédure d'intégration de l'application aux systèmes externes d'envoi et de stockage des lettres.
Les utilisateurs de l'application ─ installations médicales ─ souhaitaient utiliser d'anciens systèmes d'intégration familiers pour la version 3.0, ils ne pouvaient pas être modifiés. Notre partenaire a supposé que dans ce cas l'intégration serait rapide. Cependant, en fait, de nombreuses tâches étaient associées à l'intégration:
- Recueillir des informations générales sur le fonctionnement des systèmes d'envoi de courrier;
- faire une liste des bogues critiques qui étaient dans 2.0;
- considérer ces cas au stade de l'analyse et du développement afin de les prendre en compte et de ne pas marcher sur le même rake;
- analyser si les fonctions de la version 2.0 conviennent aux processus de la version 3.0 ou si quelque chose doit être changé. En cas de changement, précisez à chaque fois pourquoi des fonctions spécifiques sont nécessaires et communiquez avec les spécialistes techniques du client, et pas seulement avec les analystes.
Au cours des négociations avec le client, nous avons pu prouver que travailler avec l'intégration prend du temps. Notre partenaire était d'accord avec nous: vous ne pouvez pas simplement prendre et transférer le code d'une version à une autre.
Tests et analyses
La version précédente du projet a été créée sans la participation d'analystes. Les développeurs et les spécialistes de l'assurance qualité ont spécifié les exigences lors du processus de création de l'application. La troisième version était déjà basée sur les exigences des analystes, cependant, il y avait encore des difficultés avec les tests:
- différentes équipes ont travaillé sur le projet;
- il y avait un grand volume de tâches parallèles;
- pendant le sprint, les exigences et les tâches ont souvent changé;
- Il était nécessaire de prendre en compte l'interaction des nouvelles fonctionnalités avec celles déjà approuvées.
Pour travailler sur la nouvelle version du produit, nous devions transformer des workflows individuels, par exemple:
- Nous avons renforcé l'analytique du côté du développement et de l'assurance qualité et avons prévu des heures supplémentaires pour cela.
- C'était une règle pour indiquer le but de la fonction testée dans les exigences de l'examen. Cela a amélioré la compréhension des tâches des analystes et a permis de proposer la solution optimale.
- Pour clarifier les conditions de travail, nous avons changé la terminologie: au lieu d'une estimation approximative en heures, nous avons commencé à classer les tâches comme «grandes» ou «petites». Nous n'avons commencé à calculer le délai d'exécution qu'après un examen complet de la tâche du côté du développement, de l'assurance qualité et de l'approbation de la version finale des exigences par le client. Si la tâche s'est étendue, nous avons recalculé l'estimation des coûts de temps.
- Nous avons commencé à planifier les fonctions à implémenter au cours des prochains trimestres, pour les 2-3 prochaines versions. Afin de prédire plus précisément le développement, nous n'avons plus inclus dans le plan de mise à jour les tâches qui n'ont pas réussi l'évaluation.
- Pour la commodité des analystes et une meilleure compréhension du système, nous avons indiqué dans les listes de contrôle quelles interactions doivent être prises en compte lors de l'établissement des exigences. Nous avons également développé des règles communes pour la rédaction d'articles dans Confluence et la documentation dans JIRA et avons commencé à les respecter.
Des échanges en ligne réguliers avec le client nous ont aidés à améliorer notre compréhension de ses processus commerciaux. Au cours de la conversation, notre partenaire a expliqué en détail le fonctionnement des médecins et expliqué les objectifs commerciaux. À notre tour, nous avons expliqué les nuances techniques et montré divers cas non évidents. Cela nous a permis de formuler des exigences de produits qui couvrent les besoins des institutions médicales et sont optimales en termes de coûts de mise en œuvre.
Résumé
La flexibilité des processus de travail et l'attention aux besoins de l'entreprise nous ont permis de surmonter toutes les difficultés qui se sont posées pendant le processus de développement. Nous avons réalisé et lancé avec succès une nouvelle version de l'application pour les institutions médicales en Europe.
Maintenant, nous continuons à développer le produit et à introduire de nouvelles fonctionnalités. Nous examinons comment les utilisateurs réels travaillent avec le système, collectons les cas non comptabilisés et les user stories, et identifions de nouvelles valeurs commerciales.
Lors de la création d'une nouvelle version d'un produit, les développeurs sont généralement confrontés aux mêmes problèmes que nous, par exemple:
- des hypothèses incorrectes du côté des entreprises sont possibles;
- il y a des contradictions dans les désirs des utilisateurs (tout laisser tel quel ou le refaire d'une manière nouvelle);
- il est parfois nécessaire de restructurer le travail de l'équipe pour obtenir un meilleur résultat.
L'essentiel est que la sortie de la nouvelle version du produit informatique ne soit pas une copie du code «Ctrl + C», «Ctrl + V» de la version précédente, mais un développement à part entière, à partir de zéro. En effet, les processus métier, les besoins des utilisateurs ainsi que la situation sur le marché des solutions informatiques évoluent.
Merci de votre attention! Nous espérons que cet article vous sera utile.