Wie man eine Software-Engineering-Kultur aufbaut, in der jeder gedeihen kann

Die Medien lieben es, Kriegsgeschichten über Sexismus, Rassismus und andere Formen von Vorurteilen in der Technologiewelt zu erzählen. Während systembedingte Probleme ein gutes journalistisches Phänomen sind, kann es für Menschen, die sich für technische Berufe interessieren, das Lesen von Geschichten über die kulturellen Probleme im technischen Bereich bestenfalls als vertrautes Gefühl einer stereotypen Bedrohung empfinden und im schlimmsten Fall als bedrohliche berufliche Verantwortung. Die gute Nachricht ist jedoch, dass die Kultur der Technologiebranche von Natur aus nicht schlecht ist - einige davon sind großartig, und es ist sowohl möglich als auch unkompliziert, eine Software-Engineering-Kultur zu schaffen, in der jeder gedeihen kann.

Schlechte Software-Engineering-Kultur ist ineffizient - zusätzlich zu der Verdrängung von 75% der Menschen, die das Techbro-Stereotyp nicht erfüllen konnten, wodurch die Branche künstlich weniger wettbewerbsfähig wird - schlechte Software-Engineering-Kultur ist häufig auch eine Kultur, in der nur wenige Ingenieure dominieren sind tatsächlich produktiv, während sich der Rest verwirrt oder minimiert fühlt, und eine Kultur, in der riesige Teams Jahre und Millionen von Dollar aus Versehen dafür aufwenden können, die falschen Probleme zu lösen oder die falschen Produkte zu bauen. Das sichtbarere Problem eines feindlichen Arbeitsplatzes ist einfach zu messen, was für komorbide Probleme der schlechten Organisationskultur und der organisatorischen Ineffizienz spricht.

Glücklicherweise ist die Arbeitskultur sehr formbar, und Sie können sie auf große und kleine Weise beeinflussen. Wenn Sie an Ihrem Arbeitsplatz Möglichkeiten zur Verbesserung der Softwareentwicklungskultur finden, verbessern Sie wahrscheinlich nicht nur die Umgebung für sich selbst, sondern für alle. Alle sind nicht nur glücklicher, sondern auch produktiver.

Tech at MoveOn ermöglicht das Organisieren in großem Maßstab. Die Arbeit, die wir leisten, ist wichtig, und wie wir diese Arbeit leisten, ist ebenso wichtig. Mein Tech-Team baut nicht nur Tools auf, mit denen Millionen von Amerikanern mobilisiert, die Macht der Menschen gestärkt und unsere Regierung zur Rechenschaft gezogen werden können. Wir arbeiten auch mit einem Team zusammen, das über gerechte Einstellungsprozesse eingestellt wird, und wir prüfen und verbessern ständig unser Software-Engineering Praktiken und Prozesse, um sicherzustellen, dass jeder im Team eine Stimme hat und alle auf Erfolg eingestellt sind. Dies ist eine schwierige Arbeit, die sich absolut lohnt. Wenn wir unsere Teamprozesse richtig gestalten, profitieren wir davon, dass wir die richtige Technologie zur richtigen Zeit effizient und flink aufbauen, unsere Systeme und Prozesse skalieren und mit den anderen zusammenarbeiten die Organisation als technischer Denkpartner. Wir lehnen die Idee ab, dass die aktuellen technischen Stereotypen und kulturellen Erwartungen unvermeidlich sind, und sind daher ein besseres Team.

Wie können Sie eine gute Software-Engineering-Kultur aufbauen?

Business Cat ist kein guter Software Engineering Manager

Hauptzutaten einer guten Kultur

Eine gerechte und effiziente Software-Teamkultur berücksichtigt die Zusammensetzung Ihres Teams, operationalisiert Prozesse und macht Normen explizit, setzt alle Teammitglieder für den Erfolg ein und hält das Team für seine erklärten Ziele verantwortlich.

Hier sind fünf Schlüsselwerte, um dies zu erreichen:

  1. Erkennen Sie die Vielfalt der Erfahrungen des Teams an
  2. Stellen Sie klar, Kommunikations- und Kollaborationsnormen
  3. Schaffen Sie sichere Räume zum Lernen und zum Stellen von Fragen
  4. Binden Sie alle Teammitglieder explizit in neue Projekte ein
  5. Schaffen Sie eine Kultur der Verantwortlichkeit

Jede Kombination von Prozessen, die diese Werte implementieren, wird wahrscheinlich für Ihr Team funktionieren, aber nicht alle Strategien sind für jedes Team und jedes Projekt und jeden organisatorischen Kontext geeignet. Daher ist es wichtig, sowohl verschiedene Strategien auszuprobieren als auch regelmäßig mit Ihrem Team über diese zu sprechen Was funktioniert und was nicht. Lassen Sie die Teammitglieder über Prozessänderungen verhandeln und bleiben Sie flexibel.

Als Nächstes werden wir aufschlüsseln, was jeder Wert wirklich bedeutet, und ich werde eine Auswahl von Strategien vorstellen, die ich verwendet habe, um jeden Wert umzusetzen.

Erkennen Sie die Vielfalt der Erfahrungen des Teams an

Die meisten Softwareentwicklungsumgebungen umfassen Personen mit unterschiedlichen Erfahrungsebenen, und die Erfahrung variiert in vielen Dimensionen: tatsächliche Zeit für die Programmierung, jahrelange Erfahrung in einer bestimmten Sprache oder einem bestimmten Framework, Erfahrung mit einer bestimmten Unternehmensgröße, einem bestimmten Typ und einer bestimmten Branche. Jede Sprache, jedes Framework, jede Plattform und jede Branche hat eine Reihe von Erwartungen hinsichtlich der Reihenfolge der Abläufe für ein Projekt, der einfachen und der schwierigen Probleme, der als Standard geltenden Architekturmuster und der geltenden Normen für Dokumentation, Debugging. und Bereitstellung. Jeder einzelne Unterschied ist hier von Bedeutung und sollte bei der Festlegung von Kommunikations- und Kollaborationsnormen berücksichtigt werden. Durch das Auspacken der Erfahrungen und Annahmen der einzelnen Teammitglieder wird die Entscheidungsfindung klarer und potenzielle Missverständnisse werden beseitigt.

https://xkcd.com/1831/

Strategien zur Anerkennung der Erfahrungsvielfalt Ihres Teams:

  • Team-Retreats: Wenn sich die Zusammensetzung Ihres Teams ändert, ist es hilfreich, ein oder zwei Tage vorzubereiten, damit sich alle treffen, Erfahrungen austauschen und Normen zurücksetzen können
  • Team-Konstitution: Stellen Sie eine Reihe von Werten und Normen zusammen, die Sie als Konstitution Ihres Teams ratifizieren. Es ist hilfreich, die Sprache direkt zu halten, die Liste kurz zu halten und sich auf Werte im Vergleich zu bestimmten Projekten zu konzentrieren. Fordern Sie jedes Teammitglied auf, basierend auf seiner Erfahrung Geschichten darüber zu teilen, warum jeder Wert wichtig ist.
  • Erleichterte Möglichkeiten zum Erfahrungsaustausch: Sie können dies als Teil eines Team-Retreats oder eines regelmäßigen Teambuilding-Meetings tun. Die Eingabeaufforderung ist weniger wichtig als die Erleichterung. Moderation ist der Schlüssel, damit jeder (sowohl Introvertierte als auch Extrovertierte, sowohl Junior- als auch Senior-Ingenieure) die Möglichkeit hat, zu sprechen und gehört zu werden. Einige Beispiele, bei denen ich festgestellt habe, dass sie generativ sind: „Was war der schwierigste Projektstart, an dem Sie jemals teilgenommen haben?“ „Was waren die besten und schlechtesten Managementerfahrungen, die Sie jemals gemacht haben?“ Der Moderator sollte sich an alle Mitarbeiter des Treffen und geben Sie ihnen jeweils die gleiche Anzahl von Minuten, um zu sprechen und Fragen über ihre Erfahrungen zu beantworten.
  • Entpacken Sie die Überlegungen zur Softwareschätzung: Ihr Team wird immer darüber diskutieren, wie lange eine Aufgabe dauern wird, und manchmal widersprechen. In diesem Fall ist es hilfreich, die Annahmen darüber, welche Teile der Aufgabe oder des Problems als komplex angesehen werden, warum und auf welchen Erfahrungen der Vergangenheit dies basiert, explizit zu entpacken.
  • Lernpläne für das Software-Engineering: Erstellen Sie einen Lernplan für Software-Ingenieure, die ihre Fähigkeiten im Software-Engineering auf unterstützte und strukturierte Weise erweitern möchten.

Stellen Sie klar, Kommunikations- und Kollaborationsnormen

Schreiben Sie auf und stimmen Sie formell zu, wie Teammitglieder an einem Projekt zusammenarbeiten, wie Aufgaben verwaltet werden und wie die abgeschlossene Arbeit genehmigt und übernommen wird. Wenn Sie diese Normen nicht explizit angeben, werden in Ihrem Team und in Ihrem Projekt ohnehin Normen entwickelt. Diese impliziten Normen können jedoch für einige Ingenieure und nicht für andere gelten, und die Normen sind möglicherweise klarer und für diejenigen zugänglich, die sich als die dominierende Kultur Ihres Unternehmens auszeichnen und verwirrender für diejenigen, die dies nicht tun. Es ist besser, nur explizit zu sein.

Strategien zur Festlegung von Kommunikations- und Kollaborationsnormen:

  • Projekt-Kickoff-Meetings: Team Constitutions unterstützen Teams bei der Entscheidung, wie sie im Allgemeinen zusammenarbeiten. Es ist jedoch auch hilfreich, Projekt-Kickoff-Meetings abzuhalten, bei denen Teams über die Zusammenarbeit bei diesem bestimmten Projekt entscheiden. Dies sollte abdecken, wie Aufgaben verwaltet werden, wie Aufgaben angeordnet werden, wer welche Arten von Aufgaben aufnimmt, wie und wann um Hilfe gebeten werden muss, wann zusammengearbeitet werden muss, wie Änderungen und abgeschlossene Arbeiten genehmigt und übernommen werden sollten.
  • Tägliche Stand-up-Meetings: Dies ist eine Grundvoraussetzung für die meisten Agile-Software-Management-Strategien. Fordern Sie jedes Teammitglied auf, zu berichten, was es gestern getan hat, was es heute tun wird und ob es Hilfe bei irgendetwas benötigt. Halten Sie die Besprechung nach Möglichkeit unter 15 Minuten. Es ist wichtig, dies persönlich oder in einem Videotreffen (gegen Telefon) zu tun, damit die Teammitglieder visuelles Feedback und die damit verbundene soziale Dynamik wahrnehmen können, die Teil der Teammitglieder sind, die sich gegenseitig für die Teamziele verantwortlich machen. Ich fand es von unschätzbarem Wert, ein Tagesordnungsdokument für Daily Standup zu haben, in dem alle Benutzer ihre Aktualisierungen in umgekehrter chronologischer Reihenfolge vor dieser täglichen Besprechung schreiben. In diesem Dokument werden alle Aktualisierungen im Laufe der Zeit erfasst. Dies hilft Introvertierten, ihre Gedanken vor dem eigentlichen Meeting zu sammeln, und erstellt eine übersichtliche Zusammenfassung der geleisteten Arbeit, die sich als nützlich erweist, wenn Sie sich auf Evaluierungen vorbereiten oder ein Teammitglied einholen, das ein Meeting verpasst hat.
  • Regelmäßige Gelegenheit zum Einchecken in den Prozess: Manchmal bleiben Ingenieure zurück oder sind frustriert mit anderen Ingenieuren oder einem Prozess oder der Art und Weise, wie ein Projekt ausgeführt wird. Es ist besser, diese Frustrationen mit einer klaren Kommunikation, die das gesamte Team einbezieht, direkt zu vermeiden und die Möglichkeit zu schaffen, dieses Feedback bei geringem Stress weiterzugeben. Manchmal fand ich es hilfreich, "Prozessprüfung" in die Liste der Elemente aufzunehmen, über die jedes Teammitglied in den täglichen Standup-Besprechungen berichtet. In anderen Fällen habe ich es als hilfreich empfunden, diesen Schritt "Prozessprüfung" alle paar Wochen in Sprint-Planungsmeetings durchzuführen. Wann immer der "Prozesscheck" stattfindet, ist es hilfreich, nicht nur darüber zu sprechen, sondern auch die vorgeschlagenen Prozessänderungen aufzuschreiben, damit eine gemeinsame Vereinbarung besteht, auf die bei künftiger Verwirrung verwiesen werden kann.
  • POPs für Besprechungen, die länger als 15 Minuten dauern: Es ist einfach, in die Falle von Death By Meetings zu tappen, wenn große Entscheidungen als Team oder eine chaotische Situation getroffen werden müssen. Eine Möglichkeit, übermäßige Besprechungen zu vermeiden, besteht darin, jedem die Möglichkeit zu geben, eine Teambesprechung vorzuschlagen. Stellen Sie jedoch sicher, dass für die Besprechung eine POP (Zweck, Ergebnis, Ablauf) mit einer Agenda festgelegt wurde, die mindestens einen Tag vor der vorgeschlagenen Besprechung festgelegt wurde. Dies hilft, die Besprechung fokussiert und umsetzbar zu halten, und das frühzeitige Teilen der Tagesordnung ermöglicht interessierten Personen, sich auf die Teilnahme vorzubereiten, und Personen, die sich nicht abmelden sollen.

