Archiv für den Monat: September 2005

Die 1000 Fehler in der Projektleitung: 6

Meetings
Kann man so stehen lassen. Meetings sind immer ein Fehler. „You either meet or work

Ok, um die Geschichte nicht ganz dramatisch werden zu lassen, hier ein paar Regeln:
1. Kein Meeting ohne Agenda. Zeit ist knapp. Ohne Agenda wird ein Meeting zur Plauderstunde. Ohne Agenda sprengt man den Zeitplan. Und vor allem wissen die Leute, ob sie überhaupt teilnehmen müssen.
2. Kein Meeting ohne Protokoll. Sonst bekommt man den „Das habe ich nie so gesagt“ Effekt. Entscheidungen müssen protokolliert werden, sonst bringt es später nichts mehr
3. Meetingprotokolle schnell verteilen. Spätestens nach einem Tag muss das Protokoll verteilt sein.
4. Reine Statusmeetings vermeiden. Status kann man per Mail/Report einfordern. Status kann man im kleinen Kreis klären. Aber ein Statusmeeting in großer Runde dient höchstens dazu, damit sich einzelne Teilnehmer profilieren und das andere Teilnehmer gedemütigt werden. Echte Ergebnisse kann man sehr, sehr selten erwarten.
5. Fester Anfang, festes Ende. Die Teilnehmer trödeln 15 Minuten nach Begin ein? Die ersten 10 Minuten wird über das Wochenende geplaudert? Da braucht man sich auch nicht wundern, wenn das Meeting wieder kein Ende findet…
6. Keine Diskussion über 3 Minuten! Was in 3 Minuten nicht geklärt werden kann, wird einer kleinen Runde übergeben. Wichtig: Feste Zuständigkeiten! Also nicht „Macht mal und sagt uns dann Bescheid“, sondern „Herr Foo, treffen sie sich mit Bar und Barz zu Klärung und schreiben sie uns bis Morgen Mittag ein kurzes Memo“

Eric S. Raymond bekommt Job-Angebot von Microsoft

Der ist gut: Eric S. Raymond, seines Zeichens OpenSource Evangelist, hat ein Angebot von Microsoft bekommen. Mail uns Antwort gibt es hier.
Aus seiner Antwort:

What were you going to do with the rest of your afternoon, offer jobs to Richard Stallman and Linus Torvalds? Or were you going to stick to something easier, like talking Pope Benedict into presiding at a Satanist orgy?

Panne bei Briefwahl in Dortmund

Ich durfte diesmal zweimal wählen…
Als ich meine Briefwahlunterlagen bekam war ich ein wenig verwirrt. Irgendwie konnte ich mit den Namen der Direktkandidaten nicht viel anfangen. Die Lösung kam letzte Woche per Post: Ich habe einen Wahlschein für einen falschen Bezirk bekommen.
Also durfte ich (wie 100.000 andere Wähler auch) ins Bürgeramt und nochmal wählen.
Jetzt frage ich mich schon, wie die meinen alten Wahlschein rausfischen wollen…

Die 1000 Fehler in der Projektleitung: 5

Mailtext: „Anbei Dokument XYZ mit Bitte um Feedback“
Wer mit solch schwammigen Bitten Dokumente verschickt soll sich nicht wundern, wenn nix passiert. Diese Mails landen bei den meisten Empfängern ganz hinten auf der ToDo Liste. Schlimmer noch: Die Menschen, die das Dokument lesen haben zuviel Zeit. Sso will niemand was von denen – und entsprechend möchte man von denen gar kein Feedback …
Wie immer: Feste Regeln, feste Termine.
Neuer Mailtext:“Anbei Dokument XYZ. Ich benötigte Ihre Anmerkungen bis spät. XX.YY. Sollte keine Reaktion erfolgen gehe ich davon aus, dass Sie mit dem Inhalt übereinstimmen“
Zwei Tage / zwei Stunden vor Ablauf der Frist eine Erinnerungsmail senden. Wer sich bis dahin
nicht gemeldet hat: Abnahme durch Nichtreaktion erteilt …

Die 1000 Fehler in der Projektleitung: 4

Niemals Dokumente zum Review verteilen und denken, sie würden gelesen.
Nehmen wir mal an, jemand bekommt per Mail ein Dokument mit der Bitte, Anmerkungen und Verbesserungen zu schicken. Oder vielleicht auch die Bitte und Freigabe. Dummerweise ging das Dokument an 10 Personen – das sieht man im Mail-Header. Was denkt sich der Empfänger? „Ich habe soviel zu tun, da habe ich kaum Zeit für ein Review. Aber egal, es schauen ja noch 10 andere Leute drauf, da kann ich ja einfach drüberfliegen“.
Dumm nur, dass dies jetzt 9 von 10 Empfängern denken. Anschließend wundern sich alle, dass das Ergebnis Murks ist.
Die bessere Lösung: Klar, wir alle haben einen hektischen Arbeitstag. Da kann man nicht immer verlangen, dass 50 Seiten Konzept wirklich gelesen werden. Aber vielleicht 5 Seiten! Wenn ich wirklich ein Review für meine Dokumente haben möchte, mache ich folgendes: Ich definiere „verantwortliche Redakteure“ für Teile des Dokumentes. Dann schicke ich das Dokument an die Personen und bitte sie, sich das Dokument anzuschauen und mir auf jeden Fall Feedback zu „ihrem“ Kapitel zu geben. Was passiert:
1. Der Druck, 50 Seiten lesen zu müssen fällt weg. ich verlange nichts unmögliches, sondern respektiere die knappe Zeit.
2. Ich schaffe einen Konkurenzdruck. Da jeder weiß, dass jedes Kapitel einen verantwortlichen Redakteur hat, fühlt sich der ein oder andere herausgefordert, ein Kapitel mehr zu lesen – vielleicht findet man ja was, was dem Kollegen nicht aufgefallen ist.
3. Wenn Fehler erst später zu Problemen führen kann man genau sagen, wer es verbaselt hat. Bei einem Reviewteam von 10 Personen ist man andernfalls eher selber der Dumme

Kirchhof und die Steuerschlupflöcher.

Ich mache irgendwas falsch:

Jeder Bürger müsse seine Steuerschuld selbst errechnen und nachvollziehen können, sagte Kirchhof. Es dürfe nicht länger sein, dass sich Gutverdiener mit 100.000 Euro Verdienst mit Hilfe der Ausnahmeregelungen auf eine Steuerschuld Null herunterrechneten, sagte das Mitglied des so genannten Kompetenzteams Kanzlerkandidatin Merkel.

Ich habe sowohl als Angestellter, als auch als Selbstständiger ein vernünftiges Gehalt bekommen. Aber ich habe meine Steuerschuld nicht auf 0.- EUR runterrechnen können. Offenbar bin ich der einzige Depp, der sich über 1-3tsd EUR Erstattung schon freut.
Ok, in meinem Bekanntenkreis sieht es ähnlich aus. Aber vielleicht sind das auch alles Deppen. Was ich mich allerdings frage: Wo um alles in der Welt sind die ganzen Leute die entsprechend Steuern sparen?!?
Wenn tatsächlich 25% Steuersatz kommen, werden ich (single, gutes Einkommen) mehr Geld haben als
vorher – genau wie bei den letzten Steuerreformen auch. Sorry Leute, aber das kann nicht richtig sein.

UML 2.0 ist Unfug

Auch wenn ich mich aktuell auf die UML Zertifizierung vorbereite und schon seit Jahren UML in Projekten einsetze: UML entwickelt sich in die falsche Richtung.
UML ist ein Analysewerkzeug, eine Brücke zwischen Anforderungen und technischer Architektur. Das bedeutet natürlich, dass die Anforderer die für ihn relevanten Diagramme auch versteht. Ansonsten brauche ich noch ein Dokument oder noch ein Verfahren um mich mit dem Kunden abzustimmen. Das klappt in der Praxis recht gut. Sogar einfache Sequenzdiagramme sind eine super Diskussionsgrundlage.
Und was passiert jetzt? Die OMG bohrt UML mit der Version 2.0 so auf, dass man aus dem Design gleich die Applikation erzeugen soll (MDA – Modell Driven Achitekture. Kurzer Einschub: Nein, das klappt nicht so wie behauptet). Der Haken: Die Diagramme werden immer überladener und unverständlicher.
UML entwickelt sich zu einer grafischen Programmiersprache. Das braucht kein Mensch!
Einige Leute mögen einwerfen das ihre Kunden UML Diagramme nicht verstehen oder erst gar nicht wollen. Natürlich sollte man nicht hingehen und dem Kunden erzählen „hey, wir machen jetzt in UML“. Aber wenn man gemeinsam an der Tafel Modelle entwirft, diese in einer Notation schreibt die a) verständlich und b) immer gleich ist, hat das riesen Vorteile. Kunden – auch Merketingleute – sind gar nicht so begriffsstuzig wie IT-Menschen immer glauben.

Ein Beispiel für verteiltes arbeiten

Viele Leute verstehen nicht, wie neben klassischen Vorgehensmodellen die verteilte Arbeit welche man z.B. in OpenSource Projekten findet funktioniert. Es erscheint unglaubwürdig, dass viele Entwickler ohne starke Führung schnele und qualitativ hochwertige Ergebnisse liefern können. Hier ist ein wunderbares kleines Beispiel dafür, das und wie es funktioniert.
Das Projekt Joomla! ist auf der Suche nach einem neuen Logo. Praktisch über Nacht wurden Entwürfe erstellt und diskutiert. Das passiert in diesem Forum.
Man kann folgende Struktur erkennen:
– Zum Start werden erstmal viele Ideen gesammelt (also eine Art „Brainstorming“).
– Daraus ergeben sich einige „Lieblinge“ (Konsolidierungsphase)
– Die guten Ideen werden weiterentwickelt (Entwicklungsphase)
– Immer wieder – wenn auch seltener – werden kommen komplett andere Vorschläge unterbreitet (eine Art Qualitätssicherung: Sind wir auch dem richtigen Weg? Gibt es noch bessere Wege?)
– Irgendwann gibt es dann ein Ergebns.

Und das alles ohne feste Meetings, ohne Moderation, ohne Projektleiter etc.
Seltsam, dass sehr wenige Firmen sich trauen, ihre Softwareentwicklung ähnlich auszurichten.