Zeiterfassung für Entwickler: Eigene Stunden

Zeiterfassung für Entwickler kann ein persönliches Protokoll deiner eigenen Stunden sein. Du brauchst dafür weder ein Editor-Plugin noch ein Programm, das Screenshots aufnimmt.

Das Protokoll zeigt, warum eine kurze Aufgabe die Woche beanspruchte. Es benennt Arbeit besser als „Verschiedenes“ und addiert die Zeit für Besprechungen.

Wozu das Protokoll dient

Ein persönliches Zeitprotokoll kann vier praktische Fragen beantworten:

1. Was habe ich diese Woche wirklich getan? Zum Rückblick liefert es eine datierte Arbeitsliste statt „an der Plattform gearbeitet“.
2. Wie viel kostet eine Aufgabe tatsächlich? Vergleiche Schätzung und Stunden, um übersehene Teile zu finden.
3. Wohin ging die Woche? Trenne Funktionen, Fehlersuche, Prüfung, Besprechungen und ungeplante Nebenarbeiten. Eine Besprechungssumme ist eine konkrete Gesprächsgrundlage bei konkurrierenden Prioritäten. Zähle Vorbereitung mit, wenn du den ganzen Aufwand sehen willst.
4. Was berechne ich? Bei direkter Kundenabrechnung brauchst du Stunden mit verständlichen Notizen.

Führe ein einfaches Protokoll für dich: woran du gearbeitet hast, für wen und wie lange.

Nutze manuelle Zeiterfassung mit einigen Besonderheiten der Entwicklung.

Der kleinste nützliche Entwicklereintrag

Halte jeden Eintrag so knapp, dass du ihn wirklich schreibst:

Die Notiz liefert die wichtigsten Angaben. „PROJ-142: Race Condition im Bezahlvorgang behoben“ ergibt auch beim Rückblick oder auf einer Rechnung Sinn. „Programmiert“ nicht.

Falls der Eintrag zu einem Kunden oder Vorgesetzten gelangen könnte, benenne das Ergebnis in deren Worten: was behoben, veröffentlicht oder geprüft wurde. Die Probleme mit webpack gehören in eine private Notiz.

Widerstehe zusätzlicher Struktur. Du brauchst keinen Aufgabenbaum, der das Ticketsystem kopiert.

Halte Projekt- oder Kundenarbeit zusammen und markiere Fehlersuche, Prüfung oder Besprechungen für projektübergreifende Vergleiche.

An einem einfachen Tag reicht eine Notiz.

Ein Tag, der nächsten Monat noch verständlich ist

Hier ist ein hypothetischer Tag:

Die letzte Zeile ist eine Schätzung anhand der Notizen und des Kalenders. Ein späterer Commit hilft, die Aufgabe zu erkennen, legt aber nicht ihre Dauer fest.

Erfasse Arbeitsblöcke statt Editoraktivität

Ein IDE-Aktivitätsprotokoll lässt zwei Lücken in deinem eigenen Protokoll offen.

Ein offener Editor beweist keine Arbeit und ein geschlossener keine Pause. Bibliotheksdokumentation lesen, ein Datenmodell auf Papier skizzieren und nachdenken, bis die Fehlerursache klar wird, gehören zur Aufgabe. Erfassung nur im Editor kann diese Arbeit übersehen.

Außerdem können Projekt oder Zweck fehlen. Ein Repository- oder Fenstertitel kann das Projekt benennen. Eine allgemeine Dokumentationsseite sagt nicht unbedingt, welcher Kunde die Recherche brauchte.

Fehlen Bezeichnungen, musst du das Protokoll nachträglich deuten. Hier braucht automatische Zeiterfassung dein Urteil.

Ein Hintergrundprotokoll kann als Sicherheitsnetz dienen, das du später einordnest. Nutze es für Lücken im Blockprotokoll.

Nimm den Arbeitsblock als Einheit. Starte den Timer, wenn du mit einer Aufgabe beginnst. Stoppe ihn bei Aufgaben-, Besprechungs- oder Kundenwechsel und pausiere ihn bei Pausen. Eine kurze Notiz neben den Grenzen gibt dem späteren Rückblick Zusammenhang.

Dein Protokoll beantwortet deine Fragen. Du kannst es von einer möglichen Überwachung durch deinen Arbeitgeber getrennt halten. Halte die Notizen in dem Rahmen, den dein Arbeitgeber oder Kunde für Aufzeichnungen außerhalb seiner Systeme erlaubt.

Einen vergessenen Block zeitnah rekonstruieren

Ein Commit oder Pull Request erinnert dich an die Arbeit. Kalender und Nachrichten helfen, den Rest einzuordnen.

Schätze damit einen vergessenen Block und kennzeichne ihn als Schätzung. Zwei Commits im Abstand einer Stunde beweisen keine Stunde Arbeit. Dazwischen kannst du eine Pause gemacht oder die Aufgabe gewechselt haben.

Recherche und Fehlersuche können ohne Commit bleiben. Zähle sie mit, wenn du dich erinnerst, statt Codeänderungen mit der gesamten Arbeit gleichzusetzen.

Kannst du keine brauchbare Schätzung gewinnen, lasse die Dauer unbekannt. Erfasse beim nächsten Block während der Arbeit.

Nutze Stunden zur Prüfung deiner Schätzungen

Erfasst du den gesamten Aufgabenaufwand, siehst du den Vergleich mit deiner Schätzung.

Schreibe die Schätzung ins Ticket, erfasse die Aufgabe und vergleiche. Suche über vergleichbare Aufgaben hinweg nach zwei Dingen:

• Platz für übersehene Arbeit. Brauchen ähnliche Korrekturen regelmäßig mehr Prüfung und Tests als geschätzt, plane sie nächstes Mal mit ein. Lasse mehr Unsicherheit für unbekannte Arbeit.
• Ort der Überschreitung. Vergleiche Programmierung, Fehlersuche, Integration, Umgebungseinrichtung und Prüfung. Zeigt das Protokoll ein Muster, schätze die Teile getrennt.

Das funktioniert bei Festpreisen ebenfalls. Teile nach Abschluss das Honorar durch alle Stunden, um den Umsatz pro Stunde vor Kosten zu sehen. Nutze die Stunden für ähnliche Planung. Du könntest den nächsten Preis gegen Kosten und Einkommensziel prüfen, statt den Satz zu wiederholen.

Fehlersuche und Nacharbeit bei Kundenprojekten erfassen

Wenn du nicht für Kunden arbeitest, kannst du diesen Abschnitt überspringen. Fehlersuche und Nacharbeit gehen in einem vagen Entwicklungseintrag leicht unter.

Fehlersuche. Erfasse die Sitzung und beschreibe das Ergebnis: „Fehler mit doppelten Webhooks im Zahlungsablauf gefunden und behoben“ versteht ein Kunde.

Erfasse Tests, Fehlersuche und Nacharbeit getrennt, wenn dir das beim Rückblick hilft. Dein privates Protokoll kann auch Zeit enthalten, die nicht auf der Rechnung steht.

Markiere Nacharbeit klar, damit du ihren Zeitaufwand siehst. Der Artikel über abrechenbare und nicht abrechenbare Stunden hilft dir, das Protokoll zu ordnen.

Technische Sackgassen. Ein Konflikt zwischen Abhängigkeiten kann vier Stunden kosten, obwohl die Aufgabe klein wirkte. Erfasse die tatsächliche Dauer und beschreibe das Hindernis.

Wenn auf der Rechnung weniger Stunden stehen, behalte die vier Stunden in deinem eigenen Protokoll. Änderst du den ursprünglichen Eintrag auf „vielleicht zwei“, gehen Informationen verloren.

Halte auch Arbeit ohne Kundenauftrag sichtbar. Angebote, Rechnungen und das Lernen eines Frameworks, das kein Kunde verlangt hat, kosten Stunden derselben Woche. Lässt du sie weg, unterschätzt du, wie viel deiner Woche das Unternehmen braucht.

So nutzt du TimeRetain

Ein Entwicklerprotokoll enthält deine Systeme, späte Abende, wirkliche Besprechungszeiten und gegebenenfalls Kundennamen und Sätze. Du musst es nicht hochladen, um es zu führen.

TimeRetain ist ein manueller Timer für dieses Protokoll auf deinem Gerät. Du siehst Zeit für Prüfung, Besprechungen oder Fehlersuche und das Ergebnis jedes Blocks. Nichts beobachtet deine IDE.

Bei Rechnungen erklären die Notizen die geleistete Arbeit. Behalte nicht berechnete Nacharbeit im eigenen Protokoll, um den gesamten Projektaufwand zu sehen.

Das Hauptprotokoll bleibt auf deinem Gerät. Aktivierst du die Synchronisierung, speichert TimeRetain eine verschlüsselte Kopie auf seinen Servern.

Beginne mit einer Woche

Baue kein neues System. Erfasse eine Woche lang nur echte Arbeitsblöcke: Projekt oder Kunde, Beginn, Ende und eine einzeilige Notiz mit dem Ticket. Nutze Git und Notizen für Schätzungen vergessener Blöcke, solange der Tag frisch ist. Lass Lücken ohne ausreichende Grundlage stehen.

Lies das Protokoll dann durch. Vergleiche die Besprechungsstunden mit deinem Gefühl für die Woche. Vergleiche bei einer oder zwei Aufgaben den tatsächlichen Aufwand mit der Schätzung. Hilft das Protokoll beim Rückblick oder bei Rechnungen und erscheint dir der Aufwand lohnend, erfasse weiter.