COM: Pausengespräche

Heute habe ich auf dem Weg zum Mittagessen einen Vorgesetzten über ein bestimmtes Problem stöhnen gehört. Auf mein Nachfragen hin meinte er, dass das jetzt zu lange dauern würde, es zu erklären, weil es sich um so ein komplexes Problem handele.
Ich blieb allerdings hartnäckig und erfuhr so eine Menge Neues. Natürlich kenne ich weder die Vorgeschichte noch die Rahmenbedingungen, den Kern des Problems habe ich jedoch sehr wohl verstanden. Und indem er mir den auseinandergesetzt hat, hat er sich selbst einen Wahnsinnsgefallen getan. Denn wie oft muss man ein Problem einem Entscheider erklären, der eigentlich keine Ahnung in dem Bereich hat. Das nennt sich dann Executive Summary. Und an mir konnte er das prima üben (auch wenn ich leider kein Executive bin :-)).
Ich kann also nur empfehlen: Bleibt dran mit euren Fragen und lasst euch nicht abwimmeln. Und im Umkehrschluss: Woimmer möglich erklärt die Dinge euren Untergebenen. Eine bessere Übung gibt es nicht und wer weiß, wozu es noch gut sein kann, seine Leute auf diese Weise "mitzunehmen".

SNA: Die kleine Welt des Gos

Go-Spieler aufgepasst! Ab sofort können Sie an meiner Go-Umfrage teilnehmen. Es geht, kurz gesprochen, darum, zu zeigen, wie klein doch die Go-Welt ist und den Fluss von Stärke zu untersuchen.

Aber auch für die SNA-community sollte die Seite einen Blick wert sein. Denn diese Webanwendung kann sehr leicht für so ziemlich jede Netzwerk-Umfrage adaptiert werden. Interessiert? Kontaktieren Sie mich und ich helfe Ihnen gern bei Ihrer Umfrage.

Sonstiges: Globalisierung

Heute musste ich einfach eine neue Kategorie Sonstiges anlegen.

Grund ist meine neue persönliche Definition von Globalisierung. Was ist Globalisierung? Wenn GMX mit einem 50€-Amazon-Gutschein für ein .comdirect-Girokonto wirbt.

SE: Software Reengineering

Eine alte Access-Anwendung, die über verschiedene Installationen mit verschiedenen Datenbeständen betrieben wird, soll derzeit durch eine moderne Web-Anwendung abgelöst werden. Auslöser des Bestrebens war die spontane Erkenntnis, dass der offizielle Support von Microsoft für die verwendete VB- und Access-Version demnächst wegfällt. Außerdem ist der Datenbestand explodiert und dadurch der Datenaustausch via E-Mail unpraktikabel geworden.

Folgende Erkenntnisse habe ich für mich aus der Mammut-Besprechung zur Aufstellung des Forderungskatalogs an das neue System gezogen:

• Nie die Forderungsliste für die alte Anwendung als Basis für die Forderungen an die neue Anwendung benutzen! Denn diese Vorgehensweise wird immer dazu führen, dass aus Angst
  überflüssige Forderungen hängen bleiben.


• Klar machen, dass es nicht darum geht (gehen kann), die alte Anwendung ins Web zu portieren. Stattdessen geht es um eine Bereinigung und Modernisierung. Im Web werden nicht die Vorteile einer Stand-Alone Anwendung zu erreichen sein, dafür aber andere Vorteile, die mit einer Stand-Alone Anwendung unerreichbar wären, zum Beispiel Zugriff aus dem gesamten Intranet, zentrale Datenhaltung, keine aufwändigen Software-Updates für jede Installation, weniger Administratoren usw.


• Klare Priorisierung der Forderungen. Unterteilung in a) "brauchen wir zwingend zum Betrieb des Systems", b) "brauchen wir, ginge aber zur Not und übergangsweise auch ohne" und c) "nice to have". Ich bin gegen eine Kategorie d) "kann wegfallen", weil das den Forderungscharakter des Dokuments nicht zum Ausdruck bringt und unnötig verwirrt (außerdem schürt das noch zusätzlich Ängste bei den Nutzern).


• Fordernde müssen die Verantwortung übernehmen, dass mit dem System gearbeitet werden kann, wenn die wichtigsten Anforderungen umgesetzt sind. Das führt zu einer Neigung, die Dinge im Zweifel zu hoch zu priorisieren. Besser ist es, den Projektleiter schätzen zu lassen, welche Forderung wie viel kostet und eine Obergrenze für die Kosten zu definieren. Die Fordernden dürfen also "entscheiden", für welche Funktionen das Geld ausgegeben wird (und es kann nur einmal ausgegeben werden). Kommen die Fordernden zu dem Schluss, dass die Neu-Entwicklung mit dem bestehenden Budget nicht zu realisieren ist, muss neu überlegt werden. Steht nicht mehr Geld zur Verfügung, kann man es dann auch gleich ganz sein lassen.



• Daten, wie oft in der Vergangenheit welche Funktion benutzt worden ist, sind unglaublich wertvoll. Vielleicht sollte man diese Auswertung in neue Systeme von Anfang an einbauen. Der Abschied von einer Funktion wird um einiges leichter, wenn man aus einer Tabelle ablesen kann, dass dieser Button in den letzten drei Jahren genau 5 mal gedrückt worden ist.

Davon unbenommen gilt für das Reenineering natürlich weiterhin mein Beitrag über Altlasten.