x-all-the-things-template
Kommentare 4

Automate All The Things: Mein Projekt-Boot-Script

Ich switche hin und wieder viel zwischen Projekten. Ich habe es mir inzwischen angewöhnt für jedes noch so kleine Projekt ein Boot-Script zu schreiben. Kostet nur wenig Zeit und spart das nervige eingeben der IP-Adresse (mehrfach!).

Im einfachsten Fall öffnet das den Browser, öffnet den OS X finder, startet den Webserver und lässt compass lauschen.

run.sh:

/usr/bin/open -a "/Applications/Google Chrome.app" 'http://192.168.0.4:8004'
open .
php -S 192.168.0.4:8004 &
gulp watch

Ihr habt sicher andere Anforderungen – aber der Gedanke sollte klar werden. Vor allem, dass man Chrome mit einem Shellscript öffnen kann, sollte euch die eine oder andere Anregung zur eigenen Workflowoptimierung geben!

Sharing:
Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedIn
Kommentare 0

Checkliste zur Übernahme bestehender Projekte

In meiner Eigenschaft als Freelance CTO habe ich in der Vergangenheit auch regelmäßig mit komplett neuen Projekten und Codebases zu tun. Manchmal muss ich mich ganz reinabeiten, manchmal muss ich nur die Struktur erst mal bewerten. Im folgenden möchte ich einmal mit euch meine Checkliste dafür teilen mit welcher ich bei einem neuen Projekt aufschlage.

Team

  • Teamlead?
  • Teamstruktur?
  • Background der Teammitglieder
    • Studium
    • Berufserfahrung
    • Interessante vorherige Arbeitgeber=

Stack

  • Programmiersprache?
  • Backend Framework?
  • Frontend Framework?
  • Datenbank?
  • Weitere interessante Technologien /Frameworks? Worker Queues? Elastic Search, Solr?

Code

  • Styleguides? PSR?
  • Testabdeckung Unit Tests?
  • Dokumentation? Im Code?
  • Versionierung? Git? Branches oder Pfuschen?
  • Wurde Code übernommen oder lokal entwickelt?
  • Wird Code von Dritten verwendet? Falls ja: Welche Software-Lizenzen stecken im Code?
  • Package-Manager?

Hosting

  • Caching? Memcache? Varnish?
  • Hosting Anbieter?
  • Server Standort?
  • Loadbalancer?
  • Lasttests?
  • Ausfallsicherheit? Redundanter Backupserver?
  • Backups? Prozess?
  • CDN?

Security

  • https:// ?
  • Code Audits?
  • Gab es bereits Angriffe?
  • Ist das System Mehrmandantenfähig?
  • Wie werden einzelne Mandanten voneinander abgegrenzt?

Rechtlich

  • Werden ADV abgeschlossen?
  • ISO-Normen? 9001?
  • Technisch Organisatorische Maßnahmen?
  • Weitere Zertifizierungen?

Features

  • Handelt es sich bei dem Produkt um einen Managed Service oder melden Kunden sich selbst an?
  • Multilingual? Vorbereitet? Wie viele Sprachen implementiert?
  • ACL?
  • Wie erweiterbar ist das System?
  • Wie echtzeitfähig ist das System?
  • Cronjobs? Routineaufgaben?
  • Ist eine besondere algorithmische Leistung erbracht worden?

Prozess

  • Frontend-Workflow? Gulp? Webpack?
  • Feste Releasezyklen? Wöchentliche Deployments?
  • Integration Tests?
  • Deployment Prozess? Continous Integration?
  • Behaviour Driven Development?

Feedback auf meine Checkliste ist ausdrücklich erwünscht. :)

Sharing:
Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedIn
Kommentare 6

Massen-Backup von Git Repositories ( zur cloudcontrol Insolvenz)

Mein bisheriger Lieblingsanbieter für Cloud-Hosting wird zum Ende des Monats seinen Dienst einstellen. Schade. Aber nun muss man auch reagieren und seine Daten sichern.

Um meine Repositories zu migrieren, habe ich mir ein kleines Shellscript geschrieben um alle auf einmal lokal zu klonen – und anschließend wo anders hin zu transferieren. Das wollte ich mit euch teilen:

cloudcontrol-backup.sh:

array=(repositoryname1,
 repositoryname2)
