Roland Dürre
Samstag, der 23. April 2016

Neue Barcamps braucht das Land!

Jetzt weiß ich, warum meine Begeisterung für Barcamps nachlässt …

PM_BannerDiese Woche war ich beim ersten (!) Barcamp eingeladen, das einer der ganz großen deutschen Weltkonzerne in seinem Unternehmen veranstaltete. Die „Unkonferenz“ galt als Experiment und hatte als Thema eines der modernen „Führungsprinzipien“.

Man wollte mal etwas Neues ausprobieren und hat dazu zirka 50 interne Mitarbeiter und ein paar externe eingeladen (einer davon war ja ich). Die Mitarbeiter aus dem Konzern waren fast alles junge „high potentials“, darunter viele persönliche Assistent*innen von Vorständen bzw. Bereichs- oder Produktverantwortlichen.

Von den Freiheitsgraden war das Barcamp ein wenig eingeschränkt. So wurde das „Prinzip der Füße“ und die Rollen der „Schmetterlinge und Bienen“ bewusst nicht formuliert. Ich habe nachgefragt, die Veranstalter waren in der Sorge – nach meiner Meinung zu unrecht, dass es dann dass doch zu viel der Innovation sein könne.

Aber: Die Veranstaltung war wahnsinnig gut.

Ich hatte den Eindruck, dass nach kurzer Skepsis alle Teilnehmer richtig begeistert mit gemacht haben. Und dass es für alle eine tolle Geschichte war. Kein einziger der Teilnehmer hatte sich explizit mit einem Vortrag oder ähnlichem vorbereitet! So haben alle Sessionsgeber nach kurzem Nachdenken spontan ihre Probleme, Sorgen und auch Erlebnisse formuliert. Und das kam an – so wurde in allen Sessions immer an Themen gearbeitet, die wohl brennend wichtig und sehr spannend waren.

Ich habe auch wieder mal viel gelernt und war froh, dabei gewesen zu sein. Besonders habe ich viel besser verstanden, wie große Konzerne heute betreffend Führung und Management ticken. Als Wissens-Beifang wurde mir auch bewusst, dass es tatsächlich in der Regel nicht mehr darum geht, Produkte zu kreieren, die den Kunden nutzen. Denn als erstes geht es um die Bewertung, ob es im Markt noch Bereiche gibt, die unterversorgt sind („produktfreie“ Lücken), von denen jedoch eine Mehrheit der befragten Menschen glaubt, das man so etwas brauchen kann.

Wenn diese Bedingung erfüllt ist, dann geht es nur noch darum, ob es eine gute Marketing-Strategie und ein Vermarktungs-Konzept gibt, dass wesentliche Skalierung und gute Profitabilität (Herstellungskosten / durchsetzbarer Preis) ermöglicht. Dass der Nutzen eines Produkts bei der kreativen Planung so gar keine Rolle mehr spielt, hat mich dann doch ein wenig entsetzt.

Eine (indirekte und) für mich persönlich wichtige Erkenntnis war aber (und deswegen schreibe ich hier), dass mir auf diesem „Konzern-Barcamp“ klar wurde, warum ich immer barcamp-müder werde:

Je länger es ein barcamp gibt, desto mehr Menschen kommen mit vorbereiteten Themen und formulieren nicht mehr spontan und/oder im Kontext des Geschehens ihre Anliegen.

pmcamp3Diese Tendenz sehe ich leider auch immer mehr bei meinen ehemals so richtig geliebten PM-Camps, denen ich bisher immer treu die Stange gehalten habe. Und bin dann mittlerweile am meisten im Kaffeeraum und rede mit den vielen tollen Menschen, die da immer da sind. Auch meine ich bei anderen barcamps zu sehen, dass jedes Jahr die „konfektionierten“ Sessions immer mehr werden und so die Unkonferenz sich nur noch aufgrund ihrer Format-bedingten Freiheit ein wenig von einer guten klassischen Konferenz unterscheidet.

Ein Lösungsansatz könnte so sein:
a) Deutlich zu kommunizieren, dass es besser ist, wenn wir auf barcamps wieder den Moment wirken lassen und sich ausschließlich spontan und aus der eigenen und gemeinsamen Erkenntnis-Situation heraus Sessions anbietet und
b) Die Planungsphasen iterativer und „gemeinsamer“ zu gestalten
(also am Morgen nur die Sessions für den Vormittag festlegen, dann im Forum kurz zu reflektieren, was passiert ist und wie man das am Besten fortsetzen kann).

Die immer wiederkehrende Gradwanderung zwischen individuell (allein) und kollektiv (gemeinsam)  und zwischen agil und im voraus geplant ist sicher nicht einfach hinzukriegen. Aber wir müssen es immer wieder versuchen.

RMD

Roland Dürre
Freitag, der 11. März 2016

„Inspect-and-A­dapt“ deine Schätzungen!

td-logoIch gehe immer gerne zum TechTalk der Techdivision in München. Das ist eine für mich attraktive Veranstaltung, die mein Freund und PM-Camp-Komplize Sacha Storz organisiert. Der nächste Termin ist am Mittwoch, den 16. März 2016 von 19:00 bis 20:30. Das Ende ist früher als sonst, damit die Besucher die Möglichkeit haben, rechtzeitig zum Bayern-Spiel vor dem Fernseher zu sein. Die Veranstaltung findet in den Räumen der TechDivision in der Balanstr. 73 (Haus 8, 3 OG) in 81541 München statt.

Hier die offizielle Ankündigung:

In der agilen Softwareentwicklungen nehmen Schätzungen von User Stories in der Planung eines Projektes eine zentrale Rolle ein. So führen ungenaue Schätzungen beispielsweise zu Überschreitungen des geplanten Budgets und des angedachten Zeitraums.

In einer Studie bei der TechDivision untersuchten wir die User Story Schätzungen in vier verschiedenen Projekten. Das Ziel dabei: Probleme identifizieren & Verbesserungen einbringen. Ein bekanntes Prinzip – denn schließlich gilt Scrum selber auch als ein „Inspect-and-Adapt“ Framework.

Aber: Wie könnte so etwas in Bezug auf Schätzungen aussehen? Und wie stehen die Ergebnisse der Studie in Bezug zur Diskussion um #NoEstimates?

Ich finde das Thema sehr interessant, bin ich doch ein Anhänger der sicher ein wenig provokanten These „Don’t estimate“ und kann dies auch trefflich begründen. Zusätzlich motiviert mich, dass mein Sohn Rupert der Vortragende ist.

Zum Redner:
imagesRupert Dürre ist als Consultant bei der schwedischen IT-Beratung Netlight tätig. Dabei interessiert er sich für unterschiedliche Bereiche in der agilen Softwareentwicklung vom Requirement Engineering, verschiedenen Entwicklungspraktiken bis hin zu der Fragee, wie man Teams organisieren könnte, um eine effektive Zusammenarbeit zu ermöglichen.

Anmeldung:
Die Veranstaltung ist kostenfrei, um Anmeldung wird gebeten. Hier geht es zur Website der Veranstaltung.

Dann bin ich mal um am nächsten Mittwoch um 19:00 in der Balanstraße und freue mich, wenn ich dort viele Freunde treffe!

RMD

Roland Dürre
Sonntag, der 6. März 2016

Handeln!

Ich zitiere dreimal Seneca:

Seneca, part of double-herm in Antikensammlung Berlin (wikipedia)

Seneca, part of double-herm in Antikensammlung Berlin (wikipedia)

Die Philosophie lehrt handeln, nicht reden!
oder
Unsere Worte sollen nicht unterhalten, sondern wirken!
oder
Nicht schwätzen sondern steuern!

Seneca war ein wichtiger Lehrer und Denker des alten Roms. Wenn ich die Geschichte richtig interpretiere, wollte er seinen Schülern helfen, ein wenig erfolgreicher und glücklicher zu werden. Ein schönes Ziel, dass ich mir für meine Mitmenschen auch gerne zu eigen mache.

Im letzten Jahr war ich wieder viel unterwegs. Ich hatte schöne Tage in einem mich begeisternden Philosophie-Kolloquium mit Klaus-Jürgen Grün (Philkoll). In der Jury beim Business Plan Wettbewerb habe ich soviel Neues erfahren. Auf mehreren PM-Camps habe ich Erfahrung und Wissen mit vielen Menschen geteilt. Viele peer-to-peer-Treffen mit Freunden, „Mentés“, jungen Leuten von Startups und vielen mehr haben mich ganz neue Welten erfahren lassen.

🙂 Insgesamt habe wieder mal mehr gelernt als je zuvor. Und fast erdrückt mich, was ich alles weiß. Und das, obwohl ich weiß, dass ich eigentlich nichts weiß. Und so auch nicht weiß, wie ich mein Wissen einsetzen soll. Das ist schlimm, weil ich irgendwie die Nase voll habe vom Denken und Reden!

Ich möchte etwas Tun! Gemeinsam mit Freunden in einen kooperativen Flow hineingeraten, der etwas bewirkt! Und die richtigen Ergebnisse bringt. Die uns und andere begeistern. Die man umsetzen kann.

Also:
Kein Philosophie-Seminar mehr, von dem ich zwar mit vollem Herzen heimkomme, aber gar nicht so richtig weiß, mit wem ich all das aufregend Neue teilen soll, das mich so beeindruckt. Kein Barcamp mehr, auf dem ich zwar noch mehr hoch sympathische und kluge Menschen kennenlerne, die sich aber letztendlich alle doch überwiegend gegenseitig bestätigen und aus dieser Gemeinsamkeit heraus glücklich heimfahren. Weniger Zuhören und Betreuen von Gruppen oder Einzelpersonen.

Sondern:
Mehr tun und mehr handeln!

Aber wie geht das?
Da war ich zuerst mal ratlos. So habe ich mal wieder eine Anleihe bei meiner Branche genommen. Was haben wir Softworker und IT-ler doch schon alles bewirkt?! Wir haben in den Unternehmen das „Sie“ und „die Krawatte“ abgeschafft und dafür Kühlschrank und Kaffeemaschine eingeführt. Wir haben open source erfunden und das agile manifesto geschrieben. Wir haben mit extreme programming und mobprogramming begonnen und peer-to-peer-reviews gestartet. Wir haben erreicht, dass agile, lean und open gedacht wird. Und Unternehmenskulturen geschaffen, die auf Respekt und Augenhöhe basieren und in denen „Partizipation“ und „Fehlertoleranz“ keine Fremdworte sind.

Und wir haben auch das Hackathon erfunden. Da treffen sich tüchtige Programmierer mit ihren Laptops am Wochenende, bauen ihr WLAN auf und schreiben zum Beispiel eine Software für eine NGO. Die dann schon am Montag läuft und beim nächsten Hackathon weiterentwickelt wird.

Das gibt es übrigens jetzt auch jenseits der IT. Kenne ich doch ein Beratungsunternehmen, da nehmen die Herren Berater einmal im Jahr Auszeit und sich dann ein langes Wochenende treffen, um z.B. mit professioneller Anleitung ein Gebäude für einen Kindergarten zu bauen. Das gefällt mir!

Könnten man so z.B. eine Art Hackathon machen, das als Ergebnis aber nicht eine Software sondern einen tollen Businessplan hat? Der aus zwei Komponenten besteht – aus der Geschäftsidee und der Umsetzung? Könnte man auf diese Art nicht auch einen Beitrag leisten, der die zum Beispiel zweifelsfrei durch Flüchtlinge entstehenden Probleme in Positives zu verwandeln kann? Und so wieder zum Beispiel die Voraussetzung für Kreierung von „Flüchtlingsunternehmen“ schafft?

Man müsste doch vorher nur ein paar wichtige Bedingungen festlegen.

  • Das Flüchtlings-Unternehmen muss dem Gemeinwohl dienen. Damit die Menschen erkennen, dass da etwas positives passiert, das allen hilft.
  • Das Flüchtlings-Unternehmen darf etablierten Strukturen keine Konkurrenz machen. Weil es dann gleich wieder einen großen und nicht sehr produktiven Ärger gibt.
  • Die Mitarbeiter aus den Kreisen der Mitarbeiter müssen im Unternehmen eine Arbeit, die die Würde der Menschen respektiert und
  • Das Flüchtlings-Unternehmen muss sich selbst organisieren und steuern. D.h. es darf kein Management von außen geben. Der Beitrag erfahrener Unternehmer und Manager darf also kein operativer sein sondern muss sich auf die Hilfe zur Selbsthilfe beschränken, also aufs coachen & beraten.

Was können wir also machen?

Wir (20 – 30 Unternehmer, Manager und Expergen) treffen uns zu einer Art von „Hackathon“. Dort wird aber nicht programmiert, sondern ein Businessplan erstellt. Zwei Tage lang, in Klausur. Am ersten Tag kreieren wir die Geschäftsidee. Und spätestens am zweiten Tag erarbeiten wir die Umsetzung. Nennen wir so eine Veranstaltung mal StartMaker. Dazu brauchen wir nur 2 Tage – und die richtigen Leute. Ein paar davon kenne ich schon. Und bin sicher, dass da tolles Entstehen kann.

Was haltet Ihr davon?

RMD

Roland Dürre
Montag, der 25. Januar 2016

Demokratische Meinungsbildung und -findung

Bild vom wunderbaren PM-Camp in Zürich.

Bild vom wunderbaren PM-Camp in Zürich.

Seit dem ich denken kann beeindruckt und verwirrt mich meine eigene Spezies. Wie sie liebt und hasst. Wie sie gemeinsam ausgelassen feiert und trauert. Wie sie sich wegen völlig unsinniger Konstrukte bis auf den Tod bekämpft und zu jeder Grausamkeit fähig ist. Wie sie sich streitet und zankt und dann wieder versöhnt. Wie sie sich widerspricht. Wie sie ab und zu ganz gut vorankommt und dann doch wieder zurück fällt. Wie sie an Konstrukte glaubt, die sie selber erfunden hat.

Je mehr ich gelernt habe, desto mehr erstaunen mich die Windungen der menschlichen Geschichte durch die Zeit. Über Jahrtausende ging es kreuz und quer, mal im Zickzack und immer wieder nach vorne und zurück. Es gab auch immer wieder kleine Fortschritte. Aber so richtig vorwärts gekommen sind wir nicht. Und so werden Menschen immer noch eingesperrt, zerstückelt und gequält. Und es wird geheuchelt, dass man es nicht glauben kann. Im Kollektiv wird im Namen Gottes oder des Volkes oder der Sache – wie auch immer – weiter gemordet und gebrandschatzt, so wie schon immer.

Es fasziniert, wie weit wir einerseits gekommen sind (damit meine ich die Aufklärung und ähnliche Fortschritte), was wir technologisch alles für tolle Spielzeuge entwickelt haben und wie absolut rückständig und un-weise (dumm) wir gleichzeitig geblieben sind. Und wie wir es ganz normal finden, dass wir dabei sind, ganz selbstverständlich unseren Planeten (und uns selber) zu zerstören. Obwohl ein anderes Leben wahrscheinlich viel schöner wäre.

Gerade im Kollektiv erscheinen wir mir so dumm, wie es ein einzelner gar nicht sein kann. So kann man getrost mit Gunter Dueck von einer ganz besonderen Schwarmdummheit sprechen. Dummheit als Gegenteil von Weisheit.

Trotz dieser bedrohenden Realität habe ich mir die Utopie einer gerechten Gesellschaft frei von Strafe und ohne Gewalt und Krieg bewahrt. Aber wie könnten wir dahin kommen? Wenn, dann doch nur durch Kommunikation und Verständigung.

Wäre es also nicht schön, wenn wir es schaffen würden, in Teams und Gruppen im Konsens friedlich Lösungen für gesellschaftliche Herausforderungen aller Art zu finden? Und diese dann auch noch gemeinsam umsetzen würden? Nach dem Motto Senecas:

Philosophie heißt nicht Reden sondern Handeln?

