Veröffentlicht auf Oktober 27, 2014
- in Das Qubiz Blog, Die Qubiz Kultur, Projekte und Know-how
Es ist einfach, die Business Analysten innerhalb eines Projektes zu identifizieren, aber nicht jeder weiß, was sie eigentlich machen. Um die Frage zu beleuchten, haben wir uns mit unserem Business-Analysten-Team zusammengesetzt und sie gefragt, uns dabei zu helfen, ihre Rolle besser zu verstehen, und vor allem das, warum sie so entscheidend für das Scheitern oder den Erfolg eines Projektes sind.

Lasst uns mit etwas Grundlegendes anfangen. Was ist ein Business Analyst? Was unterscheidet ihn von dem Functional Analyst?

Kurz gesagt, der Business Analytiker hat das Gesamtbild im Kopf, während der Functional Analyst sich auf die Details fokussiert. Der Business Analytiker ist fähig, das Geschäft des Kunden aus allen Hinsichten zu analysieren (Prozesse, Finanzen, Organisation) und Probleme und Chancen zu identifizieren, für die er dann dem Kunden Lösungen anbietet. Der Business Analyst denkt in Bezug auf die Prozesse, wobei die Lösung nicht immer eine Software-Anwendung ist. Er bespricht die Lösung mit dem Kunden und versichert sich, dass sie der Vision des Kunden entspricht. Sollte die passende Lösung doch eine Software-Anwendung sein, dann analysiert er in der nächsten Phase die technischen oder noch genauer gesagt, die funktionellen Anforderungen, die mit dem Kunden zusammen festgelegt wurden. Das ist nun der Moment, in dem der Functional Analyst ins Bild kommt. Der Kunde hat die Vision, der Business Analyst übersetzt sie in Geschäftsanforderungen und -ziele, während der Functional Analyst sicherstellt, dass die Anforderungen mit dem allgemeinen Zweck des Systems übereinstimmen.Der Business Analyst kann die Rolle des Functional Analysts übernehmen, nachdem die Lösung definiert und mit dem Kunden abgesprochen wurde. Bei Qubiz kombinieren wir die zwei Rollen, je nach den Besonderheiten eines Projektes.

Welche Rolle und Aufgaben hat ein Business Analyst?

Die Rolle des Business Analysts ist ziemlich komplex und beinhaltet Folgendes:
  • Mehrwert für den Kunden schöpfen, indem er Wege findet, um die vorhandenen Funktionalitäten zu verbessern;
  • Neue Systeme intuitiv verstehen und die Regeln erkennen;
  • Die Übersicht der Lösung haben;
  • Die technischen Spezifikationen des Projektes verfolgen (ist es ein Fehler, oder hat sich ein Leistungsmerkmal verändert?) und diese dokumentieren, um eine leichtere Bewertung zu ermöglichen;
  • Sein Geschäftswissen mit dem Team teilen (und auch mit den Project Ownern) und dem Team dabei helfen, die richtigen Entscheidungen zu treffen;
  • Die Kommunikation zwischen dem Team und dem Product Owner zu erleichtern, und damit die Unklarheiten in Bezug auf Zweck und Ziele des Projektes auszuräumen;
  • In Konfliktsituationen zwischen dem Kunden/Product Owner und dem Team, kann er neutral/ bleiben und beide Standpunkte verstehen.
Es wird oft gesagt, dass ein Business Analyst es lieber hat, Projekte anzufangen als sie zu beenden, weil der größte Arbeitsaufwand in die Projektinitialisierung steckt.

Könnte, und wenn ja, dürfte der Business Analyst die Rolle des Product Owners spielen?

Ja, der BA kann der Product Owner in einem Scrum-Projekt sein. Eigentlich, hatten wir schon bei Qubiz solche Projekte, bei denen der BA die Rolle des bevollmächtigten Product Owners hatte, und war immer vor Ort und für die Entwickler 24/7 erreichbar. Ist das denn die ideale Aufstellung? Manchmal nicht, aber das hängt vom Projekt ab.

Kann auch ein Entwickler oder ein Tester die Rolle des Business Analysts spielen?

