Ein klügerer Mann als ich sagte: „Man kann Leute dazu bringen, 80 Stunden pro Woche im Büro zu bleiben, aber man kann sie nicht dazu bringen, mehr als 40 Stunden pro Woche zu arbeiten.“

Das ist das Problem, auf das Sie stoßen, und Sie können nichts tun.

Die Leute kommen ins Büro, weil du sie bezahlst. Sie arbeiten, weil sie es wollen. Und Sie wissen, warum diese Leute keine Motivation haben zu arbeiten.

Die Art und Weise, wie Ihr Arbeitgeber mit Menschen umgeht, nützt niemandem. Sie erhalten möglicherweise unbezahlte Überstunden von ihren Mitarbeitern, was jedoch wahrscheinlich zu einer schlechten Arbeitsmoral, minderwertiger Arbeit und einer hohen Personalfluktuation führt (zusammen mit den Kosten/Zeiten, die für die Schulung von Ersatzkräften erforderlich sind).

Langfristig glaube ich, dass Sie darauf drängen müssen, die Denkweise Ihres Arbeitgebers zu ändern. Es ist unwahrscheinlich, dass sie eine plötzliche Erleuchtung erfahren, also müssen Sie sich darum kümmern. Klopfen Sie immer wieder an die Tür, weisen Sie auf die Risiken und Probleme bei ihrer Herangehensweise hin, und schließlich könnten Sie irgendwo ankommen. Seien Sie jedoch vorsichtig – Sie müssen dies mit Subtilität angehen, weil Sie nicht als irritierend angesehen werden möchten. (Außerdem – ich kenne die Unternehmensgröße oder -struktur nicht – müssen Sie möglicherweise Ihren direkten Vorgesetzten aufsuchen und ihn bitten, die Leiter für Sie nach oben zu tragen).

( Wenn das Unternehmen finanziell in einer angespannten Lage ist, müssen Sie Ihre Anträge entsprechend anpassen. Es gibt mehr Dinge als Geld - vielleicht zusätzlichen Jahresurlaub, Zeitausgleich, die Möglichkeit, am Freitag früh zu enden, kostenloses Obst / Erfrischungsgetränke könnten den Unterschied ausmachen )

Kurzfristig kann man vieles versuchen, um die Leistung der Mannschaft zu verbessern.

• Das Unternehmen mag ihre Bemühungen nicht zu schätzen wissen – aber nichts hindert Sie daran. „Danke“ für eine gut gemachte Arbeit zu sagen, gute Arbeit zu loben und wirklich Wertschätzung zu zeigen, wenn jemand über das hinausgeht, wird zeigen, dass du seine harte Arbeit anerkennst. (Auch ab und zu eine Schachtel Donuts mitzubringen, wird Wunder bewirken!)
• Sei flexibel. Auch hier weiß ich nicht, welche Art von Arbeit Sie machen, aber wenn es möglich ist, versuchen Sie, den Menschen das Leben zu erleichtern. Lassen Sie sie früh aussteigen, wenn sie einen Termin haben oder ihre Kinder abholen müssen. Ich finde, wenn Sie in solchen Situationen etwas nachlassen, erhalten Sie es doppelt zurück, wenn die Fristen knapp sind oder der Rücken an der Wand steht. Es geht um Geben und Nehmen.
• Karrierehilfe. Chatten Sie mit Ihren Teammitgliedern. Finden Sie heraus, wo sie in 5 Jahren stehen wollen. Versuchen Sie (es ist möglicherweise nicht immer möglich), sie mit dieser Art von Arbeit vertraut zu machen. Vielleicht erlernt es eine neue Fähigkeit oder Technologie, vielleicht übernimmt es eine andere Art von Arbeit (Verkauf, Support, Projektmanagement). Wenn Menschen lernen und sich durch ihre Arbeit herausgefordert fühlen, werden sie wahrscheinlich härter daran arbeiten.
• Seien Sie ein Fürsprecher. Alle vorherigen Punkte fallen ein wenig in diese Kategorie. Sie müssen wissen (oder zumindest das Gefühl haben), dass Sie, obwohl das Unternehmen möchte, dass Sie sie verwalten, auch in ihrer Ecke kämpfen. Sagen Sie dann, dass Sie die Position schätzen, in der sie sich befinden – aber sagen Sie ihnen auch, dass Sie versuchen, sie zu ändern. Erzählen Sie ihnen, was Sie versucht haben und welche Fortschritte Sie machen.
• Kommunizieren. Kommunizieren Sie fortfahrend mit dem oben Gesagten die Fortschritte, die Sie machen. Wenn Sie etwas vom Management hören, entscheiden Sie, was Sie dem Team mitteilen können. Wenn sie sich beteiligt fühlen, fühlen sie sich investiert und daher engagierter.
• Genauer beobachten. Das oben genannte wird nicht für alle funktionieren. In diesen Fällen müssen Sie sie genauer überwachen. Wissen, woran sie arbeiten. Lassen Sie sie sich auf eine Lieferfrist festlegen (Sie müssen wissen, ob dies angemessen ist oder ob sie aufgefüllt wird) und überprüfen Sie dann regelmäßig, ob sie diese Frist einhalten. Wenn nicht, finden Sie heraus, warum. Sie zielen nicht auf Konflikte ab, es sollte eine Diskussion vom Typ "Nun, wie kann ich Ihnen helfen, die Frist beim nächsten Mal einzuhalten" sein - vielleicht muss der Prozess verbessert werden, vielleicht wurden sie unterbrochen oder neu zugewiesen, vielleicht ist etwas schief gelaufen . Wenn Fristen ständig versäumt werden, müssen Sie wahrscheinlich den disziplinarischen Weg einschlagen.