Meetings sind ja – wie wir täglich erleben – nicht das probate Mittel um voran zu kommen. Vielleicht geht es noch am besten mit peer-to-peer-Treffen, fixiert auf ein konkretes Thema. Denn alles beginnt zu zweit. Aber da fehlt dann der Gruppen- oder Team-Effekt.

So hat Habermas schon vor vielleicht 50 Jahren den redlichen Diskurs definiert. Den habe ich im Vortrag „Der Wandel im Management“ (am Ende des Artikel) beschrieben. Und dem sind wir hier und da schon ein wenig näher gekommen.

PMCampDOR Intro 2015Auch die Kollegen von Art of Hosting machen mir Mut, so wie auch die PM-Camps, bei denen ich dabei sein durfte.

Barcamps sind ganz „einfache“ Veranstaltungen. Die Gastgeber schaffen einen Rahmen, damit ihre Gäste gute Gespräche führen können. Die Menschen, die kommen, sind die richtigen und werden zu Teilgebern. Und bestimmen, wohin es geht. Es ist eine Un-Konferenz, das demokratische Gegenteil der Konferenz.

Barcamps oder ähnliche Formate wie „Open Space“ sind etwas Wertvolles. Tausende finden in Deutschland im Jahr statt. Zu vielen Themen: Mal geht es um die Wiederbelegung des Leben in der Stadt oder um die Lösung sozialer Herausforderungen. Weiter auf Barcamps beliebte Themen sind Arbeitswelt, Bildung, Familie, Forschung, Geschlechter, Gesellschaft, Gesundheit, Innovation, Leben, Mobilität, Unternehmertum, Veränderung, Vielfalt, Zukunft und vieles, vieles mehr.

Oft meine ich, dass es kein wichtiges Thema gibt, zu dem es nicht irgendwo ein passendes Barcamp gibt. Und mir wird immer mehr klar, dass es die Summe von Unkonferenzen wie Barcamps sind, mit denen Menschen Einfluss nehmen Zukunft gestalten können. Denn dort kommen Menschen zusammen, die gemeinsam Wissen und Erfahrung teilen – und sich dabei vernetzen!

Weil die vielen Barcamps so wichtig sind, bin ich froh, dass ich noch von keinem faschistischen oder rechtsradikalen Barcamp gehört habe. Kann es sein, dass die Methodik des Barcamps und „Faschismus“ sich widersprechen und gegenseitig ausschließen? Wäre das nicht wunderschön?

Meinem Freund und Partner Eberhard Huber habe ich diese Gedanken berichtet. Er hat mir dazu geschrieben:

Ich denke, dass sich Faschismus und Barcamp widersprechen. Faschismus ist immer mit einer Lehre verknüpft, die immer einen absoluten Wahrheitsanspruch hat. Lehren mit Wahrheitsanspruch brauchen Propheten, denen man zuhört. Der Status des Propheten könnte bei einer offenem Diskussion wie auf einem Barcamp nur bröckeln.

Das gibt doch Hoffnung. Und vielleicht gelingt es uns so doch eines Tages, die Bedingung von Bertrand Russell zu erfüllen. Der hat mal gesagt:

» Jeder Zuwachs an Technik bedingt, wenn damit ein Zuwachs und nicht eine Schmälerung des menschlichen Glücks verbunden sein soll, einen entsprechenden Zuwachs an Weisheit. «

Vielleicht schaffen wir mit neuer Kommunikation und neuen Formaten, endlich zu der dringend benötigten WEISHEIT zu gelangen. Und dürfen darauf hoffen, dass wenn unsere Generation ausgestorben ist, die nächsten Generationen es besser machen können.

RMD

Hans Bonfigt
Montag, der 28. Dezember 2015

Ganz agil vorbei am Ziel

Wenn man vor lauter Meta-Ebenen den Boden der Tatsachen nicht mehr sieht …

Die Spatzen pfeifen es von den Dächern: Nur etwa 20 Prozent aller Softwareprojekte funktionieren so, daß sie die Anforderungen erfüllen. Mit anderen Worten: Die Ausschußquote beträgt 80 Prozent:

  • 20% der Projekte scheitern, weil schlichtweg so falsch geplant wurde, daß sie gar nicht zu realisieren sind
  • 20% scheitern an Kommunikationsproblemen zwischen Auftraggeber und Entwickler
  • 20% werden aufgrund von Selbstüberschätzung der Entwickler nicht fertig und
  • 20% verenden, weil eingebundene Module von Drittanbietern nicht das leisten, was erwartet wurde

Von den verbleibenden 20 Prozent kann man mehr als die Hälfte getrost in die Tonne hauen, weil es entweder an Stabilität oder an Performance mangelt.

Nur in zehn von hundert Fällen liefern Softwarefirmen also das ab, was erwartet wurde – eine erschreckende Bilanz, die noch furchtbarer aussieht, wenn man das Kriterium „Termintreue“ hinzuzieht.

„Da muß doch ‚was zu machen sein“, dachten sich viele Leute, und der Schuldige war ganz schnell ausgemacht:

Der Wasserfall.

„Bitte reinigen Sie mein Auto“, mit diesen Worten übergab ein Firmenchef etwa zweimal im Monat den Mercedes-Schlüssel an seinen Prokuristen. Bevor hier Zweifel entstehen: Diese Abläufe habe ich Ende der 80er Jahre mehrfach persönlich erleben dürfen. Der Prokurist sah das Fahrzeug nach evtl. darin verbliebenen vertraulichen Dokumenten oder kompromittierenden Gegenständen durch und übergab den Auftrag an den Buchhaltungsleiter, der wiederum delegierte an seinen Chefbuchhalter, welcher seinerseits einen Lehrling verdonnerte. Am Samstagmittag reiste zuerst der Buchhalter an, um die Arbeit des Lehrlings zu begutachten, das Fahrzeug auf eventuelle Beschädigungen zu prüfen und danach erforderlichenfalls noch einmal selber Hand anzulegen. Kurze Zeit später holte dann der Buchhaltungsleiter das Gefährt ab, verbrachte es in die Remise des Chefs, wo bereits der Prokurist wartete, um die evtl. entnommenen Gegenstände wieder einzulegen sowie den Schlüssel persönlich an seinen Gebieter zurückzuüberstellen.

Besonders effizient war das sicherlich nicht. Dummerweise jedoch wurden und werden viele Softwareprojekte nach diesem Schema abgewickelt. Denn die Theorie ist äußerst verlockend:

  • „Oben“ gibt es wenige, die den nötigen Überblick  und damit den Kopf frei haben für die wirklich strategischen Entscheidungen
  • „In der Mitte“ können die taktischen Entscheidungen auf mehrere kompetente Spezialisten aufgeteilt werden und
  • „unten“ kann die zeitaufwendige Codierarbeit von vielen, ggfs. austauschbaren Programmierern schnell erledigt werden.

Das hört sich zunächst einmal schlüssig an. Und um es klar zu sagen: So hat das früher auch einmal funktioniert, und zwar erstaunlich gut. Es bleibt aber nichts, wie es war.

Eins vorweg: Eine monokausale Erklärung, warum der „Wasserfall“ nicht mehr so funktioniert wie früher, kann für solch ein komplexes Phänomen niemals ausreichen. Die nachfolgende Polemik, soweit möchte ich mich aber doch vorwagen, „erschlägt“ einen nicht ganz so kleinen Anteil der Fälle.

Der Ärger fing an mit der Verbreitung des PC. Bevor diese scheußlichen Kisten den Massenmarkt überschwemmten, besaßen Unternehmen typischerweise eine einzige Rechenanlage, und die war extrem wichtig. Deswegen wurde diese gehegt und gepflegt, und zwar von einem gut aufeinander abgestimmten, qualifizierten Team. Es dauerte mitunter Jahre, bis ein neuer Mitarbeiter administrative Rechte bekam. Der Beruf des „Admins“ oder des „Programmierers“ war geprägt von Kontemplativität. Die Maschine zeigte einem oft und unnachgiebig die eigenen Fehler und Grenzen auf, andererseits aber forderte sie häufig, daß man ihre eigenen, zumeist durch die Hardware „eisern“ festgelegten Restriktionen mit neuen Verfahren neutralisierte. Dazu mußte man dieses Ding gut kennen. Ein Assemblerlauf dauerte gerne auch einmal 2 1/2 Stunden, Fehler im Quellcode gab es immer und wer da nicht zwischen den Tests im Maschinencode „patchen“ konnte, der assemblierte sich zu Tode. Das galt sinngemäß für „Hochsprachen“, und so war es selbstverständlich, daß man sehr genau wußte, was genau ein Compiler aus einer PERFORM- oder COMPUTE – Anweisung machte. Man war auch gezwungen, sich bei der Lösung eines Teilproblems genau zu überlegen,

  • soll es besonders schnell ausgeführt werden,
  • soll es möglichst wenig Hauptspeicher belegen (ein unwahrscheinlich wichtiges Kriterium seinerzeit) oder
  • soll es möglichst portabel und, fast immer damit einhergehend, selbstdokumentierend sein?

Unterließ man diese Vorüberlegungen, fiel einem schon das Teilproblem fast unweigerlich schmerzhaft auf die Füße.  Manchmal mußte man auch noch sehr „hardwareschonend“ programmieren, beispielsweise ein eigenes Caching implementieren, um Platten-, Disketten- und vor allen Dingen Bandeinheiten vor frühem Verschleiß zu schützen.

Seit langem arbeite ich in einem Unternehmen, welches nicht nur „Computerprogramme“, sondern manchmal auch komplette Anlagensteuerungen beispielsweise zur Polyesterextrusion entwickelt – vom Steuerprogramm selbst bis zu angepaßter Sensorik und Aktuatorik; wenn es irgendwie geht, verdrahte ich auch die Schaltschränke selbst. Typischerweise übernimmt bei größeren Anlagen der Steuerungsbauer auch die Rolle des Anfahrleiters. Bei der Erstinbetriebnahme, wo aufgrund kleinster Fehler ausgesprochen rohe Kräfte sehr sinnlos, dafür aber umso verheerender walten können, muß man sich auf seine Teamgefährten, aber auch auf die eigene Arbeit hundertprozentig verlassen können. Ein einziges verdächtiges Geräusch, rechtzeitig erkannt und richtig interpretiert, kann enormen Schaden verhindern. Dazu braucht man Menschen mit Erfahrung, Sorgfalt, Vorsicht und Demut.

Nun kamen in den 90ern die scheußlichen „PC“s auf den Markt, und urplötzlich war jeder sein eigener Admin und jeder präsentierte stolz irgendeine heimgebackene Detaillösung, die unter bestimmten Umständen sogar dann und wann funktionierte. Es begann eine grauenvolle Zeit der „dezentralen EDV“, in der jeder Mitarbeiter so eine Daddelkiste unter dem Schreibtisch hatte und auch gerne daran herumschraubte. Das „Fachpersonal“ nutzte die neuen, eigentlich bis heute vielfach völlig unnötigen graphischen Fähigkeiten der Geräte für immer albernere Spiele. Das Hauptproblem bei dieser Entwicklung hat mir einmal eine Psychologin erklärt:Wissen Sie, gern läßt sich eine verlassene Frau von einem Verehrer trösten — doch sie wird nie etwas mit diesem anfangen, nach dem Motto, „Wo ich kotze, eß ich nicht“. Es gibt aber nicht nur den Dipol „kotzen – essen“, sondern auch den Dipol „Spiel und Spaß — Arbeit und Verantwortung“

Vielleicht lag es daran: Wirklich ernsthaftes Arbeiten an PCs habe ich nie erlebt. Es hing ja auch keine Verantwortung daran: Wenn so ein Ding abschmierte, dann war der Schaden lokal begrenzt und alsbald festigte sich ein allgemeines Vorurteil, daß Computer nun einmal von Zeit zu Zeit gerne abstürzen – so einfach ist das. Irgendwelche Maschinen wurden auch nicht mit den Büchsen betrieben, also konnte auch niemand zu Schaden kommen.

Wo keine Verantwortung, da auch keine (Selbst-)Disziplin. Dieses Wort wird m.E. viel zu stark verteufelt, indem es in die autoritäre Ecke gedrängt wird. Dabei leitet es sich aus dem lateinischen ‚discipulus‘ ab, übersetzt am besten mit „Schüler“. Disziplin im positiven Sinne heißt Lernwillen, heißt auch, zunächst einmal deskriptiv anstatt normativ zu arbeiten.

In der PC-Szene will aber

  • jeder
  • immer
  • alles
  • sofort

mit „seinem“ Computer machen, und das knallt schon dann, wenn er alleine an seiner Daddelkiste sitzt, denn „machen wollen“ heißt ja noch lange nicht „machen können“. „Niedere“ Arbeiten haßt der Computerbeherrscher, welcher sich gern mit Künstlernamen wie „Merlin“ oder Bezeichnungen wie „Geek“ schmückt, von ganzen Herzen und besteht darauf, diese an die unwürdigen „User“ zu delegieren. Dabei ist gerade die handwerkliche Seite der Softwareentwicklung von größter Bedeutung. Genau so, wie es keine „minderwertigen Menschen“ gibt, gibt es auch keine „minderwertigen Arbeiten“. Richtig verheerend wird es dann, wenn viele Möchtegern-Herrscher, -Künstler und -Genies gemeinsam an einem Projekt arbeiten müssen, womöglich auch noch auf ein- und derselben Kiste.

Lieber Leser, soweit Sie es bis hierhin geschafft haben: Also, wenn Sie mich fragen, dann ist es in einer solchen Konstellation sehr erstaunlich, daß überhaupt fünf bis zehn Prozent brauchbare Produkte aus einer solchen Situation resultieren können.

Und deswegen haben ganz schlaue Menschen das „Projektmanagement“ erfunden, und eine Untergruppe dieser Menschen hat das „Agile Manifesto“ aus der Taufe gehoben:

Individuen und Interaktionen über Prozesse und Werkzeuge
Funktionierende Software über umfassende Dokumentation
Zusammenarbeit mit dem Kunden über Vertragsverhandlung
Reagieren auf Veränderung über Befolgen eines Plans

Hört sich gut an, nicht wahr? Oder sind Sie selber Softwareentwickler und sehen da vier dicke fette Ausreden von cleveren Böcken, die den Gärtner geben wollen?

 

Wie auch immer – irgendwann erwischt es jeden. Und hier mein ungeschminkter Erlebnisbericht „aus der neuen Welt“:

Es ist noch früh, als ich beim Kunden auflaufe, ich bin zum erstenmal dort. Man hat dort Probleme, ein selbstentwickeltes Programm auf die IBM POWER-Architektur zu portieren. Der Kontakt kommt über IBM zustande.

Man geleitet mich in einen größeren Konferenzraum. Dort sitzen schon vier Leute, jeder versteckt sich hinter seinem Rechner, drei „Apple“, ein „Vaio“. Rechts daneben haben alle „Smartphones“ neben sich liegen. Ich sage vernehmlich Guten Morgen, bekomme etwas zurückgenuschelt (der Stuttgarter Einheimischenslang ist schwierig) und setze mich auf einen der freien Plätze. Lege mir Block und Druckbleistift zurecht und prüfe nochmal, ob das Mobiltelephon ausgeschaltet ist.

Die Empfangsdame war ein junger Mann und entsprechend wurde mir kein Kaffee angeboten. Auch keiner der Anwesenden fühlt sich bemüßigt, einem Gast, der etwa 700 Km weit angereist ist, irgendetwas anzubieten. Irgendwann kommt eine junge Frau, welche im bald beginnenden Rollenspiel die „Project Owner“ gibt. Das ist die bedauernswerte Person, die den Ärger mit den Endkunden hat. Nett angezogen, spricht hochdeutsch und war wohl die, die angeregt hat, einen Externen hinzuzuziehen. Das genaue Gegenteil ist die „Scrum Mistress“, die den „Spielablauf“ steuert.

Letztere stellt mich vor, ich sei von außerhalb und könne vielleicht helfen. „Wo haben Sie Ihr Notebook?“ fragt sie mich, worauf ich antworte, „Ich bin zum Arbeiten hier“. Als das kollektive Getipsel abrupt aufhört, wird mir klar, daß von den mittlerweile 12 anwesenden Personen 11 so ein Knaddeldaddel vor sich haben.

„Aber ein Kaffee wäre nicht schlecht“, versuche ich den gelungenen ersten Eindruck noch zu toppen.

Am Klondike

„… dwelt a miner, fourtiy-niner, and his daughter Clementine“: Im Rahmen einer Agilen Retrospektive soll ich Projekt und Status erfassen. Ein mühsames Geschäft: Ich komme mir wirklich vor wie ein mäßig erfolgreicher Goldgräber, der Fakten-Nuggets aus dem Informationsstrom filtert. Zwei anstrengende Stunden brauche ich, um zu erfassen, worum es eigentlich geht:

Gescannte Dokumente (die SCRUM-Drum sagt immer „eingescannte“) sollen aufgrund von darauf befindlichen Barcodes automatisch bestimmten Anwendungen zugeordnet werden, typischerweise den Anwendungen, welche für die Barcodes verantwortlich waren. Auf den ersten Blick hört sich das blödsinnig an, aber in der Praxis ist dies sehr wichtig, weil im täglichen Betrieb sehr viele maschinell erstellten Belege später, teilweise durch Kunden und Partner, modifiziert oder signiert werden. Der Scanner also als „Datenklo“, wo man alle anfallenden Belege ‚reinsteckt nach dem Motto, „den Scheiß bin ich erst mal los“.

Es wird ungefähr 65.536 mal versichert, daß das Datenklo im eigenen Hause prima funktioniere, bloß nicht auf dem bösen Zielrechner des Distributors.

Der Überblick fehlt: Es gibt niemanden, der mir, quasi in Form eines Blockdiagramms, die beteiligten Module auf die Reihe bringen kann.

Wo viele verantwortlich sind, ist es am Ende keiner mehr: Eine Testmaschine im Hause existiert nicht! Mir bleibt der Mund offen stehen (aber nur kurz, danach frage ich zur Sicherheit nach, ob ich mich hier in einer Softwarebude befinde oder bei einem rheinischen Tuntenballett – für letzteres spreche nicht nur die hohe Anzahl an Apple-Geräten). Auch der „PO“ scheint der Umstand, daß man nicht einmal eine Testmaschine vor Ort hat, völlig neu zu sein: Ihr angenehmer Teint bekommt eine Spur Purpur dazu. Die SCRUM – Drummerin dagegen bekommt rote Flecken im Gesicht und meint, das sei genau richtig und beabsichtigt so und außerdem stehe die Inbetriebnahme einer Testmaschine auch in den Anlagen zum „Burn-Down-Chart„.

Studieren geht über Probieren: Auf dem Burnout-Chart kann man sehen, wieviele Aufgaben noch erledigt werden müssen. Dabei hat man das gleiche Problem wie ein Mikroprozessor mit seinem Instruktionsstrom: Wie vielen älteren Menschen bekannt, wird eine Instruktion ja nicht in einem Takt vom Rechner abgearbeitet, sondern durchläuft typischerweise zwischen 16 und 24 „Bearbeitungsstufen“. Wenn die „Pipeline“ erst einmal gefüllt ist, fällt mit jedem Takt eine abgearbeitete Instruktion an (also, jetzt nicht bei Intel und Konsorten, sondern bei ordentlichen Konzepten). Dumm nur: Manchmal gibt es Sprünge innerhalb eines Programmes und dann heißt es für die Pipeline, die bisher linear nachgeladen hatte: „Zurück auf Start, alle Planung war für’n Arsch“. Fast genauso schlimm wirkt sich die sehr häufig vorkommende Situation aus, die entsteht, wenn aufeinanderfolgende Arbeitsschritte voneinander abhängig sind:

Dann muß halt so lange gewartet werden, bis der Vorgänger fertig ist. (Ja, ‚branch prediktion‘ ist mir ebenso bekannt wie ’superpipelining‘, hier geht es ums Prinzip). Mit dem Burnout-Chart wird geplant wie mit einem schlecht konfigurierten SAP-System, indem davon ausgegangen wird, daß alle Arbeitsschritte gleichzeitig und voneinander unabhängig seien. Ein Anstreicher kann aber kein Haus anstreichen, dessen Mauern noch nicht gesetzt sind. Die ganzen Schätzungen fallen wie ein Kartenhaus zusammen, wenn es, wie jetzt, einmal ernsthaft klemmt und keine Auswege da sind. Bevor man detailreich etwas postuliert, heißt es: „Vorher ausprobiert!„.

PPPPPP: Proper Preflight Planning Prevents Poor Performance! Sonst kommt es zu einem Kollaps, den Judith Andreesen gut beschrieben hat, überdies, völlig branchenuntypisch, in einer klaren, angenehmen Sprache: Die Reißleine ziehen. Überhaupt hat sich die Autorin erkennbar viel Mühe mit ihrem Blog gemacht. Korrektur: Nicht erkennbar viel Mühe gemacht. Denn auch das zeichnet einen guten Text aus, daß er nicht nach Fronarbeit riecht, sondern leicht und angenehm daherkommt.

Not my department – oder „Schuld sind die and’ren, stellt mir keine Fragen“: Die PHP – Mannschaft meint, „was kümmert uns ein Architekturproblem, wo doch unsere Sprache genau dazu gemacht ist, um Architekturprobleme zu abstrahieren („und Zombies wie Euch zu generieren“, aber das kann ich gerade noch unterdrücken – in etwa weiß ich schon, wie weit ich zu weit gehen kann. Nicht einmal Rambo kommt ohne fremde Hilfe ans Ziel). Die Webtrottel also lehnen sich zurück und genießen die Show. Das wäre bei uns in der Firma nicht denkbar. Da packt jeder mit an, um Kollegen, denen die Krawatte klemmt, weiterzuhelfen. Nun sitzen wir übrigens schon seit gut drei Stunden zusammen – und keiner raucht! Das irritiert mich jetzt aber schon.

Selber habe ich vor 20 Jahren damit aufgehört, nicht aus prinzipiellen Erwägungen (intelligente Menschen haben sowieso aus Prinzip keine Prinzipien, weil sie sie prinzipiell nicht brauchen. Doch ich wollte einmal im Leben einen Kampf gegen meine eigene Fremdbestimmtheit gewinnen). Aber jetzt vermisse ich den würzigen Duft einer leckeren Zigarette. Man sitzt in einem Boot, gemeinsam raucht man eine Zigarette, die entweder die kreative Lösungsidee bringt oder, wer weiß, als legendäre „letzte Zigarette“ das gemeinsame Ende besiegelt. Da kommen Emotionen auf! Nicht: „Wir schaffen das!“, sondern: „Wir wollen das!“. Ich frage, ob es irgendwo hier einen nahegelegenen Park gibt, damit man sich die Beine vertreten kann und auf andere Gedanken kommt – die gucken mich an, als hätte ich Gruppensex vorgeschlagen.

Niedere Arbeiten – aber doch nicht für einen „Geek“! Einer meiner Mentoren und großen Vorbilder war jahrelang Leiter der Motorenentwicklung bei seinerzeit IHC, heute bekannter unter dem Namen Case. Eine seiner Thesen war, man könne sowieso nur für ganz kurze Zeit eine kreative und konstruktive Arbeit leisten. Weil man aber schlecht 90 Prozent der Arbeitszeit Pause machen kann, nimmt man sich etwas anderes vor. Und merkwürdigerweise, genau bei diesen scheinbar „untergeordneten“ Aufgaben fallen einem die besten Ideen ein – oder, nicht so schön, aber nicht weniger wichtig, man entdeckt in einem winzigen Detail einen kapitalen Showstopper. Ich erinnere mich noch, als wäre es gestern gewesen – wir hatten ein Problem mit der sogenannten Werkzeugsicherung eines Stanzautomaten: Die Steuerung erkannte zu spät, daß ein Werkstück in einem schnellaufenden Folgeverbundwerkzeug klemmte, der Weitertransport sorgte für Überlagerung und das gewaltige polare Massenträgheitsmoment des Schwungrades der Exzenterpresse für einen kapitalen Maschinen- und Werkzeugschaden.

Mein Mentor „verdonnerte“ mich, die Maschine zu reparieren. Allein. Eine Drecksarbeit, nicht ungefährlich noch dazu. Beim Zerlegen der Drehkeilkupplung, welche die kraftschlüssige Verbindung zwischen Exzenter und Schwungrad herstellt, wurde mir klar, daß diese Verbindung bei einfacher Modifikation der Pneumatik auch noch zu einem wesentlich späteren Zeitpunkt getrennt werden konnte. Glücklicherweise hat das Unternehmen, für das ich arbeitete, bis heute noch einen Werkzeugbau und wir fertigten modifizierte Steuerkulissen und andere Komponenten selbst an. Der Leiter des Werkzeugbaus, obwohl kurz vor der Pensionierung, war mit Feuereifer bei der Sache. Nach drei Tagen lief die Maschine wieder und jahrelang gab es keinen Bruch mehr. Mein Mentor sah mich schräg an und meinte, „Das hätten Sie nie hinbekommen, wenn ich Sie nicht genötigt hätte, die Maschine selbst auseinander zunehmen“. Diese Erfahrung ist der Grund dafür, weshalb ich auch heute noch ganz gern das eine oder andere Modul selbst programmiere. Und sehr gerne irgendwelche Dinge zusammenlöte oder -schraube.

Peer Review: Nach einigem Suchen finden wir einige verdächtige „Hilfsprogramme“, welche aus einer Linux-Distribution stammen. Eines ist mir besonders suspekt. In C geschrieben, gespickt mit Abscheulichkeiten. Mein alter Deutschlehrer brachte mir eine interessante Definition nahe, „Kunst ist die konsequente Umsetzung eines Prinzips“. Hier war die Umsetzung so kaputt, daß das Prinzip angegriffen sein mußte. So wurde zum Beispiel abgefragt,

if (3==i) …

Irgendwelche Germanisten und Nichtprogrammierer haben sich das ausgedacht: Weil ausgemachte Anfänger in den ersten Tagen gern eine Wertzuweisung (=) mit einem Vergleichsoperator (==) vertauschen, wird doch allen Ernstes empfohlen, anstatt des lesbaren und unmittelbar verstehbaren ‚if (i==3)‘ so einen Blödsinn zu schreiben wie oben, denn eine Wertzuweisung an eine Konstante legt den Compiler auf die Nase. Der Anfänger ist „geschützt“ und alle Profis müssen sich jahrelang mit unleserlichem Programmkot herumärgern. Das orientiert sich an einer Lehrpädagogik, die an ein Rennrad Hilfsräder anschraubt: „Hier:  Mit unseren Stützrädern kann keiner mehr umfallen!“. Dumm nur: Mit dem Zusatzklapparatismus macht man aus einem einspurigen Fahrzeug ein mehrspuriges. Und wenn sich ein Profi mit dem „Schutz“ einmal sportlich und schnell in eine enge Kurve legt, fliegt er buchstäblich aus der Bahn, weil er seinen Schwerpunkt nicht mehr ins Kurveninnere verlagern kann und landet im Dreck. Ganz abgesehen davon: Wer „sicher“ und „geschützt“ programmieren möchte, der macht das sinnvollerweise nicht in C, sondern beispielsweise in ADA. Die Krönung: Im vorliegenden Fall steckte auch noch ein gehöriger logischer Fehler drin, denn eigentlich gemeint war: ‚if (i >= 3)‘ …

Es geht richtig fies weiter: Nicht nur „RTL – Castings“ sind stockpeinlich, auch bei der C – Programmierung erkennt man leicht den Stümper. Aus schierem Unverständnis heraus, was Indexregister („Pointer“) sind und wie ein C-Compiler sie interpretiert, werden Werte absolut zugewiesen. So was meckert der Compiler zu Recht an. Mit einem „Cast“, dem Elixier der „Aber bei mir funktioniert es doch!“ – Generation, kann man ihn ruhig stellen. So habe ich es gerne: Zwei Zeilen vorher den Sicherheitsfanatiker herauskehren und dann sozusagen den Brandmelder ausschalten.

Die nächsten Zeilen sind ein offener Angriff auf die abendländische Kultur:

for (…) sprintf (buf,string);

Die Standardfehler, zwei fiese, mißbrauchbare Sicherheitslücken, will ich gar nicht diskutieren. Wer „PHP“ einsetzt, der braucht sich um „Security“ keine Gedanken mehr zu machen. Viel schlimmer finde ich, daß

  • es dieser „teuren“ Funktion gar nicht bedurft hätte: Es werden vier konstante Buchstaben übergeben. Die Aufbereitung dieser vier Buchstaben wird an eine extrem mächtige Funktion übergeben, die die übergebene Zeichenkette lexikalisch analysiert.
  • bei „unpassender“ Parametrierung, beispielsweise mit einem Prozentzeichen im Funktionsargument, das Programm im günstigsten Fall undefiniert auf die Nase fällt.
  • bei jedem der extrem häufigen Schleifendurchläufe die „teure“ Aufbereitung erfolgt, obwohl man dies ohne Not außerhalb dieser Schleife hätte tun können.
  • der Rückgabewert der Funktion ignoriert wird. In diesem Falle wäre das o.K. gewesen, aber dann ist man so nett und benutzt tatsächlich einmal einen „Cast“, indem man ein  ‚(void)‘  vor die Funktion schreibt, um den Compliler am Meckern zu hindern („function returns value which is always ignored“) und den Kollegen anzuzeigen, „Hier habe ich bewußt auf eine Prüfung verzichtet“.

Das Allerschlimmste aber: Die Art und Weise, wie innerhalb der (in der Realität deutlich größeren) Schleife Daten übergeben und in eine Datei geschrieben werden, macht die Portabilität des Codes in Bezug auf die sogenannte Endianness kaputt. Die aufgebohrten „386er“ PC-Prozessoren sind typischerweise „Little Endian“, Mama Blue baut typischerweise „Big Endian“. In der Ausgabe landet jetzt nicht, wie beabsichtigt, „Y800“, sondern „008Y“.

Ich erläutere meinen Verdacht und ernte: Achselzucken. Denn die einzige im Raum, die die Erläuterung kapiert, ist die „nichttechnische“ Project Owneress. Später erfahre ich, daß sie gelernte Floristin ist. Was ich immer sage, „Informatiker meiden!“.

Crisis ?  What Crisis ?

Die Masteress geht jetzt mit SCRUM — vielfach ums Problem herum:

Es wird diskutiert, ob man einen laufenden „Sprint“ abbrechen sollte, um einen neuen zu beginnen, natürlich nicht ohne „Review„. Hat die noch alle Latten am Zaun? Das erste, was man jetzt vielleicht tun sollte, frei nach dem agilen Motto, „Individuen und Interaktionen über Prozesse und Werkzeuge“: Programmkorrektur, Kurztest auf im Hause vorhandener Intel-Spielarchitektur, Testrelease auf einen richtigen Computer packen (und zwar nicht auf die Endkundenmaschine, um diesen nicht weiter zu inkommodieren), dort nochmaliger Test.

Aber weit gefehlt: „Das paßt nicht in unser Tooling„.

Bei uns in der Firma sind wir ja der Meinung, daß man nur das verantwortlich einem Kunden empfehlen kann, was man selber im Einsatz hat, insofern haben wir natürlich auch zwei IBM POWER – Maschinen am Start und im Gegensatz zur INTEL-Welt gibt es dafür auch eine brauchbare Virtualisierungsplattform – ich könnte also innerhalb von kürzester Zeit eine Testumgebung bauen.

Nur leider: „Das ist in unseren Prozessen nicht vorgesehen“.

 

Wenn’s am schönsten ist, Freunde …