typeset -i i=0 max=${#array[*]}
while (( i < max ))
do
 echo "git clone ssh://${array[$i]}@cloudcontrolled.com/repository.git ${array[$i]} "
 eval "git clone ssh://${array[$i]}@cloudcontrolled.com/repository.git ${array[$i]} "
 i=i+1
done

Ihr müsst lediglich repositoryname1, repositoryname2, etc. durch eure eigenen Repositories ersetzen und anschließend das Script mit sh cloudcontrol-backup.sh ausführen.

Jetzt benötige ich nur noch ein neues Zuhause. Aktuell liebäugle ich damit, einfach alles zu AWS Codecommit rüber zu schieben. Sind hauptsächlich private, an denen nur ich arbeite.

Sharing:
Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedIn
Screen Shot 2015-12-10 at 16.45.44
Kommentare 3

Symfony Deployment Scripts

Der Deployment-Prozess für Symfony-Projekte ist ein ziemlicher Schmerz. Noch viel mehr, wenn man eigentlich gar nichts großes machen möchte und auf webspace deployed. Bisher war das dann in etwa folgender Prozess:

  • Assetic Assets rausrendern
  • src Ordner hochladen
  • web Ordner hochladen
  • app/Ressources Ordner hochladen – aber auf keinen Fall den lokalen Cache!
  • app/cache leeren
  • lokal die Assetic Assets wieder löschen, damit die wieder vom Controller generiert werden.

Das war mir alles zu nervig und ich habe mir ein Script geschrieben. Besser gesagt, zwei Scripts, was mir das ganze so einfach macht, dass ich zumindest alles überschreiben und ersetzen kann, ohne in Caching-Probleme zu kommen.

dev.sh

Dieses Script räumt überhaupt mal mit allem auf, was irgendwie statisch erzeugt wurde. Das führe ich nach einem Upload aus, oder wenn irgendwo etwas zu aggressiv gecached wurde. Das nutze ich, damit mir die durch Assetic generierten Dateien lokal nicht in die Quere kommen.

prod.sh

Das Script führt alles aus, was benötigt wird um sämtliche Ordner des Projektes mit dem FTP Client hochzuladen. Zuerst wird alles wie beim dev.sh Script gelöscht, anschließend werden die Assets neu generiert.

Conclusion

Mir ist klar, dass das noch weit weg von perfekt ist. Aber manchmal hat man keinen dedizierten Server und nutzt keinen Capistrano – aber deployed trotzdem relativ häufig.

Nachdem ich das prod.sh Script ausgeführt habe, kann ich einfach alle Ordner auf dem Webspace ersetzen und lasse nur /local/ außen vor (da ist z.B. eine SQLite-DB drin). Das ist für mich convenient genug. Um es schmal zu halten, übertrage ich außerdem .git/ und vendor/  nicht. ;)

Als nächstes werde ich auf den FTP-Client verzichten und den Upload über die Konsole machen. Mit dem FTP-Client sollte es aber einfacher verständlich sein, was meine Intension dieser Aufräumscripts ist.

Feedback gerne in die Kommentare. Wie macht ihr das?

Sharing:
Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedIn
IMG_0648_org
Kommentare 0

Phase 3: Prototyping digitaler Geschäftsmodelle

Heute zeige ich, wie am besten ein Geschäftsmodell als Prototyp entwickelt wird. Ziel ist möglichst früh möglichst viele Erkenntnisse zu erlangen und nicht 6 Monate im Keller vor sich hin zu arbeiten, bis man ein Geschäftsmodell zum ersten mal auf den Markt loslässt – oder noch schlimmer: Gar nicht erst anfängt. 

Wertschöpfung

Bevor sich nun mit einer konkreten Produktidee oder Implementierung befasst wird, muss erst mal der Kern der Wertschöpfung klar herausgearbeitet werden. Da gibt es zwei Ansätze:

Mit dem Kunden beginnen

Wird einen Bedarf im Markt erkannt, kann sich genauer mit dem Problem befassen werden – auch ohne das man vielleicht schon die Lösung dazu kennt.

Mit der Idee beginnen

Es ist genauso valide, einfach eine gute Idee zu haben oder einen technologischen Breakthrough geschafft zu haben und sich anschließend zu überlegen, auf wen die Idee passt. Die Idee sollte sich allerdings auf die Wertschöpfung konzentrieren..

Richtig: „Wir möchten Unternehmen mit Bloggern vernetzen“

.. und nicht auf eine konkrete Implementierung