Ihre Aufgabe als Teamleiter / Manager ist es, Ihre Teammitglieder vor dem Müll zu schützen, der von oben kommt, damit sie produktiv sind.

Sie müssen herausfinden, WARUM sie Überstunden machen müssen. Sind sie im Allgemeinen unproduktiv oder sind die Zeitvorgaben unrealistisch? Wenn sie unrealistisch sind, müssen Sie Schritte unternehmen, um sie realistisch zu machen ... Beziehen Sie das Team mit ein, um die Schätzungen für die Zeitskalen vorzunehmen; und wenn das Management auf unrealistische Zeitskalen drängt, müssen Sie auf mehr Ressourcen drängen.

Das Management wird es nicht mögen, wenn Sie es sagen ... niemand mag es, wenn Leute zurückdrängen; aber am Ende ziehen sie es vielleicht vor, wenn die Produktivität steigt, die Menschen zufriedener sind und Fristen eingehalten werden.

Kulturproblem

Ich finde die Antwort von Karl Bielefeldt am besten, aber ich möchte es noch eindringlicher sagen: Sie haben ein Kulturproblem, und das hat nichts mit China zu tun. Ihr Chef möchte, dass Fehler in Ihrer Software behoben werden? Eindrucksvoll!!! Es gab unzählige Male in meiner Karriere, in denen ich der Fehlerbehebung Priorität einräumen wollte, das Management aber mehr Feature-Bereitstellung wollte.

Das eigentliche Problem, das Sie haben, ist die Einstellung Ihres Teams zur Codequalität . Letztlich ist dies ein Reifeproblem. Die meisten Teams enden aus einigen häufigen, wiederkehrenden Gründen mit fehlerhaftem, kaputtem Code:

• Nicht genügend Zeit/Ressourcen zum Testen aufgewendet
• Nicht genug Zeit damit verbracht, Code zu dokumentieren und zu überprüfen
• Zu viel Fokus auf Lieferung
• Bereitschaft, unbegrenzt technische Schulden zu machen

Es ist nicht die Aufgabe Ihres Chefs, diese Probleme zu beheben. Dies sind keine organisatorischen oder betrieblichen Probleme. Dies sind Entwicklerprobleme , und Entwickler müssen sich die richtige Einstellung und Strategie aneignen, um damit umzugehen.

Kalt gelesen

Ohne weitere Informationen über Ihr Unternehmen, Ihr Team oder Ihre Geschäftspraktiken zu haben, werde ich einige Vorhersagen treffen:

• Ihre Codebasis hat wenige bis keine Unit-Tests (Codeabdeckung < 20 %)
• Ihr Team führt manuelle Tests durch (wenige bis keine automatisierten Integrations-/Funktions-/Akzeptanztests)
• Ihr Team gibt sich wenig Mühe in die Codeüberprüfung (entweder behandelt es als Stempel, Gelegenheit für unnötige Spitzfindigkeiten oder überspringt es ganz)
• Ihr Team dokumentiert selten Code oder fügt triviale Kommentare hinzu (// die nächste Zeile gibt eine Nachricht in die Protokolldatei aus).
• Ihr Team führt kein regelmäßiges Refactoring durch oder hat nur 1 oder 2 Ingenieure, die glauben, dass Refactoring überhaupt sinnvoll ist
• Ihr Team liebt es, neuen Code auf der grünen Wiese zu schreiben, und versucht zu vermeiden, bestehenden Code wie die Pest zu warten
• Ihrem System fehlen automatisierte Erfolgsmetriken (Anzahl erfolgreicher Transaktionen/Anfragen im Vergleich zu Versuchen, Anzahl der Fehler pro Transaktion, Anzahl der Zeitüberschreitungen, benutzerseitige Fehler usw.)

Klettern aus dem Loch

Selbst wenn ich nur mit der Hälfte der Vorhersagen richtig liege, reicht das aus, um Ihre missliche Lage zu erklären. Die Lösung sind nicht noch mehr Überstunden oder der Versuch, Ihren Chef davon zu überzeugen, einen Rückzieher zu machen. Ein Teil des Problems besteht darin, dass Ihnen in Ihrem Team eine starke technische Führung fehlt. Ihr Team braucht wirklich einen oder fünf leitende Ingenieure, die ausgereifte Softwareentwicklungspraktiken fördern können, die Fehler so früh wie möglich in der Pipeline reduzieren.

Wie Sie sich vorstellen können, werden die vorgeschriebenen Korrekturen direkt die oben vorhergesagten Fehler beheben, zusammen mit einem kurzen Klappentext, warum Sie in die Aktivität investieren sollten:

• Komponententests – Ich denke, 80 % sind das absolute Minimum für eine langfristig wartbare Codebasis. Ich strebe nach 98 %+, und das ist fast immer erreichbar. Hier geht es nicht darum, irgendein Kästchen in einer masochistischen SDLC-Checkliste abzuhaken. Erstens ist nicht jeder Code einfach zu testen. Das Schreiben von Tests für solchen Code zwingt den Entwickler dazu, das Design und die Organisation des Codes zu überdenken. Code Unit testbar zu machen, macht es besser. Ich sage dies als absolute Wahrheit, weil ich glaube, dass es so ist, und noch nie ein Gegenbeispiel gesehen habe. Darüber hinaus decken Komponententests viele Fehler auf, die sich schließlich in der Produktion manifestieren, und oft auf heimtückische, schwer reproduzierbare Weise. Schließlich dienen Komponententests als eine Art Dokumentation der Absichten des Entwicklers, wenn der ursprüngliche Programmierer zu einem anderen Projekt gewechselt ist und der Betreuer versucht, daraus abzuleiten, was er erreichen wollte. Ich behaupte, dass Unit-Tests immer mehr Zeit sparen, als sie kosten, weshalb reife Entwickler die Zeit investieren werden, sie zu schreiben. Leider würde ich wetten, dass weniger als 20 % der Entwickler weltweit nach dieser Metrik als „reif“ gelten. :/ Sie können nicht sagen, wie gut Sie beim Unit-Testen abschneiden, bis Sie einen Codeabdeckungsanalysator in Ihren Build-Prozess implementieren und die Ergebnisse auf ein "
• Akzeptanztests – Ihr Team muss viele Fehler beheben, weil Sie die richtigen Tests an Ihre Benutzer ausgelagert haben, und das macht Ihren Chef verständlicherweise wütend. Ihre Entwickler sind faul, glauben, dass jemand anderes die Tests durchführen sollte (z. B. dedizierte Tester) und pflegen eindeutig keine Reihe automatisierter Tests. Sie benötigen Tests, die bei jeder Zusammenführung, bei jedem Produktions-Build, bei jeder Bereitstellung in jeder Testumgebung und bei jeder Produktionsbereitstellung ausgeführt werden. Sie möchten eine breite Abdeckung durch randomisierte Testgenerierung und umfassende Datenvalidierung innerhalb Ihres Codes. Dies ist ein ganzes Thema für sich, aber auch der Kern Ihres Problems. Sie müssen nicht Tausende von Testfällen schreiben, um eine nützliche Akzeptanztestsuite zu haben. Aber Sie müssen ein gutes Test-Framework finden, sich damit vertraut machen und es zu Ihrem neuen besten Freund machen.
• Codeüberprüfung – viele Entwickler ziehen nicht den Nutzen aus der Codeüberprüfung, die ohne weiteres verfügbar ist. Erstens sollte die Codeüberprüfung dazu beitragen, einen einheitlichen Stil und Ansatz im gesamten Team aufrechtzuerhalten. Ich glaube nicht, dass Entwickler Code schreiben müssen, als ob sie alle Klone wären, à la XP-Stil. Aber es hilft, einige gemeinsame Standards durchzusetzen, ohne in Formatierungskriege überzugehen. Dies erstreckt sich auf Entwurfsmuster und Programmiersprachen, die in Ihrem Problembereich häufig vorkommen. Zweitens ist Code-Review eine Gelegenheit zum Lernen, sowohl für den Autor als auch für die Reviewer. Es ist eine besonders gute Möglichkeit für Junior-Entwickler, bewährte Praktiken von Senioren zu lernen (vorausgesetzt, die Seniors sind tatsächlich gute Programmierer). Reviewer sollten viele Fragen stellen, wenn der Code nicht klar ist, und der Prozess sollte eher kooperativ als konfrontativ sein. Dritte, gute Rezensenten können Fehler oft nur durch Lesen des Codes erkennen. Dies wird nicht immer passieren und ist kein Ersatz für Tests. Aber es ist einnetter Bonus , und einen, den Sie "kostenlos" bekommen, nur weil Sie sich die Mühe gemacht haben, 2 andere Leute zu bitten, Ihren Code zu lesen. Jede Zusammenführung sollte eine Codeüberprüfung haben .
• Das Schreiben einer guten Dokumentation wird von etwa 95 % aller Entwickler übersehen, wenn man mein höchst unwissenschaftliches Urteil bedenkt. Sie benötigen keine Dokumentation auf NASA-Ebene, um Ihre Codebasis zu verbessern, noch erfordert jeder Code dieselbe Dokumentationsebene. Im Allgemeinen gilt: Je mehr Code wiederverwendet wird, desto mehr Dokumentation sollte er haben. Daher sollte jede Art von gemeinsam genutzten Bibliotheken/Klassen/Modulen eine zusätzliche Dokumentation erhalten, insbesondere für Dinge wie Thread-Sicherheit, Ausnahmesicherheit, beabsichtigte Verwendung, detaillierte Funktions-APIs, Nullbehandlung usw. Maßgeschneiderter App-Code sollte eher klar und eigenständig sein. dokumentieren. Auch hier können Sie nicht sagen, wie gut Ihre Dokumentation ist, bis Sie sie als Teil des Build-Prozesses generieren und auf einem lokalen Webserver veröffentlichen. Viele Fehler treten auf, weil es nicht übereinstimmende Annahmen und Erwartungen zwischen Ingenieuren gibt (über gültige Werte für Felder, wo die Validierung stattfindet usw.). Die Dokumentation hilft, diesen Fehlermodus zu mindern.
• Refactoring – das ist eines der wertvollsten Dinge, die Sie für verkommene Codebasen tun können, die eine Menge technischer Schulden erworben haben. Es ist vielleicht das zweitewas Sie tun sollten (nachdem Sie Unit-Tests geschrieben haben, natürlich!). Für ein kleines Unternehmen oder ein Startup gibt es Zeiten, in denen es schnell geht und Dinge kaputt gehen, ist die richtige Vorgehensweise. Aber das lässt sich nicht auf Dauer aufrechterhalten. Wenn Sie beim Refactoring keine Pausen einlegen, wird Ihr Team schließlich von einer Klippe technischer Schulden herunterfallen (das hört sich an, als würde es sich gerade an einem winzigen Ast festhalten). Gute Ingenieure sollten ohnehin auf Refactoring drängen. Die Tatsache, dass Sie keine von Entwicklern empfohlenen Abhilfemaßnahmen erwähnt haben, zeigt mir, dass Ihnen solche Ingenieure fehlen. Code muss nicht gleich beim ersten Schreiben perfekt sein (und wird es fast nie sein). Aber Sie sollten in der Lage sein, es jedes Mal zu verbessern, wenn Sie es berühren. Refactoring sollte für Ihr gesamtes Team zur zweiten Natur werden, und jeder sollte sich dazu befähigt fühlen, wenn die Änderungen eindeutig für das gesamte Team von Vorteil sind. Offensichtlich möchten Sie unnötiges Refactoring vermeiden. Aber ich bezweifle, dass dies überhaupt ein Risiko für Ihr Team darstellt.
• Ops/Metriken: Sie benötigen nicht nur Tests auf Codeebene und außerhalb Ihres Produkts, sondern auch Betriebsmetriken, um zu sehen, wie Ihr Produkt funktioniert. Und diese Metriken sollten Qualitätsparameter enthalten (Transaktionsanzahl, Geschwindigkeit, Fehleranzahl/-rate usw.). Ihr Chef sollte nicht derjenige sein, der verlangt, dass Sie Fehler beheben. Sie sollten Ihre eigenen vom Team definierten Qualitätsziele haben, die Sie dazu zwingen, in den Aufräummodus zu wechseln, wenn Sie sich außerhalb dieser Ziele bewegen.

Nächste Schritte

Seltsamerweise haben Sie nicht erwähnt, dass Ihr Chef verlangt, dass Sie bis nächste Woche 20 neue Funktionen liefern, zusätzlich zur Behebung aller Fehler. Ich nehme an, es gibt einen solchen Druck, aber Ihr Versäumnis, ihn hervorzuheben, gibt mir Hoffnung. Es deutet darauf hin, dass Sie Platz haben, um eine Unterbrechung der Bereitstellung von Funktionen zu beantragen, während Ihr Team die massiven technischen Schulden begleicht, die es angehäuft hat. Wenn Sie für Ihren Chef einen detaillierten Plan erstellen, wie Sie die Qualität Ihres Produkts systematisch verbessern und auch in Zukunft ein hohes Qualitätsniveau halten wollen , dann finden Sie vielleicht Unterstützung für einen solchen Plan.

Natürlich müssen Sie mit Ihrem Team an dem Plan arbeiten und sich ein Bild davon machen, welche Schritte am geeignetsten und effektivsten sind. Und sicherlich wird es Kompromisse geben, die auf allen Seiten eingegangen werden müssen. Möglicherweise müssen Sie das Refactoring über einige Produktzyklen amortisieren, während Ihr Chef möglicherweise die Dringlichkeit erkennt, sofort eine anständige Testsuite zu erstellen, selbst auf Kosten des Einfrierens von Funktionen.

Zusammenfassend denke ich, dass Ihre Situation absolut zu retten ist. Ich denke jedoch, dass es eine große Änderung im Denken und in der Einstellung Ihres gesamten Teams erfordert. Anstatt Ihren Chef als Feind zu sehen, sollten Sie anfangen, den Chef als Verbündeten in einer neuen Ära der Softwarequalität zu sehen. Und stellen Sie sicher, dass Sie den Fokus auf Qualität als Munition verwenden, wenn Sie Ihren Sanierungsplan verkaufen: „Nun, Sie haben uns gesagt, dass Sie alle Fehler behoben haben möchten. Wir haben einen Plan dafür, aber dafür müssen Sie uns entgegenkommen . Folgendes schlagen wir vor..."

Viel Glück!

Es gibt andere Möglichkeiten, die Produktivität bei Fehlerbehebungen zu steigern, als nur länger zu arbeiten. Ich würde dazu Ideen von Ihrem Team einholen und ihnen Zeit geben, ihre Ideen umzusetzen. Empowerment geht einen langen Weg in Richtung Moral. Für einige Ideen:

• Verbessern Sie das Testen und führen Sie vor jeder Zusammenführung Tests durch.
• Refactoring von problematischem Code.
• Priorisieren Sie Ihre Fehler, damit die wichtigen zuerst bearbeitet werden.
• Finden Sie heraus, welcher Code die meisten Fehler verursacht, und nehmen Sie sich Zeit, um seine allgemeine Qualität zu verbessern.
• Verwenden Sie Linting- oder statische Analysetools.
• Beheben Sie die Warnungen und aktivieren Sie -Wall -Werror oder das Äquivalent Ihrer Sprache.

Konzentrieren Sie sich auf die Mitarbeiter. Stellen Sie sicher, dass Sie (Best Practice) wöchentliche Einzelgespräche führen, um über größere Ziele, große Ideen und berufliche Entwicklung zu sprechen. Hier ist eine großartige Ressource mit einer Mischung aus kostenpflichtigen und kostenlosen Angeboten – die kostenlosen Dinge haben einen echten Wert: https://www.manager-tools.com/

Informieren Sie sich insbesondere über die „Einzelgespräche“.

Ich hatte vor Jahren eine Situation, in der mein Chef einen meiner Kollegen darüber informierte, dass sein Vertrag nicht verlängert würde – ein Jahr später. Kannst Du Dir vorstellen? Folgendes habe ich getan. Ich konzentrierte mich darauf, mit dem Typen zusammenzuarbeiten, um seinen Lebenslauf aufzupolieren. Was soll Ihr Lebenslauf aussagen? Lassen Sie uns etwas davon Wirklichkeit werden lassen. Wo willst du von hier aus hin? Wie kann ich Ihnen helfen, dorthin zu gelangen? Das funktionierte sehr gut, bis der Typ eine andere Gelegenheit fand, und an diesem Punkt war es ziemlich auf Schienen. Aber es hat ungemein geholfen.

Die Einzelgespräche sind der Schlüssel zur Interaktion mit Ihren Mitarbeitern – als Menschen. Übrigens, das sind keine Projekt- oder Update-Meetings. Das sind Sie als Manager, der einen Aspekt der Führung einzeln erledigt.

Es gibt ein altes Sprichwort, dass Menschen normalerweise keine Jobs kündigen – sie kündigen Manager.

Da Ihre Leute "nur" misshandelt und nicht bereits gefeuert werden, haben Sie mehr Möglichkeiten als ich. Stellen Sie sicher, dass Ihre Mitarbeiter wissen, dass Sie alles tun, was Sie zu ihrem Vorteil tun können, sei es in diesem oder im nächsten Job.

Verwenden Sie einen formellen Prozess? Ich vermute aus den kontextuellen Hinweisen und Ihrer anderen Frage, dass Sie a) Software bauen und b) in China sind. 'a' ist relevant, 'b' möglicherweise nicht, aber denken Sie daran, dass ich aus der Perspektive der Vereinigten Staaten/Kanada komme und es kulturelle/erlernte Verhaltensweisen geben kann, die die Durchführbarkeit meiner Vorschläge beeinträchtigen oder deren Anpassung erfordern. Diese Vorschläge basieren auf mehr als 20 Jahren professioneller Softwareentwicklung und der Arbeit in Unternehmen, die von kleinen Start-ups bis hin zu großen globalen Unternehmen reichen, und alles von extrem unterstützendem Management bis hin zu regellosen Despoten, die die Dinge leiten.