Schaffen Sie sichere Räume zum Lernen und zum Stellen von Fragen.

Jeder lernt, indem er Fehler macht und sie tausendmal falsch macht, bevor er sie richtig macht. Sie können dies als „Basteln“ bezeichnen. Das Schöne an der Codierung ist, dass Sie Dinge falsch machen und schließlich mit der Geschwindigkeit, die Sie sich vorstellen können, richtig liegen können, und zwar mit geringen oder keinen physischen Kosten. Wenn Sie jedoch einen neuen Problemraum erkunden, durchsuchen verschiedene Personen (basierend auf Erfahrung und persönlichen Vorlieben) möglicherweise den Baum möglicher Lösungen breiter oder tiefer und haben möglicherweise mentale Modelle entwickelt, die es ihnen ermöglichen, einen kompakteren Suchraum als zu haben andere für bestimmte Problembereiche. Ingenieure beginnen, sich schlauer und schneller zu machen, wenn sie ihre Problemlösungsprozesse und -schritte austauschen möchten. Dies beinhaltet natürlich eine ganze Menge Dummheit und das Stellen von „dummen Fragen“ (von denen keine wirklich dumm sind). Um dies überhaupt tun zu können, ist ein erhebliches Maß an Vertrauen erforderlich. Es kann schwierig sein, Vertrauen in Jobs mit hohem Einsatz zu finden, in denen Ego oder Ansehen auf dem Spiel stehen und jeder versucht, einer Art „genialem Ingenieur“ -Archetyp gerecht zu werden. Manager sollten explizit sichere Räume schaffen, indem sie erklären, dass es keine dummen Fragen gibt. Modellieren Sie dies, indem Sie die „dummen“ Fragen stellen, strukturierten Raum für die Zusammenarbeit schaffen und diejenigen belohnen, die proaktiv zusammenarbeiten. Wenn Sie dies nicht explizit tun, werden wahrscheinlich einige Ingenieure in Ihrem Team diese sicheren Bereiche erstellen, aber nicht alle werden automatisch einbezogen.

https://xkcd.com/722/