Die idealen Kandidaten für die BA-Rolle sind Entwickler und Tester, die einen Schritt zurücktreten wollen, um das Großbild zu sehen. Als solche, können BA auch andere Rollen einnehmen, innerhalb des Unternehmens. Das hängt meistens von den Besonderheiten des Projektes ab, ob ein Vollzeitangestellter als BA eingesetzt werden muss oder nicht.Dennoch, brauchen Business Analyst spezifische Fähigkeiten, um ihre Arbeit zu leisten:
  • Gute Kommunikationsfähigkeiten: Sie müssen mit Leuten reden, die vielleicht nicht technisch versiert sind – wie z.B. Kunden. Und müssen dabei technische Begriffe verwenden und eine allgemeine Sprache benutzen, damit es dem Kunden leichter fällt zu verstehen, wie die Software eingesetzt werden kann, wie der Entwicklungsprozess verläuft sowie andere wichtige Details des Projektes;
  • Gutes Verständnis davon, wie alles in einem System integriert ist (aus funktioneller Sicht);
  • Mehrwert für den Kunden zu schaffen, indem sie die Prozesse für den Kunden optimieren;
  • Immer offen zu sein, um Neues über den Industriebereich des jeweiligen Kunden zu lernen. Indem sie diese Informationen und ihre professionelle Expertise kombinieren, können die BA die Anforderungen des Kunden und die tatsächlichen Bedürfnisse seines Geschäftes im Einklang bringen, um auf seinem Industriegebiet Erfolg erzielen zu können.

Muss der Business Analyst unbedingt über technisches Wissen verfügen? Muss er ein Experte auf dem Industriegebiet seines Kunden sein?

Obwohl die Business Analyst keinen einzigen Code schreiben, brauchen sie für ihre Rolle ein hohes Maß an technischem Wissen. Sie müssen in der Lage sein, Architektur-Ansätze zu besprechen, wenn sie dem Product Owner eine Software-Lösung anbieten.Für die zweite Frage, die Sachen sind ganz schön offensichtlich: je mehr Erfahrung der BA auf dem Industriegebiet seines Kunden hat, desto umfangreicher werden seine Lösungen sein. Falls es ihm an Erfahrung auf dem Gebiet seines Kunden fehlt, kann er diesen Mangel durch eine Serie von Treffen mit den Stakeholdern (Business Inhaber, Projektmanagers des Kunden, Endverbraucher etc.) kompensieren, und dadurch das Projekt doch erfolgreich starten.

Wie können die Business Analyst unternehmerisch in ihrer Beziehung zum Kunden vorgehen?

Proaktivität ist mehr als willkommen in der Business-Analyst-Rolle! Diese Eigenschaft ermöglicht es dem BA neue Bedürfnisse des Kunden zu identifizieren – welche oft nicht unbedingt projektbezogen sind - oder den Bedarf nach zusätzlichen Funktionalitäten aufzudecken.

Warum sollten Software-Unternehmen Business Analyst in ihrem Stab haben?

Die Unternehmen sollten die BA als einen kompetitiven Vorteil sehen, aus drei Hinsichten:Zum ersten hat kann ein agiles Team, das auch einen Business Analyst (und auch einen Functional Analyst) hat, viel schneller und unabhängiger arbeiten. Das heißt für den Product Owner, dass er selbst weniger Aufwand ins Projekt reinstecken muss; das Team ist fähig, selbst einige Fragen zu lösen, ohne bis zum nächsten Meeting mit dem Product Owner warten zu müssen. In solchen Fällen fungiert praktisch der BA, als ein bevollmächtigter des Product Owners.Zweitens, mit einem Business Analyst am Bord, befindet sich der Product Owner nicht mehr in der Situation, Selbstgespräche führen zu müssen, sondern kann mit dem Team in Dialog treten. Der Product Owner diktiert nicht mehr dem Team die Anforderungen, sondern diskutiert mit dem Team über seine Anforderungen. Sie umreißen zusammen die möglichen Probleme, und das Team kann dabei seine unternehmerischen Fähigkeiten einsetzen, indem es dem Product Owner proaktive Lösungen anbietet.Drittens, Business Analyst sind der Klebstoff ihres Teams. Bei Qubiz stellen wir die agilen Teams oft so zusammen, dass der BA auch der Scrum-Master ist. Der BA versteht die ganze Vielschichtigkeit des Systems und ist dadurch in der perfekten Position, dem Product Owner Vorschläge zu unterbreiten - wie z.B. welche Richtung das Projekt einschlagen sollte - und kann das Team zu diesem festgelegten Ziel führen.

Erzählt uns über einen interessanten Fall, in dem eure Rolle zentral war / oder der euch am besten gefallen hat?

  • R.S.: Der Kunde gab mir freie Hand zu entscheiden, welche Richtung das System einschlagen sollte und welche Datenbankstruktur angelegt werden sollte, um die Bedürfnisse des Endverbrauchers zu erfüllen.
  • S.B.: Als der Kunde eine Änderung an dem System machen wollte, hat er mich gefragt, ob wir die Änderung so machen sollten, wie er sie sich vorgestellt hatte, oder ob ich einen anderen Vorschlag dafür hätte.
  • R.B.: Wenn der Kunde es anerkennt, dass du Mehrwert für das Projekt geschöpft hast. Einmal habe ich dem Kunden ein Feature vorgeschlagen, woran er nicht gedacht hatte, und das hat ihm auf Anhieb gefallen!

Verwandte Beiträge

Comments