In meiner Firma bin ich für mehrere Softwareentwicklungsteams verantwortlich. Kürzlich haben mich unsere Manager gebeten, ein Zeiterfassungssystem für unsere Entwickler einzurichten, damit sie einen besseren Überblick über die tatsächlichen Kosten bestimmter Projekte haben.
Ich verstehe die Absicht und sehe natürlich, dass es nicht nur einen Mechanismus geben muss, um Preise für unsere Kunden zu kalkulieren, sondern auch um die Leistung unseres Unternehmens und seine Optimierungspotenziale zu verstehen und zu interpretieren.
Da es viele Unternehmen gibt, die Tools für die Zeiterfassung verkaufen, und so ziemlich jeder an die Zeiterfassung gewöhnt ist, finde ich nur Informationen darüber, wie man die Zeiterfassung durchführt, aber fast nichts darüber, wie man mit der Situation auf der Grundlage anderer Metriken als der Zeit umgeht .
Der Grund, warum ich nach dieser Alternative suche, ist, dass ich das Gefühl habe, dass unser kürzlich ziemlich erfolgreicher Scrum-Prozess in Gefahr ist. Im Gegensatz zu anderen Teams in meinem Unternehmen liefern wir pünktlich, haben weniger Softwaredefekte und haben unsere Geschwindigkeit um ein Vielfaches deutlich erhöht.
Dafür brauchten wir keine Zeiterfassung und mir scheint, dass Dinge, die man als "Zeitverschwendung" bezeichnen würde, nicht mehr möglich wären. Um nur einige Beispiele zu nennen, für mich ist es in Ordnung, wenn die Entwickler Pausen machen, wann immer sie es für eine gute Idee halten. Manchmal habe ich den Eindruck, dass manche Arten von Pausen sogar die Produktivität steigern. Wenn das bedeutet, dass jemand weniger Stunden arbeitet als vertraglich vereinbart, bin ich damit einverstanden, solange die Gesamtergebnisse des Teams über dem Durchschnitt liegen. Das aktuelle Umfeld ermutigt Teamkollegen, sich gegenseitig oder sogar anderen Entwicklern zu helfen, die nicht Teil des Teams sind, wodurch das Team und die gesamte Organisation im Allgemeinen besser werden (= höhere Kapitalrendite).
Zeiterfassung würde diese Art von Zeit reduzieren und meiner Meinung nach könnte es eine Umgebung töten, die tatsächlich auf Motivation, Vertrauen und dem inhärenten Willen der Entwickler zum Erfolg basiert. Ich denke, da könnte viel Kreativität und das Streben nach Innovation gehemmt werden. Die Notwendigkeit, nicht nur die eigene Geschwindigkeit zu erhöhen, sondern auch die Produktivität anderer zu steigern, könnte verloren gehen. Ganz zu schweigen vom unnötigen Overhead der Zeiterfassung.
Sie werden zustimmen, dass Entwickler nicht in der Lage sind, 8 Stunden am Tag zu denken, ohne an einem bestimmten Punkt auszubrennen. Vor allem bei ständigem Termindruck oder anstrengenden Pair-Programming-Sessions wäre es für mich eine schlechte langfristige Entscheidung, „sicherzustellen“, dass die Entwickler all ihre Stunden „gearbeitet“ haben.
Ich finde sogar, dass die Zeiterfassung irreführend ist. Es werden keine tatsächlichen Kosten angegeben, sondern Schätzungen oder Näherungswerte. Es gibt viele Gründe für mich, eine Alternative zu suchen. Da der Zeiterfassungsansatz hauptsächlich von unserem "nicht-technischen" Management getrieben wird, scheint es bis zu einem gewissen Grad eine Forderung zu sein, zumindest etwas zu haben™, das es ihnen ermöglicht, mit der Situation umzugehen, weil sie einfach keine Ahnung von Software haben Entwicklungsprozesse und den Einfluss von Führungs- und Kontrollstrukturen auf Scrum. Sie würden sich freuen, wenn ich einfach einen Mechanismus bereitstellen könnte, der ihren Bedürfnissen entspricht und alle notwendigen Informationen bereitstellt.
Meine intuitive Idee war, die Entwickler zu bitten, ihre Story-Point-Schätzungen zu überprüfen und möglicherweise zu korrigieren, wenn sie ein Problem schließen. Dann könnte ich die Sprintgeschwindigkeit des Teams und die Gesamtkosten des Teams pro Sprint verwenden und die Projektkosten proportional berechnen. (Ich weiß, dies liefert nicht die tatsächlichen Kosten, aber auch keine Zeiterfassung.)
Und das ist meine Frage. Ist dies die übliche Art, die Kosten zu berechnen? Haben Sie bessere Ideen? Wie machst du das?
Wenn Sie Kosten nachverfolgen müssen, verfolgen Sie dies auf Scrum-Team-Ebene und nicht auf individueller Ebene.
Eine einfache Möglichkeit, dies zu tun, besteht darin, die gemischten Kosten pro Person zu nehmen und sie mit der Anzahl der Personen im Team und der Dauer der Sprints zu multiplizieren.
Zum Beispiel:
Die durchschnittlichen Personalkosten betragen 600 £ pro Tag und Scrum Team 1 besteht aus 7 Personen und führt einen zweiwöchigen Sprint durch. 600 x 7 x 10 = 42.000 £ pro Sprint
Wenn Sie mit Scrum arbeiten, können Sie diese Kosten jetzt mit dem Wert rechtfertigen, der in jedem Sprint freigesetzt wird. Alles, was Sie tun müssen, ist die folgende Frage zu beantworten:
Ist der Wert des Teams gleich oder größer als die Kosten pro Sprint?
Wie Sie den Wert ermitteln, bleibt Ihnen überlassen. Ein Beispiel könnte beinhalten:
Jetzt müssen Sie keine Zeit mehr damit verschwenden, Story Points oder Zeitschätzungen zu verfolgen. Konzentrieren Sie sich einfach auf den gelieferten Wert und die Sprintkosten.
Wie das Team bei der Bereitstellung vorgeht, ist ihm überlassen (Pausen einlegen, zusammenarbeiten, Wissen teilen usw.). Es ist das Endergebnis, das gemessen wird, nicht die Details, wie sie ihre Arbeit erledigen.
Während ich Barnaby zustimme, dass die Zeiterfassung (oder eigentlich fast alles ) auf Teamebene besser ist als auf individueller Ebene, stimme ich Ihnen zu, dass die Zeiterfassung überhaupt nicht ideal ist.
Die beste Vorgehensweise besteht darin, das obere Management davon zu überzeugen, dass dies eine schlechte Idee ist. Der effektivste Weg, dies zu tun, ist, wie Sie bereits festgestellt haben, eine Alternative.
Eine Sache, die ich Ihnen vorschlage, ist, die Teams selbst nach Ideen zu fragen. Wenn die Anzahl der Teammitglieder klein genug ist, könnte dies auf einmal geschehen. Wenn nicht, gehen Sie ein Team nach dem anderen vor, fassen Sie alle Ergebnisse zusammen und senden Sie sie anschließend per E-Mail (da einem Team möglicherweise etwas Neues einfällt, nachdem es die Idee eines anderen Teams gehört hat).
Dies würde nicht nur potenziell zu guten Ideen führen (und von Leuten kommen, die weit besser über Ihre Situation Bescheid wissen, als es Strangers on the Internet™ sein könnte), es wird auch die Zustimmung des Teams erhöhen. Selbst im schlimmsten Fall, wenn man sich nichts einfallen lässt, wird das Team zumindest froh sein, konsultiert worden zu sein, was einen der schlimmsten Nachteile der Zeiterfassung abmildern könnte – die gesunkene Moral.
Ein möglicher Ansatz (obwohl dies stark von Ihrer organisatorischen Umgebung abhängt, sodass Ihre Laufleistung variieren kann) besteht darin, das obere Management darauf hinzuweisen, wie viel besser Ihre Teams abgeschnitten haben als andere Teams (stellen Sie sicher, dass Sie Kennzahlen haben!). Sie können dann vorschlagen, dass das Unternehmen, anstatt Zeiterfassung einzuführen, von der Sie und Ihre Teams erwarten, dass sie allein ihre Produktivität senkt, sich stattdessen darauf konzentrieren könnte, diese anderen Teams dazu zu bringen, ähnlicher wie Ihre Teams zu arbeiten.