Wenn du noch nie erlebt hast, dass eine Aufwandsschätzung an der Realität vorbei ging, heb deine Hand. Erobert von optimistischen Schätzungen und verführerisch niedrigen Kosten, wird das vermeintlich beste Angebot ausgewählt. Die Komplexität ist doch gering und die Versprechungen des Anbieters traumhaft. Dann schlägt die Realität zu und Change Request nach Change Request treibt die Kosten in die Höhe.

Hier ist die gute Nachricht: Es muss nicht bei deinem Projekt passieren. Mit dem richtigen Wissen kannst du Luftschlösser zerschlagen, indem du geschickt Fragen stellst und dich wieder einer realistischen Schätzung näherst. Dieser Artikel widmet sich den unterschätzten Themen solcher Projekte. Am Ende weißt du, wo du deine Schätzung noch einmal hinterfragen kannst. Bereit? Dann lass uns anfangen.

1

Änderungen der Anforderungen

Beginnen wir direkt mit einem Thema, das du selbst beeinflussen kannst. In der Praxis ist es viel zu oft der Fall, dass sich die Anforderungen im Laufe eines Projekts immer wieder ändern. Das ist zunächst nicht überraschend. Entscheidungen müssen sich mit zunehmendem Wissen anpassen können. In Projekten werden jedoch manchmal voreilig Entscheidungen getroffen und dann rückgängig gemacht. Dies kann vermieden werden. Das Verschieben einer Taste von links nach rechts und zurück gilt als kleine Änderung. Aber es entstehen Abhängigkeiten, z.B. bei der Entwicklung, Kommunikation und beim Testen. Das ist auf Dauer nicht nur teuer, sondern demotiviert auch den Entwickler. Das kann und sollte reduziert werden, indem man die Anforderungen und Wünsche im Voraus plant und definiert.
2

Fehlermeldungen und Fehlerbehandlung

Dein Online-Service richtet sich an den Endkunden, das integrierte Backend-System an erfahrene Spezialisten. Die kleinen, aber feinen Unterschiede werden oft vernachlässigt. Fehlermeldungen und Fehlerbehandlung gehören daher zu den weniger beachteten Kostentreibern. Multichannel Foundation for Utilities ist direkt mit dem IS-U und ggf. dem CRM-System integriert. Werden die Fehlermeldungen dieser Systeme nicht ersetzt oder abgefangen, werden sie ungefiltert an den Kunden übermittelt. Dies ist für den Kunden nicht nur teilweise unverständlich, sondern auch für dich nicht wünschenswert. Daher solltest du über die möglichen Fehlerfälle nachdenken. Es kann sinnvoll sein, generische Fehlermeldungen für unbedachte Fälle zu verwenden. Überlegungen dazu erhöhen nicht nur die Planungssicherheit, sondern reduzieren auch das Risiko unerwünschter Überraschungen im Produktivbetrieb.
3

Kontakte und Benachrichtigungen

Nachdem ein Prozess in deinem Online-Service durchgeführt wurde, möchtest du wahrscheinlich deinen Kunden oder einen Mitarbeiter informieren und einen Kontakt zum Geschäftspartner hinzufügen. Deine Ideen sollten rechtzeitig geplant und kommuniziert werden. Für welche Prozesse möchtest du welche Aktion durchführen? Gibt es Einschränkungen? Wenn du beispielsweise nur eine E-Mail an eine bestimmte Kundengruppe senden möchtest, ist dies möglich. Aber auch ein unerwarteter Aufwand, wenn diese Anforderungen mitten im Projekt erstmals angesprochen werden. Es ist sinnvoll, die gewünschten Variablen, die Empfänger, aber auch Text und Layout von Anfang an zu berücksichtigen. Bei Kontakten sollte z.B. auch die Verknüpfung mit BOR-Objekten im Vorfeld berücksichtigt werden. Können deine Kunden Dateien hochladen? Dann muss auch der Speicherort der Datei und die Virenprüfung berücksichtigt werden.
4

Abstimmungen und Koordination zwischen Backend und Frontend

Für einen Online-Service, der direkt in das Backend-System integriert ist, ist die Koordination zwischen beiden wichtig. Die Entwickler der Benutzeroberfläche sollten über ein grundlegendes Verständnis der abzubildenden Prozesse verfügen und eng mit den für den Online-Service zuständigen Backend-Entwicklern zusammenarbeiten. Die Multichannel Foundations for Utilities OData Services sind nicht selbsterklärend, daher ist es sinnvoll, die beiden Teams an einem Ort zu platzieren. Die Aufgaben sollten so konzipiert sein, dass Ausfallzeiten auf beiden Seiten vermieden werden. Allerdings ist auch außerhalb des reinen Online-Angebots eine Abstimmung erforderlich. Werden Schnittstellen, auf die die Online-Dienste zugreifen, angepasst, muss die Funktionalität erneut getestet werden. Unsere Kunden haben bisher gute Erfahrungen damit gemacht, die Funktionalität im Frontend und Backend von Anbietern mit Branchenkenntnissen durchführen zu lassen. Basierend auf unseren Erfahrungen kann das Design problemlos an eine Webagentur ausgelagert werden.
5

Tests

Ich möchte mit dem aus meiner Sicht wichtigsten Thema enden. Bei einem Angebot für Endkunden solltest du Tests nie vernachlässigen. Hier gilt das Sprichwort "Es gibt keine zweite Chance für den ersten Eindruck". Für die Tests sollte genügend Zeit vorgesehen werden. Es ist zu spät, die Tests zwei Wochen vor dem Produktivstart zu beginnen. Plane sinnvollerweise mit mindestens zwei Testwellen. Nach dem ersten Test sollte ein Zeitraum für Korrekturen und Entwicklungen festgelegt werden. Teste anschließend den gesamten Service noch einmal, bevor der Produktivbetrieb aufgenommen wird. Während des Tests ist es ratsam, die Tester und Entwickler gemeinsam zu positionieren. So können Entwickler schneller auf Fehler reagieren und Unklarheiten während der Nutzung erkennen. Nutzen Sie die Zeit und Gelegenheit, bekannte Fehler vor dem Produktivstart zu korrigieren. Eilige Notfallkorrekturen müssen unbedingt vermieden werden.

Jetzt kennst du die fünf am meisten unterschätzten Themen in Multichannel Foundation for Utilities Projekten. Und das Beste daran ist, dass diese Themen sehr universell sind. In deinem nächsten Projekt kannst du diese Themen direkt bewerten und weniger offensichtliche Aufwandsfaktoren ansprechen.

Hast du Feedback aus deinen Projekten, das für andere nützlich ist? Hast du Fragen? Dann hinterlasse einen Kommentar oder kontaktiere uns.

Hinterlasse eine Antwort