Données, perspectives et écoute pour améliorer l'expérience client.

[ad_1]

Mesurer la qualité de Windows est une tâche complexe qui nécessite de recueillir une variété de signaux de diagnostic provenant de millions de périphériques au sein de l'écosystème Windows. Les connaissances que nous acquérons de ces signaux sont essentielles pour comprendre si nos clients, à commencer par notre initié et s’adressant à la population générale des utilisateurs de Windows, utilisent avec succès nos produits et services. En plus de tous les tests internes que nous effectuons, nous nous appuyons beaucoup sur les commentaires fournis dans les données de diagnostic pour détecter et résoudre les problèmes avant de lancer de nouvelles mises à jour Windows pour la population générale, et pour en surveiller l'impact par la suite. de chaque version.

Dans cet épisode de notre série de blogs de qualitéJane Liles et Rob Mauceri, de l'équipe Windows Data Science, partagent certaines des pratiques que nous avons développées au cours des dernières années pour mesurer et améliorer la qualité de Windows.

Mesurer l'impact du changement

Nous abordons chaque version avec une question directe: "Cette mise à jour de Windows est-elle prête pour les clients?". C’est une question que nous posons pour chaque compilation et chaque mise à jour Windows et nous avons l'intention de confirmer que des tests manuels et automatiques ont été effectués avant d'évaluer la qualité. Grâce aux données de diagnostic et aux métriques basées sur les commentaires. Une fois la compilation franchie les portes de la qualité initiale et prête pour les prochaines étapes de l’évaluation, nous mesurons la qualité en fonction des données de diagnostic et des commentaires de nos propres ingénieurs qui hébergent de manière agressive Windows pour détecter les problèmes potentiels. Nous recherchons la stabilité et l’amélioration de la qualité des données générées par les tests internes, puis envisageons seulement de lancer la compilation sous Windows Insiders, après quoi nous examinons à nouveau les données, en recherchant spécifiquement les défaillances.

Pour répondre à la question "Cette mise à jour de Windows est-elle prête?", Elle nous oblige à concevoir et à corriger les métriques de manière fiable, reproductible, précise, honnête et impartiale. Cela nécessite un niveau élevé de tests et d'itérations. Nous prenons en compte les métriques plusieurs fois par semaine dans le cadre de notre activité normale pour mieux comprendre l'impact des modifications de code que nos équipes d'ingénierie intègrent au produit et pour décider du ciblage des efforts de stabilisation.

Lorsque nous sommes prêts à envoyer à notre clientèle, nos mesures doivent être au moins égales ou supérieures aux niveaux de qualité de la version précédente, l'idée étant que chaque mise à jour améliore l'expérience Windows 10. Nous utilisons ces méthodes de testez et mesurez tout au long du lancement et suivez leurs performances dans le temps, ce qui nous permet d'effectuer des expéditions avec une plus grande confiance. Ensuite, nous continuons à surveiller les problèmes de qualité qui affectent l'écosystème à mesure que la mise à jour atteint un public plus large.

Pour comprendre la qualité de chaque mise à jour via les données, nous divisons l'ensemble des fonctionnalités de Windows dans différentes zones définies par l'expérience client. Sur la base de la possibilité de disposer chaque mois de périphériques "actifs" uniques, nous nous concentrons sur le succès du processus de mise à jour et sur l'état général de l'expérience de l'utilisateur. À partir de là, nous définissons des "mesures de réussite" pour des scénarios d'utilisateurs clés qui illustrent une expérience de système d'exploitation (OS) inégalée. Par exemple, nous mesurons les taux de réussite de la connexion au Wi-Fi, de l’ouverture d’un fichier PDF à partir de Microsoft Edge ou de la connexion avec Windows Hello.

