Get best of the week

Warum Entwickler so langsam sind: häufige Probleme und ihre Lösungen

Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Artikels Warum Entwicklungsteams langsam sind: Häufige Software-Staus und -Lösungen von Eric Elliot.



Wenn Sie mehr zuhören als lesen möchten , ist die Übersetzung im Audioformat für Yandex.Music- und Apple-Podcasts verfügbar .

Schauen wir uns an, was Störungen im Softwareentwicklungsprozess verursacht und was Sie als Manager dagegen tun können. Es kann viele Gründe geben, daher wird unsere Liste natürlich alles andere als vollständig sein. Stattdessen konzentrieren wir uns auf einige der häufigsten Probleme :

  • Unrealistische Erwartungen
  • Zu viele offene Tickets
  • Unkontrollierter Aufgabenbereich
  • Überprüfung des Akkumulationscodes
  • Schlechte Vorbereitung
  • Burnout-Entwickler
  • Bugs
  • Mitarbeiterfluktuation

Langsame Entwicklung ist nicht die Wurzel des Problems. Dies ist ein Symptom für die anderen aufgeführten Probleme. In 100% der Fälle ist es die Schuld des Leiters, wenn das Entwicklungsteam zu langsam arbeitet. Aber die gute Nachricht ist, dass Sie es beheben können. Schauen wir uns die einzelnen Elemente genauer an, um zu verstehen, was wir mit den einzelnen Elementen tun können.

Unrealistische Erwartungen


Die meisten Probleme mit der Produktivität von Entwicklern wirken sich im Allgemeinen nicht auf die Entwicklung selbst aus. Es ist eher ein Problem unserer Wahrnehmung des Entwicklungsprozesses als Manager und Stakeholder.

Der schwierigste Teil der Arbeit eines Managers besteht darin, zu verstehen, dass das Schreiben von Code genauso lange dauert wie der Versuch, diesen Prozess zu beschleunigen, ihn nur verlangsamt und die Anzahl der Fehler erhöht. Geduld ist unser Alles.

Meistens besteht das Problem mit der Arbeitsgeschwindigkeit nicht darin, dass das Team nicht produktiv genug ist, sondern dass es hohen Erwartungen ausgesetzt ist. Und das liegt ganz in Ihrer Verantwortung. Wenn der Druck von einer höheren Führung ausgeht, haben Sie sich nicht die richtige Sicht auf die Situation gebildet. Wenn Sie Druck ausüben, lesen Sie weiter.

Wir vergessen oft, dass die von uns erstellte Software etwas grundlegend Neues ist. Wenn Sie bereits eine Software haben, die dasselbe tut, kaufen Sie sie, verwenden Sie sie, importieren Sie das Modul usw. Sie müssen es nicht von Grund auf neu schreiben. Die neue Software ist einzigartig. Er macht etwas Neues oder macht etwas anderes. Dann schaffen wir es. Und da wir dies noch nicht getan haben, woher wissen wir, wie lange es dauern wird?

Bauherren bauen vorgefertigte Wände im gleichen Tempo und können daher auf der Grundlage von Beobachtungen mehr oder weniger genaue Schätzungen abgeben. Softwareentwickler haben keine verlässlichen Daten, auf die sie sich verlassen können. Dieses Problem wird durch die unterschiedlichen Geschwindigkeiten der verschiedenen Entwickler verschärft und kann um eine Größenordnung variieren.

Steve McConnell, Autor von The Perfect Code, schreibt: „Die Schlussfolgerung, dass es einen signifikanten Unterschied zwischen der Produktivität verschiedener Programmierer gibt, wurde durch viele Studien von professionellen Entwicklern bestätigt (Curtis 1981, Mills 1983, DeMarco und Lister 1985, Curtis et al. 1986, Card 1987) Boehm und Papaccio 1988, Valett und McGarry 1989, Boehm et al. 2000). Wir haben nicht genügend Daten, um vorherzusagen, wie lange es dauern wird, bis unser Projekt abgeschlossen ist. Wir werden herausfinden, wie groß und komplex die Arbeit bereits ist, und dieser Prozess ist oft mit vielen Überraschungen behaftet. "Entwicklung ist nicht nur Planung, sondern auch Forschung, egal wie sorgfältig wir versucht haben, alles vorauszusehen."
« 90 10 , . 10 90 »
— , Bell Labs

Es gibt mehrere Gründe für hohe Erwartungen, die ein Manager kontrollieren kann. Einer der fundamentalen Gründe ist das Messen der falschen Dinge.
Vielleicht kennen Sie Peter Druckers berühmtes Sprichwort: "Was gemessen wird, wird kontrolliert."

Und das ist natürlich ein toller Rat. Natürlich müssen wir messen! Aber wir vermissen die Essenz dieses Zitats, außerdem stellen wir seine Bedeutung auf den Kopf.

Die ganze Idee lautet: „Was gemessen wird, wird kontrolliert, auch wenn es gemessen wird und der Versuch zu kontrollieren völlig nutzlos ist, selbst wenn es den Zielen der Organisation schadet.“

Zwei Beispiele für Dinge, die es nicht wert sind, gemessen zu werden:

  1. Vorausschauende Burndown-Diagramme mit einer grafischen Darstellung der Anzahl offener Tickets, die das Enddatum eines Projekts basierend auf aktuellen Messungen der Arbeitsgeschwindigkeit vorhersagen.
  2. Die Anzahl der vom Entwickler geschlossenen Tickets, aus der hervorgeht, wie viele Aufgaben ein einzelner Entwickler ausgeführt hat.

Das Messen dieser beiden Dinge kostet unzählige Unternehmen enorme Verluste aufgrund von Produktivitäts-, Mitarbeiter- und anderen Kostenverlusten.

Aufgabenfortschrittsdiagramme


Viele Softwaretools versuchen, das Abschlussdatum des Projekts auf der Grundlage des aktuellen Aufgabenumfangs und der Arbeitsgeschwindigkeit vorherzusagen. Das Problem ist, dass keiner von ihnen das unerforschte Aufgabenvolumen berücksichtigt. Darüber hinaus ist dies nicht möglich, da die Zeit, die zum Schließen einer Aufgabe benötigt wird, für verschiedene Aufgaben um eine Größenordnung variieren kann, was die Durchschnittswerte, die für bereits geschlossene Tickets berechnet wurden, erheblich verzerren kann.

Wenn Sie eine Frist basierend auf dem Datum aus dem Diagramm festlegen, berücksichtigen Sie, dass Sie die Fristen nicht eingehalten haben. Das einzige, was Sie retten können, ist, in Zukunft so viele Aufgaben wie möglich aus dem Rahmen zu werfen.

Wenn Sie Ihre Noten auf unvollständige Informationen stützen, werden Sie und Ihr Team definitiv dafür bezahlen. Unrealistische Schätzungen erzeugen unrealistische Erwartungen. Dies kann eine echte Katastrophe sein, wenn Sie diese Bewertungen auch dem Marketingteam, den Kunden und der Presse mitteilen.

Nicht alle Diagramme sind böse. Diejenigen, die nicht versuchen, die Zukunft vorherzusagen, können nützlich sein. Sie können uns vor der Ausbreitung des Projekts und kombinatorischen Explosionen warnen, wenn Sie feststellen, dass die Anzahl der Tickets zunimmt, anstatt abzunehmen oder sich auf und ab zu bewegen. Nützliche Aufgabendiagramme zeigen bereits realistisch abgeschlossene Aufgaben, anstatt zu versuchen, die Zukunft vorherzusagen.

Ein guter Indikator ist eine Kurve mit Höhen und Tiefen, die sich jedoch insgesamt nach unten bewegt, was eine Abnahme der Anzahl offener Aufgaben bis zum Ende des Projekts zeigt.

Projektplan, bei dem die Anzahl der Tickets reduziert wird

Ein Projekt, das unter einem überwucherten Umfang leidet, wird gegenüber durch eine Kurve dargestellt, die sich nach oben biegt.

Zeitplan eines Projekts, das in neuen Aufgaben ertrinkt

Denken Sie daran, dass der Punkt beim Beobachten dieser Kurve nicht darin besteht, zu versuchen, sie zu ändern, sondern zugrunde liegende Probleme zu erkennen und zu lösen. Wir möchten nicht, dass Programmierer einfach aufhören, neue Tickets zu öffnen.

Das Ziel ist die Transparenz der Prozesse, keine schöne Abwärtskurve.