… dann muß man halt gehen. Das ist nicht mehr meine Welt. Ich erkenne schlagartig, daß wir „Informationstechniker“ längst zu dem geworden sind, was wir verachtet und bekämpft haben:  Wir sind die neuen Bürokraten. Bleistiftspitzer. Bürohengste. Tintenpisser. Anstatt unseren Job zu machen, „Verwaltung von Information“, beschäftigen wir uns längst fast ausschließlich mit der Verwaltung der Verwaltung. Die eigentlichen Probleme sind ganz weit weg.

Mir fällt noch eine prima Verbalinjurie für die Mannschaft ein, aber irgendwie bin ich gerade zu traurig, um sie auszukippen. Ich bedaure also, unter den gegebenen Umständen nicht die Hilfe gewesen zu sein, die man sich erhofft habe, aber die neue Welt würde mich überfordern – ich käme mir vor wie der „Ich“ – Erzähler in Umberto Ecos spannendem Krimi „Der Name der Rose“:  „sic stat printine nomine rosa, nomina nuda tenemus“.

 

Epilog

Schon drei Tage später bekommen wir Bescheid von der „PO“: Ja, man hat den Fehler bestätigen können. Er wird aber nicht behoben, sondern man hat im „sprint review“ nach langer Diskussion vereinbart, daß der Kunde seine „offensichtlich unzulängliche“ POWER – Maschine von „Big Endian“ auf „Little Endian“ umstellen muß. Denn, so hat man bei IBM erklärt, mit der neuen Generation der POWER-Maschinen könne man das einstellen und außerdem gäbe es da ein passendes „UBUNTU“ …

 

Fazit

  1. Wasserfälle sind wunderschön.
  2. Zwei Dinge sind aktueller als jemals zuvor:  Brechts „Anachronistischer Zug“ und, hier einschlägiger als man es sich wünscht: »Jeder Zuwachs an Technik bedingt, wenn damit ein Zuwachs des menschlichen Glücks verbunden sein soll, einen entsprechenden Zuwachs an Weisheit.«
  3. Endlich tut sich mir schemenhaft ein Erklärungsansatz für die epochemachenden Glanzleistungen der T-Systems auf.

Und ansonsten halte ich mich bei der Softwareentwicklung zukünftig wieder an eine Empfehlung von Eberhard v. Kuenheim:

„In großer Höhe fliegt der Adler besser allein“.

hb

Roland Dürre
Sonntag, der 6. Dezember 2015

Was ich nicht mag #34 – Lobbyismus, Marketing und ihre Verbände.

Im letzten Artikel habe ich versucht, meinen Pessimismus zu Best Practice, Methoden, Prozessen, Normierung, Zertifizierung usw. zu formulieren.

bild02791Daran muss ich denken, weil ich im ICE sitze, Hunger habe und trotzdem den per Durchsage im „Bordbistro“ angepriesenen Spaghetti Bolognese tapfer widerstehe. Und das, obwohl ich Spaghetti Bolognese sehr mag, aber eben nicht als „convenient food“.

Besonders, wenn diese heute bundesweit in allen ICEs auf deutschen Schienen angepriesen und serviert werden. Hergestellt und verteilt im Rahmen eines  optimierten und präzise abgearbeiteten Prozess. Mit viel Plastik als Prozessmittel.

Die Erinnerung, wie gut ich vor ein paar Jahren (2009)  in einem rumänischen Speisewagen „gespeist“ habe (im wahrsten Sinn des Wortes), macht es noch schlimmer. Es gab zwar „nur“ Fleisch, Gemüse und Kartoffeln, aber alles so richtig frisch auf dem Gasherd zubereitet. Köstlich. Bei mir kommt Bedauern auf, dass das alles vorbei ist.

Jetzt überlege ich mir, wer diese Entwicklung verursacht hat. Weg von individueller Qualität hin zum gesicherten und sterilen Mittelmaß. Sicher hat die Industrie ihre Mitschuld. Aber auch die Konsumenten haben das kräftig mit ihrem „Geiz ist geil“ befördert.

Aber ich wollte ja über Vereine schreiben. Wegen meinem Ärger, dass es „freie“ Vereine gibt, die diesen Unsinn der Normierung und Zertifizierung in der Welt auch noch befördern. Und jeden „Sch….“ auditieren“ und die angebliche Fähigkeit, diesen „Sch….“ anzuwenden, auch noch für teures Geld zertifizieren.

Aber gehen wir eine Ebene höher in die Welt der Vereine und Verbände. Deutschland ist ja so etwas wie das Land der Vereinsmeierei. Fairerweise muss gesagt werden, dass Vereine sehr unterschiedlich sind und verschiedene Zwecke haben können. Da gibt es NGOs, die in meiner Bewertung sich wie eine Trutzburg durch die Zeit erhalten haben. Dazu rechne ich AI (Amnesty International). Das sind aber in meiner Beobachtung nur ganz wenige. Zu stark ist die Kraft der Korruption, die vieles in den Sumpf oder zumindest in die Mittelmäßigkeit zieht.

Manche Vereine sind mit „edlen“ Motiven gestartet und haben sich zum mächtigen, bürokratisch-kommerziellen System entwickelt. Sofern sie trotzdem immer noch einen wertvollen Beitrag für die Gesellschaft bringen, finde ich das zwar nicht optimal aber zumindest irgendwie in Ordnung. Da denke ich z.B. an das Rote Kreuz, Green Peace, BND (Bund Naturschutz – nicht den anderen, der ja auch gar kein Verein ist) und ähnliche Organisationen.

Es gibt auch Vereine, die für eine Verbesserung in ganz konkreten, auch wirtschaftlichen Bereichen gegründet worden sind, wie der Verein für die Einführung von Normen (DIN). Andere wollten differenziert sozial wirken wollen und konkrete gesellschaftliche Probleme angehen, die der Staat nicht zu lösen schafft . Die finde ich auch OK, solange sie ihrem Auftrag treu bleiben.

Sportvereine sind eine weitere und besondere Kategorie. Sie sind gegründet worden, um eine besondere oder neue Tätigkeit (Sportart?) in Gemeinschaft ausüben zu können. Und das ist doch schön. So ist mir ein Sportverein zum Beispiel für Breitensport lieber als ein Unternehmen, dass seine Fitness-Studios strategisch wie beim Monopoly-Spiel ausbreitet.

Da alle Vereine – wie auch die Unternehmen – soziale Systeme sind, unterliegen sie den normalen Regeln der Entwicklung von Systemen. Oft verlassen sie im Lauf der Zeit die idealistischen Prinzipien der Gründer. Das ist ganz normal. Der Erhalt des eigenen System wird oft (fast ist die Regel) zum Hauptziel des Vereins.

An Stelle des von den Gründern ersonnenen Zwecks wird das Überleben des Systems zum Selbstzweck. Das gepaart mit „systemische“ Gier führt schnell zu (extremer) Kommerzialisierung. Hier ordne ich den Motorsport-Klub ADAC, den Alpensport-Klub Alpenverein und ähnliche Institutionen ein.

Gerade im Segment „Sport“ werden Vereine schnell zu Unternehmen der Unterhaltungsindustrie, der Logik „Brot und Spiele“ folgend. Diese entwickeln dann häufig kriminelle Dach-Organisationen. Weil es halt gigantisch viel Geld zu verdienen gibt. Und das ist immer eine Gefahr. Denn Gier dominiert oft.

Es gibt aber auch Vereine, die nicht aus idealistischen sondern „räuberischen“ Motiven gegründet worden sind. Diese haben von Anfang an nur eine einzige Aufgabe: Sie wollen (müssen) Vorteile ihren Mitgliedern Vorteile verschaffen. Um das zu erreichen, gilt es  Macht zu entwickeln. Rücksichtnahme auf das Gemeinwohl stört da nur.

So sind sie bei der Wahl der Mittel nicht zimperlich, auch Bestechung ist ein übliches Werkzeug. Solche Verbände mag ich noch weniger als die FIFA und ähnliche Verirrungen, wie sie aktuell gehäuft entdeckt werden. Übrigens zum Teil dank „Whistle-Blower“, die wir dringend brauchen.

Wir nennen diese Vereine „Lobbies“. Ihre Angestellten sind die Lobbyisten. Die üben enormen Druck auf Politik und Parlament aus, um für ihre Unternehmen oder Branchen Vorteile durchzusetzen. In der Regel ist ihnen kein Mittel heilig. Wichtig ist ihnen nur, den Auftrag ihrer Mitglieder durchzusetzen. Der heißt: Alle Hindernisse müssen aus dem Weg geschafft werden, die die Mehrung von Umsatz und Gewinn stören könnten. Und Lösungen zu organisieren, mit denen die gemachten Gewinne privatisiert und die ab und zu nicht vermeidbaren Verluste sozialisiert werden können. Da darf es nur ein Bäh geben!

Ich meine:
Der Lobbyismus ist eine der beiden großen Gefahren für die Demokratie. Die andere ist das sogenannte Marketing – für mich die Industrie der Katzengoldverkäufer und Glückseinflüsterer. Die Marketing-Industrie hat ein einfaches Motto „Kauf Dich glücklich!“. Das wird mit filigranen Methoden und Techniken zur Manipulation von Menschen verkündet. So wird die persönliche Entwicklung eines autonomen und selbstverantwortetem Leben (das nennt man Freiheit) zumindest erschwert wenn nicht unmöglich gemacht.

Wahrscheinlich wäre die Welt ein wenig lebenswerter ohne Lobbyismus und Marketing. Aber irgendwie stehen wir dem ganzen so absolut hilflos gegenüber.

RMD

Roland Dürre
Samstag, der 28. November 2015

PM Camp Dornbirn – zwischen Anspruch und Realität?

pmcamp-logo-dornbirnDas PM-Camp in Dornbirn 2015 war auch im Rückblick recht gelungen. Die meisten (eigentlich alle) Teilnehmer haben sich sehr wohl gefühlt und sind hoch zufrieden nach Hause gefahren. Das finde ich toll.

Viele Teilnehmer haben auch unseren Rückmeldebogen genutzt. So haben uns (das Orga-Team) viele konstruktive Rückmeldungen erreicht. Die arbeite ich gerade durch, so wie auch die Twitter-„Timeline“ zu unserer Unkonferenz. Die „Timeline“ kann man unter dem Hashtag #PMCampDOR nachlesen. Was übrigens viel Spaß macht, es ist eine Retrospektive mit vielen nützlichen Links entstanden.

Das Feedback war statistisch wie in den Einzeläußerungen sehr positiv. Das hat dem Orga-Team gut getan. Barcamps sind etwas Besonderes. Sie basieren auf Freiheit, Augenhöhe, Partizipation, Gleichberechtigung. Das kann man auch als „Schwächen“ sehen. Allerdings Schwächen, die mir persönlich sehr gut gefallen. Ein Barcamp lebt aus dem Augenblick. Man kann es nicht steuern, die „Sitzungen“ (Sessions) entstehen im Kontext zum gerade Erlebten. So soll es sein. Und das ist gut so!

Anders gesagt:
Freiheit und Verschiedenheit können auch polarisieren. Es entstehen Schwerpunkte und Annahmen, die nicht immer jedem gefallen. Das muss man aushalten können, so wie auch Freiheit nicht immer leicht zu ertragen ist. Die Toleranz braucht.

Auch die Demokratie hat ihre problematische Seite. Die äußert sich schon in der Frage, wie man Demokratie am besten organisiert? Ich denke an die leidenschaftliche Diskussion  von „direkter Demokratie versus parlamentarischer“ – die eine gilt als die Lösung (wie in der Schweiz) und wird auch als hochgefährlich eingestuft wird (wie bei uns, weil wir glauben, dass das Volk so dumm ist). Und auf der anderen Seite sind viele mit unserer „parlamentarischen Demokratie“ gar nicht mehr glücklich.

Unkonferenzen sind demokratisch. Sie leben ganz besonders von den Menschen, die teil nehmen. Man trifft sich – im Unterschied zu Konferenzen – in einem relativ freien und nur wenig formatierten Raum. So können sich gruppendynamische Entwicklungen ergeben, die nicht jedermann gefallen. Aber jeder hat auch die Möglichkeit, dagegen zu steuern.

PM-Camps sind sehr pluralistische Treffen. Es trifft sich männlich und weiblich, alt und jung, Berufseinsteiger und -aussteiger, erfolgreiche und weniger erfolgreiche, Studierte und welche dies gelernt haben, ernste und lustige Menschen, „nicht so wohlhabende“ und „reiche“ usw. Vielleicht können solche Barcamps ein wenig den Spagat zwischen ICH und WIR schaffen und die Spannung zwischen „individuellen“ und „kollektiven“ Bedürfnissen lösen.

Und wie für Projekte gilt, dass Technologie und Werkzeuge nicht mehr das Problem sind. Auch die vorhandenen Methoden taugen in der Regel mehr oder weniger. Die meisten Projekte scheitern jedoch, weil es „menschelt“. Das ist auch die Gefahr bei barcamps. Man kann nicht allen alles recht machen. So wurden in Tweets wie in den Feedback-Bögen manche Details gleichzeitig sehr gelobt und kritisiert.

Neben den positiven Rückmeldungen gab es auch Kritik und Vorschläge für Verbesserungen. Die Verbesserungsvorschläge werden wir – soweit sie nicht den Prinzipien der Freiheit des Barcamps widersprechen – sehr ernst nehmen. Genauso wie wir uns die Kritik zu Herzen nehmen werden. Allerdings könnte man auch sagen:
Bei einem Barcamp ist manche Kritik des Teilnehmers auch Kritik an sich selber.

Ich liste mal ein paar der Rückmeldungen auf und kommentiere sie:

Positives Feedback:

Die positiven Rückmeldungen sind die große Mehrheit. Obwohl es Spaß machen würde, hier alle zu zitieren, erwähne ich nur ein paar:

Wenn es das PMCamp noch nicht gäbe, müsste man es erfinden!!

Ich komme wieder!

Ich konnte sehr viele Erkenntnisse mitnehmen, Erfahrungen und sehr interessante Bekanntschaften machen!

Weiter so, nicht regulieren!

Die Atmosphäre war sehr vertraut und angenehm, die Gespräche haben auf Augenhöhe stattgefunden!

Da könnte ich so weiter machen – und ganz oft gab es ein

Großes Dankeschön!

und 100 % haben die Frage:

„Würdest Du das PM Camp einem Kollegen / einer Kollegin weiter empfehlen?“

mit JA beantwortet.

Darüber haben wir uns natürlich sehr gefreut. Alle positiven Rückmeldungen werten wir im Orga-Team gewissenhaft aus. Gilt doch für Gemeinschaften, wie für Menschen bei der „Persönlichkeits-Entwicklung“ (oft auch Management oder Führungs-Training genannt), dass man zu erst mal seine Stärken fördern soll und nicht immer versuchen soll, die Schwächen abzubauen. Weil das Zweite meistens eh nicht gelingt und das Erste so viel mehr bringt. So wollen wir auch gerade das, was schon gut ist, noch besser machen.

Ich habe aber auch Beispiele von

negativem Feedback:

das WLAN auf dem Camp war eine Katastrophe …

Ja, das war so. Ich weiß aber, wie sehr sich gerade Stefan im Vorfeld und während der Veranstaltung bemüht hat, an der Uni für eine Verbesserung der Situation zu sorgen. Ich hatte am Vorabend auch noch einen Dialog mit einem der Spezialisten, der mir die Problematik klar machte. An der Uni wurden auch Anstrengungen unternommen, aber sie haben es halt wieder nicht geschafft. Aufgrund hoch komplizierter Sicherheitsaspekte sind die Systeme so aufgesetzt, dass die Techniker es nicht hinkriegen. Natürlich werden wir im nächsten Jahr versuchen, das Thema besser hinzukriegen. Wir sollten aber auch wertschätzen, wie viel die Fachhochschule Dornbirn als Sponsor für uns tut und da ein wenig gnädig sein.

Info zu Parkmöglichkeiten fehlte!
Ja – die lieben Autofahrer 🙂 .

Präzisere Ankündigung der Veranstaltung (Beginn, Ende) auf der Website.
Das kann man natürlich verbessern.

