Da sitzen dann die ganzen Fachleute zusammen. Grübeln und diskutieren neue Funktionalitäten. Sowohl fachliche Aspekte als auch technische Überlegungen fließen ein. Am Ende entsteht die neue Version einer vorhandenen Software.
Wir ziehen eine Station weiter und schauen nun den Projektleitern über die Schulter. Wieviel Aufwand wird in der Neukonzeption stecken, welche Personen werden gebraucht. Natürlich auch Fragen zur Dauer, zu den Kosten.
Dann die Architekten. Sie vertiefen sich in die Einbindung in die Software-Landschaft, Datenquellen und –abnehmer spielen eine Rolle. Wie könnte die Migration vorhandener Entitäten vorgenommen werden, was passiert mit den alten Daten.
Die Entwickler schließlich, die die Vorstellungen und Anforderungen in Computersprache übersetzen. Module werden programmiert, zusammengefügt und getestet. Vom Papier auf den Bildschirm.
Alles soweit bekannt. Jetzt der neue Aspekt. Ersetzen wir doch mal in der Beschreibung das Zielsystem Computer durch das Zielsystem Mensch.
Die Projektleiter berücksichtigen, wie die neue Version der Software bei den Anwendern ankommt. Wieviel Aufwand entsteht in der Umprogrammierung der Menschen, die vor dem Bildschirm sitzen. Wie lange dauert es, bis sie sich an die neue Bedienung gewöhnt haben. Was kostet die Umstellung, neben Trainings auch die verringerte Benutzungsgeschwindigkeit.
Im Sinne der Architektur müssen die Assoziationen im Gehirn angepasst werden, der bisherige Ablauf muss geändert werden.
Als Veränderungs-Paradigma schlage ich auch hier agiles Vorgehen mit Fortschritten in Sprints vor. Wobei parallel zu den Sprints in der Computer-Software auch Sprints mit Reviews auf Seiten der Anwender vorgenommen werden.
Beim Upgrade einer App ist also nicht allein der Aufwand auf technischer Seite wichtig. Auch die Kalkulation von Schulungsaufwand geht noch nicht weit genug. Nein, es braucht einen parallel laufenden Entwicklungsstrang, der sich mit dem Upgrade der Gehirn-Software beschäftigt. Er muss geplant und analog zur Computer-Seite durch ein professionelles Projektmanagement gesteurt werden. Was Controller freuen dürfte: Man kann diesen Change mit Zahlen und Kosten unterlegen, ihn also budgetär planbar machen.
Wie bei technisch komplexen Systemen gilt aber auch hier der Grundsatz „never change a running system (unless it is absolutely necessary)“.
[Andere Blogs: Dienstliche Glossen, Feingeistiges]
Keine Kommentare:
Kommentar veröffentlichen