Hüten Sie sich vor dem Goodhart-Prinzip : „Wenn eine Dimension zum Ziel wird, ist sie nicht mehr nützlich.“

Keine Prognose ist schädlich. Wenn Sie eine harte Frist haben (z. B. wenn Sie versuchen, ein Spiel vor dem Black Friday zu veröffentlichen), können Sie den Bereich systematisch anhand der durchschnittlichen Arbeitsgeschwindigkeit steuern, sodass Sie wissen, wann Sie mit dem Trimmen des Bereichs beginnen müssen. Wenn die Prognose besagt, dass Sie frühestens im Dezember fertig sein werden, vertrauen Sie ihr. Es ist an der Zeit, Prioritäten zu setzen und zu reduzieren.

Die Faustregel für Vorhersagen dieser Art lautet:
"Wenn die Vorhersage besagt, dass Sie bis zu einem bestimmten Datum etwas tun können, glauben Sie es nicht. Wenn es besagt, dass Sie es nicht tun können, glauben Sie es."

Tickets von einem Programmierer geschlossen


Die Idee, alle von einem Programmierer ausgeführten Aufgaben wiederzugeben und diese Zahl dann mit dem Durchschnittswert zu vergleichen, ist sehr verlockend. Aber ich fordere Sie auf, dieser Versuchung zu widerstehen. Es gibt unzählige bessere Möglichkeiten, Daten zur Entwicklerproduktivität zu erfassen.

Es gibt zwei grundlegende Mängel bei der Berechnung geschlossener Aufgaben. Erstens sind die Aufgaben in Komplexität und Bedeutung nicht identisch, und tatsächlich hängt der Wert der Arbeit vom Potenzgesetz ab. Eine kleine Handvoll Aufgaben hat eine Größenordnung mehr Bedeutung als der „Durchschnitt“. Es ist wie der Unterschied zwischen dem Fundament eines Wolkenkratzers und dem letzten verstopften Nagel. Durch einfaches Zählen der Anzahl geschlossener Tickets ist es daher unmöglich, den Wert eines Mitarbeiters genau zu kennen.



Vor vielen Jahren habe ich an einem Einkaufskorb für einen weltweit führenden Einzelhandelsunternehmen gearbeitet. Einmal hörte ich auf, Code zu schreiben und Tickets in Jira zu schließen, und fügte ein weiteres Ticket hinzu: „Usability-Studie“.

Ich arbeite seit über einem Jahr an einer Neugestaltung des Warenkorbs und das Erscheinungsdatum rückt näher. Bis zu diesem Zeitpunkt wurden vom Benutzer keine Usability-Tests des neuen Bestellvorgangs durchgeführt, daher dauerte es eine Woche. Wir haben den tausend loyalsten Unterstützern frühzeitig Zugang gewährt und sie interviewt, um Feedback zu erhalten.

Ich habe die Ergebnisse analysiert und einen alarmierenden Trend bei Umfragen und Protokollen festgestellt: Die Häufigkeit, mit der Benutzer die Website im Warenkorb verlassen, war zu hoch und wurde in einer zweistelligen Zahl ausgedrückt. Eine echte Katastrophe kam! Also machte ich mich an die Arbeit und plante, neue Usability-Tests mit persönlicher Präsenz aufzunehmen. Ich setzte die Neulinge hinter unseren neuen Korb, gab ihnen einige Aufgaben und ließ sie mit der Seite allein. Ich habe nichts gesagt, ich habe nur zugesehen, wie sie die neue Benutzeroberfläche verwendet haben.

Mir ist aufgefallen, dass bei der Bestellung Probleme mit Fehlern in den Formularen auftreten. Mit diesen Daten habe ich unser Open-Source-Projekt auf dem Github leicht korrigiert (ohne etwas in der Gira zu bemerken). Nach einiger Zeit führten wir einen weiteren Test durch. Die Wahrscheinlichkeit, dass Benutzer die Seite des Warenkorbs verlassen, ist viel geringer: Die Einkommensdifferenz für das Unternehmen beträgt 1 Million US-Dollar pro Monat.

In der Zwischenzeit haben meine Kollegen jeweils 10-15 Tickets geschlossen. Sie könnten argumentieren, dass ich einfach mehr Tickets für Usability-Tests bekommen könnte, um die Realität widerzuspiegeln. Aber dann müsste ich tausend zusätzliche Tickets machen, was nur Lärm verursachen und viel Zeit erfordern würde.

Ein weiterer Grund, warum das Zählen geschlossener Tickets unwirksam ist, liegt darin, dass die effektivsten Teammitglieder auch die Personen sind, an die sich alle wenden, um Hilfe zu erhalten. Sie wissen am besten über die Codebasis Bescheid, sind großartige Entwickler oder verfügen über hervorragende Kommunikationsfähigkeiten. Sie helfen Ihnen, den Rückstand an Pull-Anfragen zu überwinden, den Code anderer Programmierer zu überprüfen, Ihre Teamkollegen zu schulen und zu betreuen. Sie sind die produktivsten im Team, weil sie dem Rest des Teams helfen, die Arbeitsgeschwindigkeit zu verdoppeln. Vielleicht sind die Tickets, die sie schließen, die Schaffung von Frameworks oder Bibliotheken, die die Produktivität des gesamten Teams steigern. Sie erledigen den größten Teil der Arbeit, während der Rest Anerkennung erhält.

Wenn Sie nicht vorsichtig sindDann sehen Sie den Beitrag Ihrer produktivsten Entwickler. Der beste Weg, um herauszufinden, was Programmierer für ein Projekt tun, besteht darin, sie zu fragen. Fragen Sie das Team, wer ihrer Meinung nach der hilfreichste Kollege ist.

Normalerweise unterscheiden sich die Informationen, die in diesem Feedback enthalten sind, stark von den Daten, die durch einfaches Zählen der Anzahl der Tickets erhalten werden können.

Sammeln Sie Leistungsdaten, aber sprechen Sie nicht jeden Entwickler mit einer Maßnahme an. Entwicklung ist ein Mannschaftssport und jeder Teilnehmer des Prozesses spielt dabei eine Rolle. Es gibt keine einzige magische Methode, die ausnahmslos für die Bewertung aller geeignet wäre.

Zu viele offene Aufgaben


Es scheint einfach - öffnen Sie ein Ticket im Tracker und fahren Sie fort. Jede Aufgabe im Tracker erfordert jedoch einen gesamten Verarbeitungszyklus.

Sie müssen sortiert, priorisiert und einem Künstler zugewiesen werden, bevor Entwickler mit der Implementierung beginnen können. Diese Arbeit wird jedes Mal wiederholt, wenn Entwickler eine Aufgabe schließen und die nächste auswählen. Wenn Sie einen Projektmanager oder einen Scrum Master haben, tun diese dies jedes Mal, wenn sie die Liste der Aufgaben neu priorisieren (was normalerweise zu Beginn des Sprints oder nur einmal alle paar Wochen geschieht).

Dann muss der Entwickler in den Kontext der Aufgabe eintauchen, die Essenz des Problems verstehen, komplexe Aufgaben in Unteraufgaben zerlegen und erst dann können Sie endlich mit der Ausführung beginnen.

Das Erstellen und Lesen von Tickets ist viel Arbeit, aber es ist wie ein falscher Job. Dies ist eine Meta-Aufgabe. Sie wird benötigt, um echte Aufgaben zu beginnen. An sich haben sie den Wert Null. Und dies braucht jedes Mal Zeit, wenn Programmierer die nächste Aufgabe auswählen. Je weniger Tickets gleichzeitig im Tracker sind, desto besser. Je weniger Aufgaben mit niedriger Priorität im Backlog hängen, desto höher ist die Wahrscheinlichkeit, dass der Entwickler eine Aufgabe mit hoher Priorität auswählt.

Wenn es einen Fehler gibt, den nur ein Benutzer erwähnt hat, wie wichtig ist er für uns? Er hat eine Person berührt, aber haben wir Fehler, die mehr Menschen bemerkt haben? Gibt es neue Funktionen, die nützlicher sind als die Behebung dieses Fehlers?
Wahrscheinlich ja.

Entfernen Sie das Rauschen aus dem Rückstand. Löschen Sie, was Sie in naher Zukunft nicht vorhaben.
Wenn dies wirklich wichtig ist, fügen Sie es später hinzu, wenn dafür Zeit ist.

Unkontrollierte Aufgabengröße


Ich möchte Entwickler in meinem Team bitten, die Arbeit in Aufgaben zu unterteilen, die sie an einem Tag erledigen können. Dies ist komplizierter als es scheint, da es die Fähigkeit erfordert, komplexe Aufgaben in kleine zu unterteilen, die auch getrennt vom Rest der Anwendung getestet werden können.

Beispiel: Sie führen einen neuen Checkout-Prozess auf einer Site durch. Sie müssen UI-Komponenten, Statusverwaltung und Kommunikation mit dem Server nicht zu einem riesigen Commit mit 13 Dateien zusammenfassen, die eng mit der aktuellen Codebasis verbunden sind, da das Ergebnis eine große Pull-Anforderung ist, die schwer zu überprüfen und zusammenzuführen ist.

Beginnen Sie stattdessen mit einem unabhängig getesteten clientseitigen Korbstatusmodul und führen Sie dazu eine Pull-Anforderung durch. Erstellen Sie dann die Server-API und erstellen Sie auch für ihn eine separate PR. Schreiben Sie dann eine UI-Komponente, die den Status aus dem Modul importiert und mit der Server-API kommuniziert. Jede dieser Aufgaben kann in separate Aufgaben unterteilt werden, obwohl dies alles im Wesentlichen ein großes Merkmal ist. Als Bonus können Aufgaben auf mehrere Programmierer verteilt werden und die Entwicklung beschleunigen, wobei die Größe des Teams genutzt wird.

Der Feature-Switcher macht diesen Prozess einfacher und sicherer und ermöglicht es Ihnen, die entwickelte Funktionalität auszuschalten, bis sie für die Produktion bereit ist.

Beachten Sie:Versuchen Sie dies nicht ohne eine gute Abdeckung der Rauchtests. Sie sollten in der Lage sein, sicherzustellen, dass Sie nichts kaputt gemacht haben, indem Sie halbfertige Funktionen bereitstellen. Überprüfen Sie unbedingt, wie es ein- und ausgeschaltet funktioniert.

Anhäufung von Aufgaben durch Codeüberprüfung


Wenn Entwickler mehr abbeißen, als sie schlucken können, ist das Ergebnis eine riesige Pull-Anfrage, die auf Überprüfung und Verifizierung wartet.

Dies ist die Integrationsphase in „Continuous Integration“ (CI). Das Problem ist, dass je länger die PR geöffnet bleibt, desto mehr Zeit wird dafür aufgewendet. Entwickler werden es öffnen, um zu sehen, ob sie helfen können, es einzudämmen. Sie hinterlassen Feedback, fordern Änderungen an und die Anfrage wird an den Autor zurückgesandt, um Änderungen vorzunehmen und diese Änderungen weiter zu genehmigen. In der Zwischenzeit wird sich all diese Pull-Anforderung weiter vom Master entfernen.
Wenn mehrere Entwickler die Gewohnheit haben, sehr große Commits zu tätigen, wächst die Anzahl der Pull-Anfragen wie ein Schneeball und die Integration wird immer komplizierter.

Beispiel: Bob nimmt Änderungen an einer Datei vor, die Jane ebenfalls regiert, aber noch nicht verpfändet hat. Bobs Pull-Anfrage wird zuerst gehalten und PR Jane wird ein Commit weiter vom Master entfernt. Jetzt kann sie ihren Zweig nicht behalten, bis sie alle Konflikte mit Bobs Code behoben hat. Multiplizieren Sie diese Situation mit der Anzahl der Programmierer, die in Ihrem Projekt mit demselben Code arbeiten. Solche „Staus“ führen zu einem Übermaß an Aktionen.

Wir berechnen die Anzahl solcher Aktionen im Standardszenario:

  • Bob und Jane beginnen ihre Arbeit in derselben Branche (0 Aktionen)
  • Bob nimmt Änderungen vor und verpflichtet sich zu seiner Niederlassung. Jane macht dasselbe (2 Aktionen)
  • Bobs Code geht an Master. Jane lädt Bobs Änderungen herunter und entdeckt einen Konflikt. Sie korrigiert es und schreibt das Ergebnis in ihren Thread. (3 Aktionen)
  • Jane öffnet eine Pull-Anfrage. Bob merkt an, dass ihre Änderungen in seinem Code etwas zerstören werden, das sie nicht berücksichtigt hat. Jane nimmt Änderungen basierend auf Bobs Kommentaren vor und schreibt den Code erneut fest (4 Aktionen)
  • PR Jane verschmilzt schließlich. Nur 4 Aktionen.