Pour toute mise à jour Windows, nous disposons de milliers de "métriques" (métriques brevetées reposant sur une plate-forme de données partagée) que nous utilisons au niveau de l’équipe pour surveiller l’impact des modifications. Parmi ceux-ci, nous en incorporons chaque jour un peu plus de 1 000 dans notre panneau RQV (Launch Quality View Control), ce qui nous donne une vue d'ensemble du produit. Nous utilisons ce panneau pour évaluer la qualité de l'expérience client avant l'expédition, c'est-à-dire pendant que nos ingénieurs et Windows Insiders exécutent des compilations de pré-versions quotidiennes et hebdomadaires. Nous continuons à surveiller le RQV lorsque le produit est généralement disponible pour les centaines de millions d'appareils utilisés par nos clients commerciaux et clients Windows, en utilisant les données pour détecter et résoudre rapidement les problèmes pouvant survenir, de sorte que Windows s'améliore constamment, même après. l'ont fait publié En fait, nous utilisons des mesures à chaque étape du développement pour contrôler la qualité de chaque version, qu’il s’agisse d’une mise à jour des fonctionnalités ou d’une maintenance mensuelle. Nous construisons ces "mesures" à partir de Données de diagnostic Windows et des signaux de rétroaction pour nous aider à comprendre si le produit fonctionne comme prévu. Le diagramme suivant montre à quoi ressemble l'une de ces mesures.

Graphique illustrant le temps moyen de connexion au Wi-Fi dans une mise à jour récente de Windows 10

