Roland Dürre
Sonntag, der 15. Januar 2017

PM Camp Klausur 2017 – #pmcamp – 20. 01. 2017

Es ist sicher keine Breaking-News – aber am Freitag kommender Woche ist die PM Camp Klausur 2017.

Zur PM Camp Klausur treffen sich einmal im Jahr Vertreter*Innen aller Orga-Teams. Gastgeber des Prozesses ist in diesem Jahr das Orga-Team Dornbirn (Eberhard, Marcus, Stefan, Roland), die logistische Unterstützung erfolgt durch die InterFace AG.

So werden sich am Freitag, den 20. Januar 2017 von 8:00 bis 16:00 die Vertreter der Orga-Teams der PM-Camps Barcelona, Berlin, Dornbirn, Hamburg, Karlsruhe, München, Rhein-Main, Stuttgart und Zürich bei der InterFace AG in Unterhaching treffen.

Die PM-Camp-Klausur ist die Instanz, die an der strategischen Weiterentwicklung der PM-Camp-Bewegung arbeitet. So sind die Ziele der Teilnehmer:

  • Rückblick
    Wie haben sich die PM Camps entwickelt?
    Berichte von Format-Experimenten in 2016
  • Status Quo
    Wo stehen wir aktuell? Was ist uns JETZT wichtig?
  • Ausblick
    Was müssen wir beachten bzw. aktiv angehen, damit die PM Camp Bewegung weiter relevante Impulse in die PM Szene setzen kann?

Ich veröffentliche den Termin, um allen Freunden der PM-Camp-Bewegung oder/und Besuchern von PM-Camps die Gelegenheit zu geben, ihre Gedanken und Ideen der PM-Camp-Klausur zur Verfügung zu stellen.

Wenn Ihr also Anregungen habt, die die Zukunft von PM-Camp betreffen, so sendet diese als E-Mail an mich – ich werde diese sammeln und dann in die Runde einbringen.

Ich freue mich schon auf viele Impulse von und Inspiration durch Euch!

RMD

P.S.
Am Vorabend (Donnerstag, 19. Januar 2017) treffen sich die Frühankommer ab 19:00 im Althaching in Unterhaching. Wer Lust hat, alte Freunde wieder zu sehen, kann gerne dazu kommen.

Roland Dürre
Freitag, der 8. Juli 2016

Kann man Komplexität reduzieren?!

Vor kurzem habe ich ein Wissensangebot von Thomas Kleiner in IF-AGORA integriert. Die Botschaft war

„Komplexität
sinnvoll reduzieren
ohne sie zu trivialisieren!“

Thomas bietet Managern Seminare an, mit denen er ihnen helfen möchte, in komplexer Welt besser zurecht zu kommen. Und ist eigentlich immer ausverkauft.

Dieses neue Angebot habe ich dann auch getwittert. Mit dem Kurztitel „Komplexität sinnvoll reduzieren!“ Sofort bekam ich negative Rückmeldungen wie „diese Aussage wäre komplett #fail“ oder „da bin ich aber gespannt, wie das funktionieren soll“.

Unser Kater Lenin, genannt Wladi.Sein Bruder Stalin, genannt Joschi, ist ausgezogen.

Unser Kater Lenin, genannt Wladi. Sein Bruder Stalin, genannt Joschi, ist ausgezogen. Ein nicht nur biologisch komplexes Lebewesen.
Owner:
Barbara Dürre (cat)
Maresa Dürre (photo)

Jetzt muss man wissen, dass die Unterscheidung zwischen „kompliziert“ und „komplex“ im Internet stark diskutiert wird. In Berlin gab es sogar mal ein PM-Camp zu diesen Begriffen im Umfeld von Projekt-Management.

Projekt-Manager haben da kräftig debattiert, wie man komplexe Projekte von komplizierten differenzieren und bewältigen könne.

Ich selbst ahne nur, dass in komplexer Welt die dominante Logik auch nicht weiter hilft. Aber wenn wundert es. Versagt sie doch oft schon in ganz einfachen Welten?

Ein von mir sehr geschätzter Protagonist des Themas „komplex versus kompliziert“ ist übrigens Niels Pflaeging. Bei ihm bin ich zwar nie sicher, ob seine Analyse richtig ist, aber seine Schlüsse sprechen mir voll aus dem Herzen.

Zurück zum Wissensangebot. Man muss wissen, dass Thomas Kleiner ein kluger Philosoph ist. Seine Magisterarbeit behandelt „Das Menschenbild im Werk von Rupert Lay“. Nicht nur deswegen hat er den „Konstruktivismus“ studiert und wie ich meine auch verstanden.

Die Theorie des „Konstruktivismus“ hat mich in meinem Weltbild bestärkt, dass die Bestimmung, ob ein System oder Projekt komplex oder kompliziert ist, ausschließlich in der kognitiven Erkenntnis des Beobachters liegt.

Ich meine auch, dass Kompliziertheit und Komplexheit mit wissenschaftlichen Methoden und Metriken nicht erfasst oder gemessen werden können. Das ist ein philosophisches Thema oder wie man früher gesagt hätte, eines der „Metaphysik“.

„Komplex“ ist für uns genauso schwierig zu verstehen wie „unendlich“. Komplex steht für etwas, das man nicht rational definieren kann. Ich kenne nur Metaphern, die Komplexität vermitteln sollen, aber keine einzige von mir als valide nachvollziehbare objektive Definition.

So finde ich die „sinnvolle Reduktion“ von „Komplexität“ durchaus „zielführend“ möglich, betrifft sie doch die subjektive  Wahrnehmung von scheinbarer Realität und den Umgang mit dieser. Und natürlich meine ich auch, dass man sich davor hüten sollte, Komplexität zu trivialisieren.

🙂 Nein, an Komplexität sollte man sich erfreuen und sie genießen!

Ich bringe ein Beispiel:
Da muss jetzt unser Hauskater herhalten. Offiziell heißt er übrigens Lenin, die (Rest-)Familie nennt ihn Wladi, weil sie Lenin als Namen nicht mögen. Sein Bruder Stalin (von der Familie Joschi genannt) ist leider ausgezogen. Er hat sich mit Lenin nicht mehr verstanden.

Kater „Wladi“ Lenin ist sicher ein höchst komplexes System, so wie alle Säugetiere. Die Komplexheit von Lenin reduziere ich, in dem ich den Kater einfach als Katze und Haustier betrachte. Dadurch kann ich einen großen Erfahrungsschatz der Menschheit aus dem Umgang mit Katzen nutzen, ohne dass ich das Tier deswegen trivialisiere. Ich kann ihn sogar mögen und sein Handeln nachvollziehen. Obwohl ich die Komplexheit einer Katze nie verstehen werde.

Angst machen wir alle die Menschen, die meinen, man (MENSCH) könnte alles wissen und alles machen – und die versuchen „komplexe“ Systeme schnell und mit harten Eingriffen zu verändern. Besonders groß wird meine Besorgnis dann, wenn es um die Umwelt (die Natur) oder unsere Gesundheit (auch die Natur) geht.

Ich habe das Schicksal einer Reihe von alten Menschen erlebt. Wie die Medizin ihre letzten Jahre zerstört hat, weil sie mit wissenschaftlicher Rationalität diese Menschen heilen wollte. Wie hilfreich wäre es da gewesen, wenn man durch Reduktion und Vereinfachung sich an die einfachen Regeln der Vernunft gehalten hätte.

Ähnliches erscheint mir unserem Planeten gerade zu widerfahren.

Viel zu viele Menschen glauben, man könnte die Welt in komplex und kompliziert einordnen und sie mit Rationalität zum Besseren verändern. Ich halte das für eine Art von „Omnipotenter Geisteskrankheit“ und habe die Sorge, das da sehr oft die „Rechnung ohne den Wirt gemacht wird“ – nur merken wir das oft erst viel später.

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

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
Donnerstag, der 3. Dezember 2015

Erst normiert dann zertifiziert.

Oder:
Warum ich meine dass „Zertifizieren“ oft ein Quatsch ist.

Created by Barbara Dürre

Kreiert von Barbara Dürre, einer zertifizierten Zertifikat-Erstellerin 🙂

Um das Leben einfacher zu machen normieren die Menschen die Welt. Und erstellen Zertifikate, die bestätigen, dass das die Objekte dieser Welt sich im Rahmen einer festgelegten Norm bewegen oder dieser folgend erstellt wurden.

Ein positives Beispiel ist sicher die DIN (ehemals: Deutsche Industrie Norm). Sie wurde von einem Verein/Verband von Industrie-Partnern gestartet. Die Normierung von technischen Teilen hat einen wesentlichen Fortschritt gebracht.

Das hat wohl Sinn gemacht, wie auch eine einheitliche „Metrik“ in Europa oder gar der Welt für Eigenschaften von Objekten (Maße wie Entfernung, Gewicht, Größe, Volumen etc.) oder Zuständen (Druck, Geschwindigkeit, Temperatur, Zeit etc,) nützlich war.

Dem „Normieren“ folgt dann das „Zertifizieren“. Die verbindliche und geprüfte Angabe des konkreten Maßes eines Objekts ist die einfachste Form eines Zertifikates. Es gilt:

Zertifizierung kann es nur geben, wenn vorher eine Normierung erfolgt ist.

Wenn die Menschen in einem Bereich erfolgreich sind, dann wird die zu Grunde liegende Methode auch auf andere Bereiche angewandt. Auch wenn das vielleicht keinen Sinn macht. Zum Beispiel weil alles, was lebendig ist, eben nicht wie tote Masse sinnvoll normiert werden kann.

So normiert Brüssel (die EU) mittlerweile nicht nur Pflanzen und Früchte. Nein, in vielen Bereichen – und jetzt gerade da, wo es eben nicht geht – wird kräftig normiert und zertifiziert. So haben wir eine normierte Gurke und Nachhaltigkeit (und die dazugehörigen Zertifikate). Institutionen und Verbände aller Art „normieren“und zertifizieren fleißig mit – alles mögliche und für jeden Zweck. Meistens beginnen sie mit der Niederschrift von Sammlungen von (vermeintlichem) „Best-Practise“. Gewonnen hat man, wenn man eine verpflichtende ISO-Norm oder ähnliches geschafft hat. Und dann geht es los mit der Ausbildung der Auditoren und den Audits.

Aber wollen wir wirklich Menschen, ihr Zusammenwirken und das Leben an sich normieren? In den letzten Jahrzehnten und Jahrhunderten wurde die Metrisierung und Vermessung der Welt auf Menschen, die Natur und soziale Systeme ausgeweitet.

Unternehmen müssen jetzt mit Zertifikaten belegen, dass sie „richtig“ funktionieren, obwohl sie aus Menschen bestehen. „Richtig“ ist was im Sinne der Logik einer oft sehr komplizierten und sich widersprechenden Norm folgt. Und alles andere ist „Falsch“. Und dabei wird nur zu oft vergessen, was eigentlich beabsichtigt war oder das Problem ist.

Sogar auf Familien wollte man das ausdehnen. In den 60iger Jahren wurde diskutiert, ob man ohne einen Ehe-Führerschein überhaupt heiraten dürfe. Und ein Vater- bzw. Mutter-Führerschein wurde gefordert, um Eltern werden zu dürfen. (Führerscheine sind im übrigen auch nur Zertifikate). Sicher war das Ziel redlich, man wollte die Situation der Kinder verbessern.

Mir kam damals der zynische Gedanke, dass nach Zertifizierung von Vater und Mutter auch die Söhne und Töchter zertifiziert werden müssen. Damit sie ordentliche Kinder seien. Das ist ja heute ein wenig Realität geworden; die Schule etwa richtet auf Basis eines normierten Kinderbild ihre „Lehrpläne“ auf das Musterkind aus, ganz ohne zu berücksichtigen, wie verschieden Kinder sind.

Ich bin froh, dass der Elternführerschein dann doch nicht kam. Obwohl leider immer noch viele Kinder in einer trostlosen Situation leben. Der „Elternführerschein“ ist aber ein exzellentes Beispiel für die Grenzen von Normierung und Zertifizierung.

Familienrollen werden also noch nicht zertifiziert. Man versucht aber in anderen Gemeinschaften kräftig zu zertifizieren – zum Beispiel in Unternehmen beim Management. Man denke nur ans Projekt-, Wissens-, Qualitäts-Management etc. . Und bald wird sicher auch das BGM (Betriebsgesundheitsmanagement), die Gemeinwohl-Ökonomie und die CSR (Coporate Social Responsibity) zertifiziert. Und vorher natürlich normiert, was das ist.

Ich gehe davon aus, dass man nicht versuchen sollte, soziale Systeme, in denen Menschen agieren, zu normieren. Mir graut vor normierten sozialen Systemen. Ich glaube auch nicht, dass man Führung und Management normieren kann. Aber wie soll man etwas, das man nicht normieren kann, sinnvoll zertifizieren können?

Aber bleiben wir beim Projekt Management:
Eine Normierung von PM wird sinnvoll nicht möglich sein. Wie kann man das dann sinnvoll zertifizieren?

😉 Eigentlich ist das schade. Heißt das doch, dass auch die „Projekt Manager“ (wie z.B. die Programmierer) wieder – wie im Handwerk (craftsmanship) – so richtig von ihren Meistern lernen und viel üben müssen, um Könner zu werden.

Titel kann man mit Geld, durch den Besuch eines teuren Kurs und fleißigem auswendig lernen erwerben. Ein Meister wird  man jedoch nur über Fleiß und Schweiß. Und es könnte sein, dass man in Zukunft nur noch die Meister braucht.

RMD

P.S.
Es lohnt sich übrigens im Internet mal nach Zertifikaten zu browsen. Ich wurde von ihrer Vielfalt erschlagen und auch davon, wie absurd viele davon sind. Ich verzichte hier auf Beispiele, es würde kein Ende mehr nehmen.

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

Roland Dürre
Freitag, der 16. Oktober 2015

Noch 5 Wochen bis #PMCampDOR

pmcamp-logo-dornbirnEnde 2010 traf sich eine kleine Runde von Unternehmern, die nebenher fast alle auch als Blogger unterwegs waren. Sie hatten eine Idee und wollten mal ein barcamp für Projekt Manager ausprobieren. Sie nannten es PM-Camp (PM als Abkürzung für Projekt Management). Das waren Kornelia, Eberhard, Jens, Marcus, Stefan und meine Wenigkeit.

Unser Ziel war, Gastgeber eines freien Treffen von Menschen, Unternehmern, Führungskräften und „Managern“ aller Art zu sein, um jenseits von Konferenzen und Schulungen hautnah Erfahrung und Wissen austauschen zu können. Das ganz demokratisch und auf Augenhöhe. In einer guten Mischung von weiblich und männlich und jung und alt. 2011 auch im November ging es dann los mit dem ersten PM-Camp weltweit in Dornbirn.

Die Zeit verging schnell, in genau 5 Wochen findet dort das fünfte PM-Camp statt. Wir feiern also Jubiläum! Da sind wir schon ein wenig stolz. Auch darauf, dass aus dem 1. PM-Camp eine Bewegung entstanden ist, die jetzt in vielen Orten Europas mit lokalen PM-Camps lebendig ist.

Für Euch wird es langsam Zeit, die Karten zu bestellen. Sonst wächst die Gefahr, dass Ihr leer ausgeht. Denn PMCampDOR ist schon so etwas wie die „Mutter aller PM-Camps“ und da wollen viele hin.

Diesmal haben wir als Impuls die Metapher „Muster brechen“ gewählt. Die Hashttags sind so #PMCampDOR und #musterbrechen.
🙂 Vielleicht wird aus dann und aus die … Denn man weiß nie, was auf einem PM-Camp passiert.

Natürlich will das Orga-Team von Dornbirn das Jubiläum mit einem besonders schönen und gelingendem PM-Camp feiern. Deshalb wollen wir unter anderem unseren „Newbies“, sprich den Gästen, die das erste mal auf einem PM-Camp oder sogar barcamp sind, es ganz leicht machen, gleich so richtig einzusteigen. So weise ich hier auf eine Artikel-Reihe hin, die ich zwar schon 2013/2014 geschrieben habe, die aber immer noch aktuell ist. Da berichte ich, wie denn so ein PM-Camp funktioniert.

Hier sind die Links zu diesen fünf Artikeln:

Meine Weiterbildungsstory – Persönlichkeitsförderung, Seminare, Workshops, barcamps
(wie ich aufs Barcamp kam.)

barcamps und PM-Camp (2) – warum sie so erfolgreich sind.
(weil sie Spaß machen und alle Teilnehmer zufrieden und glücklich heimfahren.)

barcamps und PM-Camp (3) – „Typologie der Sitzungen“
(welche Arten von Sitzungen gibt es?)

barcamps und PM-Camp (4) – Twittern gehört dazu.
(Warum PM-Camps und social media sich so gut ergänzen.)

