Können tägliche Berichte die Produktivität eines Entwicklers verringern? [geschlossen]

18

In einer anderen Frage habe ich gefragt, warum Entwickler das tägliche Scrum nicht mögen . Wir haben mit Entwicklern gesprochen und beschlossen, eine Weile kein tägliches Scrum zu halten (um es zu versuchen und das Scrum in unserem ersten Versuch anzupassen). Dies ist das Ergebnis einer direkten Beratung mit Entwicklern.

Auf der anderen Seite möchten wir keine guten Teile des täglichen Gedränge verlieren, wie die Möglichkeit, Entwickler jeden Tag zu koordinieren oder den Arbeitsfortschritt wie ein Key Performance Indicator zu beobachten, um frühzeitig Maßnahmen zu ergreifen.

Als Alternative zum täglichen Gedränge möchten wir Entwickler bitten, tägliche Berichte mit den folgenden Bedingungen bereitzustellen:

  1. Es ist nicht erforderlich, ein bestimmtes Format einzuhalten. Jedes Format wird akzeptiert.
  2. Auch wenn die Arbeit nicht erledigt ist, wollen wir den Fortschritt hören.
  3. Es ist nicht erforderlich, die für jede Aufgabe aufgewendete Zeit zu erwähnen.
  4. Entwicklungshindernisse und Koordinierungsanforderungen sollten erwähnt werden.
  5. Es besteht kein Grund, von täglichen Berichten besessen zu sein. Es ist nicht so streng genommen.

Denken Sie, dass dies ihre Produktivität verringern kann? Haben Sie schon Erfahrungen mit täglichen Berichten gemacht? Haben Sie einen Vorschlag für uns, damit wir sichergehen können, dass wir nicht mit Mikromanagement befasst sind ?

Saeed Neamati
quelle
20
Wenn Ihre Scrum-Meetings länger als 5-10 Minuten dauern, machen Sie es nicht richtig. Scrum-Meetings sind kein Ort zum Fixieren oder Diskutieren. Sie sagen nur: Was ich getan habe, was ich tue und was mich blockiert. Es dauert 60 Sekunden und sollte überhaupt nicht stressig sein. Alle weiteren Diskussionen sollten außerhalb des Gedränge stattfinden.
Chris Eberle
3
Können Sie mehr darüber sagen, welchen Nutzen Sie aus der täglichen Berichterstattung ziehen (oder hoffen / erwarten)?
Poolie
9
Ich hasse Punkt 2: Es löst kein Problem seitens des Entwicklers, nur seitens des Managers. Außerdem zeigt es an, dass der Chef mir in meiner Arbeit nicht vertraut. Ich bevorzuge, was Chris sagt: was ich getan habe, was ich tue, was mich blockiert.
mouviciel
5
Stellen Sie sicher, dass die TPS-Berichte die richtige Abdeckung haben.
Simon Richter
2
Gibt es einen Grund, mit anderen auf Kohlenstoff basierenden Lebensformen zu sprechen, wenn die Quellcodeverwaltung in einen Bug-Tracker und einen CI-Server integriert ist?
Wyatt Barnett

Antworten:

37

Als Alternative zum täglichen Gedränge möchten wir Entwickler bitten, tägliche Berichte mit den folgenden Bedingungen bereitzustellen:

Was für eine schreckliche Idee.

Denken Sie, dass dies ihre Produktivität verringern kann?

Ja.

Warum? In einer mündlichen Präsentation auf einer Besprechung wird das Schreiben und das "Lesen" des Berichts durch n Personen zu einer gleichzeitigen Aktivität zusammengefasst. Sprechen und zuhören. Aus und vorbei. Fragen sofort beantwortet.

Das Schreiben eines Berichts ist Zeitverschwendung, da es Fragen geben wird und Sie den Bericht mit Leuten prüfen müssen, die (a) Fragen haben und (b) ihn nicht wirklich gelesen haben.

