XlF's BlogWorld - Software-Engineering

Bargeldloser Zahlungsverkehr

nospam@example.com (Axel Hoffmann) — Thu, 07 Jan 2010 21:23:21 +0100

Inzwischen liegt der erste Januar 2010 ja schon eine Weile zurueck und irgendwie scheinen die Banken ihren Kunden immer noch keine wirkliche Loesung fuer das EC-Karten-Problem praesentieren zu koennen.

Nachdem es sich ja offensichtlich um einen typischen Bug in einem typischen Stueck Software handelt, der durch einen dummen Zufall grosse Auswirkungen auf ein paar Zigtausende Geraete mit ein paar Millionen Benutzer hat, kann man das Alles ja mal ein wenig durch die Brille eines Softies beleuchten.

Wir bewegen uns also in einem Markt, wo eine Handvoll Technologie-Anbieter (die Anbieter von Chipkarten bzw. die Chips derselbigen), sich um ein paar Hundert (mehr Herausgeber von EC- und Kreditkarten gibs sicher nicht in Deutschland) balgen, die sich wiederum um die bereits erwaehnten paar Millionen Bank-Kunden bemuehen.

Ich war ja diverse Jahre in einem Markt zugange mit aehnlichen Zahlenverhaeltnissen in der Rolle der Handvoll "Platform-Anbieter". Die Umgebungsbedingungen sind gepraegt durch einen Standard, der (zum Glueck) vorgibt, wie die Geraetschaften alle untereinander ein Mindestmass an Funktionalitaet erbringen sollen (also im Wesentlichen Transaktionen in Girosystemen loszutreten). In diesen Standards sind normalerweise auch Test-Prozeduren festgelegt, wo es eben auch um Banalitaeten wie Jahreszahlen gehen sollte.

Nachdem es ja auch nur Geraete mit einer bestimmten Software eines bestimmten Anbieters betrifft, kann man mal davon ausgehen, dass der Standard an dieser Stelle robust genug ist, bzw. dass man an dieser Stelle das Problem erkannt und auf mehr oder weniger saubere Art umschifft hat.

Idealerweise hat man (insb. als Platform-Anbieter) fuer solche Uebergaenge wohldefinierte Testroutinen, die idealerweise genau dieses Problem feststellen, bevor es in ein paar zigtausend Geraetschaften ein paar Millionen Benutzer stoert. Am idealsten fuer das "Systemhaus" ist es natuerlich, wenn die Tests derart umfassend sind, dass bereits dem Entwickler der das betreffende Programm-Schnippsel erzeugt, der Code auf die Fuesse faellt. Eine derart hohe Testabdeckung kostet aber richtig Geld. Die Tests muessen entwickelt werden, Infrastruktur muss dafuer vorgehalten werden, die Tests muessen gepflegt werden. Auf der anderen Seite steht dem nicht wirklich messbares gegenueber. Sitzen Entscheidungstraeger ohne einen ausgepraegten Software-Hintergrund am Ruder steht man eigentlich dauernd unter Rechtfertigungs-Druck. Andererseits ist an dieser Stelle die Behebung des Fehlers noch am billigsten (ein Mann, der den Fehler mit Tools-Hilfe entdeckt, sich in den Bauch beisst, den Fehler behebt und froh ist, dass es sonst niemand gemerkt hat).

Hat man einen halbwegs passabel funktionierenden Review-Prozess, hat man womoeglich noch Chancen, dass dem zweiten Entwickler so ein Fehler auffaellt, aber bereits diese Chance ist deutlich geringer. Hier laesst es sich mit entsprechender Tool-Unterstuetzung und Protokollierungsaufwand womoeglich messen, wieviele Bugs gefunden wurden, so dass man schon etwas einfacher argumentieren koennte, aber es ist eben schon deutlich lueckenhafter. Ausserdem ist es an dieser Stelle schon deutlich teurer (ein zweiter Mann, der sich erst in die Code-Aenderung einarbeiten muss, der den Fehler entdecken und erklaeren muss, die Behebung kommt dann noch dazu).

Ist der Fehler mal von dem kleinen Arbeitspaket in die naechste Stufe gewandert ist die Wahrscheinlichkeit verschwindend gering, dass jemand diesen Test ausfuehrt:

setze das Systemdatum auf den 1. Januar 2010
fuehre eine Transaktion durch

