Bei unserer internen Organisation dreht sich alles um ein Thema: Ownership!

Darum haben wir ein eigene Organisationsform und ein eigenes Rollenbild etabliert, das unserem Selbstverständnis sowie unserem Selbst- und Fremdbild gerecht wird.

Unsere Organisation

Unsere eigene Organisation spiegelt unser Ownership-Prinzip wider. Wir denken hier abseits der klassischen Rollenbilder und Strukturen, da unser Verständnis über die Grenzen der klassischen IT-Rollen hinaus gehen.

Dies lässt sich am besten mit folgendem Bild veranschaulichen:

Firmenorganisation

Organisation innerhalb unserer Teams

Unser Firmenorganisation besteht aus drei verschiedenen Rollen, welche jeweils die Verantwortung für die drei wichtigsten Bereiche unseres Unternehmens übernehmen:

• Unsere Unternehmensführung (Company Owner)
• Unsere interne Organisation (Office Owner)
• Unsere operativen Teams (Team Owner)

Company Owner

Wir verstehen die Rolle des “Company Owner” nicht unbedingt als rechtlichen Eigentümer des Unternehmens, sondern definieren so unsere Geschäftsführung. Für uns geht es dabei darum, dass man als Teil der Geschäftsführung die PDC so behandelt, als wäre sie sein Baby.

Fairerweise muss man sagen, dass wir uns hier sehr leicht tun: Die aktuellen Geschäftsführer sind auch zeitgleich die Eigentümer der PDC.

Office Owner

Jedes Unternehmen hat eine gute Seele, die das Büro am Laufen hält. Die Rolle ist in jedem Unternehmen ein wenig anders definiert: Von Office Manager über PMO bis hin zum Sekretariat. Wir nennen diese Rolle „Office Owner“ – diese wird bei uns mit so viel Freude und Leidenschaft ausgefüllt, als wäre das Büro Teil der eigenen vier Wände.

Details zu den einzelnen Rollen findest du hier:

• Project Owner
• Product Owner
• Service Owner
• System Owner
• Software Owner
• Quality Owner
• Support Owner

Mehr als nur ein Project Manager!

Klassische Project Manager haben die Aufgabe, ein Projekt zu planen, zu organisieren und zu steuern sowie das Bindeglied zwischen Kunde und interner Organisation zu sein. Das funktioniert prinzipiell, doch zumeist verliert der Project Manager dadurch stark an Berührungspunkten mit den echten Zielen und Inhalten des Projekts.

Für uns steht das Ziel des Kunden und damit das Projektergebnis immer an ersten Stelle. Unsere Project Manager “managen” daher nicht nur das Projekt, sondern behandeln es wie ihr Baby – daher heißt die Rolle bei uns auch „Project Owner“.

Welche Aufgaben hat ein Project Owner bei uns?

• Sieht das Projekt sowohl intern als auch extern stets durch die Kundenbrille und fühlt sich persönlich verantwortlich für das zu liefernde, inhaltliche Ergebnis
• Hinterfragt aktiv die Hintergründe und Zielsetzungen, also das “Warum” des Projekts
• Erkennt aktiv Verbesserungsmöglichkeiten beim Projekt (z.B. durch Anpassung der Zielsetzung), da er das Projekt aus Kundensicht betrachtet und sich auch mit den Inhalten befasst
• Stellt nicht nur sicher, dass das Projekt “on track” ist, sondern hinterfragt regelmäßig, ob der Weg auch der richtige ist
• Agiert als Bindeglied zwischen verschiedenen internen und externen Stakeholdern
• Bedient zugleich die klassische PM-Aspekte wie Controlling, Reporting oder Risikomanagement

Was bedeutet das in der Praxis?

In der Praxis stehen unsere Project Owner nicht über dem Projekt, sondern sind ein aktiver, mitarbeitender Bestandteil des Projekts. Es ist bei uns nicht unüblich, dass ein Project Owner bspw.

• Bugs in der zu entwickelnden Software einmeldet, da er selbst das System testet, nachdem Features fertiggestellt worden sind,
• neue Anforderungen ausformuliert, da er im Gespräch mit dem Kunden auf einen entsprechenden Bedarf gestoßen ist,
• inhaltliche Workshops moderiert, da er selbst die Inhalte des Projekts sehr gut kennt oder
• aktiv die Architektur des Systems hinterfragt, da er selbst verstehen möchte, wie die Software grundsätzlich funktioniert.

Durch diese Einstellung handeln Project Owner weit außerhalb der Grenzen üblicher Project Manager und sorgen durch ihr interdisziplinäres Denken und Handeln implizit für höhere Qualität.

Mehr als nur ein Business-Analyst!

Die Aufgabe eines Business-Analysten, im klassischen IT-Rollenverständnis, ist es Kundenwünsche zu verstehen und in Anforderungen sowie Spezifikationen umzuwandeln. Business-Analysten sprechen dabei fließend die Kundensprache und können diese in Anforderungen übersetzen, die das Team versteht und verarbeiten kann. Fehler in der Business-Analyse passieren dann, wenn der Kunde seine Ziele und Wünsche nicht klar formuliert, diese sich auf einmal ändern oder wenn die formulierten Anforderungen das Entwicklungsteam bereits in eine Richtung lenken, die langfristig der Software schadet (z.B. da der Wartungsaufwand sehr stark steigt).

Für uns ändert sich die Rolle, wenn man Ownership in den Vordergrund stellt: Unsere Business-Analysten beschränken sich nicht mehr auf die reine Analyse der „Business-Anforderungen“, sondern übernehmen Verantwortung für das Produkt, das daraus entsteht. Wir nennen diese Rolle daher auch „Product Owner“.

Welche Aufgaben hat ein Product Owner bei uns?

• Hinterfragt die Ziele hinter jedem Projekt und verinnerlicht diese, um die richtigen inhaltlichen Entscheidungen für das Projekt zu treffen
• Entwickelt, gestaltet und erfasst Anforderungen in enger Abstimmung mit dem Kunden
• Erweitert, erprobt und designt diese Anforderungen mit dem Entwicklungsteam
• Kennt somit die Anforderungen und die entwickelte Software wie seine Westentasche, weil diese für ihn persönlich wichtig ist
• Klärt Rückfragen der Entwickler und hinterfragt Lösungsansätze in der Software, um diese aktiv für die weiteren Anforderungen zu nutzen
• Ist der Erste, der fertige Funktionen sehen und testen will, da er ein persönliches Interesse daran hat, was “aus den Anforderungen geworden ist”

Was bedeutet das in der Praxis?

Unsere Product Owner brennen für die Software, die umgesetzt wird und fühlen sich persönlich verantwortlich für das zu liefernde Ergebnis. Sie wollen, dass die Ziele, die ein Kunde hat, mit der Software bestmöglich erreicht werden und tun alles dafür, um diesem Anspruch gerecht zu werden, womit sie weit über die klassische Analysten-Rolle hinausgehen. Bei uns ist es zum Beispiel durchaus üblich, dass

• Kunden den Product Owner um dessen Einschätzung bitten, da sie den betroffenen Geschäftsprozess inzwischen besser kennen als sie selbst,
• der Product Owner nicht nur die Software aus Anwendersicht, sondern auch die Architektur, die Logik und teils auch den Code dahinter verstehen möchte oder
• Entwickler den Product Owner um Feedback während der Entwicklung bitten. Sie wissen, dass der Product Owner ein sehr gutes “Gefühl” dafür hat, ob die Umsetzung für den Kunden passen wird oder nicht.

Gibt es einen Unterschied zwischen einem „PDC Product Owner“ und einem „Scrum Product Owner“?

Tatsächlich ist die Rolle des Product Owners in der PDC sehr ähnlich zur Definition nach Scrum. Dies hat einen guten Grund: Wer Scrum kennt weiß, dass ein Product Owner große Verantwortung trägt und nur dann erfolgreich sein kann, wenn ihm die Software bzw. das Ergebnis wirklich wichtig ist. Das ist auch unser Grundverständnis dieser Rolle.

Der große Unterschied besteht jedoch darin, dass bei uns die Rolle des Product Owners auch außerhalb von Scrum-Projekten besteht!

Mehr als nur ein Service Manager!

Im Rollenverständnis klassischer IT-Betriebe ist ein Service Manager für den Betrieb einer Software verantwortlich.

