Archiv der Kategorie: CIO Topics

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?

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?

Advertisements

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

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).

Wenn es ein bisschen mehr sein darf – Zusatzleistungen für IT-ler

Die Karrierebibel nennt in ihrem Beitrag die Top 10 Benefits der Arbeitgeber. Erwartungsgemäß sind flexible Arbeitszeiten und Home Office ganz oben. Der Firmenwagen rangiert hingegen nur noch auf Platz 6.

Neben diesen – in der Regel bekannten und häufig angebotenen – Zusatzleistungen würde ich gerne wissen, was euch abseits vom Mainstream reizen würde. Dazu ein paar Gedanken meinerseits:

  • Eine Putzfrau für die eigene Wohnung
  • 2 extra Urlaubstage nach 10-jähriger Firmenzugehörigkeit (z.B. 32 statt 30)
  • Zusatzkrankenversicherung (z.B. für Heilpraktiker, Zähne oder Brillen)
  • Freistellung und Übernahme der Kosten für eure Fachvorträge, Community Touren oder Vorlesungen (sprich ihr betätigt euch nebenher als Referent und die Firma unterstützt euch voll dabei)
  • Regelmäßige Firmenausflüge (z.B. mal an den Bodensee)
  • Jahresticket für den Nahverkehr (dann kann es freitags direkt zum TGIF-Bierchen gehen)
  • Provision bei Vermittlung von Kunden oder neuen Mitarbeitern (bringt allen etwas)
  • Übernahme der Kosten fürs Fitnessstudio
  • Home Office Ausstattung (abseits vom Mainstream z.B. höhenverstellbare Schreibtische oder W-LAN Router)
  • Kindle / Tablet
  • Unterstützung beim Hobby (beim Marathon-Läufer z.B. Laufschuhe, Startgebühr und Shirt)
  • Kostenfreie Getränke
  • Tischkicker
  • Mitnahme von Urlaub ins Folgejahr
  • Auszahlung Urlaubstage

Ich bin gespannt, was euch einfällt. In ein paar Tagen will ich mit den Vorschlägen eine Umfrage über Facebook / Twitter starten, um zu schauen, welche davon vielleicht bei uns zum Einsatz kommen sollten.

In meinem vorherigen Beitrag habe ich zur Diskussion über die Anforderungen an ein modernes Büro angeregt.

Was IT-ler von einem modernen Büro erwarten

Welche Anforderungen habt ihr als IT-ler an eure Büros?

Schreibt mir in die Kommentare was immer euch wichtig ist. Besonders interessiert mich wie wichtig die Location für euch ist.

  • Wollt ihr z.B. keinesfalls in einem Großraumbüro arbeiten?
  • Ist euch eine gute S-Bahn-Anbindung wichtig?
  • Sollten feste Parkplätze bereitgestellt werden, damit ihr euch die morgendliche Suche spart?
  • Sind dedizierte Rückzugsräume wichtig?
  • Muss es Mitten in der City sein, damit ihr direkt nach der Arbeit z.B. ins Fitnessstudio oder in der Mittagspause zum Veganer um die Ecke gehen könnt?
  • Was sind akzeptable Fahrzeiten zum Büro? 15 Minuten ja, 30 Minuten nein?
  • Wäre euch der Stadtrand lieber, sodass ihr etwas Grün vor dem Fenster habt? Eventuell mit Balkon?
  • Oder eher ein nahe gelegener Vorort, wohin es sich bequem mit dem Auto (ohne zig Ampeln) fahren lässt?
  • Ist eine Einbauküche Pflicht?
  • Wäre eine Dusche hilfreich, damit ihr morgens zum Büro joggen oder mit dem Fahrrad fahren könnt?
  • Wie sehr beeinflusst die Location eure Entscheidung bei der Arbeitgeberwahl?

Das meinen vier IT-ler aus Karlsruhe:

  • Also ich würde Arbeitgeber im Umkreis von 15 Minuten vom Stadtzentrum gut finden. Die Location fließt zu 1/3 in meine Auswahl ein.
  • Ich denke die Örtlichkeit ist schon recht wichtig. Eine weite Fahrstrecke will keiner auf sich nehmen, da muss es schon ein Bomben-Job sein, dass man länger als 30min Fahrzeit in Kauf nimmt. Ich weiß wovon ich rede ich fahre momentan jeden morgen 35 Minuten nach Walldorf. Job und Team passen aber, von daher mache ich es auch. Außerdem müssen sich auch die Spritkosten rechnen. Ist also schon eine Überlegung. Ich würde kein Office zu weit in der Pampa suchen.
  • Mit viel Raum zum Atmen, Großraum Büros aber überall auch Rückzugsmöglichkeiten zum Tele/Skype. Ich kann dir nur sagen, dass es im agilen Umfeld mega wichtig ist, wenn es keine Wände zwischen Teamkollegen und dem Teamspace gibt.
  • ich mag es auch gerne außerhalb, wenn man gut mit dem Auto hinkommt, auf dem Weg nicht im Stau steht und einen Parkplatz bekommt. Der Stau lässt sich ja durch Gleitzeit umgehen[…]. Für mich wäre z.B. ein Büro in der Innenstadt ohne Parkplatz eher ein NoGo.