Die Integratoren, die diese Aenderungen Wochen nach der eigentlichen Entwicklungsarbeit in das Gesamtsystem (also die Software fuer ein Kartenterminal) einpflegen, haben mit hoher Wahrscheinlichkeit ein paar Tausend Aenderungen ("Change Requests") abzuarbeiten und stehen normalerweise zu stark unter Zeitdruck, um mehr als einen absolut minimalen Testdurchlauf zu machen ("Smoke Test"). Dieser wird womoeglich so aussehen:

Geraet einschalten
Transaktion nach dem Ermessen des Testers durchfuehren
Geraet ausschalten

Dieser Test ist genau genommen zufaellig, findet vermutlich unter irgendwelchen Laborbedingungen statt und prueft lediglich einen kleinen Teil eines Anwendungsfalles ab (ein "Sunny Day Scenario").
Selbst ein Fehler, der an dieser Stelle gefunden wird, ist nochmal deutlich teurer in der Behebung, weil eben noch (mindestens) ein dritter Mann involviert ist, in diesem Fall der urspruengliche Entwickler von seiner jetzigen Aufgabe auf die bereits mehrere Wochen alte Aenderung angesetzt werden muss, dafuer diverse Scheffs involviert werden muessen, neue Projekt-Kostentraeger aktiviert werden muessen usw.

Den teuersten Fall erleben wir hier. Der Fehler wird erkannt, wenn er bereits beim Benutzer angekommen ist. Andererseits stehen viele Banken unter massiven Kostendruck (es wird immer schwieriger, Konto-Gebuehren zu verlangen, um die Manager-Boni zahlen zu koennen), dieser Druck wird natuerlich tendenziell an die Lieferanten weitergegeben (und am Ende dieser Nahrungskette steht nunmal irgendein Systemlieferant). So eine Investition in gute Tests kann man da nur schlecht innerhalb eines Quartals umlegen, so dass es dem CEO nicht gruendlich sein variables Gehalt verhagelt. Einfacher lebt es sich dann mit bekannten Qualitaetsrisiken.

Die Kosten dafuer werden in allen der geschilderten Faelle aber auf die eine oder andere Art bei uns als Bankkunden ankommen, nachdem die Kosten irgendwie auf uns umgelegt werden (und wenn auch ueber mehrere Jahre verteilt).
Womoeglich schaffen es allerdings die Entscheidungstraeger das immer noch so schoen zu rechnen, dass es in schlauen Excel-Tabellen immer noch billiger war, als ein solides Testsystem am Laufen zu halten. Das hilft dem Kunden an der Supermarkt-Kasse zwar nicht, aber der Prozess-Verantwortliche des Software-Hauses steht sicher glaenzend da (und wie gesagt, die Zeche zahlt ja der Kunde).

Kommentieren natuerlich wieder hier und nicht auf Facebook.

In der zweiten Arbeitswoche

nospam@example.com (Axel Hoffmann) — Wed, 11 Nov 2009 21:58:52 +0100

Inzwischen bin ich ja in der zweiten Woche in meinem neuen Wirkungskreis.

Abgesehen, dass das Arbeiten in einem 30-Mann-Laden voellig anders ist, als in einer Tausend-Mann-Software-Organisation, habe ich mich aber schon ganz gut eingelebt .

Ich komme als Vollblut-Softie in eine Gruppe begnadeter Projekt-Manager, erfahrener Dokumenten-Artisten und Requirements-Dokumentierer und bekomme die (in den letzten zwei Jahren etwas zu kurz gekommene) Multikulti-Atmosphaere wieder. Manchmal an Stellen, wo man sie nicht erwartet (wenn ein Zulieferer im Rheinland ernsthaft die Integration verschieben will, weil sie mit dem Karneval kollidiert).

Die Spielzeuge, an deren Entstehung ich jetzt mitwirke, entstehen nach neuartigen Prozess-Konzepten wie dem V-Modell (mit seinen Urspruengen in den 1980ern), die Entwicklung im Detail ist dagegen an manchen Stellen unerwartet agil. Trotzdem kaempft man gegen die Fehlentscheidungen, die vor zwei Jahren getroffen wurden und weiss, dass man noch gut und gerne zwei bis drei Jahre damit zu tun haben wird.

Die Situation an der Toolchain-Front ist ungefaehr vergleichbar mit dem Zustand, den ich vor etwa zwei Jahren bei meinem Ex-Arbeitgeber vorgefunden habe. Dieses Mal sind allerdings sie jeweiligen Inseln ueber mehrere Firmen verteilt, das An-Einem-Strang-Ziehen der verschiedenen Parteien und die Transparenz untereinander wird also nur marginal einfacher gehen als in den letzten zwei Jahren wo sich alles innerhalb eines Konzerns abgespielt hat.

Ach ja: natuerlich geniesse ich den kurzen Arbeitsweg, solange es noch was Besonderes fuer mich ist und die Kantine ist wirklich so gut, wie sich viele Geruechte und Legenden im Ort erzaehlen.

Und: kommentieren bitte hier und nicht auf Facebook!

50 Lebenslaeufe spaeter

nospam@example.com (Axel Hoffmann) — Fri, 16 Oct 2009 19:54:22 +0200

Nachdem ich ja eine Weile auf der Bewerber-Seite stand und in meinem aktuellen Job-Umfeld keine Neu-Einstellungen zu taetigen waren, bin ich fuer ein paar Wochen auf die Gegenseite gewechselt und filtere Lebenslaeufe. Nach der Lektuere von ca. 50 (gefuehlten 100) Lebenslaeufen gibts ein paar Erfahrungen.

Ein paar Dinge sind mir schon aufgefallen:

Wie eine vollstaendige Bewerbung auszusehen hat, ist eigentlich kein wohl gehuetetes Geheimnis mehr, es gibt Webseiten darueber, die Bewerber-Portale grosser Konzerne lassen auch keine Unklarheiten (auch wenn ich zugeben muss, das Portal meines aktuellen Arbeitgebers nicht dahingehend angeschaut zu haben), trotzdem schaffen es Unmengen Bewerbungen mit fragwuerdiger Qualitaet bis zu "uns" als Fachabteilung
Es ist selbst fuer Deutsch-Muttersprachler mit akademischen Abschluss offenbar nicht selbstverstaendlich, den Office-Spellchecker ueber den Lebenslauf und Anschreiben laufen zu lassen (oder ersatzweise mindestens einen Mitmenschen vor dem Abschicken Korrektur lesen zu lassen)
Wenn man (zB insolvenzbedingt) in einer Transfer- oder Beschaeftigungs-Gesellschaft angestellt ist, bewirbt man sich offensichtlich ohne Ruecksicht auf Verluste bei jeder Stelle, ganz egal, ob das Profil IRGENDwie passen koennte

Auf letzteren Punkt lohnt es sich, etwas genauer einzugehen.

Ich kann jeden in dieser Lage verstehen. Aber dann kann es hilfreich sein, den Lebenslauf zu ueberarbeiten, dass eine gewisse Vielseitigkeit und schnelle Auffassungsgabe daraus hervorgeht. Lebenslaeufe, die keine Berufserfahrung in den direkt geforderten Bereichen aufweisen, klopfe ich darauf hin ab, und wenn ich das nicht herauslesen kann, setze ich im entsprechenden Recruitment-Portal auf "Absage". Ich meine damit nicht die (fast ueberall auftauchenden) Schlagworte in den Soft-Skills, sondern eine gewisse Vielseitigkeit in den Aufgaben. So kann es sinnvoll sein, wenn ein Software-Entwickler auch Themen wie "Administration eines Linux-Servers" im Lebenslauf stehen hat. Auch dies sollte natuerlich in sich stimmig sein, also macht es keinen Sinn, bei der genannten Server-Administration, dann bei "Sonstigen Kenntnissen" nur Windows stehen zu haben.

Zur Vollstaendigkeit:

Oft kann ich in der Fachabteilung ersehen, wie oft die Personaler Ping-Pong spielen mussten, bis die Bewerbung "vollstaendig" war (was das fuer mich bedeutet, kommt gleich ). Wenn sich das ueber laengere Zeit hingezogen hat, gibt das auch Minus-Punkte.

Fuer mich bedeutet "vollstaendig", dass ich einen Lebenslauf finde, aus dem hervorgeht, wie lange der Bewerber wo war, und was er dort gemacht hat. Anschreiben finde ich zwar vor, lese ich aber im Normalfall nicht genauer (in vielen Faellen ist es eh eine nichtssagende Email).

Hat ein Lebenslauf mein Interesse gefunden (also bei ca. 10% der Bewerber) steht eine Google-Suche an, die in vielen Faellen auch Fundstellen in den gaengigen Social Networks zu Tage bringt. Interessiert bin ich aber eher an Publikationen oder Vortraegen des Bewerbers, oder an Usenet-Postings (insbesondere bei aelteren Bewerbern) oder Forums-Beitraegen (insbesondere bei juengeren Bewerbern). Allerdings sind hier eher fachlich relevante Artikel interessant. Ein Software-Entwickler, der aktiv in Eclipse-Mailinglisten oder Foren mitschreibt, ist spannend. Ich wuerde allerdings einen Bewerber dessen einziger Footprint im Netz eine grosse Urlaubs-Photo-Serie im Netz ist, nicht von vornherein aussortieren.

Ist ein Lebenslauf in irgendeiner Form "seltsam", also ist er

Extrem gut, oder extrem schlecht
Von einem Englisch-Muttersprachler oder Inder in Englischer Sprache

freut sich der geneigte Fachidiot ueber ein Arbeitszeugnis eines deutschen Arbeitgebers.

Hier lassen sich die Standard-Formulierungen entweder von einem Personaler oder von Herrn Google genauer unter die Lupe nehmen.

Es ist und bleibt aber so, das Haupt-Werkzeug ist und bleibt der Lebenslauf. Normalerweise entscheidet sich beim ersten Lesen, ob es eine Zu- oder Absage wird. Als Lebenslauf-Autor hat man also ein paar Minuten meiner Aufmerksamkeit. Spannenderweise sind mein Kollege, mit dem ich die Lebenslaeufe diskutiere meistens einig.

Ach ja:

Wenn schon kommentieren dann hier und nicht auf Facebook!

Der Abend vor dem Flug

nospam@example.com (Axel Hoffmann) — Sun, 19 Oct 2008 20:03:16 +0200

Morgen steht der letzte Besuch bei der Niederlassung in Daenemark an.

Die letzten Wochen und Monate waren schon gepraegt von Vorbereitungen fuer die kommende Woche, in der die Entwickler dort "unser" Configuration Management zu benutzen beginnen sollen.

Damit soll ein Teil der Fehler, die beim Vorgaengerprojekt mit dem gleichen image-traechtigen Kunden passiert sind (und klassische CM Fehler) vermieden werden.

Auf meinen letzten Besuchen im noerdlichen "hyggeligen" Nachbarland durfte ich schon Bestandsaufnahmen und Politik machen, Konzepte erarbeiten und Trainings veranstalten.

Ich bin gespannt, wie das funktionieren wird. Ein grosser Teil der Arbeit wird Support und Haendchenhalten sein, bevor naechste Woche dann ein Kollege die gleiche Reise unternimmt, um Support vor Ort ("on-site" wie man im Managerdeutsch so sagt) zu leisten.

Ob es vermag, wenigstens diese Sorte Fehler zu vermeiden kann natuerlich niemand sicher beantworten, noch viel weniger, ob das neue Projekt weniger Staub aufwirbeln wird, als das gerade ueberstandene.

Joseph Weizenbaum ist tot

nospam@example.com (Axel Hoffmann) — Thu, 06 Mar 2008 20:57:32 +0100

Gestern ist Joseph Weizenbaum ist gestern in Berlin mit 85 Jahren gestorben.

Kommunikation im Unternehmen

nospam@example.com (Axel Hoffmann) — Fri, 25 Jan 2008 21:34:06 +0100

Wir haben ja schon seit ein paar Monaten eine neue Mitterfirma. Diese Mutterfirma hat ausser uns noch diverse ander Toechterfirmen. Von diesen Toechtern dreht es sich jetzt um eine, die thematisch genau die gleiche Software strickt wie wir, wenn auch mit ein paar anderen Vorgehensweisen, anderen historisch gewachsenen Strukturen usw. Diese Tochterfirma erstreckt sich ueber mehrere Standorte, wo uns der naechstliegende in Muenchen (dort, wo wir ab Ostern auch residieren werden) und ein nicht ganz so naheliegender in Nuernberg zu liegen kommt.

Es ist also nicht ueberraschend, dass wir immer mal wieder angefordert werden, irgendwo zu helfen, wo es brennt, wo jemand gekuendigt wurde, oder wo einfach Spezialwissen gefragt ist, was jemand von uns hat. Jetzt soll ich mit einem Kollegen eine Aufgabe uebernehmen (90% er, 10% ich), wo wir erstmal auch eingearbeitet werden sollen. Eine Teilaufgabe davon sind Lieferungen eines bestimmten Subsystems an einen bestimmten Kunden.

Wir hatten schon vor fast zwei Wochen darauf bestanden, dass wir so eine Lieferung mal unter Aufsicht machen wollen, um die ganzen Mechanismen, Arbeitsauftraege kennenzulernen, dass wir uns schonmal daran gewoehnen koennen, Daten von einem Excel-Sheet ins naechste zu kopieren, Dinge per mail zu verschicken, die man eigentlich besser auf shares ablegt und Dinge auf shares ablegt, die eigentlich in Mails besser verbreitet werden.

Also hat sich (verkuerzt) ungefaehr der folgende Mailwechsel gesponnen:

PL1 (Muenchen) an PL2 (Nuernberg): "Xlf und $kollegevonxlf muessten eine Lieferung zur Einarbeitung machen, koennen sie das mit Dir naechste Woche machen?"
PL2 an PL1: "Ja, aber sie muessen nach Nuernberg kommen, weil ich hier jemanden anderen Supporten muss"
(es fahren also schonmal zwei Leute nach Nuernberg, um einen Menschen zu treffen)

Ich und mein Kollege erklaeren sich bereit, nach Nuernberg zu kommen (ich bin eh schon einen Tag dort und fahre dann halt einfach den Tag vorher auch schon hin).

Ich -> PL2: "Gibt es irgendwelche Dokumentation ueber die Lieferung, die wir da machen werden?"
PL2 -> Ich: "Was fuer eine Lieferung? Da ist doch gar keine Lieferung geplant"
Ich -> PL1: "Es scheint gar keine Lieferung geplant zu sein, was fuer einen Sinn hat das dann alles?"
PL1 -> Ich: "Das stimmt, aber PL3 macht naechste Woche eine Lieferung in Muenchen"

Meine Goettergattin muss mich fuer einen Schwaetzer halten und die Firma in der ich arbeite fuer total bekloppt, die Assistentin, die fuer uns die Zugfahrkarten bucht, muss mich fuer einen extrem planlosen Kollegen halten und ich will gar nicht so genau wissen, was die netten Damen im Reisebuero und im Hotel denken, wenn ich dann am Montag das alles wieder stornieren lasse.

Jetzt kann ich eh nix mehr bis Montag aendern und dann werde ich erst mal in Ruhe den Vormittag nutzen um das zu klaeren. Vielleicht haben die ganzen involvierten Leute dann ungefaehr eine Ahung, wer was macht.

Effektiv arbeiten in der Einzelzelle

nospam@example.com (Axel Hoffmann) — Wed, 26 Sep 2007 20:13:56 +0200

Nachdem ich gestern bei meiner wichtigsten Arbeit nicht vorwaerts gekommen bin, weil der ganze Tag aus Telefonaten, Kollegen an meinem Schreibtisch, Mails beantworten usw. bestand habe ich heute nach dem abhalten eines immer mittwochs stattfindenden Meetings in ein unbevoelkertes Zimmer zurueck gezogen und habe gearbeitet. Als einziger wusste mein Scheff und die Kollegin, fuer die ich die Arbeit mache wo ich sitze.

Der Tag war dann auch erfolgreich, und als ich kurz vor meinem Feierabend an meinen Schreibtisch zurueck kam, meinten meine Kollegen, dass mein Telefon kein einziges Mal geklingelt haette und auch kein einziger Kollege waere da gewesen (Kunststueck, sie waren ja gestern schon alle da).

Arbeiten

nospam@example.com (Axel Hoffmann) — Tue, 11 Sep 2007 20:43:32 +0200

Seitdem bekannt wurde, dass wir wieder mal verkauft wurden, ist es richtig schwierig, neben dem Austauschen von Informationen, unbestaetigten Geruechten und pessimistischen Aussichten auch noch Arbeit zu schaffen.

