PowerApps

Power App ohne Anforderungsanalyse – Zum Scheitern veurteilt?

Microsoft Power Apps bietet die Möglichkeit, mit relativ geringem Aufwand und mittelmäßigen Programmierkenntnissen eine voll funktionsfähige App zu erstellen. Dennoch sollte man die Entwicklung dieser Apps, wie auch reguläre Apps, nicht ohne eine ordentliche Anforderungsanalyse machen. Dies führt nämlich sonst zu einem erheblichen Zusatzaufwand, wie ich in diesem Artikel anhand eines anscheinend einfachen Beispiels verdeutlichen möchte.

Während dieser Analysephase können die verschiedenen Stakeholder*innen einbezogen und damit die Machbarkeit aus mehreren Perspektiven beleuchtet werden. Wichtig ist hierbei, dass man die Nutzer*innen, also die Anwender*innen der App, immer auch als Stakeholder*innen betrachtet und diese in die Anforderungsanalyse einbezieht. Denn nur wenn die App einen echten Mehrwert bietet, wird diese auch genutzt. Zudem sollte sich die Bedienung für die Nutzer*innen ebenso gut anfühlen, auch wenn es letztlich „nur“ eine interne App ist. Dies erhöht nicht nur die Freude am Arbeitsplatz, sondern kann auch durch das Gefühl von Wertschätzung für eine bessere Mitarbeiterbindung sorgen.

 
 

Es ist doch so einfach...

QR Code scannen

Aber nehmen wir an, wir bauen nun die App ohne größere Anforderungsanalyse. Wir bekommen die Anfrage, eine App zu bauen, die die Besucherregistrierung am Empfang digitalisieren soll. Die Anfrage kommt direkt mit einem Lösungsvorschlag. Man möchte einen QR Code auslegen, den die Besucher*innen abscannen können, zu einem Formular weitergeleitet werden, in dem diese ihren Namen eintragen können und damit angemeldet sind. Als „nice-to-have“ Option könnte man noch eine Kontaktperson über Teams kontaktieren.

Wenn man sich nun die Frage stellt, wie dies umgesetzt werden könnte, kommt man schnell zu dem Schluss, dass man die QR-Code-Scan-Funktion in Power Apps für diesem Fall nicht benötigen wird. Obwohl dies technisch leicht umzusetzen wäre. Die Nutzer*innen können ihre eigenen QR-Code -Scanner verwenden, der häufig bereits nativ in der Kamera App integriert ist. Die Idee des QR-Codes ist es lediglich, die Nutzer*innen auf die richtige Seite zu schicken. Was jedoch auch eine native App kann. Hier können die Nutzer*innen also gewohnte Funktionen nutzten. In der Power App erstellt man einfach Eingabefelde für die benötigten Daten, die in einer SharePoint Liste gespeichert werden und voilà man hat seine Besuchererfassung. Für das i-Tüpfelchen kann man auch noch ein Personen-Dropdown einfügen, welche bei Bestätigung einen Workflow mit Power Automate losschickt und die ausgewählten Mitarbeiter*innen über Teams mit einer Adaptive Card kontaktiert.

Jetzt kommt das ABER

Nun kommt das erwartete ABER! Besucher*innen sind im Regelfall nicht ein Teil meiner Organisation und können daher auch nicht ohne Weiteres auf eine Power Apps zugreifen. Ich möchte auch nicht jede Besucher*in als Gast in meinem Azure AD pflegen. Dies bedeutet im Umkehrschluss, dass die App nicht auf den Geräten der Besucher*innen laufen kann. Eine Lösung hierfür wäre, ein Anmeldegerät bereitzustellen, welches beispielsweise über den Account der Empfangsperson läuft. Hier kann die App einfach ausgeführt werden. Zusätzlich fällt auch der Schritt des QR-Codes scannen weg, da die App ja bereits geöffnet sein kann, was den Prozess tatsächlich effizienter für die Besucher*innen macht. Hier ist also wichtig, frühzeitig technische Experten und Expertinnen mit ins Boot zu holen, die genau solche Fallen aufdecken.

Neben dem Szenario, ich besuche als einzelne Person ein Unternehmen und habe eine bestimmte Kontaktperson, kann es ja auch sein, dass ich eine  Kollegin oder einen Kollegen mitbringe und wir beide einen Termin mit  derselben Person haben. Dann wäre es einfacher, wenn ich gleich uns beide eintragen kann. Oder ich habe gar keine Kontaktperson und möchte nur ein Event besuchen. Diese verschiedenen Szenarien stellen unterschiedliche Anforderungen an das User Interface. So muss ich die Möglichkeit haben, einen weiteren Gast einfügen zu können und auch keine Kontaktperson auswählen zu müssen. Weiß man diese Dinge, bevor man die App erstellt, kann man die Datenspeicherung als auch das Interface direkt darauf anpassen. Daher ist es ratsam, mit den Personen am Empfang und mit Besucher*innen zu sprechen sowie einige Besuchssituationen einfach zu beobachten. Dadurch kann man die verschiedenen Anforderungen der Nutzer*innen aufnehmen. Selbst wenn man diese nicht beim ersten Release umsetzt, weil man einen MVP (Minimal Viable Product) erstellen möchte, ist es dennoch besser, eine Idee von der zukünftigen Komplexität zu erhalten.

Letztlich fällt dann vielleicht noch auf, dass die Daten auch irgendwann wieder gelöscht werden müssen und dass die Nutzer*innen über ihre Datenschutzrechte belehrt werden müssen. Ist die App bereits produktiv im Einsatz, bedeutet dies sehr viel Pflegeaufwand. Die Daten sollten im besten Fall mit Retention Labels automatisiert gelöscht werden. Die Datenschutzerklärung muss in die App eingebaut sein, damit die Nutzer*innen direkt darüber aufgeklärt werden. Bindet man hier seine*n Datenschutzbeauftragte*n frühzeitig ein, kann man auch diese Aspekte gleich mit in die Anforderungsanalyse aufnehmen.

 
 
Check In App Wireframes

Brauchen jetzt alle Projekte Lastenhefte?

Nun entsteht vielleicht der Eindruck, man müsse für eine kleine App gleich ein langes Lastenheft erstellen und man fragt sich, ob es diesen Aufwand wert sei. Genau das ist auch der Punkt, an dem viele sagen: „Na da bleibe ich doch lieber bei meinem Anmeldeheft aus Papier.“ Jedoch kann zum einen so eine App auch iterativ entwickelt werden. Wie bereits gesagt, man nimmt sich erst mal ein Szenario raus oder stellt für sich fest, manche Anforderungen sind in unserem Kontext überhaupt nicht relevant. Zum anderen wird das Entwicklungsteam aber auch immer eingespielter. Ein Anforderungsworkshop gehört dann einfach als fester Bestandteil zum Prozess dazu. Mit dem Wissen, je mehr Klarheit man im Vorfeld bei den Anforderungen schafft, desto weniger Aufwand hat man im Nachgang und desto wartbarer bleibt auch die App.

Auch wir im Team arbeiten so. Neben den Vorteilen für das Produkt sehen wir es auch als persönliche Bereicherung, sich außerhalb der eigenen Expertise auszutauschen und beim nächsten Projekt evtl. auch die ein oder andere Anforderung außerhalb des eigenen Fachbereiches definieren zu können.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Neueste Kommentare