Im nächsten Beitrag werde ich nach den Benefits fragen, die euch ein Arbeitgeber bieten muss. Was haltet ihr z.B. von 2 extra Urlaubstagen nach 10 Jahren Firmenzugehörigkeit? Oder einer vom Arbeitgeber gesponserten Putzfrau? Hier könnt ihr eure Meinung posten.

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

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).

Hier geht es zum YouTube Video.

Durch Klicken auf das Bild geht es zum Video

Ist guter Programmcode noch wirtschaftlich

Eine Session am vergangenen .NET Open Space behandelte das Thema Wirtschaftlichkeit. Konkret stellte der Session Hoster an die Teilnehmer die Frage:

Ist es für euch wichtiger die Implementierung technisch möglichst elegant zu machen oder steht die Wirtschaftlichkeit an erster Stelle?

Ich sehe darin 3 mögliche Antworten:

  • Gerade durch die technische Eleganz steigt die Wirtschaftlichkeit, z.B. weil das Produkt bessere Performance als Konkurrenzprodukte hat.
  • Beides steht im Einklang. Würde für die Implementierung nicht die notwendige Sorgfalt aufgewendet werden, müsste das Produkt früher oder später recycelt und gänzlich neu entwickelt werden.
  • Die Wirtschaftlichkeit in Form von Manntagen zum Zwecke einer „besseren“ Umsetzung wird vermindert.

Speziell zu letztem Punkt habe ich eine ganz eigene Einstellung, zu welchem ich gerne eure Meinung hören würde. Meines Erachtens gilt es nämlich zuerst ganz andere Stellen im Produktenwicklungsprozess zu optimieren. Hierzu einige Beispiele aus meiner Praxiserfahrung:

  • Es werden Anforderungen aufgenommen, welche keinen Nutzen bringen. Diesen kommt man recht einfach auf die Schliche, indem man dem Verantwortlichen 5x die Frage ‚Warum‘ stellt. Ich schätze, dass zw. 5-10% der Anforderungen, die von den Fachabteilungen eingebracht und umgesetzt werden, keinen praktischen Nutzen erfüllen.
  • Die Priorisierung von Feature-Wünschen ist nicht gemäß deren Business Values. Wenn nicht die Dinge zuerst implementiert werden, die den höchsten Nutzen bringen und dabei das niedrigste Risiko und den geringsten Aufwand aufweisen, dann leidet die Wirtschaftlichkeit (Ausnahme: Bei einem neuen Produkte sollten die mit dem höchsten Risiko zuerst umgesetzt werden).
  • Es werden mehr neue Anforderungen aufgenommen, als umgesetzt werden können. Wenn in einem Jahr 200 Einträge im Issue Tracking System aufschlagen, aber nur 100 umgesetzt werden können, dann wurde definitiv Geld in Form von Arbeitszeit verbraten.
  • Es wird nicht die notwendige Sorgfalt in die Ausarbeitung von Anforderungen gesteckt. In einem Pluralsight Video bin ich kürzlich auf die Aussage gestoßen, dass 50-70% der Entwicklungskosten auf schlechte/falsche Anforderungen zurückzuführen sind.
  • Bei manchen Anforderungen kann erheblich viel Entwicklungszeit eingespart werden, wenn bestimmte Aspekte, auf die auch der Anwender verzichten kann, weggelassen werden. Hierbei sind die Entwickler gefragt, nachzuhaken, ob sich das Feature eventuell an der ein oder anderen Stelle reduzieren lässt.
  • Kommunikation: Der Wert einer guten Kommunikation lässt nicht beziffern.
  • Automatisierte Prozesse für sich wiederholende Aufgaben, z.B. Continuous Deployment. Das spart täglich Geld!

Das sind nur ein paar Punkte, bei denen ich als erstes Hand anlegen würde! Wie seht ihr das?

%d Bloggern gefällt das: