In der heutigen Welt sind Anwendungen gefragt, die die Interessen aller Parteien am effektivsten erfüllen können. Oft wird dies unter Verwendung verschiedener Arten von Einschränkungen implementiert. Beispielsweise erlauben sie dem Benutzer nicht, Aktionen auszuführen, die für sich selbst oder den Eigentümer des Systems nachteilig wären. In diesem Fall ist es notwendig, die durch solche Einschränkungen verursachten Beschwerden zu minimieren.
Beispielsweise benötigt der Besitzer des Systems eine Telefonnummer im Feedback-Formular im Format +7 () -- für die weitere automatisierte Verwendung. Für den Benutzer ist es besser, beim Senden des Formulars nicht nur einen Hinweis oder eine Validierung zu verwenden, sondern auch eine Eingabemaske, die die Eingabe von Daten im falschen Format ausschließt. Es stellt sich heraus, und die Wölfe sind voll und die Schafe sind intakt.
In einigen Fällen beschränkt das System den Benutzer auf den Schutz vor möglichen Verlusten. So müssen Sie beispielsweise wie beim Anlegen eines Sicherheitsgurts vor dem Fahren bei Online-Zahlungsdiensten nicht nur Daten von der Karte eingeben, sondern auch die Zahlung per Code aus einer SMS-Nachricht bestätigen, wodurch die Wahrscheinlichkeit eines Gelddiebstahls erheblich verringert wird. Und es sollte beachtet werden, dass eine solche Sorge um die Sicherheit des Benutzers für den Dienstbesitzer von Vorteil ist, da sie das Reputationsrisiko verringert, andernfalls kann es sich wie bei der Arbeit von Alexei Apukhtin herausstellen: „... ob er ihn gestohlen hat oder ihm gestohlen wurde ... Die Hauptsache ist, dass er beteiligt war böse Sache ... ".
Daher ist es bei der Entwicklung einer Anwendung erforderlich, die Funktionalität so zu überdenken, dass sowohl der direkte Kunde als auch der durchschnittliche Benutzer zufrieden sind. Vor diesem Hintergrund können fünf Ebenen von Systemeinschränkungen unterschieden werden:
- Es gibt keine Möglichkeit, den Benutzer einzuschränken, dh sich darauf zu verlassen, dass er keine Fehler macht und sich selbst oder dem Eigentümer des Systems keinen Schaden zufügt.
- Teilweise einschränken - Der Benutzer kann einen Fehler machen, der jedoch weniger wahrscheinlich (oder weniger schwerwiegend) ist.
- Führen Sie die erforderlichen Einschränkungen ein , aber nicht übermäßig - der Benutzer ist so eingeschränkt, dass er keinen Fehler machen kann, aber die Einschränkungen verursachen keine Probleme bei der Verwendung des Systems. Dies ist eine ideale Option.
- Es ist nicht erforderlich , eine Einschränkung vorzunehmen. Der Benutzer ist so eingeschränkt, dass er das System nicht verwenden kann.
- Begrenzen Sie den Benutzer vollständig , d. H. Blockieren Sie die Funktion.
Ein bekanntes Beispiel für die erste und fünfte Ebene ist die bekannte Situation, in der eine Kassiererin im Laden „Galya, storniere!“ Ruft und die allmächtige Galya zur Rettung kommt. In diesem Fall hat der Kassierer die Funktion zum Entfernen von Lochware vom Scheck vollständig blockiert, und Gali hat keine Einschränkung für diesen Vorgang. Das heißt, diese Einschränkungen können häufig als Teil der Implementierung des Vorbilds verwendet werden.
Und für den Fall, dass es sich nicht um Extreme handelt, wird eine der Zwischenoptionen im System erstellt. Und dann besteht die wichtige Aufgabe eines jeden Projekts darin, alle notwendigen, aber nicht übermäßigen Einschränkungen einzuführen (dritte Ebene). So zum Beispiel nicht in jeder Phase des Ausfüllens eines Antrags zum Ausfüllen eines Captchas (vierte Ebene), sondern nur vor dem Senden des vollständigen Formulars. Oder damit das Telefoneingabefeld nicht nur eine Eingabemaske (zweite Ebene) enthält, sondern auch eine Überprüfung, ob der Benutzer 11 Ziffern der Nummer eingegeben hat.
Wir geben ein Beispiel. Wir hatten ein Projekt zur Entwicklung einer Anwendung, die den Erfassungsprozess begleitet (im Folgenden: Sammlersoftware). Im Rahmen des Projektstarts haben wir das Mandat entworfen und vereinbart, wonach die Arbeit des Analysten größtenteils abgeschlossen war. Es ist erwähnenswert, dass der Kunde ein Unternehmen war, das gerade erst anfängt, Schulden einzutreiben, das heißt, wie sich später herausstellte, befindet sich der Arbeitsprozess noch in der Debugging-Phase.
Und zu diesem Zeitpunkt, als die Entwicklung des Projekts bereits etwa sechs Monate dauerte, gingen neue Informationen über die Merkmale der Arbeit potenzieller Benutzer des Systems sowie über geplante Verbesserungen ein. Es sollte sofort angemerkt werden, dass wir zu diesem Zeitpunkt die folgenden funktionalen Aufgaben implementiert haben, einschließlich:
- Zuweisung einer Aufgabe, um den Schuldner anzurufen;
- die Umsetzung der zugewiesenen Aufgabe;
- Festlegen des Interaktionsergebnisses (manuell durch den Benutzer);
- Gewährleistung der Einhaltung der Anforderungen der Gesetzgebung der Russischen Föderation hinsichtlich der Häufigkeit von Interaktionen mit Schuldnern 1 .
Lassen Sie uns klarstellen, dass die letzte der aufgeführten Funktionen wie folgt war: Collector-Software hat die Möglichkeit eingeschränkt, Aufgaben zuzuweisen, die möglicherweise gegen die gesetzlichen Anforderungen verstoßen könnten. In diesem Fall wird die Aufgabe verschoben, wenn der Durchgang nicht möglich war (der Benutzer legt das entsprechende Anrufergebnis fest), und der Bediener kann später darauf zurückgreifen. Das heißt, ein fehlgeschlagener Einwahlversuch kann nicht als Interaktion betrachtet werden, und Sie können versuchen, die Aufgabe erneut abzuschließen.
Was ist über die Funktionen der Benutzererfahrung bekannt geworden? Es stellte sich heraus, dass der Betreiber im Falle eines erfolglosen Versuchs, das Mobiltelefon des Schuldners zu erreichen, die Aufgabe nicht nur verschiebt, sondern auch sofort versucht, sie zu erreichen, wenn dem Schuldner andere Nummern zugewiesen wurden.
Angesichts der engen Fristen war es unpraktisch, den Analysten erneut in das Projekt einzutauchen, sodass unser QS-Spezialist die Aufgabe hatte, zu prüfen, ob die vorhandene Implementierung mit der geplanten Verwendung der Anwendung auf Kundenseite übereinstimmt. Während der Analyse haben wir die folgende logische Kette aufgebaut:
- Der Schuldner kann mehrere Nummern haben (Mobil, Privat, Arbeit), aber Sie können einen Anruf nur für eine Nummer planen.
- Wenn der Bediener den Kunden nicht erreicht, wird die Aufgabe verschoben, es ist jedoch weiterhin unmöglich, eine andere Nummer anzurufen, da Die anstehende Aufgabe blockiert auch die Ernennung eines Anrufs zu anderen Nummern.
- Um zu versuchen, eine andere Nummer zu erreichen, muss der Benutzer die ausstehende Aufgabe manuell abbrechen und eine neue zuweisen.
- Aber zur gleichen Zeit und andere Zahlen können möglicherweise nicht durchkommen. Und dann wurden die Aufgaben, die aufgrund fehlender Wahl verschoben wurden, vergeblich verschwendet. Sie müssen sie erneut ernennen, um später erneut anrufen zu können.
Es ist zu beachten, dass nach Angaben des Kunden in der Praxis häufig erfolglose Einwahlversuche auftreten.
Darüber hinaus war geplant, eine Funktion zur Integration der Collector-Software in ein Analysesystem zur automatischen Terminvereinbarung (im Folgenden: ASANM) zu entwickeln, das auf Kundenseite erstellt wurde. Die Essenz war wie folgt:
- Täglich (einmal täglich) ASANM erstellt eine Liste der Aufgaben, die im Rahmen der Verträge ausgeführt werden müssen, und sendet eine Anforderung an die Collector-Software.
- Software Der Kollektor aus der empfangenen Liste weist die Aufgaben zu, die die Interaktionsgrenze nicht überschreiten.
Nach Ansicht des QS-Spezialisten könnten in der bestehenden Implementierung sowohl der Betreiber als auch ASANM nicht alle Nummern des Schuldners anrufen.
Im Allgemeinen bestand das Verständnis, dass die vierte Einschränkungsebene implementiert wurde (übermäßige Einschränkungen): Um andere Nummern anzurufen, müssen Sie die ausstehende Aufgabe manuell abbrechen. Tatsächlich stellte sich heraus, dass das Gesetz nicht die Anzahl der Kontaktversuche mit dem Schuldner begrenzt, sondern die Anzahl der erfolgreichen Interaktionsversuche. Dies bedeutete, dass das Interaktionslimit basierend auf den Ergebnissen der Aufgaben berechnet werden sollte.
In diesem Zusammenhang haben wir eine Änderung des Implementierungsformats eingeleitet und eine zweckmäßigere Methode zur Erfüllung der Anforderungen gewählt:
- Zählen Sie die Anzahl der Interaktionen basierend auf den Ergebnissen der Aktivitäten.
- Wenn das Limit nicht erreicht wird, erlauben Sie dem Benutzer / ASANM, Ereignisse ohne Einschränkungen zu planen.
- Wenn das Limit erreicht ist, stornieren Sie unnötige Ereignisse und verbieten Sie deren Ernennung.
Es hat einen ganzen Sprint gedauert, um die Änderungen vorzunehmen, aber wir können definitiv sagen, dass diese Zeit nicht umsonst verschwendet wurde und jetzt, da normale Benutzer keine Unannehmlichkeiten bei der Arbeit in der Anwendung haben, kann der Systembesitzer die Arbeit der Bediener mit ASANM planen.
Fazit
Allen, die sich bei der Implementierung von Einschränkungen um den Benutzer und den Kunden kümmern, wird empfohlen, zwei einfache Regeln einzuhalten:
- „Bei einer ausreichenden Anzahl von Kindermädchen verliert das Kind nicht das Auge“ - das heißt, Sie müssen den Benutzer ausreichend vor Fehlern schützen, die ihm oder dem Besitzer des Systems schaden können.
- „Angst vor Wölfen haben, aber in den Wald gehen“ - unnötige Einschränkungen müssen vermieden werden, da sonst der Wert des entwickelten Produkts für den Benutzer verloren geht.
1 Anforderungen sind im Bundesgesetz vom 03.07.2016 N 230- „Zum Schutz der Rechte und rechtlichen Interessen des Einzelnen bei der Ausübung von Tätigkeiten zur Rückzahlung überfälliger Schulden und zur Änderung des Bundesgesetzes„ Über Mikrofinanzaktivitäten und Mikrofinanzorganisationen “festgelegt.