In der dynamischen Welt der Softwareentwicklung ist die Schnittstelle zwischen Geschäftsanforderungen und technischer Umsetzung von entscheidender Bedeutung. Um diese Brücke zu schlagen, setzen viele Unternehmen auf die Rolle des Business Analysts (BA). Auf den ersten Blick scheint diese Position unverzichtbar: Sie übersetzt komplexe Geschäftsbedürfnisse in verständliche Anforderungen für Entwicklerteams. Doch die Realität gestaltet sich oft komplizierter. Die Einbindung eines BAs wirkt sich nicht immer positiv auf den Entwicklungsprozess aus und kann in bestimmten Fällen sogar schädlich für die Organisation sein.
Unternehmen starten meist klein. Gründer oder ein kleines Team nehmen sowohl Geschäftsentscheidungen als auch die Softwareentwicklung selbst in die Hand. In dieser Konstellation ist der direkte Austausch zwischen Business und Technologie noch unkompliziert. Der Abstand zwischen Entscheidungsträgern und Entwicklern ist minimal oder nicht existent. Kommunikation erfolgt unmittelbar – oft im persönlichen Gespräch – was schnelle Feedbackzyklen ermöglicht und Missverständnisse minimiert.
Diese Nähe erlaubt es Entwicklern, ein tiefes Verständnis der Geschäftsproblematik zu gewinnen und effiziente Lösungsansätze zu entwerfen, die tatsächlich den Anforderungen entsprechen. Mit dem Wachstum einer Firma steigt jedoch auch die Anzahl der Beteiligten. Die Kommunikation zwischen Business-Seite und IT wird komplexer. Unternehmen neigen dazu, den Kontakt zwischen beiden Parteien zu institutionalisieren und delegieren die Übersetzungsaufgabe an Business Analysts. Diese fungieren als Bindeglied, sind aber meist weder in der Position, weitreichende Geschäftsentscheidungen zu treffen, noch verfügen sie immer über tiefgehende technische Expertise.
Die unmittelbare Kommunikation zwischen den eigentlichen Entscheidungsträgern und den technikaffinen Entwicklern wird dadurch erschwert. Der Informationsfluss verlangsamt sich, denn nun ist ein zusätzlicher Vermittler involviert, der je nach Qualifikation und Kontext unterschiedlich gut agieren kann. Diese zusätzliche Abstraktionsschicht führt häufig zu einer Verlängerung der Feedbackzyklen. Statt einer direkten Frage an die Chefin oder den Produktverantwortlichen benötigt der Entwickler zunächst eine Rückmeldung vom BA. Ist dieser nicht in der Lage, sofort Auskunft zu geben, wird die Frage weitergereicht und muss erst von der Business-Seite beantwortet werden.
In schnelllebigen Projekten kann dieser Kommunikationsverzug erhebliche Konsequenzen haben. Wichtige Entscheidungen werden verzögert und Anpassungen können sich unnötig in die Länge ziehen. Der Moment, in dem Entwickler auf Änderungsbedarf aufmerksam werden, ist oftmals der Zeitpunkt, an dem die Flexibilität am wichtigsten wäre. Darüber hinaus bringt die Präsenz eines Business Analysts eine ungewollte Gefahr mit sich: Entwickler „entmündigen“ sich selbst häufig, indem sie sich zu sehr auf die zuvor ausgearbeiteten Anforderungen verlassen. Sie nehmen diese als unumstößliche Vorgaben hin, anstatt sich eigenständig mit den geschäftlichen Hintergründen auseinanderzusetzen.
Viele verlieren dadurch das Verständnis für das „Warum“ hinter ihrer Arbeit, wodurch Motivation und Innovationsfreude leiden können. Entwickler werden zunehmend zu bloßen „Ausführenden“ reduziert, die Technik implementieren, ohne selbst die Geschäftsproblematik zu durchdringen. Diese Distanz zwischen Technik und Business kann die Qualität der Lösungen beeinträchtigen, da wichtige Nuancen verloren gehen. Ein weiterer Aspekt, der die Rolle des Business Analysts problematischer macht, ist das Risiko der Informationsverzerrung. Das bedeutet, dass bei jeder zusätzlichen Kommunikationsstufe die Wahrscheinlichkeit steigt, dass zentrale Details verloren gehen, missverstanden oder falsch interpretiert werden.
Diese Verkettung von Missverständnissen ähnelt dem bekannten „Stille-Post“-Spiel, bei dem eine Information von Person zu Person weitergegeben wird und am Ende kaum noch dem Original entspricht. Obwohl schriftliche Dokumentation diesen Effekt abschwächen kann, ist Softwareentwicklung zu komplex und dynamisch, als dass ein starres Dokument alle Veränderungen oder Unsicherheiten abbilden kann. Anforderungen entwickeln sich laufend weiter, was einen engen Dialog zwischen Business und Entwicklern erfordert. Die Gefahr, dass ein Business Analyst in technische Detailfragen hineinzieht, ist ein weiterer Stolperstein. Oftmals versuchen BAs, Entscheidungen über API-Aufrufe, Datenstrukturen oder technische Architekturmuster zu treffen, obwohl dies eigentlich in die Verantwortung der Entwickler fällt.
Wenn BAs in diese Gebiete eingreifen, liegt häufig eine Verwechslung der Rollen und Zuständigkeiten vor. Entwickler, die über tiefgreifendes technisches Wissen verfügen, sollten diese Entscheidungen fällen, um optimale technische Lösungen zu gewährleisten. Werden technische Entscheidungen jedoch durch Personen getroffen, die nicht regelmäßig in der Softwareentwicklung tätig sind, kann dies die Qualität und Wartbarkeit des Produkts gefährden. Gleichzeitig bedeutet Softwareentwicklung, dass das Team eng mit Domain-Experten zusammenarbeiten muss, um ein tiefgehendes Verständnis der Geschäftslogik zu gewährleisten. Entwickler müssen die Möglichkeit haben, direkt mit Fachleuten aus dem Business-Bereich zu kommunizieren und Fragen in Echtzeit zu klären – vor allem in komplexen oder schnell ändernden Szenarien.
Die Zwischenschaltung eines BAs kann diesen direkten Austausch behindern. Die Fähigkeit, schnell auf Kundenanforderungen oder Marktveränderungen zu reagieren, ist heutzutage ein entscheidender Wettbewerbsvorteil. Ein langwieriger Genehmigungsprozess oder verzögerte Feedback-Schleifen schränken die Agilität eines Teams stark ein. Kleine Anpassungen, wie die Änderung eines Features oder die Verschiebung eines Bedienelements, können in Unternehmen mit zu vielen Hierarchieebenen leicht Wochen dauern. Teams, in denen Entwickler unmittelbar mit Entscheidungsträgern zusammenarbeiten, können viel schneller reagieren und sind somit besser für eine dynamische Produktentwicklung aufgestellt.
Die Erfahrung zeigt zudem, dass in Unternehmen mit Business Analysts das allgemeine Engagement der Entwickler abnimmt. Wenn sie wissen, dass Antworten auf gestellte Fragen erst nach langen Wartezeiten oder mehreren Kommunikationsstufen kommen, stellen sie die Nachfrage oft rasch ein. Dies führt zu einer passiven Haltung, bei der einfach nur noch umgesetzt wird, was vorgegeben ist, ohne die Hintergründe und das eigentliche Kundenproblem zu verstehen. Für Entwickler ist der direkte Zugang zu echten Entscheidern essentiell, um den Sinn ihrer Arbeit zu begreifen und die beste technische Umsetzung anbieten zu können. Ein idealtypischer Softwareentwicklungsprozess zeichnet sich durch kurze Feedbackzyklen und eine direkte Kommunikation zwischen Business und Technik aus.
Keine Rolle, wie erfahren der Business Analyst auch sein mag, kann den unmittelbaren Austausch zwischen einer fachlich kompetenten Person aus dem Business und einem technisch versierten Entwickler vollständig ersetzen. Das schnelle Beantworten von Fragen, das gemeinsame Diskutieren von Szenarien und das unmittelbare Anpassen von Anforderungen sind wesentliche Faktoren für den Erfolg. Nicht zuletzt sollte in Organisationen auch die Verantwortung der Entwickler selbst gestärkt werden. Sie sind nicht nur Code-Schreiber, sondern Problemlöser, die – wenn sie die Möglichkeit dazu erhalten – aktiv an der Gestaltung der Lösung und an geschäftlichen Entscheidungen teilnehmen wollen. Das Einführen von Rollen, die diese direkte Verantwortung und Kommunikation blockieren, kann langfristig Innovation und Entwicklungserfolg verhindern.
