The Spoken Word

Ich möchte die Überlegungen und Vorschläge direkt plakativ beginnen, denn schließlich liegt ein weiter Weg vor uns: reich werden! Ich finde, große Ziele sind gute gute Ziele, denn sie spornen jeden zu etwas an. Zudem ist das Ziel erreichbar! Die Menge an Geld, bis man reich ist, mag verschieden sein und ist von Mensch zu Mensch verschieden, aber das ist unerheblich - der Weg ist das Ziel!

Wie fange ich an?
Der Anfang ist meistens das schwerste, also fange ich mal klein an. Um reich zu werden, muss man wissen, was man bisher an Geld zu Verfügung hat, woher es kommt und wohin es geht. Anhand dessen kann man schonmal viele Fragen beantworten:

• Was habe ich für Einnahmequellen?
• Wieviel Geld habe ich monatlich zur Verfügung?
• Wofür gebe ich Geld jeden Monat aus?
• Wieviel Geld gebe ich jeden Monat in einzelnen Bereichen aus?
• Was habe ich monatlich zur freien Verfügung ?

Damit gewinnt man bereits ein Stück Reichtum - Erkenntnis. Der Spruch “Wissen ist Macht” kommt nicht von ungefähr. Sobald man weiß, wie es um die eigene finanzielle Lage bestellt ist, kann man deutlich entspannter den Tag beginnen, denn

• man weiß entweder, dass man keine finanziellen Probleme hat, oder
• man weiß genau, wo die finanziellen Probleme liegen und wie hoch diese sind

Das man, an und für sich , noch keine große Erkenntnis sein, aber es ist eine immense psychische Hilfe, denn entweder man fühlt sich gut, weil es einem gut geht, oder man fühlt sich nicht mehr so schlecht, weil man genau weiß, wie die Lage aussieht, ohne etwas zu “vermuten” oder zu “glauben”.

Also: der Anfang!
Ich gehe von folgender Situation aus:

• ein Girokonto oder ein Sparkonto ist vorhanden
• es gibt Kontoauszüge

Wenn dem nicht so ist, wird es etwas schwieriger, dem möchte ich mich ein andermal widmen (falls jemand besonderes Interesse hat, bitte melden, dann ziehe ich den Artikel vor!).
Zu Anfang besorgen wir usn ein paar Kontoauszüge, die am besten einen Zeitraum von 2-3 Monaten abdecken. Wenn es weniger gibt, ist das auch okay, aber mehr ist besser, um Schwankungen und Trends zu erkennen.

Hat man alle Informationen beisammen, brauchen wir eine Möglichkeit, die Zahlen und Buchungen aufzutragen und auszuwerten. Da ich reich werden möchte und deshalb kein Geld ausgeben will, verwende ich eine Tabellenkalkulation. Empfehlen kann ich OpenOffice.org, wennn man etwas haben möchte, dass als normale Anwendung läuft. Ist man etwas moderner eingestellt, oder findet “Web 2.0″ irgendwie cool, kann sich auch gerne mal die Google Spreadsheet anschauen. Für letzteres braucht es einen Google Account und die Tabellen und Dokumente bleiben bei Google gespeichert, dafür kann man von überall darauf zugreifen. Die Entscheidung überlasse ich euch, ich will reich werden

Fazit: Wie haben Kontoauszüge, anhand derer wir sehen können, wieviel Geld reinkommt und wieviel Geld rausgeht und wir haben eine Tabellenkalkulation, um mit Zahlen zu spielen - weiter geht’s!

Alles ist Kategorie!
Als nächstes beginnt der eher lästige Teil, aber keine Panik: Sowas machen wir nicht jeden Tag, schließlich haben wir besseres zu tun. Wir fangen an einem Monatsanfang an und schauen uns jede Buchung an. Eine Buchung ist entweder negativ, Geld fließt ab, oder positiv, Geld wächst an. Für jede Buchung tragen wir nun den Betrag in eine Spalte und eine Kategorie in die Spalte daneben.
Dabei sollte man nicht zu spendabel mit Kategorien sein, weniger ist mehr. Es ist nicht notwendig, alles bis ins letzte Detail zu erfassen (wie “Obst”, “Gemüse”, “HiFi”, “Computer”), sondern eher Oberbegriffe zu finden (wie “Lebenshaltung”, “Lifestyle”, “Miete”).