Falsch: „Oh hier machen wir eine App und die Nutzer kommen von ganz alleine“

Um den Kunden und die wertschöpfende Idee in Kontext zu setzen, eignet sich ein Tool wie Value Proposition Canvas*. Es hilft einem, sich auf den Kern zu fokusieren.

Egal von welcher Seite dies angegangen wird – wichtig ist, dass am Ende die Leistung auf den potentiellen Kunden passt.

Value Proposition Canvas

Geschäftsmodell

Ist die Wertschöpfung klar, sollte auch schon grob überlegt werden welche Partner und Ressourcen benötigt werden, über welche Kanäle Kunden akquiriert werden, welche Kosten entstehen und wie Geld verdient wird.Hierfür ergänzt das Business Model Canvas* perfekt das Value Proposition Canvas. (Kommt ja schließlich auch beides aus dem Hause Strategyzer.)

Business Model Canvas

Hypothesen aufstellen

Existiert nun eine prototypische Idee, potentielle Kunden und schon grobes Geschäftsmodell müssen diese Annahmen getestet werden.
Aus jeder Annahme die auf dem Value Proposition Canvas und des Business Model Canvas getroffen wurde, gilt es nun eine Hypothese zu extrahieren.

  • Wurde angenommen, dass Unternehmen sich mit Bloggern vernetzen möchten, um ihr Image zu verbessern, könnte eine Hypothese beispielsweise lauten: „Unternehmen möchten sich mit Bloggern vernetzen um ihr Image zu verbessern.“
  • Eine andere Hypothese könnte lauten: „Blogger möchten sich mit Unternehmen vernetzen, um ihre komplette Lebenshaltungskosten zu verdienen.“

Am Ende bestehen eine ganze Liste von Annahmen. Um nicht alle auf einmal zu testen, werden diese nach Priorität sortiert. Sollten sich wichtige Annahmen als falsch herausstellen, müssen weniger wichtige vielleicht gar nicht mehr getestet werden.

Hypothesen

Hypothesen

Experimente überlegen

Bestehen Hypothesen, so müssen diese als nächstes getestet werden.
Um die These „Unternehmen möchten sich mit Bloggern vernetzen um ihr Image zu verbessern“ zu verifizieren könnte eine Google AdWords Kampagne rund um die Suchbegriffe „Blogger Relations Image“ aufgesetzt werden. Die These könnte bestätigt werden,, wenn beispielsweise mindestens 2% der Suchenden auf die Werbeanzeige klicken. Wichtig ist, dass das Erfolgskriterium vorher festgesetzt wird – ansonsten wird das Ergebnis nur interpretiert.

Nach der Auswertung werden die Canvas-Annahmen verbessert und für die neuen Annahmen neue Hypothesen formuliert. Die Annahmen können immer konkreter werden.

Bei digitalen Geschäftsmodellen kann auch schon recht früh eine einfache Landing-Page aufgesetzt werden, um zu testen wie viel potentielle Kunden bereit sind zu bezahlen. Erkenntnisse daraus fließen dann wieder zurück in euer Geschäftsmodell.

Dazu eignet sich eine Beta-Anmeldung oder eine Umfrage. Je konkreter die Call To Actions sind, desto aussagekräftiger die Messwerte.

Google Adwords Experiment

Google Adwords Experiment

Wir haben doch keine Zeit

So wird Stück für Stück die Theorie auf dem Canvas getestet, anschließend ob für die angebotene Lösung überhaupt ein Markt da ist und schlussendlich sogar wie das komplette Business mit allen weiteren Akteuren (Angestellte, Partner, Dienstleister) aufzogen wird.
Tatsächliche Leistung wird erst erbracht, wenn zahlende Kunden dafür existieren.
Bei einem solchen Ansatz wird nicht nur das eigene Risiko und Investment minimiert, sondern ein Geschäftsmodell direkt am lebenden Markt und unter realitischen Marktbedingungen getestet.

Am Ende nur noch ein Tipp: Verschwendet nicht zu viel Zeit mit nachdenken. Macht lieber. Der Aufwand für die erste Iteration und bis zu ersten Erkenntnissen dauerte bei meinem aktuellen Projekt lediglich 3 Manntage – ist also innerhalb einer Woche gut durchzuziehen – und bewahrt einen davor noch weitere 2 Monate einer fiktiven Idee hinterherzurennen.

