Bis wann, und wie lange schon: Zieltermine und Reaktionszeiten

Zwei Fragen hört man in jedem Projekt ständig: „Bis wann ist das fertig?“ und „Hat sich da überhaupt schon jemand drum gekümmert?“. Bis zu diesem Stand konnte GODAV Pro keine von beiden sauber beantworten. Es gab ein Feld „Fällig am“, das für sich allein stand, und für die zweite Frage gab es gar nichts. Mit 0.3.0 kamen der Zieltermin und die Reaktionszeit. Auf den ersten Blick sind das zwei Datumsangaben, aber sie funktionieren genau entgegengesetzt.

Ein Feld, das über den eigenen Vorgang hinausreicht

Der Zieltermin ist das erste Feld in GODAV, bei dem ein Vorgang nicht für sich allein steht. Eine Aufgabe, die bis Ende Mai fertig sein soll, unter einem Feature, das schon Mitte April fertig sein muss, ist ein Widerspruch. Deshalb prüft GODAV die ganze Kette vom Projekt bis zur Aufgabe.

Dabei musste ich einige Feinheiten entscheiden, die man erst beim Bauen bemerkt. Geprüft wird gegen das früheste Glied darüber und nicht nur gegen den direkten Elternvorgang. Sonst würde jede Kette stimmen, die von oben nach unten gepflegt wurde, und genau die Fehler würden durchrutschen, die entstehen, wenn später jemand weiter oben einen Termin vorzieht. Der gleiche Tag ist erlaubt: „Alles bis zum Meilenstein“ ist die häufigste Planung überhaupt, und wenn jede Ebene einen anderen Tag bräuchte, wäre genau sie nicht möglich.

Interessant wird es, wenn ein Vorgang wieder geöffnet wird. Solange er erledigt ist, bindet er nichts, und die Termine um ihn herum können sich weiterbewegen. Holt ihn jemand zurück, verletzt er plötzlich die Kette. Ich hätte an dieser Stelle eine Rückfrage stellen können, habe mich aber dagegen entschieden: Wer einen Vorgang wieder öffnet, will ihn wieder öffnen und nicht über Termine reden. Sein Termin wird deshalb still auf den bindenden vorgezogen, nur bei diesem einen Vorgang und nicht in seinem ganzen Teilbaum. Im Änderungsprotokoll stehen dann zwei Einträge, einer für den Statuswechsel und einer für den Termin, weil es eben zwei Tatsachen sind.

Der Zieltermin steht in der Box „Allgemein“ und ist änderbar. Die Reaktionszeit darunter lässt sich nur ablesen.

Wann ein Termin „erreicht“ ist

Erreicht ein offener Vorgang seinen Zieltermin, bekommen die Zugewiesenen eine Mail. Auf Board und Liste wird der Termin vorher gelb und am Termintag rot. Wichtig war mir, dass beides dieselbe Grenze benutzt: Der Termintag selbst zählt schon als erreicht. Sonst läge die Mail im Postfach, während die Karte noch „alles in Ordnung“ signalisiert.

Die Mail war der erste Auslöser in GODAV, den kein Mensch anstößt. Ein Kommentar passiert einmal, „der Termin ist erreicht“ ist dagegen ab diesem Tag dauerhaft wahr. Deshalb merkt sich GODAV, für welchen Vorgang und welchen Termin schon gemeldet wurde. Wer den Termin verschiebt, macht damit eine neue Zusage und wird beim neuen Termin wieder erinnert.

Zwei Details dazu, die man nicht sieht:

• Gemerkt wird erst nach dem Versand. Andersherum würde ein Ausfall des Mailservers die Erinnerung für immer verschlucken.
• Geprüft wird alle 15 Minuten und nicht einmal am Tag zu einer festen Uhrzeit. Läuft die Anwendung genau zu dieser Uhrzeit nicht, wäre sonst der ganze Tag verloren.

Überschrittene Termine stehen rot auf der Karte. Abgeschlossene Vorgänge bleiben unauffällig, egal wie alt ihr Termin ist.

Die Reaktionszeit misst, statt etwas zu versprechen

Der Zieltermin ist eine Zusage über die Zukunft, deshalb lässt er sich ändern. Die Reaktionszeit ist eine Messung der Vergangenheit, deshalb lässt sie sich nicht ändern. Gemessen wird vom Anlegen bis zur ersten Zuweisung, zum ersten Statuswechsel oder zum ersten Kommentar, jeweils von jemand anderem als dem Erfasser.

Normalerweise leitet GODAV solche Werte bei jeder Abfrage neu ab, damit sie nicht auseinanderlaufen können. Hier habe ich mich bewusst für einen gespeicherten Zeitstempel entschieden. Nur im Moment des Wechsels steht fest, was „über ‚Neu‘ hinaus“ bedeutet. Statuswerte lassen sich später umsortieren und Kommentare löschen, und eine nachträgliche Rechnung käme dann zu einem anderen Ergebnis als damals. Gefragt wird übrigens nach dem festen Systemstatus „Neu“ und nicht danach, welcher Wert gerade an erster Stelle steht. Ein Wechsel von „Neu“ nach „Eingegangen“ ist schließlich keine Reaktion.

Eine Mitgliedschaft im Projekt verlange ich für die Reaktion nicht. Ein Administrator, der in keinem Projekt Mitglied ist und trotzdem antwortet, hat geantwortet. Würde man ihn nicht mitzählen, stünde eine beantwortete Meldung als unbeantwortet da.

Was bewusst noch fehlt

Auf der Roadmap stand ursprünglich auch der Fixtermin. Ich habe ihn weggelassen, weil er eine eigene Entscheidung ist: Bindet ein zugesagter Termin die Kette genauso wie ein geplanter, und was gilt, wenn sich beide widersprechen? Auch eine Vorgabe wie „Reaktion innerhalb von vier Stunden“ gibt es hier noch nicht. Gebaut ist die Messung. Was man mit ihr auswertet, kam später mit den Berichten.