"Bedienfreundliche Oberfläche" - aber für wen?

Bedienfreundliche Oberflächen wollen alle. Allerdings heißt das für jeden etwas anderes. Beispiele:

- Der gelegentliche oder erstmalige Besucher einer Website (Inter- oder Intranet) will sich schnell orientieren und finden, was er sucht. Bzw. ersteinmal herausfinden, wie das heißt, was er sucht.

- Der häufige Anwender, der fallabhängig unterschiedliche, komplexere Arbeitsflüsse im System abwickelt, braucht gut gestaltete Menüs und Dialoge.

- Wer häufig viele Daten erfasst, braucht eine sehr schnelle Reaktionszeit und kurze Fingerwege. Die Vorgabe für "schnell" gibt die Großrechneranbindung: "quasi ohne Verzögerung". Kurze Fingerwege heißt: schon der regelmäßige Griff zur Maus und die Mausfahrt zu einem Menüpunkt wäre zu zeitraubend. Tastenkombinationen müssen her.

- Anwender, die viel unterwegs sind, benutzen Laptops oder Tablets. Sie erfassen nur wenige Daten (höchstens Mitschriften) und brauchen vielleicht gut verständliche Berichtskonfigurationsmöglichkeiten. Sie brauchen gute Menüstrukturen, angepasstes Layout etc.

Wer diese Unterschiede übersieht und die Oberflächengestaltung nur für die Teilnehmer eines Lenkungskreises "stylt" wird später keine Akzeptanz bei den Anwendern finden (und im Lenkungskreis ein "Akzeptanzmanagement" vorschlagen...).

Was bedeutet das für die Technologieauswahl bzw. Architektur?

Auch hier kann man sich vertun. Wer als Datenerfasser schlechte Erfahrung mit langsamen Intranetseiten hat, wird sagen: Keine Weboberflächen!
Ein erfahrener Architekt wird erwidern: Gegenvorschlag - wir minimieren die Nachladeobjekte für Dialoge und bestellen ausreichend Netzbandbreite beim technischen Architekten bzw. bei Corporate Network.

Auch wenn das Konzept auf dem Papier überzeugt, man sollte testen, ob man vor Ort das bekommt, was man braucht und ob alles wie gedacht funktioniert.

Brauchen Methodiker Branchenwissen?

Große Diskussion: Muss ein Methodikberater etwas von der Branche verstehen, für die er seine Methodik nutzbar machen will?

Manche sagen: Nein. Was man nicht weiß, kann man sich herleiten. Und: der Kunde muss das Potenzial erkennen, wenn er die Methodik studiert.

Ich sage: Ja. Methoden müssen -ebenso -wie Technologien- erst nutzbar gemacht werden. Sie sind es nicht a-priori.

Begründung:
Das Nutzenpotenzial hat in jeder Branche, vielleicht bei jedem Kunden, ein anderes Profil. Man bringt -abstrakt gesprochen- das Nutzenprofil der Methodik mit dem Schwächenprofil der Kundenorganisation zusammen.

Beispiel Anforderungsmanagement:
Organisationen, die einfach drauflos entwickeln (a), können von der Einführung eines Anforderungsmanagement anders profitieren, als Organisationen, die zu lange an ihrem Lastenheft arbeiten (b).
(a) braucht ein Verständnis, warum Anforderungen überhaupt dokumentiert werden können: Damit man sie besprechen, priorisieren, klären - ja überhaupt Dritten zugänglich machen kann.
(b) braucht ein Verständnis dafür, dass es sinnvoller ist, unklare Anforderungen und stillschweigende Annahmen VOR dem Entwicklungsstart zu klären.

Inwiefern benötige ich hier Branchenwissen, um die Methodik nutzbar machen zu können?

Antwort:
Ich muss eintauchen in die Welt des Kunden und das spezifische Problem, an dem man den Hebel ansetzen kann, verstehen lernen. Dieses Problem kann typisch für die Branche sein, oder eine Gattung von Unternehmen in dieser Branche.

Dem Methodiker geht es da nicht anders als dem Technologen: Gibt es neue Durchbrüche in Basistechnologien, braucht man auch Branchenverständnis um die Chancen für eine Branche zu erkennen.

Bekanntes Beispiel: Die Mini-Festplatte von Intel, die für Apple das fehlende Puzzlestück für die Entwicklung des ersten iPod war. Intel wusste nicht, was Apple braucht. Und Apple wusste nicht, was die Forschungsergebnisse von Intel bedeuten. Das Potenzial wurde erst im gemeinsamen Gespräch erkannt.

Man muss also Anforderungsmanager und Architekten miteinander ins Gespräch bringen. Der Anforderungsmanager befragt den Architekten gezielt nach dem MÖGLICHEN. Der Architekt befragt den Anforderungsmanager nach dem BEDARF. Beide müssen zur Sprache bringen, was sie durch falsche Annahmen zu verschweigen neigen.

Und für dieses Gespräch brauchen beide Seiten Verständnis für die jeweils andere Seite. Sie repräsentieren aber eine der beiden Domänen.

IT-"Modernisierung"

"Mach neu!"
Peter Fox

Auslöser für die Modernisierung einer IT-Landschaft kenne ich nur zwei:
- Die Systembetreuer gehen bald in Rente oder Pension.
- Jemand hat nachdem etwas passiert war, angeordnet, dass jetzt "etwas passieren" muss.

Gründe für eine Modernisierung kann es noch viel mehr geben, aber die lösen nichts aus.

"Landschaft" heißt, da müssen mehrere zusammenspielende Komponenten angefasst werden. Und sofort entstehen Fragen wie:
- Ist die Anzahl der Komponenten fachlich oder technisch begründet?
- Allgemeiner gefasst: Wie begründet sich die heutige Architektur?

Solch ein Vorhaben ist ein Aufbruch ins Ungewisse, machen wir uns nichts vor. Was aber gewiss ist: Für alle demnächst startenden Aktivitäten und vor allem Dokumentationen sollte sich das Programm eine Basis in Form von Standards geben:
- Klärung der Vorgehensweise, Standards, Tools, Ablage etc.
-- Dies ist um so dringender, je arbeitsteiliger das Projekt organisiert wird.
--- Insbesondere zwischen extern und intern.
--- Insbesondere wenn agil entwickelt wird (gemeinsame Anforderungsklärungssitzungen)
- Zentrale Stellen für zentrale Fragen die immer wieder hoch kommen werden:
-- Anforderungsmanagement
-- Architekturmanagement

Sollte jemand auf die Idee kommen, diese zentrale Stelle bräuchtet Ihr nicht und Ihr könntet auch ohne dies "schon mal" starten, werdet Ihr schnell merken, wo Ihr da hinkommt:

- Jede Stelle benutzt ihre Tools und Standards.
- Jedes Teilptojekt nutzt Vorgehensweisen, die es kennt oder ihm am besten passen.
- Am Ende wird nichts zusammen passen und kann nicht übergreifend analysiert und gestaltet werden.

Das klingt trivial und muss man niemandem mehr sagen? Habt Ihr eine Ahnung..