Hauptsache keine Zeit verlieren. Das geht übrigens auch ganz ohne fancy Whiteboards am eigenen Esstisch. An was genau ich da gearbeitet habe, erzähle ich ein anderes mal – wenn die Experimente erfolgreich waren.

Wie testet ihr eure Geschäftsmodelle?

Sharing:
Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedIn
IMG_0287
Kommentare 0

Prozesse in der Kreativwirtschaft: Ein großes Missverständnis

Die puristische, reine Lehre nach einem immer gleichen agilen Prozess erscheint mir inzwischen schon fast wie der heilige Gral. Unereichbar und vor allem ein frommer Wunsch. Eine immerwährende gute Ausrede für den Entwickler – „Agil wäre das nicht passiert!“ – und trotzdem im Alltag schwer umzusetzen.

Auf der anderen Seite sind Marketing-Abteilungen, die von Kampagnen pixelgenaue Designs abnehmen wollen, weil sie das seit 5 Jahren schon so machen. Feedback zur wirklichen User Experience, welches über „Logo muss größer“ und „dies muss noch etwas roter“ hinausgeht, kommt dann oft erst, wenn zum ersten mal getestet wird. Und dann fängt man nochmal von vorne an.

Ein Dienstleister muss nicht jedem Kunden einen  Prozess aus dem Lehrbuch aufdrücken.

Anstatt von einem perfekten Prozess zu träumen, den der nie implementiert werden kann, sollte das was an agilen Methoden und responsiven Prozessen auf dem Markt ist, als Toolset begriffen werden.

Wie aus jedem guten Werkzeugkasten kann sich dieser und jener Tools bedienen werden, wenn sie Sinn ergeben. Es gibt für mich kein richtig oder falsch, solange es funktioniert und alle zufrieden sind. Dafür müssen aber auch alle beteiligten – inkl. Entwickler schon früh genug in die Prozessgestaltung mit einbezogen werden.

Von welchen Tools spreche ich?

Nun, es gibt eine ganze Menge an Tools im Digitalen: Eine Obermenge an abstrakten Methoden / Prozesse zerlegt sich in einzelne Tools. Um nur mal ein paar zu nennen:

Einsatz abhängig von der Zielstellung

Anhand von 3 üblichen Cases möchte ich mal zeigen, wie die diversen Toolsets in unterschiedlichen Reihenfolgen angewendet werden können. Your mileage may vary.

Case 1: Produktentwicklung

Wenn ein Startup gegründet wird oder ein Service designed wird, ist das Business-Ziel oft (einigermaßen) klar, aber noch nicht der Weg da hin. Da eignet sich dann ein Scrum aus dem Lehrbuch schon relativ gut. Die maximale Nutzung und Zufriedenheit des Teams ohne unnötigen Overhead. Darüber machen sich genügend Menschen Gedanken – hier soll es mehr um die Dienstleister-Seite gehen. (Links zu Scrum Blogposts)

Case 2: Homepage-Relaunch

Bei einem klassischen Homepage Relaunch für ein mittelständisches Unternehmen oder eine Organisation, welches keine digitalen Produkte vertreibt, wird ja oft das Rad nicht neu erfunden. Es existieren bereits viele Inhalte und Informationen, welche neu strukturiert und gegebenenfalls aktualisiert werden müssen. Die UX Herausforderungen sind punktuell – größere Änderungen an der UX sogar kontraproduktiv und vielleicht gar nicht erwartet. (Siehe All Websites Look The Same http://www.novolume.co.uk/blog/all-websites-look-the-same/). Bei diese Aufgabenstellung kann ein Prozess beispielsweise wie folgt aussehen:

  • Technische Planung und Aufsetzen der Beta-Plattform
  • Designkonzept für ein generelles Look and Feel
  • Erste Seite (z.B. Produkt) direkt auf der Plattform umsetzen gestalten und programmieren
  • Gleich mehrere nächste Content-Seiten am Block und direkt auf der Beta-Plattform umsetzen, um Synergie-Effekte zu nutzen.
  • Dann mit dem minimal nötigen Featureset eine Version 1.0 releasen
  • Im laufenden Betrieb dann die etwas aufwändigeren Features entwickeln.

Case 3: Kampagnen

Bei Kampagnen verhält es sich genau umgekehrt. Hier wird das optische Rad oft nicht neu erfunden, sondern nur auf ein Highlight übertragen, welches allerdings meist eine ziemliche Herausforderung in der UX mit sich bringt – man will ja überraschen.

  • Kommunikationsstrategie und Kreativkonzept
  • Prototyping der UX (gegebenenfalls zuerst auf Papier)
  • UX in einen Prototyp implementieren und testen, testen, testen.
  • Ein Design entwickelt Stück für Stück den Prototyp zur fertigen Kampagne weiter
  • Launch und kurz darauf wieder alles Löschen ;)

