Was „Ship It!“ (Software) und Bloggen gemeinsam haben

Neulich wurde ich nach Tipps zum Bloggen gefragt. Ihr kennt das vielleicht, den typischen „Writer’s block“, noch dazu wenn man Softwareentwickler ist. „Ach was soll ich denn schon schreiben, das ist doch alles langweilig für die Leute da draussen“. „Ich weiß auch nicht so ganz, schon wieder ein Artikel zu <Thema X>? Da gibt’s schon schon zwanzig Beiträge dazu!“. „Hm, also hier im Team machen wir eigentlich nur langweiliges Zeug, das interessiert doch keinen“ (‚wenn du nur wüsstest…‘ denke ich mir da manchmal). ‚Hmmm. Also ich hab ja schon den Anspruch, dass der Blog-Beitrag ziemlich perfekt ist. Ich will ja nicht als Depp dastehen.‘

Kennt Ihr das? Dann hab ich ein paar Tipps für Euch. Meine 2 Cents: Bloggen ist wie Vorträge halten (gerade bei der agilen Arbeitsweise haben wir als Team Kontakt mit dem Kunden, insofern kann dies nützlich sein) ein wichtiges Handwerkszeug, das Bestandteil der Fertigkeiten eines Software Developers sein sollte.

Also, dann lasst uns mal schauen, was man tun kann, um die (häufig selbst gemachten) Hürden zu senken.

Meine Tipps im Detail

Ich erzähle ein bißchen, wie ich manchmal Blogbeiträge schreibe. Und das dann doch recht schnell geht.

Gliederung (EPICs) als Startpunkt

Zunächst, wie damals in der Schule, ein paar Gliederungspunkte schreiben. 3 bis 5, das reicht für die erste Iteration. Aufbau wie eine Geschichte. Ein fiktives Beispiel (bei dir kann das völlig anders aussehen!) für eine Gliederung wie folgt:

1. Probleme von Werkverträgen mit Kostenfixierung
2. Grundlagen: Scope, Time, Quality, Budget
3. Warum nicht alles fixiert werden kann
4. Ausweg aus dem Dilemma: agile Projektvorgehensweise
5. Vorteile der agilen Vorgehensweise aus Kundensicht
6. Ausblick: wie Vertragsmodelle im agilen Kontext aussehen

Praktisch: die Gliederung können dann schon Zwischenüberschriften im Blogsystem   sein. Danach schreibe ich dann in der Regel 1-2 Sätze je Gliederungspunkt. Manchmal mehr, manchmal weniger. Manchmal „fliesst“ es auch, dann schreibe ich einen Gliederungspunkt direkt fertig (FLOW, den wir alle aus der Softwareentwicklung kennen. Und nein, ich meine damit jetzt nicht FLOW3 Typo3 Flow ;-) ).

Und so hangel ich mich iterativ von Punkt zu Punkt, und je Iteration erweitere ich dann die jeweiligen Sätze des einzelnen Gliederungspunktes. Manchmal auch Pomodoro timeboxed, also nach 25 Minuten klingelt ein Alarm. Kaffee holen. Weiter geht’s.

Wenn ich Codebeispiele einbauen muss, mach ich mir erstmal einen Hinweis in den Artikel – die Codebeispiele (praktisch finde ich, sie in Github als gists anzulegen und dann einfach die URL zu copy-pasten – WordPress zum Beispiel embedded die gists dann automatisch) schiebe ich dann recht spät oder ganz zum Schluss rein.

Das Gleiche mache ich bei Bildern/Screenshots: ich setz mir nen Marker („BILDHIER“ o.ä.) in den Text und baue dann die Screenshots später rein. Gedanke dahinter: in Batches texten (erstmal Text schreiben, Code und Screenshots später in einem Rutsch).

Das tolle ist: nach ein, zwei Iterationen hab ich dann schon nen ganzes Stück Text beisammen und das motiviert.

Manchmal fällt mir irgendwann im Laufe des Beitrags ein, dass ich noch ein oder zwei Gliederungspunkte hinzufügen will: das mache ich dann einfach.

Vorschau verwenden

