miradlo bloggt

Seit heute haben wir buecherbrett.org geschlossen. Das bucherbrett war ein non-profit-Projekt, dieser Aufwand nur um es zu erhalten, obwohl es seit längerem nicht mehr aktiv genutzt wurde, war zuletzt nicht mehr vertretbar.

"buecherbrett.org hat geschlossen - danke" vollständig lesen

In der Session, die mit einer Vorstellungsrunde begann, kam gerade heraus, dass rundum den See verschiedene Initiativen gibt Coworking einzusetzen. Manchen geht es vor allem um die Zusammenarbeit, anderen eher auch um Nachhaltigkeit und soziales Engagement. Mein erster ernsthafter Kontakt zu diesem Thema war Haralds Session zu Coworking beim Barcamp Stuttgart.

Coworking versus Bürogemeinschaften

Was bringt denn Coworking, wenn es doch auch einfach Bürogemeinschaften gäbe? Die Räume gemeinsam nutzen ist ein Teil, das gibt es auch durchaus häufiger und ist eher geeignet für Startups, die sich noch keine eigenen Räume leisten können oder wollen. Bei Coworking geht es jedoch um mehr, nämlich um das gemeinsame Austauschen, wenn Freelancer oder Selbständige sich zusammen tun wollen. Viele wollen an sich schon selbst- und eigenständig zu arbeiten, aber zuweilen hätten sie gern Austausch mit Kollegen oder brauchen Spezialisten aus anderen Fachbereichen. Mancher möchte für Kundentermine nicht unbedingt grad das eigene Wohnzimmer nutzen. Coworking bietet die Chance die Vorteile der Selbständigkeit und eines größeren Unternehmens zu kombinieren.

Rundum die Region

Von Dornbirn mit Net-Culture-Lab, über die Ostschweiz, Benefactum aus Liechtenstein, Lindau usw. bis hin zu unseren eigenen Ideen es in Konstanz zu etablieren gibt es immer Menschen, die diese Idee spannend finden... Austausch von Kompetenzen ist eine ganz wichtige Seite der Coworking-Idee, die sich deutlich von reinen Bürogemeinschaften unterscheidet. Wie lässt sich gerade in der Region eine Vernetzung erreichen, gerade da manche schon hier ganz andere Hintergrundideen. Manche wollen schon eher in Richtung Nachhaltigkeit und Geminsamkeit. Als Ergebnis der Session ist eine weitere Vernetzung geplant. Diese soll im Wiki des Barcamps Liechtenstein angekündigt werden, so dass ein weiteres Wiki aufgesetzt werden kann, welches die Initiativen und Interessen derer vernetzt, die sich hier in der Region (Bodensee und rundum) für Coworking interessieren.

Ich finde Programmierbeispiele häufig ziemlich ungeschickt. Mal sind sie zu groß und zu kompliziert, mal sind sie zu einfach und können später nicht umgesetzt werden. Und da es so viele Programmierbeispiele gibt, möchte ich noch eines hinzufügen Ute hat mich mal gefragt, ob wir eine Newsfunktion erstellen können, mit der man auch ein paar Bilder einfügen kann. Soll heißen, dass aktuelle Informationen auf einer Webseite so lange dargestellt werden, bis sie nicht mehr aktuell sind. Also Weihnachtsgrüße sollen nur automatisch zu Weihnachten erscheinen und kurz vor Ostern können wir die abstellen Aussehen soll es ihrer Vorstellung nach, in etwa wie folgt:

• Newssystem erstellen

Newsüberschrift Ostergrüße

Neben dem Bild einer News soll die jeweilige Überschrift einer Meldung oder Neuigkeit stehen und anschließend der dazugehörige Text. Weiterer Text oder die nächste Meldung folgt dann erst danach. [Zumindest in standardkonformen Browsern klappt das... ]

Dieses Newssystem soll Bilder einpflegen können. Und da wir ja gerne komplizierte Sachen machen, sollen die Editoren, die die Texte schreiben, mit einem vernünftigen Rechtesystem ausgestattet sein.

Kurz gesagt: Wir wollen eine komplette Webapplikation bauen. Und wir sind Wiederholungstäter. In den letzten Jahren haben wir diverse Webapplikationen erstellt. Diesmal gehen wir jedoch einen etwas anderen Weg. Ich habe unter Newssystem erstellen beschrieben, wie das Newssystem aussehen soll und wir diskutieren dort im Internet über die Erstellung. Falls ihr mitmachen wollt, seid ihr herzlich eingeladen. Es geht darum, ein wirklich rundes und großes System zu erstellen mit dem wir später auch noch was anfangen können. Die Entwicklung wird wohl etwas langsamer vorwärts gehen, als wenn ich das Teil alleine schreiben würde. Aber vielleicht erfinden wir hier ein paar schönere und bessere Komponenten bei denen wir alle was lernen?

Schon in meiner Diplomarbeit habe ich dieses Bild verwendet, damals gabs keine deutsche Übersetzung, die für die Arbeit jedoch gefordert war. Daher habe ich aus der Bildquelle dann dieses Bild erstellt.