Stellen Sie sich nun eine Situation vor, in der die Commits geringer wären und Pull-Anforderungen schneller flackern würden:

  • Bob nimmt eine kleine Änderung vor und sein Code fällt in den Master (1 Aktion)
  • Jane lädt die neue Version des Assistenten herunter und schreibt ihren Code unter Berücksichtigung der Änderungen von Bob. (2 Aktionen)
  • Da das Begehen von Jane auch klein ist, wird er schnell im Meister festgehalten. Insgesamt nur zwei Aktionen.

Wenn wir kleine PRs erstellen, reduzieren wir die Notwendigkeit, den Code zu wiederholen, erheblich, was durch Konflikte und Codekomplexität verursacht wird.

Schlechte Vorbereitung


Die IT-Branche ist in Bezug auf Schulung und Support schrecklich. Die Universitäten unterrichten Algorithmen, die bereits in Standardbibliotheken integriert sind, und nur wenige Programmierer schreiben sie von Grund auf neu.

Während die Grundlagen der Entwicklung wie die Prinzipien der Abstraktion, des Zusammenhalts und des Engagements, der Modularität im Vergleich zum monolithischen Design, der Arbeit mit Modulen, der Zusammensetzung von Funktionen, der Zusammensetzung von Objekten, dem Entwurf von Frameworks und der Anwendungsarchitektur übersehen werden. Aufgrund des explosiven Wachstums der Branche verfügt ungefähr die Hälfte der Entwickler über weniger als fünf Jahre Erfahrung, und 88% der Spezialisten glauben, dass Schulungen ihnen nicht schaden würden.

Teams arbeiten langsam, weil sie ein schlechtes Verständnis dafür haben, was sie tun, und niemand sie unterrichten möchte.

Unsere Aufgabe als Manager ist es, erfahrene Spezialisten einzustellen, die unsere Teams leiten und ihnen dafür Zeit geben können.

Was kann getan werden:

  • Codeüberprüfung: Entwickler lernen viel, indem sie den Code des anderen lernen
  • Erstellen von Paaren von Senior- und Junior-Ingenieuren: Es ist nicht erforderlich, permanente Paare zu erstellen. Eine einmalige Vereinigung zur Lösung eines bestimmten Problems funktioniert einwandfrei.
  • Besondere Zeit für Mentoring: Stellen Sie erfahrene Fachkräfte ein, die gerne lernen und gut kommunizieren, und geben Sie ihnen Zeit, Erfahrungen mit Nachwuchsentwicklern auszutauschen. Dies hilft letzteren zu verstehen, wie sie ihre Fähigkeiten entwickeln.

Ausbrennen


Das Ausbrennen Ihres Teams ist ein großer Rückschlag für den Leiter, als die Fristen nicht einzuhalten.

Burnout ist ein ernstes Problem, das zum Verlust von Entwicklern, zur Fluktuation, zu enormen Kosten und zu einem erhöhten Bassfaktor führen kann (Busfaktor - ein Maß für die Konzentration von Informationen zwischen einzelnen Projektmitgliedern; der Faktor bedeutet die Anzahl der Projektteilnehmer, nach deren Verlust das Projekt von den verbleibenden Teilnehmern nicht abgeschlossen werden kann). .

Noch wichtiger ist jedoch, dass Burnout zu gesundheitlichen Problemen führt. Die Folgen von Burnout können zu einer Destabilisierung des Körpers und sogar zum Tod durch Herzinfarkt oder Schlaganfall führen. In Japan ist dieses Phänomen so weit verbreitet, dass sie sogar ein spezielles Wort haben: „Karoshi“.

Der Leiter kann das gesamte Team ausbrennen und so seine Produktivität vollständig zunichte machen. Das Problem, ganze Teams auszubrennen, ist besonders häufig in der Computerspielentwicklungsbranche anzutreffen, wo der Schwarze Freitag fast immer eine schwierige Frist ist.

Leider ist „sterben, aber tun“ ein gängiges Prinzip bei der Organisation der Arbeit dieser Teams, obwohl Manager die Gefahren eines solchen Ansatzes selten erkennen.

Anstatt Entwickler zu mehr Arbeit zu zwingen, sollten Manager erkennen, dass 100% der Verantwortung für die Einhaltung von Fristen beim Management und nicht bei den Entwicklern liegt.

Die Frist ist einfacher, wenn Sie die folgenden Techniken anwenden:

  • Priorisieren Sie Aufgaben besser und reduzieren Sie den Umfang
  • Prozesse rationalisieren
  • Code-Verwirrung erkennen und umgestalten

Mitarbeiterfluktuation


Die von Linkedin im Jahr 2018 gesammelten Daten zeigten, dass die Fluktuation der IT-Mitarbeiter der in jedem anderen Unternehmen überlegen ist. Und das ist schlecht, weil es das Risiko des Bassfaktors verursacht, das Risiko, dass Sie wichtige Spezialisten Ihres Projekts verlieren.

Viele Unternehmen legen keinen Wert darauf, Spezialisten zu halten. Schauen wir uns genauer an, wie viel die Fluktuation kostet.

Die Vermittlung von Stellen kostet 15-30 Tausend Dollar. Die Ingenieurzeit kostet durchschnittlich 90 USD pro Stunde. Multiplizieren Sie dies mit etwa 50 Interviews und vielen, vielen Stunden, um die Fragen des Neulings zu beantworten und ihm zu helfen, im Team Fuß zu fassen. Wir haben also bereits 50.000 Dollar ausgegeben, aber das ist noch nicht alles.

Es kann bis zu einem Jahr dauern, bis ein neuer Mitarbeiter das Niveau des Entwicklers erreicht, den er ersetzt hat. Beim ersten Mal macht er viele Fehler und verbringt viel Zeit damit, sie zu beheben.

Die Einstellung und Schulung eines neuen Entwicklers, die Opportunitätskosten und der Produktivitätsverlust eines Teams, das einen Anfänger für einige Zeit schulen und gleichzeitig einen Teil seiner Arbeit ausführen muss, machen fast 90% des Gehalts eines verstorbenen Entwicklers aus. Das Finden eines Ersatzes kann mehrere Monate dauern, und dann dauert es etwas länger, bis der Anfänger seine volle Wirksamkeit erreicht hat.

Dies ist alles sehr zeitaufwändig und große Teams leiden ständig unter laufenden Umsätzen, da laut einer Umfrage von Stack Overflow aus dem Jahr 2019 60% der Entwickler in den letzten zwei Jahren ihren Arbeitsplatz gewechselt haben.

Wenn der Entwickler endlich anfängt, mit maximaler Effizienz zu arbeiten, werden Sie es verlieren.

Wie vermeide ich Fluidität? Hier einige Tipps aus verschiedenen Quellen:

  • Zahlen Sie ehrlich
  • Erhöhen Sie Ihr Gehalt regelmäßig
  • Lass die Leute lange Ferien machen
  • Fernarbeit anbieten
  • Halten Sie realistische Erwartungen
  • Stellen Sie Aufgaben bereit, die für den Entwickler von Interesse sind
  • Lass den Tech-Stack nicht zu alt werden
  • Bereitstellung von Ausbildungs- und Karrieremöglichkeiten
  • Nutzen Sie die Gesundheit
  • Zwingen Sie Entwickler nicht, mehr als 40 Stunden pro Woche zu arbeiten
  • Stellen Sie den Mitarbeitern moderne Geräte zur Verfügung

Bugs


Wenn Sie der Meinung sind, dass Sie keine Zeit haben, einen qualitativ hochwertigen Entwicklungsprozess zu implementieren, können Sie wirklich nicht darauf verzichten.

Laut Evaluating Software Engineering Technologies (David N. Card, Frank E. Mc Garry, Gerald T. Page, 1978) können gut optimierte Prozesse Fehler reduzieren, ohne die Kosten zu erhöhen. Der Hauptgrund ist, dass laut einem anderen Buch, „Software Assessments, Benchmarks und Best Practices“ (Casper Jones 2000), die Fehlererkennung und -korrektur eine der zeitaufwändigsten und teuersten Aufgaben in der Entwicklung ist.

Fehler sind dafür berüchtigt, dass sie Code verarbeiten müssen. Je später Sie sie finden, desto teurer wird es, sie zu beheben. Wenn ein Entwickler angewiesen wird, einen bereits in der Produktion entdeckten Fehler zu beheben, reißt ihn dies oft von dem ab, was er getan hat. In dem Buch „Eine Tagebuchstudie über das Wechseln und Unterbrechen von Aufgaben“ (Mary Czerwinski, Eric J. Horvitz, Susan Wilhite) heißt es, dass eine Aufgabe, von der wir abgelenkt sind, doppelt so viel Zeit in Anspruch nehmen und doppelt so viele Fehler enthalten kann, was darauf hindeutet dass Fehler mit hoher Priorität in gewisser Weise ansteckend sind: Wenn wir einen Fehler beheben, werden wir wahrscheinlich neue Fehler erzeugen.

Fehler in der Produktion erfordern auch, dass wir dem Support mehr Aufmerksamkeit schenken und sind sehr nervige und ermüdende Benutzer, was Sie letztendlich Geld kosten wird. Sie müssen in die Korrektur der alten Funktionalität investieren, anstatt eine neue zu erstellen.

Ein in der Entwicklungsphase gefundener Fehler kann in wenigen Minuten behoben werden, während ein in der Produktion gefundener Fehler viele zusätzliche Phasen durchläuft: Melden eines Fehlers, Überprüfen, Priorisieren, Ernennen eines Künstlers und schließlich Entwickeln.

Aber das ist nicht alles. Dieser Fehler hat sein eigenes Commit, seine Pull-Anfrage, seinen Überprüfungscode, seine Integration und möglicherweise sogar seine eigene Bereitstellung. In jedem Stadium kann ein Test fallen und der gesamte CI / CD-Zyklus muss neu gestartet werden.

Wie bereits erwähnt, kostet ein Fehler in der Produktion viel mehr als ein Fehler, der während der Entwicklung festgestellt wurde.

Die folgenden Tipps tragen zur Verbesserung der Prozessqualität bei.

  • Verlangsamen Sie, um zu beschleunigen. Langsam bedeutet ununterbrochen, ununterbrochen bedeutet schnell.
  • Führen Sie eine Entwurfsprüfung durch. Durch die Kombination von Codeüberprüfung und Anforderungen können Sie bis zu 70% der Fehler abfangen.
  • Überprüfung der Postleitzahl. Gut getesteter Code ist 90% einfacher zu warten. Eine Stunde Überprüfung erspart Ihnen 33 Stunden Support. Programmierer, die Codeüberprüfungen durchführen, sind 20% produktiver.
  • Verwenden Sie den TDD-Ansatz. Es reduziert die Anzahl der Fehler um 30-40 Prozent.
  • CI/CD. , , . , . CI/CD .
  • Erhöhen Sie die Testabdeckung . Ihr CI / CD-Prozess sollte Tests ausführen und anhalten, wenn mindestens einer von ihnen abstürzt. Dies hilft, die Bereitstellung von Fehlern in der Produktion zu vermeiden und Ihnen viel Geld und Zeit zu sparen. Ihr Ziel ist eine Abdeckung von mindestens 70%, aber versuchen Sie, nahe bei 80% zu bleiben. Wenn Sie sich 100% nähern, werden Sie feststellen, dass die Abdeckung wichtiger Benutzerprozesse mit Funktionstests zu mehr als einer weiteren Steigerung der Komponententests führt.

Fazit


Es gibt viele Möglichkeiten, die Teamleistung zu beeinflussen, darunter:

  • Setzen Sie realistische Erwartungen
  • Verfolgen und steuern Sie die Anzahl offener Aufgaben
  • Kontrollieren Sie die Aufgabengrößen
  • Lassen Sie nicht zu, dass Aufgaben durch Codeüberprüfung akkumuliert werden
  • Entwickler ausbilden
  • Sorgen Sie für ein ausgewogenes Verhältnis zwischen Arbeit und Freizeit
  • Implementieren Sie effektive Entwicklungsprozesse
  • Achten Sie auf die Mitarbeiterbindung

More articles:


All Articles