Beinahe jedes IT-Projekt setzt auf die ein oder andere Art und Weise Features um. Jedes Software Produkt brüstet sich mit einer umfangreichen Feature Liste und Feature getriebene Entwicklung scheint, auf den ersten Blick, das Normalste der Welt zu sein. Der Teufel steckt jedoch, wie so oft, im Detail: in der Ausgestaltung der einzelnen Features.

%CAD2%

Was ist ein Feature?

Ein Feature ergibt sich in einem klassischen Digital-Projekt aus einer Kombination aus verschiedenen Anforderungen – sowohl fachlich als auch technischer Natur. Es beschreibt primär eine Eigenschaft oder Funktion, die das Produkt erhalten soll. Dies ist natürlich sehr unspezifisch. Die Frage muss daher wesentlich konkreter gefasst werden: Was ist ein geeignetes Feature, um das Projekt voranzutreiben und dem Entwicklungsteam sinnvolles Arbeiten zu ermöglichen?

Feature versus Story

In heutigen Softwareentwicklungstools wie JIRA und anderen Ticketsystemen entspricht ein Feature oft einer sogenannten User Story. Kommt die Feature getriebene Entwicklung also aus dem agilen Umfeld? Und kann sie nur dort angewendet werden? Definitiv nein.

Vielmehr hat die agile Entwicklung das Feature erneut wieder in den Fokus der Entwicklung gerückt. Auch die klassischen Konzeptpapiere sind Sammlungen von Features und deren Beschreibung. Nur sind in Vorgehensweisen wie Wasserfall oder V-Modell die Definition eines Features und dessen Umsetzung zeitlich voneinander getrennt. Teilweise ist fachliche und technische Konzeption auch aufgeteilt in Pflichten- und Lastenheft.

Im agilen Umfeld – sei es nun Scrum oder Kanban oder eine Mischform – sind Definition und Umsetzung wesentlich näher beieinander.

Die Feature getriebene Entwicklung stellt nun das Feature ganz klar in den Mittelpunkt des Projekts. Während der Umsetzung gilt das Ticket als zentrales Dokument bzw. Artefakt, um alle Informationen zu einem Feature zusammenzustellen.

Warum Features?

Durch die Aufteilung der Konzeption in Pflichtenheft und Lastenheft und einem sehr späten Beginn der eigentlichen Umsetzung entstehen lange, parallele und damit getrennte Handlungsstränge.

Hinzu kommt, dass umfangreiche Konzeptpapiere oftmals nicht gelesen werden. Viele Kunden stehen kurz vor dem Start der Umsetzung schon so in den Startlöchern, dass für das Studium des Feinkonzepts oftmals nicht die nötige Muße vorhanden ist und teilweise auch die Zeit fehlt, es in der Tiefe durchzugehen. Und wer kann die Komplexität eines so umfangreichen Projekts anhand eines 350 Seiten Konzeptes noch erfassen? Es bleibt trotz einer Unmenge an produziertem Papier viel Raum zu Interpretation und Missverständnissen.

Dadurch kommt im Projektverlauf trotzdem zu Auseinandersetzungen, weil die Erwartungen nicht getroffen wurden. Und als Dienstleister zieht man langfristig meist “den Kürzeren”. Die Beziehung zwischen Kunde und Dienstleister leidet und wirklich Spaß macht das Projekt so auf jeden Fall nicht mehr.

Zudem können die althergebrachten Argumente der agilen Vorgehensweise hier ebenfalls ins Feld geführt werden: Anforderungen ändern sich über die Zeit, daher sollten sie erst kurz vor der tatsächlichen Umsetzung konkret formuliert werden. Aber dies ist kein Artikel über Scrum versus Wasserfall, sondern er zeigt, wie man gute Features definiert und welche Erfolgsfaktoren hierbei eine Rolle spielen.

Gemeinsame Verantwortung

Wichtig für eine erfolgreiche Umsetzung ist besonders die gemeinsame Verantwortung von Fachbereich und Entwicklung. Nur gemeinsam kann ein Feature konkret genug beschrieben werden, um ein gemeinsames Verständnis der Aufgabe herzustellen. Eine gleichartige Erwartungshaltung ist extrem wichtig, um ein Projekt erfolgreich abzuschließen.

Daher sollte auch das jeweilige Ticket, in dem das Feature beschrieben ist, allen Projektteilnehmern gemeinsam gehören. Im Ticket werden u.a. die folgenden Details beschrieben:

Fachliche Anforderungen: Was ist das zentrale Ziel, das die Fachabteilung erreichen möchte?

• Kurze Beschreibung des Features, worum geht es?
• Was sind die Key Points, die der Fachabteilung besonders wichtig sind?
• Wie soll ein Feature funktionieren, welche Abläufe sind essentiell?
• Was sind Akzeptanzkriterien, wie weiß das Entwicklungsteam, dass das Feature fertig ist?

Rückfragen: Ein temporärer Bereich, in dem das Entwicklungsteam Rückfragen für ein Meeting mit der Fachabteilung oder dem Product Owner sammeln kann.

• Dies könnte auch in einem verknüpften Ticket gesammelt werden. Es kann aber sinnvoll sein, dies zu Dokumentationszwecken direkt im eigentlichen Feature Ticket zu verorten

Technische Umsetzungsplanung: Welche Ideen hat das Entwicklungsteam bereits gesammelt?

• Welche Technologie wird eingesetzt?
• Welche Annahmen über die Ausgangslage werden getroffen? Welche Abhängigkeiten gibt es?
• Welche Entwurfsmuster oder Ansätze werden verfolgt?
• Wie sind die Zuständigkeiten zwischen Frontend und Backend aufgeteilt?
• Wie können aus den Akzeptanzkriterien bereits Testszenarien abgeleitet werden?
• Wieviel Aufwand sieht das Entwicklungsteam für die Umsetzung des Features

Ein Wort zur Aufwandsschätzung

Viele Entwicklungsteams, die “Scrum nach Lehrbuch” praktizieren wollen, tun sich schwer damit, in Stunden oder Personentagen zu schätzen. Es wirkt “zu konkret”. Es scheint keine Schätzung mehr zu sein, sondern ein Ergebnis.

Letztendlich ist die Schätzung in Stunden aber auch eine Komplexitätsbewertung. Und um die geht es beim klassischen Planning Poker hauptsächlich. Letztendlich rechnen viele Entwickler die Punkte des Planning Pokers ohnehin wieder in Stunden um, damit sie die korrekte Bewertung für sich im Kopf machen können. Und beim Planning selber ist es in einem Kunde-Dienstleister Verhältnis ebenfalls wichtig, die Aufwände für das Projekt konkret genug zu kennen, damit ein Sprint oder eine Umsetzungsplanung halbwegs treffsichere Erkenntnisse liefert.

Bisher war es nach einer kurzen Umgewöhnung noch nie ein Problem für Entwickler, Features in Stunden und Tagen statt in Punkten zu schätzen. Die Diskussionen, warum ein Entwickler 2 Stunden und einer 6 Stunden schätzt, sind genauso hilfreich und decken die gleichen Dinge auf, wie ein Unterschied in Punkten.

Tipps für die Praxis

Was sollte man bei der Definition von Features beachten?

• Immer eine feste Struktur: Legen Sie alle Feature Tickets nach dem gleichen Schema an. So ist sichergestellt, dass kein Aspekt vergessen wird und alle Projektmitarbeiter sich jederzeit zurechtfinden.
• Lieber eine Frage zu viel stellen, als eine Frage zu wenig: Bei der Beschreibung eines Features gilt das Motto: Viel hilft viel. Jede Frage, die bereits bei der Definition gestellt wird, sorgt für weniger Abstimmungsaufwand im Laufe der Umsetzung.
• Auch offensichtliche Annahmen konkret hinterfragen: Manches erscheint auf den ersten Blick “normal” und “selbstverständlich”. Doch viele Projekte zeigen deutlich, dass gerade hier die Erfahrungswelten der Beteiligten voneinander abweichen können. Das macht Missverständnisse in diesem Bereich besonders ärgerlich, weil damit keiner gerechnet hat.
• Ein Bild sagt mehr als tausend Worte: Viele Themen lassen sich entweder mit viel Prosa beschreiben oder mit einem Diagramm schnell auf den Punkt bringen. Auch Scribbles oder Ergebnisse des Paper Prototyping können wertvolle Informationen für die Umsetzung enthalten.
• Mehrdeutigkeit vermeiden: Machen Sie vor dem Finalisieren der Definition auf jeden Fall noch einen Plausibilitäts-Check. Oft kommt es vor, dass im Rahmen von Diskussionen plötzlich widersprüchliche Informationen im Ticket angekommen sind. Hier fällt es nachher schwer, die gültige Definition zu ermitteln. Gehen Sie also auf Nummer sicher und prüfen Sie die fertiggestellte Definition. So können Sie unangenehme Überraschungen vermeiden.
• Überschaubare Größe eines Features: Der Aufwand pro Gewerk sollte nicht mehr als einen Personentag betragen. Beteiligt sein können beispielsweise Frontend, Backend, Administration, Design, etc. Hierdurch wird das Risiko für das einzelne Feature auf genau diesen Aufwand minimiert.
• Abhängigkeiten reduzieren: Features sollten möglichst so gekapselt werden, dass keine konkreten Abhängigkeiten bestehen. Je isolierter ein Feature umgesetzt werden kann, umso besser kann es auch getestet und abgenommen werden.
• Akzeptanzkriterien und Testkriterien gehören zusammen: Das zentrale Element für die Abnahme eines Features durch den Fachbereich sind die Akzeptanzkriterien. Sie ermöglichen es, die Erwartungshaltung genau zu definieren. Im Optimalfall können an die Akzeptanzkriterien der Fachabteilung direkt Testszenarien der Entwicklung geknüpft werden. So wissen beide Seiten, wann das Feature als abgeschlossen gilt.

Kunst oder Wissenschaft?

Die Tipps zeigen, dass es an der ein oder anderen Stelle durchaus knifflig werden kann. Welches Feature hat schon keinerlei Abhängigkeiten? Kann man immer so genau zwischen acht und zehn Stunden Aufwand differenzieren? Hier verschwimmt die Grenze zwischen Kunst und Wissenschaft. Das optimale Beschreiben eines Features basiert in den meisten Fällen auf Erfahrung und einer Intuition, wie ein Feature am besten “geschnitten” wird, damit man möglichst alle Tipps beachtet. Sie sollten jedoch nicht als Dogma betrachtet werden.

Gibt es beispielsweise Features, die länger als acht Stunden im Backend bedeuten, so kann es durchaus sinnvoll sein, dies trotzdem so beizubehalten. Wenn beispielsweise die Umsetzung mehrerer Webservices gebündelt Sinn macht und die Vorgehensweise klar ist, so ist auch das Risiko für dieses Feature nicht besonders hoch. Es handelt sich um “Fleißarbeit”, die gut abzuschätzen und planbar ist.

Chancen und Herausforderungen beim Dienstleister

Wie man sieht, maximiert die gemeinsame Verantwortung bei den Tickets (und damit den Features) die Transparenz im Entwicklungsprozess. Die Fachabteilung darf und muss sich aktiv einbringen. Sie bekommt mit, welche technischen Hürden bestehen und welche Anforderungen eventuell trivial sind. Das Entwicklungsteam bekommt mit, warum welche Funktionen benötigt werden und erkennt, dass die Wirklichkeit wesentlich “dreckiger” ist als in der schönen Welt von 0 und 1. Schließlich sind Digital-Projekte meistens komplexe Abläufe in komplexen Umfeldern, die nicht am Fließband abgearbeitet werden können.

In der Theorie wird somit das gemeinsame Verständnis füreinander gestärkt. Soweit so gut. Was sind nun die Risiken der Feature getriebene Entwicklung für Dienstleister? Findet die Entwicklung komplett In-House und ohne externen Dienstleister statt, sind die Fronten geklärt und die Kosten liegen komplett intern. Hier kann es natürlich auch zu Unstimmigkeiten kommen, aber dies kann innerhalb der bestehenden Organisation gelöst werden.

In der Beziehung zwischen Dienstleister und Kunden gibt es eine andere Dynamik. Man muss sich daher im Klarem sein, dass Transparenz ein großes Maß an Vertrauen und Goodwill erfordert. Nicht jede Beziehung hält dies aus. Wenn eine Atmosphäre des Misstrauens besteht, dann kann das Entwicklungsteam nicht offen über technische Hürden sprechen. Bereits getroffene Entscheidungen können nur sehr schwer für eine noch bessere Lösung in Frage gestellt werden. Und fehlende Kompetenz in einem Bereich kann nicht offen zugegeben werden, weil man sich sonst in ein schlechtes Licht rückt. Die Aufwände können beim Kunden für Unverständnis sorgen und es kann zu handfestem Streit bei den gemeinsamen Meetings kommen.

Spielen beide Seiten mit offenen Karten, so zeigt die Erfahrung aber: Es lohnt sich! Die Transparenz stärkt das Vertrauen in die Kompetenz und die Arbeitsweisen. Die Vorgehensweisen des Dienstleisters werden nachvollziehbar. Das Anliegen des Kunden wird deutlich. Die Ergebnisse der Umsetzung sind besser und passen genau zu den Erwartungen des Kunden. Beide Seiten können ein erfolgreiches Digital-Projekt feiern.

Typische Herausforderungen und mögliche Lösungsansätze

Auch, wenn man sich gemeinsam und mit jeder Menge Vertrauen in das Abenteuer eines Relaunchs oder einer Produktentwicklung stürzt, zeigt die Projekterfahrung, dass es doch einige Herausforderungen zu meistern gilt:

Stakeholder können Anforderungen schlecht formulieren

Viele Mitarbeiter von Fachabteilungen sind es nicht gewohnt, Anforderungen so zu formulieren, dass sie jemand anderes, geschweige denn ein Entwickler mit einem ganz anderen Erfahrungshintergrund, genauso versteht, wie es gemeint ist. Ein Entwicklungsteam mit einer großen Domain Knowledge, also Vorerfahrung in dem Fachbereich um den es geht, kann hier helfen. Es kann hilfreich sein, die Untiefen des Leasingerlasses zu kennen, um die größten Klippen zu umschiffen. Wie damit aber von Kunde zu Kunde intern umgegangen wird, kann nur die Fachabteilung definieren.

Die Erfahrung zeigt, dass zwei Aspekte sehr hilfreich sind: On-Boarding und Coaching-on-the-Job. On-Boarding kann durch einen vorgelagerten Workshop geschehen. Hier werden alle Beteiligten anhand von Beispiel Features durch den Prozess geleitet. Es wird klargemacht, welche Rolle im Projekt für welche Themen verantwortlich ist. Idealerweise wird gegen Mitte des Workshops bereits das ein oder andere Feature aus dem Projekt heraus als Übungsgegenstand verwendet.