Fotos der Sessiongeber helfen bei der Orientierung.
Leider war „Aebby“ (Eberhard Huber) kurzfristig verhindert, so blieb auch seine Polaroid-Kamera in Baden-Württemberg.

Zu
Ice-Breaking, Moderation und Vorstellungsrunde
waren die Kritiken/Vorschläge sehr gegensätzlich. Die einen wollten eine Vorstellungsrunde, die andern keine. Die einen mehr, die anderen weniger Moderation und/oder „ice-breaking. Ich würde sagen, das war so fifty/fifty.

Viele Gedanken und Verbesserungsvorschläge in den Feedback-Bögen drehen sich um
„Newbees“ und „Klassentreffen von alten PM-Camp’lern) und wie man die Qualitätsverbesserungen von Sessions zum Beispiel durch Coaching-, Mentoring- oder Moderationsangebote erreichen kann.
Eine leichte Mehrheit hat hier eine explizite Unterstützung für Newbees gewünscht, der Rest meinte, dass dies ganz gut „automatisch“ gelungen wäre. Ich meinte auch herauszulesen, dass bei kleineren PM-Camps wie in Barcelona besser gelingt als bei so großen wie in Dornbirn. Also fast indirekt eine Kritik, dass Dornbirn zu groß wird.

Kritik wurde auch an einzelnen Sessions und dem Angebot von Sessions geübt.

Die Sessions waren zu IT-lastig.

Vermisst habe ich die Spiele.

Die Sessions des zweiten Tages sollten mehr auf denen vom Vortag aufbauen.

Prinzip und die Varianten von Sessions sollte im Vorfeld gerade für die „newbees“ besser erklärt werden.

Alles, das den Rahmen für die Sessions verbessert, unterstütze ich. Ich meine aber, dass die Organisatoren sich nicht in den Inhalt der Sessions einmischen sollten. Die gehören den „Teil-Gebern“. Die Organisatoren haben die Chance, durch formulieren des Mottos und Auswahl der Impulsgeber im Vorfeld die Menschen, die an diesen Botschaften interessiert sind oder sich daran reiben wollen zum Kommen zu motivieren. Und das sollte genügen.

Auch Herausforderungen für die Zukunft wurden genannt, hier hat mir eine besonders gut gefallen:

Das hohe Niveau zu halten wird DIE Herausforderung der Zukunft sein.

Das sehe ich auch so!

Nebenbei: Auch im offiziellen Blog der GPM gab es neben (zu) viel Lob einiges an Kritik fürs PM-Camp Dornbirn. Dort hat Reinhard Wagner in einem post vom PM-Camp in Dornbirn berichtet und sich im letzten Absatz doch recht negativ geäußert (… Anspruch konnte das PM Camp nur bedingt gerecht werden. …).
Weil ich hier eine Reihe von Missverständnissen sehe und ich auch persönlich erwähnt wurde, habe ich mich im folgenden mit den Aussagen von Reinhard „dialektisch“ auseinandergesetzt und versuche hier ein paar Dinge richtig stellen.


Hier geht es los mit dem Text des letzten Absatzes von Reinhard im GPM-Blog. Die kursiven Teile sind zusammen der komplette letzte Absatz, den ich 1:1 aus dem Post von Reinhard (RW) kopiert habe. Dahinter mit „normalem“ Font stehen immer meine Kommentare (RMD), so also immer abwechselnd.

(RW) … Das Motto des diesjährigen PM Camp Dornbirn war „Musterbrechen“ (Welche Muster sollten wir im PM brechen und wie kann der Musterbruch gelingen?). Diesem Anspruch konnte das PM Camp nur bedingt gerecht werden. Dies ist aus meiner Sicht auch das Dilemma der gesamten „PM Camp“-Bewegung.
(RMD) Nicht nur das PM-Camp sondern die ganze menschliche Gemeinschaft hat dieses Dilemma, dass Veränderung nicht in dem Masse  gelingt wie dies notwendig oder zumindest wünschenswert wäre. Das belegt die aktuelle Geschichte (Kriege, Terrorismus, Zerstörung des Planeten …).
Mein Problem mit den Sätzen von Reinhard ist, dass ich als Anspruch eines PM-Camps eigentlich nur sehe, a) ein guter Gastgeber zu sein und b) die „richtigen Teilgeber“ zu finden. Das ist auch das Ziel des Orga-Team Dornbirn für „unser“ PM-Camp. Und wie ich meine auch der der gesamten „PM-Camp-Bewegung“.
Jedes Jahr besprechen wir im PM-Forum (unser strategisches Organ aller PM-Camps), wie wir das am besten hinkriegen. Da treffen sich die Vertreter der regionalen Orga-Teams (die operativen Veranstalter, die die Camps machen) und des Kern-Teams (die normative Ebene der Gründer). In dieser Klausur tauschen wir aus, wie wir es besser machen können, dass Ihr – unsere Gäste und Besucher – noch besser Wissen austauschen, Konsens finden und Erkenntnis gewinnen könnt.
Das Orga-Team eines PM-Camps hat vor allem die Rolle des Gastgebers. Es sucht Sponsoren und finanziert so gemeinsam mit den Beiträgen der Teilnehmer/Teilgeber die Veranstaltung. Ergänzend versuchen wir durch gedankliche Anregungen (im Vorfeld ein Motto wie zum Beispiel die Metapher des „Musterbrechen“) und auf dem Camp durch Impulsvorträge (das Was) und Vorschläge zur Methodik (das Wie) das Gelingen zu fördern, ohne aber den Kern eines barcamps zu gefährden. Wir sind achtsam bemüht, dass nicht klammheimlich aus der „Unkonferenz“ eine Konferenz oder Kongress wird.
Zur Erinnerung:
Ein PM-Camp ist nichts anderes als ein Barcamp, dass sich besonders an Projekt Manager, Manager, Unternehmer, Führungskräfte richtet, eigentlich an alle Menschen, die bereit sind Verantwortung für Zukunft zu übernehmen. Es gibt diesen eine Plattform zum Austausch und unterstützt so die Vernetzung.

(RW) Die „jungen Wilden“ (sorry Roland Dürre) wollen sich „krampfhaft“ von den etablierten Größen der Branchen, allen voran die GPM, das PMI oder die PRINCE2-Community abgrenzen.
(RMD) Zu den jungen Wilden: Da sehe ich mich ja nicht mehr ganz so. Mit dieser Metapher habe ich manch jungen start-up gemeint. Die legen schon ganz anders los, als ich es von „etablierten Unternehmen“ gewohnt bin. Und wenn ein Start up mal so richtig Erfolg hat, dann ganz gewiss nicht, weil er in Projekten denkt.
Aber zurück zum Text: Allein schon die Wortwahl „etablierte Größen der Branche“ zeigt die problematische Positionierung von Reinhard. Ich sehe die „PM-Camp-Bewegung“ in keiner Rivalität mit „etablierten Größen der Branche“. Denn wir sind eben kein Verband. Wenn, dann sind wir eine Alternative für die, die sich in einem freien Rahmen treffen wollen, um Wissen und Erfahrung auszutauschen. Auf einem PM-Camp regt man sich gegenseitig zum Nachdenken an. Da treffen sich die ICHs „als Teil vom“ WIR. Das hat nichts mit einem Verband oder ähnlichen Strukturen zu tun. Auch deshalb darf und wird das Orga-Team keine proaktive Empfehlungen geben.
Die „PM-Camp-Bewegung steht übrigens in enger Abstimmung mit openPM, dem offenen Portal mit Plattform zum freien Austausch für alle Projekt Manager. openPM ist ein gemeinnütziger Verein, den ich auch nicht in Rivalität zu den „etablierten Größen“ sehe. So hat auch openPM nichts mit den genannten Vereinen/Verbänden zu tun.
Ich persönlich hüte mich deshalb vor Vereinen und Verbänden, weil in meiner Wahrnehmung diese sich oft im Besitz der „Wahrheit“ wähnen, diese in „Gesetz- und Regelbücher“ fest schreiben und und dann Lehren und so ihr (vieles) Geld verdienen. Da grenze ich mich ab, aber nicht krampfhaft sondern einfach eindeutig im Sinne von klar.

(RW) Das Muster „agil“ versus „traditionell“ wird allzu oft bemüht. In fast allen Diskussionen wird immer wieder der Vergleich „Industriezeitalter ist alt und schlecht“ versus „Informationszeitalter ist jung und gut“ bemüht, das gleiche wird auf „Wasserfall“ versus „Scrum“ usw. übertragen.
(RMD) Hier hat Reinhard wohl etwas falsch verstanden. Mag sein, dass es da vor Jahren Fronten gab. Um diesen Unsinn zu beenden, starteten wir in 2011 in Dornbirn ein PM-Camp mit dem Motto „Brücken bauen“.
So habe ich auf dem PM-Camp in Dornbirn kaum Konflikte „agil“ versus „traditionell“ oder ähnlich wahrgenommen. Im Gegenteil, alle die ich gehört habe – auch die Impulsgeber – haben betont, dass alles seine Rechtfertigung hat, man sich nur gut überlegen muss, was man wann und für welchen Zweck einsetzt.
Ich meine eh, dass zu „agil“ alles was wichtig ist im „agile manifesto“ geschrieben wurde. Das, was dort steht, ist eine Empfehlung, den „gesunden Menschenverstand“ in „Redlichkeit“ zu nutzen. Und das ist doch keine Methode? Sondern eigentlich eine Selbstverständlichkeit. Genauso wie, dass man in Projekten viel falsch machen kann.