1. Wenn Sie dies noch nicht tun, beginnen Sie mit der testgetriebenen Entwicklung oder einer ähnlichen schnellen Feedback-Lösung, um Sie sofort zu informieren, wenn neue Commits irgendetwas kaputt machen (vorausgesetzt, Schritt 0 ist erledigt und Sie verwenden die Quellcodeverwaltung – falls Sie es tun). t, sofort umsetzen ). Das Testen muss automatisch erfolgen und bei jedem Commit durchgeführt werden.
2. Nehmen Sie einen Prozess an, um neue Arbeit aufzunehmen, auszuführen und zu liefern. Scrum ist sehr beliebt. Der Schlüssel hier ist, äußerst transparent zu sein, wie Sie schätzen und liefern, und kontinuierliches Feedback über den Fortschritt zu geben. Behalten Sie im Auge, was Sie realistischerweise liefern können: schnell, günstig, gut – wählen Sie 2. Erstellen Sie als Teil davon einen Rückstand bekannter Fehler und arbeiten Sie daran, ihn zu reduzieren.
3. Priorisieren Sie, keine neuen Fehler einzuführen. Wenn Nr. 1 etwas kaputtes zeigt, beheben Sie es, bevor Sie noch mehr Änderungen vornehmen. Wenn Sie ständig neue Fehler hinzufügen, werden Sie nie aufholen und die Produktivität wird sich nie verbessern. Und ein ständiger Kreislauf endloser Fehler ist ein sicherer Weg, Produktivität und Motivation zu schwächen.
4. Verfolgen Sie Ihren Fortschritt: Zeit bis zur Lieferung, Rate der Fehlererstellung, Anzahl der Fehlerrückstände usw. Demonstrieren Sie anhand von Daten, dass die Qualität des Produkts abnimmt, wenn das Team unter Druck gesetzt wird, mehr zu liefern, als es nach eigenen Angaben problemlos liefern kann. Feiern Sie schrittweise Verbesserungen und behandeln Sie Rückschläge als Lerngelegenheiten, nicht als Entschuldigung, um Strafen auszuteilen.
5. Helfen Sie den Teammitgliedern zu erkennen, dass die Behandlung eines Mitarbeiters durch das Management nicht den Wert dieser Person widerspiegelt. Dies ist etwas, das jede Person in Ihrem Team verstehen muss. Sie arbeiten in einer toxischen Umgebung und das fordert einen enormen Tribut von Ihrer psychischen Gesundheit. Sie merken vielleicht nicht einmal, wie es sie beeinflusst, bis jemand darauf hinweist.