Warum machen wir das?
Wir wollen erfahren, woher wir Geld bekommen und wohin Geld fließt! Haben wir gleichartige Buchungen (”Obst” und “Gemüse”), werden beide der gleichen Kategorie “Lebenshaltung” oder “Nahrungsmittel” zugeordnet. Damit bekommen wir schnell eine Ãœbersicht, wieviel Geld insgesamt pro Monat für diese Kategorie verwendet wird.

Typischerweise werden die meisten Posten negativ sein und die wenigsten positiv. Das ist normal, sonst müssten wir uns das reich werden keine Gedanken machen

Was sind typische Kategorien:

• Nahrungsmittel
• Kleidung
• Miete
• Nebenkosten
• Rückstellungen a.k.a “Sparen”
• Versicherung
• Steuern
• Kapitalerträge oder Zinsen
• Telefon/Internet
• etc.

Bei den Kategorien muss jeder selber schauen, welcher Art die Ausgaben sind, das hier können nur Beispiele sein.

Die Analyse!
Nachdem die Daten eingetragen sind, fängt es an interessant zu werden: Die Daten in Informationen umwandeln. Wenn wir zurückblicken, haben wir eine Spalte mit Kategorien und eine Spalte mit Beträgen. Eventuell gibt es noch eine Spalte mit Beschreibungen zu den einzelnen Posten, das ist zwar hilfreich aber nicht zwingend. Nun kann man die Macht der Tabellenkalkulation ausnutzen und Zahlen gruppieren und sammeln. Macht man es einfach, schreibt man jetzt die gefundenen Kategorien nochmal in Spalten daneben, sodass die Kategorien nun in den Zeilen und in den Spalten stehen (und damit quasi ein Koordinationsystem mit zwei Achsen markieren).

Nun verwenden wir die Möglichkeit einer Tabellenkalkulation, Felder automatisch zu füllen, wenn bestimmte Bedingungen erfüllt sind. Wie das ganue funktioniert, bitte in der jeweiligen Hilfe nachforschen (Stichworte: Formel, IF, WHEN, WENN, Formula). Wir möchten nun folgendes erreichen: Wenn der Kategorienname in der Zeile mit dem jeweiligen Kategorienname in der Spalte übereinstimmt, dann soll in der jeweiligen Zelle der Betrag auftauchen.

Damit verteilen wir eine Liste von Buchungen auf Spalten und machen das ordnen einfacher.

Nun kann man über die Summierungsfunktion (SUM, SUMME) relativ leicht alle Spalten mit Kategoriennamen summieren - et voila: Soviel Geld landet in den einzelnen Kategorien!

Ist das gut? Ja! Den nun addieren wir die Summen der Kategorien und erhoffen:

• Summe = 0 für ein neutrales Ergebnis. Wir geben genau so viel Geld aus, wie wir bekommen. Damit werden wir nicht reich, ruinieren uns aber kurzfristig auch nicht - ein Anfang
• Summe > 0 für ein positives Ergebnis. Wir behalten mehr Geld übrig, als wir ausgeben. Damit werden wir reich, aber es kann eine halbe Ewigkeit dauern. Nichts desto trotz: ein guter Anfang!
• Summe < 0 für ein negatives Ergebnis. Wir geben mehr Geld aus, als wir eigentlich bekommen. Das ist ein Problem - an dieser Stelle muss schnellstens analysiert werden, in welchen Kategorien das meiste an Geld abfließt!

Wenn ihr dazu Fragen habt, bitte schreibt einen Kommentar oder eine eMail. Ansosnten überlebt euch mal, wie es von hier aus weiter geht, bis ich mit den nächsten Post an dieser Stelle weitermache …

Scott Young stellt in seinem Weblog eine Strategie vor, mit der er mehr Dinge in weniger Zeit schafft.

Dabei verfolgt er mit drei verschiedenen Ansätzen das gleiche Ziel: höhere Produktivität sicherzustellen. Wie kann das erreicht werden?

Nach seinen Ausführungen, geht das wie folgt:

• Die Zeit, die eine Tätigkeit benötigt, minimieren
• Tätigkeiten aus dem Tagesprogramm entfernen, die von anderen besser erledigt werden können oder einfach nicht wichtig sind
• Neue Tätigkeiten aufnehmen, sodass andere hinten runterfallen (müssen)

Die Idee ist eigentlich ziemlich interessant, wenngleich sich die meisten vermutlich etwas schwer mit der Umsetzung tun werden. Aber vorher möchte ich die Ideen nochmal kurz durchsprechen:

Durchführungszeit minimieren

Wie kann man die Zeit reduzieren, die für eine Tätigkeit benötigt wird? Das kann auf verschiedene Weise erfolgen. Man kann

• den Umfang der Tätigkeit reduzieren - muss man jemanden erst anrufen und im Nachhinein den Inhalt nochmal per eMail bestätigen oder reicht die eMail nicht einfach aus? Muss eine Präsentation tatsächlich noch überarbeitet werden, um “fancy” zu sein oder geht es nicht vielmehr um den Redner und dessen Inhalt?
• die Arbeit schneller erledigen - kenne ich die Shortcuts der Anwendung? Kann ich Arbeitsschritte automatisieren (z.B. mit AutoHotKey)? Kann ich Vorlagen nutzen?

Das ganze ist eine Umstellung in der Denkweise, indem ich nicht einfach meine Arbeit mache, sondern aktiv versuche, die Arbeit bei gleicher Qualität schneller zu erledigen. Zu einigen Möglichkeiten werde ich noch separat etwas schreiben, bzw. eine Linkliste erstellen.

Ansonsten kann man auch einfach Überlegen, ob nicht externe Faktoren einen in der Arbeit beschränken? So kann beispielsweise ein zweiter Monitor sehr viel mehr bewirken, da man einfach mehr auf dem Bildschirm sieht, als jede Automation. Auch ein größerer Monitor kann helfen, wenn man viel “scannen” muss, da die Zeit für das Scrolling wegfällt. Und zu guter letzt gehört schnellere Hardware mit in den Plan. Wenn man untätig auf das Starten von Programmen warten muss und in der Zeit nichts anderes machen kann, könnte mehr Speicher oder ein anderer Arbeitsplatz ebenfalls die Produktivität steigern. Und die Kosten, die das dem Arbeitgeber verursachen sind evtl. gar nicht von Relevanz, da die PC Mietkosten sowieso anfallen oder das Gerät bereits abgeschrieben ist.

Überflüssige Tätigkeiten entfernen

Wer träumt nicht in der Gegend rum oder liest Nachrichten? Sicherlich einige! Aber wißt ihr auch, wieviel Zeit dafür drauf geht? Gerade das Tagträumen kann unglaublich viel Zeit kosten. Ich plädiere nicht dafür, Tagträume komplett zu streichen, allerdings sollte man die Zeit bewußt einplanen, um nachher kein schlechtes Gewissen zu bekommen.

Neue Tätigkeiten einfach mitmachen

Wie soll das gehen, werdet ihr fragen? Ganz einfach - entweder, die Tätigkeiten können noch miterledigt werden oder eben nicht. Können sie mitgemacht werden, habt ihr die Produktivität gesteigert! Geht es nicht, müsst ihr gucken, welche Tätigkeiten weniger wichtig sind. Diese müssen dann entweder fallen gelassen werden, oder jemand anders erledigt sie.

Das Ziel der ganzen Übung ist, diejenigen Tätigkeiten zu finden, die nur ihr erledigen könnt bzw. für die ihr am besten geeignet seid. Nur mit solchen Tätigkeiten könnt ihr euer Profil schärfen und eure Produktivität maximieren - und maximale Produktivität bedeutet nicht, nur noch zu arbeiten, sondern die Zeit bestmöglich zu nutzen! Entweder zum Wohle einer Firma oder um euch selbst willen!

Fazit

Es ist nicht einfach, seine Produktivität zu steigern, aber es gibt ein paar Möglichkeiten. Schlussendlich läuft alles auf Verdrängung heraus: unwichtiges wird verdrängt, überflüssiges fällt hinten runter oder wird von anderen erledigt.

Das Ziel ist immer, diejenigen Aufgaben zu finden, die man am besten erledigen kann und sich auf diese zu fokussieren. Damit ereicht man einen maximalen ROI (=Retun On Investment). Und investierte Zeit sollte sich auch auszahlen - auf die eine oder andere Art und Weise

Eigentlich hätte ich den Beitrag mit einer anderen Ãœberschrift versehen soll .. z.B. “Dienstleistung - Balanceakt zwischen den Welten”, das wäre aber etwas zu theatralisch und würde ganz sicher meinem Stil nicht entsprechen.
Also versuche ich es etwas bodenständiger.

Als Dienstleister im Software-Umfeld etntwickelt man einerseits Lösungen für Kundenprobleme, andererseits kommt man aber auch um Fragen der Wartung und der Fehlerbehandlung nicht herum. Unter Wartung kann man dabei Weiterentwicklungen verstehen, aber auch Vorgespräche dazu. Unter Fehlerbehandlung verstehe ich in diesem Falle aber nicht die techn. Fehlerbehandlung, sondern eher Anfragen, die sich auf Fehler beziehen, die durch den Betrieb nicht gelöst werden können.

Typischerweise liegt es nahe, diese Fehler an die Entwickler weiterzureichen, da diese die Komponenten entwickelt haben und für die Fehlerbehebung am Besten durchführen können.
Ist man in einem überschaubaren Projekt, oder handelt es sich um Anfragen, die zu dem jeweiligen Projekt gehören, ist dies in Ordnung bzw. verständlich.
In einem Umfeld, in dem man aber mehrere verschiedene Projekte abhandelt, ist dies auf Dauer nicht tragfähig, da die anstehenden Projekte um die Zeit der Fehlerbehebung verlängert werden, oder über Mehrarbeit abgehandelt werden, was nicht wünschenswert ist.

Wie kann dies nun praktikabel gelöst werden? Verwendet man für die Problemlösung einen SixSigma Ansatz, also einen analytisch geprägten Ansatz, so benötigt man eine Ausgangssituation. In diesem Falle kann man sagen, dass das Support-Team keinerlei Anfragen bearbeitet und das Entwickler-Team alle Anfragen beantwortet. Nun ist die Aufgabe, dieses Verhältnis zu verschieben. Für einen guten Schnitt soll dieses Verhältnis auf 50/50 angehoben werden.

Was ist das grundsätzliche Problem für ein Support-Team? - Es kommen über die Zeit Anfragen der verschiedensten Art, die bearbeitet werden sollen. Diese können sich entweder auf die implementierte Lösung direkt oder das Umfeld dieser Lösung beziehen, um das Problem erstmal zu vereinfachen. Später kann es verkompliziert werden, indem auch Anfragen eher fachlicher Natur bearbeitet werden sollen.

Nachdem die Aufgabe der Definition abgeschlossen ist und damit auch der finanzielle bzw. zeitliche Impact klar ist - die unzweifelhafte Zeitersparnis für die Entwickler und die höhere Produktivität des Support-Teams - geht es daran die Informationen zu sammeln, auf Basis deren weiter Entscheidungen und konkrete Handlungsmassnahmen abgeleitet werden können.

Nun kommt die Aufgabe der Messung. In dieser müssen Daten erhoben werden, die zielführend sind und valide Aussagen darüber zulassen, welcher Art die Anfragen sind. Dazu kann ein evtl. bereits bestehendes Trouble-Ticket-System verwendet werden. Dazu ist eine Kategorisierung der Tickets notwendig. Diese sollte mehrfach vorgenommen werden, um die unterschiedlichen Dimensionen des Fehlers zu erfassen. Sinnvolle Dimensionen sind:

• Art des Fehlers - Datenfehler, techn. Fehler, Bedienungsfehler, Mappingfehler, Programmierfehler
• Tiefe des Fehlers - simpel, einfach, mittel, schwer
• Umfang des Fehlers - Komponente, Datenstrecke, Randsysteme, Benutzer
• betroffene Systeme - EAI, Randsysteme, Datenbanken

Typischerweise erhält man an dieser Stelle den Einwand, dass die ganze Datenerhebung keine Sinn macht und sowieso überflüssig ist. Man könnte meinen, dass dem so ist, stimmt aber nicht. Das Problem ist, dass man, methodisch betrachtet, etwas erreichen möchte, ohne Aufwände in Blindleistung zu investieren. Aus diesem Grunde sollte im ersten Schritt Daten erhoben werden, die Aussagen darüber zulassen, wieviel Anfragen überhaupt kommen und wie diese eingestuft werden können. Anschließend kann man für die Kategorien mit dem höchsten Aufkommen überlegen, wie diese behandelt werden können.

Und da ich jetzt keine Lust mehr habe, weiter zu schreiben, kommt morgen oder so der Rest zum Thema Analysieren und Verbessern.

Kommentare zum Bereich Definieren und Messen sind herzlich willkommen, gerade auch um andere Sichtweisen einzuarbeiten…

On his blog entry, Bill Miller states some of his thoughts of what an ESB is. This is something pretty interesting, as there seems to be a good amount of buzz around what something really is!

I’m working with Apache ServiceMix, an ESB product, implementing the JBI standard - Wow, what a lot of buzz around it! To my understanding, an Enterprise Service Bus is nothing concrete and it is neither something to be concrete ever.

Instead of being something a product can be, it’s more of a metaphor and a list of attributes a product may or may not deliver. The idea of an Enterprise Service Bus is to be a pattern, which can be implemented even without using a product delivering it.

What it’s all about is getting a clue of how separate building blocks can work together and how one get’s data and information from one point to another.

In designing enterprise applications, it’s important to focus on the logic of the application, on the side effects (locking, multi-user issues, etc.) and the overall picture. If one has many applications, offering certain distinct pieces of functionality, you need a standard’s based methodology to pass data around and get all things connected. This is the foundation of an enterprise service bus - a possibility to connect in a standardized way.

Getting back to software development, it’s nothing but “contract based development” and “object oriented programming” one step further. The contract is the message format, the contract is the interface. On top of which platform such things are implemented, if irrelevant. Products implementing the ESB idea typically deliver a runtime environment, tooling and convenience functionality (such as a messaging system, transactionality, etc.). This is pretty necessary and very very good - but the foundation is just an idea.

I hope, this idea got a bit clearer (considering the shortness of this post). I’d be glad to get any comments on this or your thinkings on it!

Zusammenfassung: Jeder hat Methoden, die täglichen Aufgaben zu bewältigen - sei es eMails, Telefonanrufe, Bankgeschäfte. Was wir meistens nicht tun, ist diese Prozesse und Verfahren in regelmässigen Abständen zu betrachten und zu überlegen, wie diese vereinfacht werden können. Die meisten Prozesse sind verkünstelt, vieles lässt sich vereinfachen - mit dem Ziel, höhere Produktivität und mehr Spass dabei zu haben.

Wie sieht das übliche Vorgehen aus? - wir werden mit Anforderungen konfrontiert und wollen diesen gerecht werden. Das können so unterschiedliche Dinge sein, wie

• eMails zeitnah beantworten
• Anfragen “sofort” bearbeiten
• Projekte pünktlich und in hoher Qualität fertig stellen
• Bankgeschäfte pünktlich erledigen
• etc.

Das Problem dabei ist, dass wir uns Prozesse überlegen, wie wir überhaupt mit den Problemen umgehen können. Aber denken wir auch daran, wie wir diese vereinfachen - streamlinen - können? Die wenigsten tun dies vermutlich und dieses Potenzial liegt dann brach.

Was können wir tun? - Einfach überlegen, wie wir bisher arbeiten und was uns daran stört!

• Füllen wir Ãœberweisungen per Hand aus oder verwenden wir Online-Formulare oder benutzen gar Einzugsermächtigungen
• Verwenden wir Werkzeuge (offline wie online :)) effizient, oder hakt es in der Verwendung
• Liefern wir die Qualität, die wir uns selber wünschen würden, oder warum schaffen wir es nicht?

All diese Fragen führen uns weg von dem Vorgehen, wie wir es gewöhnt sind, wie wir es uns erarbeitet haben und zeigen mit erhobenem Zeigefinger auf Stellen, die vielleicht nicht rund laufen und deshalb verbessert werden könnten. Aber da Veränderung und Verbesserung nichts schlechtes ist, können wir uns darüber freuen. Haben wir Problempunkte gefunden, können wir diese aktiv angehen - ohne deren Kenntnis ist das erheblich schwieriger.

Wie finden wir Verbesserungen? - Ein schwieriger, aber eigentlich auch spannender Punkt! Um Prozesse zu verbessern kann man mehrere Möglichkeiten ausprobieren. Die Entscheidung, welche Variante einem persönlich am Besten gefällt, am Besten liegt, muss jeder selber treffen:

• MindMapping/Brainstorming - das Problem wird in die Mitte gestellt und darum herum schreibt man Ideen auf, ohne sie zu bewerten. Hat man keine Ideen mehr, sortiert man durch die gefundenen und überlegt sich, was praktikabel umsetzbar ist
• Analogien - das Problem wird abstrahiert und man sucht Lösungen aus anderen Bereichen. Warum das Rad neu erfinden, wenn es bereits Lösungen gibt? Diese sind vielleicht nicht optimal, funktionieren aber und müssen vielleicht nur geringfügig angepasst werden!
• Gespräche - glücklicherweise haben wir Freunde, Bekannte, Kollegen! Vielfach hilft ein kurzes Gespräch, eine Lösung zu finden, die einem selber alleine nicht eingefallen wäre
• Fragen - Eine mächtige Waffe! Wenn man einen Prozess hinterfragt - Warum muss etwas so geschehen, Wieso kann es nicht anders laufen, Muss dieser Schritt gemacht werden, Kann jenes nicht später erledigt werden - prüft man seine Notwendigkeit auf eine ungeahnt fruchtbare Art und Weise. Man lernt mehr über den Sinn und Zweck und findet oftmals ein Hintertürchen, um doch Veränderungen einzuführen

Hat man etwas gefunden, was einem vermutlichen helfen wird, kommt es nur noch darauf an, sich bewußt dafür zu entscheiden, diese Lösung anzunehmen und umzusetzen. Durch die eigene, bewußte Entscheidung wird es erheblich einfacher, das auch stringend zu halten.

Also: Viel Spass beim Vereinfachen von Allem Komplizierten!

Bitte schreibt auch Eure Meinung zu dem Thema, ich habe vermutlich noch hunderte gute Ideen nicht aufgeführt!

So und weiter geht’s im Text um eine sinnvolle und für die Wartung brauchbare Dokumentation. Diesmal wechsle ich den Themenbereich und wende mich direkt den Quelltexten zu, denn aus denen sind die meisten Anwendungen dieser Tage aufgebaut.

Wenn Fehler auftreten, äußert sich das im Falle von Java zumeist durch einen Stack Trace. Dieser gibt an, in welcher Java Klasse der Fehler aufgetreten ist und wie der Aufrufgraph dahin aussieht. Darüber lässt sich nachvollziehen, über welche anderen Java-Klassen hinweg zu dieser, möglicherweise fehlerhaften, Stelle im Code gelangt worden ist.

Was passiert nun, wenn an diesen Stellen keine Fehlerbehandlung durchgeführt wird? Richtig - es werden Java Exceptions geworfen, die genau das aussagen, was gerade passiert. Übliche Beispiele wären NullPointerException, ArrayIndexOutOfBoundsException oder auch RemoteException - sehr beliebt übrigens auch aufgrund ihrer hohen Aussagekraft in einem Applikationskontext

Was braucht nun der Support? Der Support oder auch die Wartungsmannschaft möchte möglichst schnell die Stelle in den Protokolldateien finden, die den Fehler erwähnt und anschließend möglichst schnell erkennen können, was der Fehler genau ist. Im Sinne einer möglichst niedrigen Ausfallzeit ist das auch Sinn der Ãœbung. Nun hilft aber eine Darstellung der Form “RemoteException in Klasse Blah, Zeile Blub” herzlich wenig.

Darum plädiere ich ganz massiv, wie dies eigentlich auch getan werden sollte, für sprechende Exceptions, die zumindest auf einen Cluster von Fehlern hinweisen.

Ein Beispiel wären ein paar Projekte aus meinem Umfeld. Diese verwenden eine andere Komponente zur Auflösung von Qualitätsgruppen. Tritt beim Zugriff auf diese ein Fehler auf, sieht man in den Protokolldateien eine lustige RemoteException (oder auch CORBA Exception) und mehr nicht - suboptimal. Wie könnte es besser aussehen? Geholfen wäre zum Beispiel durch eine QualityCodeCacheManagerUnavailableException!

Durch solche Fehlertexte ist zwar die Lösung noch nicht gefunden, eine weitere Analyse an dieser Stelle ist aber überflüssig, weil das Problem woanders liegt. Nun kann sich aber der Support direkt dieser Thematik zuwenden und nachschlagen, was bei einem solchen Fehler zu tun ist.

Eine weitere Alternative ist die Eskalation über eMails. Dadurch können die notwendigen Informationen direkt an die Zuständigen Personen übermittelt werden (idealerweise eine Verteilerliste), ohne direktes Eingreifen zu erfordern. Dies könnte z.B. wie folgt aussehen:

Bitte legen Sie für den Qualitätscode das Wertpapier XY fest. Es wurde keine Gruppe gefunden.
Im Anschluss daran ist der Betrieb über den Neustart der Komponente zu informieren.
Diese eMail wurde automatisch generiert, bitte antworten Sie nach Abschluss der Wartungstätigkeit.

Wird diese eMail so gestaltet, dass Sie einerseits an die Verteilerliste gelangt und andererseits dem Betrieb mitgegeben wird, erkennt dieser sofort, wann kein direktes manuelles Eingreifen notwendig ist. Steht der Betrieb zudem als “Reply-To” Empfängerkreis in der eMail, kann dieser direkt informiert werden, wenn der normale Betrieb weitergehen soll.

Was ist der Nachteil einer solchen Vorgehensweise? Das ist relativ leicht dargestellt:

• Die Java Quelltexte werden länger, da mehr “named” Exceptions geworfen werden
• Die Quelltexte erhalten eine höhere Komplexität, da mehr defensive Prüflogiken eingebaut werden
• Der Entwickler muss sich nicht nur darüber Gedanken machen, wie er sein Problem löst, sondern auch, wie er dem Wartungsproblem begegnet

Es gibt sicherlich noch eine Menge mehr, was an dieser Stelle aufgeführt werden kann, aber nun auch ein paar positive Anmerkungen:

• Die Entwickler werden entlastet, da mehr Aufgaben durch den Betrieb/Support gelöst werden können
• Die Entwickler sind nur noch dann einbezogen, wenn der Fehler nicht durch den 2nd Level gelöst werden kann. In diesem Fall handelt es sich aber um “sinnvolle” Fehler, die tatsächlich einen Entwickler erfordern. Dies ist meistens nicht der Fall
• Die Projekte werden automatisch robuster entwickelt. Da der Entwickler möglichst wenig Aufgaben im Wartungsumfeld wahrnehmen möchte, es ihm ein Anliegen, die möglichen Fehler möglichst umfassend zu dokumentieren (in Form von Exceptions und SDs)

Was ist das Ende vom Lied? Eine bessere Supportleistung ist möglich. Dies ist in diesem Falle mit einem Eingriff in den Quelltext verbunden, der den üblichen Rattenschwanz hinsichtlich Change, Deployment und Re-Test nach sich zieht, aber schlußendlich qualtitativ höheren Code hinterlässt.