Auf der Arbeit

Wie zu erwarten

Termin mit meiner Product Ownerin (PO) und Kollege SF, seines Zeichens ja jetzt PO des IT Change Management Teams (CM).

Thema: Wir haben in den JahresabschlußprĂŒfungen von den WirtschaftsprĂŒfer:innen ein paar Dinge zum IT Change Prozess ins Gebetbuch geschrieben bekommen, die wir angehen mĂŒssen.

Anforderung

Beispielsweise ist nur mit großem Aufwand nachzuvollziehen, auf Grund welcher Anforderung ein Change Request (CR) umgesetzt wurde. Weiterhin muss oft mĂŒhsam manuell fĂŒr Change Requests der Nachweis ĂŒber den Test und die Freigabe beigebracht werden, da sie völlig losgelöst davon dokumentiert wird. Bei Infrastruktur-Change Requests liegt manchmal gar keine Tesdoku & Freigabe vor.

Es muss also zukĂŒnftig im Change Request klar erkennbar sein, zu welcher Anforderung der CR gehört, wie das Testergebnis war, zudem muss die Dokumentation der Freigabe fĂŒr die Produktivsetzung vorhanden sein. Entweder als Link zu anderen Tools, oder direkt im CR als Attachment o.Ă€.

Wir hatten bereits mit Product Manager (PM)-Kollege M. dazu ein Epic formuliert, aus dem ein Feature an das IT Change Management Team geht mit der Bearbeitung dieser o.g. Themen. Denn dies ist ganz klar im Rahmen des IT Change Prozesses zu behandeln, sie mĂŒssen als QS drauf achten, dass die Changes zukĂŒnftig diesen Anforderungen genĂŒgen.

Abstimmung

Heute haben wir nun gemeinsam mit SF die Anforderungen genau spezifiziert als Abnahmekriterien fĂŒr dieses Feature. Außerdem will Kollegin G. noch Beispiele aus der letzten PrĂŒfung zusammensuchen und ans CM-Team weitergeben. Als Hilfe fĂŒr die Kunden:innen = Nutzer:innen des IT Change Prozesses.

Bei nahezu allen Punkten hatte SF nichts anderes im Sinn, als die Arbeit wegzuschieben: mehr oder weniger O-Töne:

  • „Die Anforderungen mĂŒssen dann ĂŒber die ARTs und Gilden an die anderen weitergegeben werden, damit sie diese zukĂŒnftig erfĂŒllen“
  • „Ich warte, bis ihr die Beispiele liefert“
  • „Wir mĂŒssen das dann noch genauer Ausformulieren“ – mit „wir“ gemeint: Kollegin G., ich, und ganz am Ende zur Not auch er

Initiative = Null

Er zeigte (mal wieder, so vorhersehbar) Null Initiative, das Thema von sich aus anzugehen und auszuarbeiten. Er hat es ĂŒberhaupt nicht als sein Thema angenommen. Sondern eher im Sinne von: das mĂŒssen doch die anderen lösen.

Jedoch muss das IT Change Management diese Anforderungen konkret bearbeiten, detaillieren und ausformulieren (z.B. was sie wie und wo im Change Request konkret erwarten), und sie in die Dokumentationen rund um den IT Change Prozess aufnehmen. Außerdem mĂŒssen sie sich im Team darĂŒber einigen, dass dies zukĂŒnftig Pflichtbestandteile eines CRs sind, die im Zweifelsfall aktiv eingefordert werden.

Als ich mal kurz auf Toilette war, muss er wohl noch deutlicher von G. die Arbeit eingefordert haben (erzĂ€hlte sie mir im Nachgang). Sie ist recht neu und kennt ihn noch nicht so, bei mir hat er es sich nicht so explizit getraut. Aber G. ist ja zum GlĂŒck alles andere als blöd :-), außerdem hatte ich sie natĂŒrlich gebrieft.

Einigkeit beim Rest

Zum GlĂŒck sind wir uns mit PM und auch Chef-Chef alle einig: das ist eindeutig Aufgabe des IT Change Managements!

Was wir aber wohl nochmal deutlicher im Feature formulieren mĂŒssen: das wir aus Regulatorik-Sicht erwarten, dass das IT Change Management als Gatekeeper fungiert und Changes nur durchlĂ€sst, wenn sie die Kriterien erfĂŒllen. Sonst wird das nĂ€mlich nix. Und G. und ich fĂŒrchten, dass ist noch nicht so klar bei SF angekommen.

Die EinfĂŒhrung der neuen Anforderungen wird nicht von alleine passieren und auch niemand fĂŒr ihn erledigen! Da muss er nun doch tatsĂ€chlich mal als PO tĂ€tig werden. Zu HĂŒlf 😼

Bin sehr gespannt, wie das weitergeht! 😋