Tägliche Berichte werden nicht gelesen. Sie entwickeln sich schnell zu In-Box-Geräuschen.

"Es besteht kein Grund, von täglichen Berichten besessen zu sein". In welchem ​​Fall warum?

Haben Sie einen Vorschlag für uns, damit wir sicherstellen können, dass wir keine Mikromanager sind?

Ja. Täglich aufstehen. Es dauert ein paar Minuten und du bist fertig.

Wenn Ihr täglicher Stand-up-Vorgang mehr als ein paar (15?) Minuten dauert, teilen Sie viel zu viele Details und müssen separate Besprechungen für diese Details planen. Tägliche Stand-ups sind einfach zu machen. Nach einer zweiminütigen Zusammenfassung handelt es sich wahrscheinlich nur um Details, nicht für das gesamte Team, und es muss ein Folgetreffen eingeleitet werden. Die Besprechung rückt den Tagesfokus der nächsten Person auf.

S.Lott
quelle
6
+1 "Wenn Ihr täglicher Stand-up mehr als ein paar (15?) Minuten dauert, teilen Sie viel zu viele Details ..." in unserem wöchentlichen Meeting (wo wir mit Entwicklern in Kontakt treten, die zwischenstaatlich sind) wir wirklich versuchen Sie, diese Art von Regel zu verstärken. Wir hatten Meetings, die viel zu lange gedauert haben und da wir sie vor dem Mittagessen ansetzen.
James Khoury
Der längste Stand-up, an dem ich beteiligt war, war 20 Minuten, und das lag an einem Zustrom von Menschen. Wir hatten nicht nur das Entwicklerteam, sondern auch Praktikanten, Genossenschaften und ein oder zwei Auftragnehmer. Nicht jeder redete immer, aber wenn viele Leute relevante Updates hatten, wurden die Grenzen überschritten. Nach 20 Minuten begannen die Aufmerksamkeiten zu schwinden, so dass dies die Obergrenze wurde, bis die Anzahl abnahm und wir zu 15-minütigen Besprechungen zurückkehrten. In der Regel sind jedoch 15 Minuten eine gute Zeit, um zu fotografieren.
Thomas Owens
Denken Sie, dass dies ihre Produktivität verringern kann? Ja. lol so wahr. Warum codierst du nicht? coz Ich schreibe einen Bericht über die Codierung.
Anonymous Type
+1: "Ich schreibe einen Bericht über die Codierung". Der Mikro-Status lautet "Ich erstelle einen Makro-Statusbericht".
S.Lott
11

Ich habe dies in der Vergangenheit getan, aber am Morgen im Gegensatz zum Ende des Tages. Das Ausfüllen dauerte in der Regel weniger als fünf Minuten. Nein, ich kann keinen Rückgang der Produktivität eines Entwicklers feststellen. Das Schöne am Morgen war, dass man sich überlegte, was man für den Rest des Tages tun wird.

Davon abgesehen ...

Wir stellten fest, dass dies mehrmals der Fall war und nicht die effektivste Methode, um zu kommunizieren, was wir am Vortag getan hatten und was wir an diesem Tag arbeiten wollten. Warum? Die Leute haben sie im Allgemeinen nicht gelesen. Es war eine geplante Outlook-Aufgabe, also schickte jeder sie jeden Tag heraus, aber entweder wurden sie beschönigt oder nur ganz übersehen (anders als durch Leads oder das Management).

Wir fanden, dass das tägliche Aufstehen viel wertvoller war, da die Leute dazu neigten, einander zuzuhören. Wenn es ein Missverständnis gibt, wird es auch sofort gelöscht. Dies ist eher der Fall, als wenn jemand auf eine tägliche Status-E-Mail antwortet, um weitere Fragen zu stellen.

