Häufige Fehler: Funktionale Web-Spezifikation

Unwirksame Funktionsspezifikationen für Webprojekte wie Websites, Intranets oder Portale tragen weitgehend zu Verzögerungen, höheren Kosten oder Anwendungen bei, die nicht den Erwartungen entsprechen. Unabhängig davon, ob die Website, das Intranet oder das Portal maßgeschneidert entwickelt oder auf gepackter Software wie Web-, Enterprise Content Management oder Portalsoftware basiert, ist die funktionale Spezifikation die Grundlage für Projektverzögerungen und höhere Kosten. Um Verzögerungen und unerwartete Investitionen während des Entwicklungsprozesses zu begrenzen, sollten folgende Fallstricke vermieden werden:

Zu vage oder unvollständige funktionale Spezifikation: Dies ist der häufigste Fehler, den Unternehmen tun. Alles, was mehrdeutig oder gar nicht definiert ist, implementieren oder implementieren Entwickler nicht auf eine andere Weise, was Website-Eigentümer wollen. Dies betrifft vor allem Web-Features, die als gemeinsame Nutzererwartungen gelten. Zum Beispiel HTML -Tag-Tags, die zum Bookmarkieren von Webseiten verwendet werden. Der Web-Lenkungsausschuss kann spezifizieren, dass jede Seite einen Seitentitel enthält, aber nicht spezifiziert, dass HTML-Titel-Tags ebenfalls implementiert werden müssen. Web-Entwickler können daher nicht implementieren HTML-Titel-Tags oder implementieren sie in einer Weise, die von Website-Besitzer Visionen unterscheidet. Es gibt weitere Beispiele, wie beispielsweise die Fehlerbehandlung auf Online-Formularen oder die Definition von ALT-Texten für Bilder, um mit dem Behinderungsaktabschnitt 508 übereinzustimmen. Diese Beispiele sehen aus wie Details, aber in der Praxis, wenn Entwickler Hunderte oder sogar Tausende von Seiten modifizieren müssen Beträgt mehrere Mann-Tage oder sogar Mann-Wochen. Insbesondere müssen die Korrekturen für Bilder als Unternehmer zuerst die Bildnamen definieren, bevor Webentwickler die ATL-Texte implementieren können. Ambiguous funktionale Spezifikation kann aufgrund des Mangels an interner oder externer fehlender Usability-Fähigkeiten führen. In diesem Fall überträgt ein eintägiger Usability-Best-Practice-Workshop die notwendigen oder zumindest grundlegenden Usability-Fähigkeiten an das Web-Team. Es wird empfohlen, auch für Unternehmen, die über Usability-Fähigkeiten verfügen oder sich auf die Fähigkeiten des Subunternehmers verlassen, dass ein externer und neutraler Berater die funktionalen Spezifikationen überprüft. Insbesondere beziehen sich solche Bewertungen auf marginale Ausgaben im Vergleich zu den gesamten Webinvestitionen (z. B. ungefähr $ 10 K – $ 15 K Dollar für eine Überprüfung).

Zukünftige Website-Erweiterung nicht identifiziert oder nicht kommuniziert: Es ist wichtig, dass der Web-Ausschuss mindestens die wichtigsten zukünftigen Website-Erweiterungen identifiziert und kommuniziert sie an das Entwicklungsteam. Im besten Fall kennt das Entwicklungsteam den Fahrplan für die kommenden drei Jahre. Ein solcher Ansatz ermöglicht es dem Entwicklungsteam, die Implementierungsoptionen vorwegzunehmen, um zukünftige Standortverbesserungen zu bewältigen. Es ist mittel- oder langfristig kostengünstiger, am Anfang mehr zu investieren und eine flexible Lösung aufzubauen. Wenn Webteams künftige Verbesserungen nicht kennen oder gar ignorieren, erhöht sich das Risiko für höhere Investitionen (z. B. das Hinzufügen neuer Funktionen in der Zukunft zum Teil oder im schlimmsten Fall bei der völligen Wiederherstellung der bestehenden Funktionalität). Mit Blick auf das Finanzdelta für eine flexible Lösung gegenüber einer Lösung, die nur den aktuellen Anforderungen gerecht wird, hat sich die flexible Lösung in der Praxis aus einer mittel- und langfristigen Perspektive als kostengünstiger erwiesen.

