WIE BIG TECH TECH-PROJEKTE DURCHFÜHRT UND DIE SELTSAME ABWESENHEIT VON SCRUM

Technisches Projektmanagement ist der Prozess der Verwaltung aller IT- und IT-bezogenen Projekte. Technische Projektmanager sind unerlässlich, wenn es darum geht, ein Projekt zu initiieren, zu planen, durchzuführen, zu überwachen, zu kontrollieren und abzuschließen. Technisches Projektmanagement beinhaltet die Kommunikation sowohl mit technischen als auch mit nicht-technischen Beteiligten. Projektmanager haben die Art und Weise, wie Unternehmen Projekte planen und durchführen, verändert. Sie sind Innovatoren, starke Kommunikatoren, datengesteuerte Vermittler und Problemlöser, die andere führen und inspirieren.

Big Tech hat andere Ansätze für die Durchführung von Tech-Projekten als andere Unternehmen. Ich habe Daten gesammelt, indem ich einige bekannte börsennotierte Technologieunternehmen untersucht habe. Hier sehen Sie, wie sie die Dinge in der Regel angehen:

UnternehmenHaben sie eine zentrale Methodik?Projektmanagement-Methodik, die normalerweise bei der Durchführung von technischen Projekten verwendet wird.Leiter der technischen Projekte.
AmazonScrumPlanen (6-Paager) – Bauen (iterieren) – VersendenTechnischer Leiter
ApfelScrumPlanen – Bauen (wiederholen) – SchiffTechnischer Leiter
DatadogDie Teammitglieder können entscheidenPlanen (RFC) – Bauen – SchiffTechnischer Ingenieur oder Leiter
FacebookDie Teammitglieder können wählenPlanen – Bauen (iterieren) – AusliefernTechnischer Ingenieur oder Leiter
GoogleDie Teammitglieder entscheidenPlanen (Design Doc) – Bauen – SchiffTechnischer Ingenieur oder Leiter
NetflixDie Teammitglieder wählen eine geeignete MethodePlanen – Bauen (iterieren) – AusliefernTechnischer Ingenieur oder Leiter
ShopifyDie Projektmanagement-Methodik wird in der Regel bei der Durchführung von technischen Projekten eingesetzt.Nein, das Team wählt ausTechnischer Ingenieur oder Leiter

Hier sind einige der Merkmale, die Big Tech-Ingenieure bei der Durchführung von Projekten gemeinsam haben

  • Die meisten Projekte werden von Ingenieuren geleitet: Sowohl entwickelte Startups als auch Big Tech setzen in der Regel ihre Ingenieure auf allen Ebenen ein, um technische Projekte zu leiten. Als Ingenieur ist es wichtig, dass Sie sich die Fähigkeiten aneignen, dies zu tun, wenn Sie in leitende Positionen aufsteigen wollen. Und wenn Sie als Manager Ihren Mitarbeitern helfen, diese Fähigkeiten zu entwickeln, können Sie sich als Führungskraft weiterentwickeln.
  • Die Teams haben die Möglichkeit, die Projektmanagement-Methode zu wählen: Viele Teams arbeiten mit einem RFC-ähnlichen Planungsprozess, wiederholen den Aufbau und liefern alles innerhalb weniger Wochen aus. Andere Teams verwenden eher Kanban-ähnliche Methoden und arbeiten an den Artikeln mit den höchsten Prioritäten.
  • Für Projekte auf Teamebene gibt es keinen festen Projektmanager: Die meisten Unternehmen haben technische Programmmanager (TPMs), die für große Projekte zuständig sind, an denen mehrere Teams beteiligt sind oder die organisationsübergreifend laufen. Diese Manager leiten auch technische Programme, die sich nicht als Produkte qualifizieren. Wenn es um die Arbeit geht, die kein Produkt oder keine Plattform ist, die aber unerlässlich ist, wie die Migration von lokalen Rechenzentren zu einem Cloud-Anbieter. Das sind die Bereiche, in denen TPMs die Verantwortung übernehmen.

Das ist für Mitarbeiter in großen Technologieunternehmen sehr üblich. Wenn Sie jedoch den gleichen Ansatz in einem traditionelleren Unternehmen kopieren würden, würde er wahrscheinlich scheitern. Das liegt daran, dass die Organisationsstruktur von Big Tech die Art und Weise, wie Teams ihre Aufgaben erfüllen können, erheblich beeinflusst.

WARUM GROSSE TECH-UNTERNEHMEN KEIN SCRUM VERWENDEN

  • Scrum ist nicht agil: Scrum wurde anfangs so stark mit agilen Projekten in Verbindung gebracht, dass die Gemeinschaft es versäumte, sie als getrennt zu betrachten. Der wissenschaftliche Ansatz von Scrum und die enthusiastische Werbung dafür haben viele in ein falsches Gefühl der Sicherheit versetzt. Die Betonung von Scrum auf empirisches Management ist logisch begründet. Wenn sich die Umstände und Prioritäten schnell ändern, scheitern konventionelle Planung und Ausführung, so dass Sie stattdessen kontinuierlich beobachten und anpassen müssen.
  • Das ist genau das, was agile Softwareentwicklungsansätze leisten, auch wenn sie aus einer anderen Perspektive zu ähnlichen Praktiken gelangt sind.
  • Hybris und Enthusiasmus: Viele erwarteten, dass Scrum ein „Wrapper“ für jede Art von neuer Produktentwicklungsmethode sein würde. Das war zwar gut gemeint, ignorierte aber einen fatalen logischen Fehler: Wenn man einen nicht-agilen Prozess einwickelt, ist das Ganze nicht mehr agil. Diese Hybris führt dazu, dass so viele Scrum-Projekte die Saat für ihr Scheitern legen. Der fatale Fehler von Scrum ist, dass es sich selbst als hohl ansieht; es hat keine Meinung dazu, wie Software entwickelt werden „sollte“. Es ist, als ob die Assoziation von Scrum mit Agile eher als ein Umstand denn als eine Eigenschaft angesehen würde. Agile wird durch Prinzipien und Werte beschrieben, nicht durch Zeremonien und Prozesse. Agile wird durch ein Manifest geregelt, nicht durch ein Prozesshandbuch. Dies sind zwei sehr unterschiedliche Dinge, und dennoch sind viele Menschen auch heute noch durch diese Vermischung verwirrt.
  • Scrum führt oft zu einer Ausweitung des Projektumfangs, da es kein definitives Enddatum gibt.
  • Die Wahrscheinlichkeit, dass ein Projekt scheitert, ist hoch, wenn der Einzelne nicht sehr engagiert oder kooperativ ist.
  • Die Einführung des Scrum-Frameworks in großen Teams ist eine Herausforderung
  • Der Rahmen kann nur mit erfahrenen Teammitgliedern erfolgreich sein
  • Tägliche Meetings frustrieren manchmal die Teammitglieder
  • Wenn ein Teammitglied während der Durchführung eines Projekts aussteigt, kann dies erhebliche negative Auswirkungen auf das Projekt haben.
  • Qualität lässt sich nur schwer umsetzen, wenn die Teammitglieder einen anspruchsvollen Testprozess durchlaufen.

WIE SICH DIE ORGANISATIONSSTRUKTUREN VON BIG TECH AUF PROJEKTE AUSWIRKEN

Um zu verstehen, wie Big Tech Projekte verwaltet, sollten wir einen Schritt zurücktreten und das Umfeld analysieren, in dem die meisten dieser Unternehmen arbeiten:

Eigenständigkeit für Software-Ingenieure. Von Entwicklern in etablierten Unternehmen wird erwartet, dass sie die ihnen zugewiesenen Aufgaben erfüllen. Bei Startups wie Unternehmen wird erwartet, dass sie die Probleme lösen, mit denen das Unternehmen gerade konfrontiert ist. Das ist ein erheblicher Unterschied, der sich wiederum auf den Arbeitsalltag eines jeden Ingenieurs auswirkt.

Problemlöser, keine hirnlosen Ressourcen. Ein motivierter Ingenieur, der Probleme schnell löst, erzielt mehr Wirkung als ein Industriearbeiter, der nur die Aufgaben ausführt, die ihm aufgetragen wurden. Für Unternehmen, die mit Industriearbeitern arbeiten, ist diese Methode nicht für schwergewichtige Projektmanagementansätze geeignet, die absichtlich weniger Spielraum für Interpretationen lassen.

Einblicke in das Geschäft und die Geschäftsmetriken. Ingenieure müssen mit dem Rest der Branche interagieren und Beziehungen zu Nicht-Ingenieuren aufbauen. Auf der anderen Seite machen es traditionelle Unternehmen den Entwicklern in der Regel schwer, mit dem Rest des Unternehmens zu interagieren.