Demian Brecht
quelle
2
+1: "Sie wurden beschönigt". Ich habe für Kunden gearbeitet, die den täglichen Status wollten, aber trotzdem auf Besprechungen bestanden, um darüber zu diskutieren. Wenn wir das Meeting trotzdem haben würden, warum sollten wir alles zuerst aufschreiben?
S.Lott,
@ S.Lott - vielleicht, weil es sowieso aufgeschrieben ist - im Grunde die To-Do-Liste, mit der viele Leute ihren eigenen Fortschritt verfolgen werden. Angesichts der Tatsache, dass (aus der Frage) "es nicht erforderlich ist, einem bestimmten Format zu folgen", würde ich gerne meine Aufgabenliste mit den durchgestrichenen erledigten Elementen kopieren und einfügen - das mache ich normalerweise jeden Tag, um anzufangen zur nächsten Tagesliste sowieso. Mein gesprochener Bericht würde sich auf das konzentrieren, woran ich mich erinnere und was andere meiner Meinung nach hören sollten - also würde er Dinge im Vergleich zum Geschriebenen verpassen, aber auch über bevorstehende Probleme spekulieren, die andere Menschen betreffen könnten.
Steve314
@ Steve314: "Mein gesprochener Bericht ..." Das ist eine großartige Anstrengung, um das Beste aus einer schlechten Situation zu machen. Grundsätzlich jedoch, warum duplizieren? Wenn der schriftliche Bericht für nichts verwendet wird, warum fragen die Leute danach?
S.Lott,
@S.Lott - wenn es für nichts verwendet wird, ist das wahr. Aber ich habe viel von Programmierern gehört, die daran gedacht haben, dass alles gut läuft, und dass viele Fortschritte erzielt wurden, während die Manager in Panik geraten, weil sie seit Ewigkeiten nichts mehr gehört haben Fortschritt oder eine bevorstehende Katastrophe. Lassen Sie die Manager einige angekreuzte Aufgaben sehen, und vielleicht kann dies vermieden werden. Was die Vervielfältigung betrifft, muss die menschliche Kommunikation redundant sein - alle Beteiligten sind nur Menschen.
Steve314
@ Steve314: "Programmierer denken, alles läuft gut ..., während die Manager in Panik sind". Überhaupt nicht der Punkt. Ein schriftlicher Bericht, der lediglich zu einer Sitzung zur Erörterung der Fortschritte führt, wurde nicht gelesen . Wenn es nicht gelesen wurde, warum schreiben Sie es? Sie können eine edle Anstrengung unternehmen, um eine schlechte Situation zu verbessern. Ein schriftlicher Bericht, der nur zu einem Folgetreffen führt, ist jedoch eine Verschwendung eines schriftlichen Berichts. Machen Sie einfach das Folgetreffen. Nehmen Sie einfach täglich an einem Folgetreffen teil. Im Stehen. Und fertig damit.
S.Lott
6

Um ehrlich zu sein, scheint es ein bisschen zu weit von der liberalen Seite der Gleichung entfernt zu sein, jedem zu erlauben, sich ohne Einschränkungen zu melden. Wo ich arbeite, bewegen wir uns im Kreis und jeder Entwickler gibt Folgendes an:

  1. Was wurde am Vortag gemacht. Nicht alle kleinen Details, aber insgesamt.
    • Wenn das oben Genannte nicht fertig ist, wenn nicht, was wird benötigt, um fertig zu sein und wie lange wird es dauern.
    • Wenn das oben Genannte abgeschlossen ist, wie lautet die nächste Aufgabe, was ist erforderlich und wie lange wird es dauern?
  2. Blocker. Wenn Sie an Foo arbeiten, was von Bar abhängt, und Bar noch nicht fertig ist, muss dies klargestellt werden.

Das Einrichten eines allgemeinen Schemas, dem jeder folgen kann, erleichtert das Durchgehen eines bestimmten Berichts. Sie können ganz einfach eine Methode festlegen, mit der jeder eine E-Mail mit den täglichen Berichten erhält, um herauszufinden, was gerade passiert.


quelle
+1: Wir machen das Gleiche. Nicht täglich, sondern wöchentlich am Montag für die ganze Woche (also nur in einem größeren Zeitrahmen). Wir machen das nicht täglich, weil die meisten Angestellten Studenten sind und nicht jeden Tag da sind. Die meiste Kommunikation erfolgt über Instant Messaging oder ähnliches. Daher ist ein wöchentliches Treffen zwischen dem gesamten Team (ca. 10) ausreichend.
Femaref
6

IMO jede Art von täglichen Besprechungen / Berichten verringert die Produktivität, da es, um ehrlich zu sein, nach Mikromanagement stinkt. Ja, ich bin mir über Scrum und ähnliches im Klaren und diese sind nicht schlecht, vorausgesetzt, es handelt sich um kurze Statusaktualisierungen ("Hey, wie geht es mit Project X?"), Aber ich bin fest davon überzeugt, dass dies der Fall ist für professionelle Entwickler Beleidigung ist , Überblick zu behalten uns auf diesem niedrigen Niveau; Es ist vergleichbar mit der Verwendung von Zeitkarten, um sicherzustellen, dass wir 8 Stunden am Tag im Büro sind, oder um sicherzustellen, dass keine Wände vorhanden sind, sodass Sie die Computer der Benutzer ausspähen können, um festzustellen, welche Fenster zu einem bestimmten Zeitpunkt geöffnet sind.

Wenn Sie alle im Auge behalten müssen, um sicherzustellen, dass sie funktionieren, bedeutet dies, dass Sie ihnen nicht vertrauen. Wenn Sie ihnen nicht vertrauen, gibt es ein größeres Problem bei der Arbeit als das, über das Sie sich Sorgen machen.

Wayne Molina
quelle
4

Mein Team macht seit ungefähr einem Jahr Scrum. Zuvor hatten wir zwei Treffen pro Woche, in denen jedes Teammitglied über seine / ihre Aktivitäten in den letzten 2, 3 Tagen berichtete. Jede Sitzung dauerte zwischen 30 Minuten und 1 Stunde. Für den Fall, dass wir Informationen austauschen und unsere Arbeit koordinieren mussten, gingen wir einfach zu unseren Kollegen und sprachen mit ihnen (was wir natürlich immer noch tun).

Jetzt, wo wir Scrum machen, haben wir oft den Eindruck, dass ein Meeting pro Tag (obwohl es nur 15 Minuten dauert) zu viel ist. Oft lauten die Berichte einiger Mitglieder: "Nichts Neues seit gestern". Wir hatten oft den Eindruck, dass das 2-Meetings-pro-Woche-Schema effektiver war.

Ein weiterer Nachteil ist, dass es sich bei dem täglichen Meeting um eine geplante Unterbrechung handelt (siehe z. B. Artikel von Paul Graham , Punkt 1). Vermeiden Sie Ablenkungen: Da Sie wissen, dass die Unterbrechung bevorsteht, werden Sie vor dem Meeting keine schwierigen Vorbereitungen treffen (tägliche Meetings möglicherweise) 1 bis 1 ½ Stunden nach Arbeitsbeginn stattfinden).

Last but not least hat frühes Feedback zwar Vorteile ("Oh, Sie arbeiten an diesem Problem, wir sollten darüber diskutieren!"), Aber manchmal ist es effektiver, eine Diskussion nur dann zu beginnen, wenn Sie Ihre Ideen bereits in Ihrem Kopf organisiert haben Sie haben konkrete Fragen und fühlen sich zur Diskussion bereit. Stattdessen können tägliche Berichte schnell zu unnötigem und unstrukturiertem Brainstorming führen. Also hüte dich vor zu früh Feedback: Es kann Sie verwirren und verlangsamen.