(RW) Ein Vortrag sprach sich gegen alle Regeln und „Muster“ aus und propagiert ein paar Folien weiter, dass man ja keine Projekte machen solle (#noprojects).
(RMD) Wenn hier der Impuls von Robert Weisgräber gemeint war, so war das einer der besten Vorträge, die ich seit langem gehört habe. Auch die Rückmelde-Statistik belegt dies. Aber vielleicht ist die Metapher von #noprojects nicht ganz so einfach zu verstehen. Dass man keine Projekte machen soll, habe ich so aber nicht raus gehört. Viel mehr, dass man sich gut überlegen soll, was man tut.

(RW) In einem Workshop zur „Lebendigkeit von Organisationen“ wird versucht, die Wirkmechanismen einer solchen Organisation aufzuzeigen. Auf meine Frage, ob wir das mal am Beispiel der – leider sehr erfolgreichen – Organisation des Islamischen Staates aufzeigen können wird dies brüsk abgelehnt mit dem (Totschlags-)Argument, das passe jetzt gar nicht hier rein.
(RMD) 
Natürlich können Aussagen in Sitzungen nicht immer allen Teilnehmern gefallen. Das hat etwas mit Demokratie zu tun. Ich halte es aber auch für nicht zielführend, die IS als sinnvolles Fallbeispiel zu diskutieren. Nicht nur, weil das mir die IS eine kriminelle faschistische Organisation zu sein scheint (Auch das dritte Reich war faschistisch. Und trotzdem hat der „GröFaZ“ mit agiler Kriegsführung der etablierten Generalissima das Fürchten beigebracht).
Aber natürlich hätte Reinhard Wagner eine eigene Session zu IS machen können oder vielleicht präziser formuliert zum Thema „Moderner Guerillakrieg von faschistoiden Organisationen als erfolgreiche Methode im Kampf gegen militär-technisch überlegene Armeen“. Die hätte ich allerdings nicht besucht (oder wenn, dann nur um mein Unverständnis auszusprechen).

(RW) Schließlich versuchte ein Teilnehmer, das Cynefin-Framework zu diskutieren. Diese endete dann mit der Einteilung, dass alle Ingenieure und Betriebswirtschaftler auf der rechten Seite zu verorten seien (simple oder komplizierte Systeme), wohingegen die Software-Entwickler die kreativen Wilden, also auf der linken Seite des Frameworks zu finden sind. Das bringt natürlich keinen wirklich weiter.
(RMD) 
Auch hier geht es um den Inhalt einer Session. Das hat nichts mit dem PM-Camp Dornbirn zu tun. Ich sehe es persönlich aber ähnlich wie Reinhard Wagner und halte die ganze Diskussionen zu kompliziert/komplex, links/rechts, blau/rot mehr oder wenig für esoterischen Humbug. Wobei man aus falschen Annahmen und falschen Schlüssen durchaus richtiges ableiten kann …

(RW) Statt Muster zu brechen, werden alte Klischees in ein neues Gewand gepackt.
(RMD) 
Den Satz verstehe ich nicht. Aber das pauschal vom PM-Camp Dornbirn zu behaupten empfinde ich schon als starken Tobak. Mir klingt diese irgendwie nach Kulturpessimismus. Ich gestehe aber zu, dass unsere Gesellschaft daran leidet, dass wir immer wieder die alten Muster bemühen. Und Phantasie und Kreativität eher verdrängen. Vielleicht führen hier Reinhard und ich dieselbe Klage.

(RW) Schließlich stellt sich mir die Frage, was die PM Camps mit ihrem Anspruch in der Praxis erreichen wollen.
(RMD) 
Nochmal: PM-Camps bieten einen Rahmen, der es den Menschen ermöglichen soll, sich zu treffen, im Vertrauen zu kommunizieren, Wissen zu teilen, Erkenntnis im redlichen Diskurs zu gewinnen. Es gibt keinen Zweck-Anspruch von Seite der Organisatoren des Camps. Wenn dann geht es darum, dass die Menschen, die kommen, sich gegenseitig größer machen – und eben nicht kleiner wie in vielen Lehrsystemen. Ich gehe aber davon aus, dass „Wissen teilen“ und vom „Gegenüber“ zu lernen für die Praxis meistens wertvoller sind als der Erwerb von Zertifikaten oder schlimmer die „Zertifizierung der Welt“.

(RW) Auf meinen Workshop-Impuls zu „Projektmanagement für soziale Zwecke“ gab es zwar viel Diskussion und begeisterte Redebeiträge, …
(RMD) Frage: „Was ist ein begeisterter Redebeitrag?“! 🙂

(RW) … auf meine Frage, wer nun was konkret machen will, waren alle ziemlich schnell (zum Mittagessen) verschwunden.
(RMD) 
Ist doch sinnvoll. Dazu hätte man ja den zweiten Tag für konkrete Sessions dazu nutzen können._

(RW) Zugegeben, es ist auch bei der GPM ziemlich schwer, die Mitglieder zur Umsetzung des Besprochenen zu bewegen.
(RMD) 
Ich wüsste nicht, warum es bei der GPM einfacher sein sollte als im täglichen Leben.

(RW) Hier erweist sich allerdings, ob es bei „Sonntagsreden“ bleibt, oder den „schönen Worten“ auch konkrete Taten folgen.
(RMD) Schon Seneca hat gesagt „Philosophie heißt nicht Reden sondern handeln“. Und das wir alle viel reden und nichts tuen sehen wir ja nicht nur bei der Veränderung des Klimas durch die Verbrennung von fossilen Brennstoffen. Aber auch hier entdecke ich eine Gemeinsamkeit mit Reinhard.

(RW) Das würde ich mir wünschen, aber vielleicht bleibt das auch nur ein frommer Wunsch zu Weihnachten 🙂
(RMD) Mein (weiß nicht ob frommer) Wunsch nicht nur zu Weihnachten ist, dass die Menschheit ein wenig weiser werden würde.


Auch wenn ich viel Gegenrede halte, möchte ich mich bei Reinhard explizit für seinen Artikel bedanken. Vielleicht ist das ein Beginn für eine leidenschaftliche und wunderbare Diskussion zur Frage:
Wie viel Verbände und Vereine brauchen wir wirklich?
Weil mir da eine ganze Reihe für überflüssig erscheinen und ich mir mehr von Graswurzelbewegungen erwarte.

RMD

P.S.
Die Überschrift dieses Posts ist nicht von mir, sondern vom post vom Reinhard übernommen.

CLOU/HIT in der InterFace Connection

Oder:

Wie Wolf und ich es dann selber machten.

Beim PM-Camp Berlin habe ich von vier Projekten aus der Vintage Zeit berichtet, die für mich sehr wichtig waren. Und hier angekündigt, dass ich alle vier auch in IF-Blog beschreiben werde.

if-logoProjekt 4

Jetzt kommt die Geschichte zum vierten Projekt:

Schon vor 1983 hatte ich keine Lust mehr, für andere zu arbeiten. Ich war damals noch bei Softlab. Dort konnte ich mein einseitiges Wissen – es bestand bis auf ein wenig SNA (IBM) überwiegend aus Siemens-Technologie – erweitern und lernte weitere IBM-Technologien aber vor allem auch die Technik von verschiedenen Systemen der „Mittleren Datentechnik“ kennen.

Das waren Maschinen, die je nach Speicherausbau aus zwei bis drei Teilen groß wie Bosch-Kühlschränke bestanden. Also viel kleiner und auch einfacher als Mainframe. Die waren damals groß in Mode und so gab es zuhauf europäische und nicht-europäische Wettbewerber mit mit unterschiedlicher und oft sehr proprietärer Technik. Kienzle und Nixdorf waren bei diesen aufstrebenden MDT-Unternehmen auch dabei und damals wurde allein in einer Stadt wie München ein und dieselbe Branchen-Software von verschiedenen Unternehmen parallel für verschiedene Technologien entwickelt.

Softlab war mit Sicherheit damals eines der innovativsten deutschen „Software-Häuser“. Sie hatten auch ein proprietäres System, das berühmte PET-Maestro. Für mich war das das erste System ohne den Frust des permanenten Datenverlusts, den das Pet-Maestro arbeitete auch schon zeichenweise – und jedes Zeichen wurde sofort auf die Platte geschrieben. Bei Reset erfolgte so immer ein aktueller Warmstart – und nichts war futsch! Es war eine Erlösung, das Zittern vor Datenverlust beim Arbeiten zum Beispiel mit EDT oder EDOR war vorbei.

Auch sonst lernte ich bei Softlab viel Neues. Aber auch im kaufmännischen Bereich: Wie man Angebote möglichst risikofrei formuliert, wie man mit den VB’s der großen Unternehmen (Bull, ICL, IBM, Nixdorf, Siemens) klüngelt (ohne die großen ging es damals schon nicht) oder – und wie man Studien schreibt. So wurde ich zum Papiertiger (das hat nichts mit paper tiger, der namhaften freien chinesischen Theaterbewegung zu tun). Und damals war es schon so, dass man als Papiertiger (noch) bessere Stundensätze bekam denn als Programmierer. So weiter gestärkt, wollte ich es selber machen. Alleine traute ich mich nicht. Also ging ich auf Partnersuche. In meinen Kreisen suchte und identifizierte ich Menschen, die mir sympathisch und fähig vorkamen. Und die vielleicht auch gründen wollten. Da gab es einige. Aber immer wieder klappte es nicht.

Bis der Wolf (Geldmacher) kam. Wolf war deutlich jünger als ich. Er war fachlich Spitze. Und wir sahen die Dinge ähnlich. Das soll heißen, dass sich unsere Werte, Erwartung, Interessen und Bedürfnisse gegenseitig sehr gut ergänzt haben. Ich war so mehr der Old-Style-Programmierer – und der Wolf hatte die Ahnung, von allem was in der IT modern und neu war. Und Wolf war absolut der Qualität verpflichtet. Und wenn einer Menschenverstand hatte, dann war es der Wolf. Und das sind wohl die wichtigsten Dinge: Fachliche Ahnung, Menschenverstand und Qualitätsbewusstsein. Dann muss man nur noch ein netter Kerl sein …

So gründeten wir in Kurzform die InterFace Connection. Die InterFace hat Peter Schnupp auf uns vererbt, die „Connection“ war unser Begriff. Das wollten wir gemeinsam mit unseren zukünftigen Mitarbeitern sein, eine „Connection“, die zusammen hält und gemeinsam erfolgreich wird. So gründeten wir 1983 das Unternehmen und starteten am 1. April 1984 das Geschäft.

Das Projekt von dem ich berichte, ist aber nicht das Unternehmen, sondern die Entwicklung unseres Produkts. Und ein Produkt wollten Wolf und ich aus zwei Gründen haben: Zum einen waren wir überzeugt, dass ein Produkt etwas ist, auf das man stolz sein kann. Dass ein Produkt eine Identität schafft. Und dass ein Produkt besser skalierbar ist, als Dienstleistung.

Außerdem gaben wir dem damals sehr gut funktionierenden „Body Leasing“ keine Zukunft. Wir glaubten nämlich noch an die Gesetze, und uns war als Gründer ziemlich klar, dass die übliche Form von Body Leasing genau das schon damals war, das dem AÜG folgend ganz einfach ungesetzlich war.

Schnell war uns klar, dass damals Unix die richtige Basis für zukünftige Produkte wäre. Wir waren uns auch rasch einig, dass ein auf Unix so ziemlich alles fehlte, was man für die Nutzung von Rechnern bei Unternehmen bräuchte. Und dass da ganz besonders ein Textsystem fehlen würde. Und dass man auf Unix mit seinen neuen Datensichtgeräten (im raw oder cooked mode) und gerade mit der Sprache c zuerst mal eine komfortable Schreibmaschine relativ zügig entwickeln können müsse.

Weil wir vor der Herstellung und dem erfolgreichen Vermarkten eines Produktes großen Respekt hatten, begannen wir die Entwicklung des Produktes in Kooporation mit InterFace Computer. Wir hatten sehr schnell einen kleinen Erfolg im Umfeld von SINIX (dem Unix von Siemens) und so verlagerte sich die Entwicklung zu uns und InterFace Computer übernahm die Portierungen wie auch den Vertrieb im „Restmarkt“.

Und wir hatten ganz schnell ein zweistelliges Team von ganz jungen Leuten. Das waren in der Regel Studenten. Sie mussten programmieren können und sympathisch sein. Und trotz der Doppelbelastung Arbeit und Studium zweiteres durchziehen. Alles andere war uns egal.

Da Wolf und ich (gemeinsam mit ein paar jungen fest angestellten Informatikern mit akademischen Abschluss durch besagtes Bodyleasing (mit Stundensätzen zwischen 150 – 120 DM) die Entwicklung finanzierten, waren die jungen Menschen ziemlich frei. Gesteuert wurden sie von unserer „Assistentin“ Heidi (Kaindl). Die Heidi hatte die Jungs gut im Griff und passte gut auf, dass die auch arbeiteten. Wolf und ich waren nur in kurzen Meetings mit den Jungens zusammen (bald nach der Gründung kamen dann auch Frauen dazu).

Der Wolf hatte damals die Rolle eines SCRUM-Masters und mehr (obwohl es damals SCRUN noch lange nicht gab. Er erklärte dem Team, was Qualität wäre. Und dass sie die Qualität eben nicht für unsere Endkunden, nicht für unsere Vertriebspartner für Siemens und auch nicht für die InterFace Connection machen würden, sondern zuerst mal als ehrliche Programmierer für sich. Und Wolf hatte hohe Ansprüche und war streng. Wenn jemand nicht fähig oder willens war, die Qualität zu bringen, gab es keine Zukunft bei der „Connection“. Wolf beschützte aber auch das Team, wenn z.B. ich auf Ressourcen spechtete. Und setzte auch die notwendigen Investitionen durch.

Meine Aufgabe war vielleicht die des Product Owners. Zumindest am Anfang. Ich musste als Jugendlicher Stenographie und Schreibmaschine schreiben lernen. Stenographie habe ich geliebt, es ist eine wunderschöne Art zu schreiben. Weil es nicht gegen die Hand geht, wie die normale Schreibschrift. Aber die Schreibmaschine haßte ich. Und ich wusste genau, wie eine gute Editier-Maschine aussehen musste. Das hatte ich dann auch in Gründerzeiten aufgeschrieben.

Wie es komplizierter wurde und z.B. CLOU mit seiner „embedded sql“ dazu kam, gab ich die Rolle des Product-Owners an unsere Kunden ab. Und das war eine der besten Entscheidungen meines Lebens. Denn die Kunden konnten uns tatsächlich sagen, wie sic sich eine automatisierte Bausteinverarbeitung vorstellten. Und haben uns den weiteren Weg gewiesen.

Eine Regel war, dass alle Mitarbeiter – bis auf Heidi – programmieren konnten. Die Heidi war unsere erste und wichtigste Kundin. Sobald die erste Version von HIT verfügbar waren, haben wir ihr den „vi“ und die für Bürobetrieb geschriebenen „nroff-makros“ weggenommen, und sie musste mit HIT arbeiten – sehr übrigens zu ihrem Unwillen. Den so schlecht war die vi-Lösung nicht. Später hat sie dann aber trotzdem ihren HIT lieben gelernt. Wen wundert es, sie hat ihn ja auch mit gebaut!

Alle anderen Kollegen im HIT-Team mussten „hands-on“ legen können. D.h. jeder musste programmieren, Fehler suchen und vor allem „co-working“ (Team-Arbeit) können.

Wir benutzen ganz früh Werkzeuge, lange bevor diese in den breiten Einsatz kamen. Aber nur sinnvolle wie „lint“ zur Kontrolle der Qualtitiät unseres Codes oder „sccs“ für die Source-Code-Verwaltung. Ich bin mir sicher, das wir immer wieder die ersten in München waren. Auch einen „tracker“ und automatischen „built“ hatten wir früher als fast alle anderen. Aber nie gab es eine Planungssoftware. Wie wir auch „bürocrazy“ nach Kräften mieden.

So waren alle im Projekt Programmierer. Die tatsächlich unter sich absprachen, wer was entwickelte. Es waren sehr verschiedene Typen dabei. Es gab auch den Wunderprogrammierer, nicht nur scherzhaft „Gott“ genannt. Die erste Regel war aber, dass es ein Team ist. Dass jeder für jeden da ist. Es galt immer, „einer für alle, alle für einen“. Nie wurde jemand im Stich gelassen. Und wenn man nicht mehr weiter wusste, hat man sich an seinen Kollegen gewendet. Es gab so kein explizites pair-programming, weil dies selbstverständlich war und quasi automatisch funktionierte. So gab es immer mehrere, die sich auch in den Sourcen der Kollegen aus kannten. Das war wie ein überlappendes System, das irgendwie ganz von selbst ohne viel Worte funktionierte.

Natürlich hatten wir ein komplizierte System in Entwicklung mit unheimlich vielen Modulen, Schnittstellen, Werkzeugen, APIs …. In der Summe entstand eine riesige Anzahl von lines of code. Es gab Module wie für die Virtualisierung von Keyboards, Teminals oder Drucker. Wir hatten den ersten National Language Support entwickelt, der dann in die UNIX-Implementierung von X-Open einging. Wir hatten komplizierte und gefürchtete Module und langweilige. Ab und zu mussten wir Fehler den von uns genutzten Compilern finden.

Das Team hat immer unter sich ausgemacht, wer welche Aufgabe anpackt. Unsere Werkbank – meistens aufgebaut auf OpenSource-Komponenten zur Source-Code-Verwaltung, für den Built und den teilweise automatisierten Test, für die Portierung auf die vielen Zielsysteme, die die Unix-Welt damals anbot, alles war Teil des Projekts. Das ging hin zur Produktion der im Quartals-Rhytmus erscheinenden Kundenzeitung, HITNews, von Fachliteratur, der Konzeption der Kurse. Alles wurde im Team gemacht, jeder brachte sein bestes ein.

Natürlich gab es auch gelegentlich mal Situationen, wo vielleicht der eine oder andere überfordert war. Weil er noch nicht die Erfahrung hatte oder er die Aufgabe einfach unterschätzt hatte. Aber dann hat ihm ein Kollege ihm geholfen. Immer gab es den richtigen. Und wenn es notwendig war, dann kam eben „Gott“.

Natürlich hatten wir verschiedene Rollen in den Teams. Jeder war ein Projekt Manager und für die zugesagten Termine verantwortlich. Der eine mehr, der andere weniger. Jeder war Quality Manager, der eine mehr, der andere weniger. Natürlich gab es so etwas, wie einen ersten Ansprechpartner für unsere Kunden und unsere Partner. Der wurde gemeinsam bestimmt („wer kann es am besten machen“), er ist aber als Programmierer im Team geblieben. Aber im Prinzip hat jeder Entwickler die Fragen der Kunden beantwortet. Da die einfach bei uns ins Büro rein kamen. Die zentrale Klingel erklang, Und wer zuerst ans Telefon ging, hatte den Kunden in der Leitung.

Natürlich gab es Kollegen, die sich mehr um die Integration, die Planung, die Konfiguration und Built-Thematik, das Manual … gekümmert haben. Aber alle waren immer voll fachlich im Team drin.

Aber alle haben immer weiter programmiert. Und immer für Qualität gesorgt. Zum Beispiel weil sie automatische Testumgebungen einfach als Teil des Projektes gebaut haben. Es war eine total geteilte Verantwortung.

Mit dem Erfolg haben wir Lehrer für unser Produkt HIT/CLOU gebraucht. Die ersten Jahre haben alle Entwickler unsere sämtlichen Schulungen gehalten. Sie haben genauso die Kurse für Endnutzer wie Fachanwender, Systemleute und Programmierer. Selbst die zentralen Leute wie Friedrich Lehn, der „Vater“ des CLOU, hat Kurse gehalten und Anfängern das Programmieren mit CLOU beigebracht.

Gelegentlich hat das den Entwicklern nicht gefallen. Das Entwickeln wäre doch viel wichtiger. Aber die Kurse liefen gut (weil die Kollegen eben wussten, von was sie redeten und das manche „didaktische“ Schwäche mehr als ausgeglichen hat). Das tolle war aber, dass unsere Kollegen so immer erlebt haben, was der Kunde eigentlich will und braucht! So wurde der Kunde im Gesamt zum „Product Owner“.

Die Kollegen sind aufgrund dieser interdisziplinären Aufgaben fachlich und menschlich in einem enormen Tempo gewachsen – menschlich wie fachlich aber auch vertrieblich. Es war oft unglaublich, wie junge Studenten schon innerhalb wenigen Monaten zu selbstbewussten Experten wurden.

Ohne es zu formulieren, hatten wir schon damals im Team verstanden, dass es darum geht, alle Menschen im Team und im Unternehmen größer und nicht kleiner zu machen. Und an allen Dingen zu beteiligen und partizipieren. Wir haben gewusst, dass wir uns sehr hohe Ziele, oft kühne Ziele setzen mussten, sonst hätten wir das Produkt nie gestemmt. Aber uns war auch klar, wie wichtig es gerade dann ist, eine starke Fehlertoleranz zu leben. Dass nie der Kollege im Team oder der Kunde der Feind oder Gegner sein darf, sondern nur die zu lösende Herausforderung oder die Widrigkeit der Umstände.

Wolf und ich waren das „Management“. Wir waren aber mehr wie Besucher in unserem Unternehmen. Nach 8 – 10 Stunden am Tag Beratungszeit beim Kunden haben wir uns bei unseren „Mitarbeitern“ zu Hause im Büro ausgeruht. Die waren alle unsere Freunde, da haben wir uns wohl gefühlt. Und die Kollegen haben uns gezeigt, was sie wieder alles tolles geschaffen hatten. Wir haben unsere Rückmeldungen gegeben und sind dann wieder in den nächsten Beratungstag verschwunden.

Und immer wenn wieder ein schönes Ergebnis erreicht wurde, haben wir alle gemeinsam gefeiert. Es war die schönste Zeit meines Lebens. Wir haben damals soviel gelernt. Auch wie oft das normale und konservative Denken Blödsinn ist. Zum Beispiel wollte ich unseren Kunden immer Termintreue bieten. Und musste Lernen, dass das Unsinn war.

Denn wenn Du wirklich Innovatives schaffen willst, lernst Du immer wieder, dass Termine keinen Sinn machen. Es funktioniert einfach nicht. Wenn der Termin einfach nicht gehalten werden kann, dann geht es nur darum, dass die Kommunikation klappt und man Lösungen findet, wie man den Bedürfnissen der Kunden gerecht wird. Denn wenn alle an einem Strick ziehen und gemeinsam erfolgreich sein wollen, gibt es immer eine Lösung – und siehe da, es geht immer.

Ich höre schon die Einrede:
Na ja das mag ja bei einem kleinen Projekt gehen? Aber bei einem großen?

Klar waren wir eher weniger als 50 Menschen. Aber genau die gleichen Projekt sind nicht nur bei einem Großkonzern gescheitert. Dort wurden dann oft fünf mal so viele oder noch mehr Menschen eingesetzt. Teure, erfahrene, hochqualifizierte. Und es hat nicht funktioniert.

Ich meine, es geht so auch in großen und sehr großen Projekten, wenn viele solche tollen Teams vernetzt und im good will vereint zusammenarbeiten.

RMD

Oder:

Wie ich das erste Mal echtes „Projekt Management“ erlebte.

Beim PM-Camp Berlin habe ich von vier Projekten aus der Vintage Zeit berichtet, die für mich sehr wichtig waren. Und hier angekündigt, dass ich alle vier auch in IF-Blog beschreiben werde.

Projekt 3

Jetzt kommt die Geschichte zum dritten Projekt:

Fernschreiber (Siemens T100) - eingeführt im Jahre 1958 - moderner Nachfolger des T50

Fernschreiber (Siemens T100 – 1958), der moderne Nachfolger des T50

Nach meinem Wechsel innerhalb der Siemens AG weg von UB D WS DF 131 hatte ich gemeinsam mit einem neuen Kollegen, der schnell zum Freund wurde, die technische Verantwortung für ein relevantes und absolut innovatives Groß-Projekt namens DISPOL.

Siemens hatte den Auftrag gewonnen, das Fernschreib-Netz der Polizei Bayerns durch ein Transdata-Netzwerk basierend auf moderner Leitungsvermittlung zu ersetzen. Parallel zur Netzablösung sollten auch die Karteikästen durch eine Datenbank in einem zentralen Host (Mainframe – das war ein BS 1000 System) und die Fernschreiber durch moderne Datensichtgeräte abgelöst werden.

Das war so ungefähr von 1979 – 1981. Ich war noch fest angestellt bei Siemens, allerdings war ich gerade der Entwicklungsabteilung von Transdata/PDN, bzw. der dort eingezogenen „Bürocracy“ entflohen und suchte jetzt mein Heil im „Vertrieb“ bei UB D V S 3. Das war die Abkürzung für „Unternehmensbereich Datenverarbeitung, Vertrieb, Sonderprojekte  3“.
Siehe dazu den Bericht zu meinem Vintage Projekt #2.

Mein Wechsel aus dem Labor zu den Sonderprojekten bewirkte, dass ich aus der lieb gewonnenen und so angenehm privaten Umgebung der Ortenburgstraße (nahe dem Standort Hofmannstr.) nach Neuperlach umziehen musste. Und schnell habe ich verstanden, warum das neue Gebäude an der S-Bahn Neuperlach Süd von vielen Menschen boshaft „Datasibirsk“ oder „Lego-Stadt“ genannt wurde.

Für mich war es noch schlimmer. Ich zog in ein kühles Hochhaus in einem eingezäuntem Areal ein, das mich an ein großes Kasernengelände erinnerte. Beton und kalter HighTech-Schick dominierten. Und ich fühlte mich auch kaserniert, das einzig zivile innerhalb des Geländes ein Obst-Händler, der seine Waren an seinem Stand innerhalb des Standortes feil bot.

Vom ersten Tag fühlte ich mich im nur außen bunten aber innen recht grauen Betonbunker unwohl. Dies obwohl man immerhin noch die Fenster öffnen konnte und es im Inneren des umzäunten Bereiches viel Grün gab. Doch auch das Grün war auf eine sehr nüchterne Art domestiziert – nicht so schön wie man sich z.B. einen Schloßgarten vorstellt sondern mehr so techno-zweckmäßig.

Aber ich hatte Glück. Ich war ja bei den Sonderprojekten – und die fanden eben nicht im heimischen Office statt, sondern draußen in der Welt. Und da ich quasi mit Herrschaftswissen ausgestattet war, war ich jetzt mein eigener Herr und fühle mich wie ein kleiner König.

Und so zog ich es vor, mich überwiegend in der Räumen des Kunden (Bayerisches Landeskriminalamt in der Maillinger Straße) zu bewegen und mich in Neuperlach nur sehen zu lassen, wenn es eben unbedingt notwendig war. Die Räume der Polizei kamen mir trotz strengster Sicherheitsvorkehrungen viel menschlicher vor als der neue High-Tech-Standort der Siemens AG.

Die Flucht aus dem der Bürokratie geopferten „Labor“ war gelungen und ich durfte das richtige Leben erleben. Und das Projekt Dispol war eine tolle Sache. Eine totale Innovation. Gemeinsam mit exzellenten Partnern auf Seite der bayerischen Polizei waren wir ein wunderbares Team, das maximal konstruktiv und auf Augenhöhe zusammen arbeitete. Allerdings kam ich zu einem Zeitpunkt, zu dem das Projekt recht fortgeschritten war.

Und es gab eine Reihe von Geburtsfehlern – in allen möglichen Dimensionen des Projekts. So galt es, zuerst mal eine Reihe von hohen Hürden zu überwinden; da hatten wir ein völlig unsinniges Design, das schon teilweise implementiert war (man wollte ein starres System völlig funktionswidrig mit dynamischen Verbindungsaufbau realisieren), es gab diverse Architekturfehler bei HW und SW, die ganz schnell korrigiert werden mussten (Systeme ohne lokalen Speicher für den schnellen Reload, mangelhafte Testumgebung …), der totale Ausfall von zugesagten Komponenten (ein Beispiel ist hier der Fernschreib-Port, der zwar die Protokolle der damaligen Post trefflich konnte, aber nicht die der Polizei, die schon „elektrisch“ ganz anders waren) und dazu viele weitere „normale“ Herausforderungen, die eben so auftreten, wenn man Dinge das allererste mal macht …

Und es gab auch eine schwierige Anforderung im Vertrag. Denn das neue Produkt DISPOL sollte ein Fernschreiber-Netz ablösen. Und solche Fernschreibernetze hatten (zumindest in Bayern) eine Verfügbarkeit über Jahre wenn nicht Jahrzehnte von echten 100%. Das heißt, sie fielen NIE aus.

Und das hat der Kunde natürlich auch von der neuen Lösung erwartet. Zurecht?! Da Siemens (damals) natürlich nicht dumm war, hatten sie im Vertrag ausgehandelt, dass das System zumindest keine Verfügbarkeit von 100 % haben musste. Es durfte auch ab und zu mal ausfallen. Man ahnte wohl, dass die EDV ihre Einschränkungen hatte. Aber eben nur „ab und zu mal“.

So war vertraglich vereinbart, dass die Abnahme erst erfolgte, wenn das System einen gewissen Zeitraum (ich meine zwei Wochen) am Stück lief und die „down-time“ bei ganz wenigen Stunden lag (ich meine es war genau eine).

Das Problem war nur, dass der Wiederanlauf unserer Rechner auch gut eine Stunde erforderte. So bedeutete ein Absturz auch nur eines Systems, dass die zwei Wochen von vorne los gingen und so alle Versuche der Abnahme nach ein paar Tagen, spätestens aber ein paar Tage vor Fristablauf scheiterten …
(Einschub: Auch dieses Problem haben wir triggy gelöst, bei Interesse berichte ich gerne darüber).

Einen Absturz gab es halt immer, denn wir hatten eine Reihe von sporadischen und schwer zu reproduzierenden Fehlern, von denen der eine oder andere halt dann immer vor Ablauf der vier Wochen auftrat. Und die wir halt der Reihe nach „raus-pulen“ mussten. Das „raus-pulen“ von Fehlern braucht aber Zeit. Weil man da Fallen implementieren muss, die den Fehler „fangen“ und ihn reproduzierbar machen. Und diese Zeit hatten wir vertragsbedingt nicht.

Vielleicht noch ein vielleicht interessanter Einschub:
Der Test ging so, dass der Polizeibetrieb in der Phase der Abnahme doppelt lief. Der Echtbetrieb mit den Echtdaten lief weiter auf der alten Technologie des bewährten Fernschreib-Netzes. Die archivierten Originaldaten (Lochstreifen) liefen dann aber zeitversetzt 1:1 über das neue System. Zum Testen. Formal wurden zwar kritische Daten anonymisiert und entschärft. Aber eben nur soweit es möglich war. Und es ist (natürlich) nichts passiert. Weil wir wußten, dass das sensible Daten sind und wir da eine Verantwortung haben. Heute würden die Herren vom Datenschutz wahrscheinlich heulen.

Aber zurück zum Thema:
Das Problem mit der Standfestigkeit des Systems trat erst in der Endphase des Projektes auf (die sich ganz schön lange hinzog). Wegen den beschriebenen Ursachen gab es schon vorher eine Reihe von Problemen.

So geriet das Management in Panik. Das war auch der Grund, warum es mich ins Projekt geholt hatte. Dann hat es verstanden, dass sehr viel zu tun war und versorgte uns mit zusätzlichen Ressourcen! Das waren Consultants und junge Leute, die halt irgendwo im großen Konzern herum sassen und nichts zu tun hatten. Und:
Es installierte einen Projekt Manager! 

Ich berichte zuerst von meinen Erfahrungen mit den Consultants und jungen Leuten, dann vom Projekt Manager.

Die Consultants

Da kamen ein paar. Die sollten uns verstärken, was sie aber in der Regel nicht so richtig getan haben. Besonders erinnere ich mich an zwei Kollegen von der PSE (österreichische Siemenstocher für SW-Entwicklung). Der eine kam aus Wien und der andere aus Graz. Beide waren Doktoren, der eine hatte den akademischen Titel in der Psychologie, der andere in der Physik.

Beide waren höchst sympathische Kerle. Beide waren unglücklich in der Fremde. Der eine vermisste das schöne Wien, der andere Graz. Beide kamen mir sehr intelligent wenn nicht genial vor. Beide hatten einen Namen, der mit einem M. begann. Und beide hatten aber vom System wenig und wie guter Code aussehen sollte gar keine Ahnung.

Das habe ich den beiden aber nie gesagt, weil sie mir eben so richtig sympathisch waren. So durften sie mitspielen und haben das auch brav und gut gemacht. Nur so richtig im Projekt sind sie halt nicht angekommen. Auch weil sie wie Söldner in diesem Projekt „auf Montage“ waren. Und das erhöht Motivation und Leistungsfähigkeit nicht sonderlich. So war auch ihr Wertbeitrag nicht sonderlich relevant.

Die jungen Leute

Ich erinnere mich auch an eine junge Frau und einen jungen Mann, die wir bekommen haben. Beide waren blutjung (Anfang 20, ich war zu Beginn noch keine 30). Die beiden hatten irgendwo bei Siemens eine Ausbildung in Richtung IT gemacht.

Beide waren höchst motiviert, haben aufmerksam zugehört, gut gefolgt und so schnell die Technik wie ihre Aufgabe verstanden. Beide waren auch wahrscheinlich sehr billig – besonders in Relation zu den promovierten Consultants – und haben einen extrem hohen Beitrag zum Gelingen des Projektes geleistet. Aus beiden ist dann übrigens etwas geworden. Aber nicht bei Siemens.
Jetzt fehlt nur noch der neue

Der Projekt Manager

Der Projekt Manager war ein seriöser Herr, der immer Krawatte trug und vom ersten Tag durch hohe Nervosität auffiel. Die ich ich gut verstehen konnte, denn er sollte ja ein Problem lösen, von dem er wirklich keine um nicht zu sagen null Ahnung hatte. Einen wesentlichen Teil sass er bei uns und schrieb unaufhörlich Berichte. Die restliche Zeit war er in Sitzungen in Neuperlach. Er war so etwas wie ein Dolmetscher zwischen den Welten des Management und dem Projekt, das aus Technologie bestand. Der Sprache der Technologie war er nicht mächtig und konnte so das Projekt nie verstehen. Ich mutmasste, dass er auch nicht der Sprache des Managements mächtig war, die ich ja in meiner Zeit im Labor als Versorger von Großprojekten so ein wenig kennen gelernt hatte. Er war ein einsamer Wanderer zwischen zwei Welten.

Unser Projekt Manager hatte eine eigenartige Stimme und so schnell einen Spitznamen weg (Schnarrie). Den haben ihm unsere beiden Damen (W. und C.) gegeben, die die Koordination recht gut durchführten und den Kunden sehr klug betreuten. Vielleicht weil sie sich ärgerten, dass so auch ihre Rollen beschnitten wurden.

Schnarrie hatte für uns einen zweifachen Nutzen. Zum ersten mussten wir uns nicht mehr dem Management gegenüber rechtfertigen, eine Übung, die nicht nur Hans und Mich wie unseren Damen gelegentlich durchaus Zeit und auch Nerven kostete. Und er hatte ein Budget! Das hatten wir vorher nie. Und so gelang es uns, doch eine Reihe von schönen „Siegesfeiern“, wenn wir wieder einen sporadischen Bug oder so gefunden hatte, auf Kosten von Siemens durchzuführen …

Das sollte genügen. Das Projekt DISPOL wurde übrigens ein großer Erfolg und lief Jahrzehnte zur äußersten Zufriedenheit der Bayerischen Polizei. Und brachte der Siemens AG gute Folgeaufträge ein.

RMD

Wie ich zu meinem zweiten und so ganz vielen Projekten kam.

Projekt #2

Oben links meine damalige Siemens-Visitenkarte, auf dich immer noch stolz bin.

Oben links meine erste Siemens-Visitenkarte aus meiner Sammlung, auf die ich immer stolz bin.

Mein Studium setzte ich nach meinem Restart im Oktober 1971 bis zum glücklichen Ende fort (dem Gewinn des Diploms univ.). Das ging so: Im 4. Semester im Sommer 1973 merkte ich, dass das Vordiplom anstand. Und ich stellte fest, dass ich doch eine Reihe von Wissenslücken hatte.

So waren Wochen des Durch-Lernens angesagt. Das war eine stressige Zeit vor den vier mündlichen Prüfungen zum Vordiplom. Tag und Nacht lernen. Ich erkrankte an Wissens-Bulimie, einer Krankheit, die heute weit verbreitet ist und sich in allen mir bekannten Schul- und Universitäts-Systemen wie eine Seuche ausgebreitet hat.

Wie ich das Vordiplom so immerhin ordnungsgemäß geschafft hatte (erstaunlicher weise sogar mit der Note „gut“), war ich ziemlich erschöpft und musste mich erst Mal ausruhen. Das Ausruhen machte besonders viel Spaß in der Rechnerluft beim Siemens. Da gab es wirklich viel Hardware: Großrechner mit BS2000 und BS1000, Prozessrechner,  Büro-Systeme, Netzrechner und vieles mehr. Und an alle kam ich fast jederzeit ran.

Es war um mich geschehen. An der TH – die jetzt TU hieß, weil ja eine Universität etwas besseres als eine Hochschule war – waren die Rechenzeiten sehr knapp – also sah man mich dort nur noch selten. Die nächsten 4 Semester verbrachte ich folgerichtig viel beim Siemens und nur selten in den für Menschen recht unfreundlichen (und wohl damals auch schon verseuchten Räumen) des damals neuen Südbaus Informatik  (Fertigstellung auch so Anfang der 70iger).

Der ist übrigens vor Jahren abgerissen worden. Mannomann, wenn ich mir überlege, dass ich das Gebäude, in dem ich studiert habe, überlebt habe, obwohl es erst 20 Jahre nach meiner Geburt errichtet wurde, dann ist das doch auch irgendwie befremdlich. Ich dachte immer, dass Universitäten auch als Gebäude respektabel sein sollten, der ehrwürdige Altbau der TH steht der TUM auch heute noch prächtig zu Gesicht. Bin mal gespannt, wie lange es der Neubau in Garching schaffen wird …

Mein Hauptfach, die Mathematik, kann man gut aus Büchern lernen. Das war mein Glück, so konnte ich die Abwesenheiten in den Vorlesungen kompensieren. Nach 8 Semestern bemerkte ich dann, dass vor den Prüfungen die Diplomarbeit geschrieben werden sollte. Ich fand als Professor für meine Diplomarbeit Dr. Werner Heise. Leider ist er – obwohl er der jüngste Mathematikprofessor aller Zeiten an der TUM war – schon verstorben. Werner fand für mich eine wirklich spannende Aufgabe aus der Kombinatorik (es ging um eine Vermutung von George Polya, die noch nicht bewiesen war) – und so entstand der Satz von Dürre :). Das war nicht einfach und so war die Lösung auch für mich persönlich ganz toll. Schön war auch, dass ich Mr. Polya aus Ungarn sogar noch auf einem Kongress der Kombinatorik in Berlin erleben durfte. Besonders faszinierend an diesem Ausflug war übrigens, dass Berlin damals noch die herrliche Insel im feindseligen Umfeld war.

Nach der Diplomarbeit kamen die Abschlussprüfungen – und ich erkrankte wieder an Wissensbulimie. Noch heftiger als beim Kraftakt zum Vordiplom. Aber auch das zweite Mal hat das System „Wissen in Massen verschlingen und es dann noch schneller wieder vergessen“ gut funktioniert. So hielt ich eines Tages zwar total erschöpft aber doch sehr glücklich meine Diplom-Urkunde in der Hand. Zwar wusste ich nicht, ob ich da stolz darauf sein sollte oder eher nicht. Aber ich hatte es geschafft und ich war unendlich glücklich, dass das leidige Kapitel Uni für mich vorbei war.

Auf Arbeiten hatte ich eigentlich keine große Lust. Eine Weltreise oder auch nur Urlaub gingen auch nicht und so probierte ich, einen Job zu finden. Ich bewarb mich bei Softlab. Diese Firma fand ich ganz toll, weil ich bei Siemens mal eine Hektographie eines Buches von Peter Schnupp (Strukturiertes Programmieren) fand und das mir wie eine Fackel im Dunklen vorkam. Und der Peter Schnupp, den ich später sehr gut kennen lernen und lieb gewinnen sollte, war ja einer Gründer (gemeinsam mit den Kollegen Neugebauer und Heldmann) von Softlab.

Also schickte ich meine erste (in meinem Leben gab es dann vier Jahre später noch eine weitere) Bewerbung zu Softlab. Softlab hatte aber damals wohl eine kleine Krise und so haben sie mir sehr liebevoll abgesagt. Mit der sinnigen Aussage, dass sie an mir durchaus interessiert wären, aber zurzeit keine Aufgaben für mich hätten und ich mich in einem Jahr wieder melden sollte.

Natürlich war das für mich nicht sehr hilfreich. Aber wie es der Lauf der Dinge so wollte bin ich gut vier Jahre später dann tatsächlich bei Softlab gelandet – aber das ist eine andere Geschichte.

„Nach dem Studium muss man arbeiten!“ – das gab mir der bürgerliche Teil meines Über-Ichs vor. Also bewarb ich mich nach der Absage von Softlab mit denselben Papieren nochmal bei der Siemens AG. Ich war optimistisch, weil die mich ja schon kannten. Und siehe da, sie nahmen mich – und hatten gleich ein richtiges Projekt für mich. Das war Teil eines größeren Projekts, das wiederum Teil eines ganz großen Projektes war.

Ich landete bei UB D WS ST DF 131, was als Abkürzung für Unternehmensbereich Datenverarbeitung, Werk für Systeme, Systemtechnik, Datenfernübertragung, 1. Kompanie, 3. Zug, 1. Gruppe. Die letzten drei Begriffe sind meine Interpretation der 131. Der Gründer von Siemens hat das Unternehmen ja nach dem Vorbild der Reichswehr organisiert.

Ganz DF (sozusagen die Kompanie für Datenfernverarbeitung in der Siemens-Armee) arbeitete an einem Hardware- und einem Betriebssystem zur Realisierung von Datennetzen, genannt TRANSDATA. Es ist übrigens eine Schande mehr für die deutsche IT, dass es diesen Begriff in Wikipedia nicht gibt (wollte ihn gerade verlinken und habe ihn nicht gefunden). Immerhin war das die einzige und technisch wahrscheinlich sogar überlegene Konkurrenz für „SNA“ (System Network Architecture) von IBM  – und Big Blue war der Marktführer und schon so etwas wie unser großes Vorbild.

Die Software von Transdata nannte sich PDN (Programmierbare Daten Netztechnik) und generierte die Betriebssysteme, die für Datenstations-, Netzknoten- und die Vorrechner an den Mainframes notwendig war. Die wohl zwei spannendsten Jahre meines Berufsleben begannen, ich könnte mehrere Bücher darüber schreiben.

Erste Werkstatt von Siemens & Halske im Hinterhaus der Berliner Schöneberger Straße 19, Oktober 1847 (Quelle Wikipedia)

Erste Werkstatt von Siemens & Halske im Hinterhaus der Berliner Schöneberger Straße 19, Oktober 1847 (Quelle Wikipedia)

Wir waren im offiziellen Sprachgebrauch ein Labor, das 131 von DF und entwickelten APS (Abkürzung für Anwenderprogrammiersprache). Diese Sprache bestand aus einem Interpreter und einem auf Makro-Basis realisierten Übersetzer, der den Bit-Teppich für den Interpreter erzeugte. Die Sprache diente dazu, die „dummen“ Vermittlungsrechnern in die Lage zu bringen, intelligente (Vor-)Verarbeitung schon am Rande des Netzes zu erledigen wie z.B. Daten für einen Geschäftsprozess im Anwenderdialog aufzusammeln und zu überprüfen oder „intelligentes Routing“ und vieles mehr.

Innerhalb DF waren wir eine ganze Reihe von Teams, die alle Neues entwickelten, denn so ein Rechnernetzwerk braucht viele Module und war für die damalige Zeit schon ganz schön komplex (oder hochkompliziert). Und das hochintensiv zusammen arbeitete.

Gemeinsam mit den Kunden und den Partnern der FBZ (Fachberatungszentren der Siemens AG) brachten wir Transdata als die Basis für die neuen großen IT-Projekte voran. Und das lief ganz agil, offen und schlank. Die Protokolle der Abstimmungsgespräche mit den Großprojekten und den Fachberatungs-Zentren waren unsere Pflichtenhefte . Es gab auch ein Management, aber dessen Aufgabe war es vor allem, sich um die Menschen zu kümmern. Und die Teams vor dem Siemens Management zu schützen.

Wir arbeiteten in einer Enklave, in der Ortenburgstr. Die war  eine der vielen Dienststellen außerhalb der Hofmannstr. Im Erdgeschoß gab es noch eine richtige Bäckerei, allein das machte den Standort schon attraktiv. Keine Kasernierung und gute Brezen und Semmeln.

Irgendwie waren wir alle zusammen bei DF gut und haben den Laden geschmissen. Alle waren wir Ingenieure, die Technologie für echte Projekte entwickelten. Und Transdata wurde erfolgreich. Ich war stolz, an Systemen zu arbeiten, die doch so oft in wichtigen und revolutionären Projekten lief.

Mein Job sah damals so aus:
Ich arbeitete als Programmierer parallel an drei Versionen. Die Version A (z.b. 4.0), die aktuell im Markt lief, pflegte ich. Da ging es um Fehlerbehebung und Kommunikation mit den Nutzern. Für die Folgeversion entwickelte ich die besprochene und beschlossene Funktionalität (Version B genannt 4.1). Und dann musste gemeinsam mit den Partnern in den Projekten die Version C – bei uns 5.0 – geplant werden.

Die Zeit, die wir so in die Zukunft investierten, war nicht unerheblich. Denn der Markt war war anspruchsvoll und in großer Dynamik, die Konkurrenz war schnell und das Tempo musste so hoch sein.

Neben der Arbeit des Programmierens an zeitgleich drei Versionen hatte ich noch mehr Aufgaben. Natürlich habe ich das Manual zu unserer Programmiersprache selbst geschrieben. Ich musste die Großprojekte fachlich betreuen und bei den Systemingenieuren, die unser System nutzten, Kurse gehalten.

So wie ich auch den Test unserer neuen Funktionen gemeinsam mit unseren Pilot-Anwendern organisiert und  die Produkt-Blätter fürs Marketing geschrieben habe. Damals kamen auch laufend neue Mitarbeiter zu uns, nach einem halben Jahr war man damals beim Siemens vor lauter „newbies“ schon ein alter Hase. Und weiterbilden mussten wir uns auch – dazu dienten vor allem Papiere wie die „lecture notes“ der ACM oder von IEEE.

Nebenher haben wir noch eine Kaffeemaschine und einen Kühlschrank für unser Büro organisiert und damit bei der Siemens-Administration ein Erdbeben ausgelöst. Eine Kaffee-Maschine in einem Siemens-Büro – das war gegen alle Regeln (obwohl es diese Maschine im „Für uns“-Laden angeblich günstiger für die Mitarbeiter zu kaufen gab). Aber sogar das haben wir hinbekommen.

Und dann ging das Unglück los. Das Management wurde immer mächtiger. Es führte eine Arbeitsteilung ein. Das war so eine Art von Entwicklungs-Taylorismus im Labor. Dazu kamen immer aufwändigere Verwaltungsprozesse ein. Das war in der zweiten Hälfte der siebziger Jahre. Schluss war es mit der Labor-Idylle.

Zuerst kam die Manualredaktion. Wir mussten Menschen, die NULL Ahnung von IT hatten, beibringen, was in einem Programmier-Manual drinstehen muss. Dann kam das Quality Management. Dort sassen Menschen, die unsere Software getestet haben mussten, bevor sie prototypisch von den Kunden eingesetzt wurden. Nur hatten sie keine Ahnung von Software und auch nicht vom Testen.

Dann wurden Produkt-Planung (Product Management) und Requirement Engineering eingeführt. Plötzlich gab es Meilensteine wie A20, A30, B20 … B50. Das Wasserfall-Modell kam. Sogar das Ende des Produktes wurde in großer Gründlichkeit definiert. Das war T50, wenn ich mich richtig erinnere (Falsch, der Andi hat mir das Diagramm geschickt, es war der berühmte Meilenstein B90 – siehe unten). Das ganze nannte sich Projektphasen-Modell. Und wir durften nicht mehr programmieren, sondern mussten uns überlegen, welchen Reifegrad unser Werk gerade hatte.

Man führte Budget-Denken ein und verlangte von uns, dass wir für jede diskutierte Funktion Aufwandsabschätzungen tätigen (erraten) mussten. Blöderweise waren die meisten der neuen Funktionen sehr innovativ und hatten so einen hohen Anteil an kreativer Forschung. So wurde das „Aufwandsabschätzen“ schnell aufwändiger als das Programmieren. Nur programmieren durften wir ja nicht mehr, denn für den Beschluss, ob das ganze programmiert werden sollte, brauchte man ja erst eine gültige und geprüfte Aufwandsabschätzung.

Und so wurde das – was wir früher mit Kunden und FBZ direkt an einem Nachmittag vereinbaren konnten, immer länger diskutiert. Aus Wochen wurden Monate. Eigenartige Beschlüsse waren die oft absurden Ergebnisse, die man dann alle wieder aufwendig wegdiskutieren musste – oder heimlich U-Boote bauen. Was in einem gut kontrollierten Konzern auch nicht ungefährlich ist. Aber was tut man nicht alles für ein erfolgreiches Projekt.

Zusätzlich wurden Arbeitszeitregelungen durchgesetzt, die uns klar machten, dass wir nicht soviel arbeiten durften, wie das Projekt es erforderte. In logischer Konsequenz wurden dann später in Neuperlach auch für die Ingenieure Stechuhren eingeführt. Und wenn man erwischt wurde, dass man nach dem Stempeln noch ein wenig weiter gearbeitet hatte, gab es vom Betriebsrat erzwungene Schelte.

Sogar das „Arbeit nach Hause mitnehmen“ wurde immer schwieriger, denn der Werkschutz hatte sich an den Toren einen Zufallsgenerator einfallen lassen. Wenn der bimmelte, wurde man kontrolliert (gefilzt) und Unterlagen nach Hause mitnehmen war ja strengstens verboten.

So wurde es immer schlimmer. Es gab neue Sitzungen mit 3- oder 4-Buchstaben-Abkürzungen (die ich vergessen habe). Da sassen plötzlich Leute am Tisch, die von neuen Abteilungen kamen, die man bis dahin gar nicht kannte. „Querschnittsverantwortliche“ demonstrierten, wie wichtig sie waren. Leute, die keine Ahnung vom Markt und der Technologie hatten aber mit Allgemeinplätzen gut umgehen konnten bestimmten immer mehr die Produktentwicklung. Das kostete viel Zeit und mancher Blödsinn wurde beschlossen, der natürlich nie zum Fliegen kam. Wenn es überhaupt zu Entscheidungen kam. Das alles bewirkte vor allem Hilflosigkeit und Frust.

Kurz gesagt – es wurde Zeit zu gehen. So bin ich – noch innerhalb der Siemens AG – zu einer der Abteilung gewechselt, die die Projekte gemacht hat (UB D V S 3 – Unternehmensbereich Datenverarbeitung, Vertrieb Sonderprojekte Abteilung 3). Dort musste man ja noch echte Projekte stemmen und blieb – zumindest noch eine zeitlang – von Bürocrazy und Management-Wahnsinn verschont.

Ich hatte ein gutes Angebot, denn bei UB D V S 3 kriselte es (nicht nur) in einem Projekt, dass der Führung ganz wichtig war. Und das kräftig in Verzug war. Ich sollte es über die Bühne bringen. Es nannte sich DISPOL und wurde für die Bayerische Staatsregierung entwickelt. Aufgabe war es, bei der Polizei den Fernschreiber (Kommunikation), den Aktenschrank (Datenbank und -archiv) und die Schreibmaschine (Dokumentenerzeugung) durch IT-Equipment abzulösen.

Bei diesem Produkt habe ich dann das erste Mal in meinem Leben einen richtigen Projekt Manager erlebt … Der sollte es retten – und das war auch mein Job. Gemeinsam haben wir es auch geschafft. Weil er die Techniker machen ließ und nichts machte. Aber mehr erzähle ich hier noch nicht, denn das ist genau die dritte Geschichte aus meiner Serie Vintage Projekt Management vom PM-Camp in Berlin.

RMD

P.S.
Mittlerweile gibt es Personal Manager und Service Manager. Auf einer Visitenkarte der BVS.de habe ich vor kurzem „Ausbildungsmanager“ gelesen. HumanResource kümmert sich um BGM (Betriebsgesundheits Management). Die Unternehmen haben ihr Wissensmanagement  und zertifizierte Wissens Manager, die schaffen sollen dass „Siemens weiß was Siemens weiß“ – Siemens hier als Metapher.

Wenn das nichts hilft, wird ein Innovations Manager installiert und es dann immer noch klemmt, dann kommt der Change Manager. Und macht ein „Programm“. Und braucht dann natürlich einen oder mehrere „Programm Manager“.

What a brave new world …!

P.S.1
Hier noch das Diagramm, nach dem tatsächlich ein paar Jahre später bei Siemens gearbeitet wurde … Ist doch auch wunderschönes Projekt Management Vintage … Der Andreas Weber hat es mir zugesandt – Danke – lieber Andi!

Und danach sollte man innovative Software und Produkte entwickeln - ist doch irgendwie lächerlich.

Und danach sollte man innovative Software und Produkte entwickeln – ist doch irgendwie lächerlich.