Sonntag, 23. November 2014

Praktische Führung

Es wird ja viel über Führung und Management geschrieben. Die einen sind dafür, die anderen dagegen. Aber was ist eigentlich die Aufgabe von Führungspersonen?

Eine sehr gute Erklärung liefert aus meiner Sicht Reinhard K. Sprengers Buch “Radikal führen”. Danach hat Führung fünf Kernaufgaben:

  • Zusammenarbeit organisieren - Klar, das ist der Ausgangspunkt. Verschiedene Aktivitäten müssen so “verdrahtet” werden, dass ein Gesamtergebnis entsteht. Dazu gehört natürlich auch die Zielsetzung.
  • Transaktionskosten senken - Für die Zusammenarbeit müssen günstige Rahmenbedingungen geschaffen werden. “Irgendwie” kann man sich auch ohne Führung zusammenraufen. Mit Führung soll es ökonomischer sein.
  • Konflikte auflösen helfen - Irgendwas ist immer. Dann muss Führung helfen, wieder Kohärenz herzustellen.
  • Zukunftsfähigkeit sichern - Heute gut zusammenarbeiten, bedeutet nicht, dass das auch noch morgen funktioniert. Innen wie außen können sich Verhältnisse verändern; darauf muss Führung (proaktiv) reagieren.
  • Mitarbeiter führen - Nicht nur die Zusammenarbeit will geführt werden, auch der Einzelne. Immer geht es ja um Ziele, die erreicht werden sollen. Hilfe kann da nicht schaden. Und schließlich müssen auch noch Stellen in der Zusammenarbeit geeignet besetzt werden, damit es bei guter “Verdrahtung” auch wirklich fließen kann.

Wenn ich durch diese Brille auf Unternehmen schaue, dann verstehe ich sehr gut, was funktioniert und was nicht - und warum. Ein Schema, das mir schon sehr geholfen hat.

Aber trotzdem: Irgendwas hat mir noch gefehlt beim Verständnis. Und das ist mir heute klar geworden, als ich mit meiner Tochter einen Nähkurs bei Zick und Zack in Hamburg besucht habe.

image

Dort wurde uns nämlich gesagt, dass eine Nähmaschine Führung brauche.

Der zu nähende Stoff muss unter der stationären automatischen Nadel entlangbewegt werden, um eine Naht zu produzieren. Das übernimmt der Transporteur unterhalb der Nadel.

image

Er zieht den Stoff, den der Nähfuß auf ihn drückt, an der Nadel vorbei. Die Richtung ist einstellbar; normalerweise bewegt sich der Stoff weg vom Näher, aber der kann ihn auch zu sich hin wandern lassen.

Der Stoff ist also grundsätzlich in Bewegung, die Naht entsteht von allein. Irgendwie. Denn bisher ist da sozusagen nur “rohe Kraft am walten”.

Was jetzt noch fehlt, das ist… Führung.

Die “rohe Kraft” des Transporteurs muss auf ein Ziel ausgerichtet werden. Und zwar immer wieder.

Hier sehen Sie, wie ich zur Übung entlang auf den Stoff gezeichneter Linien nähe. Der Stoff bewegt sich zwar von allein - nur nicht unbedingt “linientreu”. Ich muss ihn immer wieder nach-führen.

image

Dazu gehört, dass ich die Richtung korrigiere, indem ich den Stoff unter der Nadel drehe. Wenn die Richtungsänderung zu krass ist wie bei einer Zickzack-Linie, muss ich den Nähvorgang dafür sogar unterbrechen.

Darüber hinaus muss ich die “globale” Geschwindigkeit regulieren. Das tue ich über einen Fußschalter. Der bestimmt, wieviel “Input” sich die Maschine zum Nähen holt. Der Transporteur zieht sich ja den Stoff selbst.

Das ist aber noch nicht alles. Mein Aha-Moment bestand darin, dass ich fühlen konnte, was Micro-Management bedeutet.

Micro-Management entsteht nämlich immer dann, wenn zusätzlich zum allgemeinen Arbeitsfluss noch versucht wird, im Detail zu optimieren. Man überlässt das Resultat nicht dem Prozess, sondern greift lokal immer wieder ein.

Das führt bei Menschen zu Unmut. Die fühlen sich bevormundet; man lässt sie ja nicht die Arbeit tun, für die sie einmal kompetent gehalten wurden, sondern greift ein. Wer micro-managet, der vertraut nicht.

Daraus resultieren in Bezug auf den Produktionsfluss Stockungung und Qualitätsverlust.

Und genau das habe ich eben spüren können: Sobald ich anfing, den Stoff in Transportrichtung auf die Nadel noch zusätzlich zu zu schieben (Druck, push), war das Ergebnis schlechter. Dito, wenn ich anfing, den Stoff in Transportrichtung noch zusätzlich hinter der Nadel zu ziehen (pull).

Die Naht war sofort ungleichmäßig und die Ausrichtung entlang einer Linie fiel sofort schwerer.

Führung bedeutet mithin, einen Prozess aufzusetzen - und sich dann weitgehend rauszuhalten. Wer über die im Prozess wirkenden Kräfte noch drückt oder zieht… der betreibt Micro-Management. Das Ergebnis sind Stauungen oder Risse. In jedem Fall gerät etwas aus dem Gleichgewicht und der Arbeitsfluss wird gestört.

Führung bedeutet, in Kontakt bleiben mit dem Prozess. Immer wieder schauen, ob der noch fließt und auch noch auf das Ziel ausgerichtet ist. Falls nicht, muss nachjustiert werden - aber vorsichtig. Und eher nicht an den einzelnen Prozesselementen (lokale Optimierung), sondern am Ganzen (globale Optimierung).

Wenn es mit der Naht bei mir nicht geklappt hat, dann aufgrund von Micro-Management und zu wenig Blick auf das Ganze. Schlechte Führung also.

Es schien einfacher, nah an der Nadel den Stoff zu ziehen/drücken, als die Gesamtgeschwindigkeit zu regulieren. Und es war attraktiver, überhaupt mit der Maschine zu nähen, statt das Nähen vorzubereiten. So habe ich zum Beispiel ein Band, das ich auf eine Tasche nähen wollte, nicht vorher mit Nadeln ausreichend fixiert. Ich dachte, ich kriege es durch Eingriffe nahe an der Nadel während des Stoffdurchlaufs hin, das Band gerade drauf zu nähen. So musste ich auf die harte Tour lernen, dass gute Vorbereitung hilft, den Durchsatz zu erhöhen.

Auch das gehört zu Führung: Bewusstsein dafür vermitteln, dass zu guter Zusammenarbeit auch darin besteht, auf Qualität von Input und Output zu achten. Systeme definieren sich ja durch das, was zwischen ihren Bestandteilen fließt.

Aber auch das ist eine Sache, die eben nicht während der Produktion geschehen sollte. Da müssen die Prozessschritte schon gut “verdrahtet” sein. Führung ist eine Sache des Rahmens, in dem Produktion stattfindet.

An der Nähmaschine habe ich ja auch nicht selbst die Naht hergestellt. Dazu greifen die Teile der Nähmaschine ineinander. Vielmehr habe ich in guten Moment einfach nur “sanft” geführt.

image

Das Ergebnis war dann doch passable und nützlich. Ich habe bei der Führung die Kurve gekriegt. Aber wie ist das im Tagesgeschäft? Kriegt Management da auch immer die Führungskurve? Das scheint mir nicht der Fall zu sein.

