Business Analysten entwickeln fachliche Lösungen, Entwickler technische! Oder?

Die Grenze zwischen den Rollen im Entwicklungsprozess sind fließend. In meinem vorherigen Beitrag habe ich erläutert, wen ich mit welche Rolle betrauen würde und wie sich dadurch die Produktentwicklung um das 100-fache beschleunigen lässt.

Wer kann sich wie an der Lösung beteiligen?

In diesem Beitrag möchte ich meine Sicht darauf geben, bis zu welcher Stelle der Product Owner gefragt ist und wann die Arbeit des Entwicklers beginnt. Dazu greife ich das Beispiel aus diesem Video auf:

 5*3 = 15

Stellen wir uns den Entwickler als Schüler in einer Matheklasse vor, die Multiplizieren lernen sollen. Der Business Analyst (BA) ist dabei der Lehrer, welcher den Schülern erklärt wie die Multiplikation funktioniert. Lediglich das Ergebnis zu nennen kann bei sehr trivialen Prozessen möglich sein. Da die wenigsten Prozesse in Unternehmen trivial sind, gehen wir davon aus, dass wir einer Erklärung bedürfen. Und genau an dieser Stelle scheiden sich häufig die Geister: In welche Tiefe muss der BA in das Problem einstigen und wie weit ins Detail bei dem Lösungsansatz gehen?

Klar ist: Der Lösungsansatz muss vom BA kommen, denn nur er weiß, wie er den Prozess gerne hätte bzw. wie er korrekt ist. Im obigen Beispiel muss der Lehrer den Schülern sagen, dass sich eine Multiplikation in eine Summe umformen lässt. Das kennen die Schüler bereits. Der Lehrer würde ihnen also sagen:

5*3 = 5+5+5 = 15

Leider ist das falsch. Nicht das Ergebnis, aber der Rechenweg.

5*3 = 5+5+5 = 15

Denn der korrekte Rechenweg lautet:

5*3 = 3+3+3+3+3 = 15

Leider reicht es bei Prozessen nur selten, wenn lediglich das Ergebnis korrekt ist, denn die Zwischenergebnisse können auch weiterverwendet werden. Außerdem ist nicht gesagt, dass für alle möglichen Werte das Ergebnis immer stimmt.

Wir waren uns einig, dass der Rechenweg vom BA kommen muss. Macht es dann Sinn, dass der Entwickler diesen validieren und ggf. zig Testrechnungen durchführen muss, um die Richtigkeit zu gewährleisten? Würden das die Schüler der imaginären Schulklasse machen? Können diese überhaupt alle etwaige Abzweigungen/Konstellationen kennen. Was wäre, wenn wir von irrationalen Zahlen sprechen würden? Die sind den Schülern noch gar nicht bekannt. Aber wie sollten sie dann eine Testrechnung mit selbigen machen? Wenn als nächstes auf dem Lehrplan die Division stünde, welche in eine Multiplikation umgeformt werden kann, wären die Schüler dann in der Lage den Rechenweg dahingehend zu validieren, dass er später auch bei Divisionen funktioniert?

Ich bin der Meinung, dass dem nicht so ist und daher der BA sich entsprechend darum kümmern muss. Dagegen spricht ebenfalls, dass es im Sender-Empfänger-Modell immer zu Problemen kommen kann. Wenn ich beim Schach von einem Spielfeld rede, meine ich dann das gesamte Brett oder eines der 64 Felder? Je früher es dabei zu Missverständnissen kommt, desto weiter bewegt man sich von der Lösung weg. Denn wenn der BA nur kontrolliert, ob das Ergebnis 15 ist, dann könnte im Untergrund auch einfach 5+10 gerechnet worden sein.

Selbst kleine Ungenauigkeiten können in der Praxis grobe Probleme machen. Ob ich einen Rabatt entweder auf jede einzelne Position einer Rechnung anwende und dann summiere oder ob ich den Rabatt auf gesamte Rechnung anwende und dann auf die einzelnen Positionen verteile, ist ein großer Unterschied. In bestimmten Fällen können so Rundungsfehler entstehen, die am Schluss das Ergebnis verändern. Wenn ich zuerst 10% abziehe und dann wieder 10% dazu rechne, dann kommt eben nicht der ursprüngliche Betrag heraus.

Mit diesen Details müssen sich aus meiner Sicht die Business Analysten beschäftigen. In technische Lösungen einzusteigen, verlangt niemand. Genauso wenig erwarte ich, dass alles immer zu 100% durchdacht werden kann. Ich schließe auch nicht aus, dass die Entwickler Vorschläge für bessere Lösungen geben. Aber wenn es um die fachliche Problemanalyse und das Entwickeln eines Lösungsansatzes geht, dann ist das die Kernaufgabe der BAs.

Wie seht ihr das? Sind bei euch die Aufgaben klar getrennt? Funktioniert das bei euch? Oder übernehmen bei euch die Entwickler die Rolle Business Analysten?

Werbung

Wie mittelständische Unternehmen ihre Produktentwicklung um das 100-fache beschleunigen

Vorweg: Die Zahl 100 ist frei erfunden, aber jetzt, wo du schon mal da bist, kannst du trotzdem weiterlesen und am Ende gerne einen Kommentar hinterlassen.

Rollen bei der Softwareentwicklung

Während Konzerne ganze Teams von Business Analysten mit entsprechendem akademischem Background haben, sind kleine und mittelständische Unternehmen (KMUs) weniger breit aufgestellt. Das trifft genauso auf die Größe des Entwicklerteams zu: Dedizierte Software-Architekten und Development Leads gibt es nur selten. Das rechte Bild zeigt einige der Rollen im Entwicklungsprozess von Software (aus diesem hervorragenden Video von Pluralsight entnommen). Deshalb gilt es zu analysieren, wer im Unternehmen welche Kompetenzen besitzt und wo es zu Engpässen kommt. Die Grenzen der Rollenübergänge sind aufgrund der fehlenden dedizierten Rollenbesetzung fließend und werden deshalb häufig von mehreren Personen übernommen.

Das trifft speziell auf die Rolle des Business Analysten zu. Während Wikipedia eine lange Liste von Aufgaben für diesen definiert, will ich meine Sicht – oder besser meine Vision – darlegen, auf welchen Personenkreis die Aufgaben in KMUs aufgeteilt werden müssen. Denn wenn diese Rolle im Unternehmen sinnvoll implementiert wird, ergibt sich ein gewaltiges Optimierungspotential. Generell muss das aber unternehmensspezifisch nach Kompetenzen und Verfügbarkeiten der Mitarbeiter geregelt werden. Diese gilt es kontinuierlich weiterzuentwickeln.

Zukunft des Anwenders

Fachexperten (in der Grafik Subject Matter Expert genannt) sind die eigentlichen Anwender des jeweiligen Geschäftsprozesses. Will man also wissen, wie das Versenden eines Packstückes abläuft und wo es dabei zu Problemen kommt, dann wäre der Lagerist der richtige Ansprechpartner. Deshalb sollte er es auch sein, der den Prozess im Unternehmenswiki festhält. Ein Wiki deshalb, weil es sich einfach nutzen lässt und einige wenige Regeln genügen, um es erfolgreich mit Inhalten zu füllen. Außerdem ist es die Grundlage, um neben dem Prozess Know How weiteres Inselwissen zu erfassen.

Zukunft des Product Owners

Die Koordination, den Überblick über Domänengrenzen hinweg, die Konsolidierung der Informationen und das Überführen von Anwenderwünschen siedle ich beim Produktverantwortlichen (Product Owner bei Scrum) an. Mit steigender Kompetenz und mit steigendem Wissen der Anwender können selbige immer mehr Verantwortung und Aufgaben übernehmen, z.B. das Formulieren der eigenen Wünsche in das Issue Tracking System (Backlog in Scrum). Der Product Owner wird dann stärker zum Koordinator, der das Big Picture und die Vision vorantreibt, der eher in Innovationen statt Evolutionen denkt und der Anforderungen (Achtung: Wunsch != Anforderung) noch besser herausarbeitet. In dem Zuge sind Akzeptanzkriterien zu nennen. Eines könnte lauten:

Wenn eine Rechnung abgeschlossen wird,

• dann lässt sie sich nicht mehr verändern
• dann wird sie automatisch an die Rechnungsabteilung geschickt
• dann wird die Marge es Auftrags berechnet

Zukunft des Entwicklers

