Wie kann ich Teamablenkungen wie Geplauder bewältigen?

Konversation ist nicht von Natur aus störend

Ich arbeite mit einem Team von Entwicklern zusammen, die talentiert sind, sich aber oft gegenseitig mit Geplauder ablenken.

Sie sagen, sie seien „talentiert, aber abgelenkt“. Was lässt Sie denken, dass sie talentiert sind? Warum denken Sie, dass sie abgelenkt sind? Was ist Ihre Metrik, um festzustellen, dass das Team oder der Prozess auf einem suboptimalen Niveau arbeitet?

Sie haben für keines dieser Dinge wirklich plädiert, außer insofern, als wir uns von Anfang an darauf einigen sollten, dass " Geplauder " (das eine ziemlich abwertende Konnotation hat) das Projekt stört. Wie haben Sie festgestellt, dass der Kommunikationsstil des Teams den Erfolg Ihres Projekts verhindert?

Selbstverwaltete Teams und der Irrtum der 100-prozentigen Auslastung

Idealerweise hätten die Entwickler Erwartungen, die von ihnen verlangen würden, konzentriert zu bleiben und (sic) ihre eigene Arbeit zu verwalten.

Obwohl ich zustimme, dass ein ideales Team sich selbst verwaltet, habe ich keine Kenntnis von Ihren Einstellungspraktiken, Ihrer Unternehmenskultur oder den organisatorischen Anreizen für Teams, sich selbst zu verwalten. Die Tatsache, dass Sie in einer Rolle zu sein scheinen, in der Sie die Aufgabe haben, ein Team zu leiten, das sich nicht selbst verwaltet, spricht dafür, dass dies ohne Änderungen an Ihrer Organisation oder Ihren Prozessen möglicherweise nicht vernünftig ist.

Darüber hinaus ist „konzentriert bleiben“ oft Managementsprache für „beschäftigt aussehen“. Wie oben, es sei denn, Sie können argumentieren, dass Ihr Team keine Leistung erbringt, klingt es wirklich so, als ob es wichtiger ist, wie es sich verhält, als welche Ergebnisse es erzielt.

Indem Sie das „Wie“ zu einem Problem machen, handeln Sie sogar gegen das Prinzip der Selbstverwaltung, das Sie scheinbar wollen. Selbst wenn das Team wirklich nicht engagiert ist, sollten Sie Ihre Zeit besser damit verbringen, herauszufinden, wie Sie es einbeziehen können, anstatt zu versuchen, es engagiert aussehen zu lassen .

Entwickler sind oft seltsame Enten. Einige Entwickler arbeiten am besten in katakombenartiger Stille oder arbeiten um 2:00 Uhr; andere leben vom Austausch und Teamengagement im Büro. Unabhängig vom Arbeitsstil brauchen jedoch alle Entwickler Bedenkzeit, um produktiv zu sein – mehr Klicks auf der Tastatur (z. B. höhere Auslastung) führen nicht zu mehr Durchsatz oder hochwertigerem Code.

„Rechenschaftspflicht“ und Projektprozess

Selbst wenn ich frage, wie lange es dauern könnte, Aufgaben abzuschließen (die ich in einem sehr genauen Zeitrahmen abschließen kann), bekomme ich negative Rückmeldungen, die darauf hindeuten, dass ich die Verantwortlichkeit unterdrücken möchte.

Auch hier basiert Ihre Schlussfolgerung nicht auf Beweisinformationen. Es kann andere Gründe geben, warum Ihr Entwicklungsteam keine festen Fristen setzen möchte.

1. „Rechenschaftspflicht“ ist ein Schlagwort für eine Möglichkeit, Schuld zu verschieben.

   Wenn Ihre Organisationskultur gerne Schuldzuweisungen macht und Projekte oft zu spät kommen oder auf andere Weise zum Scheitern verurteilt sind, warum sollte das Team dann zur Rechenschaft gezogen werden wollen?

2. Gebote von oben sind keine Verpflichtungen.

   Wenn das Team nicht Teil des Schätzungs- oder Planungsprozesses ist, wird es für Liefertermine „zur Rechenschaft gezogen“, für die es sich nicht angemeldet hat. Fragen Sie sich ehrlich, ob Schätzungen der Entwickler als Projektgrundlinie eingeholt und eingehalten werden oder ob Projektfristen außerhalb des Teams festgelegt werden.

3. Schätzungen sind keine Verpflichtungen.

   Wenn Ihnen ein Entwickler sagt, dass etwas wahrscheinlich drei Tage dauern wird, aber der Job fünf Tage dauert, was passiert dann in Ihrem Unternehmen? Ist jemand schuld? Wird der Entwickler für die Fehleinschätzung bestraft oder verunglimpft? Wenn ja, warum sollten sie etwas anderes tun, als in dem Tempo voranzuschreiten, das sie für nachhaltig halten?

4. Zusagen sind keine Garantien.

   Entwickler sind selten dumm. Wenn sie wissen, dass etwas zwei Wochen dauern wird (aufgrund von Komplexität, Prozessaufwand oder organisatorischen Hindernissen) und Sie denken, dass es zwei Tage dauern wird, was ist ihr Anreiz, Ihnen eine andere Frist zu geben? Wenn die Organisation routinemäßig ihre Schätzungen kürzt und sie dann zur Rechenschaft zieht, wo ist dann ihr Anreiz? Wenn sie ehrliche Schätzungen abgeben und freiwillige Verpflichtungen durch externe Hindernisse nicht erfüllen, erwartet die Organisation dann eine Geld-zurück-Garantie in Form von unbezahlten Überstunden, anstatt zu versuchen, das Hindernis zu beseitigen?

Auch wenn wir davon ausgehen, dass Ihre Schlussfolgerung, dass das Team die Verantwortlichkeit vermeiden möchte, richtig ist, haben Sie nicht tief genug nachgeforscht, warum . Hier ist eindeutig ein organisatorisches oder prozessuales Problem am Werk, und die Lösung des wahrgenommenen Problems ist nicht wirklich die eigentliche Ursache anzugehen – oder Ihnen etwas zu kaufen, wenn Sie letztendlich für ein fehlgeschlagenes Projekt „zur Rechenschaft gezogen“ werden.

Was nun?

Werfen Sie einen ehrlichen Blick auf Ihre Organisation, Ihren Projektmanagementprozess und die Mitglieder Ihres Teams. Versuchen Sie, objektiv zu sein und sehen Sie, ob die Anreize tatsächlich mit den Interessen der Entwickler übereinstimmen. Wenn nicht, fangen Sie dort an!

Auch eine Scrum-ähnliche Retrospektive kann hilfreich sein. Wenn das wirkliche Problem, das Sie lösen möchten, darin besteht, ehrliche Schätzungen vom Entwicklungsteam zu erhalten, können Ihnen nur die Teammitglieder sagen, wie Sie diese erhalten. Natürlich müssen Sie sich ihr Vertrauen verdienen (wenn ehrliche Kommunikation nicht die Norm ist), und es gibt keine Patentrezepte. Dennoch ist es eines der besten Tools da draußen: Fragen Sie die Leute mit den tatsächlichen Antworten!

Es gibt immer andere Dinge, die Sie überprüfen und anpassen können. Trotzdem muss man irgendwo anfangen, und ehrliche und offene Dialoge sind fast immer der beste Ort, um dies zu tun.

Ich weiß nicht, warum aclear16 seine Antwort gelöscht hat. Seine Antwort ist perfekt. Es gibt eine Menge positiver Aspekte von ungenutzter, unproduktiver Zeit durch Teamarbeit. Es reift das Team und das will man. Ich würde sogar so weit gehen zu sagen, wenn Sie hinterherhinken, lassen Sie die soziale Zeit weitergehen, denn die positiven Aspekte davon werden helfen, nicht schaden. Und wahrscheinlich war die Ausfallzeit nicht die Ursache.

Wenn Sie versuchen, es zu zerquetschen, laufen Sie ein viel größeres Risiko, das Teaming zu zerstören und sich zu entfremden.

Was Sie fühlen, ist, dass Sie Ihr Team nicht unter Kontrolle haben – es hat nicht einmal den Anstand, beschäftigt zu wirken, wenn Sie in der Nähe sind. Begegne deiner Unsicherheit. Komm darüber hinweg.

Das erste Problem, dem Sie sich stellen müssen: Sind Ablenkungen gut oder schlecht? Ich denke, das kann man weder mit einem klaren Ja noch mit Nein beantworten.

Erstens kann kein Entwickler 8 Stunden am Stück arbeiten und trotzdem bei Verstand bleiben. An einem guten Tag bekommt man 4-6h konzentrierte Arbeit. Aber denken Sie nicht, dass sie, da sie nicht konzentriert am Schreibtisch sitzen, „nicht arbeiten“. Meiner Erfahrung nach kommen die besten Ideen und Einsichten in der Freizeit.

