Mein Unternehmen hat kürzlich die Protokollierung von Stundenzetteln für jeden Einzelnen im Entwicklungsteam eingeführt. Ehrlich gesagt ist es ziemlich zeitaufwändig. Jedes Mitglied muss protokollieren, was es jeden Tag getan hat.
Sie erwähnten, dass der Zweck darin besteht, eine Historie eines Projektplans für spätere Bezugnahme bereitzustellen, aber manchmal sagen sie: „Lassen Sie uns überprüfen, was Sie kürzlich getan haben.“ Es fühlt sich an, als würde man uns nicht vertrauen.
Im Allgemeinen ist die Protokollierung ein Symptom für einen nicht agilen Entwicklungsprozess, der für das aktive Engagement und das Situationsbewusstsein eines Projektmanagers steht. Es ist auch oft ein Zeichen dafür, dass das Projekt das Falsche misst, da „Zeitverbrauch“ selten ein gültiges Maß oder ein Indikator für Ergebnisse ist. Wenn es nicht ausschließlich für vertragliche Abrechnungszwecke verwendet wird, wird es meistens fälschlicherweise als Tool zur Rechenschaftspflicht oder Ursachenanalyse verwendet.
Ergebnisbasiertes Tracking ist im Allgemeinen effektiver. Beispielsweise ist in Scrum eine Story am Ende eines Sprints entweder „done“ oder „not done“. Wie viel Zeit für welche Aufgabe im Sprint aufgewendet wurde, ist weitgehend irrelevant, obwohl Blocker und Warteschlangenprobleme sicherlich gültige Themen für eine Sprint-Retrospektive sind.
Die Verfolgung der Zeit ist für Abrechnungszwecke und angeblich für zukünftige Schätzungen nützlich. In Wirklichkeit sind Stundenzettel jedoch entweder eine Fiktion oder unnötiger Mehraufwand.
In der Fertigung kann es sich durchaus lohnen zu dokumentieren, dass es x Minuten dauert, y Geräte am Fließband herzustellen . Bei Wissensarbeit wie dem Programmieren lässt sich die Arbeit jedoch selten sauber in messbare Schritte aufteilen. Darüber hinaus geht es insbesondere beim Programmieren oft darum , über das richtige Problem nachzudenken , das es zu lösen gilt, so dass eine allzu granulare Aufzeichnung, die keine vollständige Fiktion ist, so aussehen könnte:
Wenn das Protokoll akribisch und ehrlich geführt wird, summiert sich die Zeit am Ende des Tages aufgrund von Aufgabenwechseln, Overhead und (natürlich) der Zeit, die für die Zeiterfassung auf granularer Ebene aufgewendet wird, einfach nicht auf 8 Stunden. Das macht das Protokoll weniger nützlich, als Manager vielleicht glauben möchten.
Eine vernünftige Zeitmessung ist tendenziell weniger granular. Ein vernünftiger Protokolleintrag könnte lauten: „Ich habe heute 6 Stunden mit der Arbeit am foo -Projekt verbracht und 2 Stunden mit Meetings, Zeiterfassung und anderem Projektaufwand.“ Diese Art der Protokollierung auf hoher Ebene ist jedoch aufgrund kognitiver Verzerrungen, Auslassungsfehler, sozialer Filterung und anderer Faktoren, die sie als gültige Messung weitgehend unbrauchbar machen, oft unvollkommen.
Agile Frameworks wie Scrum unterstützen implizit eine ergebnisorientierte Arbeitsumgebung . Während ROWE selbst ein Schlagwort und Marketingbegriff ist, ist das Konzept der Ergebnismessung (z. B. Wurde ein Ziel erreicht oder nicht erreicht? ) im Allgemeinen nützlicher als die Messung der Minuten pro Aufgabe. Auch hier benötigen Sektoren wie die Fertigung, die den Durchsatz messen müssen, möglicherweise Zeitdaten, aber selten Zeitdaten der Art, die von den von Ihnen beschriebenen Arbeitszeitnachweisen erfasst werden.
Sich darauf zu konzentrieren, ob Aufgaben „erledigt“ oder „nicht erledigt“ sind, ist in vielen Organisationen ein bedeutender Kulturwandel. Es erfordert Vertrauen zwischen dem oberen Management und dem Entwicklungsteam und die Verpflichtung des Teams, Schätzungen, Hindernisse und verfehlte Ziele transparent zu machen. Ohne dieses Vertrauen und ohne diesen Kulturwandel greifen die meisten Unternehmen einfach auf nutzlose Metriken wie Zeiterfassung zurück.
Wenn Ihre Organisation nicht bereit ist, diesen kulturellen Wandel vorzunehmen, und wenn Sie die granulare Protokollierung als störend oder lästig empfinden, können Sie versuchen, einen agileren Ansatz zu evangelisieren. Es ist jedoch wahrscheinlicher, dass es einfach an der Zeit ist, Ihren Lebenslauf aufzufrischen und nach einer Organisation zu suchen, die weniger von Misserfolgen betroffen ist.
Ich habe in Organisationen gearbeitet, die die Zeit in 15-Minuten-Schritten erfassen, und in solchen, die die Zeit überhaupt nicht erfassen.
Aus PM-Perspektive bevorzuge ich Ersteres sehr, da es nahezu unmöglich ist, den zukünftigen Aufwand objektiv abzuschätzen, wenn Sie keine Historie der tatsächlich aufgewendeten Zeit haben. In meiner derzeitigen Organisation müssen wir alle möglichen Verrenkungen durchlaufen, um herauszufinden, wie viele Projekte umgesetzt werden können, wie diese zu priorisieren sind usw. usw. Es wäre viel einfacher, ein Gespräch über Projektpriorisierung zu beginnen, wenn wir dazu gehen könnten unsere Führung und sagen: "Wir haben XX warme Körper, unserer Erfahrung nach können wir YY-Projekte mit dieser Mitarbeiterzahl erfolgreich durchführen".
Ich schließe mich Davids Gedanken dazu an. Ich musste 8 Jahre lang Zeiterfassung machen - zuerst auf eine halbe Stunde, dann auf eine Stunde - und das einzige Mal, als es "schmerzhaft" war, als ich jemand anderem in einer Angelegenheit half, mit der ich nichts zu tun hatte, und deshalb nicht konnte um dort irgendwelche Stunden zu protokollieren.
Aus der Perspektive des Projekts hat es einige Vorteile, da das Team/der Projektleiter weiß, wie viel Aufwand in das Projekt gesteckt wurde, und sieht, ob es noch im Budget ist oder nicht.
Dies kann auch hilfreiche Daten für Leads sein, um zu sehen, wer an vielen Dingen beteiligt ist, und helfen, die Ursachen für den Kontextwechsel zu reduzieren.
Teamkollegen argumentierten oft, dass das Ausfüllen zu viel Zeit in Anspruch nahm, und als wir tatsächlich gemessen haben, waren es ungefähr 10 Minuten an einem Freitag für die ganze Woche. Beim zweiten Argument ging es um Vertrauen, wie Sie bereits erwähnt haben. Ich habe nur eine PM kennengelernt, die die Stundenzettel benutzt hat, um herauszufinden, was die Leute tun – anstatt dorthin zu gehen und es selbst zu sehen –, andere haben versucht, Probleme zu lösen. Die Details interessierten sie auch nicht so sehr. Die Ingenieure verbrachten viel Zeit damit, die Blätter sehr genau auszufüllen, wozu sie nie aufgefordert wurden. Der PM war an den groben Zahlen interessiert, nur um zu sehen, wo das Projekt steht.
Wie andere hier musste ich als Berater jahrelang meine Zeit auf 1/4-Stunden-Niveau erfassen. Ich habe es zuerst gehasst, aber ich habe gelernt, den Aufwand anzunehmen, weil es später Informationen liefert. Kommentare nicht vernachlässigen!
Als Entwickler muss ich sagen, dass ich zustimme, dass dies eine Nervensäge sein kann. Es ist in Ordnung, wenn Sie einem einzelnen Projekt zugewiesen sind oder die Brocken groß sind, sagen Sie einen Tag an diesem einen Tag an diesem.
Das Problem tritt auf, wenn Sie an einem einzigen Tag an mehreren zufälligen Dingen arbeiten müssen und diese einfach nicht in das schön geordnete Zeiterfassungssystem passen, das eingerichtet wurde.
Angenommen, ich bin in einem BAU-Team und implementiere Funktionen von einem Scrum Board. Ich habe meine Aufgabe für den Tag und ich kann ihr ohne Probleme Zeit zuweisen. Also arbeite ich weg und Manager Bob kommt zu mir, um mich nach einem möglichen Fehler zu fragen, den ein Benutzer gemeldet hat. Es ist wahrscheinlich nichts, aber kann ich nachforschen? Dann möchte Entwickler Jim mich nach einem Code fragen, den ich letzte Woche programmiert habe, Sales Jane fragt, kann ich zu einem Meeting kommen, um die Schnittstelle für den neuen Kunden Z zu besprechen? HR Sam kann seine Tabelle nicht in das interne Tool Y hochladen, kann ich einen schnellen Bericht über etwas aus der Datenbank erstellen? usw usw
"Aber!" Sie sagen, wir machen Scrum/Kanban/Agile der Woche! du solltest "nein" sagen! zu all diesen Dingen und der Scrum Master, um einzugreifen, Aufgaben aufzuschreiben und sie zu priorisieren!
Leider zwingt dies die Entwickler in der Praxis dazu, sich zwischen „Scrum-Polizei“ zu entscheiden, Überstunden zu machen, Stunden zu haben, die sich im System nicht summieren, oder diese Stunden „aufzurunden“.
Darüber hinaus neigen Unternehmen dazu, sich auf diese „Schatten-IT“ zu verlassen, die Entwickler dazu drängt, „Arbeitseinheitsstil zu sein und nur Aufgaben auf dem Board zu erledigen“, was einen enormen Druck auf Projektmanager und BAs ausübt, diese Aufgaben korrekt zu spezifizieren, was zu einem Wasserfall-Ansatz führt . genau das Gegenteil von dem, was das Unternehmen wollte.
Ich wage zu sagen, dass diejenigen, die glauben, dass ihnen nicht vertraut wird, wahrscheinlich etwas zu verbergen haben.
Das tägliche Sammeln von Daten ist wichtig, um die Leistung sowohl im Vergleich zu Ihren Kosten- und Zeitplanbasisplänen als auch für Eingaben in ähnliche zukünftige Projekte zu messen. Es wird täglich durchgeführt, um die Genauigkeit und Präzision zu erhöhen, denn wenn es wöchentlich durchgeführt wird, handelt es sich bei den Daten höchstwahrscheinlich um eine bestmögliche Schätzung, wodurch die Daten unbrauchbar werden. Arbeitnehmer sollten die für ein bestimmtes Arbeitspaket geleisteten Arbeitsstunden so genau und genau wie möglich erfassen.
Wir alle erfassen unsere Zeit, von Arbeitern, die einstempeln, bis hin zu Fachleuten, die Stunden erfassen, um sie ihren Kunden in Rechnung zu stellen.
Es ist absolut notwendig, Projekte und Geschäfte zu verwalten. Wenn Sie das beleidigt, schauen Sie sich genau an, was Sie vor Ihrem Chef verbergen könnten.
Aziz Scheich
Aziz Scheich
Willl
Nathan Cooper
Erif Förp
Erif Förp
Bart van Ingen-Schenau
Amrinder Arora