barcamps und PM-Camp (5) – Regeln
(auf einem Barcamp herrscht Freiheit, weil die Menschen sich sozial verhalten.)

Ein weiterer Artikel informiert pauschal:

Geschichte von und Leitfaden für PM-Camp
(und barcamps allgemein)

Und für alle – nicht nur die „newbies“ – möchte ich hier auf unsere Werte hinweisen, die wir in einem Leitbild zusammengefasst haben. Dazu gibt es auch ein Dokument.

Es ist bestimmt nützlich, sich das noch mal anzuschauen. Und vielleicht gibt es ja auch Änderungs-, Erweiterungs- oder Verbesserungsbedarf. Und den einzubringen und zu diskutieren, dafür ist auch #PMCampDOR die richtige Plattform.

Und hier noch ein kurzes Video zum Thema PM-Camp.

RMD
(auch fürs Orga-Team Dornbirn)

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.

Das war erst viel später und da war es schon vorbei. Das erste Projekt war noch in Koppstr. (Nahe Hofmannstr.)

Das gab es erst viel später – da war es schon aus und vorbei. Mein erstes Projekt war in der Koppstr. (Hofmannstr.)

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.

Jetzt beginne ich mal mit dem ersten kleinen Projekt:

Projekt 1

Das erste Projekt meines Lebens war nur ein ganz kleines. Es sollte 6 Wochen dauern, es war mein erster beruflicher Einsatz in der Datenverarbeitung.

Ich war damals Student der Informatik im zweiten Anlauf. Das erste Mal bin ich 1969 an der Technischen Hochschule München (THM) gestartet mit Mathematik und Informatik als Nebenfach. Die einzigen Alternativen fürs Nebenfach waren Physik – das mochte ich nicht und BWL. Da war ich allerdings skeptisch, hatte ich doch am „Wirtschaftswissenschaftlichen Gymnasium“ Jacob Fugger zu Augsburg Abitur gemacht.

Buchführung war da Abiturfach, und das konnte ich sehr gut. Während mir das Wissen, das mir in BWL/VWL vermittelt wurde, doch sehr hinterfragbar vorkam – wie übrigens heute noch mehr. Also blieb nur Informatik – und das klang ja 1969 richtig spannend. Professor F.L. Bauer gelang es dann im Herbst 1969 mir noch mehr Appetit darauf zu machen.

Aber dann zwangen mich am 1. April 1970 finstere Schicksalsmächte und eine Mischung von Pech und Ungeschick zur Bundeswehr. Das war kein Aprilscherz und so musste ich 18 Monate als Wehrpflichtiger auch in sehr hinterfragbaren Umgebungen verbringen.

Und wie ich dann Ende September 1971 wieder frei war, fing ich halt wieder von vorne an, wieder im ersten Semester, wieder mit derselben Fachkombination und wieder an selben Hochschule, die aber plötzlich TUM (Technische Universität München) hieß.

Aber außer dem Namen war nichts anders. Und ich wusste schon fast alles, weil ich 1969 noch ein fleißiger Student gewesen war und alles schon mal gehört und brav gelernt hatte. So ging es mir gut und die Olympiade 1972 kam ins Land. Da hatte ich neben dem Studium einen tollen Job mit guter Bezahlung bei der Eisenbahn (damals noch der Deutschen Bundesbahn) als Kundenberater für die Gäste aus der ganzen Welt. Und irgendwie gehörte mir die ganze Welt …

1974 schaffte ich das Vordiplom und brauchte wieder ein wenig mehr Geld als ich als Tutor an der TUM (Lineare Algebra I und II und ein Programmier-Praktikum waren meine Themen) verdienen konnte (fürs Bafög hat es bei mir ganz knapp nicht gelangt und meine Eltern – auch bei der Eisenbahn – waren der Meinung, ich könnte ja auch in Augsburg bei der Familie in meinem Zimmer wohnen bleiben und so wie mein Vater nach München pendeln). Das wollte ich aber nicht. Also suchte ich einen Ferien-Job – und natürlich war das Ziel bei einem führenden High-Tech- und Computer-Unternehmen.

Das war Siemens damals! Es ist aus heutiger Sicht kaum fassbar, welches wahnsinnige Know-How auf unheimlich vielen Feldern in diesem Unternehmen vorhanden war. Und sie nahmen mich bei Siemens und so war ich ab Sommer 1974 dann zuerst für 6 Wochen und dann für das restliche Studium mitten drin in der echten High-Tech-Welt. Mit Rechnern, Betriebssystemen und Programmiersprachen aller Art in direktem Zugriff – und das in vollem Überfluss, ganz anders als z.B. in der sogenannten TUM.

Und schon am ersten Tag bei Siemens bekam ich mein erstes Projekt! Mein (Ober-)Chef, unser Abteilungsleiter hieß Bieck. Er war ein Hardware-Mann und wurde ein paar Jahre später der Entwicklungs-Chef bei einem der damals aufstrebenden deutschen Computer-Hersteller, der Firma Kienzle.

Kienzle war nur einer der kleinen Konkurrenten von Siemens – aber es war schon sehr bemerkenswert, was solche Unternehmen – wie auch das viel größere Nixdorf oder viele kleinere damals so alles auf die Beine stellten.

Ich hatte in meiner 6 Wochen Werkstudentenzeit die totale Freiheit – versehen aber mit einen konkreten Auftrag. Und mir wurde signalisiert, dass meine Aufgabe wahrscheinlich gar nicht lösbar sein werde. Aber dass es schon schön wäre, wenn ich es irgendwie schaffen würde. Das war durchaus so, wie es in den letzten Jahren mir von Google berichtet wurde: Man stellt sich unerreichbare Ziele, es gibt aber eine schöne Toleranz fürs Scheitern und so freut man sich so richtig, wenn man das unmöglich scheinende dann doch schafft.

Die Aufgabe war ganz einfach zu formulieren:
Die Abteilung wollte möglichst große Mersenne-Primzahlen haben. Für einen Hardware-Prototypen.

Für Nicht-Mathematiker:
Eine Zahl heißt dann Mersenne-Primzahl, wenn sie eine Primzahl ist, die sich als eine Zweierpotenz minus 1 ergibt. Also wenn (2 power n) – 1 oder (2 power m) – 1, eine Primzahl ist. So würde ich es mal aus der freien Hand definieren.

Ja – und da wollte mein Chef möglichst hohe „n“s und „m“s haben. Wie ich das machen würde, war ihm gleich.

Zum Hintergrund:
Bei Siemens war damals viele Menschen so richtig in „Forschung und Entwicklung“ Das war wirklich toll. Aber das war kein losgelöstes akademisches F&E. Nein, die Anstrengungen dienten fast immer ganz konkreten Anwendungen und Projekten. Es war einfach geil.

Praktische F&E braucht theoretisches Wissen. Das holte sich die Wirtschaft von den Universitäten (früher gab es da noch etwas zu holen). Und da hat die Siemens AG natürlich auch über die Grenzen geschaut – besonders gerne über die innerdeutsche. Denn die DDR-Unis waren so schlecht nicht.

So lag auf meinem Schreibtisch eine wissenschaftliche Arbeit – ich meine sie war aus Leipzig – in der theoretisch bewiesen wurde, dass es möglich wäre, einen Zufallsgenerator aus einer Ringschaltung mit n binären Schaltern zu bauen. Und wenn man den  Aufbau an der richtigen Stelle „kurzschließen“ würde, dann würde das System eine maximale Perioden von Zufallszahlen liefern. Und zwar genau dann, wenn die Anzahl der verwendeten Schalter n eine Mersenne-Primzahl wäre. Und wenn der „Kurzschluss“ mach dem m-ten Schalter geschaltet würde – und dies m eine Mersenne-Primzahl wäre.

(ich bitte meine laienhafte Beschreibung zu entschuldigen, aber in der Hardware war ich nie sehr kundig).

Diese Arbeit habe ich nie verstanden, auch wären die 6 Wochen wären wohl viel zu kurz gewesen, um sie zu verstehen. Aber das war ja für meinen Job auch völlig unwichtig. Man wollte ja nur möglich große Primzahlen der Art 2 power n -1 von mir. Sogar die Primzahlen waren unwichtig, wichtig war nur das m und n.

Für meine Freunde aus der Software:
Anfangs der 70iger Jahre war es völlig utopisch, so etwas wie einen Zufalls-Generator in Software zu bauen. Die Teile sollten ja ziemlich schnell die Bitmuster erzeugen, immerhin waren sie für den Test von Maxi-Flachbaugruppen für Großrechner vorgesehen, und das waren für die damalige Zeit ganz schön schnelle Teile.

