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.
Projekt 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
Wird geladen ...
Eine Antwort
„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.“
„Nie wurde jemand im Stich gelassen. Und wenn man nicht mehr weiter wusste, hat man sich an seinen Kollegen gewendet.“
„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.“
Da wird mir richtig warm ums Herz.
Denn ich hatte einmal das Glück und die Ehre, einem Team mit einer verwandten Kultur anzugehören.
Sie können ja ‚mal raten, welche Rolle ich innehatte.