Zum einen ist natuerlich bei vielen Kollegen ein massives Motivationsloch zum Anderen wollen lechzen Alle nach Informationen und aus jedem noch so kleinen Anruf um gezielt Informationen fuer mein Tagesgeschaeft zu bekommen ("in welcher Version ist der Bug Nr. 4711 geloest?") wird eine halbe Stunde Frage-und-Antwort-Spiel, wer wieviel weiss, wer noch Lust hat, was fuer die neuen Inhaber zu tun, wie hoch unsere Chance ist, dass unsere Software ueberlebt etc.

Nachdem ich als Integrator, Tools und Methoden-Arbeiter nicht direkt an der Front bin, arbeite ich zur Zeit an Aufraeum-Arbeiten, die seit Wochen liegengeblieben sind. Einerseits koennen diverse huebsche Tools und Informationssysteme auch zur Profilierung unserer Gruppe beitragen, andererseits weiss man ja nicht, wofuer es gut ist, wenn da mal jemand anderes reinguggt. Nachdem wir an einigen Stellen unseren neuen Eigentuemern was voraus haben duerften, tue ich gut daran, "meine" Software so modular zu gestalten, dass sie auch in einem neuen Umfeld arbeiten kann.

Kindergarten

nospam@example.com (Axel Hoffmann) — Wed, 05 Sep 2007 17:22:00 +0200

Heute war ich zu einem Meeting eingeladen.

Urspruenglich hiess es, ich sollte mit ein paar Kollegen etwas reviewen, wo ein Kollege eine Loesung fuer ein Problem gestrickt hat, dessen wir uns aus Zeit-, Prioritaets- und Personalgruenden nicht annehmen koennen, was aber eigentlich in unsere Verantwortung fallen wuerde.

Es hat sich dann aber herausgestellt, dass zwei Kollegen im anderen Team aber nicht miteinander koennen und deren Chef nicht imstande ist, das zu klaeren und wir sollten dann das salomonische Urteil faellen.

Prinzipiell stand es schon unter einem schlechten Stern, nachdem wir nicht die Chance hatten, erst mal gemeinsam das Problem, fuer das die Implementierung eine Loesung ist, zu formulieren (es war eigentlich klar, aber es hilft, es an der Tafel stehen zu haben). Die beiden Streithaehne haben naemlich sofort angefangen die Loesung auseinander zu nehmen und keiner "von uns" und auch deren gemeinsamer Scheff war im Stande sie zu bremsen.

Waehrend des Meetings fielen dann zwischen diesen beiden Kollegen Sachen wie "You're unprofessional", "You have a destructive attitude to my implementation" usw. und einer der beiden Streithaehne hat den Raum verlassen (gluecklicherweise nicht derjenige, der die Implementierung gemacht hat).

Danach konnten wir immerhin das Problem nochmal aufschreiben (da waren wir uns einig).

Meine Bemerkung, dass ich ueber die Realisierung ja nix sagen kann, solange ich sie nicht gesehen habe und dass ich sie aber gerne sehen will, hat dann das eigentliche Problem zu Tage gefoerdert.

Der Entwickler wollte seine Arbeit gewuerdigt sehen!

Wir koennen uns noch solange unserer technischen Ausbildung und Professionalitaet ruehmen. Emotional will jeder Anerkennung fuer das, was er geleistet hat und das Mindeste ist, es sich anzuguggen.

Selbst wenn sich herausstellt, dass sie aus irgendwelchen Gruenden nicht funktioniert (was ja auch noch nicht feststeht) oder dass sie noch Aenderungen braucht (was sehr wahrscheinlich ist), will er, dass man nicht einfach so urteilt.

Das ist eigentlich voellig verstaendlich, immerhin hat er ja einige Wochen daran gesessen. Warum sein Scheff nicht den Weitblick hatte, uns von vornherein um Rat zu fragen, bleibt sein Geheimnis.

Dem Entwickler selbst kann ich keinen Vorwurf machen, er versteht unter unserer Abteilung bis jetzt noch eine verschlafene Support-Abteilung, die jede Veraenderung erst mal ablehnt.

Workflows dokumentieren

nospam@example.com (Axel Hoffmann) — Fri, 31 Aug 2007 07:40:43 +0200

Ich bin ja zur Zeit zum grossen Teil damit beschaeftigt, neue Methoden zu entwickeln und zu dokumentieren.