Der letzte Punkt ist wahrscheinlich der wichtigste, aber die ersten 4 helfen Ihrem Team dabei, dorthin zu gelangen. Man kann Menschen nicht zwingen, sich zu "fokussieren", zumindest nicht effektiv.

Eine Beobachtung, die ich im Laufe der Jahre gemacht habe, ist, dass Unternehmen, die von Eigentümern geführt werden, die sich ständig in die Arbeit der Fachleute einmischen und versuchen, die Produktivität durch Androhung von Strafen zu drücken, auch tendenziell die am wenigsten erfolgreichen waren.

Beantworten Sie dieses Bit speziell:

Manchmal beobachte ich, dass meine Teammitglieder nicht so konzentriert arbeiten, wie sie sollten, weil wir alle wissen, dass wir wieder Überstunden machen müssen

Was hier wahrscheinlich passiert, ist, dass sie erkannt haben, dass sie nicht nur im Büro sind, bis ein paar Fehler behoben sind, sondern dass sie dort festsitzen, egal wie viele Stunden die Geschäftsleitung gewählt hat und wie viel Arbeit sie tun irrelevant.

Beheben Sie es, indem Sie das Ziel für den Tag festlegen, auf das das Team hinarbeiten kann: „3 weitere Fehler und wir können alle nach Hause gehen. X, wenn Sie Ihren Fehler beendet haben, können Sie sich mit Y paaren, damit wir alle schneller nach Hause gehen können ?"