Zweitens ist die Moral ein sehr wichtiger Aspekt der Produktivität. Ein motivierter Entwickler kann in 2h mehr Arbeit erledigen als ein unmotivierter in einem ganzen Tag. Es ist wichtig zu erkennen, dass beschäftigt aussehen nicht mit „hart arbeiten“ gleichzusetzen ist.

Drittens können Ablenkungen die Produktivität wirklich beeinträchtigen. Nicht wirklich in verlorener Zeit, sondern eher im unterbrochenen Fluss. Egal, ob es der Kollege ist, der nach den neuesten Trends in Webtechnologien fragt, oder der Manager, der den neuesten TPS-Bericht diskutieren möchte. Es dauert einfach ewig, bis es wieder synchron ist.

Das Hinzufügen von Metriken kann hilfreich sein. Ohne Druck auf die Entwickler auszuüben, können Sie damit beginnen, einfache Metriken wie Probleme/Zeit zu sammeln. Dies kann zu einem gesunden Wettbewerb zwischen Entwicklern darüber führen, wer die beste Punktzahl erzielen kann. Aber seien Sie sehr vorsichtig , übertreiben Sie es und die Leute werden anfangen, das System zu spielen. Genauso wie Anreize reduziert Druck auf Menschen, die kreative Arbeit leisten müssen, ihre Leistung.

Am Ende geht es um ein gesundes Arbeitsumfeld.

Ich schließe mich der Meinung von @sqreept (+1!) an, Sie versuchen, eher mit dem Symptom als mit der Ursache umzugehen .

Meine Meinung unten stellt jedoch nur einige wenige unter allen möglichen Szenarien dar.

Nun das Szenario:

Mein Team quatscht ein bisschen zu viel

Wieso den? Weil sie wissen, dass sie lockere Fristen einhalten müssen.

Wieso den? Weil Entwickler eher zurückhaltend sind, Schätzungen abzugeben.

Wieso den? Weil sie nicht für Verabredungen verantwortlich gemacht werden wollen.

Wieso den?

• ODER sie haben keine guten Spezifikationen, und dann fühlt sich das Team berechtigt, ihre Schätzungen stark aufzufüllen
• ODER die Spezifikationen werden vom Entwicklerteam als nicht gut genug angesehen, das sich weigert, unter einer engeren Frist für angeblich schlechte Spezifikationen zu arbeiten
• ODER es gibt eine Kultur, die es ihnen erlaubt, sich so zu verhalten

Um Ihre Frage zu beantworten, müssen Sie also die Ursachen für dieses Verhalten einschätzen und sich mit der Ursache befassen, nicht mit dem Symptom.

Denken Sie jedoch daran, dass niemand 8 Stunden am Stück produktiv arbeitet. Wenn Sie glauben, dass sich das Geplauder eindeutig auf die Gesamtleistung des Projekts auswirkt, müssen Sie möglicherweise handeln. Aber versuchen Sie nicht, Ihr Team zu sehr zu fordern, denn das wird einfach nicht funktionieren.

Eine Randnotiz: Die Frage , wie der Fortschritt ist, endet eindeutig mit einem Plausch, das mag unhöflich klingen. Sie versuchen, mit etwas umzugehen, das Sie für ein echtes Problem halten, ohne sich direkt damit auseinanderzusetzen. Wenn Sie nach der Bewertung des Szenarios wirklich glauben, dass es sich um ein Problem handelt, seien Sie offen zu Ihrem Team und lassen Sie es seine Meinung preisgeben. Nebenaktionen (oder in diesem Fall Nebenfragen) werden keinen großen Mehrwert bringen, da Sie demonstrieren, dass Sie nicht mit dem eigentlichen Problem konfrontiert sind. Steigen Sie ein und lösen Sie das Problem (falls es eines gibt), ohne herumzuirren.

Ihre Frage enthält eine Antwort und eine versteckte Frage: "Übertreiben Sie das symptomatische Geplauder?"

Overdoing: Wann ist normales Geplauder übertrieben? symptomatisch: Ja, du hast recht. Dies ist lediglich ein Symptom. Versuchen Sie nicht, das Symptom zu beheben.

Aber erfahrungsgemäß, wenn man sich Gedanken über Geplauder macht und das sichtbar wird, machen sie unbewusst mehr davon :) Ich weiß, es macht keinen Sinn.

Worauf Sie sich jetzt konzentrieren sollten, ist, das Produkt mehr zu „ihrem Produkt“ und weniger zu „Ihrem Produkt“ zu machen. Bauen Sie auf ihren Stolz, auf ihre Selbstachtung. Nie Angst!!!

Und viel Glück! Sie haben eine größere Aufgabe vor sich als das Produkt, was auch immer Sie tun ...