12 Faktoren, die Programmierer am Arbeiten hindern

Niemand wird vom Entwickler verlangen, Code ohne Zugriff auf einen Computer zu schreiben, aber viele Unternehmen glauben, dass er irgendwie arbeiten muss, ohne seine mentalen Fähigkeiten voll ausnutzen zu können. Und das ist ungefähr so ​​unrealistisch.



Lassen Sie uns also eine Liste von zwölf Dingen durchgehen, die Entwickler daran hindern, in einen Stream-Status zu gelangen und maximale Produktivität zu erzielen. Ich werde versuchen, von den wichtigsten zu den weniger wichtigen Dingen überzugehen. Schlagen Sie Ihre Optionen und Kommentare vor!

Wenn jemand Zweifel hat, ob es sich lohnt, dafür Geld und Mühe auszugeben, reicht es aus, sich daran zu erinnern, wie viel die Programmierer bezahlt haben. Selbst eine Steigerung der Produktivität um 10% ist viel Geld!

1) Treffen und andere Ablenkungen

Meiner Meinung nach ist die Ablenkung des Entwicklers der sicherste Weg, seine Produktivität im Keim zu töten. Er kann den Ort, an dem er unterbrochen wurde, nicht einfach nehmen und fortsetzen. Zuerst muss er sich wieder in den Prozess einmischen und dann die gesamte Gedankenkette bis zum richtigen Moment durchlaufen - dies allein kann eine halbe Stunde oder länger dauern. Und je mehr solche Pausen auftreten, desto mehr Irritationen häufen sich, desto geringer wird die Qualität der Arbeit, desto häufiger treten Fehler auf, und diese Liste kann fortgesetzt werden.

„Je öfter ich abgelenkt werde, wenn ich versuche, eine Aufgabe zu starten, desto mehr Zeit vergeht zwischen den Versuchen. Wenn ich den ganzen Morgen gezogen wurde, ist es nicht verwunderlich, dass sich der Tag als unproduktiv herausstellte. “- Anonymer Entwickler bei Reddit

Was ist mit dem Treffen? Ihr einziger Unterschied zu anderen Ablenkungen besteht darin, dass sie im Voraus geplant sind. Und das macht die Situation nur noch schlimmer. Für einen Programmierer ist es schwierig, ein Problem zu lösen, wenn er eine Unterbrechung der Arbeit im Voraus erwartet. Wenn er in ein oder zwei Stunden zum Planungsmeeting gehen muss, kann er höchstwahrscheinlich für keines seiner Projekte etwas Bedeutendes tun - schließlich dauern die meisten technischen Aufgaben länger.

Wie Paul Graham sagte: "Ein Meeting kann einen halben Tag töten: Die Zeit ist in zwei Zeiträume unterteilt, für die Sie nichts Ernstes tun können."

Wie vermeide ich diesen Zustand? Darauf wurde schon lange alles gemalt, daher gibt es keine Ausreden. Sie müssen die Hobel nur ganz am Anfang des Tages oder beispielsweise kurz vor dem Abendessen aufstellen, damit Sie die Menschen nicht ohne Notwendigkeit von der Arbeit ablenken müssen.

2) Nitpicking

Von allen Arten von Managern haben diejenigen, die aus irgendeinem Grund eingreifen, möglicherweise den schlimmsten Einfluss auf die Mitarbeiterproduktivität. Dies wird natürlich auch dadurch beeinflusst, dass dieser spezielle Typ besonders dazu neigt, eine Reihe von Besprechungen zu organisieren und aus unvorhergesehenen Gründen die Aufmerksamkeit der Entwickler zu fordern. Dies ist jedoch nicht der einzige Punkt. Solche Handlungen zeigen einen Mangel an Vertrauen, und infolgedessen haben die Menschen das Gefühl, dass sie zu nichts fähig sind und ihre beruflichen Fähigkeiten in Frage stellen. Selbst wenn die Programmiererin trotz endloser Unterbrechungen immer noch motiviert ist, zu arbeiten, wird eine solche Einstellung sie völlig entmutigen. Die Folgen sind nicht auf einen Leistungsabfall beschränkt. Besonders aufdringliche Manager zwingen Mitarbeiter häufig, das Unternehmen oder zumindest das Team zu verlassen.

3) Unklar

Unklarheit kann durch viele verschiedene Beispiele veranschaulicht werden. Zum Beispiel ein Fehlerbericht im Sinne von "Es funktioniert hier nicht, behebe es!" Offensichtlich erhalten Entwickler nicht alle für die Arbeit erforderlichen Informationen. Übrigens kann in diesem speziellen Fall die Einführung einer Vorlage für Fehlerberichte hilfreich sein.

Oder ein anderer Fall: vage Anforderungen für einen Teil des Produkts. Mit einer solchen Einführung beginnen Entwickler einfach, das zu tun, was sie sich vorstellen, und dann kommt ein Manager mit einer detaillierteren Beschreibung des erwarteten Benutzerverhaltens, und alle müssen von vorne beginnen.

Undeutlich gesetzte Prioritäten gehören zur gleichen Kategorie. Programmierer verbringen viel Zeit damit, sich Gedanken darüber zu machen, womit sie beginnen sollten, obwohl es sehr einfach wäre, dies zu vermeiden. Wenn sie dem Manager jemals mitteilen müssen, warum sie damit beschäftigt sind und nicht (trotz der Tatsache, dass niemand die Bestellung festgelegt hat), können Sie sicher sein, dass dies sie großartig macht.

4) Möwenmanager

Schon mal was davon gehört? Es gibt Manager, die überhaupt nicht am Workflow teilnehmen ... außer in den Momenten, in denen sie sich plötzlich dazu entschließen, jemanden anzugreifen und einen Fehler zu machen. "Das ist nicht gut, und das auch, aber es sieht überhaupt nicht aus", und flog weiter. Ich muss zugeben, ich mag den Vergleich, aber das Phänomen dahinter ist viel häufiger als wir möchten. Dieses Verhalten wirkt sich sehr stark auf die Entwickler aus: Viele müssen dann stundenlang eine Arbeitsstimmung entwickeln, und jemand fällt für ganze Tage aus dem Stream aus.

5) Diebstahl von Lorbeeren

Ist Ihnen jemals passiert, dass einer der Manager oder andere Programmierer sich selbst zugeschrieben hat, was Sie mehrere Wochen lang gekämpft haben? Entwickler stellen ihre Professionalität über alles. Die Verdienste anderer Leute zu stehlen ist wie die Verweigerung der Kompetenz einer Person, um ihre eigene aufzublähen. Ich habe diesen Punkt hoch genug gesetzt, weil ich glaube, dass solche Dinge zu einer sehr angespannten Situation führen, die die Leistung des gesamten Teams für lange Zeit „beeinträchtigen“ kann.

6) Einrichtung: Lärm, Bewegung, Gestaltung des Arbeitsbereichs ...

Für Menschen aus anderen Berufen mag es seltsam erscheinen, aber für Programmierer entscheidet die Umgebung im Laufe der Arbeit sehr stark. Sagen wir, das weiße Rauschen - die summende Klimaanlage, das Summen von Autos und Lastwagen von der Straße - hilft ihnen, sich besser zu konzentrieren. Deshalb arbeiten viele von uns mit Kopfhörern! Übrigens habe ich kürzlich RainyMood entdeckt - eine großartige Sache!

Wenn das Büro jedoch so gestaltet ist, dass sich immer etwas um die Person bewegt, hat dies den gegenteiligen Effekt. Und wenn Monitore zusätzlich so installiert werden, dass Manager ständig sehen, was auf dem Bildschirm angezeigt wird, entsteht unnötiger Stress und unnötige Gründe, um Entwickler vom Geschäft abzulenken.

7) Versetzen Sie die Projektgrenzen

Im Projektmanagement wird dieser Begriff für Situationen verwendet, in denen das Projektvolumen unkontrolliert wächst. Dies geschieht normalerweise, wenn sie anfangs nicht genau definiert und dokumentiert waren oder dabei nicht überwacht wurden.

Aufgrund der Verschiebung von Grenzen wachsen relativ einfache Abfragen zu verwirrten Monstern, die viel Zeit verbrauchen! In den meisten Fällen beginnt dies, wenn sich das Produkt bereits in der Entwicklung befindet.

Nehmen Sie zum Beispiel eine einfache Funktion:

• Erste Version (vor der Implementierung): Die Funktion ist definiert als "Standortkarte anzeigen"
• Die zweite Version (wenn die erste Iteration fast abgeschlossen ist): Die Beschreibung ändert sich in "3D-Positionskarte anzeigen".
• Dritte Version (wenn die zweite Iteration fast abgeschlossen ist): Die Beschreibung ändert sich in "Anzeige einer 3D-Positionskarte, auf der sich der Benutzer bewegen kann".

8) Prozess zur Bestimmung des Produktmerkmals

Es mag auf den ersten Blick unverständlich erscheinen, aber tatsächlich ist alles einfach. Wenn die Verantwortlichen des Produkts Prioritäten setzen, ohne ihre Hypothesen (durch Feedback oder auf andere Weise) über das Interesse des Publikums an bestimmten Opportunities zu testen, und die Entwickler feststellen, dass diese Opportunities einfach nicht genutzt werden, haben sie das Gefühl, dass Ihre Arbeit macht keinen Sinn und die Motivation wird zusammenbrechen. Wir alle möchten das Gefühl haben, dass wir Spuren in der Welt hinterlassen, und dies ist besonders wichtig für Entwickler!

9) Technische Schulden ignorieren

