Barcamp Liechtenstein

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.

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?

• 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…

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.

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!

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…

Was machen wir mit den Anforderungen, wenn sie in schriftlicher Form vorliegen? Wir müssen die Informationen bündeln und in eine Form bringen, die wir für die Umsetzung verwenden können.

Warum müssen wir so vorgehen?

Egal ob wir mit Extreme Programming oder mit dem Wasserfallmodell arbeiten, wir können die Anforderungen nicht einfach nur heruntertippen. Das heißt, können kann man schon. Aber dann kommt eine Software dabei heraus, die garantiert nicht erweiterbar und wartbar ist.
Ich mußte einmal ein PHP-Projekt übernehmen, das direkt von den Anforderungen in Code geschrieben wurde. Das war eine tolle Erfahrung!

In einer .php-Datei war Javascript, CSS, HTML, SQL und PHP-Code vereint. Für einen Prototypen, um schnell mal dem Kunden zu zeigen, wo die Reise hingehen soll, mag das so passen. Wenn wir später nur eine Änderung an der Datei vornehmen wollen geht es schief. Die Aufwände für die Weiterentwicklung steigen ins Unermessliche und am Ende muss alles neu geschrieben werden.

Was muss gemacht werden?

Um wirklich stabile Software erstellen zu können, muss die Software einer Systemarchitektur genügen. Die Architektur muss so ausgewählt werden, dass sie die Anforderungen abdecken kann. So muss eine Applikation, die für die Verarbeitung von Formulardaten erstellt wird, viele parallele Eingaben verarbeiten können. In einer Software für die Fahrtsteuerung eines  Autos muss vor allem die Realzeitanforderung abgedeckt werden. Es wäre ziemlich unangenehm, wenn das Auto erst die Wand durchschlägt und dann der Computer nachträglich das Lenkmanöver einleitet

Die Kundenanforderungen beschreiben das System von der Kundenseite aus. Das Detailkonzept beschreibt, wie das zu erstellende System die Kundenanforderungen abdecken wird. Eine 1:1 Abbildung wird es nicht geben. Der Zwischenschritt über das Detailkonzept ist notwendig. Über den Umfang des Detailkonzepts kann man streiten. Soll wirklich alles zuerst beschrieben und dann umgesetzt werden? Manchmal ist das nicht zielführend. Jedoch muss so viel beschrieben sein, dass eine abschließend definierte Softwarearchitektur vorhanden ist.

• Im ganz Groben kann man sagen, dass man iterativ vorgeht und zuerst ein paar Basiskomponenten erstellt.
• Der jeweilige Stakeholder kann nach relativ kurzer Zeit das Ergebnis ansehen und seine Anforderungen näher beschreiben.
• Auf diese Weise ist man stets im Kontakt mit seinen Stakeholder und wird die Bedürfnisse eher verstehen.
• Bei allen Arten der Anforderungsanalyse ist es vor allem wichtig zu wissen, dass die verschiedenen Stakeholder die Welt unterschiedlich sehen und beschreiben.
• Wenn vier Personen etwas sagen, können dabei mindestens vier unterschiedliche Ansichten entstehen.
• Die echte Wahrheit gibt es nicht.

Weitere Hinweise zu Extreme Programming gibts z.B. in den Quellen zu Requirements Engineering.

Vorgehen

• Beschreiben des Problems, eventuell mit Storybooks oder UML
• Offene Punkte herausschreiben
• Stakeholder beantwortet so gut er oder sie kann die offenen Punkte
• Einarbeitung in das erstellte Dokument
• Review über die Vorstudie

Mit nur schriftlichen Vorgehen ist die Gefahr extrem hoch, dass die Kunden nicht das bekommen was sie wirklich wollen.

Seid deshalb sehr vorsichtig mit nur schriftlicher Anforderungsanalyse.

Eigentlich gibt es gar kein Problem

Wie immer im Leben gibt es verschiedene Sichtweisen und Erfahrungswerte. Hans hat zum Beispiel keine negativen Erfahrungen gesammelt:

Westaflex Markenwelt Lufttechnik Schallschutz Filtration » Blog Archiv » Blogparade Projektarbeit

In seiner Umgebung werden Projekte korrekt und mit den notwendigen Ressourcen durchgeführt. Der Projektleiter muss keine Brüllaffen-Mentalität besitzen und Projekte dienen, wie es laut Lehrbuch auch sein sollte, dazu ein Problem aus der Welt zu schaffen. Ich habe solche Erfahrungen ebenfalls gehabt. Eine Firma wollte ein neues Produkt einführen und ich hatte von Anfang an die Zielsetzung, den Umfang und das notwendige Team beieinander. Der Umfang war realistisch, das Team und die benötigten Kenntnisse ausreichend vorhanden und nach der Projektlaufzeit konnten wir erfolgreich abschliessen. Kein Brüllaffe und auch keine Prügelei um Mitarbeiter.

Oder gibt es doch ein Problem?

Georg bestätigte mit dem Beitrag Anders leben wollen: Projektleiter der Welt vereinigt euch! jedoch wieder, dass in einigen Firmen Projekte nicht sinnvoll aufgesetzt sind.

Ich habe in den letzten Wochen mit meinen Projektleiterkollegen über dieses Thema etwas mehr diskutiert. Sie haben zwar nicht bei der Blogparade mitgemacht, aber wir konnten im Betrieb erreichen, dass wir über die Verteilung der Mitarbeiter anders diskutieren. Wir haben zwar noch keine abschliessende Lösung gefunden, das wird auch nicht möglich sein, wir haben jedoch eine Basis gefunden und sprechen gemeinsam mit allen Beteiligten. Wir kommen ein wenig von der Ellbogenplanung weg.

Vielleicht ist die Definition eines Projekts einfach falsch?

Genial finde ich den Beitrag von Rick: Projektleiter = unter einem Projekt Leider
Er beschreibt auf eine wunderbar satirische Weise was Projekt und das Projekt (leiden) wirklich bedeutet. Vielen Dank für diese geniale Definition Wenn man mit Humor an die ganze Sache herangeht ist die Welt wesentlich einfacher und eigentlich auch logischer.

Ich danke Euch für Eure Beiträge!

Brainstorming Sessions

Mit Brainstorming Sessions können schnell diverse Anforderungen klar gemacht werden.

Eine mögliche Vorgehensweise:

• Die verschiedenen Stakeholder (Betrieb, Auftraggeber, Anwender, Entwickler usw.) werden eingeladen.
• Es ist schon einigermaßen klar was wir überhaupt bauen wollen, z.B. eine neue Geldwaschmaschine )
• Zu den einzelnen Aspekten werden einleitende Fragen erstellt. Beispielsweise könnte man Fragen was die Bedienbarkeit der Geldwaschmaschine ausmachen soll.
• Man sollte nicht zu viele Fragen erarbeiten. (Zum Beispiel vier Fragen pro Session)
• Nun wird die Frage gestellt und alle Beteiligten dürfen zehn Minuten lang alle Ideen, seien sie noch so verrückt, sagen. Die Ideen werden aufgeschrieben.
• Nach zehn Minuten werden die Ideen angesehen und geordnet.
• Aus den gesammelten Ideen können die wirklich unsinnigen gemeinsam gefunden und entfernt werden. Alle weiteren Ideen werden nach Wichtigkeit geordnet und später ausformuliert.

Mit dieser Vorgehensweise können sehr komplexe Themengebiete eingegrenzt und Lösungen dafür gefunden werden.

Gute Idee ::: Stakeholder

Eine wirklich gute Idee ist es, sich mit den betroffenen Stakeholdern zusammen zu setzen und sie zu fragen was sie wollen.

Damit das einigermaßen geordnet gehen kann, verwende ich meistens folgendes Vorgehen.

Vor dem Interview

Ich mache mir vor dem Interview klar, welche Anforderungen und welche Sprache der jeweilige Stakeholder verwendet.

• Ein Betriebsmitarbeiter spricht sehr technisch und will vor allem verstehen welche Auswirkungen die neue Software auf seine übrigen Systeme hat.
• Ein Auftraggeber hat Vorstellungen von dem was er will. Im Normalfall ist er nicht in der Lage die Vorstellungen in einer IT-geeigneten Sprache zu formulieren.
• Ein Anwender kann, falls es sich um die Ablösung eines bestehenden Systems handelt, noch sagen was ihm daran gefallen und nicht gefallen hat. Er oder sie wird viele Ideen haben und keine Idee konkret formulieren können.
• Ein Zulieferer wird sein System perfekt verkaufen und einem das Gefühl geben, alle Probleme der Welt auf einmal mit der neuen Software lösen zu können.
• Ein Partner, der an das zu erstellende System angebunden werden soll, wird so wenig wie möglich Auswirkungen auf sein System haben wollen.

Zusammenstellen von Fragen

Für die jeweiligen Stakeholder stelle ich einen Fragekatalog zusammen. Im Interview kann ich somit das Gespräch etwas steuern. Wichtig ist hierbei, dass die Gesprächspartner nicht zu sehr von den Fragen manipuliert werden. Sie sollen immer noch ihre Wünsche und Ansprüche formulieren können.

Während des Interviews

Im Interview versuche ich die Erkenntnisse jeweils in grafischer Form aufzuzeigen. Ich erstelle grobe Systemübersichten, Business-Abläufe usw.
Diese lasse ich mir im Interview von dem jeweiligen Stakeholder bestätigen.

Nach dem Interview

Nach dem Interview schreibe ich die Erkenntnisse in der Vorstudie zusammen und lasse sie vom Stakeholder nochmals gegenlesen.
Hiermit können ziemlich viele Fehlinterpretationen direkt beseitigt werden.

Falls jedoch Fussballfans erst Zeit haben, sobald es einen spielfreien Tag gibt, wird verlängert bis einschließlich Dienstag, 24. Juni 2008 (damit sind es zwei spielfreie Tage der Euro 2008):

Projektleiter der Welt vereinigt euch!

Die Blogparade möchte Antworten von euch zu folgenden Fragen

• Was sind eure Erfahrungen?
• Arbeitet ihr mit euren Projektleiterkollegen zusammen oder führt ihr ein Einzelleben?

Selbstverständlich könnt ihr sowohl in den Kommentaren, als auch mit eurem Blog teilnehmen.

Wäre fein, wenn sich noch der ein oder andere beteiligen würde…

Die Blogparade Projektleiter haben wir, ebenso wie die Verlängerung bei blog-parade.de eingetragen, ein Service, bei dem Blogparaden gesammelt werden.