Er kümmert sich darum, dass die Software läuft und der Kunde im täglichen Betrieb nicht auf Probleme stößt. Diese Rolle ist wichtig, da durch Projekte, Deployments, Migrationen und sonstige außergewöhnliche Effekte die Software unter laufender Veränderung steht und deswegen der Betrieb der Software aktiv gesteuert werden muss. Service Manager haben oft eine eingeschränkte Sicht auf die Software. Ihr Fokus liegt mehr auf den Betriebsparametern (z.B. Antwortzeiten des Systems, Auslastung der Hardware, etc.) und weniger auf den inhaltlichen Funktionen der Software. Daher kann es sein, dass die Software zwar “gut läuft”, der Kunde aber trotzdem unzufrieden ist.

Wir haben daher ein gänzlich anderes Verständnis der Rolle und nennen diese “Service Owner”: Bei uns ist man nicht nur für den Betrieb des Systems verantwortlich, sondern für die Kundenzufriedenheit. Als Service Owner ist man de facto der wichtigste Feedbackmechanismus abseits des direkten Kundenfeedbacks, da der Service Owner sich selbst ebenfalls als Kunde der Software – sowohl im Hinblick auf die Betriebsparameter als auch auf die Funktionalität des Systems – sieht.

Welche Aufgaben hat ein Service Owner bei uns?

• Verantwortlich für die Kundenzufriedenheit im täglichen Betrieb des Systems und daher im ständigen Austausch mit dem Kunden
• Stellt sicher, dass neue Funktionen für den Kunden ein Wow-Erlebnis sind und die Kundenzufriedenheit dementsprechend erhöhen
• Ist oft in die Konzeption neuer Funktionen involviert und dient als interner Feedback-Mechanismus
• Verantwortlich für die Sicherstellung des ordentlichen Betriebs der Software sowie aller dazugehörigen Services (z.B. Support)
• Passt aktiv die Parameter des Betriebs (z.B. Hardware) an, soweit dies notwendig ist

Was bedeutet das in der Praxis?

In der Praxis sind unsere Service Owner die internen Vertreter unserer Kunden in Bezug auf den operativen Alltag des Systems. Ein Service Owner fühlt sich der Kundenzufriedenheit zutiefst verpflichtet und strebt danach, dass die Software Mehrwert für unsere Kunden generiert. Was bei unseren Service Ownern in der Praxis bspw. durchaus vorkommen kann, ist, dass:

• Service Owner sich aktiv Features wünschen, da sie wissen, dass diese von unseren Kunden dringend benötigt werden. Oftmals wissen die Service Owner dies, bevor es den Kunden selbst bewusst wird,
• Product Owner aktiv den Service Owner beim Verfeinern der Anforderungen ansprechen, da sie wissen, dass die Perspektive des Service Owners die Kundenperspektive ausgezeichnet ergänzt oder
• Service Owner das System so ausgezeichnet kennen, dass sie auch ohne Probleme in Projekten fachlich mitarbeiten können und dies in Einzelfällen auch tun.

Service Owner stellen durch ihren persönlichen Einsatz sicher, dass unsere Kunden auch nach einem erfolgreich abgeschlossenen Projekt weiterhin jeden Tag glücklich mit ihrem Produkt sind. Damit trägt der Service Owner dazu bei, dass die Software nicht nur ein kurzfristiges Problem löst, sondern auch langfristig eine wichtige Erfolgskomponente des Kundenunternehmens darstellt.

Mehr als nur ein IT-Architekt!

IT-Architekten sind im klassischen IT-Rollenbild für die Grundstruktur eines Systems verantwortlich. Sie konzipieren und designen die Komponenten des Systems, definieren den Datenfluss durch die Applikationen und stellen allgemeine Regeln für die Entwicklung auf. Üblicherweise sind IT-Architekten am Anfang eines Projekts sehr stark in der Konzeptionsphase involviert, jedoch kaum bei der eigentlichen Umsetzung des Konzepts. Diese Trennung funktioniert zwar prinzipiell, führt allerdings dazu, dass Lösungskonzepte im Rahmen der Umsetzung immer weniger hinterfragt werden und Software-Lösungen oft nicht mehr zu den sich weiterentwickelnden Projektzielen passen.

