Das Entwicklerteam von Compass hatte ein Problem. Technisch waren unsere Lösungen einwandfrei, was fehlte, war der Zugang zum Kunden. Wir waren effizient darin, Code zu schreiben, aber haben wir die richtigen Probleme gelöst?
Als Senior Engineering Manager bei Atlassian, wo ich an Compass arbeite, habe ich mich jahrelang mit dieser Frage auseinandergesetzt. Mein Team und ich sind dafür verantwortlich, Tools zu entwickeln, die Entwicklungsteams bei der Verwaltung ihrer Softwarekomponenten und Ressourcen im großen Maßstab unterstützen. Als ich anfing, fiel mir ein Muster auf, mit dem viele technische Organisationen konfrontiert sind: Wir sind großartig darin, Funktionen bereitzustellen, aber manchmal verfehlen wir das Ziel, einen Mehrwert zu bieten.
Ich habe aus erster Hand gesehen, wie Ingenieurskultur den Erfolg eines Produkts bestimmen oder zerstören kann. Bei Atlassian entwickeln wir nicht nur Tools für Softwareteams – wir leben und atmen die gleichen Herausforderungen, vor denen unsere Kunden täglich stehen. Das gibt uns eine einzigartige Perspektive auf die Transformation der Ingenieurskultur, und deshalb teile ich besonders gerne, was wir gelernt haben.
Entwickler – normalerweise abgekoppelt
Nehmen wir als Beispiel ein hypothetisches Produktteam, das es so überall geben könnte.
Tina ist leitende Entwicklerin, die für ihr technisches Know-how bekannt ist. Sie schreibt tadellosen Code, ist aber in einem typischen Kreislauf gefangen: Anforderung erhalten, Code schreiben, Funktionen bereitstellen. "Ich habe in einem luftleeren Raum programmiert", sagt Tina. "Ich hatte keine Ahnung, ob meine Arbeit tatsächliche Kundenprobleme löst." Sie wünscht sich mehr Kontext und Input vom Kunden, fühlt sich aber eingeschränkt, weil sie nur an der Implementierung arbeitet.
Rita, die Produktdesignerin des Teams, hat ihre eigenen Probleme. Sie verbringt Wochen damit, pixelgenaue Designs zu erstellen, nur um dann von der Entwicklung entscheidendes Feedback zu erhalten, das ihr größere Überarbeitungen abnötigt. "Bis Entwickler auf technische Einschränkungen hinweisen, ist es oft zu spät, um die ursprüngliche Designvision beizubehalten", erklärt sie. Rita wünscht sich eine bessere Integration in den Entwicklungsprozess und eine Möglichkeit, Designs früher zu validieren.
Dann ist da noch Paul, der Produktmanager, der versucht, alles zusammenzuhalten. Er verbringt unzählige Stunden damit, detaillierte Anforderungsdokumente zu schreiben, aber irgendwas geht im Verlauf immer verloren. "Es ist, als würde man stille Post spielen", so Paul. "Bis die Funktionen beim Kunden ankommen, ist etwas ganz anderes daraus geworden, als wir uns ursprünglich vorgestellt hatten." Er sucht verzweifelt nach einem Weg, die Zusammenarbeit zwischen Entwickler- und Designteams zu verbessern, aber der traditionelle Übergabeprozess schafft immer neue Hindernisse.
Rick, der Programmmanager, hat vielleicht die herausforderndste Rolle von allen. Die Koordination mehrerer Teams und das Ausbalancieren von Liefergeschwindigkeit und Qualität halten ihn nachts wach. "Wenn Teams isoliert arbeiten, können einfache Änderungen zu wochenlangen Verzögerungen führen", beobachtet Rick. Er brauchte eine Möglichkeit, die Zusammenarbeit unter den Teams und die Sichtbarkeit zu verbessern.
Die technische Leiterin Anna hat die Oberaufsicht und möchte die Arbeitsweise ihrer Teams nachhaltig verändern. Obwohl sie technische Exzellenz sehr schätzt, weiß sie, dass sie nicht alles ist. "Wir haben unglaublich talentierte Entwickler", stellt sie fest, "aber wir liefern nicht durchgehend den Nutzen, den unsere Kunden benötigen." Anna möchte die Teamkultur verändern, aber das traditionelle Entwicklungsmodell macht es schwierig, technische Exzellenz und Kundennutzen in Einklang zu bringen.
Das beschriebene Szenario spiegelt ein gängiges Muster in der Softwareentwicklung wider. Obwohl organisiert und vorhersehbar, schafft der traditionelle phasenweise Ansatz eine natürliche Trennung zwischen denen, die das Produkt herstellen, und denen, die es verwenden.
Kultur: Der Schlüssel zur Transformation
"Kultur verspeist Strategie zum Frühstück." Dieses Zitat wird oft dem Management-Guru Peter Drucker zugeschrieben. An Bedeutung gewann es, als Mark Fields es 2006 dauerhaft in einem Konferenzraum in Fords Firmenzentrale installieren lies. Die Aussage ist mehr als Effekthascherei – sie drückt eine einfache Tatsache aus, die sich in der Technologiebranche wiederholt bewahrheitet hat: Selbst die brillanteste Strategie wird scheitern, wenn sie mit der Unternehmenskultur kollidiert.
Als wir beschlossen, unsere Ingenieurskultur bei Compass zu transformieren, entdeckten wir etwas Tiefgreifendes: Technische Exzellenz ist nicht alles. Wir mussten die Kluft zwischen Entwicklern und Kunden überbrücken. Die Zahlen belegen das: Unternehmen mit einer starken Kultur verzeichnen ein vierfaches Umsatzwachstum im Vergleich zu ihren Konkurrenten.
Unsere eigene Transformation bei Compass veranschaulicht das perfekt. Wir sind von einem herkömmlichen Feature-Lifecycle-Prozess, der in der Regel 6–8 Wochen in Anspruch nahm, zu einem iterativen Ideenfindungsprozess übergegangen, der uns den Kundenproblemen viel näher gebracht hat. Das war nicht nur eine Prozessänderung, sondern ein grundlegender Wandel von einer "Wir wissen schon alles"- zu einer "Wir lernen ständig weiter"-Mentalität, bei der jedes Feature eine Chance darstellte, von den Kunden zu lernen.
Die Evolution der Produktentwicklung
Bei der Softwareentwicklung ging es immer darum, aus Anforderungen durch systematisches Entwerfen, Entwickeln und Testen funktionierenden Code zu erschaffen. Die Entwickler konzentrieren sich hauptsächlich auf die technische Ausführung: das Schreiben von effizientem Code, die Wartung von Systemen und die Sicherstellung der Qualität.
Die Produktentwicklung stellt unsere Herangehensweise an die Entwicklung von Software auf den Kopf. Hohe technische Qualität bleibt ein Hauptmerkmal der Softwareentwicklung, zwei entscheidende Element kommen jedoch hinzu: tiefes Kundenverständnis und kontinuierliches Lernen. Produktentwickler schreiben nicht nur Code, sie sind auch an der Analyse und Lösung von Kundenproblemen beteiligt, bringen ihr technisches Know-how in Produktentscheidungen ein und sind für die Ergebnisse ihrer Arbeit verantwortlich.
Das herkömmliche Softwareentwicklungsmodell
Beim herkömmlichen Modell folgt die Entwicklung einem linearen Pfad. Vom Produktmanagement kommt die Anforderungsbeschreibung, die an das Designteam übergeben wird und schließlich bei den Entwicklern landet, die alles in Programmcode umsetzen. Stell dir den Prozess wie einen Staffellauf vor, bei dem jedes Team den Staffelstab an das nächste weitergibt.
Unser Team arbeitete früher genau nach diesem Muster:
- Die Erstellung und Freigabe der Leistungsbeschreibung dauerte Monate.
- Architekten und Designer arbeiteten getrennt voneinander.
- Die Entwickler schrieben ihren Code nach exakten Spezifikationen.
- Am Ende standen die Testphase und das Deployment.
- Das Feedback vom Kunden durchlief mehrere Ebenen.
Dieser Ansatz funktionierte gut, als Leistungsbeschreibungen unveränderlich und Änderungen teuer waren. Aber in den sich schnell entwickelnden Märkten von heute benötigten wir etwas, das flexibler und kundenorientierter ist.
Der kontinuierliche Kreislauf der Produktentwicklung
Unsere Transformation konzentrierte sich darauf, den linearen Prozess durch eine kontinuierliche Lernschleife zu ersetzen. Anstatt Entwicklung als Staffellauf zu sehen, arbeiten wir jetzt eher wie eine Fußballmannschaft – alle bewegen sich zusammen, passen sich an wechselnde Bedingungen an und behalten das Ziel im Auge, echten Kundennutzen zu liefern.
Das neue Modell:
- Entwickler sind an Kundeninterviews und der Ideenfindung beteiligt.
- Entwicklung und Design arbeiten Hand in Hand, mit schnellem Prototyping und Tests.
- Technische Entscheidungen werden mit den Kundenbedürfnissen abgeglichen.
- Das Deployment ist nicht nur mehr ein Meilenstein zum Erreichen des Endergebnisses, sondern wird als Lernmöglichkeit angesehen.
- Teams messen den Erfolg am Kundenimpact, nicht nur an technischen Metriken.
Von der Implementierung zur Eigenverantwortung
Für Entwickler wie Tina bedeutete diese Transformation, von der reinen Implementierungsarbeit zur Eigenverantwortung überzugehen. Die Arbeitsbeschreibung unserer Entwickler hat sich geändert:
- An der Problemdefinition und Lösungsfindung beteiligen
- Eine technische Perspektive in frühe Diskussionen einbringen
- Fragen direkt mit dem Kunden abklären
- Eigenverantwortlichkeit für Features über die reine Codequalität hinaus
- Geschäftsmetriken und Marktauswirkungen im Blick behalten
Die Ergebnisse sprechen für sich: Unternehmen, die dieses Modell anwenden, erreichen eine schnellere Markteinführung und eine höhere Akzeptanz von Features als Unternehmen, die traditionelle technische Ansätze verfolgen. Vielleicht noch wichtiger ist, dass wir Verbesserungen bei der Teambeteiligung, den technischen Entscheidungen und der Übereinstimmung zwischen der technischen Lösung und dem Kundenbedürfnis sehen.
Wie wir unsere Transformation umgesetzt haben
Die Veränderung der Arbeitsweise von Entwicklern erforderte mehr als nur eine Änderung der Denkweise – es brauchte die richtige Grundlage. Für unser Team war Jira Product Discovery ein entscheidender Bestandteil dieser Grundlage, ein Tool, das den Kundenkontext auf natürliche Weise in unseren täglichen Arbeitsablauf einbezog.
Die erste Herausforderung, die wir lösen mussten, bestand darin, Kundeninformationen für alle zugänglich zu machen. Vorher waren Kundenfeedback und Produktanforderungen auf Confluence-Dokumente, Slack-Threads und Jira-Tickets verteilt. Jira Product Discovery stellte diesen Kontext direkt in unserem Entwicklungsworkflow bereit. Entwickler konnten jetzt Kundeninterviews, Feedbackgespräche und Nutzungsmuster direkt in der Entwicklungsumgebung sehen, wodurch Kundenbedürfnisse nachvollziehbar und unmittelbar statt abstrakt und abgekoppelt waren.
Diese neue Zugänglichkeit hat die Art und Weise der Zusammenarbeit unter den Teams grundlegend verändert. Wenn eine Designerin wie Rita neue Designs entwarf, konnte sie sie direkt mit den Pain Points der Kunden verknüpfen, die die Entwickler einsehen und nachvollziehen konnten. Wenn Paul Funktionen priorisierte, konnte er den Kundenimpact und die technische Komplexität in einen Zusammenhang bringen, was die Entscheidungsfindung verbesserte. Am wichtigsten war, dass unsere Entwickler endlich das komplette Bild vor Augen hatten – warum unsere Arbeit für den Kunden wichtig war und welche Auswirkungen sie haben würde.
Wenn ihr als Team eine ähnliche Transformation in Betracht zieht, denkt immer daran, dass es nicht darum geht, zwischen technischer Exzellenz und Kundenorientierung zu wählen. Das Ziel ist, beides zu vereinen und Produkte zu entwickeln, die eure Kunden begeistern. Entwickler, die die Anforderungen der Kunden genau kennen, treffen bessere technische Entscheidungen, entwerfen elegantere Lösungen und empfinden ihre Arbeit als erfüllender, weil sie ihre direkten Auswirkungen sehen können.
Möchtest du mehr darüber erfahren, wie wir diese Transformation umgesetzt haben? Sieh dir unser Webinar Die Kunst hinter der Produktentwicklung – vom Kundenproblem zur beliebten Funktion an, in dem ich genauer auf den Verlauf eingehe und praktische Strategien und Rituale vorstelle, die du in deinem eigenen Team einsetzen kannst.