allein den Namen find ich schon erstklassig :) und erinnert mich an Fugengrau und Superkleber.

So why doesn’t anybody make a schedule? Two key reasons. One, it’s a real pain. Two, nobody believes that it’s worth anything. Why go to all the trouble working on a schedule if it’s not going to be right? There is a perception that schedules are consistently wrong, and only get worse as time goes on, so why suffer for naught?

die grundproblematik:

1) tasks / projekte werden nicht geplant
2) wenn sie geplant werden, werden sie falsch geplant (aufgaben vergessen, zeiten falsch geschätzt, overhead mit hilfe ms project, sap produziert)
3) wenn sie halbwegs ordentlich geplant werden / sind, sind änderungen (wir erinnern uns an das teufels quadrat) schlecht abbildbar und vorallem kommunizierbar
4) auch bei einer ordentlichen und aktuellen planung, hab ich immer noch das problem dass der status nicht gepflegt wird.
5) planung, nachvollziehbarkeit und steuerung verursacht einen erheblichen mehraufwand

Was dabei sehr interessant ist, dass die Problematik viele Verantwortliche (und vorallem Informatiker) sehr ähnlich wahrnehmen, wie z.B. http://www.joelonsoftware.com/articles/fog0000000245.html, was zu 80% meinen Überlegungen entspricht.

Mein lösungsansatz:

Zunächst einmal muss ich gestehen, dass mein Lösungsansatz zunächst nur das Teilproblem der Aufgabenverwaltung aufgreift. Allerdings ist es bewusst so gewählt dass man das Konzept zu einem späteren Zeitpunkt “aufbohren” kann – will heissen ob der PL die Planung für ein grösseres Projekt mit ms project macht oder doch lieber Visio oder einfache Text- und Tabellendokumente benutzt, überlasse ich jedem selbst. Die Aufgabenverwaltung / Terminplanung kann natürlich später auch im Lieblingstool der Wahl erfolgen, Outlook, Thunderbird etc. (das Zauberwort heisst API und Middleware-Funktionen)

So genug Lala, um was gehts eigentlich?

Ein Modell schaffen, dass die realen Gegebenheiten in realen (kleinen und mittleren) Unternehmen sinnvoll abbildet – und nicht die DIN-Norm für Projekt- und Arbeitsorganisation! und gleichzeitig die einfache Selbstorganisation fördert um Overhead zu minimieren.

Das führt dazu, dass ich einigen “unsauberen” Annahmen ausgehe.

– MA haben Linienarbeit und mehrere Projekte parallel
– Der Arbeitsfluß wird öfters von “Notfällen” unterbrochen
– Ein erheblicher Teil der Planung bzw. der Steuerung erfolgt on-the-fly, d.h. Features werden gekürzt um Termine einzuhalten oder “unglaublich wichtige” Features, die erst später im Projektverlauf dazu kommen, müssen vor dem Release noch rein.
– das System wird überhaupt nur genutzt wenn es nicht als 5 Minuten Zeit am Tag kostet und einfach ist
– das Arbeitsverhalten entspricht am ehesten dem Abarbeiten einer Queue
– Korrekturen Aufwandschätzung finden nicht Top-Down sondern Bottom-UP statt (der Bearbeiter erkennt das Ausmaß / Verzögerung als erstes)

Die Grundanforderungen an eine Lösung die sich daraus meiner Meinung ergeben …

– KISS
für den User
kein zusätzlicher Login notwendig, Kombination von Desktop- und Web-Technologie, kleine aber stressfreie Reminder (für das Timetracking), auf wenige Klicks optimiert, automatische Emails (auch hier wieder ohne zu nerven, also zb nur einmal am Tag oder sogar nur einmal pro Woche), doppelte Dateneingabe vermeiden (Taskliste im Client kommt aus der DB)

– KIESS (keep it extreme simple and stupid)
für den Kunden
Gehen wir davon aus, dass Kunden meistens extrem doof sind. Viel mehr als Email und Telefon können sie nicht benutzen, schon gar nicht ist die Erstellung von strukturierten Dokumenten, Vorgaben und Konzepten durch den Kunden möglich.

Zusätzlich haben Kunden das talent vollkommen unnötig zu nerven, z.B. durch Anrufe alle paar Stunden, wie lange es noch dauert oder warum dieses oder jenes “auf einmal” länger dauert.

Das führt zu folgenden “Funktionalitäten” für den Kunden

Der Kunde muss das System selbst per Email (und Telefon) füttern können.
Der Kunde braucht zeitnah eine Rückmeldung über Dauer (und / oder Kosten) und erwarteter Zeitpunkt der Fertigstellung.
-> grössere Aufgabe muss in Pool gestellt werden zur Aufwandsschätzubg
-> Wenn geschätzt und in Queue sortiert, Email raus mit Aufwand und wo es derzeit in die Queue steht

Automatische Statusmails
jede Woche (evtl auch jeden Tag) geht eine Mail raus, was ist in der letzten Zeitperiode gelaufen und was ist für die nächste Periode geplant

bei Änderungen vom Kunden
-> Funktionalität wird vom Kunden geändert, Email mit Auswirkungs-Warnung wird versendet (“Achtung dadurch ändert sich Termin / Zeit / Kosten / Qualitätsziel”). Evtl sollte man den Kunden das bestätigen lassen oder selbst festlegen lassen welche Ecke er anfassen will ;)

bei Verzug
-> Entwickler stellt eine neue “erwartete Dauer der Fertigstellung” fest, der Auftraggeber bzw. PL muss informiert werden.

Der Auftraggeber wird direkt eingebunden
kann die Reihenfolge / Priorisierung selbst ändern oder “Vorschläge machen”

Sonstige Feature Ideen

neben linienarbeit führen wir noch abwesenheitszeit ein … urlaub / krankheit

pro ma gibts einen ratio von planbarer zeit (80 / 20, 60 / 40) und definierbare wochenarbeitsstundenzeit

evtl. verbesserungen …
automatische subtasks für bestimmte arten von tasks
wenn ich einen task (neues feature anlege) wird auto

Ganz wichtig dürfte die Möglichkeit sein Vorgänge anzulegen, d.h. innerhalb der Linienarbeit ein Mini-Projekt, Prozess mit dynamischen oder festen Workflow oder Subtasks zu einem Task definieren zu können (auch innerhalb der Linie).

Beispiel: VServer Laura kündigen, als ich die Aufgabe angehe, stelle ich fest, dass wir ja den DNS Kram und Monitoring noch brauchen, aber wohin damit? Also brauchen wir noch einen neuen VServer auf Angelina. Ja wenn der DNS eh schon fertig ist, dann bitte schön auch richtig und nicht nur die üblichen 90% und dann nutzen wir das Teil auch endlich mal. Hm, dass muss ich dann noch die ganzen Sachen von Euhost abziehen.

Aus der usprünglichen Aufgabe sind 6 Miniaufgabe geworden, die eigentlich auch von unten nach oben abgearbeitet werden müssen / sollen.