Unsere IT-Architekten sind nicht nur für die reine Konzeption zuständig, sondern übernehmen die Verantwortung für die langfristige Architektur des Systems. Sie behandeln das System dabei, als wäre es ihr Baby – daher heißt diese Rolle bei uns auch „System Owner“.

Welche Aufgaben hat ein System Owner bei uns?

• Die Lösung ist sein Baby – sie ist ihm persönlich wichtig und er behandelt sie mit entsprechender Eigenverantwortung
• Ist Teil des Anforderungsprozesses und versteht bzw. hinterfragt die Anforderungen und die Ziele des Projekts
• Kümmert sich nicht nur um das initiale Konzept, sondern begleitet das System über den ganzen Life-Cycle der Software hinweg (auch im späteren Betrieb)
• Unterstützt „hands-on“ beim Setup der Architektur und sorgt dafür, dass die Lösung ein stabiles Fundament bekommt
• Überprüft als Teil der Qualitätssicherung aktiv, ob die umgesetzte Architektur die Ziele des Projekts erfüllt
• Coacht und unterstützt das Entwicklungsteam bzw. lernt vom Feedback bei der Umsetzung der Architektur

Was bedeutet das in der Praxis?

Unsere System Owner sind nicht nur ein aktiver Bestandteil des Projekts, sondern begleiten die Software auch darüber hinaus in der Wartung. Sie kümmern sich daher nicht nur initial um den korrekten Aufbau des Systems, sondern stellen den langfristigen Nutzen sowie die adäquate Wartbarkeit sicher. Unser System Owner sieht sich folglich dafür mitverantwortlich, dass er:

• aktiv mit dem Kunden über Anforderungen diskutieren, um sicherzustellen, dass er die Ziele der Software vollumfassend verstanden hat,
• den Project Owner im Rahmen der Projektplanung unterstützt, damit sichergestellt wird, dass der Plan den Aufbau eines soliden Fundaments unterstützt,
• selbst am Anfang des Projekts beim Setup des Systems mitentwickelt, weil ihm die Umsetzung der Architektur wichtig ist,
• selbst einen Bug behebt, wenn die Übergabe an einen Entwickler aufwändiger wäre als das eigenständige Lösen oder
• von Entwicklern Feedback einholt, die er in seine nächsten Projekte oder die Verbesserung des aktuellen Systems einfließen lässt.

Durch die persönliche Verantwortung des System Owners über den ganzen Software-Life-Cycle hinweg wird sichergestellt, dass das Projekt nicht nur einen kurzfristigen Mehrwert bringt, sondern auf Jahre Stabilität garantiert.

Mehr als nur ein Software-Entwickler!

Im klassischen IT-Rollenbild haben Software-Entwickler die Aufgabe, Anforderungen umzusetzen und in funktionierende Features zu überführen. Ihr Fokus liegt dabei auf der Entwicklung: Sie geben nur Input bei der Erstellung der Anforderungen bzw. beim Testen der Software durch entsprechende Tester. Dies führt oft dazu, dass zwischen Kundenwunsch, Anforderung, Qualitätssicherung und umgesetzter Software Fehler entstehen, die erst sehr spät entdeckt werden. Generell gilt: Je später ein Fehler gefunden wird bzw. umso früher im Prozess der Fehler entsteht, desto teurer ist die Behebung.

Unsere Entwickler nehmen ihre Aufgabe anders als oben beschrieben wahr – sie sehen sich nicht als reine Entwickler, sondern fühlen sich persönlich für die Software verantwortlich. Wir nennen sie deswegen „Software Owner“.

Welche Aufgaben hat ein Software Owner bei uns?

• Sieht die Lösung, ähnlich wie der System Owner, als sein Baby an und entwickelt diese mit entsprechender Eigenverantwortung weiter
• Involviert sich aktiv in den Anforderungsprozess, um die Anforderungen aktiv mitzugestalten, statt sie nur vorgegeben zu bekommen und einfach nach zu programmieren
• Ist an vorderster Front auch Teil der Qualitätssicherung, da er die durch ihn umgesetzten Features gründlich auf einer praxisnahen Umgebung testet, bevor jemand anderer das Ergebnis sieht
• Hinterfragt die Nutzung des Systems, am besten mit den tatsächlichen Nutzern, damit das System optimal auf die zukünftigen Bedürfnisse zugeschnitten werden kann
• Gestaltet die Lösungsarchitektur als Teil der Konzeption aktiv mit und versteht, warum die Architektur in der gegebenen Form für das Projekt passend ist