Exemple: durée moyenne de connexion au Wi-Fi dans une mise à jour récente de Windows 10: 1,503 seconde (dans la limite des 3 000 ms, mesurée à 101,1 millions de connexions avec une qualité de signal d'au moins 50%)

Lors du développement du RQV, nous devions normaliser notre évaluation en plusieurs mesures, chacune avec une manière différente d’exprimer le "succès". Les mesures doivent être suffisamment souples pour saisir ce qui est important, par exemple:

  • Comment caractériser l'expérience mesurée pour influencer l'action correcte, par exemple définir le succès comme un faible taux d'échec de connexion au Wi-Fi, ou le pourcentage de périphériques sans échec, ou le taux de réussite de l'élimination du Historique du navigateur via les paramètres?
  • Comment devons-nous exprimer les objectifs, tels qu'un taux de réussite de 99,85% lors de la création d'un nouvel onglet dans Microsoft Edge ou moins de 500 millisecondes pour démarrer le menu Démarrer?
  • Quelle unité de mesure devrions-nous utiliser, par exemple, combien de millisecondes pour ouvrir le panneau Centre d’action par rapport au nombre absolu des inversions d’installation?

Pour fournir une vue significative de la qualité dans autant de variables, nous évaluons chaque mesure avec un score normalisé, en fonction de la distance qui le sépare de son objectif. Nous calculons ce score pour chacune des mesures constituant le RQV et fournissons une vue récapitulative pour chaque domaine de produit (par exemple, les réseaux), sous-domaine (par exemple, le Wi-Fi) et pour Windows en général. Ensuite, nous surveillons les tendances vers la réalisation des objectifs pour tous les domaines, dans le but d’une amélioration continue. Si une zone commence à dévier dans la mauvaise direction, loin des objectifs, nous pouvons rapidement la détecter, diagnostiquer et corriger le problème et valider le retour de la mesure à la santé.

L'une des choses que nous avons apprises lors de l'élaboration du RQV était l'importance de relier les erreurs des problèmes exposés par les mesures ayant échoué aux mesures elles-mêmes. Avoir la capacité de valider le fait qu'une solution d'erreur résolve vraiment un problème en voyant la même mesure revenir à une plage saine, basée sur l'utilisation réelle par nos propres ingénieurs et nos initiés, s'avère être une chose puissante et utile.

Vue de la tendance des mesures pour les mesures de réseau dans les constructions internes et Windows Insider

L’évolution de la mesure des mesures réseau dans les compilations internes et Windows Insider entre le 25/01/2019 et le 19/2/2019 montre une amélioration du score (76 -> 100) depuis la compilation précédente.

Actions mesures d'actions

Comme tous ceux qui travaillent régulièrement avec des métriques l'ont découvert, les données sont aussi utiles que l'engagement de l'entreprise à les utiliser pour prendre de vraies décisions et guider les actions de manière cohérente. Avoir un ensemble de mesures offre un avantage limité sauf s’il existe un processus et une responsabilité pour son utilisation.

Aujourd'hui, les dirigeants de l'organisation Windows se rencontrent plusieurs fois par semaine pour examiner la qualité de la dernière version de Windows hébergée par nos propres équipes d'ingénierie et par des centaines de milliers de membres Windows, représentés par nos mesures de RQV. En commençant par les problèmes les plus faibles, nous passons en revue la liste des domaines dont les mesures sont proportionnellement les plus éloignées de leurs objectifs. Ensuite, il est demandé aux propriétaires d’ingénierie de ces zones d’expliquer la cause du problème, qui est sur le point de le résoudre et à quel moment ils s’attendent à ce que la qualité de cette zone, telle qu’elle est représentée par les mesures, soit à nouveau conforme à la cible. Nous recherchons des différences de construction par construction et des tendances dans les mesures dans le temps.

Entre ces sessions de "préparation à la diffusion", ingénieurs et responsables vérifient régulièrement leurs mesures et les commentaires des clients, en recherchant les défaillances à l'aide d'outils d'analyse permettant de corréler les cohortes de conditions de défaillance avec les problèmes rencontrés dans le code. Cela leur permet de diagnostiquer les problèmes plus facilement et de les résoudre. Les corrections que les ingénieurs vérifient dans les compilations futures sont suivies dans le système. Ainsi, les réviseurs peuvent voir quand une correction sera livrée dans une nouvelle compilation et en surveiller l'impact au fur et à mesure de l'avancement de la compilation. voie de validation normale: à travers des portes de qualité automatisées. périphériques dans nos "anneaux" d'ingénierie internes et pour nos membres Windows. Les régressions impactantes, encore une fois, exposées par le biais de mesures et de commentaires d'utilisateurs, en qualité à chacune de ces étapes, peuvent arrêter la progression de cette compilation vers le prochain public jusqu'à ce qu'une nouvelle solution soit disponible (généralement sous la forme de: une nouvelle compilation).

Il a été passionnant de développer une nouvelle culture d’équipe axée sur la qualité de conduite grâce à des mesures construites à partir de nos canaux d’écoute, et nous continuons d’investir pour l’améliorer. Dans les débuts de Windows 10, il fallait des mois de réparation, de révision et d’itération pour obtenir un ensemble initial de mesures représentatives, fiables et fiables. Il fallait de la patience et de la rigueur pour parvenir à un état où des mesures pourraient raconter une histoire crédible. Si le propriétaire d'une propriété devait expliquer pourquoi les mesures ne décrivaient pas exactement ce qui se passait, nous devions prendre l'habitude de demander comment il les corrigerait et quand. Cela ne s’est pas fait du jour au lendemain, mais c’est ce qui est arrivé, en partie grâce à des dirigeants comme Mike Fortin, passionnés par la vie selon nos mesures, et à nos équipes de scientifiques et d’ingénieurs en données dévouées. Nous avons beaucoup appris sur la façon d’exprimer la qualité de manière centrée sur le client par le biais de mesures quantitatives (à grande échelle), et nous continuons à apprendre.

Exemple de mesure: création réussie d'un nouvel onglet dans Microsoft Edge

L'une des centaines de mesures suivies est le taux d'échec lors de l'ouverture de nouveaux onglets dans le navigateur Microsoft Edge. Le succès de cette action est essentiel pour une bonne expérience client, mais il s’agit également d’une opération non triviale en coulisse. Cela en fait une bonne mesure à suivre en tant que mesure de la qualité.

Nous avons détecté la création d'un nouvel onglet en recherchant une séquence de trois événements de diagnostic: (1) TabAddedToViewModel, (2) AddNewTabCreateInstance et (3) ConsumedPreLoadedTabInstance. Si chacun de ces événements se produit dans l'ordre et dans le délai imparti, l'action est considérée comme un succès. Cependant, de nombreux événements peuvent entraîner l'échec de l'opération. Par exemple, si nous voyons l'événement TabAddedToViewModel, mais que la séquence n'est pas terminée à temps, l'action est considérée comme un échec.

Voici la logique derrière cette mesure illustrée sous la forme d'un modèle d'état, qui correspond à la manière dont nous décrivons le modèle d'événement dans la définition de la mesure:

Schéma de la machine d'état pour mesurer la

Diagramme de la machine à états pour mesurer le "taux d'erreur de l'onglet Microsoft Edge"

Nous ajoutons tous les résultats de réussite et d’échec pour déterminer la fiabilité générale de l’action. Le pourcentage de succès sur tous les succès et les échecs est le résultat de la mesure. Dans ce cas, "l'objectif" ou l'objectif défini par l'équipe Microsoft Edge pour cette mesure est de 0,15%. Ainsi, si le pourcentage moyen de failles dans la création d'onglets est de 0,15% ou moins pendant une période donnée. période de sept jours consécutifs, alors la mesure est en cours.

Lorsque nous voyons les résultats d’une mesure, nous comparons entre les compilations pour comprendre ce qui suit:

  1. Comment cette mesure est-elle effectuée pour ce public d'appareils avec cette construction spécifique?
  2. Cette fonction fonctionne-t-elle mieux dans cette compilation que dans la dernière compilation que nous avons publiée pour ce public?
  3. Quelle est la qualité de cette fonction dans cette compilation par rapport à la version la plus récente de Windows?

Voici un exemple de comparaison des résultats de cette mesure dans trois versions différentes le 24 février:

Comparaison du taux d'erreur de création d'onglets pour trois différentes compilations Windows 10

Comparaison du taux d'erreur de création d'onglets pour trois différentes compilations Windows 10

Comme la mesure se situait dans les limites de sa cible de 0,15%, avec une moyenne de 0,07% au cours des sept derniers jours, il obtient un score de 100 (en vert).

Une vue plus détaillée du premier graphique montre plus d'informations sur le nombre d'instances et les moyennes quotidiennes:

Vue détaillée de l'onglet Créer une mesure de faute

Vue détaillée de l'onglet Créer une mesure de faute

Les barres grises au bas du tableau indiquent le nombre d'instances de cette mesure pour la journée. L'intervalle de confiance indique la plage de résultats de cette journée, qui était relativement étroite le 24 février. Il est probable à 95% que la moyenne vraie se situe dans la plage de 0,02% se situant dans les limites de la cible. . Si la mesure échouait, nous pourrions obtenir des informations détaillées sur le tableau afin d’obtenir les informations générées par l’apprentissage automatique des cohortes anormales ou des schémas de conditions entre les périphériques défaillants, ainsi que des corrélations avec les défaillances connues. Nous pouvons également rechercher des données de diagnostic supplémentaires pour comprendre la cause première des problèmes et aider les ingénieurs de l'équipe Microsoft Edge à les résoudre rapidement en vue d'une future compilation.

Progrès et plus d'investissement.

Nous avons parcouru un long chemin dans notre quête pour mieux comprendre et améliorer la qualité de Windows grâce aux signaux que nous recevons de Windows Insiders et à leur utilisation sur le marché. Nous continuerons à rechercher des possibilités de rendre nos systèmes d’audition et d’analyse plus intelligents, dans le but de vous offrir à vous, notre client, la meilleure expérience Windows possible. Nous cherchons constamment à appliquer de nouveaux moyens améliorés d’augmenter notre instrumentation et nos mesures; Par exemple, investissez davantage dans les commentaires des clients pour nous aider à identifier les lacunes ou les incohérences dans nos mesures en fonction des données de diagnostic et à fournir des informations sur vos expériences personnelles. Nous investissons également dans de nouveaux modèles d'apprentissage automatique pour encourager la détection précoce par l'analyse de texte. En résumé, nous sommes sur la voie de l'amélioration continue et nous utilisons les données et l'intelligence artificielle pour prendre des décisions de lancement plus éclairées et davantage axées sur le client, tout en préservant leur confidentialité et leur confiance.

[ad_2]