Macht einfach eine pragmatische Projektplanung..

Vergesst nicht: Der Kunde ist der Experte für das Produkt oder sein Unternehmen. Ihr seid die Experten für das digitale. Sprecht seine Sprache und drückt ihm keine Begriffe auf, die er nicht versteht oder die ihm Angst machen. Überfallt ihn nicht, wie von einem anderen Planeten.

Also redet nicht von Sprints, sondern macht einfach eine grobe Projektplanung, macht ihm klar was er bis wann feedbacken muss und aktualisiert diese regelmäßig.

Sagt ihm ruhig, dass die Planung speziell für ihn und sein Projekt so ist und das ihr das nächste mal wieder schaut, was die beste Art ist, dass Projekt zu planen.

.. und beherzigt dabei diese Dinge

Aus allen Tools und Werten, die das agilen Projektmanagement und der responsive Webdesign Prozess zur Verfügung stellt habe ich folgende Dinge als essentiell erkannt:

  1. Immer ein lauffähiges Produkt haben. Änderungen sollten immer so nah am tatsächlichen Produkt gemacht werden, wie möglich. Also keine kompletten Screens designen, die weggeworfen werden, sondern so früh wie möglich die Styles auf die Plattform bringen und über konkrete Dinge sprechen. Das versteht auch ein Kunde.
  2. Weiter ist ein Mechanismus wichtig, um ständig reflektieren zu können, ob man auf dem richtigen Weg ist. Aber den müsst ihr nicht Retrospektive nennen, sondern könnt ihn einfach auf die Agenda des „Jour Fix“ setzen.
  3. Experimentieren und Erfahrungen sammeln. Nutzt die Methodne und deren Tools, die es gibt! Bevor ihr zusammenstellen könnt, was für das jeweilige Projekt am besten ist, müsst ihr auch Erfahrungen damit gemacht haben. Also macht gezielt Experimente, wenn es sich anbietet.

Die Ironie der agilen Methoden

Die Ironie an der Sache ist ja, dass wenn man sich zu 100% an eine „agile Methode“ hält, man ja schon eigentlich nicht mehr agil ist. Die Arbeit wird nur von einer anderen Methode diktiert. Ein Appell zum Nachdenken.

Weiterführende Lektüre gibt es bei Andy Hunt, Autor des Alltime-Klassikers The Pragmatic Programmer, – vergesst auch nicht, den zweiten Teil seines Posts zu lesen.

(Das auf dem Bild oben ist übrigens ein Artbot, gesehen auf der Makerfaire.)

Sharing:
Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedIn
IMG_5278
Kommentare 0

Phase 2: Der Berliner mit seinen Projekten am Laufen

Er wird zwar oft belächelt, doch der Berliner mit all seinen Projekten „am Laufen“ steht für ein intaktes Innovations Ökosystem. Im folgenden einige Gedanken, die mir auf der Suche nach meinem nächsten Geschäftsmodell so kamen.

Jeder kennt die Situation: Man lernt jemanden kennen und möchte etwas über ihn lernen. Man fragt: Und was machst du so – beruflich? Aus dem „Irgendwas mit Medien“ von früher wurde inzwischen ein „Ich habe da so ein Projekt am Laufen“. Viele Menschen (meistens mit einem festen Job oder nicht aus/in Berlin) machen sich darüber lustig. Symbolisch steht für mich dafür das Lied „Ich will nicht nach Berlin“ von Kraftclub:

Ich habe da gerade so n‘ Projekt – super!
Noch nichts konkretes, aber sehr geil
Businessmäßig hab ich mich da noch nicht festgelegt
Irgendwas im „creative“ Bereich – Auf jedenfall!
Bloß kein nine to five job – ?? – find ich ja mega ätzend!
Genau, ich mach einfach einen Fashion Blog – geil!
Und laufe dann mit meiner Spiegelreflex durch Friedrichshain
und mache Fotos, von „Streetern“ und intressanten Leuten
Hauptsache hier in Berlin!