Was bedeutet das in der Praxis?

Unsere Software Owner sind nicht nur reine Entwickler. Ihr Aufgabengebiet beginnt viel früher und endet viel später: Sie unterstützen z.B. bei der Anforderungsdefinition, um suboptimale Lösungen zu vermeiden und sichern die Qualität durch entsprechendes Testing der eigenen Umsetzungen. Bei uns ist es selbstverständlich, dass ein Software Owner bspw.:

• selbst Anforderungen an das System definiert, weil er Kundenwünsche antizipiert und entsprechende Features umsetzt,
• proaktiv seine eigenen Ergebnisse prüft und auch kritisch hinterfragt, ob man gewisse Strukturen “aufräumen” sollte,
• Bugs erfasst, da er hat ein Problem entdeckt hat, das er derzeit selbst nicht lösen kann; anstatt es zu ignorieren, erfasst er das Problem und geht damit aktiv auf den Kunden zu oder
• sich über Anforderungen echauffiert, die aus seiner Sicht für den Nutzer nicht sinnvoll sind – durch dieses Feedback stößt er eine weitere Feedbackschleife mit dem Kunden an und verhindert unnötigen Aufwand.

Klarerweise besteht die Hauptaufgabe eines Software Owners darin, das angeforderte System umzusetzen, jedoch tun sie das nicht mit aufgesetzten Scheuklappen, sondern involvieren sich aktiv in die umliegenden Rollen und Aufgabengebiete, weil ihnen das Gesamtergebnis wichtig ist.

Mehr als nur ein Test-Manager!

Viele der heutigen IT-Unternehmen beschäftigen Test-Manager (bzw. Tester), um die Qualität ihrer Software-Projekte zu sichern. Im klassischen Verständnis erarbeiten diese Rollen Testkonzepte basierend auf der Projektzielsetzung, definieren Testfälle aufgrund der Spezifikationen, führen besagte Testfälle aus, sobald das System dazu bereit ist und erfassen Bugs, wenn Abweichungen zwischen den Anforderungen und der Umsetzung existieren. In der Praxis kommt es allerdings oft vor, dass ein Qualitätsmangel aus Kundensicht nicht aufgrund einer fehlerhaft implementierten Funktion entsteht, sondern bereits die Spezifikation mangelhaft ist und nicht das Problem des Kunden löst. Dies kann in der klassischen Rolle eines Test-Managers kaum abgefangen werden.

Bei uns wird die Rolle des Test-Managers daher breiter gesehen – wir sprechen von „Quality Ownern“. Für uns beschränkt sich die Verantwortung der Quality Owner bewusst nicht auf die Planung und Durchführung von Tests, sondern umfasst die gesamte Qualität des Systems aus Kundensicht. Das qualitative Anspruch eines Quality Owners ist, dass das System die Erwartungen des Kunden vollumfänglich erfüllt.

Welche Aufgaben hat ein Quality Owner bei uns?

• Baut ein tiefes Verständnis für den Sinn und Zweck des Systems auf und weiß daher genau, welche Funktionen das System umfasst
• Hinterfragt aktiv Funktionen, die aus seiner Sicht nicht dem Zweck des Systems dienen, damit diese erst gar nicht umgesetzt werden, wenn sie keinen Mehrwert generieren
• Versteht den Aufbau des Systems, sodass er jene Stellen erkennt, an denen es wiederholt zu Problemen kommen kann
• Leitet aus diesen Gegebenheiten die richtigen Testfälle für das System ab und kümmert sich anschließend um die Testdurchführung
• Beleuchtet die Ursache von Problemen, damit er besser versteht, wie es zu diesen gekommen ist – daher steht er auch im regelmäßigen Austausch mit den Entwicklern

Was bedeutet das in der Praxis?

Natürlich definieren unsere Quality Owner genauso Testfälle und führen diese durch, wie es ein klassischer Tester tut. Der Unterschied liegt allerdings darin, dass ein Quality Owner proaktiv die „wahre Qualität“ – nämlich den Mehrwert des Systems aus Kundensicht – bereits in der Anforderungsdefinition mitbeeinflusst. In der Praxis bedeutet das für den Quality Owner zum Beispiel, dass er:

• Unstimmigkeiten in der Software (z.B. Funktionen, die sich zwar ähnlich, aber nicht gleich aufgebaut sind) aufzeigt, die technisch gesehen keine Fehler sind, aber dem Mehrwert des Systems aus Kundensicht schadet,
• proaktiv die Entwicklung verstehen möchte und sich dafür auch den Code hinter den Funktionen erklären lässt oder
• selbst einen direkten Draht zum Kunden hat, wodurch er ein vollumfängliches Verständnis für dessen Bedürfnisse aufbaut.

Bei Software-Projekten definiert sich Qualität nicht durch die genaue, fehlerfreien Umsetzung der Spezifikationen, sondern durch den realen Mehrwert, den ein Kunde durch die Erfüllung seiner Ziele erhält – darum steht dieser Aspekt bei unseren Quality Ownern im Mittelpunkt und treibt sie an.

Mehr als nur ein Support-Mitarbeiter!

Je komplexer eine Software ist, desto mehr Unterstützung benötigen deren Nutzer beim täglichen Umgang damit. Im klassischen IT-Rollenverständnis ist hierfür der IT-Support bzw. ein IT-Support-Mitarbeiter zuständig. Dieser nimmt Tickets entgegen und kümmern sich darum, dass die darin erwähnten Probleme gelöst werden oder helfen den Usern dabei, die Probleme selbst zu lösen.

Der Fokus von Support-Mitarbeitern liegt dabei meist auf der Behebung eines konkreten Problems. Wir sind allerdings davon überzeugt, dass jedes Problem eine Ursache hat und nur das Ausmerzen dieser Ursache dafür sorgt, dass ähnliche Probleme nicht mehr auftreten. Bei unseren Support-Mitarbeitern ist dies das Natürlichste auf der Welt. Sie sehen sich daher nicht als normaler IT-Support, sondern als „Support Owner“ und haben ein klares Ziel: Sie möchten, dass die Nutzer das System bestmöglich und ohne Unterstützung nutzen können. Im Prinzip ist unser IT-Support dann zufrieden, wenn er nicht benötigt wird.

Welche Aufgaben hat ein Support Owner bei uns?

• Kennt das System in- und auswendig und kann unsere Kunden bei der korrekten Handhabung beraten und unterstützen
• Kümmert sich um die Anliegen unserer Kunden, wenn es um die tägliche Nutzung eines Systems geht
• Fokussiert sich bei der Lösung eines Problems nicht nur auf die Symptombekämpfung, sondern hauptsächlich auf die Ursache
• Trägt Ursachen, die er nicht selbst lösen kann, mit entsprechender Priorität zu unseren Service und Product Ownern, damit Bewusstsein für das Problem entsteht und dieses gelöst wird
• Priorisiert zwischen unterschiedlichen Supportfällen, da ihm bewusst ist, welche Themen den Kunden am stärksten beeinträchtigen.

Was bedeutet das in der Praxis?

Unsere Support Owner sind nicht nur reine Ticket-Verwalter – sie sind die aktive, helfende Hand und der erste Ansprechpartner für die Nutzer des Systems. Sie fühlen sich den Nutzern verpflichtet und wollen um jeden Preis helfen, indem sie an der Verbesserung der Software teilhaben. In der Praxis bedeutet das zum Beispiel, dass ein Support Owner bei uns:

• Anforderungen an das System definiert, da er die Nutzer der Software am besten kennt und weiß, wie man ihnen das Leben erleichtern könnte,
• selbst Hand anlegt und Probleme behebt, falls dies für ihn technisch möglich ist oder
• eine enge Beziehung zu den Power-Usern des Systems aufbaut und pflegt, da persönliches, gemeinsames Interesse am System besteht.

Die Rolle des Support Owners lässt sich in zwei Sätzen gut zusammenfassen: Support Owner sind dann zufrieden, wenn Nutzer das System eigenständig nutzen können. Nutzer sind im Gegenzug dann zufrieden, wenn sie trotz eines guten Systems einen Support Owner haben, der ihnen mit Rat und Tat zur Seite steht.