Technische Pflicht ist eine bewusste Entscheidung, bei der Auswahl von Lösungen und beim Schreiben von Code eine gewisse Anstrengung zuzulassen, um das Produkt schneller einzuführen. Ein gewisses Maß an technischer Verschuldung entsteht zwangsläufig bei jedem Projekt und kann bei Fristen über kurze Strecken helfen. Auf lange Sicht erhöht dies jedoch die Komplexität des Systems und verlangsamt dadurch die Entwickler. Menschen, die weit davon entfernt sind, zu programmieren, unterschätzen häufig die Auswirkungen dieser Prozesse auf die Produktivität und müssen ununterbrochen vorankommen - in dieser Situation treten Probleme auf. Wenn Refactoring immer außerhalb der Prioritätenliste bleibt, leidet nicht nur die Produktivität der Mitarbeiter, sondern auch die Qualität des Produkts.

10) Eine Vielzahl von Werkzeugen und Geräten

Entwickler verwenden täglich viele Tools zum Schreiben, Pushen und Zusammenführen von Code. Je mehr sie es schaffen, Prozesse zu automatisieren, desto besser. Es versteht sich von selbst, dass alte Werkzeuge einen direkten Einfluss auf die Leistung haben. Es entscheidet auch viel darüber, woran die Arbeit erledigt wird - auf einem Laptop oder auch auf einem zusätzlichen Bildschirm. Wenn wir die Eisenpreise mit den Gehältern der Programmierer vergleichen, zahlt sich sogar eine Steigerung der Produktivität um 5% definitiv alle Kosten aus! Sie müssen dem Team nur die Geräte und Werkzeuge zur Verfügung stellen, die es bevorzugt (für Geräte sollte die Lösung individuell sein, für Werkzeuge - kollektiv).

11) Dokumentation

Während des Programmierunterrichts haben wir alle gelernt, dass Sie so schnell wie möglich und so oft wie möglich Kommentare zum Code hinzufügen müssen. Die Idee war, dass es besser wäre, wenn es zu viele Kommentare gäbe, als nicht genug. Leider haben viele Leute dies missverstanden und entschieden, dass jede Zeile einer Erklärung bedarf. Deshalb haben wir Beispiele wie dieses aus Jeff Atwoods Artikel „Code ohne Kommentar“:

r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}

Verstehst du, was dieser Code im Allgemeinen macht? Also habe ich nichts verstanden. Das Problem ist, dass hier viel darüber gesagt wird, wie alles funktioniert, aber kein Wort darüber, warum dies benötigt wird. Wenn wir davon ausgehen, dass ein Fehler im Programm aufgetreten ist und Sie ein solches Codefragment unter der Haube gefunden haben, hätte dies Ihnen nicht geholfen, die Situation herauszufinden.

12) Extrem enge Fristen

Der letzte Punkt hängt mit der Tendenz der Manager zusammen, die Entwickler zu bitten, grob zu schätzen, wie viel Zeit sie benötigen, dann auf sie zu drücken, um diese Schätzung zu unterschätzen, und dann das Enddatum auf magische Weise mit der Frist gleichzusetzen! Gleichzeitig glauben die Manager sogar, dass die Entwickler, da sie „die Fristen selbst festlegen“, sich für die entsprechende Frist angemeldet haben und als endgültig genehmigte Option betrachtet werden sollten, die an die Geschäftsleitung übertragen werden kann.

Die Entwickler glauben, dass eine solche Frist völliger Wahnsinn ist und es unmöglich ist, sie einzuhalten. Es gibt Zwietracht im Team und niemand kann sich konzentrieren.

Aber geht es nur um Entwickler?

Wenn Sie sich all diese 12 Punkte ansehen, werden Sie feststellen, dass sie größtenteils für alle an Projekten Beteiligten relevant sind. Es ist nur so, dass Programmierer besonders kritisch sind, da ihre Arbeit ein tiefes Eintauchen in den Prozess erfordert.

Wenn Sie feststellen, dass einige der genannten Punkte für Ihr Unternehmen typisch sind, sollten Sie diese Liste mit dem Entwicklerteam durchgehen, einen Dialog mit ihnen aufbauen, herausfinden, wo die Probleme auftreten und wie sie am besten gelöst werden können. Was auch immer sie sagen, es ist äußerst wichtig, dieses Feedback und diese Kommentare ernst zu nehmen. In den letzten dreißig Jahren hat sich in Bezug auf die Technologie viel geändert, aber das Grundprinzip der Teamarbeit bleibt dasselbe: Bei der Diskussion über die Leistung muss der menschliche Faktor berücksichtigt werden. Verbessern Sie Ihre Arbeitsprozesse, Ihre Umgebung und Ihre Teamgewohnheiten und geben Sie ihnen die Möglichkeit, Ihnen zu erklären, wie Sie maximale Produktivität erzielen können.