Lesson 1: Direkte Kommunikation

Abriss

Nach ersten Gehversuchen mit Basic und später dem Comodore64, lernte ich im Studium zum Vermessungsingenieur programmieren.
Wir waren der erste Jahrgang, der mit C++ eine Hochsprache lernen durfte.
 

‚Wer misst, misst Mist‘ lautet unter Vermessern ein Sprichwort. Das soll heissen, dass jede Messung nur mit einer gewissen Genauigkeit geschieht. In einem Netz aus Messungen von Winkeln und Distanzen wirken sich diese ‚Fehler‘ auf die Genauigkeit der bestimmten Lage eines jeden Punktes aus. Befindet man sich in kleinen Netzen, in denen man alle 3 Dimensionen gleich berücksichtigt und nicht die Höhe separat, wie beispielsweise in der Landesvermessung, wird die Berechnung dieser Genauigkeiten zu einem ziemlich komplizierten jonglieren mit Matrizen.
Ausgleichsrechnung heisst die Lehre dieser Fehlerfortpflanzung. Ein klitzekleines Übungsnetzwerk zu berechnen dauert Stunden und kann einmal im Unterricht durchgeführt werden. Danach gibt es eine Prüfung von 4 Stunden mit einer einzigen Aufgabe, ein 3D Netz zu berechnen!
Es war schon immer der Traum des Dozenten für Ausgleichsrechnung, für diese 3D Netze eine Software zur Verfügung zu haben. So könnten die Studenten mehr experimentieren und Erfahrungen mit 3D Netzen Sammeln. Es würde immerhin jeder 3te nach dem Studium Staudämme vermessen, Rutschhänge überwachen oder im Tunnelbau die Richtung angeben. Eine solche Software zu programmieren wäre ein geeignetes Thema für eine Diplomarbeit.
 

Im Jahre 1999 traten 3 Umstände zusammen ein:

  • Die Studenten hatten mit C++ das richtige Handwerk erlernt.
  • Für die Diplomarbeit standen erstmals 10 Wochen zur Verfügung.
  • Mit meinem geschätzten Kollegen Moritz Wittensöldner und mir waren geeignete und motivierte Kandidaten gefunden, ein solches Abenteuer in Angriff zu nehmen.

Der Versuch konnte also gestartet werden.

Trinet – Mein erstes Software Projekt.

Durchführung

Die Priorität für eine solche Software wurde so hoch eingestuft, wir hatten eine extra Semesterarbeit zur Verfügung, für Requirements Engineering und Konzeption.
Instinktiv war uns klar: Um wahren Wert zu liefern, musste unser Programm nicht nur die Berechnungen korrekt durchführen, sondern auch die komplizierte Theorie sinnvoll abkapseln und ein einfaches Benutzerinterface mit simpler Bedienung liefern.
 

Selbst Studenten, waren wir potentielle User unserer Software. Wir dachten aber: Wie können wir zwei für alle künftigen Studenten sprechen? So entschieden wir uns, die gesamte Klasse beizuziehen. Uns war klar, dass wir deren Input so früh wie möglich brauchten um unsere Annahmen zu validieren. Wir erstellten als erstes eine Benutzer Anleitung für unsere Software. Anhand dieser, führten wir unsere Mitstudenten durch das zukünftige GUI. Wir konnten Ihre Reaktionen beobachten und ihr Feedback einholen. Die Ergebnisse flossen in die eigentliche Entwicklung mit ein. Heute würde ich so etwas usability testing oder wireframing nennen.
 

Trinet – So nannten wir unsere Software – wurde ein voller Erfolg und viele Jahre an den Schweizer Fachhochschulen eingesetzt.

 

Retrospective

Schon dieses erste Projekt zeigte mir, die besten Resultate entstehen, wenn Entwickler direkten Kontakt mit dem Endbenutzer haben und diese verstehen und wissen was sie weshalb umsetzen.
Umwege zwischen diesen beiden Parteien nenne ich gerne Managertreppchen. Es geht auf Kundenseite das Treppchen rauf, auf Dienstleisterseite das Treppchen wieder runter. Es müssen nicht zwingend Managerstufen sein, es können auch ganze Abteilungen sein, die extra dafür geschaffen sind, den Abstand zu vergrössern. Mit jeder Stufe schaffen wir eine Schwelle, an der Missverständnisse auftreten und Informationen verloren gehen oder gar dazu erfunden werden.
Ihr habt bestimmt alle als Kind das Telefon-Spiel gespielt? Wo man sich durch die Reihe etwas zuflüstert und am Ende etwas ganz Anderes rauskommt. Unterwegs gibt es Schritte wo gar nichts verstanden und Kauderwelsch weitergegeben wird, plötzlich versteht einer wieder etwas und gibt dies weiter etc. Immer ist es jedoch sehr amüsant, wenn zur Auflösung das ursprüngliche Wort genannt wird.
 

Dieses Problem ist lange bekannt und wurde Jahre lang gelöst – in meinen Augen völlig falsch!
Um alle Stufen des Umweges zu meistern wurden ganze Theorien geschaffen und Standards entwickelt. Diese Standards wurden zum Selbstzweck und an deren Einhaltung wurden der Fortschritt und die Qualität gemessen. Um die Qualität zu erreichen und die Standards korrekt einzusetzen und sauber zu überwachen wurden noch mehr Stufen eingebaut… Persönlich habe ich das nie verstanden!

 

Wann immer ich in späteren Projekten auf diese Umwege stiess, unternahm ich alles, um diese abzukürzen und sicherzustellen, dass die Entwickler die Benutzer und deren Beweggründe verstanden. Wo immer mir dies gelang, waren die Projekte erfolgreich.
Damit wurde ich aber immer als Querulant und Revoluzzer eingestuft – Es hiess: Ich sei ein Maverick (und das hiess in deren Augen etwas Schlechtes). Erfolge sprachen jedoch für mich und so wurde ich auch oft als verdrehtes Genie betrachtet. Nur weil niemand einsah, dass es so viel einfacher ist, das Ziel auf direktem Weg zu erreichen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *