Der Business Value von Zeiterfassung
von Rainer Stropek
Die Zeiterfassung hat einen schlechten Ruf. Niemand möchte genau rechenschaftspflichtig sein, wie sie ihre Arbeitszeit verbringt. Entwickler möchten programmieren, anstatt sich mit administrativen Aufgaben wie dem Ausfüllen ihres Stundenzettels herumzuschlagen. Meiner Meinung nach ist diese Einstellung falsch. Zugegeben, wir entwickeln Software für die Zeiterfassung, daher liegt das Thema mir natürlich am Herzen. Unabhängig davon glaube ich wirklich, dass eine gute Zeiterfassungspraxis ein großes Problem für viele Entwickler lösen kann: Sie kann helfen, ungeliebte technische Schulden loszuwerden.
Funktionen vs. Refactoring
Neben meiner Arbeit an time cockpit helfe ich oft Teams in Softwareunternehmen dabei, bessere Produkte zu entwickeln. Viele dieser Projekte beginnen mit einer Phase der Code- oder Architekturüberprüfung. Stakeholder beauftragen mich, den aktuellen Stand eines Projekts zu überprüfen und Feedback zu geben.
Hinweis: Vor einigen Wochen habe ich auf einer Entwicklerkonferenz einen Vortrag über C#-Codeüberprüfungen gehalten. Falls Sie interessiert sind, hier ist die Präsentationsfolien:
Während der Überprüfungsprojekte diskutiere ich oft mit Mitgliedern von Entwicklungsteams über die Gründe für technische Schulden. Im Detail variieren die Argumente von Unternehmen zu Unternehmen, aber es gibt einen gemeinsamen Nenner: Entwickler beschweren sich, weil ihre Manager nicht verstehen, dass Software kontinuierliche Modernisierung benötigt. Sie beschreiben, dass sie gezwungen sind, jeden Tag neue Funktionen hinzuzufügen, aber keine Zeit bekommen, um zu refaktorisieren oder notwendige Architekturänderungen zu implementieren. Sie sagen, dass Manager das Problem nicht verstehen würden, schließlich seien sie keine Entwickler.
Geschäftsfälle statt technischer Belanglosigkeiten
Entwickler haben mit dieser Diagnose oft recht. Manager, deren Aufgabe es ist, Budgets, Verkauf, Personal usw. im Auge zu behalten, verstehen nicht, worüber wir sprechen, wenn wir Entwickler darüber reden, wie wichtig es wäre, z. B. eine professionelle Abhängigkeitsinjektion zu einem Softwareprodukt hinzuzufügen, das aus ihrer Sicht nicht defekt ist. Das überrascht nicht, oder?
Als Entwickler müssen wir lernen, in geschäftlichen Begriffen zu argumentieren. Stellen Sie sich vor, Sie möchten ein bestimmtes Modul in Ihrer Software refaktorisieren. Präsentieren Sie diese Idee nicht voreilig Ihren Managern. Fragen Sie sich zunächst:
- Kann ich nachweisen, dass die aktuelle Situation wirklich ein Problem ist? Idealerweise haben Sie messbare Beweise.
- Kann ich das Problem und die geplante Refaktorisierung so beschreiben, dass auch jemand ohne Doktortitel in Informatik meinen Standpunkt versteht? Bereiten Sie eine Präsentation mit Visualisierungen vor und testen Sie sie mit Personen, die nicht so tief in der Technologie stecken wie Sie.
- Habe ich eine solide Schätzung bezüglich des Aufwands für die Refaktorisierung? Bin ich überzeugt, dass meine Schätzung einer kritischen Befragung meiner Manager standhalten wird?
- Habe ich plausible Argumente dafür, was nach der Refaktorisierung besser sein wird? Idealerweise basieren Ihre Argumente auf verständlichen Zahlen und Schätzungen.
- Kann ich meine Vorschläge mit den strategischen Plänen meines Unternehmens verknüpfen (z. B. verbessert die Refaktorisierung die Skalierbarkeit, die für die aggressive Wachstumsstrategie meines Unternehmens notwendig ist)?
Wenn das Denken in solchen geschäftlichen Begriffen für Sie neu ist, holen Sie sich Hilfe. Vielleicht haben Sie einen Scrum Master, der Erfahrung in der Erstellung und Präsentation von Geschäftsfällen für technologisch komplexe Themen hat. Sie könnten sogar den Manager, dem Sie Ihre Idee präsentieren möchten, um Hilfe bitten. Sagen Sie ihr, dass sie Sie durch den Evaluierungsprozess für Ihre Idee führen soll, damit Sie wissen, wie Sie sich in Zukunft in ähnlichen Fällen vorbereiten sollen.
Fakten, keine Bauchgefühle
Wie hängt das mit der Zeiterfassung zusammen, fragen Sie? Geschäftsfälle basieren weitgehend auf Fakten. Ein Vorschlag für eine technische Änderung, der ausschließlich auf Attributen wie “sauberer”, “einfacher zu warten”, “modern”, “elegant” usw. basiert, ist schwach. Er wird stärker, indem Zahlen hinzugefügt werden. Beispiele:
- In den letzten drei Monaten haben wir x Stunden für Supportfälle aufgewendet, die direkt mit dieser Schwachstelle unserer Software zusammenhängen. Wir glauben, dass dieser Aufwand durch die von uns vorgeschlagene Refaktorisierung um 75 % reduziert werden könnte.
- Ein erfahrener Entwickler, der neu in unserem Team ist, benötigte drei Wochen, bis er aufgrund der unnötigen Komplexität dieses Codeabschnitts erste produktive Änderungen vornehmen konnte. Mit unserem Refaktorisierungsprojekt könnten wir diese Einarbeitungszeit auf wenige Tage verkürzen.
- Unser Testteam musste x Wochen damit verbringen, das gesamte Modul erneut zu testen, weil wir keine geeigneten automatisierten Tests dafür haben.
- Im letzten Monat hat der Support x Stunden damit verbracht, y Kundenbeschwerden über die Leistung dieser Funktion zu bearbeiten. Unsere Telemetriedaten zeigen, dass die Leistung tatsächlich nicht zufriedenstellend ist. Wir glauben, dass wir dies durch…
- Ein Schnell-und-Schmutzig-Prototyp zeigt, dass wir die durchschnittliche CPU-Auslastung auf unseren Cloud-Servern um 25 % senken können, wenn wir die vorgeschlagenen Codeänderungen vornehmen. Damit könnten wir x Server ausschalten und jeden Monat y Euro sparen.
Für die Mehrheit aller Softwareunternehmen sind Personalkosten ein wesentlicher Kostenfaktor.
Daher ist es entscheidend zu wissen, wie das Entwicklungsteam seine Zeit verbracht hat, wenn es darum geht, Geschäftsfälle zu schreiben. Die Zeiterfassung, die Sie für die Lohnabrechnung durchführen müssen, reicht nicht aus. Sie müssen wissen, wie viel Zeit Sie z. B. für den Kundensupport, den internen Support (z. B. für den technischen Vertrieb), administrative Aufgaben, Prototyping, Tests, Dokumentation, die Entwicklung bestimmter neuer Funktionen usw. aufwenden.
Damit ist es nicht getan:
- Stellen Sie sicher, dass Sie ein professionelles Support-Ticket-Management-System haben.
- Stellen Sie sicher, dass Sie den Aufwand für alle Ihre Aufgaben schätzen. Vergleichen Sie den tatsächlichen Aufwand mit den Schätzungen und führen Sie eine Ursachenanalyse durch, wenn Sie das Zeitbudget wesentlich überschreiten.
- Beschaffen Sie sich eine integrierte ALM (Application Lifecycle Management)-Toolkette.
- Beschaffen Sie sich ein professionelles BI-Tool, mit dem Sie in die Zahlen eintauchen können.
Ihre Entwicklungsprozesse benötigen Telemetrie genauso wie Ihre Server oder Softwarekomponenten. Diese Telemetriedaten bilden die Grundlage für überzeugende Geschäftsfälle.
Aufbau von Vertrauen durch Präsentation von Ergebnissen
Vergessen Sie schließlich nicht, Ergebnisse zu präsentieren, sobald Sie Ihre Modernisierungsprojekte abgeschlossen haben. Sind Ihre Vorhersagen eingetreten? Haben Sie sogar die Erwartungen übertroffen? Auch hier ist es wichtig, die Zahlen zu haben, die beweisen, dass Ihr Konzept richtig war.
Regelmäßige Präsentationen messbarer Ergebnisse bauen Vertrauen auf. Wenn Sie das tun, wird es einfacher, Ressourcen für von Ihnen vorgeschlagene technische Verbesserungen zu erhalten.