Strategien zur Schaffung sicherer Räume

  • Regelmäßige 1–1: Manager sollten regelmäßige 1–1 mit Mitarbeitern haben, vorzugsweise eine halbe Stunde einmal pro Woche. Die Manager sollten die Mitarbeiter ermutigen, die Tagesordnung für diese Besprechungen voranzutreiben. Es ist hilfreich, ein gemeinsames 1–1-Agendadokument für diese Besprechung zu führen, in dem die Mitarbeiter vorab Elemente hinzufügen können, wenn Probleme auftreten. Dieses Agendadokument dient auch als hilfreicher Wegweiser, wenn Sie Auswertungen schreiben oder über frühere Herausforderungen und Chancen nachdenken.
  • Regelmäßiges 2x2-Feedback: Der Manager und der Mitarbeiter schreiben jeweils zwei Dinge auf, die der Mitarbeiter gut macht, zwei Dinge, die der Mitarbeiter besser machen könnte, zwei Dinge, die der Manager gut macht, und zwei Dinge, die besser sein könnten. Dies kann ein hilfreicher Check-in-Punkt für die Mitarbeiterleistung sein und auch ein sicherer Ort, an dem die Mitarbeiter ihren Managern Feedback geben können. Unabhängig davon, wie freundlich oder aufgeschlossen Sie als Manager sind, zögern die meisten Mitarbeiter, Ihnen negative Rückmeldungen zu geben, es sei denn, Sie laden sie dazu ein.
  • Auspacken von Jargon: Normalisieren Sie das Markieren von Jargon, wenn ein Ingenieur einen unbekannten Begriff oder ein Akronym ausstößt, das nicht vom Rest des Teams verwendet wird, und fordern Sie ihn auf, zu erklären, was der Begriff für das gesamte Team bedeutet.
  • Geplante Paarprogrammierung: Die Paarprogrammierung ist ein großer Produktivitätsschub und eine hervorragende Möglichkeit für Ingenieure, voneinander zu lernen. Anstatt darauf zu warten, dass die Paarbildung zwischen Ingenieuren, die bereits mit einander vertraut sind, organisch abläuft, fordern Sie die Teammitglieder auf, dies explizit in ihren Kalendern zu planen, und stellen Sie sicher, dass alle Ingenieure Zugriff auf die gewünschte Pairing-Zeit haben. Fordern Sie die Ingenieure außerdem auf, die richtige Einheit für die Fokuszeit (für einige 60 Minuten, andere 90 Minuten, andere 120 Minuten) und die produktivste Tageszeit für das Pairing festzulegen.
  • Explizite Mentoring-Möglichkeiten: Geben Sie jedem Nachwuchsingenieur im Team die Möglichkeit, einen Senior Engineer-Mentor zu beauftragen, und beziehen Sie effektives Mentoring ausdrücklich in die Leistungsziele des Senior Engineers ein. Ermutigen Sie die Mentoren, wöchentliche Treffen mit ihren Mentees zu organisieren und sichere Räume zu schaffen, in denen sie „dumme“ Fragen stellen oder Prozesse oder Normen mit einem älteren Verbündeten klären können.
  • Übe regelmäßige Wiederholungen: Wenn ein Ingenieur anderen ein neues Framework beibringt, alle durch eine vorgeschlagene Architektur führt oder Mitglieder des Teams in ein neues System einbindet, ist es manchmal für die Zuhörer einfach, herunterzufahren oder abgelenkt zu werden. Um die Diskussion aktiv zu halten, fordern Sie die Zuhörer regelmäßig nach jeweils 5 Minuten auf, das gerade Erläuterte mündlich zu wiederholen. Die performative Natur des verbalen Repeatbacks zwingt den Hörer, sich selbst zu beweisen, dass er das Konzept versteht, ODER zu artikulieren, welche zusätzlichen Informationen er verstehen muss. Normalisieren Sie dies, wenn Sie Meetings zum Projektstart einplanen oder durchführen, und rufen Sie die Leute nach dem Zufallsprinzip auf, die Wiederholungen durchzuführen, um alle daran zu hindern, aufmerksam zu bleiben.
  • Ermutigen Sie und modellieren Sie das Stellen von „dummen“ Fragen: Als Manager beobachten die Leute Ihr Verhalten und Ihren Ton genau und modellieren ihr Verhalten und ihre sozialen Normen dagegen. Daher ist es wichtig, die oben genannten Werte für die Interaktion mit dem Rest Ihres Teams zu modellieren und insbesondere die Fähigkeit zu modellieren, direkte Fragen zu stellen, wenn Sie etwas nicht vollständig verstehen. Dies zeigt, dass eine effiziente Problemlösung immer wichtiger ist als das Ego oder die Wahrnehmung, immer richtig zu sein.

Binden Sie alle Teammitglieder explizit in neue Projekte ein.

Wenn Sie ein neues Projekt starten, ist es wichtig, nicht nur zu entpacken, welche Arbeiten ausgeführt werden, sondern auch, warum diese Arbeiten wichtig sind und wem diese Arbeiten wichtig sind. Stellen Sie sicher, dass Ingenieurteams sowohl das Warum als auch das Was verstehen, um Entscheidungen zu treffen, wenn unerwartete Entscheidungspunkte auftauchen, und minimieren Sie das Risiko, Zeit für die Lösung falscher Probleme aufzuwenden. Und nachdem Sie ein neues Projekt gestartet haben, ist es wichtig sicherzustellen, dass jeder das hat, was er braucht, um eine Aufgabe zu übernehmen und bei dieser Aufgabe sofort produktiv zu werden. Wenn Sie dies nicht explizit tun, werden einige Ingenieure in Ihrem Team sofort einsatzbereit sein, und andere haben Probleme mit Bootstrapping-Schritten wie der Einrichtung lokaler Entwicklungsumgebungen. Wenn Sie diese Schritte als Voraussetzung für den Start eines Projekts festlegen, ist sichergestellt, dass alle Beteiligten in der Lage sind, die ersten Schritte zu unternehmen.

Strategien für explizites Onboarding

  • Entwicklungsumgebungen: Stellen Sie sicher, dass jeder im Team über eine funktionierende Entwicklungsumgebung verfügt, bevor Sie ein Projekt zum Start aufrufen. Junge und alte Ingenieure bemühen sich von Zeit zu Zeit, lokale Entwicklungsumgebungen zum Laufen zu bringen. Dies führt zu versteckten Kosten in der Zeitplanung für Softwareprojekte. In diesem Fall sind die Ingenieure verlegen und geben häufig nicht zu, dass sie Hilfe benötigen, indem sie in einer Rolle bleiben, die für die Codierung unerlässlich ist, oder nur mit Ingenieuren zusammen programmieren, die über funktionierende Entwicklungsumgebungen verfügen. Es ist am besten, nur den potenziellen Kampf und die Schande zu beseitigen und diese Arbeit als die Arbeit zu bezeichnen, die sie ist, und dann das Frontloading dieser Arbeit zu planen, indem die Einrichtung der Entwicklungsumgebung explizit und unterstützt wird - etwas, das jeder gemeinsam tut und das nicht als "gekennzeichnet ist". erledigt “, bis alle am Projekt Beteiligten ein funktionierendes lokales Umfeld haben.
  • Führung durch die Codebasis: Wenn ein Projekt gestartet oder neu gestartet wird, sollte der Ingenieur, der die Codebasis am besten kennt, eine Führung durch die Codebasis geben und bei den weniger vertrauten Teammitgliedern eine Pause einlegen, um regelmäßige „Wiederholungen“ durchzuführen dafür verantwortlich, die Codebasisstruktur gut genug zu lernen, um sie zurück zu erklären.
  • Debugger: Sobald jeder über eine Entwicklungsumgebung und ein konzeptionelles Verständnis der Funktionsweise des Systems verfügt, sollte jeder einen Debugger installieren und die Ausführung für eine Beispielanforderung oder -eingabe über das System verfolgen können. Durch die Möglichkeit, lokal zu arbeiten und Fehler zu beheben, wird sichergestellt, dass Ingenieure, wenn sie Aufgaben übernehmen, diese zumindest selbstständig ausführen können. Dies verringert die Frustration und erhöht Produktivität und Eigenverantwortung.

Schaffen Sie eine Kultur der Verantwortlichkeit

Die entscheidende Aufgabe des Software-Engineering-Managements besteht darin, sicherzustellen, dass Ihr Team die richtige Arbeit zur richtigen Zeit in der richtigen Reihenfolge ausführt, und ein wichtiger Teil der Konzentration auf die richtige Arbeit besteht darin, die Stakeholder auf die richtige Weise zu erreichen. Software-Teams haben mehrere Interessengruppen: einander, die größere Organisation und die Benutzer der von ihnen erstellten Software. Prozesse zur Verwaltung von Softwareteams sollten Verantwortlichkeit gegenüber all diesen Stakeholdern schaffen.

Strategien zur Schaffung einer Kultur der Rechenschaftspflicht

  • Projektbesprechungen: Nachdem ein Projekt abgeschlossen und gestartet wurde, ist es wichtig, Platz für eine Besprechung zu schaffen und diese zu ermöglichen, damit alle im Team ihre Rückmeldungen austauschen können. Eine hilfreiche Eingabeaufforderung, die ich dafür verwende, ist „SaMoLo: Was würden Sie beim nächsten Mal genauso, mehr oder weniger tun?“. Ermutigen Sie die Teammitglieder, Feedback zu technischen und prozessbezogenen Bereichen auszutauschen. Auf diese Weise können sich die Teammitglieder gegenseitig zur Rechenschaft ziehen, ob die im Rahmen des Projektstarttreffens ausgehandelten Prozesse befolgt wurden.
  • Rechenschaftspflicht für Softwareprozesse: Codeüberprüfungs- und Freigabeprozesse, die in Project Kickoff Meetings festgelegt wurden, sorgen ebenso für Rechenschaftspflicht im Team wie die täglichen Standup-Meetings.
  • Regelmäßige Demo-Meetings: Regelmäßige Demos des Projektfortschritts schaffen Verantwortlichkeit gegenüber der größeren Organisation. Wir halten gerne Platz für wöchentliche Demos für alle interessierten Mitarbeiter. Dies ist eine Motivation für das Team, da sie ihre Arbeit vorführen können, ein Forum für die Erfassung von frühzeitigem Stakeholder-Feedback geschaffen wird und die Projektarbeit sich nach Möglichkeit auf iterative, demo-fähige Ergebnisse konzentriert.
  • Benutzerorientierte Metriken: Erstellen Sie Verantwortlichkeiten für Benutzer Ihrer Software, indem Sie Benutzertests durchführen und Erfolgsmetriken basierend auf der Benutzereingabe definieren und verfolgen.

Warum ist das wichtig?

Trotz massiver Gewinne ist die Welt des Software Engineerings derzeit ziemlich ineffizient. 90% der Software-Starts schlagen fehl, und ich glaube, dass dies zu einem großen Teil auf vermeidbare Probleme bei der Ausführung von Softwareprojekten zurückzuführen ist. 50% der Softwareprojekte großer Unternehmen werden nicht rechtzeitig, im Rahmen des Budgets oder überhaupt nicht gestartet. Ein Jahr zu spät oder eine Million Dollar über dem Budget zu sein, ist für niemanden neu, der jemals bei einem großen Softwareunternehmen gearbeitet hat. Die Softwareentwicklungskultur bezeichnet Manager häufig als Gemeinkosten oder weniger wichtig als Softwareentwickler. Dies führt dazu, dass Softwareentwickler als effektive Manager diesen Aufstiegspfad vermeiden können und aktuelle Softwareentwickler Schwierigkeiten haben, mit ihren eigenen Teams zu verhandeln und zu regieren. In Umgebungen, in denen Cowboy-Programmierer bewundert werden, kann es manchmal sogar zu Stigmatisierungen kommen, wenn man sich offen um den Softwareentwicklungsprozess kümmert.

Es ist demoralisierend, an einem großen Softwareprojekt zu arbeiten, nur um zu sehen, dass die Frist immer weiter verschoben oder das Projekt abgebrochen wird. In der gewinnorientierten Welt ist dies eine ineffiziente Verschwendung von Zeit und Geld. In der gemeinnützigen Welt ist es meiner Meinung nach eine unethische Verwendung von Mitgliedsspenden. Für Softwareentwickler ist dies eine Verschwendung unserer wertvollen Zeit, Energie und Aufmerksamkeit.

Aus intellektuellen und finanziellen Gründen ist es wichtig, die Kultur Ihrer Arbeitsumgebung zu überprüfen und nach Möglichkeiten zu suchen, diese zu optimieren und zu verbessern. Wenn Sie damit beginnen, Ihre Arbeitskultur gerechter, rechenschaftspflichtiger und fairer zu gestalten und einen Ort zu schaffen, an dem jeder Erfolg haben kann, werden Sie nicht nur Softwareentwickler glücklicher und Softwareentwicklung effizienter machen, sondern auch die Welt fairer Senkung der Kosten für die Softwareentwicklung und Beseitigung diskriminierender Hindernisse.

Es ist nicht schwer, eine Software-Engineering-Kultur aufzubauen, in der sich jeder entfalten kann. In einer Tech-Kultur, die von Hybris, Gier, Ego und ethischen Problemen überflutet ist, ist dies jedoch eine radikale Idee. Ich betrachte den absichtlichen Aufbau einer effektiven und unterstützenden Teamkultur als einen Akt des Aktivismus. Machen wir eine faire und effektive Software-Teamkultur zur Norm!