paint-brush
Abbau organisatorischer Barrieren zur Beschleunigung der Softwareentwicklungvon@hacker9096769
309 Lesungen
309 Lesungen

Abbau organisatorischer Barrieren zur Beschleunigung der Softwareentwicklung

von Illia Halashko9m2024/07/13
Read on Terminal Reader

Zu lang; Lesen

Verzögerungen bei der Bereitstellung von Funktionen in Technologieunternehmen sind häufig auf organisatorische Probleme und nicht auf rein technische zurückzuführen. Wenn Sie die Unternehmensstruktur, die Mitarbeiterhierarchie, die Teamverantwortlichkeiten und den Bereitstellungsprozess von Funktionen verstehen, können Sie die Grundursachen identifizieren und schrittweise Änderungen zur Verbesserung implementieren.
featured image - Abbau organisatorischer Barrieren zur Beschleunigung der Softwareentwicklung
Illia Halashko HackerNoon profile picture
0-item


Zu verstehen, warum bestimmte Funktionen nicht bereitgestellt werden, kann oft schwierig sein. Das Management könnte die Schuld den technischen Teams zuschieben, während diese mit dem Finger auf das Management zeigen. Unterdessen ist die Geschäftsseite in der Zwickmühle: Sie versucht, die Grundursache zu ermitteln und gleichzeitig ungeachtet der Umstände Ergebnisse zu erzielen. Dieses Szenario tritt typischerweise nach erheblichem Unternehmenswachstum auf oder wenn frühere Probleme, die zuvor leicht zu beheben waren, im Laufe der Zeit vernachlässigt wurden. Es ist ein weit verbreiteter Irrtum, dass alle Probleme in einem Technologieunternehmen rein technischer Natur sind; das ist weit von der Wahrheit entfernt.

In diesem Artikel werde ich Bereiche innerhalb der Organisation eines Unternehmens skizzieren, die die Bereitstellung von Funktionen erheblich behindern können. Ich werde auch Untersuchungsanweisungen vorschlagen, um die Grundursachen zu ermitteln, die dann innerhalb Ihrer Autoritätsebene eskaliert oder gelöst werden können.

Es ist entscheidend, unsere Arbeitsumgebung zu verstehen, bevor wir Änderungen oder Verbesserungen umsetzen. Obwohl viele aufschlussreiche Bücher zu diesem Thema geschrieben wurden, sind nicht alle Ansätze für jedes Unternehmen geeignet. Dies bedeutet nicht, dass wir etwas falsch gemacht haben, sondern vielmehr, dass wir die Einzigartigkeit jedes Unternehmens anerkennen.

Ein wichtiger Hinweis ist, dass sich die hier geteilten Erkenntnisse in erster Linie auf die Softwareentwicklung beziehen und am ehesten auf Unternehmen oder Abteilungen mit 50 oder mehr Mitarbeitern anwendbar sind.

Organisatorische Struktur

Machen Sie sich zunächst einmal mit der Größe und Struktur Ihres Unternehmens vertraut. Identifizieren Sie die verschiedenen Abteilungen und klären Sie Ihre Erwartungen an jede einzelne. Beurteilen Sie, ob alle diese Abteilungen notwendig sind. Erstellen Sie ein Diagramm der Organisationsstruktur, in dem jede Abteilung und ihre Rollen detailliert beschrieben werden. Stellen Sie sicher, dass Sie verstehen, was sie tun und warum sie existieren. Oft besteht jede Abteilung aus mehreren Teams – nehmen Sie diese ebenfalls in Ihr Diagramm auf, beschreiben Sie sie jedoch vorerst nicht, sondern nennen Sie lediglich Teamnamen.

Wenn Unternehmen wachsen, können Organisationsstrukturen komplex werden, was es schwierig macht, den Fortschritt zu verfolgen. In dieser Komplexität verlieren Sie möglicherweise die ursprünglichen Gründe für die Schaffung bestimmter Abteilungen oder Teams aus den Augen. Einige Teams wurden möglicherweise eingerichtet, um Probleme anzugehen, die nicht mehr relevant sind. So kann es auf hoher Ebene aussehen.



Was kommt als nächstes, nachdem Sie ein klares Diagramm Ihrer Organisationsstruktur haben?

Mitarbeiterhierarchie

Als nächstes ist es wichtig, die Hierarchie Ihrer Mitarbeiter abzubilden. Es ist entscheidend zu verstehen, wer wem unterstellt ist und warum. Linienmanager müssen effektiv mit ihren Untergebenen kommunizieren, unabhängig davon, ob sie eine große Geschäftseinheit oder ein kleines Team leiten. Die Kommunikation sollte klar sein, entweder in technischer oder geschäftlicher Sprache, da der Umgang mit beiden eine Herausforderung sein kann. In größeren Unternehmen gibt es möglicherweise direkte und funktionale Manager mit unterschiedlichen Verantwortungsbereichen, die in Ihrem Hierarchiediagramm klar dargestellt werden sollten.

Eine Mitarbeiterhierarchie verdeutlicht nicht nur die Berichtslinien, sondern hilft auch dabei, vertikale Hierarchien innerhalb der Organisation zu identifizieren. Vertikale Hierarchien sind hierarchische Strukturen, die als gemeinsame Ressourcen für mehrere Abteilungen dienen, wie Designer, HR, DevOps und sogar Entwickler. Obwohl vertikale Hierarchien sehr nützlich sein können, können sie manchmal zu Engpässen werden, insbesondere wenn Entwickler an verschiedenen Projekten arbeiten und Managern unterstellt sind, die mit den Geschäftszielen oder technischen Herausforderungen nicht vertraut sind. Infolgedessen erhalten Entwickler kein angemessenes Feedback und Manager keinen angemessenen Kontext. Daher ist das Verständnis der Hierarchie entscheidend, um potenzielle Probleme oder Priorisierungen der Aufgaben zu identifizieren und zu analysieren. Am Ende haben Sie so etwas.



Anmerkung

CEO — Vorstandsvorsitzender
CPO – Produktleiter
CTO – Technischer Leiter
COO – leitender Betriebsleiter
HD – Leiter Design
PO – Produktbesitzer
HE — Leiter Technik
HS — Leiter Vertrieb
HM — Leiter Marketing
D — Entwickler
PM — Produktmanager
TL – Technischer Leiter
EM – Technischer Leiter
S — Vertriebsleiter
M – Vermarkter


Vergleichen Sie Ihre Organisationsstruktur mit Ihren Berichtslinien, um Einblicke in die Beteiligung jedes Mitarbeiters an verschiedenen Aktivitäten zu erhalten. Darüber hinaus kann die Ausrichtung Ihrer Organisationsstruktur an der Mitarbeiterhierarchie dabei helfen, festzustellen, ob einzelne Mitarbeiter in denselben Abteilungen und Teams und auf ein gemeinsames Ziel hinarbeiten. Die Vorlage für die Zuordnung liegt ganz bei Ihnen, könnte aber so aussehen.


Abbildung der Mitarbeiterhierarchie in einer Abteilung

Verantwortlichkeiten des Teams

Es ist wichtig, den Bereich, in dem jedes Team arbeitet, klar zu definieren. Wenn ein Team mit Code arbeitet, geben Sie an, welche Dienste es nutzt und welche ihm gehören. Überraschenderweise können diese oft unterschiedlich sein. Stellen Sie fest, ob das Team ausschließlich innerhalb einer Abteilung arbeitet oder ob es sich um ein Plattformteam handelt, das an Kernfunktionen arbeitet, die von anderen Teams genutzt werden, ohne diese direkt zu ändern.

Das Erstellen einer Tabelle mit den folgenden Spalten kann sehr hilfreich sein: Teamname, Abteilung, Liste der eigenen Dienste, Liste der allgemeinen Dienste, die das Team ändern kann, aber nicht besitzt (idealerweise sollte es keine solchen Dienste geben) und eine kurze Beschreibung. Mithilfe dieser Tabelle können Sie feststellen, ob mehrere Teams an derselben Codebasis arbeiten, was zu Konflikten führt, oder ob ihre Verantwortungsbereiche nicht klar sind. Sie kann auch aufzeigen, ob ein Team hauptsächlich Fehler behebt oder sich ohne klaren Fokus mit verschiedenen Aufgaben beschäftigt.

Dieser Detaillierungsgrad ist von entscheidender Bedeutung, um Überschneidungen, Konflikte und Lücken in den Teamverantwortlichkeiten zu erkennen und so eine reibungslosere Zusammenarbeit und eine effizientere Projektausführung sicherzustellen.

Pflichten des Mitarbeiters

Neben der Beschreibung der Teams ist es wichtig, die Positionen der Mitarbeiter im Allgemeinen zu verstehen und eine detaillierte Beschreibung ihrer Verantwortlichkeiten vorzubereiten. Oftmals kann sich das, was sich das Management vorstellt, erheblich von dem unterscheiden, was die Mitarbeiter tatsächlich tun. Die Softwareentwicklungsbranche bietet eine Vielzahl von Positionen, und die Erwartungen können von Unternehmen zu Unternehmen sehr unterschiedlich sein. Beispielsweise kann die Rolle eines Engineering Managers sehr unterschiedlich sein, ganz zu schweigen von Rollen wie Delivery Manager, Data Scientist, Architect, Technical Lead usw. In manchen Unternehmen wird von einer einzelnen Person möglicherweise erwartet, dass sie mehrere Rollen erfüllt.

Es ist wichtig, für jede Position klare Erwartungen festzulegen. Diese Klarheit hilft nicht nur dabei, Aktivitäten richtig zu verfolgen, sondern stellt auch sicher, dass die Mitarbeiter verstehen, was von ihnen erwartet wird und was außerhalb ihres Aufgabenbereichs liegt. Dies gilt für alle Positionen innerhalb der Organisation. Klare Rollendefinitionen helfen dabei, Überschneidungen zu vermeiden, Verwirrung zu reduzieren und sicherzustellen, dass alle effizient und organisiert auf gemeinsame Ziele hinarbeiten.

Funktionsbereitstellungsprozess

Inzwischen sollten Sie ein klares Verständnis Ihrer Unternehmensstruktur, der Hierarchie der Mitarbeiter und ihrer Verantwortlichkeiten haben. Auch wenn die Dinge verwirrend erscheinen mögen, besteht das Ziel darin, zunächst den aktuellen Stand zu verstehen, bevor Sie Änderungen vornehmen. Jetzt ist es an der Zeit, Ihren Feature-Delivery-Prozess zu beschreiben – wie Geschäftsfunktionen von der ersten Idee zur Produktion gelangen.

Bitte konzentrieren Sie sich hier nicht auf die technischen Aspekte wie CI/CD, sondern auf den Fluss vom Geschäft zu den Entwicklern, vorausgesetzt, Entwickler schreiben Code und stellen ihn direkt in der Produktion bereit. Das Ziel besteht darin, alle Probleme in Ihrem Prozess vom Geschäft zum Team zu identifizieren und zu sehen, wie gut die Mitarbeiter damit umgehen.

Berücksichtigen Sie diese Aspekte:

  • Wie oft planen Sie neue Funktionen und weisen den einzelnen Abteilungen und Teams Arbeit zu?
  • Wie legen Sie Leistungskennzahlen fest und messen sie?
  • Verwenden Sie Meilensteine? Wer ist an deren initialer Ausarbeitung beteiligt? Wie planen Sie diese mit dem Team?
  • Wer koordiniert den Planungs- und Durchführungsprozess?
  • Sind Sie wirklich ein agiles Unternehmen? Verwenden Sie Frameworks wie SAFe, Prince2 oder PMP oder haben Sie etwas Individuelles, das für Sie funktioniert?
  • Wie bewältigen Sie komplexe teamübergreifende Aufgaben und kontrollieren den Fortschritt? Gehen Sie strukturiert vor oder verlassen Sie sich darauf, dass sich die Dinge schon irgendwie lösen?

Denken Sie daran, dass jede Management- und Berichtsebene unabhängig von der Richtung Komplexität und Unsicherheit mit sich bringt. Letztendlich sollte Ihr Prozessdiagramm eine einfache Frage beantworten: „Wie?“

Sie können mit den Vorlagen experimentieren und sie Ihren Bedürfnissen anpassen. Hier ist ein sehr ausführliches Beispiel für einen Lieferprozess ohne Schlüsselpersonen, die die Lieferung regeln, aber mit Zeitrahmen.



Wenn Sie nicht sicher sind, wie Sie dieses Diagramm erstellen sollen, verwenden Sie BPMN (Business Process Model and Notation) oder ein einfacheres Format wie Rechtecke und Linien, um Klarheit und Verständnis für alle Beteiligten zu gewährleisten. Der Schlüssel liegt darin, den Prozess klar und verständlich zu gestalten.

Feedback einholen

Sobald Sie die Unternehmensstruktur, die Mitarbeiterhierarchie, die Teams und Positionsverantwortlichkeiten sowie den Lieferprozess abgebildet haben, teilen Sie alle Ihre Ergebnisse der Organisation mit und führen Sie eine Umfrage durch, vorzugsweise anonym. Diese Grundlage zeigt, wie Ihr Unternehmen funktioniert. Auch wenn Sie diese Übersicht möglicherweise selbst erstellt oder einige Aufgaben delegiert haben, ist es wahrscheinlich, dass Entwickler, Designer und Analysten nicht direkt beteiligt waren. Ihr Feedback ist entscheidend, um die Genauigkeit Ihrer Ergebnisse zu beurteilen.

Bitten Sie Ihre Mitarbeiter, die Qualität Ihrer Dokumentation zu bewerten. Was denken sie über den Lieferprozess? Spiegelt er wirklich wider, wie die Dinge erledigt werden? Wo sehen sie Hindernisse?

Erwarten Sie eine Vielzahl von Beschwerden und Feedback, die Ihnen helfen werden, Ihre Ergebnisse zu verfeinern, damit sie besser mit der Realität der Geschäftstätigkeit des Unternehmens übereinstimmen. Dieses Feedback ist wichtig, da der Kontext auf mehreren Hierarchieebenen oft verloren geht. Durch das Sammeln von Input von allen Ebenen erhalten Sie ein klareres und genaueres Bild der Organisation.

Ergebnisse schätzen

Nachdem Sie nun eine umfassende Beschreibung der Arbeitsweise Ihres Unternehmens oder Ihrer Abteilungen haben, können Sie mit der Analyse und Suche nach potenziellen Problemen beginnen. Diese Grundlage bietet einen klaren Ausgangspunkt für das Verständnis und die Lösung von Problemen.

Hier sind einige Bereiche, auf die Sie sich konzentrieren sollten:

  • Sind Ihre Abteilungen strukturiert? Sind die Berichtslinien klar?
  • Können Vorgesetzte überhaupt Feedback zu ihrem Aufgabenbereich geben?
  • Herrschen Verwirrung oder Unsicherheiten bei der Umwandlung geschäftlicher Anforderungen in technische Aufgaben?
  • Gibt es Abhängigkeiten von anderen Teams, die zu Verzögerungen während der Entwicklung führen?
  • Sind Mitarbeiter mit Tätigkeiten beschäftigt, die außerhalb ihres Hauptverantwortungsbereichs liegen und behindern sie dadurch die Erfüllung ihrer Hauptaufgaben?
  • Wie gut passt die Mitarbeiterhierarchie zur Teamstruktur?
  • Ist die Berichtshierarchie effektiv oder gibt es Lücken in der Kommunikation und im Kontext?
  • Arbeiten verschiedene Teams an denselben Diensten, was zu Konflikten und Zeitverschwendung bei der Entscheidung über die Aufgabenverantwortung führt?
  • Gibt es Teams oder Abteilungen ohne klar definierte Verantwortlichkeiten oder ohne fehlende Schlüsselspieler?
  • Sind manche Teams in keine Abteilung integriert?

Am Ende können Sie eine Liste mit echten Problemen Ihres Unternehmens erstellen, an denen Sie arbeiten werden. Priorisieren Sie sie von kritischen Problemen, die eine sofortige Interaktion erfordern, bis hin zu „nützlichen“ Verbesserungen.

So nehmen Sie Änderungen vor

Sie fragen sich vielleicht: „Das klingt ja alles großartig, aber wie kann ich die Dinge tatsächlich verbessern?“ Das ist eine gute Frage, und die ehrliche Antwort hängt von den spezifischen Problemen ab, die Sie identifizieren, und von Ihren Geschäftsanforderungen. Ein wichtiger Ratschlag ist jedoch, nicht zu versuchen, alles auf einmal zu ändern. Implementieren Sie stattdessen kleine Änderungen schrittweise, bewerten Sie die Ergebnisse und wiederholen Sie die Schritte. Denken Sie daran, dass der agile Ansatz nicht nur in der Softwareentwicklung funktioniert, sondern auf jede Art von organisatorischer Veränderung angewendet werden kann.

Hier sind einige Schritte zur Anleitung Ihres Verbesserungsprozesses:

  • Stellen Sie sicher, dass die Mitarbeiter genau wissen, was ihre Rollen beinhalten und was nicht in ihren Verantwortungsbereich fällt.
  • Erstellen Sie klar definierte Abteilungen oder Domänen und weisen Sie jeder Domäne bestimmte Teams zu.
  • Definieren Sie klare Verantwortungsbereiche und minimieren Sie Überschneidungen zwischen Abteilungen und Teams.
  • Machen Sie sich mit dem Team Topologies-Ansatz vertraut, der Plattform-, Stream-Alignment-, Enabling- und komplizierte Subsystem-Teams einführt, um verschiedene Aspekte der Softwareentwicklung abzudecken.
  • Überprüfen Sie Ihre Mitarbeiterhierarchie und passen Sie sie an die neu eingerichteten Domänen und Teams an.
  • Stellen Sie sicher, dass die Berichtsstrukturen klar sind und die Fortschrittsverfolgung unkompliziert ist.
  • Wählen Sie die Methodik oder das Framework aus, das Sie für die Funktionsbereitstellung und die Ergebnisverfolgung verwenden möchten.
  • Testen Sie Änderungen in einer beliebigen Abteilung, vorzugsweise nicht in einer kritischen, und beurteilen Sie die Auswirkungen. Verfeinern Sie Ihren Ansatz auf der Grundlage von Feedback und Ergebnissen.
  • Verbessern Sie sich kontinuierlich, indem Sie die gewählte Denkweise auf organisatorische Änderungen anwenden.


Indem Sie diese Schritte befolgen, können Sie fundierte, schrittweise Änderungen vornehmen, die die Effizienz und Effektivität Ihres Unternehmens schrittweise verbessern.

Zusammenfassung

Ich wollte allgemeine Probleme hervorheben, die in jedem Unternehmen oder jeder Abteilung auftreten können. Ich habe bewusst darauf verzichtet, bestimmte Frameworks oder Ansätze zu empfehlen, da jedes Unternehmen einzigartige Ziele und Strukturen hat und es entscheidend ist, zu entscheiden, was für Sie am besten funktioniert.

Auch hier ist es einfach, die Schuld den Entwicklern zuzuschieben, aber denken Sie daran, dass sie sich der geschäftlichen Prioritäten möglicherweise nicht bewusst sind oder durch unklare Lieferprozesse blockiert werden. Manchmal schafft das Unternehmen selbst unbewusst Blockaden. Ich hoffe, dieser Artikel hilft dabei, erste Schritte zur Verbesserung zu unternehmen.