Ingenieur-zu-Ingenieur-Kommunikation über Dreieckskommunikation. In traditionellen Unternehmen wird in der Regel eine hierarchische Kommunikation gefördert, die den Informationsfluss verlangsamt und dazu führt, dass Entscheidungen langsamer getroffen werden und sich die Markteinführung von Produkten verzögert.

Eine weniger enttäuschende Erfahrung für Entwickler schaffen. Unternehmen, die ihr Augenmerk darauf richten, dass Ingenieure in der Lage sind, Probleme so schnell wie möglich zu lösen, schaffen mehrere Plattformteams, die die Abwanderung von Entwicklern verringern.

Höhere Gehälter sind durch eine höhere Verschuldung gerechtfertigt. Unternehmen, die Ingenieure einsetzen, werden keine Probleme haben, in der Nähe der Marktspitze oder darüber zu zahlen.

Das Kaliber des eingestellten Talents. Diese Unternehmen stellen hochkompetente und hochmotivierte Mitarbeiter ein, da sie die oben genannten Faktoren vereinen. Sie können aus einem großen Pool auswählen, da sie für großzügige Vergütungspakete und umfangreiche Karrieremöglichkeiten bekannt sind.

Was ist Scrum?

Scrum ist eine agile Entwicklungsmethodik, die zur Entwicklung von Software auf der Grundlage sich wiederholender und inkrementeller Prozesse verwendet wird. Scrum ist leicht anpassbar, flexibel, schnell und ein praktisches agiles Framework, das Teams bei der Zusammenarbeit unterstützt. Es ermutigt die Teammitglieder, durch Erfahrungen zu lernen, sich bei der Lösung eines Problems selbst zu organisieren und über ihre Erfolge und Verluste zu reflektieren, um eine kontinuierliche Verbesserung zu gewährleisten. Es ist darauf ausgelegt, dem Kunden während der gesamten Entwicklung eines Projekts einen Mehrwert zu bieten.

Die Bedeutung der Scrum-Methodik

  • Die Scrum-Methodik ist einfach und effektiv. Sie ist etwas anderes als eine essentielle Sammlung von miteinander verbundenen Komponenten. Die Scrum-Methodik wird in der Regel als eine Philosophie missverstanden. Sie verwirklicht die logische Methode des Experimentierens. Die Scrum-Methodik kann auch anstelle eines maßgeschneiderten algorithmischen Ansatzes verwendet werden. Man neigt dazu, Scrum-Methodik und Agile als etwas Ähnliches zu betrachten, weil Scrum-Methodik auf konsequenter Verbesserung basiert, die eine zentrale Leitlinie der agilen Scrum-Methodik ist.
  • Die Scrum-Methodik ist ein Rahmenwerk für die Durchführung von Arbeiten, während Agile eine Einstellung ist. Der Scrum-Methodik-Rahmen ist erfahrungsbasiert; er stützt sich auf kontinuierliches Lernen und ändert sich bei schwankenden Komponenten. Sie stellt fest, dass der Einzelne zu Beginn eines Projekts nicht alles weiß und sich allmählich weiterentwickeln wird.
  • Die Scrum-Methodik hilft Organisationen, sich seltener an schwankende Umgebungen und Kundenbedürfnisse anzupassen. Die Hauptpriorität des Scrum-Rahmens besteht darin, die kurzen Lieferzyklen zu verbessern und Organisationen dabei zu helfen, während der Arbeit zu lernen. Die Scrum-Methodik ist zwar organisiert, aber nicht sehr starr. Ihre Ausführung kann auf die Anforderungen jeder Organisation zugeschnitten werden. Es gibt zahlreiche Hypothesen darüber, wie genau Scrum Methodology Gruppen funktionieren müssen, um effektiv zu sein. Nachdem wir bei Atlassian über eine lange Zeit hinweg agile Gruppen bei ihrer Arbeit unterstützt haben, haben wir jedoch festgestellt, dass eine gute Korrespondenz, Geradlinigkeit und ein Engagement für kontinuierliche Verbesserung stets im Mittelpunkt stehen sollten, egal für welches Scrum- und agile Framework Sie sich entscheiden.

Verschiedene Rollen in Scrum

Die drei Scrum-Rollen beschreiben die Hauptaufgaben derjenigen, die im Scrum-Team mitarbeiten. Es handelt sich dabei nicht um Berufsbezeichnungen, d.h. jede Berufsbezeichnung kann eine der Rollen ausfüllen, auch Ihre. In Scrum konzentriert sich das Team in der Regel auf Selbstorganisation, kontinuierliche Verbesserung und die Erstellung von Qualitätssoftware. Der Eigentümer eines Scrum-Projekts achtet darauf, die Funktionen zu definieren, die das Produkt haben soll (was soll gebaut werden, was nicht und in welcher Reihenfolge) und Herausforderungen zu bewältigen, die das Entwicklungsteam behindern könnten.