Da ist Micro-Management an der Tagesordnung - insbesondere, wenn irgendetwas sowieso nicht rund läuft. Da wird gedrückt und gezogen, statt auf den Gesamtprozess zu schauen. Wie sind die Prozessbeteiligten eigentlich grundsätzlich zueinander angeordnet? Wie ist die Qualität des Input? Wo gibt es einen Engpass?

Vielleicht würde ja mal ein Nähkurs für Führungskräfte helfen? Da kann man eine Menge lernen, nicht nur über Führung. Und Spaß macht es obendrein, mal wieder etwas Anfassbares mit den Händen hergestellt zu haben.

Freitag, 21. November 2014

Hacker-Tool für Gedanken

Wie soll ich wissen, was ich denke, solange ich es nicht aufgeschrieben habe? So geht es mir oft. Deshalb schreibe ich Blog-Postings und Zeitschriftenartikel und auch Bücher. Das Schreiben hilft mir beim Denken.

Aber welches Werkzeug benutzen für das Schreiben? Für den Zeitschriftenartikel ist MS Word der Standard. Aber muss das so sein? Wie könnten Redaktion und Autor vielleicht noch besser zusammenarbeiten? Oder was ist “Gedankensammlungen” in Unternehmen? Oder mit selbstverlegten Büchern oder eben Blog-Artikeln, wo noch mehr Feedback gewünscht ist?

Für manches haben sich Wikis sehr empfohlen. Die Materialsammlung für Clean Code Developer haben wir auch in einem Wiki vorgenommen. Für ein Buchmanuskript schien mir das bisher jedoch nicht passend. Da setze ich auf Markdown-Texte, die ich in meiner Dropbox verwalte und per Leanpub veröffentliche. Alternativ könnte ich aber auch ein Git-Repository benutzen. Nur für Kommentare von Lesern nah am Text ist das noch nicht das Richtige.

Aber jetzt bin ich auf hackpad.com gestoßen. Das sieht irgendwie cool aus. Artikel, genannt Pads, lassen sich dort so einfach wie in einem Wiki bearbeiten und verlinken. Man kann sie mittels Tags und sog. Collections organisieren und unter dem Dach eines Workspace veröffentlichen.

Einfache Refaktorisierung wird unterstützt (“extract pad”), Verlinkungen wie in Wikis sind mühelos, Medien können eingebettet werden. Und: Mehrere Benutzer können am selben Text arbeiten. Gleichzeitig. Man sieht, welche Teile von wem stammen. Explizite Kommentare sind auch möglich. Das finde ich cool für Texte, die “work in progress” sind oder eben das Werk einer Gruppe.

Aufsetzen lässt sich ein Workspace bei Hackpad leichter als ein Wiki, finde ich. Deshalb überlege ich mit Stefan Lieser, ob wir unsere nächste Initiative nach Clean Code Developer dort hosten. Zu klären ist dafür jedoch noch, ob Google die Pads von öffentlichen Workspaces ordentlich indexiert.

Allemal, so glaube ich, lohnt Hackpad aber einen Blick für alle, die ein Unternehmenswiki einrichten wollen.

Hier als Beispiel eines Pads ein Text aus meinem englischen Blog. In dem Pad hier können Sie auch schreiben. Mit “//” beginnen Sie eine Kommentarzeile.

Viel Spaß beim einhacken von Gedanken! :-) Hackpad sozusagen als “thought IDE”.

Freitag, 14. November 2014

Wunderlist für Personal Kanban

Ein Tool ist kein Selbstzweck, sondern soll dienlich sein. Das trifft auf Software zu wie auf Methoden.

Um meine Arbeit zu organisieren, wenn es mal wieder etwas mehr wird, habe ich vor einiger Zeit Personal Kanban eingeführt. Naja, “einführen” kann man da nicht viel ;-) Ich habe also angefangen, nicht nur eine Aufgabenliste zu führen, sondern die Aufgaben über ein Brett zu ziehen.

image

Das funktioniert - aber irgendwie, irgendwie fand ich es zu aufwändig. Die Software KanbanFlow stand mir im Weg. Es fühlte sich umständlich an. Und so schlief die Methode immer wieder ein.

Doch nun bin ich wieder dabei. Neues Tool, neues Glück. Hier fühle ich mich freier. Irgendwie. Und das eherne Gesetz des Personal Kanban “Transparenz” wird immer noch erfüllt.

Mein neues Tool heißt Wunderlist. Das gibt es auf allen Geräten und im Browser, selbstverständlich synchronisiert.

Es ist viel einfacher. Nix Kanbanbrettspalten. Keine Kärtchen. Einfach nur Listen.

Aber genau das macht den Unterschied für mich. Die Bedienung ist mehr auf den Punkt, finde ich.

Mein “Backlog”, das, was zu tun ist, pflege ich in verschiedenen Listen. Hier eine als Beispiel geöffnet, weitere sind darunter links zu sehen:

image

Das, was ich gerade tue, markiere ich als wichtig, so dass es herausgestellt in einer eigenen Liste steht:

image

Das ist mein WIP (work in progress). Wunderlist bietet da zwar keine WIP-Begrenzung, aber das ist auch nicht so wichtig. Es ist halt meine Verantwortung, nicht mehr als 1–2 Einträge über die Listen hinweg jeweils bis zur Erledigung als wichtig zu markieren.

Und am Ende kommen alle Aufgaben ins Archiv. Sie sind dann done:

image

Termine, Notizen, Teilaufgaben, Kommentare… das alles gibt es auch. Gelegentlich nutze ich es. Für den häufigsten Fall jedoch, die Abarbeitung von ständig einfließenden Aufgaben, reicht es mir völlig, schnell einen Eintrag in einer Liste machen zu können.

Wer sich noch überwältigt fühlt von zu erfüllenden Wünschen, der kann ja mal versuchen, mit Wunderlist etwas Systematik reinzubringen.

Dienstag, 11. November 2014

Die vielen Gesichter des Product Ownership

Wie sollte, wie kann Product Ownership aussehen? Stefan Rook hat dazu einen Vortrag gehalten:

Product Ownership hat also viele Gesichter. Diese Botschaft hat mir an dem Vortrag gefallen. Mir hat allerdings auch etwas gefehlt. Nämlich die Abstraktion. Was ist das Muster? Worum geht es im Kern?

Mag sein, dass das schon allen klar ist. Meine Erfahrung ist jedoch, dass die meisten Unternehmen genau da jedoch herumeiern. Denn wäre es ihnen klar, würde sich die Ermunterung von Stefan Rook, Product Ownership durchaus unterschiedlich zu leben, erübrigen.

Hier mein Versuch einer Abstraktion:

Die Hauptaufgabe des Product Owners (PO) nach Anschauen des Vortrags ist… die Priorisierung von Anforderungen.

Bei Wooga haben die Teams in einem Rahmen alle Freiheit und tun das selbst; in den Teams ist es der Product Lead, denke ich mal, der dafür verantwortlich ist, aber wohl sehr eng mit seinen wenigen Teamkollegen in dieser Hinsicht zusammenarbeitet.

Bei Jimdo ist es der Manager mit dem PO-Hut auf.

Bei der Zeitung gibt es dafür die Berechnungsvorschrift im Tagesgeschäft, die vom PO verwaltet wird.

Immer gibt es eine Reihe von Stakeholdern mit Wünschen; immer müssen diese Wünsche mit begrenzten Ressourcen erfüllt werden; also muss immer priorisiert werden. Ohne Priorisierung gibt es keine geordnete, verlässliche Umsetzung.

