Serie: Wie man die Architekturabteilung tötet Teil 4

Teil 4: Der leitende technische Product Owner

In Teil 3 dieser Serie hat Herbert die Rolle des technischen Product Owners als Gegenstück zum (funktionalen) Product Owner vorgestellt. Bevor Product Owner und Technical Product Owner mit ihrer Arbeit beginnen können, müssen von der Unternehmensleitung Prioritäten auf höchster Ebene festgelegt werden. In diesem Beitrag wird der Chief Technical Product Owner vorgestellt. Er vertritt die technische Perspektive in dieser Phase der Prioritätensetzung auf hoher Ebene.

Den Dingen Prioritäten geben

In einem typischen Unternehmen gibt es viele Anfragen für neue Funktionen. In der Regel übersteigt die Anzahl der Anfragen die Realisierungskapazität bei weitem. Daher müssen bereits in einem frühen Stadium des Prozesses Auswahlentscheidungen getroffen werden. Die Funktionalitäten können in der Reihenfolge ihrer Priorität ausgewählt werden. Und die Priorität ergibt sich aus dem erwarteten Geschäftswert, den relativen Kosten und der Durchführbarkeit. In einem frühen Stadium des Prozesses ist es schwierig, den Aufwand für die Realisierung abzuschätzen. Zu diesem Zeitpunkt ist eine funktionale Anforderung in der Regel noch nicht analysiert, detailliert oder genau festgelegt worden. Eine niedrige Schätzung gibt dem Geschäftsinhaber einen Blankoscheck, um die User Story später so zu gestalten, dass sie teurer ist als ursprünglich geschätzt. Sie können sich auf die ursprüngliche niedrige Schätzung berufen, wenn die IT-Abteilung "nein" sagt. Ein hoher Kostenvoranschlag kann dazu führen, dass die Funktion nie in Angriff genommen wird. Der Geschäftseigentümer kann sich nach externen Parteien umsehen, um die Funktionalität ohne Beteiligung der IT-Abteilung zu realisieren. Infolgedessen kommt es zu noch schlimmeren architektonischen Inkompatibilitäten. In dem im ersten Beitrag skizzierten agilen Organisationsmodell gibt es eine Phase, die für die Priorisierung von Funktionen vorgesehen ist. Die Priorisierung wird größtenteils von den Geschäftsmanagern vorgenommen. Viele Business Manager haben keine Ahnung von Technik. Sie können den technischen Umfang einer Story nicht einschätzen. Einige funktionale Anforderungen hängen von größeren technischen Änderungen ab. Für Menschen mit einem technischen Hintergrund scheint es schwierig zu sein, Geschäftsmanagern den Wert solcher technischen Änderungen zu erklären. Vor allem, wenn Sie mit dem oberen Management sprechen. An dieser Stelle kommt der Chief Technical Product Owner (CTPO) ins Spiel.

Der leitende technische Product Owner

Der Chief Technical Product Owner ist ein spezialisierter technischer Product Owner, der sich durch politisches Feingefühl und die Fähigkeit, mit dem oberen Management zu kommunizieren und zu verhandeln, von den anderen abhebt. Er hilft dem Unternehmen bei der Entscheidung, welche Funktionalitäten in welcher Reihenfolge aufgenommen werden sollten und wie die nichtfunktionalen Eigenschaften des Systems verbessert werden können. In einer idealen Welt sollten Stories strikt nach dem Geschäftswert priorisiert werden. In der realen Welt gibt es jedoch praktische und technische Hürden wie Altsysteme und technische Schulden zu überwinden. Manchmal muss zuerst eine technische Änderung vorgenommen werden, um eine Reihe von User Stories effektiv aufgreifen zu können.Der Chief Technical Product Owner unterscheidet sich vom Technical Product Owner dadurch, dass er sich mehr auf das Management konzentriert. Der Technical Product Owner konzentriert sich mehr auf das Team.Andererseits muss der Chief Technical Product Owner ein Verständnis für die Technik in der Ready, Done und Production Phase haben. Wenn die Systembetreiber beispielsweise von Produktionsproblemen geplagt werden, sollte der CTPO das obere Management davon überzeugen, Maßnahmen zu ergreifen, die langfristig eine strukturelle Lösung bieten, anstatt die Teams mit großen Stapeln neuer Funktionen zu belasten, die sie aufbauen müssen.Um dies zu erreichen, ist der CTPO eine hochrangige Funktion. Wenn Sie einen Vergleich mit einer traditionellen IT-Organisation ziehen, ist der Leiter der Architekturabteilung möglicherweise am besten geeignet, diese Position auszufüllen. Wenn kein Manager für diese Position zur Verfügung steht, könnten Sie einen Ihrer Unternehmensarchitekten in Betracht ziehen, die Rolle des CTPO zu übernehmen. Stellen Sie sicher, dass die obere Führungsebene dieser Person vertraut und dass sie für die technologischen Herausforderungen in der IT-Organisation sensibilisiert ist.

Was kommt als nächstes?

Mit den Rollen des CTPO und des TPO werden die Priorisierungs- und Spezifikationsphasen des Lebenszyklus einer User Story gut gemanagt. Was die klassischen Architekten angeht, so werden der Architekturmanager/Unternehmensarchitekt und der Informationsarchitekt durch agilere Rollen ersetzt. Im nächsten Beitrag werden wir uns mit den architektonischen Aufgaben des Senior Software Engineers in einer agilen Organisation befassen. Bleiben Sie dran!

Mehr aus dieser Serie

    
How to Kill the Architecture Department - Part 1
    
How to Kill the Architecture Department - Part 2
    
How to Kill the Architecture Department - Part 3
    
How to Kill the Architecture Department - Part 4
    
How to Kill the Architecture Department - Part 5
    
How to Kill the Architecture Department - Part 6
    
How to Kill the Architecture Department - Part 7