Das Coaching sollte im Rahmen der Umsetzungsphase in regelmäßigen Intervallen geschehen. Hier bietet es sich an, anhand von anstehenden Features das Refinement mit einem Scrum Master oder Projektleiter gemeinsam vorzunehmen. Zu Beginn des Projekts kann dies intensiv geschehen, bspw. mit zwei Terminen pro Woche. Später sollte man es von der Art der Features und den Erfahrungen des Entwicklungsteams abhängig machen.

Die Fachabteilung unterschätzt den eigenen Aufwand

Wie man vielleicht vermuten kann, bedeutet das konkrete Formulieren von Features einen nicht zu unterschätzenden Zeitaufwand. Kann man sich um das Lesen eines 350 Seiten Konzepts noch irgendwie herumdrücken oder überfliegen, ob die eigenen Annahmen getroffen wurden, ist die Zusammenstellung von Features für Fachabteilung und Entwicklungsteam harte Arbeit. Arbeit, die sich lohnt, aber die getan werden muss.

Wieviel dies im Einzelnen bedeutet, wird von vielen Fachabteilungen unterschätzt. Teilweise werden durch Rückfragen des Entwicklungsteams auch Herausforderungen im Prozess aufgezeigt, die vorher noch gar nicht klar wurden. Dies bedeutet an vielen Stellen Hausaufgaben für die Fachabteilung und kann im schlimmsten Fall für Verzögerungen in der Umsetzung sorgen, da noch aufwändige Abstimmungsrunden durchlaufen werden müssen.

Wer kümmert sich beispielsweise um die Anfragen, die über das neue Kontaktformular eintreffen? Die Zentrale? Die Niederlassung? Gibt es in jeder Niederlassung kompetente Ansprechpartner? Gibt es ein professionelles Input Management für Anfragen, die ausgedruckt oder als Fax übermittelt werden? Wie wird auf diese Anfragen geantwortet, wenn der restliche Prozess komplett auf E-Mails ausgerichtet ist?

Wie sieht der Entwicklungsprozess aus?

Heutzutage gibt es viele geeignete Softwareentwicklungs-Tools. Eine sehr weit verbreitete Suite für die Abwicklung verschiedenster Projekte bietet Atlassian an. Hierzu zähle JIRA als Ticketsystem, Stash als Repository-Verwaltung und Bamboo als Build & Delivery Server. Die folgende Beschreibung orientiert sich zwar an Atlassian Produkten, kann aber ohne Probleme auch auf andere Kombinationen übertragen werden.

Ticket wird erstellt und Informationen werden ergänzt – gemeinsam oder asynchron

Als zentrales Dokument während der Umsetzung steht zu Beginn der Entwicklung das Ticket in JIRA. Hier werden, angelehnt an die Tipps aus der Praxis, die Anforderungen an das Feature festgehalten und alle sinnvollen Beschreibungen erfasst.

Feature wird geschätzt

Auf Basis der Informationen im Ticket werden die voraussichtlichen Aufwände geschätzt. Das Verfahren richtet sich hier nach der Projektmethode. Bei Scrum-Projekte würde dies beispielsweise im Rahmen des Planning Pokers stattfinden und das Entwicklungsteam würde die Schätzung gemeinsam vornehmen. Die geschätzten Aufwände werden am Ticket erfasst. JIRA bietet hierfür verschiedene Möglichkeiten, unter anderem auch das Schätzen in Stunden oder Tagen.

Feature wird für die Umsetzung vorgesehen

Damit das Feature auch tatsächlich umgesetzt wird, erfolgt eine Priorisierung der verschiedenen Features für den nächsten Umsetzungszeitraum. Bei einem Scrum-Projekt würde es beispielsweise für das nächste Sprint Backlog vorgesehen, bei Kanban zur Liste der anstehenden Aufgaben hinzugefügt und entsprechend sortiert. In einem Wasserfall-Projekt würde es in den Projektplan aufgenommen.

Feature Branch wird erstellt

Das Entwicklungsteam erstellt auf Basis des Feature Tickets einen eigenen Feature Branch im Git Repository. So ist die Arbeit an dem Feature gekapselt und es kann isoliert entwickelt und getestet werden. In JIRA ist das Erstellen eines neuen Branches bequem über einen Link im Ticket möglich. Dabei übernimmt Stash das Anlegen und Benennen des Feature Branches und das Team kann danach den Feature Branch direkt auschecken und bearbeiten. ID und Bezeichnung des Features werden direkt in den Branchnamen übernommen, so dass jederzeit klar ist, welches Feature in welchen Branch gehört.

Die Umsetzung wird durchgeführt

Das Entwicklungsteam kann nun im entsprechenden Branch das Feature umsetzen, Tests schreiben und das Feature beispielsweise auf eine interne Test-Umgebung deployen. Hierbei können einzelne oder mehrere Entwickler am Feature im Feature Branch arbeiten. So kann ein Frontend Entwickler den View für die Eingabemasken für ein Kontaktformular erstellen und ein Backend Entwickler parallel die Models und Controller für die Verarbeitung erstellen. Während der Arbeiten wird der aktuelle Stand vom CI System gebaut und ein Tool wie bspw. Sonarqube ermittelt die Qualitätsmetriken als Indikator für das Entwicklungsteam.

Ein Pull Request wird erstellt

Nach Abschluss der Arbeiten erstellt der Hauptverantwortliche für das Feature einen Pull Request. Andere Entwickler führen anhand des Pull Requests einen Code Review durch. Je nach Art des Features oder auch nach Art des Projekts kann es ausreichen, wenn ein Teil des Entwicklungsteams den Pull Request genehmigt. Bei kritischen Features sollte jedoch das gesamte Team den Pull Request prüfen. Dies unterstützt wiederum auch die gemeinsame Verantwortung innerhalb des Entwicklungsteams und die sogenannte Collective Code Ownership.

Der Code Review geschieht entweder gemeinsam in einem Meeting oder asynchron und toolgestützt, beispielsweise über Stash. Wobei sich auch bei einem Meeting Stash als zentrale Plattform eignet, damit das Ergebnis des Reviews dokumentiert werden kann.

Nach erfolgreichem Code Review wird der Feature Branch in den aktuellen Entwicklungsstand zurückgeführt. Auch dies kann komplett über die Web Oberfläche von Stash durchgeführt werden.

Der neue Entwicklungsstand wird bereitgestellt

Über Bamboo kann nun der neue Entwicklungsstand, meistens ein Branch mit dem Namen develop, development oder trunk, auf die einzelnen Umgebungen verteilt werden. Hierbei greift der Build & Delivery Server auf die Branches im Stash zu und erstellt auf deren Basis nachvollziehbare Releases. Diese können dann auf ein QA-System oder nach Freigabe durch den Kunden auch auf das Produktionssystem ausgerollt werden.

Das Feature ist fertig

Um im Nachhinein noch Zusammenhänge zu einem Feature nachvollziehen zu können, sind im Ticket nach der Fertigstellung folgende Informationen zu finden:

• Welcher Branch im Repository gehört zu diesem Feature?
• Welche Commits gehören zu dem Feature?
• Wie viele Builds gibt es zu dem Feature und wie ist der Status der Builds?
• In welchen Umgebungen wurde das Feature bereits bereitgestellt (Development, Testing, QA, Production)

Durch den Einsatz des Atlassian Stacks werden viele dieser Informationen automatisiert erfasst und dokumentiert. Aber auch andere Systeme bieten diese Automatisierung. Wenn man keins dieser Systeme einsetzt, bietet es sich trotzdem an, diese Informationen manuell im Ticket zu erfassen.

Hybridansätze

Oft ist es so, dass die eigentliche Feature Entwicklung erst auf einem Basis-System aufsetzt. So kann bspw. ein Intranet Projekt auf einem Portalsystem wie Liferay aufsetzen. Oder ein Website Relaunch wird mit TYPO3 durchgeführt. In beiden Fällen gibt es viele Standardaufgaben, die beim Einrichten des Systems durchgeführt werden müssen, die aber keine konkreten Feature-Definitionen bedeuten. Hier kann das Digital-Projekt in zwei Phasen aufgeteilt werden: Die Setup Phase und die Feature Phase.

In der Setup Phase werden die üblichen Dokumente in abgespeckter Fassung erstellt. So ist nachvollziehbar, was die Ausgangsbasis für die Umsetzung der Features ist. In der Feature Phase gelten dann die oben beschriebenen Vorgehensweisen.

Rollen im Projekt

• Entwicklungsteam: Das Team von Entwicklern, das für die Umsetzung des Projekts oder Produkts verantwortlich ist.
• Stakeholder: Wichtige Ansprechpartner des Kunden, die Anforderungen an das Projekt definieren. Dies können CEO, CTO, IT Leiter, CFO, Aktionäre, Betriebsrat uvm. sein. Hierzu zählen vor allem aber auch: die Mitarbeiter der Fachabteilungen. Vertrieb, Customer Service, Administration oder Sachbearbeitung.
• Fachabteilungen: Fachliche Ansprechpartner, die konkrete fachliche Anforderungen an das Projekt definieren.
• Projektleiter: In klassischen Projekten organisiert er das Projekt, erstellt Statusberichte und informiert die Stakeholder über den Projektfortschritt
• Scrum Master: In agilen Projekten der Ansprechpartner, der für das Entwicklungsteam Stolpersteine aus dem Weg räumt und für das Einhalten des Scrum Prozesses zuständig ist.
• Product Owner: In agilen Projekten ist er verantwortlich für die Priorisierung der Features/Stories und gibt die Richtung für das Projekt oder das Produkt vor.

Tools für die Umsetzung

• Ticketsystem: JIRA, Redmine, Trello, Mantis. Es eignet sich jedes System, in dem ein Feature gemeinsam beschrieben werden kann. Eine Integration in die anderen Systeme erleichtert das Arbeiten für das Entwicklungsteam. JIRA erlaubt bspw. das direkte erstellen eine Feature Branches in Stash aus dem Ticket heraus.
• VCS: Version Control System. Oftmals Git oder Subversion, bspw. Stash, Gitlab, Github, Bitbucket. Für die Feature getriebene Entwicklung eignet sich besonders ein Tool, das Feature Branches unterstützt und das Branchen und Mergen erleichtert.
• Build und Continuous Integration: Bamboo, Jenkins, Travis CI, Gitlab CI. Mit diesen Tools werden die Feature Branches gebaut, die Tests ausgeführt und Software Metriken erhoben. Idealerweise werden diese dann in einem Tool wie Sonarqube gesammelt.
• Delivery: Bamboo, Jenkins. Hiermit wird das Projekt oder ein bestimmter Feature Branch auf eine der Umgebungen gebracht.

Fazit

Feature getriebene Entwicklung bietet viele Chancen, ein Digital-Projekt erfolgreich zu machen. Seine größten Stärken spielt es sicher in der agilen Entwicklung aus, da viele unterstützende Prozesse bereits vorhanden sind und es mit der User Story ein Instrument gibt, das ideal geeignet für die Beschreibung eines Features ist. Aber auch Wasserfall-Projekte können stark davon profitieren, das Feature in den Mittelpunkt zu stellen.

Anforderungen werden hinterfragt. Der Fokus wird auf den Mehrwert für die Anwender und Nutzer gelegt. Fachabteilung und Entwicklung arbeiten wesentlich enger miteinander.

Hauptgrund für das Scheitern von Digital-Projekten sind oftmals unterschiedliche Vorstellungen von dem, was der Kunden wünscht und dem was der Dienstleister verstanden hat. Diese Kluft wird durch das Fokussieren auf das einzelne Feature stark verkleinert und es werden durch die gemeinsame Arbeit an der Definition des Features eine Menge Brücken gebaut, die das gesamt Projekt in eine konstruktive und offene Atmosphäre versetzen.

Man darf nicht vergessen, dass diese Art der Entwicklung nicht weniger Aufwand für Konzeption und Abstimmung bedeutet. Aber dieser Aufwand wird an der richtigen Stelle eingesetzt und maximiert damit den Output für das Projekt. Auch in Konzeptphasen vorab wird nun über konkrete Features gesprochen und nicht mehr im stillen Kämmerlein “vor sich hin konzipiert”. Das Verständnis beim Kunden ist größer und er hat in diesem Szenario viel eher die Möglichkeit, Einfluss zu nehmen und Missverständnisse zu korrigieren.

Der Beitrag Chancen einer Feature getriebenen Entwicklung erschien zuerst auf contentmanager.de.

In der Softwareentwicklung setzt sich Scrum als agile Projektmanagement-Methode zunehmend durch. Inzwischen gibt es zahlreiche Workshops, umfassende Literatur und eine große Anzahl erfahrener Scrum-Experten. Im Scrum-Kontext wurde es bisher jedoch vernachlässigt, andere Elemente und fachliche Disziplinen, die essenziell für ein starkes Produkt sind, zu integrieren – wie beispielsweise das User Experience Design. Eine gute User Experience (UX) führt dazu, dass Anwender ein Produkt bzw. eine Software gerne nutzen und ist damit ein wesentlicher Erfolgsfaktor.

%CAD2%

Dennoch treten in der Praxis das User Experience Design und der Scrum-Prozess bisher meist nur nebeneinander an und haben wenige Berührungspunkte: Das User Experience Design – vom User Research über die Definition von Personas bis hin zur Erarbeitung von Skizzen und Wireframes – wird oft im Voraus erstellt und dann für die Umsetzung dem Entwicklungsteam übergeben. Erschwerend kommt hinzu, dass meist externe, spezialisierte Agenturen – die oft nach der klassischen Wasserfall-Methode arbeiten – das User Experience Design gestalten. Das liegt zumeist daran, dass bei der Gründung insbesondere der seit längerem bestehenden IT-Unternehmen das Thema UX noch nicht so sehr im Vordergrund stand wie heute.

Mit der zunehmenden Bedeutung und Verbreitung des Internets – bis auf die Bildschirme unserer Smartphones – haben sich die Ansprüche der User an eine Software jedoch verändert: Sie legen deutlich mehr Wert auf das Design und die Nutzerführung einer Software oder einer Internet-Anwendung. Um den stetig steigenden Ansprüchen der User gerecht zu werden und nicht zuletzt, um Marktanteile zu halten oder gar auszubauen, muss das UX-Design den User nicht nur bei der Anwendung unterstützen, sondern ihm auch ein gutes Gefühl bei der Nutzung der Software vermitteln. Je weniger Software-Unternehmen also auf ein optimales User Experience Design verzichten können, umso wichtiger ist es, diese Disziplin mit dem Scrum-Prozess zu verzahnen, der von ihnen meist für die Entwicklung eingesetzt wird. Denn nur wenn das User Experience Design und die Entwicklung im Rahmen eines agilen Prozesses gemeinsam antreten, steht am Ende ein Sieg: ein erfolgreiches Produkt, das nicht nur funktioniert, sondern das die Nutzer auch gerne anwenden.

Die drei wichtigsten Aspekte für eine erfolgreiche Integration von UX-Design in den Scrum-Prozess

Erfolgsfaktor 1: Räumliche Nähe – für mehr Austausch und gegenseitiges Verständnis

Eine gelungene agile Zusammenarbeit zwischen UX-Designern und Softwareentwicklern

wird durch viele Faktoren bestimmt, der Hauptfaktor aber ist das Team selbst. Häufig ist jedoch das Verhältnis zwischen Designern und Entwicklern eher angespannt. Das liegt nicht selten daran, dass beiden Gruppen nur wenig über die Arbeitsprozesse der jeweils anderen Gruppe wissen. So ist es für Designer oft nicht leicht nachzuvollziehen, wie die Entwickler mit den von ihnen zur Verfügung gestellten Designs weiterarbeiten. Die Entwickler wiederum können sich häufig kein Bild von den Prozessen machen, die Designer durchlaufen, um ein valides Konzept zu gestalten. Für beide Seiten ist es mitunter sehr intransparent, was die jeweils andere Gruppe in ihrer täglichen Arbeit leistet.

Aufklärungsarbeit seitens der Projektleitung und der Teammitglieder selbst kann hier zunächst ein grundlegendes Verständnis schaffen. Dabei sollte erklärt werden, was die Aufgaben der einzelnen Rollen sind und inwiefern sich durch die Integration der Designer auch Prozesse in der Softwareentwicklung anpassen müssen. Es ist wichtig, dass alle Teammitglieder verstehen, dass nur durch ein gutes Zusammenspiel beider Prozesse – User Experience Design und Softwareentwicklung – ein gelungenes Produkt entstehen kann.

Um das Verständnis für die Arbeit der jeweils anderen zu verbessern, ist räumliche Nähe ein wesentlicher Aspekt: Wenn Designer und Entwickler zusammen im gleichen Raum arbeiten, bekommen sie mit, an was der jeweils andere arbeitet. Sie können sich Fragen stellen und/oder ihre Arbeitsschritte wie z. B. Designs oder Softwarearchitektur-Bilder sichtbar im Raum anbringen. Durch das offensichtliche Visualisieren der aktuellen Arbeiten können einfacher und schneller Gespräche und Diskussionen entstehen. Diese Kommunikation – die weitaus häufiger stattfindet, wenn ein Team in einem Raum sitzt – fördert den kontinuierlichen Austausch, auch im Hinblick auf die technische Realisierung von Design-Ideen. Kurze Kommunikationswege führen dazu, dass Fragen häufiger gestellt und schneller geklärt werden, und wirken sich damit positiv auf das Produktergebnis aus.

Wenn es zeitlich möglich ist – und das entsprechende Fachwissen vorliegt – können die Designer die Entwickler auch bei der Programmierung unterstützen, etwa im Bereich der Frontend-Entwicklung. Der Vorteil: Selbst entworfene Designs lassen sich auch gleich technisch umsetzen und somit auf ihre Machbarkeit prüfen. Umgekehrt können sich auch die Entwickler im Rahmen des Scrum-Prozesses an der Erstellung des User Experience Designs beteiligen, etwa indem sie Mockups oder Prototypen erstellen.

Erfolgsfaktor 2: UX-Design schon in Sprint 0 berücksichtigen – für relevante Personas und gute User Stories

Im Scrum-Prozess wird die Zeit vor dem ersten Sprint für vorbereitende Maßnahmen genutzt, wie z. B. die Aufstellung der technischen Architektur. Dieser Zeitraum wird auch als Sprint 0 bezeichnet. In diese Phase lassen sich die ersten konzeptionellen und kreativen Prozessschritte des UX-Designs gut integrieren. Ziel von Sprint 0 ist in diesem Fall, gemeinsam ein grundlegendes Verständnis für den User und eine einheitliche Produktvision zu erarbeiten

Hierfür empfiehlt sich ein Workshop, in dem alle Projektbeteiligten – Entwickler, User Experience Designer, Product Owner und idealerweise auch die Stakeholder – ein Big Picture der UX-Idee entwickeln. Ebenso sollten bereits in Sprint 0 die ersten Schritte des UX-Designs umgesetzt werden: User Research, Persona-Erstellung und das Erarbeiten von Anforderungen in Form von User Stories. Auf dieser Basis können die Beteiligten gemeinsam ein für alle verständliches Product Backlog erarbeiten. Bereits im Sprint 0 sollten Daily Scrum Meetings stattfinden, in denen sich die Teammitglieder gegenseitig über den Fortschritt und aktuellen Stand der Vorbereitungsphase informieren.

Die User Stories, die im Sprint 0 zusammen erarbeitet werden, sortiert der Product Owner am Ende des Sprints nach ihrer Priorität. Am höchsten werden die User Stories priorisiert, die das sogenannte Minimal Viable Product (MVP) abbilden – also das Produkt oder Feature, welches mit dem geringsten Aufwand den größtmöglichen Nutzen für den User bringt. Diese User Stories sollten dann in den ersten Sprints umgesetzt werden.

Um abschätzen zu können, wie viele Sprints benötigt werden, um das MVP umzusetzen, sollten die Entwickler in Sprint 0 eine Aufwandsschätzung der priorisierten User Stories vornehmen. Aufgabe der User Experience Designer in dieser Phase ist es, den Wert und Nutzen einer User Story zu beschreiben und die Entwickler an den Aufwand für die Umsetzung des Designs zu erinnern.

Für die Entwickler kann es schwierig sein, eine Aufwandsschätzung abzugeben, wenn noch kein definiertes User Experience Design vorhanden ist. Um ein gemeinsames Verständnis – und damit eine genauere Schätzung – der User Stories zu erreichen, empfiehlt es sich, während Sprint 0 einfache (Papier-)Prototypen zu erstellen. Die Ideen aller Projektbeteiligten lassen sich auf diese Weise schnell visualisieren und so besser in der Gruppe diskutieren. Die tragfähigsten Ideen können dann weiterentwickelt und idealerweise anhand von mit Prototypen noch in Sprint 0 auf ihre Benutzerfreundlichkeit getestet werden, z. B. von Kollegen. Das Feedback der Tester lässt sich dann in einer schnellen Iteration berücksichtigen.

Der parallelen Entwicklung geschuldet, wird es im Laufe des Projekts nur noch den User Experience Designern möglich sein, den kompletten Prozess immer wieder durchzuführen, d.h. kontinuierliche User Research, Anpassung – und falls erforderlich Neuerstellung – von Personas, Erstellung und Test von Prototypen etc. Die User Experience Designer sollten im Laufe des Prozesses darauf achten, ihre gewonnenen Erkenntnisse und Resultate regelmäßig mit dem restlichen Team zu teilen.

Erfolgsfaktor 3: UX-Designer an allen Scrum-Meetings beteiligen – für das „Big Picture“

Voraussetzung für eine ganzheitliche Integration der User Experience Designer in den Scrum-Prozess ist deren Teilnahme an allen Scrum-typischen Meetings. Dazu zählen Daily Scrum, Plannings, Product Backlog Refinement, Retrospektiven und Reviews.