Geplante Funktionalität, die nicht auf interne Ressourcen abgestimmt ist: Viele Unternehmen betrachten die Standortfunktionalität nur aus Sicht des Standorts (z. B. Erleichterung der Suche von Informationen oder Durchführen von Transaktionen) und Unternehmensvorteilen (z. B. finanzielle Vorteile von Self-Service-Funktionen). Allerdings gibt es eine dritte Dimension die Auswirkungen der Website-Funktionalität auf interne Ressourcen. Site-Funktionalität, die sich stark auf interne Ressourcen auswirken können, sind beispielsweise:
– Web-Sites: Bereitstellung von Nachrichten, Online-Rekrutierung, Online-Support, etc.
– Intranets / Portale: Bereitstellung von Content-Maintenance-Funktionen für Business-Manager

Für den Erfolg der Site-Funktionalität ist es entscheidend, dass das Web-Komitee die Auswirkungen analysiert und Maßnahmen ergreift, um die geplante Funktionalität sicherzustellen. Zum Beispiel die Bereitstellung der Inhaltswartungsfunktionalität für Unternehmer und Produktmanager mit einem zugeordneten Workflow. Diese Funktionalität ist effektiv und kann Geschäftsvorteile wie reduzierte Zeit bis zum Markt zu generieren. In der Praxis müssen Unternehmer und Produktmanager jedoch Inhalte schreiben, validieren, überprüfen, genehmigen und zurückziehen. Dies führt zu zusätzlicher Arbeitsbelastung. Wenn das Web-Komitee in der Web-Governance (Prozesse, Richtlinien, Besitz und potenziell Durchsetzung) nicht definiert ist, kann es vorkommen, dass diese Funktionalität nicht verwendet wird und daher nutzlos wird.

Wunschlisten versus tatsächlichen Anforderungen und geschäftlichen Anforderungen: Die funktionale Spezifikation ist nicht auf die Bedürfnisse der Benutzer oder geschäftliche Anforderungen ausgerichtet. Dies ist häufiger für interne Anwendungen wie Intranets oder Portale. In vielen Fällen vernachlässigt der Projektausschuss eine solide interne Umfrage und definiert die Funktionalität durch die Verallgemeinerung der individuellen Wünsche der Mitarbeiter, ohne dass ein Klang entsteht. Das Erfassen der Rückmeldung interner Benutzer im gesamten Unternehmen ermöglicht die Bestimmung der kritischen Funktionalität. Um eine Umfrage effektiv durchführen zu können, muss ein repräsentativer Mitarbeiter eingestellt werden. Darüber hinaus müssen diese Mitarbeiter in Profile kategorisiert werden. Die Profile müssen beispielsweise durch die Häufigkeit der Nutzung des Intranets, die geschätzte Dauer des Besuchs, die Nutzung des Intranets zur Erleichterung ihrer täglichen Aufgaben, den Beitrag zum Geschäft usw. charakterisiert werden. Basierend auf diesen Informationen kann das Webteam dann die Prioritäten setzen Funktionalität und wählen Sie die effektivste und relevanteste Funktionalität für die nächste Version. Weniger kritische oder weniger wichtige Funktionalitäten können Bestandteil zukünftiger Releases sein (Roadmap) oder fallengelassen werden. Wenn solch ein solider Entscheidungsprozess nicht durchgeführt wird, kann es vorkommen, dass Funktionalität entwickelt wird, aber nur von wenigen Benutzern verwendet wird und die Rückkehr von Investitionen nicht erreicht wird.

Nicht genügend visuelle Unterstützung oder rein textbasiert: Textliche Beschreibung von Web-Anwendungen kann subjektiv interpretiert werden und damit zu falschen Erwartungen führen. Zur Vermeidung von falschen Erwartungen, die nur während der Entwicklung oder schlimmstenfalls zum Startzeitpunkt entdeckt werden können, muss die Funktionsspezifikation durch visuelle Unterstützung ergänzt werden (zB Screenshots oder bestenfalls HTML-Prototypen für Homepages oder beliebige wichtige Navigationsseiten wie Sub-Homepages Für die wichtigsten Abschnitte der Website wie für Human Resources, Business Units, Finanzen, etc.). Dies ermöglicht eine Verringerung der subjektiven Interpretation und die Berücksichtigung des Feedbacks der Nutzer vor der Entwicklung. Solch ein Ansatz hilft, die richtigen Erwartungen zu setzen und jegliche Enttäuschungen am Ende zu vermeiden, sobald die neue Anwendung online ist.

Diese gemeinsamen Fehler haben wir selbständig beobachtet, wenn Unternehmen ihre Web-Anwendungen intern entwickelt oder an externe Dienstleister vergeben haben.