Das Scrum-Team umfasst die folgenden Rollen:

Scrum Master: die Person, die hinter dem Team steht, die die Richtung vorgibt und es anleitet, nach den Regeln und Prozessen der Methodik zu handeln. Der Scrum Master kontrolliert auch den Abbau von Hindernissen für das Projekt und arbeitet mit dem Product Owner zusammen, um die Kapitalrendite zu verbessern. Der Scrum Master hilft dem Product Owner auch dabei, den Wert zu definieren, das Entwicklungsteam schafft den Wert und das Scrum Team macht ihn besser. Der Scrum Master beschreibt nicht nur eine unterstützende Art der Führung, sondern auch die täglichen Abläufe im Team.

Product Owner: Dies ist der Vertreter der Interessengruppen und Kunden, die die Software nutzen. Er konzentriert sich auf den geschäftlichen Teil und ist für die Rentabilität des Projekts verantwortlich. Der Product Owner versteht nicht nur die Bedürfnisse der Kunden, sondern visualisiert auch den Wert, den das Scrum-Team den Kunden liefern wird. Er sorgt auch dafür, dass ein Gleichgewicht zwischen den Bedürfnissen der Beteiligten besteht. Der Product Owner muss also für diese Inputs verantwortlich sein und die Arbeit zur obersten Priorität machen. Dies ist eine wichtige Aufgabe, denn widersprüchliche Prioritäten minimieren die Effektivität des Teams und zerstören das Vertrauen zwischen dem Entwicklungsteam und dem Unternehmen.

Das Team: Dies ist in der Regel eine Gruppe von Experten mit dem erforderlichen technischen Wissen für die Entwicklung des Projekts, die gemeinsam die Aufgaben ausführen, mit denen jeder Sprint beginnt. Die meisten Leute denken, dass das Entwicklungsteam nur aus Ingenieuren bestehen muss, aber das ist nicht der Fall. Das ist aber nicht der Fall. Dem Entwicklungsteam können alle Arten von Personen angehören, darunter Designer, Programmierer oder Autoren. Dieses Team sollte selbstorganisiert sein, um Entscheidungen treffen zu können, mit denen die Arbeit erledigt wird. Das Entwicklungsteam kann genau wie das Team für den Produktionssupport Entscheidungen umsetzen, die die anstehenden Probleme beheben und gleichzeitig einen Mehrwert bieten. Dieses Team sorgt auch für Transparenz während des täglichen Standups. Das tägliche Scrum-Standup sorgt für Transparenz bei der Arbeit und bietet eine Plattform, über die Teammitglieder um Hilfe bitten können.

Fazit

Wir haben erörtert, wie Unternehmen in verschiedenen Stadien ihre Projekte mit unterschiedlichen Methoden durchführen und dass Big Tech im Allgemeinen keinen einheitlichen Ansatz verfolgt. Dennoch haben große Firmen viel organisatorische Unterstützung, damit dieser Prozess funktioniert.

Wie Sie Teams führen, sollte im Allgemeinen von Ihrem Kontext abhängen. Zu den relevanten Faktoren gehören Ihre Organisationsstruktur, die Menschen, mit denen Sie zusammenarbeiten, die Autonomie und die Fähigkeiten dieser Menschen, Ihre Konkurrenz und die Frage, ob Sie in „Kriegszeiten“ oder „Friedenszeiten“ arbeiten. Die Liste lässt sich fortsetzen.

DevologyX OÜ
Harju maakond, Tallinn, Lasnamäe
linnaosa,
Vaike-Paala tn 1, 11415

+372 6359999
[email protected]
DevologyX Limited
Nakawa Business Park
Kampala
Uganda

+256206300922
[email protected]

DevologyX Pty Ltd
Tijger Park 3
Willie van Schoor Drive
Bellville
Cape Town
7530

[email protected]

DevologyX OÜ
Harju maakond, Tallinn, Lasnamäe
linnaosa,
Vaike-Paala tn 1, 11415

+372 6359999
[email protected]
DevologyX Limited
Nakawa Business Park
Kampala
Uganda

+256206300922
[email protected]

DevologyX Pty Ltd
TijgerPark 3
Willie van Schoor Drive
Bellville
Kapstadt
7530

[email protected]