Füllen des Rucksacks

Zu Beginn Ihrer Karriere ist Ihr Rucksack mit viel Theorie gefüllt, und mit dem Fortschreiten Ihrer Karriere kommen immer mehr Erfahrungen hinzu, perfekt. Irgendwann werden Sie nichts Neues mehr lernen, wenn Sie immer dieselbe Aufgabe übernehmen. Deshalb übernehmen Menschen verschiedene Rollen und wachsen in einem Team. Das Ziel des Teams, in dem Sie arbeiten, bleibt jedoch oft ähnlich: die Entwicklung von System X, das die User Stories Y und Z umsetzt. Viele Leute übernehmen viele Rollen, aber alle auf der 'produzierenden' Seite der IT. Ich persönlich habe die Erfahrung gemacht, dass es sich lohnt, für eine gewisse Zeit auf die andere(n) Seite(n) zu wechseln. Nachdem ich in meine ursprüngliche Rolle zurückgekehrt war, wurde ich viel effektiver.

Seit ich in der IT angefangen habe, habe ich 98% meiner Zeit in der Softwareproduktion verbracht. Ich war in der Entwicklung, im Design, in der Architektur tätig, wechselte ein wenig hin und her, aber immer im Bereich der Softwareerstellung. Ich wurde gebeten, eine Rolle als technischer Implementierungsmanager für eine IT-Landschaft zu übernehmen, die aus mehr als 40 Systemen und allen Arten von Integrationsadaptern besteht. Das war nicht wirklich mein Ding, aber ich nahm die Herausforderung an und hoffte, etwas zu lernen (obwohl ich mir nicht sicher war, was). Der Umfang, mit dem ich mich befassen musste, reichte von 1 System und den direkt damit verbundenen Systemen bis hin zu 40+ Systemen, die zusammen eine ganze Kette mit vielen Abhängigkeiten bilden. Aufgrund all dieser Abhängigkeiten war es unmöglich, nur 1 System zu aktualisieren. Die Aufrüstung von 1 System führte zu einem Schneeballeffekt, der Upgrades für die gesamte Kette erforderlich machte. Schlechtes Design, das stimmt, aber eine Tatsache, die wir nicht auf Anhieb ändern konnten. Das Hauptziel des Implementierungsmanagers ist es, sicherzustellen, dass die Systeme auf zuverlässige und vorhersehbare Weise in die Produktion aufgenommen werden, ohne dass es zu ungeplanten Ausfallzeiten in der Kette kommt. Angesichts von 10 Systemen, die auf einmal aktualisiert werden müssen, ist das keine triviale Aufgabe. Die letzte Inbetriebnahme der Kette war eine Katastrophe und es dauerte Wochen, bis sie "irgendwie" funktionierte. Das ist wahrscheinlich der Grund, warum die Leute mir ihr Beileid aussprachen, als ich die Stelle antrat, denn es war nicht abzusehen, dass wir Erfolg haben würden... Das Gute daran war, dass es einfach war, es besser zu machen als beim letzten Mal. Um den Schmerz des Scheiterns noch zu verstärken, gab es zum Zeitpunkt des gescheiterten Go-Live kaum Endkunden, die die Kette nutzten, aber wenn wir live gehen würden, würden viele Endkunden die Kette nutzen. Scheitern war also keine Option. In einem mehrstündigen Brainstorming haben wir(Toine war mein Komplize) das Ziel, das wir von der Geschäftsleitung erhalten hatten, durchgekaut und einen Plan erstellt, wie wir es erreichen wollten. Das Ziel war es, die gesamte Kette in weniger als 24 Stunden zu aktualisieren (so dass wir es an einem Wochenende schaffen konnten und noch Raum für ein Rollback hatten). Um dies zu erreichen, beschlossen wir, uns gründlich vorzubereiten und die gesamte Übung mehrmals in einer produktionsähnlichen Umgebung mit den Mitarbeitern zu proben, die die Migration am Go-Live-Wochenende durchführen würden. Der einzige Unterschied war, dass die Proben während der normalen Bürozeiten und nicht nachts stattfanden. Der Plan wurde in 3 einfachen Zeitplandiagrammen zusammengefasst, die für jeden Zeitblock definierten , welches Ziel erreicht werden muss. Diese Diagramme bildeten die Grundlage für viele Gespräche, die wir führten. In den Monaten vor dem Go-Live waren die Zeitblöcke ziemlich grob (z.B. 2 Wochen), für die letzte Woche und das Wochenende selbst wurden sie feiner in Stunden unterteilt. Beachten Sie, dass wir absichtlich nicht festgelegt haben, wie die Ziele zu erreichen sind. Wir haben dies den verschiedenen Projektteams überlassen, damit sie den für sie am besten geeigneten Ansatz festlegen konnten. Die Anforderung an das Team, sich vorzubereiten, legte die Messlatte für viele Teams sehr hoch. Wir mussten die Leute immer wieder davon überzeugen, dass Vorbereitung der Schlüssel zum Erfolg ist und dass es sich lohnt, viele Stunden ihrer knappen Ressourcen zu investieren. Wir sind nie von unserer Vision und unserem Plan abgewichen und die Freiheit bei der Frage nach dem Wie hat uns einige Widerstände genommen. Was uns half, war, dass der Ruf der Abteilung auf dem Spiel stand (vor allem nach dem letzten Fehlschlag) und wenn wir scheitern würden, der Ruf des Unternehmens, da die Kette von vielen Kunden verwendet wurde. Das hat geholfen, die Leute zu überzeugen. Niemand wollte den letzten Misserfolg wiederholen und mit einigen erfolgreichen Mini-Ketten haben wir unseren Ansatz bewiesen und uns etwas Ansehen verschafft. Leute, die sich normalerweise nur auf "ihre" Phase im Projekt konzentrierten, wurden"eingeladen", dabei zu helfen, die Kette zum Laufen zu bringen. Zum Beispiel: Architekten und Designer halfen bei der Ausarbeitung von Implementierungsplänen und waren während des Go-Live-Wochenendes auf Abruf oder vor Ort. Die Mitarbeiter der Qualitätssicherung hatten die meiste Erfahrung mit den neuen Versionen der Systeme in der Kette und waren daher während des Go-Live vor Ort, um bei der Validierung der Upgrades und der Analyse von Problemen zu helfen. Das Projektteam, das normalerweise bei der Übergabe der Software an die Qualitätssicherung nicht mehr beteiligt war, schrieb nun die detaillierten Implementierungspläne und musste die operativen Wartungsmitarbeiter bei der korrekten Ausführung der Pläne anleiten. Die operativen Wartungsmitarbeiter erkannten, dass sie viel weniger Nachsorgeprobleme haben würden, wenn sie eng mit dem Projektteam zusammenarbeiteten, um die Playbooks zu proben. Bei den anfänglichen Proben der Playbooks konzentrierten wir uns auf Teilketten und ließen sie später alle zusammen in einer Probe der gesamten Kette arbeiten, was den Mitarbeitern half, sich zu finden und effizienter zusammenzuarbeiten. Eines der größten Risiken für die Einhaltung der 24-Stunden-Frist waren mehrere Datenmigrationen, die in einigen Fällen zunächst Tage in Anspruch nahmen. Es wurde viel Aufwand betrieben, um diese zu optimieren und auch an Kopien der Produktionsdaten zu testen. Dabei traten zahlreiche Probleme zutage, die am Go-Live-Wochenende zum Scheitern geführt hätten, aber jetzt konnten wir sie im Vorfeld angehen. Was habe ich also gelernt und was wende ich jetzt in meiner aktuellen Rolle als Architekt (mehr) an? Kommunikation ist der Schlüssel Wir hatten über 100 Personen, die an dem Wochenende aktiv waren, und die Proben haben die Kommunikation zwischen den Personen geglättet. Oft mussten Leute, die nie wirklich zusammengearbeitet hatten, nun zusammenarbeiten, um Probleme zu analysieren und zu lösen. Dies begann bereits während der Proben, als der Druck im Vergleich zu einem Go-Live-Wochenende viel geringer war. Das macht es für die Menschen viel einfacher, Beziehungen aufzubauen (im Vergleich zu einer Situation mit hohem Druck). Frühzeitige Einbindung aller Beteiligten Es waren viele Projektteams beteiligt und es erwies sich als sehr wichtig, alle Teams so schnell wie möglich an Bord zu holen. Nach dem ersten Brainstorming begannen wir, unsere Vision dem Management, den Projektteams, der Betriebswartung, dem internen Kunden usw. zu vermitteln. Wir machten deutlich, was wir von ihnen erwarteten und baten sie, mit den Vorbereitungen zu beginnen. Das war 6 Monate vor der Inbetriebnahme und die Aufnahme der Produktion stand nicht ganz oben auf ihrer Prioritätenliste. Dennoch wollten wir, dass sie mit den Vorbereitungen beginnen, erste Playbook-Versionen erstellen, über Abhängigkeiten und Zeitpläne nachdenken usw. Wir stellten sicher, dass wir uns regelmäßig bei den Teams über ihre Fortschritte erkundigten und das Ziel und die Vision immer wieder kommunizierten. Schaffen Sie eine Vision und teilen Sie sie Wir begannen mit einem großen Ziel und einer Vision, wie wir es erreichen können. Dieses Ziel und diese Vision leiteten all unsere Handlungen und verschafften allen Beteiligten, mit denen wir zusammenarbeiten mussten, Klarheit. Es dauerte eine Weile, bis wir es verinnerlicht hatten, aber indem wir es ständig wiederholten und fast schon religiös annahmen, wurde es zu einem gemeinsamen Ziel aller beteiligten Teams. Anfangs hatten viele Leute Zweifel, aber mit der Zeit konnten wir die Ergebnisse der Proben und des Go-Live von Miniketten vorweisen. Das brachte langsam alle dazu, den Ansatz zu unterstützen. Es erwies sich als sehr wichtig, einen Punkt am Horizont zu setzen und diesen zu einem gemeinsamen Ziel zu machen. Ein Projekt endet nicht mit der Übergabe an die Qualitätssicherung . Der Umfang von Projekten sollte den Go-Live und die Nachbetreuung einschließen. Eine der Hürden, die wir nehmen mussten, bestand darin, die PMs davon zu überzeugen, dass ihr Projektteam Zeit für die Vorbereitung des Go-Live aufwenden sollte. Dies war eine Hürde, weil dies nicht als Teil ihrer Projektleistungen angesehen wurde und sie daher keine Ressourcen dafür hatten. Glücklicherweise konnten wir sie alle überzeugen, aber es hat einige Zeit gedauert. Es wäre viel einfacher gewesen, wenn der Projektumfang das Go-Live einschließt und nicht bei der Abnahme durch die QA aufhört. Die betriebliche Wartung ist Ihr Freund, beziehen Sie sie mit ein, immer Stellen Sie sicher, dass Sie die betrieblichen Wartungsteams frühzeitig einbeziehen und sie auch weiterhin einbeziehen. Sie müssen die Software tagtäglich betreuen. Daher ist es wichtig, dass ihre Bedürfnisse berücksichtigt werden und dass sie sicher sein können, dass die neue Software ihnen das Leben nicht schwerer macht. Außerdem sind dies die Leute, die Zugang zu den Maschinen haben und die Dinge für Sie überprüfen (z.B. die Konnektivität) oder reparieren können. Bringen Sie immer etwas Kaffee mit, wenn Sie einen Gefallen von ihnen brauchen. Automatisieren Sie so viel wie möglich Die Bereitstellung von Software sollte so weit wie möglich automatisiert werden. Der Hauptgrund dafür, dass wir viel Zeit mit dem Einstudieren der Playbooks verbracht haben, war, dass die Upgrades der Systeme manuell durchgeführt wurden. Abgesehen von der langen Dauer erwies sich dies als fehleranfällig. Die Playbooks mussten sehr detailliert sein und wir mussten die Mitarbeiter davon überzeugen, die Schritte im Playbook auch wirklich zu befolgen. Es gibt einen Grund für diese Schritte, also lassen Sie sie nicht aus oder machen Sie sie in einer anderen Reihenfolge. Leider waren wir nicht in der Lage, automatische Bereitstellungen für alle Systeme zu realisieren, so dass dies ein Bereich ist, der noch verbessert werden muss. Datenmigrationen sind ein Risiko, validieren Sie sie im Vorfeld mit Produktionsdaten Im Rahmen des Go-Live musste eine Reihe von umfangreichen Datenmigrationen durchgeführt werden. Hier gibt es zwei Risiken zu beachten: die Dauer und die Robustheit. Beide Risiken wurden beseitigt, indem die Datenmigrationen mit Kopien der Produktionsdaten durchgeführt wurden. Dies gab uns Aufschluss über die Dauer, die zu lang war. Es war also eine Optimierung erforderlich. Außerdem stellte sich heraus, dass die Produktionsdaten nicht so sauber waren wie die Testdaten, die von der QA zum Testen der Datenmigration verwendet wurden. Die schmutzigen Produktionsdaten brachten die Migration zum Scheitern und es waren zusätzliche Anstrengungen erforderlich, um die Migration robuster zu machen und die Produktionsdaten zu bereinigen. Geben Sie den Mitarbeitern Freiheiten, aber kommunizieren Sie die Ziele und erklären Sie sie Wir hatten es mit mehr als 20 Projektteams, Abteilungen, externen Lieferanten usw. zu tun. Es gab keine Möglichkeit, sie auf einer detaillierten Ebene abzustimmen. Also konzentrierten wir uns darauf, die Ziele, die Vision und den Plan zu kommunizieren. Darin wurde erklärt, was wir insgesamt zu erreichen hatten und welche (meist zeitlichen) Beschränkungen es gab. Dann gaben wir den verschiedenen Teams die Freiheit, eine solide Lösung für ihr System zu finden. Natürlich mussten sie während der Proben beweisen, dass ihr Ansatz funktionierte, und wir mussten überprüfen, ob er in den Gesamtplan passte, aber indem wir ihnen Freiheiten gaben und die Ziele klar darlegten, konnten sie effiziente Lösungen für ihren Bereich erarbeiten. Die Zusammenarbeit mit internen IT-Abteilungen kann eine Herausforderung sein Interne IT-Abteilungen konzentrieren sich in der Regel auf laufende Belange und sind nach Spezialgebieten organisiert (Netzwerk, Datenbank, Rechner, Betriebssystem). Wenn die Infrastruktur läuft, sorgen sie dafür, dass sie weiterläuft. Die Unterstützung von Projekten, die schnelle Reaktionszeiten erfordern und deren Anforderungen sich kurzfristig ändern, ist nicht ihr Ding. Das erfordert einfach eine andere Art von Menschen und Prozessen. Dies war ein frustrierender Bereich, und nach mehreren Eskalationen gelang es uns, einen engagierten PM zu bekommen, der integraler Bestandteil unseres Teams war und nur ein Ziel hatte: unsere Änderungsanfragen pünktlich auszuführen und so viel Verfahrensmüll wie möglich zu vermeiden. Das bedeutete nicht, dass wir alle Verfahren umgehen konnten, aber wir hatten jetzt jemanden, der wusste, wie wir die Dinge beschleunigen konnten. Er zwang uns auch dazu, etwas mehr im Voraus zu denken und Änderungsanträge früher zu stellen. Das war fair und wir haben es geschafft, eine praktikable Situation zu schaffen. Das einzige Problem war, dass wir an diese eine Person gebunden waren, und als sie ersetzt wurde, mussten wir wieder von vorne anfangen. Wenn Sie also mit diesen Gruppen etwas erreichen wollen, sollten Sie sie frühzeitig einbeziehen, versuchen, einen Ansprechpartner zu finden und dessen Netzwerk zu nutzen. Ich bin froh, wieder auf der 'softwareproduzierenden' Seite der IT zu sein, schätze aber auch die Erfahrung, auf der empfangenden Seite zu arbeiten. Ich habe dabei einige neue Dinge gelernt und Dinge verstärkt, die ich bereits wusste, aber nicht genug getan habe. Ich bin sicher, dass ich wieder ein solches Sabbatical machen werde, nicht jetzt, aber mal sehen, welche Herausforderungen sich in der Zukunft ergeben.