Ich möchte heute mal eine Lanze für diese Projekte brechen. Weil das ist eigentlich ganz gut. Viele großartige Unternehmen, die ein wirkliches Problem lösen, starteten mal als Projekt. Eben weil der Bedarf dafür da war.

Projekte-Darwinismus: Natürliche Selektion

Das Positive vorab: Aus einem Projekt zu starten ist erst mal ungezwungen. Man muss sich noch nicht Vollzeit verpflichten und gründet noch keine Firma. Es kann sich ganz natürlich entwickeln und wie es sich entwickelt, wird es für alle passen. (Oder halt nicht.)

Auf dem Weg eines Projektes zum Erfolg oder einem richtigen dauerhaften Unternehmen muss ein Projekt einige Hindernisse nehmen und sich anpassen. Im Prinzip Darwinismus. Das stärkere Projekt setzt sich durch:

  • Soziale Einflüsse: Weil es mit den einen Menschen besser passt, als mit den anderen.
  • Umwelt-Einflüsse: Weil der Markt dafür da ist und der richtige Zeitpunkt gekommen ist.
  • Wirtschaftliche Einflüsse: Manche Projekte bezahlen einfach die Miete.
  • Genetische Einflüsse: Oder schlicht weil man mehr Bock auf eine Sache hat.

Auch die ganzen Fashion Blogs die Kraftclub besingt (und die keiner braucht) werden wieder verschwinden. Deren Autoren werden daraus (hoffentlich) Erfahrungen gezogen haben, die sie weiterverwenden. Das ist natürliches Element einer natürlichen Auswahl ihres eigenen Projektes im großen Markt. Und das eigentlich auch ganz ok.

So schließt sich der Kreislauf wieder: Projekte kämpfen natürlich nicht nur bei den initiierenden Menschen ums überleben, sondern später natürlich auch auf dem Markt.

Regeln für das eigene Überleben

Man sollte sich emotional nicht zu sehr auf einzelne Projekte versteifen. Die Chance, dass sich ein Projekt wirklich durchsetzt weil es z.B. im Projekte Pool von jemand anderem nicht überlebt, ist relativ hoch.

Wenn man sich auf wirkliche „Spaß Projekte“ einlässt, sollte einem auch klar sein warum. Vielleicht möchte man sich weiterbilden. Kann in dem Kontext ganz ungezwungen eine neue Programmiersprache oder ein neues Framework einsetzen. Man sollte zumindest eine These formulieren können, was man sich davon erhofft.

Jedes Projekt sollte zumindest irgendwie getrackt werden. Selbst bei einem Bier formulierte Projekte sollte man aufschreiben. Mindestens in einer Liste, noch besser natürlich in einem Kanban oder Trello.

Und dann einfach das machen, was einem Spaß macht. Am besten ruhig mal alleine loslegen und erst mal rumexperimentieren. Dadurch, dass etwas passiert, schafft man ja auch Anreize, die das eigene Projekte bei den anderen mit ihren eigenen vielen Projekten wieder attraktiver macht.

Das große Ganze

Was ich jetzt mit den Projekten beschrieben habe, trifft ja nicht nur auf mich zu sondern auf jeden! Jeder hat ganz viele kleine Projekte, von denen er selbst noch nicht weiß welches sich durchsetzt und die untereinander konkurieren. Der eine macht es bewusster, der andere unbewusster. Interaktionen mit anderen Menschen sorgen für neue Impulse und reichern diese Projekte an.

Man darf nur nicht alles auf eine Karte setzen. Die Ironie daran ist ja: Eben weil nicht nur man selbst so viele Projekte am laufen haben, sondern auch jeder andere, wird aus einem einzelnen Projekt selten das große Ding. Also mal rein quantitativ gesehen.

Dazu  kommt noch, dass jeder Angst hat, das nächste große Dinge zu verpassen. Jeder möchte eigentlich ständig was anderes machen, was einem (mehr) Spaß macht. Das ist ganz tief in uns einprogrammiert. Das ist der Kampf ums Überleben – nur heute nicht mehr in einer steinzeitlichen Höhle, sondern bei einem „Käffchen“.

(Auf dem Bild zu sehen ist übrigens der Blick vom sagenumwobenen St. Oberholz, Ursprung unzähliger Projekte in Berlin, auf den Rosenthaler Platz an einem fröstelnden Februar Nachmittag.)

Sharing:
Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedIn