Softwareentwicklung – Organisation nach Schnittstellen im Unternehmen

onOffice wächst seit Jahren sehr konstant. Auch der Bereich der Softwareentwicklung und die IT-Bereiche insgesamt sind über die Jahre stetig größer geworden. Durch das Wachstum entsteht immer wieder der Bedarf, die Struktur oder Organisation der Teams zu ändern. Als das IT-Team noch sehr klein war, war es normal, dass jeder Mitarbeiter mehrere Aufgaben hatte. Große Weiterentwicklungsprojekte waren oft nur schwer umzusetzen, weil die Entwicklung immer wieder für Supportfälle und Bugreports aus der Arbeit gerissen wurde.

Erste Aufteilung in Teams

Aus dieser Erfahrung heraus haben wir schon sehr früh den Bereich der Softwareentwickler in zwei Teams aufgeteilt und diese Team “Product” und Team “Customer” genannt. “Product” war für Weiterentwicklungsprojekte zuständig, der Bereich “Customer” sollte alles umsetzen, was aus Kundensicht zeitkritisch ist (Bugreports, Datenimporte, etc.). Diese Aufteilung haben wir jedoch nach 2-3 Jahren wieder aufgehoben, da das Gefühl einer Zweiklassengesellschaft entstand. Das Customer-Team war nur noch dafür zuständig, so schnell wie möglich Brände zu löschen. Alle Arbeiten, die länger als 1-2 Stunden dauerten, wurden an das Product-Team übergeben und hatten dort oft keine Chance auf Umsetzung, da die Feature-Weiterentwicklung Vorrang hatte.

Die Teamaufteilung der Softwareentwicklung hat sich immer wieder geändert – trotzdem blieb es bislang eine Abteilung. Über das vergangene Jahr haben wir jedoch gemerkt, dass die Softwareentwicklung mit knapp 50 Mitarbeitern zu groß wurde und wir zu viele verschiedene Tätigkeiten, Schnittstellen und Projektarten unter einen Hut steckten.

Genaue Betrachtung der Arbeitsbereiche

Es entstand die Idee, die vorhandenen Schnittstellen zu betrachten. Dabei war der DevOps-Gedanke, Teamgrenzen anhand von Conway’s Law festzulegen, im Hinterkopf.

• Wir erhalten in der Entwicklung Bug-Reports von Kunden über unseren Support.
• Uns arbeiten Produktmanager zu, die uns mit Projekten zur Weiterentwicklung der Software versorgen und damit Kunden, Support, Vertrieb und die Geschäftsleitung vertreten.
• Wir führen Refactoring und Performance-Optimierungen durch, versorgen uns selbst mit Aufgaben und sind unsere eigene Schnittstelle.
• Die Abteilung zur Durchführung der Datenimporte wünscht sich immer wieder Anpassungen am selbst entwickelten Import-Tool.
• Und zu guter letzt gibt es auch noch Anpassungen zur Verbesserung der Sicherheit unserer Software, die durch Entwickler oder unseren IT-Sicherheitsbeautragten angestoßen werden.

Gerade den Bereich, in dem aus der Entwicklung heraus selbst Änderungen angestoßen werden, haben wir schnell als verbesserungswürdig angesehen. Mit dem Ziel, möglichst klare, einheitliche Abläufe zu etablieren, liefen diese Anpassungsideen auch immer eine Schleife über unser Produktmanagement. Der Produktmanager, der eigentlich ein neues Modul plante und betreute, wurde aus seiner Arbeit gerissen und musste sich mit einem Bugreport und der daraus resultierenden Verbesserungsidee beschäftigen. Hier konkurrierten also zwei sehr unterschiedliche Themen – die Weiterentwicklung, sowie die Wartung und Pflege der Software.

Sinnvollere Teilung der Teams

Um für jeden der oben genannten Bereiche ein eigenes Entwicklerteam zu gründen, sind wir (noch) zu klein. Im ersten Schritt haben wir uns aber dafür entschieden, den Bereich zur Umsetzung der Weiterentwicklungsprojekte aus dem Produktmanagement von den restlichen Schnittstellen zu trennen. Die erste Abteilung nennen wir jetzt “Product Development”, der zweite Bereich ist “TecOps”. 

Kurz nachdem wir die Idee zur Aufteilung der Abteilung Softwareentwicklung in diese zwei Bereich hatten, bin ich über einen Artikel von Stefan Priebsch gestolpert, in dem eine ähnliche Aufteilung, wie von uns vorgenommen, mit einem anderen Hintergrund angesprochen wird. Er beschreibt darin, dass in der Softwareentwicklung oft nicht zwischen der eigentlichen Weiterentwicklung und der Wartung/Pflege eines Softwareproduktes unterschieden wird und daher Mitarbeiter mit falschen Erwartungen eingestellt werden bzw. später nicht das machen, was in Stellenanzeigen und Vorstellungsgesprächen versprochen wird.

Optimierung und Verfeinerung der Softwareentwicklung

Dieser Gedanke entspricht (zum Teil) unserem Schnittstellengedanken. Der Bereich Product Development hat die klare Aufgabe, die Software weiterzuentwickeln. Der Bereich TecOps führt Refactorings durch, behebt Bugs, erhöht die Performance – Wartungsaufgaben eben. Durch den Artikel und weitere Diskussionen kamen wir darauf, dass wir so auch noch ein weiteres Problem lösen können, das über die Jahre nach und nach entstanden ist. Bisher wurden Anpassungswünsche immer über unser Produktmanagement gesteuert. Hat ein Entwickler durch Bugreports festgestellt, dass kein klarer Programmierfehler vorliegt, sondern die Software an der entsprechenden Stelle unverständlich oder missverständlich ist, wurde ein Anpassungswunsch festgehalten. Diese Anpassungswünsche verlieren in der Priorisierung häufig gegen die Weiterentwicklungsprojekte (Wartung gegen Entwicklung).

Fazit

Wir lassen jetzt diese Verbesserungen, die aus Bugreports abgeleitet werden, vollständig im neuen TecOps-Bereich durchführen, inkl. Priorisierung / Planung – ein weiterer Schritt zur Trennung von Entwicklung und Wartung unserer Softwareprodukte.

Somit haben wir jetzt zwei getrennte Bereiche, die Softwareentwicklung betreiben –  mit unterschiedlichen Schnittstellen und unterschiedlichem Fokus.