Aber wirklich, wie alle anderen gesagt haben, ist es Ihre Aufgabe, für Ihr Team zu kämpfen, nicht, es auszunutzen. Feature Creep sollte auf die nächste Iteration verschoben werden.

Schlechte Arbeitsbedingungen belasten Ihre Mitarbeiter – egal, wer die Schuld trägt.

Das Beste, was Sie tun können, ist, das Management davon zu überzeugen, dass unbezahlte Überstunden kontraproduktiv sind und die Rate, mit der sie die „gelegentlichen Überstunden“ ziehen, wie es in den Verträgen Ihrer Mitarbeiter wahrscheinlich ist, möglicherweise illegal ist (abhängig von der Gerichtsbarkeit).

BEARBEITEN: Gemäß virolinos Kommentar muss dies sorgfältig erfolgen . Wir können Ihnen nicht sagen, welcher Ansatz bei Ihrem Management am besten funktioniert, da wir es nicht kennen. Wenn Sie dies nicht selbst beantworten können, ist es möglicherweise am besten, diese Option zu meiden.

Antwort auf Ihr erstes Update:

Auf der anderen Seite, wenn es Sonntag ist, wir aber Überstunden im Büro machen, wie viel Zeit ist akzeptabel, um soziale Medien zu nutzen?