Herrn Bieck war es auch völlig gleichgültig, wie ich die Aufgabe lösen würde – sprich ob ich etwas zur Berechnung programmieren würde oder ob ich irgendwo auf der Welt die gesuchten großen Mersenne-Primzahlen finden würde. Ich hatte alle Möglichkeiten.

So trieb ich mich gleich an den nächsten Tagen nach Auftragserteilung in diversen Bibliotheken (Siemens, StaBi, Unis) herum (man erinnere sich, dass es damals noch kein Internet gab). Und ich habe schnell gemerkt, dass die Suche nach großen Mersenne-Primzahlen auf diesem Wege aussichtslos war, selber wenn irgend jemand auf der Welt diese schon berechnet hätte.

Also habe ich mich zu einer schnellen Entscheidung gezwungen. Ich vergesse die Welt um mich herum und versuche es allein – und programmiere mal los. Ich hatte ja nur noch ein bisschen mehr als 5 Wochen.

Das war das erste, was ich in meinem Leben zu „Projekt Management“ gelernt habe:
Fälle rasch eine Entscheidung, besonders wenn es wirklich schwer ist und Du eigentlich nicht weiter weißt.

Dann habe ich versucht, konventionell zu programmieren. Im Dezimal-System gedacht, mit integer und in arithmetischen Rechensystemen gewühlt. Und nach zwei Wochen gemerkt, dass ich so niemals ans Ziel kommen würde.

Und das war das zweite, was ich für Projekte und fürs Leben gelernt habe:
Du musst neue Wege gehen, wenn Du nicht weiter weißt! Verabschiede Dich dann von den alten Gedankenwelten und Mustern, aber das ganz schnell!

Ich beschloss also mich ab sofort nicht mehr um die großen Zahlen zu kümmern, sondern eine Zahl nur noch als Feld von Bits zu sehen. Und plötzlich schrumpften die ganz großen Zahlen ganz klein – zum Beispiel wurde aus 2hoch256 nur noch ein 32 Byte langes binäres Feld. Und mit 32 langen Bit-Feldern (oder auch größeren) kann man ganz elegant „rechnen“, denn man muss nur noch „shiften“. Und schon hatten die großen Zahlen ihren Schrecken verloren …

Die Geschichte erzähle ich aus zwei Gründen.

Zum ersten, weil ich da ganz bewusst plötzlich verstanden habe, dass neben dem schnellen und mutigen Entscheiden das Verlassen alter Denkmuster notwendig ist, wenn man etwas besonderes voll bringen will. Und habe dann oft darunter und dem typischen „Aber das war doch immer schon so ..:“ gelitten, das so oft im Wege stand.

Und weil ich als Zeitzeuge bestätigen kann, dass Siemens vor gut 40 Jahren oft so gearbeitet hat, wie man es heute Google unterstellt. Und dass in dieser Zeit wirklich großartiges geleistet wurde und es so weltweit eigentlich nur wenig Konkurrenz gab, wie vielleicht IBM und Xerox oder Hitachi. Alles andere war erst am entstehen.

Demnächst wird meine nächste Geschichte aus Berlin vom #PMCampBER zum Vintage Projekt Management hier erscheinen. Da war ich dann schon fest angestellt – bei Siemens im Labor. Das war Ende der Siebziger. Ich werde dann schildern, wie Siemens alles, aber wirklich alles getan hat, um seine damalige Stärke zu zerstören.

Dies durch ein Abschwören von seinen alten Tugenden und durch Einführung von Arbeitsteilung (Taylorismus) im kreativen Bereich wie Produktplanung (Requirement Management), Qualitätsmanagement, spezialisierte DV/IT-Lehrer in seinen D-Schulen, Manual-Redakteure und manchen mehr solcher Rollen.

Und vor allem immer vor Entscheidungen nur noch Fragen wie „Was bringt uns das?“ und „Wo ist dabei unser Vorteil“ gestellt wurden und nicht mehr die zentrale Frage „Warum machen wir das überhaupt?“ wie früher.

🙂 Projekt Manager gab es zurzeit meines ersten Projektes noch keine – der erste Projekt Manager taucht so erst in der von mir erlebten Welt dann erst in meiner dritten Projekt Management – Vintage – Geschichte auf. Das war dann Anfang der Achtziger Jahre.

RMD