Je suis en train de créer un outil de dysfonctionnement informatique dans un centre informatique universitaire. Idéalement, l'outil est censé fonctionner comme quelque chose de similaire à une alerte orange, où le rapport d'un événement pourrait être transmis à chaque client utilisateur. Par exemple, si un ordinateur cesse de fonctionner, un avertissement peut être envoyé à tous les informaticiens disponibles dans le bâtiment. Le but ici est un temps de réponse extrêmement rapide, afin que nous puissions faire fonctionner chaque ordinateur et des temps de réponse très rapides pendant les heures de pointe de la construction. Cependant, cet outil repose entièrement sur les rapports des étudiants et des professeurs, car un système de billetterie serait trop lent et ne serait pas utile pour maintenir un temps de disponibilité correct du bâtiment.
Bien qu'une utilisation totalement éthique rendrait cet outil extrêmement utile, il est naïf de penser qu'il n'y aura pas d'utilisateurs contraires à l'éthique. J'ai quelques problèmes évidents, et quelques problèmes moins évidents que je voudrais résoudre si possible. Cet outil pourrait ne pas être en mesure de se concrétiser, il pourrait donc simplement agir comme un exercice d'expérience utilisateur.
Comment puis-je décourager les faux rapports?
Comment puis-je transmettre ces informations aux clients d'une manière efficace mais facile à utiliser?
Enfin, comment puis-je limiter l'utilisation à des bâtiments particuliers?
Merci d'avance et je suis ouvert à toutes les suggestions et directions de projet.
Si le temps de réponse rapide est primordial, vous n'aurez pas le temps pour une étape de triage de filtrer les mauvais rapports. La responsabilité/auditabilité est votre seul autre choix pour limiter les fausses alarmes. Les clients qui crient "loup" auront éventuellement des conséquences, mais ils peuvent peut-être être identifiés d'autres façons (caméras, registres d'accès aux portes, registres de connexion à l'ordinateur, etc.) La bonne nouvelle est que ce n'est peut-être pas un problème que vous devez résoudre immédiatement. Vous pourriez attendre de voir à quel point il est mal utilisé avant de mettre en œuvre une solution dure, coûteuse ou trop complexe.
Le modèle que vous recherchez s'appelle Publier-S'abonner. Un abonné dit "Je veux être informé de X" et l'éditeur informe chaque abonné lorsque X se produit. Une sorte d'administration sera nécessaire ici pour ajouter des abonnés autorisés à la liste - peut-être que vos informaticiens sont membres du groupe "LocalResponders", et vous mettez à jour la liste des abonnés tous les soirs, ou un mécanisme similaire pour ajouter et supprimer des personnes .
Vous devrez tenir à jour une liste de ce que signifie être "dans un bâtiment" et trouver un attribut que vos abonnés auront qui ne sera pas contraignant à modifier.
Une chose que vous n'avez pas mentionnée est un bouton "répondre". Si vous allez contacter cinq personnes avec une alerte, pensez-vous que les cinq vont se précipiter de leur chaise pour répondre à chaque appel? Ou est-ce que tous les cinq vont rester assis parce que "quelqu'un d'autre le comprendra?" En donnant aux répondeurs une sorte de bouton "réclamation" ou "réponse", appuyer dessus annulera l'alerte que les autres voient. Il permettra également à l'utilisateur de savoir que l'aide est en cours.
Une autre chose à considérer est ce qui se passe si personne ne répond? Combien de temps allez-vous laisser vos utilisateurs se tenir là dans le noir? Une minute? Cinq minutes? Que voient-ils s'ils n'obtiennent aucune réponse une fois le temps écoulé? Signalez-vous des intervenants dans le bâtiment adjacent le plus proche? Signalez-vous à un superviseur de se rendre sur le site de l'utilisateur pour s'excuser à profusion? Dites-vous à l'utilisateur "nous sommes désolés, tous nos techniciens sont actuellement occupés à aider d'autres personnes, votre problème est important pour nous, nous vous répondrons bientôt, votre temps d'attente moyen est de - vingt-sept - minutes?"
Combien de temps un ordinateur doit-il être arrêté avant d'envoyer un informaticien? Interrogez-vous les ordinateurs toutes les 15 secondes? Toutes les 30 secondes? Est-ce suffisant pour répondre à un ping ou l'ordinateur a-t-il besoin d'un agent installé pour répondre? L'agent fait-il un diagnostic ou une analyse préliminaire? Ou envoyez-vous simplement tous les événements système au serveur, et si vous n'entendez pas d'un ordinateur après 1 heure, vous supposez qu'il est mort?
Savez-vous si chaque problème nécessite une réponse physique? La plupart de ces problèmes peuvent-ils être traités automatiquement par un agent logiciel? ou par du personnel distant, ce qui élimine le temps de déplacement? Votre logiciel agent par ordinateur peut-il faire la différence?
Enfin, la grande question concerne vos informaticiens. Quelle est leur incitation à répondre à ces appels? Obtiennent-ils des points pour répondre en premier, ou pour répondre dans les 30 secondes, ou pour répondre à une réponse en 10 minutes ou moins? Ou s'agit-il simplement d'un travail supplémentaire pour lequel ils ne reçoivent aucune récompense spéciale? Comment pouvez-vous régler les différends lorsque Joe est le gars intelligent qui prend 30 minutes sur des problèmes difficiles, mais Jim est le gars rapide qui gifle un pansement dans les cinq minutes, lui permettant de répondre à plus d'appels? Tout cela va conduire leur comportement, ce qui est l'objectif ultime de ce type de projet. Vous ne pouvez pas vous attendre à ce que quelqu'un se rende sur les lieux parce que son téléphone portable lui a donné une alerte.
Si vous allez assumer cette tâche principale, vous devez la mener à terme. Et c'est un très gros projet, juste d'après ce que vous avez décrit.
La reddition de comptes est un bon moyen d'assurer une bonne utilisation - Si un utilisateur sait qu'un rapport sera accompagné de son nom et de son ID et que les enregistrements des rapports sont conservés pour analyse, il sera moins susceptible d'utiliser l'outil pour le plaisir.
Une autre façon de résoudre le problème des rapports faux ou déraisonnables consiste à intégrer une sorte de triage dans l'outil - en faire un outil pour résoudre les problèmes informatiques courants qui permet de créer des rapports en cas d'échec. De cette façon, l'utilisateur devra effectuer un certain nombre de tâches d'autodiagnostic avant il peut soumettre un rapport. Vous pouvez également utiliser les données de l'autodiagnostic pour compiler le rapport.
Avec un système de compte, vous commencerez rapidement à rassembler une grande quantité de données qui peuvent éviter tous les problèmes ensemble - Si vous savez qui signale des problèmes, vous pouvez découvrir un problème de formation avec certaines facultés ou groupes, si vous maintenant où des problèmes surviennent, vous pouvez découvrir des problèmes avec certains sites, si vous savez quand des problèmes surviennent, vous pouvez découvrir des problèmes associés aux taux d'utilisation, etc.
Pour la notification, vous devrez trouver ce qui est le plus utile pour vos utilisateurs. Vous pouvez même trouver utile de l'intégrer à un tiers tel que IFTTT afin de permettre aux utilisateurs de décider comment ils reçoivent les alertes et quoi en faire.
En ce qui concerne l'emplacement, j'ai fait des recherches sur des choses comme ça récemment et il y a pas mal d'options, mais elles reposent sur du matériel externe: NFC portes, balises BLE, etc. tout fonctionne idéal pour déclencher des événements de proximité, y compris l'enregistrement et le retrait d'un espace donné - bien que ce soit plus un problème de mise en œuvre et n'est certainement pas mon point fort.
C'est une question extrêmement vaste, mais je ferai de mon mieux.
Comment puis-je décourager les faux rapports?
On dirait que vous parlez de cela en termes d'un environnement universitaire. Je suppose que des personnes ont déjà attribué des adresses e-mail de cette organisation, il semble donc que vous pouvez utiliser leur compte existant pour activer l'enregistrement unique de leur appareil afin de pouvoir créer des rapports.
Les utilisateurs seront beaucoup moins enclins à abuser du système s'ils comprennent que leurs rapports sont connectés à leur compte, plutôt qu'à une simple publication anonyme.
Si un utilisateur abuse du système, interdisez-le.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Comment puis-je transmettre ces informations aux clients d'une manière efficace mais facile à utiliser?
Cela ressemble à ce pour quoi les notifications ont été conçues.
Enfin, comment puis-je limiter l'utilisation à des bâtiments particuliers?
Vous devez autoriser les utilisateurs à lier leurs rapports à un emplacement (s'ils n'utilisent pas le GPS, puis en sélectionnant les détails du bâtiment et de la pièce sur une carte ou une liste). En faisant cela, vous pouvez alerter les 5 techniciens les plus proches avec une alerte préliminaire. Si après 15 minutes, le problème n'est toujours pas "détecté" par un technicien, vous pouvez envoyer une alerte secondaire avec une priorité plus élevée aux 10 techniciens les plus proches.
Je pense que les deuxième et troisième questions ont déjà été assez bien répondues, je veux donc me concentrer un peu plus sur la première. Il existe en fait un certain nombre de stratégies qui ont déjà été suggérées, mais je vais résumer et voir si cela vous aide à identifier celle (s) qui est la plus applicable.