Ich prüfe häufig über die Vorschau, wie der Beitrag im Blog final aussieht. Dabei
achte ich nicht nur auf die „Formatierung“ (also Zwischenüberschriften, passen die Bilder
etc.), sondern ob die Länge genügt oder ich schon übers Ziel hinaus geschossen bin.

Die kurze Überprüfung ist praktisch, denn dann sehe ich recht schnell „Ah, das reicht
jetzt. Ich könnte zwar noch stundenlang schreiben, aber das passt so. Und wenn
Interesse da ist, dann mach ich einfach später noch nen zweiten Teil draus“.

Backlog Grooming auch für Blogbeiträge

In System-der-Wahl (zB Wiki, Evernote, …) notiere ich mir Ideen für Blogbeiträge. Manchmal habe ich nach Telefonaten/Meetings mit Kunden Themenideen, es kommen Rückfragen von Kunden/Webinar-Teilnehmern/KollegInnen/… Diese Fragen lassen sich wunderbar in Themen für Blogbeiträge wandeln. Kommen Fragen gehäuft von unterschiedlicher Stelle (zB „Björn, wie macht Ihr das mit agilen Projekten zum Festpreis?“), dann denke ich mir entweder „Tja, das ist unser Wettbewerbsvorteil, das erzähle ich dir zum teuren Consulting-Tagessatz :-)“ (SPASS!) oder, noch viel besser: „Tolle Frage. Klar antworte ich dir. Und parallel setze ich das in die Ideenliste“.

Wenn Ihr so wollt, habe ich also mein eigenes Raw Idea Bin in Form einer simplen Aufzählungsliste, einer Wiki-Tabelle, einer Evernote Notiz o.ä. Wichtig ist, dass die Themen gesammelt sind. Und dann, ganz GTD-like, braucht es nur noch ein regelmäßiges Gärtnern: veraltete/unattraktive Ideen rausnehmen, manche Themen nach oben priorisieren (Thema akut!), neue Themen hinzufügen usw.

Wichtig hierbei ist, dies in regelmäßigen Abständen zu machen. Zum Beispiel einmal die Woche, wenn man vielleicht eh (GTD …) seinen eigenen weekly review hat. Oder aber auch alle zwei Wochen, ganz wie es einem gerade einfällt.

(Eigene)Barrieren überwinden

Manchmal hat man das Gefühl „Hm, der Text ist nicht gut genug“, oder „Ob die Leute
da draussen das wirklich toll finden, was ich da schreibe?“, oder „Hm, was ich da
beschreibe sind doch alles Basics, gibt’s doch alles schon als Manual“.

Das sind meiner Meinung nach unbewusste künstliche Barrieren, die man sich hier drauf schaufelt, nur um ein „Nein“ als Ergebnis zu bekommen. Meine These: weg mit diesen Barrieren!

Was du schreibst, ist völlig okay. Einfach machen.

Dialog suchen

Ein Blog ist nicht nur eine Einwegkommunikation, sondern soll dem Dialog dienen. Um mit Euch Lesern in Kontakt zu kommen, ist es hilfreich, mit offenen Fragen gegen Ende des Blogbeitrags zu arbeiten. Stellt die eigenen Thesen, die Ihr im Laufe des Blogbeitrags aufgestellt habt, zur Disposition. Zettelt eine Diskussion im positiven Sinne an. Wir können alle von verschiedenen Perspektiven nur gewinnen.

Wie man das machen kann? Wenn Ihr am Ende des Artikels angekommen seid, werdet Ihr es schon merken :-)

Verlinken, verlinken

Es ist sinnvoll, in einem Blogbeitrag auf externe Quellen zu verlinken. Zugegeben, in diesem Beitrag habe ich das nicht löblich gemacht :-) Dennoch ist es hilfreich, nicht nur aus SEO-Gründen, sondern um dem Leser weiterführende Informationen zu bieten, auf Quellen zu verweisen oder möglicherweise auf andere Standpunkte zu einem Thema, die in anderen Blogs dargelegt wurden.

Sicher(er) werden

Du bist immer noch unsicher, ob du einen Beitrag schreiben sollst? Was, wenn der plötzlich von allen zerrissen wird? Wie kannst du an Sicherheit gewinnen? Meine Empfehlung, auch wenn es sich leichter schreibt als getan ist: blende die Unsicherheit aus.  Nimm zwei Gänge aus deinem eigenen Anspruch zurück. Hey, es handelt sich „nur“ um einen Blogbeitrag, nicht um eine Dissertation!

Meine These: in vielen Fällen wird das Ergebnis, das zustande kommt, um vieles besser sein, als du anfänglich befürchtet hattest. ;-)

Routine hilft

Was ist so toll an Scrum? Der stetige Rhythmus. Die regelmäßigen Sprints mit ihren ritualisierten Meetings helfen uns, an Stabilität und Sicherheit zu gewinnen. Das ist so ein bißchen wie mit Heiligabend, 1. und 2. Weihnachtsfeiertag: die hängen jedes Jahr immer gleich zusammen. ;-)

Übertragen auf das Bloggen bedeutet das: regelmäßige Schreibe in Form einer Routine hilft dir nicht nur, klarer in deinen Worten zu werden, sondern auch an Sicherheit zu gewinnen. Und irgendwann macht das Schreiben Spaß :-)

Pair Blogging

Du schreibst nicht gerne alleine? Moment mal… du kennst doch sicherlich das Prinzip des Pair Programmings. Warum nicht einfach mal „Pair Blogging“ betreiben und gemeinsam zu zweit an einem Beitrag schreiben, als Driver+Navigator, und sich gegenseitig abzuwechseln? Damit wird nicht nur der Blogbeitrag besser, sondern es macht einfach auch eine Menge Spaß. Ich verweise hier auf unseren Blogbeitrag zum Thema Pair Programming, der im Pair Blogging Style geschrieben wurde :-)

Der da drüben hat im Blog ein paar Sachen vergessen!

Ihr kennt das. Rasmus Lerdorf und Linus Torvalds haben mal wieder einen tollen Blogbeitrag geschrieben, aber Eurer Meinung nach zwei wichtige Aspekte vergessen. Wunderbar! Schon habt Ihr eine Idee für ein bis zwei Blogbeiträge, die auf die Blogs bei Rasmus/Linus verweisen, und Ihr über die beiden Aspekte schreibt.

Und schon ist Euer Themen-Backlog um ein paar Punkte reicher. :-)

Weniger ist mehr

So, jetzt ist es passiert. WordPress sagt: 1494 Wörter. Hat der Björn mal wieder zuviel geredet. Mein SEO-Plugin empfiehlt mir, ein Blogbeitrag sollte mind. 300 Wörter haben. Sehr viel mehr Wörter würden möglicherweise im SEO Ranking schaden. Egal. Mir hat’s Spaß gemacht, der Beitrag hat nicht mal eine halbe Stunde gedauert.

Solltet Ihr Euch auch mal in Rage schreiben, so empfehle ich Euch: baut einen Cliffhanger und teilt den Beitrag in mehrere kürzere Teile auf. Damit bekommst du mehrere Vorteile: die einzelnen (in sich interessanten) Beiträge sind als kurze, genüssliche Happen zu lesen, und du hast aus einer Themenidee schon mehrere einzelne Backlog-Items gebaut.

Abschluss: ein paar Links

Ich bin ja schon ruhig. Gehen sollt Ihr nicht ohne ein paar Links entgegen geworfen zu bekommen, die Raum für Inspiration und Transpiration beim Schreiben bieten:

• http://www.quicksprout.com/2009/07/21/how-to-write-a-blog-post/ (QuickSprout ist immer lesenswert)
  
• http://www.problogger.net/how-to-write-great-blog-content/
• http://www.copyblogger.com/
• die Blogs von Moz und KISSMetrics
• das Blog von HubSpot
• und viele weitere – manchmal auch Inc.com und FastCompany

Liebe Leser, Eure Tipps?

So, das war’s. Vielleicht konnte ich den Einen oder Anderen motivieren, ein wenig zu schreiben. Was sind Eure Tipps für das Bloggen, vielleicht sogar in Eurer Rolle als Softwareentwickler? Welche anderen Blogs verfolgt Ihr, um auf Ideen fürs Bloggen zu kommen und den berühmten „writer’s block“ zu umgehen? Ich freue mich auf Anregungen und Meinungen in den Kommentaren!