Dass unsere Entwickler dann auch damit arbeiten koennen, empfehlen sich ein paar Grundregeln

Den kompletten Workflow muss ich selbst mindestens einmal von Anfang bis Ende durchgezogen haben
Der Workflow braucht anfaenglich nicht komplett automatisiert sein
Das Dokument muss ein Kochrezept sein, wo man oben anfaengt und unten aufhoert (keine Spruenge zwischen mehreren Dokumenten, keine Spruenge zwischen Kapiteln)
Fuer Entscheidungen waehrend des Prozesses muessen klare Kriterien gegeben sein, oder der Entscheider muss klar benannt werden
Screenshots, Screenshots, Screenshots!
Beim ersten Anwender sitze ich idealerweise daneben, wenn er an Hand des Dokuments arbeitet, dabei habe ich das Dokument bei mir und mache mir gleich Notizen
Die zwei-fuenf Anwender des Workflows und Prozesses werden direkt von mir angesprochen und nach Feedback gefragt

Ich schreibe Dokumente am liebsten in unserem Wiki, nachdem ich dort mit wenig Aufwand ansprechende Dokumente zaubern kann. Ebenso bietet ein Wiki Versions- und Zugriffs-Kontrolle und ganz automatisch sind die Dokumente von ueberall im Firmennetz erreichbar.

Spruch des Tages

nospam@example.com (Axel Hoffmann) — Tue, 12 Jun 2007 08:44:14 +0200

Alle sagten, dass es unmöglich sei, bis einer kam der das nicht wusste und es einfach gemacht hat.

Dieser Spruch will mir nicht aus dem Kopf, angesichts dessen, was ich gestern in der Arbeit erleben durfte.

Which Programming Language?

nospam@example.com (Axel Hoffmann) — Thu, 03 May 2007 07:00:10 +0200

Nachdem ein Blog-Kollege schon da mitgemacht hat, konnte ich es mir auch nicht verkneifen.

Wirklich ueberraschend ist das Ergebnis ja nicht .

Which Programming Language are You?

Besuch im Vereinigten Koenigreich (1)

nospam@example.com (Axel Hoffmann) — Wed, 07 Mar 2007 14:24:19 +0100

Gestern frueh sollte es mit der 7:20 Maschine von Muenchen nach London losgehen.

Natuerlich ruft der ScheffScheff an, als wir grad am Checkin stehen, dass er spaeter kommt (er schafft es aber dann doch noch rechtzeitig zum Boarding).

Also sitzen wir dann in der Maschine, sie wird von der Parkposition aufs Vorfeld geschoben und da stehen wir erst einmal eine halbe Stunde im Weg rum. Irgendwann der Pilot "leider haben wir Kerosinaustritt am Triebwerk und muessen da erst einmal einen Techniker kommen lassen". Eine Viertelstunde spaeter "der Flug ist annulliert, sie fliegen in der Maschine um 9:00 mit". Also haetten einige Leute fast 2 Stunden laenger schlafen koennen .

Mit besagter Maschine sind wir dann mit gekommen, aber selbst diese hatte dann nochmal eine Stunde Verspaetung, so dass wir anstatt 9:00 (urspruengliche Planung) und 11:00 (Planung mit der spaeteren Maschine) um 12:00 in der Firma waren.

Natuerlich hat dann alles am Nachmittag laenger gedauert als geplant, aber wir haben es uns dann auch nicht nehmen lassen, noch ein wenig die Hauptstadt des Vereinigten Koenigreichs zu besuchen (und meinem Scheff, der noch nie dort war, einen authentischen Pub und die Tube vorzufuehren).

Jetzt ist der zweite Schulungstag hier, meine Scheffs sind aber grad mit Praesentieren dran und ich hab eine Stunde Pause.

Spannend wird natuerlich dann auch wieder der Heimflug.

Einfach ein Eintrag aus dem Chaos

nospam@example.com (Axel Hoffmann) — Thu, 14 Dec 2006 07:20:10 +0100

Tja, was soll man sagen nach den letzten paar Tagen? (Oh das reimt sich, und was sich reimt, ist gut).

Ich war am Montag und Dienstag in Ascot, wo ich Kollegen in unserer dortigen Niederlassung trainieren und Support geben durfte. Mir ist dabei aufgefallen, dass British Airways sich wohl weniger den puenktlichen Transport, als vielmehr die Unterhaltung ihrer Befoerderungsfaelle (dieser Ausdruck ist ja eigentlich von der Bahn gepachtet) auf ihre Leitwerke geschrieben hat.

In jedem Fall durfte ich neben ungeplanten Flughafen-Rundfahrten in London Heathrow ein Flugzeug im Notfall-Modus geniessen (weil die Stromversorgung in Muenchen nach dem Parken nicht funktionieren wollte, vielleicht hatten sie keinen UK-DE-Stromadapter dabei ), mit Spannung darauf warten, ob meine Tasche noch aus dem Flugzeug kommen wuerde (natuerlich laesst sich so eine Ladeklappe nur schwer ohne Strom oeffnen).
Im Endeffekt sollte ich am Dienstag abend um viertelnachacht (abends) in Muenchen landen, es war eine Stunde verspaetet, und mit der Warterei auf Strom und Gepaeck war ich dann kurz vor elf zu Hause.

In der Arbeit hat einen dann der Alltag wieder, weil ein neues Ticket-System ausgerollt wurde. Natuerlich standen gestern einige Leute beschwerenderweise in meinem Buero. Ebendiese Leute waren natuerlich diejenigen, die nicht in den Trainings waren, die nicht bereit sind, die Doku zu lesen und natuerlich sich in erster Linie beschweren, dass frueher alles besser war.

Ansonsten das bekannte Eingeklemmt-Sein zwischen irgendwelchen Geschenk-Ideen der Verwandtschaft. Ueber Geschmack kann man sich ja bekanntlich streiten, aber schwieriger wird es dann, wenn ein Geschenk nunmal einfach nicht passt. Da helfen dann so gut(?) gemeinte Ratschlaege, man moege sich doch einfach neue Matrazen kaufen, dann wuerde es schon passen auch nur wenig, aber meine Telefonpartnerin hat sich bis zum Schluss davon nicht abbringen lassen, dass das doch fuer alle(!) die einfachste Loesung gewesen waere.

Dazu kommt dann noch ein gewisses Unverstaendnis, dass im Versandhandel nunmal Umtaeusche anders gemacht werden, als wenn eine Gutvernetzte Dame einfach so mit der Besitzerin eines grossen Stoff-Waren-Versandhauses telefonieren kann (wobei ich da auch meine Zweifel haette, dass das dann anders laufen wuerde).

Es ist annaehernd unmoeglich, mit Verwandten zu streiten, die 50 Jahre aelter sind, 6 Zeitzonen weiter westlich sitzen und fuer die materiell eigentlich nur wenig Probleme existieren, dafuer aber grosser Wert auf traditionelle Werte gelegt wird. (hier wuerde mir jetzt ein passendes Zitat eines Geschichtslehrers einfallen, aber das verkneife ich mir).
Es sind wirklich zwei voellig unterschiedliche Welten, zwischen denen es nur wenige Verbindungen gibt, und die man nur schwer verstehen kann. Ich kenne nunmahl nicht die wichtigen Porzellanhersteller-Familien oder Versandhaus-Scheffs persoenlich, ich habe keine Rathaeuser geplant und kenne dadurch jeden zweiten Buergermeister im Muenchner Umland persoenlich, ich gehe nicht regelmaessig mit jedem zweiten wichtigen Professor an den Kliniken einen Saufen und bekomme dadurch ueberall Termine, wann immer es mir passt.

Ich bin annehmbar vernetzt in meiner Welt, aber die ist eine Andere, aber das ist eben wohl unmoeglich zu vermitteln.

So... genug Frust von der Seele geschrieben, und man moege mir entschuldigen, dass ich es mal etwas oeffentlicher schreiben wollte. Wenn es auf zu viel Kritik stoesst, kann ich es ja wieder verschwinden lassen.

Grosse Konzerne, Software-Abteilungen und Consulting-Firmen

nospam@example.com (Axel Hoffmann) — Sun, 12 Nov 2006 18:40:15 +0100

Auf einem von mir gerne gelesenem Blog ueber Software-Entwicklung gibt es
diesen Blog-Eintrag ueber das Verhaeltnis zwischen grossen Consulting-Firmen und grossen Konzernen mit Software-Abteilungen.

Ist zwar "nur" auf englisch aber lesenswert.