An einem Sonntag? Ich würde sagen, mindestens acht Stunden sind akzeptabel. Obwohl ich hoffen würde, dass sie sich früher langweilen würden!

Zunächst einmal, warum macht die Wochenendarbeit nicht mehr Spaß?

Sie alle müssen am Wochenende ins Büro kommen, während noch Fehler behoben werden müssen, das ist die unglückliche Realität Ihrer Situation.

Aber Sie wissen bereits, dass niemand in der Lage sein wird, Fehler am Samstag und Sonntag zu beheben, nachdem er bereits von Montag bis Freitag gearbeitet hat.

Akzeptieren Sie also, dass sowieso niemand etwas erledigen wird. Sie können sich sicherlich etwas Besseres vorstellen, als in den sozialen Medien zu surfen?

Sie könnten mit dem Spielen von Programmierspielen wie TIS-100 und Shenzhen I/O beginnen und miteinander um Highscores konkurrieren.

Wenn alle ein bisschen entspannt sind und Spaß haben, fällt euch vielleicht ein Programmierprojekt ein, an dem ihr zehn gemeinsam arbeiten könntet? Vielleicht hat jemand von euch schon Ideen?

Es ist das Wochenende! Du wirst nicht bezahlt. Also mach was du willst.

Dann können Sie vielleicht , wenn Ihnen danach ist , in der letzten Stunde jedes Samstags und Sonntags sagen: „Okay Leute! Lasst uns jeden von uns einen Fehler nehmen und die letzte Stunde des heutigen Tages damit verbringen, ihn zu beheben!“

Ein energiegeladenes und motiviertes Team wird in einer Stunde mehr reparieren als ein demotiviertes Team an einem Wochenende.

Der Titel meiner anderen Frage kann ein wenig irreführend sein. Feature Creep ist einer der Hauptgründe, warum wir viele Fehler beheben müssen. Wir entwickeln neue Funktionen im Namen der Fehlerbehebung!

Wie arbeitest du? Es hört sich so an, als hätten Sie eine neue Funktionsliste, die ständig ergänzt wird, und daran arbeiten Sie während der Woche. und eine ebenfalls ständig wachsende Fehlerliste, an der Sie an den Wochenenden arbeiten.

Wenn Sie die Fehlerliste beheben können, müssen Sie an den Wochenenden nicht mehr kommen (so viel Sie nach der Implementierung des letzten Bits vielleicht möchten ;-) )

Teilen Sie Ihre Arbeit in Sprints auf. Planen Sie jeden mit Ihrem Team. Priorisieren Sie die Behebung von Fehlern gegenüber der Entwicklung neuer Funktionen. Retrospektiven machen. Im Grunde all die guten Sachen in der Antwort von Lawnmower Man .

Aber beheben Sie zuerst das Moralproblem, um das Team wieder auf Touren zu bringen.

Ich denke, niemand hat sich bisher mit dem Folgenden befasst: Die Leute konzentrieren sich auf "nicht" (was ich voll und ganz unterstütze) oder konzentrieren sich auf einige Codierungspraktiken.

Wenn Sie unbezahlte Überstunden nicht vollständig abschaffen können (wie es von oben kommt), was können Sie tun?

• Können Sie flexible Arbeitszeiten anbieten? „Leute und Mädels, ich weiß, wir müssen 80 Stunden pro Woche arbeiten, aber in meinem Team könnt ihr kommen und gehen, wann ihr wollt, ihr müsst nur diese Stunden arbeiten, weil ich das noch nicht ändern kann.“
• Haben Sie finanzielle Mittel, um dies zu kompensieren? Etwas finanzieller Voodoo könnte in Ihrem Griff sein. "Ich weiß, die Überstunden werden von der Firma eigentlich nicht bezahlt, aber jeder Mitarbeiter in meinem Team bekommt einen Bonus von 1.000 $, wenn wir bis Ende des Jahres 100 Bugs löschen."
• Holen Sie sich eine nicht-monetäre Entschädigung, a la Google hat es getan, um die Leute länger im Büro zu halten. „Leute, die Überstunden machen, bekommen drei Mahlzeiten kostenlos serviert, erhalten einen Pass für das hauseigene Fitnessstudio und können in den seltenen arbeitsfreien Stunden kostenlos einen Therapeuten besuchen.“ Ich übertreibe natürlich.
• Dinge, auf die ich nicht gekommen bin, aber Ihr Team auf alle möglichen Arten unterstützen. Besorgen Sie ihnen schickere Computer. Bewegen Sie sie in ein besseres Büro. Schneiden Sie dem oberen Manager die Kehle durch und schaffen Sie unbezahlte Überstunden ab. Solche Sachen.
• Wenn alles schief geht: mit dem ganzen Team kündigen und einen neuen Job finden / ein Startup gründen.

Wie kann ich meine Mitglieder verwalten, um eine angemessene Produktivität aufrechtzuerhalten, wenn mein Arbeitgeber die Mitarbeiter nicht gut behandelt?

Die letzte Hälfte der Frage ist irrelevant. Wenn Mitarbeiter nicht produktiv sind, disziplinieren Sie sie, da andere Ansätze nicht funktioniert haben. Wenn Sie nicht bereit sind, zu disziplinieren, dann versagen Sie in Ihrer Rolle.

Raten Sie, wer der Schlimmste ist, und disziplinieren Sie ihn zuerst für den Mutmacher.

Möglicherweise müssen Sie dies einige Male wiederholen. Sehen Sie in der Zwischenzeit, was Sie mit dem Chef tun können, um einige Zugeständnisse an die Moral der Mitarbeiter zu machen, wiederholen Sie das auch immer wieder. Untergraben Sie Ihren Chef nicht gegenüber den Arbeitern, sondern tun Sie Ihr Bestes für sie und Ihre Verantwortung.