Also: In einigen Fällen haben tägliche Berichte unsere Produktivität verringert. Im Durchschnitt habe ich nicht das Gefühl, dass sie unsere Arbeit effektiver gemacht haben.

AKTUALISIEREN

Ich habe meine ursprüngliche Antwort vor ein paar Jahren geschrieben und inzwischen die Mannschaft gewechselt. In meinem derzeitigen Team führen wir tägliche Meetings auf Abruf durch, dh wenn wir das Gefühl haben, ein kurzes Status-Update zu benötigen. Es gibt also jeden Tag die Möglichkeit, ein solches Treffen abzuhalten, aber wir tun es nicht, wenn niemand darum bittet. Wir haben eine wöchentliche Retrospektive. Dies ist im Grunde genommen sehr ähnlich zu dem Ansatz, den wir ursprünglich in meinem vorherigen, nicht agilen Team verwendet haben: feste wöchentliche Besprechungen plus zusätzliche On-Demand-Besprechungen während des Restes der Woche.

Giorgio
quelle
2

Wenn Sie wirklich einen groben Status wünschen und sich Hindernisse notieren möchten, fragen Sie am besten nach einer kurzen "täglichen Status-E-Mail". Wenn Sie zu viel Wert darauf legen oder eine Liste erstellen, was es enthalten sollte / nicht enthalten sollte, verbringen zumindest einige Ihrer Entwickler zusätzliche Zeit damit, es so zu gestalten, dass es den Anforderungen entspricht. Bitten Sie stattdessen einfach um eine einfache E-Mail. Wenn im Laufe des Tages Dinge auftauchen, wie "Oh, schreib das in deine E-Mail am Ende des Tages", und wenn du eine wirklich lange E-Mail am Ende des Tages erhältst, erwähne beiläufig "du musst nicht jeden Tag so detailliert sein".

Seifenkiste
quelle
1
Wenn Sie nicht genau sagen, was Sie mit einer kurzen täglichen Status-E-Mail meinen, werden sich mindestens einige Leute täglich stundenlang Sorgen machen, ob sie es richtig machen.
Steve314
@ Steve314, lol true, möglicherweise ein guter Weg, um die nächste Runde von Ahem- Kürzungen proaktiv zu erkennen .
Anonymous Type
2

Es ist sehr hilfreich, sich über den Zweck eines Meetings oder Berichts im Klaren zu sein , insbesondere über einen, den jeder jeden Tag erstellt. Sie sagen, der Grund ist:

Wir wollen keine guten Teile des täglichen Gedränge verlieren, wie zum Beispiel die Möglichkeit, Entwickler jeden Tag zu koordinieren.

Was meinen Sie mit Koordinatenentwicklern ? Welche Art von Arbeit muss koordiniert werden und wird bei Bedarf nicht von den Entwicklern und ihren Managern ad-hoc koordiniert? Gibt es vielleicht eine Möglichkeit, Aufgaben zu identifizieren, die koordiniert werden müssen, und nur in diesen Fällen zu kommunizieren?

oder beobachten Sie den Arbeitsfortschritt wie einen Key Performance Indicator, um frühzeitig Maßnahmen zu ergreifen.

Viele gute KPIs (wie die Reaktionszeit der Website oder die Anzahl kritischer Fehler) sind mechanisch messbar und Sie müssen den Entwicklern keine Kosten auferlegen, um dies zu tun.

Poolie
quelle
2

Ich musste am Arbeitsplatz tägliche Berichte in verschiedenen Formaten erstellen. Generell denke ich, dass die täglichen Berichte nur für Manager und nicht für die Entwickler selbst von Nutzen sind. Während Manager von den täglichen Berichten profitieren, indem sie in kurzer Zeit den Gesamtstatus jedes Projekts und die Aufgabenlast jedes Mitarbeiters ermitteln können, machen sich die meisten Entwickler meiner Erfahrung nach nicht die Mühe, die Statusberichte der jeweils anderen zu lesen.