Im Rahmen dieses „institutionalisierten“ Austauschs zwischen Entwicklern und User Experience Designern – idealerweise zusätzlich unterstützt durch räumliche Nähe – können beide Gruppen schnell herausfinden, ob sich das erstellte User Experience Design mit angemessenem Aufwand umsetzen lässt. Weiterhin haben die Entwickler so auch die Möglichkeit, ihre Ideen und Ansichten in den UX-Design-Prozess einfließen zu lassen.

Ebenfalls empfiehlt sich eine enge Zusammenarbeit zwischen UX-Designern und Product Ownern, speziell bei der Ausgestaltung von User Stories. Sie können ihre Erfahrung im Umgang mit den Nutzern und deren Bedürfnisse bei der Erstellung von User Stories einfließen lassen und User Experience Designs zu den geplanten User Stories anfertigen. Dabei sollte darauf geachtet werden, sehr detailliertes User Experience Design erst dann zu erstellen, wenn es benötigt wird – und nicht schon weit im Voraus. Das Gleiche gilt auch für die finale Ausformulierung der User Stories, da es sehr wahrscheinlich ist, dass sich initiale User Stories aufgrund neuer Erkenntnisse im Laufe des Projekts ändern. Somit ist es ratsam, die User Stories auch hinsichtlich ihrer User Experience erst ein bis zwei Sprints vor der geplanten Umsetzung zu finalisieren, um den Arbeitsaufwand zu minimieren.

Als fester Bestandteil eines Scrum Teams stehen die User Experience Designer jederzeit für Rückfragen zur Verfügung. Das trägt dazu bei, Mehrfach-Arbeit zu verhindern, etwa wenn ein Detail zum Verhalten des User Interfaces vom Entwickler anders verstanden und ohne Rückfrage implementiert wurde. Indem sie die Akzeptanzkriterien einer User Story prüfen, unterstützen die UX-Designer auch den Product Owner, der die User Stories maßgeblich mitprägt.

User-Tests sind ein weiteres Aufgabenfeld, dessen sich UX-Designer während der Entwicklung annehmen können. Hierfür empfiehlt es sich, mit ausgewählten Anwendern in regelmäßigen Abständen – etwa alle zwei Sprints – Usability-Tests durchzuführen, idealerweise zunächst mit Prototypen. So hat die Zielgruppe die Möglichkeit, neu implementierte Produktinkremente zu evaluieren. Eine frühe Rücksprache mit den Anwendern hat den Vorteil, dass etwaige Änderungswünsche der User umgehend berücksichtigt werden können. Insbesondere wenn die Anpassungen bereits an Prototypen erfolgen und nicht erst an der bereits entwickelten Software, bedeutet das enorme Zeit- und Kostenersparnisse. Anpassungen lassen sich direkt in einer darauffolgenden Iteration vornehmen, oder die Änderungswünsche werden in neuen User Stories verankert. Um den transparenten Austausch mit dem Scrum Team aufrecht zu erhalten, sollten die UX-Designer die Ergebnisse der User Tests im Daily Scrum präsentieren.

Fazit

User Experience Designer können in einem Scrum-Team umfassende Aufgaben übernehmen und wesentlich zum Erfolg des Produkts beitragen. Voraussetzung dafür ist, dass die UX-Designer als Doppelpartner der Entwickler im Scrum-Prozess mitspielen. Zum einen ist es ihre Aufgabe, nach vorne zu schauen und mittels User Research, User Tests und Prototyp-Erstellung eine auf den Anwender ausgerichtete Entwicklung des Produkts voranzutreiben. Zum anderen sollten sie immer für Nachfragen der Entwickler bezüglich aktuell bearbeiteter User Stories verfügbar sein, die bereits implementierten User Stories validieren und gegebenenfalls an der Zielgruppe testen.

Dabei sollten sich alle Beteiligten bewusst sein, dass es in der agilen Softwareentwicklung im Grunde keine endgültige Lösung gibt. Mit sich verändernden Bedürfnissen der User muss sich schließlich auch das Produkt verändern – indem es stetig angepasst und weiterentwickelt wird. Daher sind mit der Freigabe eines Softwareprodukts die Entwicklung und das User Experience Design nicht abgeschlossen. Im Prinzip beginnt in diesem Moment schon ein neues Match.

Autor: Heidi Oltersdorff, Consultant bei diva-e Digital Value Enterprise GmbH (www.diva-e.com)

Der Beitrag Ein gutes Doppel: User Experience Design und Scrum erschien zuerst auf contentmanager.de.

Ob CMS oder Suchmaschine, ob Social Software oder Collaborationstool, ob Portal oder Dokumentenmanagement: in jedem Projekt kommt der Zeitpunkt, an dem sich Unternehmen nach dem „richtigen“ System zur Umsetzung ihrer Vorhaben umsehen. Ein entscheidender Schritt, der großen Einfluss sowohl auf die Benutzerakzeptanz als auch auf die Gesamtkosten einer Lösung hat. Doch häufig leider auch ein Schritt, den Unternehmen nicht professionell angehen.

Ausgangslage für eine Systemevaluation

Übersichtlich ist er nicht gerade, der Markt für Systeme im Bereich Online-Medien und Informationsmanagement. Alleine in manchen Unterbereichen dieses Markts für „Content Technologien“ findet man teilweise weit über hundert Anbieter. Und diese Bereiche sind weder genormt, noch stabil oder klar abgegrenzt, so dass schon die Bestimmung der richtigen Systemkategorie für die eigenen Bedürfnisse zu einer Herausforderungen werden kann.

Marktübersichten von Technologieanalysten, wie die „Content Technology Vendor Map“ der Real Story Group helfen in dieser Situation einen ersten Eindruck der wichtigsten Akteure und ihrer Produkte zu bekommen:

Mehr als einen ersten Überblick sollte man sich von solchen Aufstellungen jedoch nicht erwarten, denn sie geben immer nur einen Ausschnitt aus der Marktrealität wieder. So sind in solchen Übersichten weder alle Anbieter aufgeführt (üblicherweise liegt der Fokus auf größeren Anbietern und geografisch meist auf Nordamerika), noch sind alle existierenden Systemkategorien abgedeckt. Auch die Zuordnung der einzelnen Systeme zu Kategorien (im obigen Beispiel zu „U-Bahn-Linien“) ist nicht immer eindeutig und umfassend.

Die Ausgangslage für eine Systemevaluation kann also durchaus schwierig und verwirrend sein. Insbesondere für Instrumente, die mehrere der aufgeführten Systemkategorien umfassen, wie dies beispielsweise bei Intranets, Mitarbeiterportalen oder „Digital Workplace“-Projekten der Fall ist.

Nun sind verwirrende oder von Unreife geprägte Märkte für Unternehmen jedoch meist kein Neuland, sondern etwas, mit dem sich Beschaffungsabteilungen auch in anderen Bereichen konfrontiert sehen. Der Marktzustand alleine reicht also nicht aus, um zu erklären, warum sich viele Firmen dermaßen schwer damit tun, die richtigen Systeme für ihre Online-Medien auszusuchen.

Die wichtigsten Ursachen, für Fehler bei der Systemevaluation, sind in folgenden Umständen zu sehen:

• Den meisten Unternehmen fehlt schlicht die Erfahrung mit der Evaluation derartiger Systeme. Diese weisen im Vergleich zu anderen IT-Beschaffungsvorhaben durchaus spezifische Besonderheiten aus, so dass übliche Vorgehensweisen nur bedingt erfolgsversprechend sind.
• Bei vielen Projekten in diesem Bereich handelt es sich um durchaus komplexe Vorhaben. Diese Komplexität hat Auswirkungen auf alle Ebenen: die Technologie, die Konzeption und auch die Vorgehensweise. Und die Fehleranfälligkeit eines Evaluationsprozesses steigt mit zunehmender Komplexität überproportional.

Es sind also insbesondere die Vorgehensweisen, die in Systemauswahlen zu Problemen führen. Als direkte Folge davon sind Unternehmen mit den gewählten Systemen allzu häufig nicht zufrieden und die Kosten fallen im Endeffekt höher als geplant aus.

Die folgenden sieben Punkte stellen die wichtigsten Vorgehensfehler dar, die in der Praxis häufig anzutreffen sind und die allesamt schwerwiegende Einflüsse auf die Qualität des Ergebnisses einer Systemevaluation haben. Und die man deshalb tunlichst vermeiden sollte.

Fehler Nr. 1: Unklares Vorhaben

In vielen Projekten wird zu früh mit der Systemauswahl begonnen. Und zwar meist zu einem Zeitpunkt, an dem noch überhaupt nicht klar ist, wie der Anwendungsfall des zukünftigen Systems denn konkret aussieht. Obwohl dieses Verhalten eher an „spontanes Shopping“ erinnert als an einen gesteuerten Beschaffungsprozess, ist es in Organisationen aller Größen und Branchen häufig anzutreffen.

Bevor jedoch die Frage nach dem „Warum?“ nicht ebenso geklärt ist, wie die Fragen nach dem „Was?“ und dem „Wie?“, kann die Frage nach dem „Womit?“ logischerweise nicht sinnvoll beantwortet werden. Dementsprechend muss zunächst die Frage nach der Strategie und den Zielen (also dem „Warum?“) gestellt werden. Auf dieser Grundlage können dann die geschäftlichen Anforderungen (das „Was?“) definiert werden und in Systemanforderungen übersetzt werden (das „Wie?“). Erst dann besteht eine Basis zur Beantwortung der Frage nach dem „Womit?“.
Die Reihenfolge dieses Vorgehens sollte deshalb unbedingt eingehalten werden.

Fehler Nr. 2: Äpfel mit Birnen vergleichen

Jedes Vorhaben ist unterschiedlich, jedem Vorhaben kann aber eine oder mehrere Systemkategorien zugeordnet werden, die ihm am besten entsprechen. Leider werden die zu evaluierenden Systeme jedoch häufig nicht nach einer klaren Systematik, sondern relativ willkürlich ausgewählt. Für ein neues Intranet vergleicht man dann beispielsweise gerne mal ein Wiki-System mit einem CMS, einem Portalsystem und einer Collaborationsplattform. Welches Produkt davon für die eigenen Anforderungen am Besten geeignet ist, kann dann meist gar nicht sinnvoll festgestellt werden, weil sich das Bewertungsschema im Laufe des Auswahlprozesses als ungeeignet für derart unterschiedliche Systemarten mit völlig verschiedenen Schwerpunkten erweist.Und selbst wenn ein Resultat dabei herauskommt, so bedeutet das in diesem Fall nur, dass man nun festgestellt hat, dass man zum Beispiel eher Äpfel als Birnen braucht, nicht jedoch, dass man schon die am besten geeignetste Apfelsorte gefunden hat.

Somit ist die Festlegung der passenden Systemkategorie(n) und die daran anschliessende Auswahl der zu untersuchenden Systeme ein entscheidender Schritt zu Beginn eines jeden Evaluationsprozesses.

Fehler Nr. 3: Herstellerunabhängigkeit falsch einschätzen

„Mein Dienstleister berät mich neutral!“ Während immer mehr Unternehmen die Wichtigkeit einer unabhängigen und objektiven Beratung in der Systemevaluation erkennen, herrschen meistens falsche Vorstellungen darüber, welche Voraussetzungen erfüllt sein müssen, damit ein Dienstleister überhaupt neutral beraten kann.

Und tatsächlich sind nur wenige Agenturen, Berater und Systemintegratoren in der Lage, neutral zu beraten. Das liegt gleich an mehreren Faktoren:

• Marktkenntnis: die meisten Dienstleister kennen nur einen kleinen Ausschnitt des Markets und beziehen nur die ihnen geläufigen Anbieter in das Auswahlverfahren mit ein. Somit bleiben viele unter Umständen besser geeignete Produkte von Anfang an unberücksichtigt (und man verbringt außerdem viel Zeit damit, Systeme zu evaluieren, die sowieso nicht in Frage kommen).
• Bevorzugung von Systemen, die man selber implementiert: Dienstleister, die technische Umsetzung anbieten, kennen in der Regel eine bestimmte Anzahl von Systemen sehr gut – diese werden üblicherweise einfach aufgrund dieser Kenntnis bevorzugt, egal ob sie auf das Anwendungsgebiet des Kunden passen oder nicht.
• Finanzielle Anreize: Vermittlungsprovisionen, Incentives, Kick-backs – die Bezeichnungen sind unterschiedlich, der Effekt jedoch immer derselbe. Sobald ein Dienstleister Geld von einem Systemanbieter bei Vermittlung seiner Produkte bezieht, berät er nicht mehr neutral. Als Kunden sollte man auf eine schriftliche Zusicherung bestehen, das der „neutrale“ Dienstleister von keinem Anbieter entsprechende Vergütungen erhält.

Auf dieser üblicherweise anzutreffenden Basis kann keine Empfehlung erfolgen, welches System sich für den individuellen Anwendungszweck des eigenen Unternehmens am Besten eignet. Nur neutrale Marktanalysten und wirklich unabhängige, spezialisierte Berater sind in der Lage, Empfehlungen auszusprechen, die ausschliesslich im Interesse des Anwenders liegen.

Fehler Nr. 4: Excel die Entscheidung überlassen

Wie vergleicht man dutzende, manchmal sogar hunderte von Anforderungskriterien über verschiedene Systeme hinweg? Klar: eine Excel-Tabelle muss her. Nur sollte man von dieser Tabelle nicht das endgültige Ergebnis erwarten.

Eine Systemevaluation ist keine wissenschaftliche Arbeit, an deren Ende ein mathematisch exaktes, völlig objektives Ergebnis herauskommt. Zu unterschiedlich sind die Ansätze der verschiedenen Hersteller und zu wenig klar sind häufig auch die direkten Auswirkungen der einzelnen Kriterien auf die Gesamtlösung. In der Praxis geht es somit vielmehr darum, die großen Mengen an heterorgenen und überwiegend unstrukturierten Informationen, die im Laufe eines Evaluationsprozesses anfallen, zu abstrahieren, zu konsolidieren und qualittiv auswertbar zu machen.

Dabei kann am Ende der Evaluation zwar gerne ein quantitatves Gesamtergebnis zu jedem System herauskommen, dieses sollte aber nicht als absolute Wertung betrachtet werden. Ein System, das 99% aller Kriterien erfüllt, wird zwar bestimmt besser geeignet sein, als eines, das nur 50% aufweisen kann. Bei gut gewählten Auswahlkriterien und zu untersuchenden Systemen liegen die Ergebnisse jedoch typischerweise deutlich näher zusammen. Und ob ein System mit 78% Übereinstimmung dann tatsächlich klar gegenüber einem mit „nur“ 75% zu bevorzugen ist, muss in der Praxis doch hinterfragt werden.

Fehler Nr. 5: freie Präsentationen

Sobald die Anzahl der Anbieter auf eine überschaubare Größe reduziert wurde und die grundsätzliche Einsatzeignung feststeht, sollte man Anbieterpräsentationen durchführen. Dieser Schritt ist wichtig, um ein besseres Gefühl für die Software zu bekommen und einen Abgleich zwischen dem eigenen Eindruck und den Antworten des Anbieters in den Ausschreibungsunterlagen herzustellen (und da gibt es nicht selten die eine oder andere Überraschung).

Die Effektivität solcher Produktdemonstrationen hängt jedoch entscheidend von deren Ablauf ab. Eine fest definierte, für alle Anbieter gleiche Struktur ist schon aufgrund der Vergleichbarkeit erforderlich. Die richtige Wahl und Vorbereitung der Agendapunkte ist jedoch genauso wichtig, damit auch die für den nächsten Entscheidungsschritt relevanten Dinge präsentiert werden. So sollten zum Beispiel immer genau definierte Anwendungsfälle vorgegeben werden, damit man bei allen Systemen die wichtigsten Einsatzgebiete der zukünftigen Lösung in vergleichbarer Form zu sehen bekommt.

Fehler Nr. 6: keine Probefahrt

Was bei jedem Autokauf eine Selbstverständlichkeit ist, fällt bei Softwarebeschaffungen aus Gründen des damit verbundenen Aufwands häufig unter den Tisch: die Probefahrt. Aber ohne einen „Proof of Concept“ mit den sich in der Endauswahl befindlichen Systemen durchgeführt zu haben, sollte man keine Evaluation beenden.

Das damit unter Umständen beträchtlicher Aufwand verbunden sein kann, ist zwar korrekt, im Vergleich zum Aufwand und den Kosten einer Fehlentscheidung ist dieser jedoch vernachlässigbar.

Durch einen „Proof of Concept“ wird nicht nur eine ungleich bessere Einschätzung der Systeme möglich, er gibt auch einen Vorgeschmack auf die Zusammenarbeit mit dem Systemanbieter oder Integrationsdienstleister. Und wenn diese bereits vor Vertragsabschluss nicht gut funktioniert, hat man ein weiteres, zwingendes Ausschlusskriterium vorliegen.

Fehler Nr. 7: zu spät verhandeln

„Wir haben uns für ihre Software entschieden, können Sie am Preis noch was machen?“ Dass am Ende eines Evaluationsprozesses nicht der beste Zeitpunkt für Verhandlungen ist, dürfte einleuchtend sein. Trotzdem verpassen es viele Unternehmen im Eifer des Auswahlprozesses zu den richtigen Zeitpunkten im jeweils richtigen Maße zu verhandeln.

Dabei muss man sich zunächst bewusst machen, dass Preise für Software häufig sehr willkürlich sind. Massive Unterschiede zwischen Listenpreisen und individuell angebotenen Konditionen sind eher die Regel als die Ausnahme. Dementsprechend ist es für beschaffende Unternehmen wichtig, den Verhandlungshebel möglichst an der richtigen Stelle anzusetzen. Und das ist weder zu früh im Auswahlprozess (wenn noch zu viele Anbieter im Spiel sind und der Anreiz für den einzelnen Hersteller noch relativ gering ist), noch zu spät (wenn also kaum mehr Konkurrenz besteht und die Anbieter die Preise der anderen Kandidaten relativ gut einschätzen können).

Bonus-Tipp: die Kunst des richtigen Filterns

Eine Systemauswahl ist immer eine schrittweise Verfeinerung einer Auswahl, von einer großen Anzahl von nur potentiell passenden Kandidaten, hin zu einer kleinen Anzahl von möglichst genau passenden Anbietern. In diesem Prozess ist es wichtig, in jedem Verfeinerungsschritt die richtige Anzahl an Kandidaten mit dabei zu haben. Nicht zu viele – sonst ist der Aufwand zu groß, aber auch nicht zu wenige – sonst wird die Auswahlmöglichkeit eingeschränk, was fast zwangsläufig zu letztlich unnötigen Kompromissen führt.

Die genaue Anzahl von Anbietern je Schritt lässt sich dabei nur grob bestimmen, da jedes Evaluationsszenario unterschiedlich ist und die ideale Anzahl von vielen Faktoren abhängt. Es kommt dabei stark auf die Erfahrung des Evaluationsleiters an, ob die Steuerung des „Filters“ gut funktioniert oder eher zufällig erfolgt.

Fazit: „Drum prüfe …“

In Gesprächen mit Unternehmen bekommt man häufig den Eindruck, dass die Folgen eines Systemwechsels stark unterschätzt werden. Dementsprechend wird auch der Wichtigkeit, bei einer Softwareevaluation die bestmögliche Wahl zu treffen, nicht ausreichend Bedeutung zugemessen. Man könne ja in 3 bis 4 Jahren wieder auf ein anderes System umsteigen, wenn sich das jetzt ausgewählte doch nicht als idealer Kandidat herausstellen sollte. Bis dahin haben sich die Lizenzkosten ja ammortisiert, so der Gedankengang.

In der Regel machen die Lizenzkosten einer Software jedoch nur einen kleinen Teil der Gesamtkosten eines Systems aus. Denn die direkt von einer ausgewählten Software abhängigen Kostenfaktoren sind zahlreich und weitreichend. Sie umfassen beispielsweise Anpassungen und Weiterentwicklungen, die individuell auf Basis der Software erfolgt sind, ebenso wie erstellte Schnittstellen und Integrationsmaßnahmen in die bestehende IT-Landschaft. Aber auch Konzeptionsarbeiten müssen bei einem erneuten Systemwechsel normalerweise wieder neu durchgeführt werden, so dass die Aufwände eines späteren Wechsels nicht selten, die des ursprünglichen Projekts noch deutlich übertreffen.

Vor diesem Hintergrund – den man natürlich noch um Aspekte wie die Umgewöhnung der Anwender auf ein neues System, den erneut erforderlichen Kompetenzaufbau in der IT, etc. ergänzen müsste – sollte man an Systemevaluationen besser mit der Einstellung herangehen, dass das Resultat für die sprichwörtliche Ewigkeit halten muss.

Von dieser Einstellung wird nicht nur das Evaluationsergebnis positiv beeinflusst, sondern es zeigt sich mit zunehmender Ausweitung der Online-Medien auch, dass diese Systeme mit der Zeit einen Umfang erlangen, der ein Auswechseln der jeweiligen Plattformen in der Tat kaum noch möglich macht.

Es würde wohl kein Unternehmen einen unnötigen Austausch eines Kernsystems, wie zum Beispiel eines ERP-Systems, riskieren. Der gleiche Maßstab sollte auch für derart komplexe Instrumente wie fortgeschrittene Intranets, umfassende E-Commerce-Plattformen oder einen digitalen Arbeitsplatz angelegt werden.

Doch auch wenn man sich (aus heutiger Sicht) nicht unbedingt „ewig bindet“, sollte man eine Systemevaluation doch eher als das Eingehen einer Ehe statt einer unverbindlichen Affäre ansehen. Deswegen ist auch der Prüfungsaufwand, den ein professioneller Auswahlprozess mit sich bringt, auf jeden Fall gerechtfertigt.

Der Beitrag Die 7 größten Fehler bei der Systemevaluation erschien zuerst auf contentmanager.de.