Und zu guter Letzt kommen wir noch auf den Entwickler zu sprechen: Je weniger er in die Ausarbeitung von Anforderungen, fachlichen Lösungsansätzen und Modellierungen stecken muss, desto mehr Zeit kann er in gute Softwarearchitektur stecken. Und eine gute Architektur ist der Schlüssel für gute, adaptive und skalierbare Produkte. Die Grenze, wo die Aufgaben des Product Owners aufhören und die des Entwickler anfangen, ziehe ich an der Stelle, wo es einer entsprechenden Ausbildung bedarf – und sei es nur 1. Semester Informatik im Rahmen des BWL-Studiums. Ob der Datentyp Integer werden soll oder ob eine Enum die bessere Wahl für eine Auswahlliste ist, das entscheidet der Entwickler. Bei Fragen nach gültigen Wertebereichen, z.B. ob als Gewicht für einen Artikel 0 Kg zulässig sind, das kann der Produktverantwortliche mit steigender Kompetenz früher oder später gleich mitgeben. Hier bedarf es aber immer der sorgfältigen Prüfung des Entwicklers, dem sich solche Fragen naturgemäß eher erschließen. Hingegen ist der Product Owner immer für das Entwerfen der fachlichen Lösungsansätze verantwortlich, denn nur er hat den Überblick über den Geschäftsprozess und wie dieser mit anderen Prozessen interagiert. Für ein konkretes Beispiel kannst du diesen Beitrag lesen.

Fazit/Vision

Anwender sollte man in den Produktentwicklungsprozess einbinden. Mit steigender Erfahrung können sie mehr Aufgaben übernehmen und helfen, die Entwicklung zu beschleunigen und das Produkt noch besser zu machen. Transparenz, größere Akzeptanz, besseres Verständnis und die Reduzierung von Inselwissen sind nur einige wichtige Nebeneffekte. Ein Feature, sei es noch so gut, welches aufgrund von Ablehnung nicht genutzt wird, ist wertlos. Ein Prozess, egal wie gut durchdacht er ist, um den aber herumgearbeitet wird, produziert mehr Probleme als dass er löst.

Im Gegenzug kann der Produktverantwortliche mehr Zeit in Innovationen und bessere Anforderungen stecken, die zu besserer Softwarearchitektur und niedrigeren Entwicklungskosten führen. Das Ergebnis ist eine schnellere Entwicklung eines passgenaueren Produkts mit weniger Fehlern und höherer Qualität.

Der Entwickler wiederrum kann sich auf eine solide Infrastruktur konzentrieren, die zum Einen schnelle und einfache Anpassungen ermöglicht, zum Anderen entsteht Zeit für das Automatisieren von regelmäßigen Abläufen. Durch automatisierte Tests (durch gute Akzeptanzkriterien) lässt sich das Gros der Arbeit der Tester übernehmen (siehe Rolle in der Grafik oben). Ein Continuous Deployment System macht händisches Deployment überflüssig. Trainings reduzieren sich auf ein Minimum, weil die Fachabteilung von Anfang an in die Prozessumsetzung eingebunden wurde.

Wie haltet ihr das bei euch? Schreibt mir eure Erfahrungen in die Kommentare. Wie weit die Transformation bei heco fortgeschritten ist, erzähle ich in diesem Beitrag (Link folgt noch).

WordPress, TYPO3 CMS, TYPO3 NEOS – Anforderungen an ein gutes Content Management System

Die Anforderungsanalyse ist das A und O in Entscheidungsprozessen über Software-Systeme. In einem Praxisbeispiel zeige ich euch unser Ergebnis bei der Auswahl des neuen Content Management Systems. Dabei erkläre ich, was funktionale und nicht-funktionale Anforderungen sind, mit welchen Prioritäten wir diese unterscheiden und nenne Do’s & Don’ts von evaluierbaren Anforderungen.

Durch Klicken auf das Bild geht es zum YouTube Video

Webseiten Baukästen können teuer werden

Oder doch nicht? Das könnt ihr erst bewerten, wenn ihr ein Mindestmaß an Hirnschmalz reingesteckt habt. Gerade kleine und mittelständische Unternehmen (KMUs), die vielleicht auch nur wenige Produkte im Portfolio haben, gehen zu schnell an die Umsetzung und verbrennen dadurch mehr Geld als notwendig. In dem Video gebe anhand eines Praxisbeispieles ein paar Fragen mit, die ihr euch stellen könnt. Das sind z.B.

• Anbindung bestehender Systeme (ERP zur Bestandsanzeige)
• Mehrsprachigkeit
• Tracking
• Google-Optimierung
• Online Shopping
• Kundengruppen / Personas
• Inhaltstypen (Text, Bild, Tabellen, Videos, interaktive Elemente)
• Redakteure bzw. wer pflegt die Inhalte
• Wie oft ändern sich die Inhalte
• Mobile-Optimierung
• und einige mehr

Das Video soll euch nur ein paar anfängliche Ideen geben. Es gibt noch viele weitere Punkte und am Ende steht eine Anforderungsanalyse wie >hier< (Link folgt später).

Durch Klicken auf das Bild geht es zum Video