• Projektmanagement ::: was war gewünscht?
• Open-Source Version

Neu ist die Idee als solche bei weitem nicht. Dirk berichtete jetzt über neue und zusätzliche Cartoons, die es bislang nicht gab. Aber so ab und an, gibt es nette Ergänzungen, besonders schön, finde ich die Version für Open Source, das Original habe ich optisch ein bisschen an mein Ursprungsbild angepasst. Weitere, sehr nette Ideen, wie z.B. iSwing gibts bei projectcartoon. In meiner Diplomarbeit ging es damals um Requirements Engineering in Kundenprojekten, an der Thematik hat sich bis heute nicht viel geändert. Denn egal wie groß ein Informatikprojekt ist, egal mit welchen unterstützenden Werkzeugen Anforderungen aufgenommen werden, immer wieder passiert es doch, dass die Kundenanforderungen bei weitem nicht wie gewünscht umgesetzt werden. Ein für mich hierbei nach wie vor ganz entscheidender Punkt ist, den Kunden gleich zu Anfang genau zuzuhören, sehr genau nachzufragen, bzw. zu erklären, damit die Unterschiede am Ende möglichst gering ausfallen. Falls ich eine Wippe statt einer Schaukel für geeigneter halte, dann sollte mein Kunde sehr früh ja oder nein dazu sagen können...

Immer wieder steht man als Firma oder Projektleiter vor der Herausforderung die Projekte sinnvoll aufzusetzen. Wenn die Mitarbeiter in der Matrixorganisation bleiben, und die Projekte sich die Mitarbeiter teilen, enstehen folgende Vorteile:

• Wenn ich das Projekt in der Matrixorganisation betreibe ,gefährde ich den täglichen Betrieb nicht. Die Mitarbeiter sind in ihrer bestehenden Organisation und können schnell von einem Projekt zum Betrieb wechseln.
• Mehrere Projekte können sich dieselben Mitarbeiter teilen. Die Mitarbeiter müssen nicht zu 100% von einem Projekt finanziert und betreut werden. Mehrere kleinere Tasks können gleichzeitig abgearbeitet werden.
• Die Organisation bleibt stabil. Es gibt keine größeren Wechsel und die Mitarbeiter wissen über eine lange Zeit wo sie arbeiten.

Die Nachteile der Matrixorganisation für Projekte sind:

• Viele Projekte benötigten dieselben Mitarbeiter. Der einzelne Mitarbeiter muss sehr schnell zwischen verschiedenen Projekten umschalten und verliert an Effizienz.  Im schlimmsten Fall kann der Mitarbeiter keine Leistung mehr bringen, da er permanent zwischen den Aufgaben wechseln muss. Dies führt zu Frust und schlechten Ergebnissen.
• Bei strategisch wichtigen Projekten kann die Koordination innerhalb der Matrixorganisation dazu führen, dass der Projektfortschritt extrem gebremst wird.

Aus diesen, und natürlich noch vielen anderen, Gründen muss vor Projektbeginn nachgedacht werden welche Organisationsform zu wählen ist. Die Projektorganisation verursacht Unruhe unter den Mitarbeitern, da sie für die Projektlaufzeit nur für das jeweilige Projekt zur Verfügung stehen. Der Vorteil ist jedoch, dass sehr effizient und gezielt an einem einzigen Projekt gearbeitet wird. Je nach Zeitrahmen und Aufgabenstellung, kann es daher sinnvoll sein, eine Projektorganisation innerhalb einer Matrixorganisation zu etablieren.

Wir haben vor kurzem wieder mal ein Projekt gestartet und wie immer kam die Frage auf, ob wir wirklich alle Prozesse durchführen müssen. Die Fragen waren:

• Müssen wir ein proaktives Risikomanagement aufbauen?
• Braucht es ein Changemanagement?
• Ist ein Costtracking wirklich notwendig?
• Wieso brauchen wir ein Stakeholder-Management?
• Wer macht denn heute noch Support-Prozesse oder Incident-Management um Projekte an den Betrieb zu übergeben?

Wie immer gab es im Team mehrere Bestrebungen. Die Einen wollten am liebsten alle Prozesse aufsetzen und im Papierstapel ertrinken. Die Anderen wollten am liebsten gar nichts machen und einfach schnell mal das Projekt fertig stellen. Tja, da war also unser Dilemma. Entweder wahnsinnig viel schreiben, viele Protokolle erstellen, viele Dokumente unterschreiben und weiter leiten, oder schnell und schlank durchs Projekt schreiten und beim ersten politischen Rülpser unter die Räder kommen. Wir saßen also zusammen und stellten unsere Anforderungen zusammen. Wir wussten, dass dieses Projekt politisch nicht leicht werden wird. Es ist ziemlich dick und wir müssen viele Mitarbeiter an verschiedenen Standorten koordinieren. Das schreit nach viel Prozess, Planung und Koordination. Aber wie immer haben wir nicht viele Mitarbeiter, die uns beim Planen und Koordinieren helfen können. Das kostet Geld und ist für die Auftraggeber ziemlich nervig. Stellt euch vor ihr zahlt für den Umbau eurer Wohnung 10.000€ und davon für die Projektleitung 7.000€. Das würde euch sicher gefallen oder? Wie etwa nicht? Und da hat einer von unseren altgedienten Projektleitern eine super Aussage gemacht:

• Du kannst jeden Prozess weglassen.
• Du kannst in deinem Projekt auf alles verzichten.
• Mit jedem Prozess den du weglässt erhöht sich lediglich dass Risiko.

Und so haben wir uns auf ein hoffentlich vernünftiges Maß der eingesetzten Prozesse geeinigt. Wir lassen diverse Prozesse weg, oder behandeln sie etwas stiefmütterlich. Andere Prozesse, die wir wegen der Eigenheiten des Projektes als wichtig ansehen, setzen wir komplett um. Den Rest machen wir mit unserem Bauchgefühl. Denn wie schon Tom DeMarco sagte, das wichtigste Organ des Projektleiters ist der Bauch. Also dann auf ins Projekt und vertraut hier und da eurem Bauch! Ich für meinen Teil kann da auf einen relativ dicken Teil meines Körpers vertrauen Viel Spaß beim Leiten!

In den letzten Jahren bin ich von einem Projekt zum nächsten gesprungen und arbeitete mit Architekten, Projektmanagern, Systemspezialisten und Experten aus unterschiedlichsten Disziplinen zusammen. Ich eignete mir BPM, Design Patterns, UML, J2EE, PHP, EAI, SOA, Webservices, Web2.0 und vieles mehr an. Vor lauter dazulernen habe ich völlig vergessen, dass es auch Anfänger gibt, denen das Programmieren nicht in die Wiege gelegt wurde. Unser Azubi bei miradlo hat mir da die Augen geöffnet. Unsere Welt dreht sich extrem schnell und wir dürfen nicht stehen bleiben. Dummerweise müssen die "Neuen" auch irgendwie hinterher kommen. Da stellt sich nun die Frage, was sie alles lernen müssen und was wirklich nicht mehr benötigt wird.

Dinge die garantiert noch benötigt werden

Ich glaube beim Einstieg in die Programmierung sind die folgenden Themengebiete immer noch unumgänglich:

Boolesche Algebra

Das ist DIE Grundlage. Zum Einstieg sollten wirklich die grundlegenden Elemente erlernt werden. Im Internet findet sich genügend Dokumentation darüber; (siehe wikipedia oder IT-Wissen). In den Schulen sollte das auch unterrichtet werden. Leider sollte das nur unterrichtet werden. Bei manchen Schulen wird im ersten Lehrjahr alles mögliche unterrichtet, die benötigten mathematischen Grundlagen sind jedoch eher nicht gern gesehen...

Datentypen

Hier geht es weiter. Wenn man sich in die Programmierung einlernen will, sollte man sich mit den Standarddatentypen auskennen. (Siehe wikipedia) Es ist wichtig zu wissen, was folgende Datentypen bedeuten:

• bool
• int
• long
• double
• float
• String

Egal in welcher Programmiersprache. Irgendwie findet man diese elementaren Datentypen immer wieder.

Syntax der Programmierung

Wie in at-mix.de schön beschrieben, handelt es sich bei der Syntax um die Festlegung welche Zeichen miteinander kombiniert werden dürfen. Im letzten Jahr habe ich mehrmals Anfänger erlebt, die ihre Programme nach Form, anstatt nach Syntax erstellten. Wenn man das zuvor noch nicht gesehen hat, ist es schwer zu erklären. Vielleicht gelingt mir das mit einem Beispiel: Die Aufgabe war eine Überprüfung von Eingabewerten durchzuführen:

// Some other codeif(a > 10){

// do something which looks like a very long string

}else{

// do something else which didn't fit in this line. So you have to look what to do...

}

Der zu lange Text sah nicht gut aus und so wurde er umgebrochen:

// Some other codeif(a > 10){

// do something which looks like a very long string

}else{

// do something else which didn't fit in this line.

So you have to look what to do...

}

Wenn ihr euch ein bisschen mit programmieren auskennt, wisst ihr warum das keine gute Idee ist Der Code sieht zwar schöner aus, kann aber nicht mehr ausgeführt werden. Ein weiteres Beispiel, bei dem die Syntax nicht verstanden wurde, zeigt diese Zeile hier:

if(count($argv > 2)){}

Anstatt:

if(count($argv)  > 2){}

Na erkennt jeder den Unterschied?

Fazit

Im ersten Moment ist es irritierend, wenn man selbst diese Fehler lange nicht mehr macht. Doch es hat mir gezeigt, dass man vor lauter bunten Oberflächen, schnelleren Modellen und einem blinden Glauben an die Technik immernoch auf die Menschen achten muss, die diese Maschinen bedienen. Egal wie perfekt unsere Computer und Methoden werden, schlussendlich müssen wir sie bedienen und verstehen können, um wirklich nutzbringende Systeme erstellen zu können. Schaut euch mal ein bisschen um und überprüft ob alle in eurem Umfeld noch mitkommen...