Ziele

Die besprochenen Szenarien unterscheiden sich darin nicht, sondern in der Zahl der Ziele, auf die hin die Wunscherfüllung priorisiert werden muss. Bei Wooga gibt es viele gleichzeitige Ziele; jedes Projekt hat seines. Bei Jimdo und der Zeitung hingegen gibt es nur eines.

Jedes Ziel hat viele Stakeholder und braucht daher einen PO der deren Wünsche auf die eine Umsetzungsressource hin priorisiert.

Wenn Sie Ihre PO-Strategie nun überdenken wollen, dann fragen Sie sich: Welche Ziele gibt es? Jedes verdient einen PO.

Gewichtung

Der PO hat in Bezug auf ein Ziel hin die Kompetenz (und Erlaubnis) zur Priorisierung. Und wie macht er das? Bei Wooga und Jimdo erfahren wir nichts darüber. Das kann “nach Gefühl und Wellenschlag” gehen. Bei der Zeitung hingegen, wird eine Formalisierung angedeutet. Dort wird “ohne Zorn und Eifer” priorisiert; alle Stakeholder stehen “im fairen Wettstreit”. Solange sie ihre Wünsche ehrlich in verschiedenen Kategorien bewerten, ergibt sich eine vorteilhafte Hitliste von Wünschen.

Dieser Unterschied ist für mich deutlich genug herausgekommen: Priorisierung kann mehr oder weniger formal geschehen. Jedes Unternehmen muss sich also fragen, wie nachvollziehbar die Priorisierung sein soll (oder auch kann).

Noch betrüblicher fand ich dann, dass die Bewertung bei der Zeitung so stehengelassen wurde. Als seien die Bewertungen gleichzeitig die Prioritäten.

Der PO als Herr über den ROI. Das wurde schon am Anfang gesagt. Kann er diese Aufgabe mit den Bewertungen in der Hand aber erfüllen? Nein.

Die Bewertungen, also Wertzuschreibungen die mehr oder weniger direkt auf erwartete verringerte Verluste oder vergrößerte Umsätze/Gewinne verweisen, sind nur ein erster Input für die Priorisierung. Schön, wenn Anforderung A bei Umsetzung 100.000 EUR einbrächte. Aber über welchen Zeitraum – und vor allem: mit welchem Aufwand?

Leistung ist nicht Arbeit und auch nicht Arbeit mal Zeit, sondern Arbeit pro Zeit. Die Aufgabe des PO bei der Priorisierung ist es, die Leistung zu optimieren. Die besteht darin, möglichst viel Wert mit möglichst wenig Aufwand zu schaffen.

Dieser Gedanke steckt auch in der Priorisierung mit “Weighted Shortest Job First” (WSJF). Einem Wert wird dort ein Aufwand gegenübergestellt, so dass sich ein Gewicht ergibt. Je gewichtiger dann ein Wunsch, desto eher sollte er umgesetzt werden.

Ein Wert von 100, der mit einem Aufwand von 10 realisiert werden kann (Gewicht: 100/10=10), hat ein geringeres Gewicht, als ein Wert von 50, der mit einem Aufwand von 4 realisierbar ist (Gewicht: 50/4=12,5).

Wie Wert und Aufwand ermittelt werden, ist von Ziel zu Ziel verschieden. Das finde ich wichtig herauszustellen. Um die Priorisierung gewissenhaft vornehmen zu können, muss ein PO also Wertmaßstäbe und Aufwandsmaßstäbe definieren.

Wer dann entscheidet, “das mache ich aus dem Bauch heraus”, muss nicht falsch liegen. Nachvollziehbar ist das jedoch kaum. Und was das für flüssige Kommunikation und Vertrauensaufbau bedeutet, kann man sich denken.

Aber… warum soll es nicht Situationen geben, wo das (zunächst) ausreicht? Entscheidend ist, dass man sich einmal dazu Gedanken gemacht hat – und in Retrospektiven die Annahmen immer wieder überprüft.

Abnahme

Am bedauerlichsten fand ich, dass der Vortrag nichts über die Aufgabe des POs als schließende Klammer der “Wertproduktion” gesagt hat. Es wurden nur Varianten der öffnenden Klammer gezeigt. (Was allerdings in der Tradition der Scrum-Darstellungen ist, die vor allem Backlog und Planning betonen – das Review bzw. die Abnahme demgegenüber jedoch vergleichsweise schwach ausleuchten.)

Das halte ich für einen Kardinalfehler, weil sich genau hier nämlich immer wieder das größte Problem von POs zeigt: Sie glauben, sie könnten Anforderungen “über den Zaun kippen” und bekommen dann “wie versprochen” Wert geliefert.

Das  ist der Ansatz “Stopfgans”. Da hilft auch nicht, am Anfang in schönem Einvernehmen mit Entwicklern über User Stories zu diskutieren.

Wenn der PO nicht an der “Wertschöpfung” zieht, entsteht kein rechter Fluss.

Hier spekuliere ich mal in Bezug auf die vorgestellten Szenarien: Bei Wooga und Jimdo ist das kein Problem, weil der PO besonders eng-agiert an den Entwicklern dran ist. Abnahme passiert hier ständig. Das große Ziel ist auch allen klar. Hohe Kohärenz der Energie aller Beteiligten. Bei Wooga nehme ich sogar an, dass die Entwickler wie bei Open Source Projekten z.T. ihre eigenen Kunden sind.

Schön, wenn das so ist – nur muss man eben wissen, warum es funktioniert. Co-location reicht da nicht aus. Es kommt auf den Willen des PO an.

Wie es bei der Zeitung ist, kann ich nur ahnen. Die Priorisierung ist explizit. Schön. Aber wie ist die Abnahme? Zieht da jemand an Wert? Wie groß sind die Brocken, die in die Entwicklung hineingekippt werden? Nach meiner Erfahrung mit größeren Unternehmen vermute ich, dass das nicht so einfach fließt wie bei Wooga und Jimdo. Man glaubt eher, dass “Reinkippen” schon ein Garant dafür ist, dass auch etwas rauskommt.

Aber ich kann nicht beurteilen, wie es dort ist. Ich kann nur betonen, wie wichtig eben die schließende Klammer Abnahme bei der Softwareentwicklung ist. Automatisierte Akzeptanztests sind nicht genug. Ein Mensch auf 2 Beinen erzeugt viel mehr Zug als ein paar Tests, die auf grün gehen müssen.

Der PO ist für mich die wichtigste Rolle in der Softwareentwicklung. Angesichts dessen, welch feste Strukturen in der Codierung entstehen und wie schwer es ist, dafür gute Leute zu finden, ist die Qualitätssicherung bei den Anforderungen immens wichtig. Vor der Codierung und nach der Codierung. Einen PO einzusetzen ist eine Maßnahme im Sinne des 3. Fokussierungsschritts der Theory of Constraints (TOC).

Ohne PO ist die Codierung der Engpass der Softwareproduktion. Mit PO… wird allerdings schnell der PO zum Engpass. Daher bin ich nicht überzeugt, dass das Jimdo-Modell oben auf der Liste zur Nachahmung stehen sollte. PO sein ist ein Vollzeitjob (außer bei trivialen Zielen). PO+Entwickler oder PO+Geschäftsführer sind für mich Anti-Patterns.

Bottom line

Ich stimme Stefan Rook zu, dass Product Ownership viele Gesichter haben kann. Welches zu einem Unternehmen passt, muss sich jedoch aus der Beachtung von Prinzipien ergeben:

  • Anforderungen im Rahmen eines Ziels müssen auf dem Weg zu den “Transformatoren” durch 1 Instanz gehen, den PO. Er ist die “single source of truth”.
  • Der PO priorisiert durch Gewichtung in angemessener Nachvollziehbarkeit. Er stellt dafür Wert und Aufwand gegenüber.
  • Was im System zur Umsetzung ist, muss möglichst schnell aus dem System herausgezogen werden. Erst dann entsteht Wert. Die vornehmste Aufgabe des PO ist daher der Zug am Ende der Produktionskette, die Abnahme. Die muss ab-so-lut verlässlich geschehen.

Im Rahmen dieser Prinzipien können Sie jede Form des Product Ownership wählen. Form Follows Function. Oder sie fragen sie mit diesen Prinzipien in der Hand, was Ihrem heutigen Product Ownership womöglich noch fehlt.

Freitag, 3. Oktober 2014

Regelmäßiges Lernen - Meine Retrospektive

Ende Juni 2014 hatte ich versprochen, ich würde nun auch noch expliziter das Lernen in meine Arbeitszeit einbauen. Zwar besteht mein Job als Berater, Trainer, Autor zu einem großen Teil ohnehin aus Lernen, doch das hat eine andere Qualität als das, was ich meinen Seminarteilnehmern und Kunden nahelege. Mein Job ist Lernen, deren Job ist es nicht.1

Wenn ich Softwareentwickler empfehle, in der Arbeitszeit zu lernen, dann bürde ich ihnen scheinbar eine extra Aufgabe auf. Das war bei meinem Lernen bisher nicht der Fall gewesen. Deshalb wollte ich mein Lernen noch expliziter machen; es sollte auch für mich eine zusätzliche Aufgabe im Tagesgeschäft werden, damit ich einmal fühle, wie es meinen Kunden geht.

Mein Commitment war, dass ich wöchentlich während der Arbeitszeit 2+ Stunden mich auf diese Aufgaben konzentriere:

  • Französisch lernen
  • Bücher zu Sachthemen außerhalb normaler Lernthemen lese
  • Meditiere, d.h. "Ruhe und Fokus lernen"

Und ich hatte versprochen, über meine Erfahrung mit solchem extra Lernen nach drei Monaten zu berichten. Hier nun meine Beobachtungen:

image

Das sind zwei Auszüge aus meinem Lernprotokoll, das ich mit Lift geführt habe.

Sie sehen, lückenlos ist das nicht. Meine erste Beobachtung also: Es ist nicht leicht. Es ist nicht leicht, an jedem Arbeitstag die 15-30 Minuten aufzuwänden. Irgendetwas anderes schien oft dringender und so war das Lernen dann verschoben auf später und dann auf den nächsten Tag.2

Gelegentliche "Planübererfüllung" hat das zum Teil wett gemacht, ist langfristig aber keine erfolgversprechende Strategie, würde ich sagen. Das ist wie mit dem Refactoring: wenn man es länger und länger nicht tut, dann ist der Berg am Ende so groß, dass man es auch nicht nachholen kann.

Außerdem ist der mentale "Umschaltaufwand" gerade beim Französich Lernen für mich teilweise so hoch, dass in der kurzen Zeit die echte Lernaufmerksamkeit dann noch kürzer ist. Das fühlt sich ineffizient an.

Die Lehre, die ich daraus ziehe: Extra Lernen macht in so kleinen Tageshappen nur sehr bedingt Sinn. Besser scheint mir ein wöchentlicher Lernblock von 2+ Stunden.

Manchmal habe ich mir aber auch selbst ein Bein gestellt. Die beste Zeit für Französisch und Sachbuch war der Vormittag - ebenso jedoch auch fürs Schreiben. Welcher Tätigkeit dann den Vorzug geben? Die Entscheidung fiel mir leichter fürs Schreiben.

Die nächste Lehre daher: Der Zeitpunkt für Lernen will gut gewählt sein. Und wenn er einmal gewählt ist, sollte die Entscheidung nicht immer wieder neu getroffen werden müssen. Da geht Kraft verloren. Da zieht Lernen allzu schnell den Kürzeren. Vertagen scheint so einfach, so schmerzfrei. Doch in Wirklichkeit wird nicht vertagt, sondern gestrichen.

Aber auch von solchen Äußerlichkeiten unabhängig fiel mir das Lernen nicht immer leicht. Ich habe Wellen der Motivation gespürt. Manchmal klappte es besser, dann war ich für den nächsten Tag motivierter; manchmal klappe es nicht so gut, dann hatte ich am nächsten Tag nicht soviel Lust, mich weiterem Frust auszusetzen.

Solche ups and downs lassen sich wohl nicht vermeiden. Aber ich denke, man kann sie mildern. Das ist wie beim Fitnesstraining. Die Lust am Morgen (oder Abend) sich aufzumachen, ist unterschiedlich - da hilft es, wenn jemand auf einen wartet.

Ich habe (wieder einmal) übers Lernen gelernt: Lernen macht mehr Spaß und funktioniert verlässlicher, wenn man es nicht allein machen muss. Das Mindeste ist ein Accountability Partner, d.h. eine Person, der man direkt in die Augen blicken und gegenüber Rechenschaft ablegen muss. Eine Person, die den Lerner zieht. Die ihn an seinen Vorsatz erinnert, ihn fordert (aber auch durchaus fördert).

Damit meine ich nicht unbedingt einen Lehrer, aber der kann es natürlich auch sein.

Ein Mitlerner ist genauso gut. Oder einfach nur jemand, der eben zieht und sonst nichts.

Lernen in Teams sollte deshalb nicht Sache der Einzelnen sein, sondern der Gruppe. Gemeinsam Lernzeit einrichten, gemeinsam lernen. Das hilft ungemein.

Unterschätzt habe ich am Ende allerdings vor allem einen Aspekt: Relevanz. Nach einer initialen Phase hoher Motivation bin ich beim Französisch Lernen in den Morast gekommen. Es ging nur zäh voran. Nicht, weil es besonders schwierig gewesen wäre. Es lag vielmehr an einer fehlenden Bedeutung des Französischen für mein sonstiges Leben.

Ich mag Französisch. Ich würde es gern lesen und auch sprechen können. Doch am Ende ist das nicht jeden Tag wieder genug Antrieb gewesen, um dauerhaft dabei ins Lernen zu kommen. Anders wäre es wahrscheinlich gewesen, hätte ich schon mehr Vokabular drauf gehabt und mit dem Lesen von spannenderer Lektüre anfangen können. So aber war dieses Thema sehr abstrakt.

Das bedeutet: Lernen funktioniert umso besser, je relevanter es für das sonstige Leben (hier: Arbeitsalltag) ist. Je kleiner der Sprung vom Lernen ins Tagesgeschäft, desto besser. Das muss nicht bedeuten, dass man alles anwenden kann oder Großartiges leisten muss. Aber immer wieder sollte im Arbeitsalltag etwas ein Stückchen leichter fallen, besser werden.

Das habe ich bei der Lernaufgabe "Sachbuch lesen" positiv gemerkt. Dort habe häufiger Impulse für die Arbeit bekommen.

Diese Retrospektive zu meinem Lern-Commitment mag ernüchternd klingen. Es hat nicht so einfach geklappt, wie gedacht. Auch die Öffentlichkeit, in die ich mich mit dem Commitment begeben hatte, hat daran nicht viel geändert.

Doch ich sehe es positiv: Immerhin habe ich dabei etwas gelernt. Auf der Meta-Ebene. Für mich selbst, für meine Kunden oder für Sie braucht es neben der Erkenntnis, dass Lernen wichtig ist, und dem guten Willen einfach noch ein paar Rahmenbedindungen:

  1. Wenn es um echten Lernstoff geht, dann besser jede Woche eine längere Lernzeit einplanen (2+ Stunden).3
  2. Einen Lernpartner oder zumindest einen Accountability Partner suchen.
  3. Immer wieder probieren, den Lernstoff im Alltag anzuwenden. Sozusagen inkrementelles Lernen à la Agilität, d.h. es entsteht sofort Nutzen.

Das mögen jetzt keine weltbewegenden Einsichten sein. Irgendwie klingt das doch selbstverständlich. Und doch ist es nochmal etwas anderes, diese Einsichten durch Erfahrung gewonnen zu haben.

Angesichts der Wichtigkeit des Lernens und auch des Lernens während der Arbeitszeit, in sich immer wieder etwas anderes dazwischen drängt, ist jeder Gewinn an Klarheit jedoch ein Fortschritt, finde ich. Mit dem falschen Fuß loszugehen, sich Illusionen hinzugeben, enttäuscht nur. Besser ist es, von Anfang an ein realistisches Rahmenwerk aufzubauen.

In diesem Sinn ist auch die CCD School gedacht. Sie bietet nicht nur Input fürs Lernen, sondern auch eine Form der Begleitung, der Accountability Partnerschaft. Offline geht das im Monatsrhythmus, online auch häufiger.

Zu guter Letzt aber doch noch ein Trost: Ich habe auch festgestellt, dass sich manches verselbstständigt. Ich mag mich schließlich nicht so regelmäßig und dauerhaft zur Meditation hingesetzt haben, wie geplant - doch das, was ich damit erreichen wollte, hat sich auf anderem Wege in mein Leben eingeschlichen. Die Fokussierung und das Konzentrieren auf "Innen" finden inzwischen "einfach so" immer wieder statt.

Manchmal wird aus extra Lernen also neue Gewohnheit. Dann macht das Thema keine Last mehr, sondern ist Alltag, gar Lust.


  1. Ob das wirklich eine günstige Sichtweise ist, die Arbeit von Softwareentwickler als nicht (oder nur wenig) lernend anzusehen, lasse ich hier einmal dahingestellt.

  2. Dazu kam, dass ich nicht jeden Tag meine Arbeitszeit einteilen konnte, wie ich wollte, weil ich in Trainings- und Beratungen beim Kunden war.

  3. Anders ist es mit Gewohnheiten oder einzelnen Handlungen. Meditation lässt sich nicht auf einmal pro Woche konzentrieren. Genauso wenig eine tägliche Reflexion, wie sie der Rote Grad des Clean Code Development empfiehlt.

Donnerstag, 2. Oktober 2014

Responsibilities zählen

Das Single Responsibility Principle (SRP) ist eine Säule sauberer Softwareentwicklung für hohe Wandelbarkeit. Nicht umsonst macht es auch den Anfang bei den SOLID Prinzipien, würde ich sagen.

Aber: Wie finden Sie denn heraus, wieviele Responsibilities (Verantwortlichkeiten) eine Methode oder Klasse hat? "Naja, das sieht man halt", scheint mir ein zu schwammiges Kriterium für ein so zentrales Prinzip.

Was ist eine Verantwortlichkeit?

Bevor es mit dem Zählen losgehen kann, muss natürlich klar sein, was da überhaupt entdeckt und gezählt wird. Was ist eine Verantwortlichkeit?

Die Literatur spricht von "only one reason to change". Das finde ich leider nicht wirklich hilfreich. Denn um welche Gründe geht es, worauf beziehen die sich?

Ich versuche es daher einmal so:

Jede Methode soll nur Anweisungen enthalten, die Anforderungen eines Aspekts erfüllen.

Diese Definition ist knackiger, erfordert jedoch die Klärung zweier Begriffe:

  • Aspekt: Ein Aspekt ist eine Menge von zusammengehörigen Merkmalen, die sich unabhängig von anderen Merkmalen ändern können. Man könnte einen Aspekt auch eine Dimension nennen. Beispiele für Aspekte in der realen Welt sind z.B. Frisur, Kleidung, Bildung. Sie können die Merkmale Ihrer Frisur (Haarfarbe, Haarlänge, Schnitt) unabhängig von Merkmalen Ihrer Kleidung (Stoff, Jahreszeitlichkeit, Stil) oder Bildung (Dauer, Inhalt, Ort) ändern.
  • Anweisung: Anweisungen sind Sprachkonstrukte, die definieren, was eine Software tun soll. Sie fallen für mich in zwei Kategorien: Logik und Integration.
    • Logik: Mit Logik bezeichne ich die essenziellen Anweisung von Programmiersprachen, die der Erfüllung von funktionalen wie qualitativen Anforderungen dienen. Das sind Operatoren, die Daten transformieren, Kontrollstrukturen (z.B. if, while), die den Verarbeitungsfortgang steuern, und Hardwarezugriffe (vermittels API-Aufrufen). Logik beschreibt Algorithmen.
    • Integration: Integration bindet mehrere Methoden zu einem Datenfluss zusammen.

Ich denke, jetzt wird auch verständlicher, was "only one reason to change" bedeutet: Methoden sollen nur geändert werden müssen, wenn sich an einem Anforderungsaspekt etwas verändert hat.

Methoden sind die kleinsten Container von Programmiersprachen. Darüber liegen für mich in wachsender Größe Klassen, Bibliothekn, Komponenten und µServices. Für die muss das SRP natürlich auch gelten. Also lautet es ganz allgemein:

Jeder Container soll nur Anweisungen enthalten, die Anforderungen eines Aspekts erfüllen.

So zumindest das Ideal. In der Praxis kann und muss sogar davon temporär oder in überschaubarem Maße abgewichten werden. Ziel sollte jedoch ein einziger Aspekt pro Container sein.

Außerdem ist zu bedenken, dass Aspekte in Hierarchien existieren. Zum Aspekt der Kleidung mögen die Merkmale Stoff, Jahreszeitlichkeit und Stil gehören. Nur zum Stoff z.B. gehören dann jedoch weitere Sub-Aspekte wie Farbe, Material, Haptik. Kleidung kann aus grobem roten Leinen oder feiner grüner Seide oder rauer gelber Wolle oder feinem gelbem Leinen usw. bestehen.

Ein Container auf höherer Abstraktionsebene (z.B. Klasse) kann dann für einen Dachaspekt stehen, der Container von Sub-Aspekten (z.B. Funktionen) zusammenfasst.

Härtegrade

Für mich gibt es Aspekte in unterschiedlichen Härtegraden. Hart sind Aspekte, die man an der Form erkennt. Man muss die Anforderungen nicht verstehen, die Anweisungen erfüllen, sondern nur die Programmiersprache/Plattform.

Beispiele hierfür sind die Anweisungsaspekte Logik und Integration sowie der Aspekt Datenstruktur.

Innerhalb der Logik können dann jedoch weitere verschiedene Hardwarezugriffe unterschieden werden, z.B. Tastatureingabe, Bildschirmausgabe, Dateisystemzugriff, Datenbankzugriff. Und sogar den Zugriff auf den Heap würde ich dazurechnen, also den Umgang mit Hauptspeicher. Dazu ist zwar kein spezieller API nötig, doch Zugriffe aus globale Daten (statische Felder oder Felder von Objektinstanzen) sind klar erkennbar.

Weich hingegen sind Aspekte, bei denen man verstehen muss, worum es geht. Es geht um das Was, wohingegen harte Aspekte das Wie betreffen.

Schon die Unterscheidung zwischen lesender und schreibender Logik setzt Interpretation voraus. Es ist daher kein Wunder, dass bei weichen Aspekten schnell Diskussionen entstehen. Der eine empfindet Lesen und Schreiben als Merkmale des selben Aspekts, der andere empfindet sie als getrennt - was sich dann jeweils in unterschiedlicher Aufteilung in Container ausdrückt.

Auch hier wieder eine Hierarchie: Lesen und Schreiben sind z.B. Sub-Aspekte von Objektpersistenz (zu der auch z.B. Serialisierung gehört). Und Objektpersistenz ist ein weicher Aspekt von z.B. Personalisierung. Die wiederum ein Aspekt des Anforderungsaspektes Usability ist - welche zur Anforderungskategorie Qualität gehört.

Und was folgt aus der Unterscheidung zwischen harten und weichen Aspekten? Halten Sie sich so lange wie möglich bei der Strukturierung von Code an harte Aspekte. Darüber gibt es viel weniger Diskussion. Das macht Ihre Codierung schneller, das macht Reviews konfliktfreier.

Am Ende jedoch können Sie natürlich den weichen Aspekten nicht ausweichen. Üben Sie also immer wieder Ihre Sensibilität in der Unterscheidung und Zusammenfassung von weichen, inhaltlichen Merkmalen.

Apropos Üben...

Angewandte Aspekterkennung

Zum Abschluss ein Codebeispiel, an dem ich Ihnen die Identifikation von Aspekten praktisch demonstrieren möchte. Ich entnehme es dem Buch "Head First C#".

image

Das Szenario? Versuchen Sie es doch einmal dem Code zu entnehmen. Wie Sie feststellen werden, ist das jedoch schwierig. Weil er nicht integriert und kein Titel sichtbar ist. Die Methode Main() enthält ausschließlich Logik. Und die hat ihrer Natur nach denkbar wenig Dokumentationsqualität. Reine Logik muss immer entziffert werden. Hobbyarchäologen sind klar im Vorteil ;-)

Aber ich verrate Ihnen das Szenario: Es handelt sich um eine Anwendung zur Darstellung von Dateiinhalten in hexadezimaler Form.

Hier nun der von mir mit Aspekten kommentierte Quellcode:

image

Das Kapitel im Buch heißt "Dateien lesen und schreiben" - aber wie das geht, muss der Leser sich mühsam im ganzen Code zusammensuchen. Nicht nur wie das Problem ganz allgemein gelöst wird, wie der Prozess aussieht, der das gewünschte Verhalten herstellt, ist also unklar. Es wird auch dem technologisch Interessierten schwer gemacht, sich zu informieren.

Das ist Bullshit. Das ist dirty code par excellance. Niemandem ist mit soetwas gedient. Und das in deinem Lehrbuch...! Erschreckend.

Ich habe vier Aspekte identifiziert, die über den Code verstreut und auch noch geschachtelt sind. Das ist das Gegenteil von Entkopplung.

Die Domäne ist die Formatierung von Bytes in hexadezimale und ASCII Darstellung. Aber weder ist diese Domäne als ein für sich stehendes Stück Logik herausgearbeitet, noch die anderen Aspekte.

Aber ich will Goethes "Besser machen, nicht nur tadeln, soll den rechten Meister adeln" folgen und Ihnen nicht vorenthalten, wie ich meine, das der Code aussehen sollte.

In der reinen Logik unterscheidet sich meine Lösung nur unwesentlich von der im Buch. Doch ich habe die Logik anders (bzw. überhaupt) in Container verpackt. Zunächst nur in Funktionen:

image

Das ist ein erster Schritt. In Main() ist der Prozess nun deutlich sichtbar. Außerdem ist klar, wo welche APIs benutzt werden. Wer sich zum Thema "Dateien lesen und schreiben" informieren will, schaut einfach bei Check_if_file_exists() und Read_blocks_from_file() rein; den Rest kann man dann ignorieren.

Wem das nun jedoch zu wenig objektorientiert ist, wer gern noch eine deutlichere Zusammenfassung der Subaspekte sehen möchte, der findet hier eine Lösung mit Klassen:

image

Zum Beispiel bündelt die Klasse FileSystemProvider die Methoden, in denen sich Logik befindet, die den API System.IO benutzt.

Die Aspekttrennug ist damit deutlicher. Der Preis dafür ist etwas Rauschen: in Main() müssen nun Klassen instanziert werden und Methodenaufrufe haben Objektnamen als Präfix.

Überhaupt haben meine Lösungen doppelt oder gar mehr als doppelt so viele LOC (lines of code). Ist das gut? Sollte Code nicht immer so kurz und knapp wie möglich sein? Trägt Knappheit nicht zur Lesbarkeit bei?

Klar, wenige Zeilen Code lassen sich leichter überschauen, sozusagen physisch. Aber inhaltlich ist das nicht unbedingt der Fall, nämlich wenn es sich um reine Logik handelt. Das war ja das Problem des ursprünglichen Codes. 40-50 LOC, also rund eine Bildschirmseite, das war nicht viel - und doch war es nur schwer verständlich.

Da bezahle ich gern den Preis von etwas Rauschen und mehr LOC, wenn ich dafür Verständlichkeit bekomme. Und die ist nun vorhanden, würde ich sagen.

Der Einstieg ins Programm ist sonnenklar. Er beschreibt lesbar, wie das Verhalten "Dateiinhalt als Hex Dump anzeigen" hergestellt wird:

image

Main() hat nun eine einzige, harte Verantwortlichkeit: Integration.

Und jede Klasse hat wiederum nur eine einzige Verantwortlichkeit, z.B. FilesystemProvider:

image

Sie kapselt die Nutzung des System.IO API. Dieser Aspekt zerfällt jedoch in zwei weiche: Prüfen, ob eine Datei existiert, und blockweises Lesen der Bytes aus einer Datei.1

Fazit

Das Single Responsibility Principle ist zentral für saubere Softwareentwicklung. Um es anwenden zu können, muss man allerdings wissen, was denn eine Responsibility eigentlich ist.

Mit der Definition, die ich gegeben habe, fällt es Ihnen hoffentlich leichter, die Verteilung von Responsibilities in Ihrem Code zu überschauen - und sie dann mit Refaktorisierung zu entzerren.


  1. Ok, ich gebe zu, ein kleinwenig unsauber ist der Code noch. Denn sowohl in Check_if_file_exists() wie in Get_filename() nutze ich zwei APIs. Zum einen den eigentlichen, um den es dort geht (Dateisystem- bzw. Kommandozeilenzugriff), zum anderen jedoch auch den für die Ausgabe auf der Konsole zur Fehlermeldung. Konsequenterweise müsste ich die Fehlermeldung in eine eigene Methode verpacken und z.B. in den ConsoleProvider verschieben. Eigentlich - denn hier lasse ich das mal so stehen. Es ist eine vergleichsweise kleine Sünde. Und wer will schon Perfektion? :-) Wenigstens bin ich mir der “Schmutzrückstände” bewusst.

Sonntag, 28. September 2014

Von Startup-Krautern lernen

Crowdfunfing ist in. Ich habe auch schon mehrfach gesponsort, gefundet, gespendet. Es ist einfach schön, motivierten Menschen unkompliziert ein bisschen helfen zu können - wenn mich die Idee begeistert.

So war es auch bei den Krautreportern. Ihre Vision hat mir in Zeiten des hypebasierten Einheitsjournalismus und der undurchsichtigen Verbindungen zwischen Medienmachern und Institutionen angesprochen:

Krautreporter ist ein tägliches Magazin für die Geschichten hinter den Nachrichten. Werbefrei, gemacht für das Internet, gegründet von seinen Lesern.

Jeden Tag mit vier ausführlichen, möglichst multimedialen Beiträgen von tollen Autoren. Emotional, relevant, journalistisch. In enger Zusammenarbeit mit unseren Mitgliedern. Auf einer modernen, leicht zu bedienenden Seite.

Das war kurz vor Kampagnenschluss im Juni 2014.

Also habe ich gesponsort - und das Kampagnenziel wurde erreicht. Naja, nicht allein durch meinen Sponsorenbeitrag ;-), aber ein kleinwenig habe auch ich dazu beigetragen. Das war ein schönes Gefühl. Und ich habe mich gefreut, bald engagierten, ehrlichen Journalismus zu genießen.

Doch seitdem... nichts. Oder fast nichts. Knapp eine Woche nach Fundingschluss schreiben die Krautreporter in ihrem Blog nämlich etwas. Nur was?

image

Man kann es nicht lesen. Es ist mit einem Passwort geschützt. WTF!

Außerdem erreicht die Email mit dem Passwort nicht alle Unterstützer. WTF!

Wenn man dann jedoch irgendwann den Zugang zu diesem "Geheimpapier" hat, dann liest man da von einem Plan. Der enthält wiederum einen Plan, nämlich für eine Software. Und noch einen Plan, einen Redaktionsplan. Und man liest von Verträgen die abzuschließen sind, einer Genossenschaft, die zu gründen ist, Büros die zu suchen sind usw. Lesernutzenstifend ist das alles nicht. WTF!

Wahrlich top secret Informationen. Gut, dass man das passwortgeschützt ins Web stellt und das Passwort eher nur auf Nachfrage mitteilt.

Dann im Juli aber ein nächstes Lebenszeichen. Dieses Mal ein öffentliches. Auch schön.

image

Aha, mit Hochdruck wird gearbeitet. Weiterhin natürlich im Verborgenen. Kenne ich irgendwoher solche Aussage. Ein Muster der Softwareentwicklung abgeschaut, scheint es ;-) Dazu noch ein Versprechen: Eine exklusive Beta-Phase für Mitglieder (dazu zähle ich auch mich als Sponsor) ab September 2014.

Nun ist es jedoch schon fast Oktober. Von einer Beta-Phase habe ich bisher nichts gehört. Auch berichtet das Blog seit Juli nichts mehr über den Fortgang der Hochdruckarbeit. WTF!

So nicht!

Leute, das macht keinen Spaß. So funktioniert doch keine Gründung im Jahr 2014. Haben die Krautreporter in den letzten Jahren soviel schreiben müssen, dass sie keine Zeit zum Lesen hatten? Zum Beispiel Bücher wie Lean Startup oder Kopf schlägt Kapital oder ReWork?

Eine Idee mit Crowdfunding statt über Banken zu finanzieren, ist ein erster Schritt in die digitale Welt. Schön, dass Journalisten sich das trauen.

Aber es gehört schon etwas mehr dazu, um auch in der digitalen Welt dann anzukommen. Wer es geschafft hat, Vertrauen aufzubauen und auch noch Geld einzusammeln, der darf sich nicht zurücklehnen und meinen, damit sei dem 21. Jahrhundert Genüge getan.

Wie gewonnen, so zerronnen - das gilt ganz besonders für Vertrauen. Umso mehr, als dass die versprochene Dienstleistung selbst mit Vertrauen zu tun hat.

Mein Vertrauen jedenfalls ist im Grunde verschwunden. Wie denn auch nicht? Was habe ich bekommen für mein Geld? Nichts. Unregelmäßige Blogbeiträge ohne Relevanz, dazu nicht eingehaltene Versprechen. WTF!

Das ist das Gegenteil von dem Journalismus, den die Krautreporter versprochen haben.

Aber so!

Ich will nicht zuviel spekulieren, doch es drängt sich mir der Verdacht auf: Selbst die motiviertesten Journalisten "alter Schule" stecken so tief im traditionellen journalistischen System, dass sie es schwer haben, sich modern zu bewegen.

Ihre Sorgfalt im Journalismus, ihre Liebe zur Recherche, zum Detail... das passt womöglich nicht zu dem, was der Markt draußen eben auch erwartet: Transparenz und Geschwindigkeit.

Transparenz

Guter Journalismus enthüllt. Nur sollten die Krautreporter das auch auf sich selbst beziehen. Was soll eine geheime Blogbotschaft? Was ich als Sponsor oder auch nur Interessierter möchte, das ist Offenheit, Ehrlichkeit. Kontinuierlich. Proaktiv. Über das, was bei den Krautreportern passiert.

Dafür gibt es Blogs, dafür gibt es Twitter, Facebook, Newsletter. Insbesondere in Phasen, wenn womöglich tatsächlich noch nicht der primäre Nutzen (hier: Artikel) geliefert wird.

Sobald die Produktion begonnen hat, urteile ich anhand der Produkte. Vorher möchte ich heutzutage und insbesondere, wenn da jemand die Crowd bemüht, auf dem Laufenden darüber gehalten werden, wie sich der Fortschritt auf dem Weg zur Produktion gestaltet.

Wo ist die Enthüllung der Krautreporter? Warum gibt es keinen Hintergrundbericht über das Geschäftsmodell, das Eigentumsmodell, die Arbeitsweise? Wo ist die Home Story - oder besser: Office Story - über die Redaktion? Wann gibt es eine Reportage über die Entwicklung einer zeitgemäßen Redaktion? Natürlich in zeitmäßer Form: live! Mit Foto, Video, Tonaufnahme, Text in Kombination.

Das ist doch kein technisches Hexenwerk. Dazu reicht ein Blog. Das gibt es schon. Oder auch noch ein Newsletter gelegentlich. Den gibt es auch schon. (Sagt man, denn erhalten habe ich noch keinen.)

Aber nein. Die Journalisten geben sich intransparent und technisch unwillig bis inkompetent. WTF!

Transparenz schafft und erhält Vertrauen. Wer Geld eingesammelt hat (oder noch etwas dazuverdienen möchte), tut gut daran, den Vertrauensaufbau nicht aus den Augen zu verlieren.

Die Krautreporter sind dafür leider kein gutes Beispiel.

Ein viel besseres ist Circuit Scribe. Die Idee dort: Elektronische Schaltkreise mit einem Stift auf Papier malen.

image

So ein Produkt marktreif zu entwickeln, dauert natürlich. Es war also nicht zu erwarten, dass nach Kampagnenende bald der Stift schon im Postkasten landet.

Aber Circuit Scribe hat angesichts dessen zeitgemäß gehandelt: Rund alle 14 Tage gibt es ein Update zum Fortschritt. Bisher sind es 28 in knapp 11 Monaten. Das ist Transparenz. Das ist Kommunikation, die Vertrauen aufbaut und erhält. Da behalte ich den Spaß an meinem Sponsorenbeitrag.

Geschwindigkeit

Transparenz ist gut. Doch über alle Transparenz sollte man nicht die Lieferung vergessen. Auch und gerade, wenn man noch nicht 100% sicher sein kann, was eigentlich geliefert werden soll. Das ist bei Software der Fall, das ist aber auch bei den Krautreportern der Fall.

Klar, man startet mit einer Idee. Die hat auch genügend Sponsoren motiviert. Wunderbar. Nur ist die bisher schwammig. Es gibt keinen Prototypen. Es gibt... nichts außer Versprechen.

Weder dient das dem Vertrauenserhalt, noch ist das nützlich für den Leser, und Feedback wird so auch nicht generiert.

Wenn es eine Lehre aus der Agilitätsbewegung oder dem Lean Startup gibt, dann ist es: Liefere in Iterationen. Generiere Feedback. Lerne schnell.

Dieser zentralen Lehre für Unternehmen in Märkten, wo unklar ist, was eigentlich wirklich, wirklich gesucht, gebraucht wird, widersprechen die Krautreporter.

Nicht nur sind sie intransparent, sie haben auch noch keine Kostprobe ihres Könnens geliefert.

Das verstehe ich nicht. Es handelt sich um kein materielles Gut. Wenn Ciruit Scribe Anlaufzeit braucht, wenn Bonnaverde nicht sofort liefern kann, wenn Solar Roadways nicht im Wochenrhythmus Nützliches an jeden Sponsor versendet, dann ist das alles mehr als verständlich.

Aber Krautreporter wie Softwareentwickler können und sollten so schnell wie möglich und so häufig wie möglich liefern. Kleine, feine Inkremente, zu denen die Nutzer Feedback geben können.

Die Krautreporter wollen ja einen digitalen Dienst aufbauen. Dann sollten sie auch die Vorteile der Digitalität nutzen.

Als Sponsor interessiert mich gerade bei dieser Art Produkt nicht, ob es ein Büro gibt, ob schon die perfekte Redaktionssoftware oder der perfekte Website gebaut ist, ob man genossenschaftlich organisiert ist und dergleichen mehr.

Das ist alles nice to have - wenn das Produkt stimmt. Nichts davon ist nämlich eine Bedingung für die Möglichkeit, den versprochenen Qualitätsjournalismus zu liefern.

Wenn am Ende jeden Tag geliefert werden soll, dann erwarte ich natürlich nicht, dass das in Form und Frequenz schon kurz nach Kampagnenende der Fall ist. Aber warum nicht jede Woche ein Artikel? Das müssen keine zehnseitigen Reportagen sein. Sogar work-in-progress würde ich womöglich nehmen. Ganz modern: Nicht immer alles nur in ultimativer Form perfekt am Ende dermaleinst ausliefern wollen, sondern dem Cult of Done folgen. Accept that everything is a draft! Laugh at perfection!

Warum stehen im Blog nicht schon Artikel? Achso, weil man ja nicht für alle Welt transparent sein will. Warum dann aber nicht einen eigenen Newsletter einrichten, mit dem ab und an schon erste Werke verschickt werden? Die können in HTML gesetzt sein. Oder man bietet einen Link zum Download eines perfekt gesetzten PDF an. Oder man macht es gleich digital lesefreundlich und veröffentlicht ePub/mobi Dateien. Achso, da fehlt dann ja noch die essenzielle Kommentarfunktion für die Leser? WTF!

Ist doch egal, wenn es nicht perfekt ist. So ist das bei Experimenten und in der Übergangsphase. Es geht nicht um Perfektion, sondern um Annäherung. Progress over completion sagt dazu das Elastische Manifest. Und reactivity over commitment.

Oder, achso, liegt es vielleicht daran, dass man erst überhaupt mit der Arbeit beginnen wollte, wenn das Fundingziel erreicht wurde? Hm... das wäre schade. Wer keine Vorleistung bringen will, wer nicht geben, aber nehmen will... der macht den Vertrauensaufbau schwer. Geschenke erhalten nicht nur, sondern stiften auch Freundschaft.

Doch auch wenn die Arbeit an Qualitätsartikeln erst nach erfolgreichem Funding begonnen hätte, sollte doch schon das eine andere Ergebnis bis heute zu sehen sein. Nicht jeder Qualitätsartikel braucht doch 3 Monate Arbeit. Das glaube und erwarte ich nicht.

Nun gut: Was die Krautreporter irgendwann mal wirklich als ihr ultimatives Produkt liefern... Wer weiß das schon? Das muss keiner dort wissen. Nein, ich möchte sogar, dass keiner dort meint, dass man das schon wisse. Denn da hätte ich meine Zweifel, dass man der Kraut wirklich zuhörte. Konstant.

Das Produkt der Krautreporter muss sich entwickeln. Vor und in den Augen der Nutzer. So ist das in digitalen Zeiten. Dazu passt aber weder Intransparenz noch Langsamkeit.

Fazit

Aus Fehlern kann man lernen. Schade, dass es gerade ein Projekt ist, das ich gesponsort habe, das nun Fehler macht. Aber so ist das halt mit Investitionen. Nicht alle tragen die Früchte, die man sich erwünscht. Deshalb Investitionen streuen.

In puncto Journalismus setze ich daher nicht nur auf die Krautreporter. Ich "sponsore" auch impulse, agora42, Hohe Luft, die Zeit und brand eins.

Das sind Publikationen in unterschiedlichen Entwicklungsstadien. Ich lese sie, solage sie mir Nutzen bieten. Die Bezahlmodelle sind flexibel genug, dass ich mich frei fühle, ultimatives Feedback durch Kündigung zu geben. Bisher stimmen die Inhalte aber. Also bin ich auch bereit, zu zahlen. Gute Arbeit darf etwas kosten. Die von anderen wie meine.

Dafür möchte ich aber auch, dass man liefert. impulse & Co tun das schon. Die Krautreporter zieren sich noch. Zu lange für meinen Geschmack.

Dass die Menschen dahinter motiviert sind, glaube ich gern. Ich ärgere mich auch nicht über mein Sponsoring. Doch das Ergebnis bleibt mager. Vielleicht können wir ja aber etwas daraus lernen und es besser machen, wenn die Reihe an uns ist, etwas Neues in die Welt zu bringen. Es braucht Transparenz und Geschwindigkeit, um Vertrauen nicht zu verspielen. Hier am eigenen Leib zu erfahren als Kunde des Journalismus. Im Projekt als Lieferant von Software zu beherzigen gegenüber dem Kunden.

PS

Kaum hatte ich diesen Artikel veröffentlicht und getwittert, meldete sich Krautreporter bei mir per Twitter und bat um Kontaktaufnahme zwecks Registrierung zum Newsletter. Das ist aufmerksam. Daraufhin habe ich mir dann nochmal die Postings bei Twitter und Facebook angeschaut. Vielleicht hatte ich ja Transparenz oder Geschwindigkeit übersehen.

Aber nicht wirklich. Auch die verpassten Newsletter haben meinen Eindruck nicht wirklich zerstreuen können. Formulierungen wie “Leider können wir noch keine Details verraten” oder “Mehr dazu bald!” liefern… wieder nichts.

Manchmal ist der Aufbau von Spannung ja spannend. Hier halte ich ihn für kontraproduktiv. Ich will nicht wissen, ob ein Krautreporter von einer Reise zurück ist. Ich will wissen, was er auf der Reise entdeckt hat. Wenn man dazu nichts sagen kann/darf/will, dann lieber schweigen.

Naja, nun warte ich mal ab. Im Oktober soll es wirklich, wirklich bestimmt mit der Betaphase losgehen. Und eine neue Plattform ist dann auch am Start. Es kann also nur besser werden ;-)