Wenn Sie jedoch kein Format für Ihre täglichen Berichte erzwingen, erschweren Sie das Lesen und Verarbeiten der Berichte sowohl für Manager als auch für andere Entwickler, was das Problem der verlorenen Entwicklerzeit noch verschärft.

Wenn Sie sich dazu entschließen, tägliche Berichte für Ihre Entwickler zu erstellen, kann ich die Verwendung eines internen Wikis anstelle von E-Mail-Berichten vorschlagen? Auf diese Weise spammen Sie nicht die Posteingänge der Leute und behalten gleichzeitig den Verlauf des täglichen Status aller bei.

user937146
quelle
2

Es ist eine großartige Idee, Ihre agilen Methoden so anzupassen, dass sie zu Ihnen passen - ein großes Lob dafür.

Also, tägliche Berichte, ich würde sagen, das ist nicht viel besser als eine tägliche Besprechung, es ist immer noch der gleiche Ansatz "Sag mir, was du tust".

Hier ist ein alternativer Ansatz: Anstatt diese Abfragetechniken zu verwenden, bei denen Sie jeden Entwickler nach seinem Status fragen, verwenden Sie stattdessen eine Push-Technik. Wenn der Entwickler nicht viel zu berichten hat, sollte er alle auftretenden Probleme und Fortschritte melden. Wenn sie ein Modul abschließen, sollten sie dem gesamten Team per E-Mail mitteilen, dass es fertig ist, dass es sich in SCM befindet, wo sich die Dokumentation befindet und eine kurze Zusammenfassung dessen, was es ist, wie es funktioniert und / oder wie es verwendet wird es. Wenn sie ein Problem haben, sollten sie das Team per E-Mail um Rat, Hilfe oder Tipps bitten. (Ja, genau wie in früheren Zeiten, als die Teams ohne das Mikromanagement, unter dem wir heute leiden, gut kommunizierten.)

Sie werden feststellen, dass dies viel produktiver und konstruktiver ist. Sie werden keine bedeutungslosen Berichte erhalten und Sie werden ein motivierteres Team erhalten, da jeder seine Kollegen gerne über ihre Arbeit informieren möchte.

gbjbaanb
quelle
2

Ich stimme auch zu, dass es eine schlechte Idee ist, die täglichen Stand-ups durch einen Bericht zu ersetzen. Ein tägliches Aufstehen ist ein großartiger Ort, um Ideen und Probleme zu äußern. Dies ist einer der Gründe, warum ich das gute alte Whiteboard (das wir zusammen mit Jira + Greenhopper verwenden) mag. Das Whiteboard ist ein Ort, an dem die Gruppe Informationen sammelt und teilt, alles ist da, alles ist sichtbar, jeder bewegt sich und ändert die Stickies, an denen er gearbeitet hat, und es macht auch viel Spaß.

Vladaimir Cetkovic
quelle
2

Können Sie diese Informationen nicht aus Ihren anderen Tools extrahieren?

  • Woran arbeiten Sie gerade? Die Tickets habe ich vergeben.
  • Was ist dein Fortschritt? Für Tickets, die länger als 1 Tag sind, siehe Kommentare im Ticket oder Commit-Nachrichten der Filiale. Tickets habe ich kürzer: wahrscheinlich morgen gemacht (du machst keine großen 5+ Tageskarten, ja?)
  • Was ist der allgemeine Fortschritt? siehe open / closed-tickets-verhältnis
  • Was muss organisiert werden? Die Tickets, die Sie zurückerhalten, mit dem erforderlichen Statusfeedback und allem, was im IRC Ihres Teams, Campfire Room, besprochen wurde.

Wenn Sie spezifischere Fragen zu beantworten haben, würde ich die Notwendigkeit für spezifische Berichte sehen, aber ohne das Ihre Berichte ein wenig wie ein Selbstzweck aussehen.

keppla
quelle