IT-Experten gewinnen, motivieren und binden E-Book

Thomas Saller

• Herausgeber: Haufe Lexware
• Kategorie: Fachliteratur
• Serie: Haufe Fachbuch
• Sprache: Deutsch
• Veröffentlichungsjahr: 2020

Seitenzahl: 307

Beschreibung

Der Erfolg der Digitalisierung hängt nicht nur vom richtigen Mindset des Top-Managements ab. Viele Unternehmen kämpfen mit einem viel handfesteren Thema: der Verfügbarkeit von qualifizierten und motivierten IT-Experten. Der Markt ist leergefegt, die Gehälter steigen immer weiter. Und mit der Rekrutierung x-beliebiger IT-Experten ist das Problem noch lange nicht gelöst: Studien zeigen den massiven Produktivitätsunterschied zwischen guten und weniger guten Entwicklern. Im War for IT-Talents gewinnen nicht die Unternehmen, die die besten Gehälter zahlen, sondern jene, die ein echtes Verständnis dafür haben, wie die Zielgruppe tickt. Die Autoren erklären, was ein Softwareentwickler eigentlich macht, was ihn beschäftigt, wodurch er sich anerkannt fühlt und worauf man beim Employer Branding, Recruiting und in der Mitarbeiterführung achten muss. Das Ziel: die richtigen Experten gewinnen, motivieren und langfristig binden. Inhalte: - Was machen Software Developer eigentlich den ganzen Tag? - Wie geht man mit Software Developern am besten um? Employer Branding, Rekrutierung, Auswahl, Motivation - Kurz-Interviews mit HR-Verantwortlichen und Managern in erfolgreichen Tech-Firmen, IT-Startups etc. - Aus dem Innenleben eines Software Developers: Wie nimmt er seine Führung wahr? Für welche Innovationen und Arbeitsformen brennt er? Mit welchen Vorurteilen kann er gar nichts anfangen? 

Leseprobe

[7]Inhaltsverzeichnis

Hinweis zum UrheberrechtImpressumGeleitwortEinleitung: Was Ihnen dieses Buch bietet1 IT-Experten verstehen1.1 Aus dem echten Leben: Warum Dr. Matthias Gerber es bei der GABI GmbH langweilig findet1.2 Was macht eigentlich ein IT-ler? Rollen und Bezeichnungen im Überblick1.2.1 Software entwickeln1.2.2 Software betreiben1.2.3 Entwicklung: Architekten1.2.4 Entwicklung: Developer1.2.5 Entwicklungssteuerung: Product Owner, Requirement Engineer, Anforderungsmanager, Business Analyst1.2.6 Betrieb: Administration, Support1.2.7 Der ganze Rest: Wen man sonst noch braucht1.3 Wovon gerade alle sprechen: Aktuell wichtige Schlagworte in der IT1.3.1 Blockchain1.3.2 Big Data1.3.3 Bring Your Own Device (BYOD)1.3.4 Cloud1.3.5 Cyber-1.3.6 Hybrid Computing1.3.7 IaaS, PaaS, SaaS1.3.8 IoT1.3.9 Künstliche Intelligenz (KI)1.3.10 Machine Learning1.3.11 Mobile First1.3.12 Quantencomputer1.4 Irgendwas mit programmieren halt, oder? Aus dem Arbeitsalltag des IT-Experten1.4.1 Code schreiben1.4.2 Denken1.4.3 Experimentieren1.4.4 Testen1.4.5 Bugs beheben1.4.6 Dokumentieren1.4.7 Kommunizieren1.4.8 Lernen1.4.9 Wissen weitergeben1.4.10 Der Rest1.5 Was habt Ihr gegen Wasserfälle? Agilität in der Softwareentwicklung1.5.1 Agilität1.5.2 Agiles Manifest1.5.3 Agilität als Methodologie, nicht als Methode1.5.4 Scrum und Agilität in der IT1.6 Wundertüte Agilität? Der Agilitäts-Boom außerhalb der IT1.7 Sind IT-Experten wirklich anders? Ein wissenschaftlicher Blick auf Persönlichkeitsunterschiede1.8 Warum gute IT-ler oft keine guten IT-Manager sind: IT und das Management2 IT-Experten gewinnen2.1 Aus dem echten Leben: Wie PLQL Alexander das Leben schwer machte2.2 Recruiting im Überblick: Wie funktioniert Personalgewinnung allgemein?2.2.1 Was ist Recruiting?2.2.2 Schritt 1: Employer Branding2.2.3 Schritt 2: Anforderungsprofil und Stellenausschreibung2.2.4 Schritt 3: Kandidatensuche2.2.5 Schritt 4: Screening und Auswahl von Kandidaten2.2.6 Schritt 5: Angebot und Einstellung2.2.7 Schritt 6: Einarbeitung2.3 IT-Experten finden: ein leergefegter Markt2.3.1 Aufgaben definieren2.3.2 Notwendige Fähigkeiten und Eigenschaften klären2.3.3 Erwartungen an die IT-Experten formulieren2.3.4 Zielgruppe identifizieren2.3.5 Wo sind die IT-Experten?2.3.6 Ich verstehe einfach nicht was er will: Was wünschen sich IT- Experten vom Arbeitgeber?2.3.7 Was Arbeitgeber bieten: Gehalt2.3.8 Was Arbeitgeber bieten: Benefits2.4 Personalsuche und IT-Personalberatungen2.4.1 Lass ja keinen Personaler auf die los: Interviews mit technischen IT-Experten2.4.2 Schöner scheitern: Acht Tipps wie man ein IT- Fachinterview sicher vermasselt2.4.3 Erfolgreiche technisches Interviews2.5 Recruiting in der öffentlichen Verwaltung: Interview mit Hans-Christian Witthauer3 IT-Experten motivieren3.1 Aus dem echten Leben: Frank Frickels zweifelhafte Ehre beim Triple B Award3.2 Motivation im Überblick: Wie funktioniert Motivation im Allgemeinen?3.2.1 Ein Streifzug durch die Welt der Motivation3.2.2 Motivation besser verstehen – 6 Thesen3.3 Nicht alle wollen den Barista: Wie kann ich IT-Experten individuell motivieren?3.4 Die einzelnen Motive im Überblick – und woran sie sich bei IT-Experten zeigen3.5 Besonders arbeitsrelevante Motive3.5.1 Motiv Neugier3.5.2 Motiv Anerkennung3.5.3 Motiv Einfluss3.5.4 Motiv Status3.5.5 Motiv Autonomie3.5.6 Motiv Sozialkontakte3.5.7 Motiv Prinzipien3.5.8 Motiv Struktur3.6 Nur teilweise arbeitsrelevante Motive3.6.1 Motiv Soziales Engagement3.6.2 Motiv Sicherheit3.6.3 Motiv Besitzen3.6.4 Motiv Revanche3.6.5 Motiv Bewegung3.6.6 Motiv Essensgenuss3.6.7 Motiv Familie3.7 Richtige Arbeit mit den Erkenntnissen über Motive3.8 IT-Management im Berliner Scale Up: Interview mit Coco3.9 IT-Management im E-Commerce: Interview mit Nadja4 IT-Experten binden4.1 Aus dem echten Leben: Wie die Fassbrause das Fass zum Überlaufen brachte4.2 Retention im Überblick: Wie funktioniert Mitarbeiterbindung im Allgemeinen?4.2.1 Pullfaktoren4.2.2 Pushfaktoren4.2.3 Faktoren, die indirekt wirken4.3 Drum prüfe, wen Du ewig bindest: Woran merke ich, ob ich gute IT-Mitarbeiter habe?4.4 Retention: Methoden und Verfahren4.4.1 Beurteilung durch Mitglieder der Peergroup4.4.2 Reviews4.4.3 Metriken4.4.4 Benchmarking4.5 Noch ein Soft-Skill-Training: Ist IT-Weiterbildung notwendig, ist sie wünschenswert?4.5.1 Weiterbildung: wollen das die IT-Experten überhaupt?4.5.2 Inhalte der Weiterbildung4.5.3 Formen der Weiterbildung4.5.4 Organisation der Weiterbildung4.6 Von Hundeversicherungen, Jakobsmuscheln und NERF-Guns: Was Unternehmen sich einfallen lassen, um IT-Experten zu binden.4.7 IT-Management im Spin-Off: Interview mit Stefan Haflinger4.8 IT-Recruiting im Konzern: Interview mit Jakob5 IT-Experten gewinnen, motivieren und binden: Die 10 goldenen RegelnLiteraturverzeichnisDie AutorenStichwortverzeichnis

[1]

Hinweis zum Urheberrecht

Haufe Lexware GmbH & Co KG

[6]Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.dnb.deabrufbar.

Print:

ISBN 978-3-648-13797-0

Bestell-Nr. 10520-0001

ePub:

ISBN 978-3-648-13798-7

Bestell-Nr. 10520-0100

ePDF:

ISBN 978-3-648-13799-4

Bestell-Nr. 10520-0150

Thomas Saller / Victor V. Terber

IT-Experten gewinnen, motivieren und binden

1. Auflage, Mai 2020

© 2020 Haufe-Lexware GmbH & Co. KG, Freiburg

www.haufe.de

[email protected]

Bildnachweis (Cover): © Ryzhi, gettyimages

Produktmanagement: Anne Rathgeber

Lektorat: Ulrich Leinz, Berlin

Dieses Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte, insbesondere die der Vervielfältigung, des auszugsweisen Nachdrucks, der Übersetzung und der Einspeicherung und Verarbeitung in elektronischen Systemen, vorbehalten. Alle Angaben/Daten nach bestem Wissen, jedoch ohne Gewähr für Vollständigkeit und Richtigkeit.

[11]Geleitwort

Was haben wir früher noch über die Programmierer geschmunzelt! Jene unbekannte Spezies, die damals gut versteckt im Kellergeschoss der Unternehmenszentrale nicht weiter beachtet ihrer Arbeit nachging.

Es gab einem dieses Gefühl der Sicherheit und Überlegenheit zu wissen, dass die IT-Experten tief unten im Maschinenraum des Unternehmens irgendetwas machten, was man nicht näher verstehen musste – und ab und zu darüber lachen konnte, wenn sie bei der Programmierung einer Software mal wieder Murks fabriziert hatten.

Heute aber haben auf einmal oft genau jene Vertreter der unbekannten Spezies das Sagen, die da vor kurzem noch im Maschinenraum waren. Kaum ein Geschäftsprozess, der nicht maßgeblich beeinflusst ist durch das, was oft unzureichend präzise als Digitalisierung beschrieben wird.

Als ich anfangs des neuen Jahrtausends ins Arbeitsleben eintrat, stand auf einem Poster in der Konzernzentrale meines Arbeitgebers: »Wir nutzen Systeme, um Menschen zu ermöglichen, bessere Entscheidungen zu treffen«. In einer wachsenden Anzahl von Unternehmen ist es heute etwas anders: »Wir nutzen Menschen, um Systemen zu ermöglichen, bessere Entscheidungen zu treffen«, heißt es zum Beispiel in einem großen amerikanischen E-Commerce-Unternehmen.

Das sichere Gefühl der Überlegenheit ist auf einmal einem Unbehagen gewichen: »Wenn ich weder die Digitalisierung verstehe noch die Menschen, die sie maßgeblich gestalten, was ist dann mein Beitrag zum Unternehmenserfolg?« Das Leben als Entscheider kann schon hart sein.

Wie so oft ist es besser, Unbehagen nicht lediglich zu ertragen, sondern Themen aktiv anzugehen und zu gestalten. Ein wichtiger Schritt dazu ist es meines Erachtens, Kompetenzen aufzubauen. Kompetenzen in den wichtigsten Themen der Digitalisierung, aber auch Kompetenzen im Umgang mit IT-Experten – mit jener Spezies, über die wir früher ab und zu noch geschmunzelt haben.

Dieses Buch fokussiert sich auf den Aufbau von Kompetenzen in der Gewinnung, Motivation und Bindung von IT-Experten. Es lässt aber auch wichtige Themen der Digitalisierung nicht außer Acht. Aus meiner Sicht leistet das Buch somit einen wichtigen Beitrag, die relevanten Bereiche nicht nur zu entmystifizieren, sondern auch konkrete und sinnvolle Handlungsanweisungen zu geben. Zudem ist das Buch einfach strukturiert sowie verständlich und kurzweilig geschrieben.

[12]Ich wünsche Ihnen viel Spaß bei der Lektüre und viel Erfolg bei der Umsetzung in Ihrem Unternehmen!

Gerrit Nolte

Gerrit Nolte arbeitete nach zehn Jahren im Management von Nestlé und Procter & Gamble zuletzt für mehr als acht Jahre bei Amazon. Hier war er zunächst für fünf Jahre als Finance Director / CFO für das deutsche Geschäft tätig und leitete danach eine Business Unit. Seit 2020 ist er selbständig und experimentiert mit verschiedenen – meist digitalen – Geschäftsmodellen.

[13]Einleitung: Was Ihnen dieses Buch bietet

Fachbücher zur Gewinnung, Bindung und Motivation von Mitarbeitern gibt es in Hülle und Fülle. Warum nun ein spezielles Buch über die Arbeit mit IT-Experten? Bietet eine Veröffentlichung zu diesem Thema einen echten Mehrwert? Schließlich gibt es ja auch keine Fachbücher zur Gewinnung, Bindung und Motivation von Dachdeckern, Vertriebscontrollern oder Social-Media-Experten. Ist die Zielgruppe IT-Experten wirklich etwas derart Besonderes? Wir würden diese Frage mit »Ja« beantworten.

Zum einen wird in keinem anderen Berufszweig der Fachkräftemangel aktuell offenkundiger als im IT-Umfeld. In seiner Ausgabe vom 7. Februar 2020 zählt der Tagesspiegel aktuell 124.000 offenen Stellen in der IT-Branche und beschreibt Wege, mit denen Unternehmen um die besten IT-Experten »kämpfen« können. In der Onlineausgabe des österreichischen Industrie-Magazins vom 28. Februar 2020 beschreibt das Organ einen »Milliardenschaden für den Standort – weil IT-Spezialisten fehlen«. Und aus der Antwort des Bundesinnenministeriums auf eine Anfrage der Linken im Bundestag im Winter 2020 geht hervor, dass von den knapp 2.800 Stellen für IT-Sicherheit in den Bundesministerien aktuell rund 700 Stellen unbesetzt sind.

Die digitale Transformation von Unternehmen und Behörden kann nicht ohne jene Personen funktionieren, die sozusagen im »Maschinenraum« arbeiten. Daher müssen sich unseres Erachtens alle Organisationen damit beschäftigen, mit der knappen »Ressource« IT-Experte richtig umzugehen. Der gesunde Menschenverstand sagt uns, dass die Notwendigkeit, die Zielgruppe IT-Experten zu verstehen, daher durchaus größer ist als jene, sich mit Dachdeckern, Vertriebscontrollern oder Social-Media-Experten zu beschäftigen.

Zum anderen lehrt uns unsere eigene Erfahrung – aus vielen hundert Interaktionen in Trainings mit IT-Experten und aus mehr als 30 Jahren Arbeit als freiberuflicher IT-Spezialist mit vielfacher Führungsverwendung – dass die Zielgruppe der IT-Experten tatsächlich in vielen Bereich anders tickt, als andere Berufsgruppen dies tun.

Dem klassischen »Nerd-Image« mit dicker Hornbrille, pizzaverschmierten Fingern, Themen-T-Shirts und Birkenstock-Sandalen entsprechen zwar nur noch die wenigsten IT-Spezialisten. Dennoch erleben wir nach wie vor viele IT-Experten, die bei ihrer täglichen Interaktion mit ihrem Umfeld gerne gegen klassische gesellschaftliche Konventionen verstoßen oder sich zumindest durch bestimmte Eigenschaften und Verhaltensweisen von der »Durchschnittsbevölkerung« abheben.

Auch wenn wir keine Pauschalisierung vornehmen können und wollen, finden wir die häufig erlebte Kombination aus Intelligenz, Wettbewerbsorientierung, beruflichem [14]Selbstbewusstsein, Sachlichkeit, Introvertiertheit und Abneigung gegenüber bestimmten sozialen Normen durchaus bemerkenswert. Eine Bewerberansprache, die bei Dachdeckern, Vertriebscontrollern und Social-Media-Experten funktioniert, könnte daher bei IT-Experten ins Leere laufen.

Mit diesem Buch wollen wir einen Beitrag dazu leisten, Führungskräften, Personalexperten, Kollegen und generell an gesellschaftlich relevanten Themen interessierten Lesern das Phänomen »IT-Experte« etwas näher zu bringen.

Dabei starten wir unser Buch mit einem umfangreichen Kapitel, das dabei helfen soll, IT-Experten besser zu verstehen. Wir beschreiben hier beispielsweise verschiedene Rollen innerhalb der IT, erklären in einfachen Worten den typischen Arbeitsalltag verschiedener IT-Experten und erläutern aktuell wichtige Schlagworte innerhalb der Informationstechnologie-Branche.

Die anschließenden drei Kapitel beschäftigen sich mit drei der »klassischen« Personalthemen: Der Gewinnung (Rekrutierung), der Motivation und der Bindung (Retention) von Mitarbeitern. Jedes der drei Kapitel beginnt mit einer Beschreibung von allgemeinen »Best Practices«. Die folgenden Unterkapitel beschreiben aus unserer Sicht relevante IT-Spezifika. Zum Beispiel stellen wir Studien zur Frage vor, was sich IT-Experten vom zukünftigen Arbeitgeber wünschen, diskutieren Methoden, anhand derer die Qualität von IT-Experten gemessen werden kann und werfen einen genaueren Blick auf den IT-Weiterbildungsmarkt.

Ergänzt haben wir unser Buch durch Interviews mit fünf Fachexperten, die sich schon seit vielen Jahren mit den Themen Gewinnung, Bindung und Motivation von IT-Experten beschäftigen. Die Bandbreite der Interviewpartner reicht vom CTO (Chief Technology Officer) eines Unternehmens, das einen digitalen Spin-Off aufgebaut hat, über einen Recruitingspezialisten eines Berliner Techunternehmens bis hin zum Leiter des Aufbaustabes des ehemaligen »Behörden-Start-ups« ZITiS. Die Interviews haben wir zudem von IT-Spezialisten kommentieren lassen. Diese nehmen bei der Bewertung des jeweiligen Gespräches kein Blatt vor den Mund.

Im abschließenden Kapitel 5 bieten wir Ihnen unsere Zusammenfassung, in Form von 10 goldenen Regeln im Umgang mit IT-Experten. Sollten Sie nur wenig Zeit zum Lesen haben, legen Ihnen wir die Lektüre dieses Kapitels besonders nahe.

Noch vor weniger als zehn Jahren durfte einer der Autoren live miterleben, als der Geschäftsführer eines größeren deutschen Unternehmens seinen CIO (Chief Information Officer) ins Büro zitierte, um ihm darum zu bitten, eine neue Tastatur bei seinem [15]PC zu installieren. Auch wenn mittlerweile die meisten Vertreter des Managements ein etwas elaborierteres Verständnis von den Aufgaben und Fähigkeiten eines IT-Experten haben, erleben wir hier immer noch Defizite. Wir hoffen, mit diesem Buch einen Beitrag dazu zu leisten, die noch bestehenden Gräben zwischen dem Management und der IT zu überbrücken. Bei der Lektüre wünschen wir Ihnen viel Spaß und interessante neue Erkenntnisse!

Wörthsee / München, März 2020

Thomas Saller

Victor V. Terber

[17]1IT-Experten verstehen

1.1Aus dem echten Leben: Warum Dr. Matthias Gerber es bei der GABI GmbH langweilig findet

»Laaangweilig!«, tönte es durch den Besprechungsraum der GABI GmbH. »Einfach nur langweilig«, gefolgt von einem langen Stöhnen. Eine ungewöhnliche Aussage, die man in dem holzgetäfelten Executive Boardroom im vierten Stock des mittelständischen Unternehmens nicht häufig hörte.

Maria Subota, Leiterin der Fachabteilung »Recht und Compliance« glaubte zuerst, sie habe sich verhört, und setzte die Beschreibung der Anforderungen für die IT-Architektur fort. Da hörte sie das Stöhnen wieder; es kam eindeutig aus der Ecke von Gerber.

Dr. Matthias Gerber war ein IT-Architekt der ersten Stunde bei der GABI – ein hyperintelligenter, promovierter Programmierer, der schon öfter in vergleichbaren Runden negativ aufgefallen war. So hatte er an anderer Stelle sich in einem Meeting mit dem Topmanagement geweigert, eine Grobabschätzung für den Aufwand der Implementierung eines neuen Programmes abzugeben: »Ich kann es nicht schätzen, bevor ich die genauen Anforderungen habe. Schreib einfach eine Million hin«, hatte er damals zum CFO gesagt. »Aber bitte, Herr Gerber, das ist doch eine völlig illusorische Zahl«, hatte dieser geantwortet und ergänzte in fast bettelndem Ton, »ich weiß, wir haben noch nicht alle Spezifikationen, aber wir brauchen bitte, bitte, bitte eine ganz grobe Abschätzung«. »Na, dann schreib halt 42 hin. Das ist doch die Antwort auf alle großen Fragen im Leben«, hatte Gerber damals geantwortet und den Raum verlassen.

Nun drohte also wieder eines der gefürchteten Meetings mit dem ungehobelten, zugleich aber auch unersetzbaren IT-Experten zu eskalieren. »Herr Gerber, können Sie bitte etwas näher ausführen, was Sie mit »langweilig« meinen?«, fragte Frau Subota, die von der Kritik an ihrem langjährigen Projekt offensichtlich getroffen war.

»Naja, die Anforderungen sind einfach total langweilig und null herausfordernd. An solchen Themen zu arbeiten macht mir überhaupt keinen Spaß. Gibt es kein Thema mit ernsthaften Herausforderungen?«

Schweigen im Konferenzraum. Offenbar war die Aussage von Gerber fachlich richtig – soweit die Nicht-IT-Experten im Raume dies beurteilen konnten. Aber ging es denn in diesem Meeting darum, Dr. Gerber anspruchsvolle Aufgaben zu vermitteln oder nicht vielmehr darum, seine Unterstützung für die Umsetzung eines Compliance-Themas zu [18]erbitten? Der Kollege war doch immer wieder äußerst sperrig in seinen Interaktionen. Wäre er kein IT-Experte, hätte man sich sicherlich schon längst von ihm getrennt.

»Überlegt doch bitte noch mal, ob Ihr was etwas Spannenderes findet«, unterbrach Gerber das Schweigen. »Und bis dahin höre ich jetzt einfach wieder Musik«.

Gesagt, getan. Gerber zog seine geräusch- und gesprächsunterdrückenden Sennheiser-Kopfhörer auf und vertiefte sich wieder in die Arbeit auf seinem Notebook, das er unerlaubterweise ins Meeting mitgebracht hatte. Während sich die Kollegen ratlos anschauten, war deutlich der berühmte Death-Metal-Song Spirit Crusher der Gruppe Death zu vernehmen.

1.2Was macht eigentlich ein IT-ler? Rollen und Bezeichnungen im Überblick

»Was macht Dein Bruder eigentlich beruflich?« – »Irgendwas mit Computern«. So oder so ähnlich haben sich noch vor wenigen Jahren Gespräche mit Angehörigen von IT-Experten abgespielt. Auch wenn dies etwas seltener geworden ist, das Unverständnis über die genaue Tätigkeit von IT-Experten ist großteils geblieben. Da hatte die Umgebung gerade eben erst so einigermaßen verstanden, was ein Programmierer eigentlich den ganzen Tag macht, da wurde der Betroffene schon Entwickler oder Software Engineer.

Zugegeben: Bei vielen Controllern, Psychologen oder Ingenieuren verhält es sich nicht anders. Das Alarmierende ist jedoch, dass es selbst Projektleitern und Vorgesetzten ohne IT-Hintergrund immer wieder unklar ist, wer im IT-Bereich denn eigentlich was macht (oder machen sollte). Der folgende Abschnitt soll dazu dienen, etwas Licht ins Dunkel zu bringen.

Grundlegende Unterscheidung anhand der Tätigkeit

Die Informationstechnologie hat sich zu einem extrem weiten Feld entwickelt, in dem es zahllose Möglichkeiten gibt, Tätigkeiten zu kategorisieren. Im beruflichen Umfeld dominieren quantitativ (im Sinne der Anzahl der beschäftigten Mitarbeiter) zwei Hauptgruppen von Tätigkeiten:

Software entwickelnSoftware betreiben

Weitere Bereiche der IT, von denen es viele gibt – etwa die Hardwareentwicklung –, sind ebenfalls äußerst relevant, bilden aber nicht den Schwerpunkt dieses Buches; wieder andere – wie etwa die theoretische Grundlagenforschung – sind kaum im kommerziellen Umfeld vertreten.

[19]1.2.1Software entwickeln

Software, Apps, Anwendungen, Programme – sie alle schreiben sich nicht von allein, sondern werden von Menschen entwickelt. Trotz enormer Bemühungen, diesen Prozess effektiver zu gestalten oder zumindest teilweise zu automatisieren, gibt es keine Automaten oder Roboter, die dies leisten können – und wenn es diese eines Tages gäbe, dann müsste jemand eben diese Automaten oder Roboter programmieren.

Historisch gesehen war die Softwareentwicklung zunächst die Aufgabe einer einzelnen Rolle, nämlich jene des Programmierers. Ein oder mehrere Programmierer erstellten ein Programm vollständig, einschließlich aller dafür notwendigen Arbeitsschritte. Eine weitere Differenzierung fand lange Zeit nicht statt. Doch mit der Erweiterung des Feldes änderte sich dies, und es kam zu einer fortwährenden und mit Sicherheit noch nicht abgeschlossenen Ausdifferenzierung der Rollen und Aufgaben. Schon aus diesem Grund können die nachfolgenden Überlegungen nur einen aktuellen Schnappschuss ohne Anspruch auf Vollständigkeit darstellen.

Softwareentwicklung kann sehr vielfältig aufgefasst und definiert werden. Insbesondere die Bedeutung der jeweiligen Rollen im Entwicklungsprozess wird äußerst unterschiedlich bewertet.

Die nachfolgende Grafik illustriert die empfundene Perspektive vieler IT-Experten, insbesondere aus dem Entwicklungsbereich:

Abb. 1: Softwareentwicklungsprozess aus Sicht eines stereotypischen Entwicklers

Die Entwickler – die Architekten und Developer – stehen im Zentrum des Prozesses. Sie haben jedoch wichtige Zulieferer von Informationen sowie Abnehmer ihrer Arbeitsergebnisse.

[20]Aus Managementsicht stellt sich das oft deutlich anders da. Der relevante Ansprechpartner ist die IT-Projektleitung, alle weiteren Differenzierungen sind weitgehend irrelevant, wie es die folgende Abbildung darstellt.

Abb. 2: Softwareentwicklungsprozess aus Sicht eines stereotypischen IT-Managers

Aus übergeordneter Sicht beginnt die Entwicklung mit dem Wunsch nach einer bestimmten Funktionalität. Dazu werden die dafür notwendigen Ressourcen zur Verfügung gestellt. Aus dieser Perspektive gibt es eine hohe Anzahl verschiedener an der Entwicklung beteiligter Rollen: Von den Mitarbeitern, die im Kerngeschäft des Unternehmens tätig sind und sich die Anforderung »überlegt« haben, bis hin zum internen oder externen Nutzer der fertigen Anwendung.

Die Softwareentwicklung im engeren Sinne führt im Wesentlichen die technische Entwicklung der Software aus, sie erstellt den Entwurf der Software und »schreibt« schließlich das Programm.

Die Softwareentwicklung wird unterstützt von technischen Rollen: Sie stellen sicher, dass die Software die geforderte Funktion und Fähigkeit erfüllt, sie sind dafür zuständig, die Software in qualitativ akzeptabler Form auf produktive Systeme auszurollen, und sie steuern zudem die nichttechnischen Teams.

Übersicht

Kernbereiche der Softwareentwicklung: Architektur und DevelopmentUnterstützung der eigentlichen Entwicklung: Integration, DevOps, Quality AssuranceSteuerung der Entwicklung: Product Owner, Requirement Engineer, Business Analyst

Die besagten Begriffe werden nachfolgend in diesem Kapitel erklärt werden. Doch zunächst gehen wir auf die zweite Hauptgruppe der Tätigkeiten ein, auf diejenigen, die die Software betreiben.

[21]1.2.2Software betreiben

Spezielle Software erfordert gerade auch nach der Inbetriebnahme spezifische Aufwände. Viele Aufgaben sind eher einfacher, wie zum Beispiel Backups erstellen oder Updates installieren. Andere Tätigkeiten sind schwierig oder gar komplex, wie zum Beispiel die Unterstützung der Nutzer, Anpassung an neue Rechner oder Betriebssysteme, Analyse und Behebung von Störungen. Dieser Bereich wurde traditionell »Operations«, »Run« oder »Betrieb« genannt.

Typische Rollen in diesem Gebiet sind Administration, Support, Helpdesk oder allgemein Betriebsunterstützung.

1.2.3Entwicklung: Architekten

Software Engineering hat eine ganze Reihe von Metaphern aus dem Bauwesen übernommen. Neben der Idee von Entwurfsmustern (Alexander, Ishikawa & Silverstein, 1977) hat insbesondere das Konzept von Architektur und Architekten Widerhall gefunden. Das griechische Wort ἀρχιτέκτων (architékton) wird nicht nur als Baumeister, sondern auch als »Meisterbauer« oder »Oberster Handwerker« übersetzt. Analog dazu wird Software »gebaut« und die IT-Architekten sind als Ober-Handwerker tätig.

Wie vieles in der jungen Disziplin der IT ist auch die Rolle des Softwarearchitekten keineswegs klar definiert. Zum Aufgabenkern gehört aber in jedem Falle das Definieren von Vorgaben und das Erstellen von Leitlinien, an denen sich seine Kollegen aus der Entwicklung orientieren sollen.

Diese Tätigkeit kann auf ganz verschiedenen Ebenen erfolgen, was sich auch (meist) in unterschiedlichen Rollenbezeichnungen niederschlägt:

Enterprise Architect: Gestaltet die Anwendungslandschaft für einzelne Firmenbereiche oder das ganze Unternehmen, abhängig von der Unternehmens- und der IT-Strategie. Erarbeitet eine Zielarchitektur, sowie die Zwischenschritte aus der aktuellen Situation heraus dorthin (Migration).Business Architect: Entwickelt die IT-Architektur eines Unternehmens oder einer Abteilung aus fachlicher Sicht.Solution Architect: Entwickelt Softwarearchitekturen für komplexe, unternehmenskritische Anwendungen.Software Architect: Verantwortet das technische Design einer einzelnen Anwendung.

Die Begriffe und Beschreibungen sind historisch gewachsen. Es gibt keinen Standard, was die Termini exakt bedeuten, auch wenn in der Fachliteratur immer wieder derartige Bestrebungen auftauchen. Für die Führungs- oder Projektverantwortlichen ist es [22]vor allem wichtig, eine erste Vorstellung davon zu haben, wovon gesprochen wird, um auf dieser Basis eine eigene Aufgabenbeschreibung zu definieren.

1.2.4Entwicklung: Developer

Developer, Dev, Entwickler, Programmierer, Software Engineer: All dies bezeichnet im Wesentlichen dasselbe, nämlich den Mitarbeiter, der den Sourcecode erstellt, aus dem die Software gebaut wird.

Während Programmierer die älteste und im deutschen Sprachraum lange Zeit einzige Version des Berufes war, kam es in den letzten Jahrzehnten zu einer langsamen Entwertung dieses Begriffes. Mehr und mehr setzte sich die Einsicht durch, dass ein Programmierer mehr als »nur programmiert«. »Entwickler« und die englische Version »Developer« sind heute wohl die verbreitetsten Bezeichnungen. Auch »Software Engineer« ist inzwischen salonfähig geworden, allerdings praktisch nur in der englischen Form.

Die Rolle des Developers ist für die Softwarenentwicklung zentral. Sicherlich ist Software Development wie jedes komplexe Unterfangen eine Teamaufgabe: mit Entwicklern, Testern, Integratoren, Anforderungsmanagern, Projektleitern und vielen anderen. Aber Dreh- und Angelpunkt der Softwareentwicklung ist der Entwickler. Auch aus diesem Grunde ist, wenn vom Fachkräftemangel die Rede ist, der Softwareentwickler im Zentrum der Aufmerksamkeit.

Aktuell werden oft folgende Begriffe zur (eher groben und zugleich fluiden) Kategorisierung der Entwickler genutzt:

Frontend: Der Developer entwickelt überwiegend Benutzeroberflächen (User Interfaces), etwa Webseiten oder andere Bedienelemente sowie deren Anbindung an den Rest des Programms.Backend: Der Developer entwickelt überwiegend die nicht sichtbaren Teile eines Programms, welche sich um die komplexere Programmlogik sowie die Datenspeicherung kümmert.Fullstack: Ein Developer, der beides kann: Frontend- und Backend-Entwicklung.

Doch das ist nur eine mögliche Klassifizierung. Mindestens ebenso oft wird nach den verwendeten Werkzeugen und Technologien unterschieden. Unter den zahllosen Compilern, Frameworks, Entwicklungsumgebungen, Datenbanken und Betriebssystemen existieren bestimmte Kombinationen von Werkzeugen, die besonders gut miteinander harmonieren. Sehr stark vereinfacht könnte man das mit Bausätzen von Lego, Fischertechnik oder Playmobil vergleichen, wenn auch mit weitaus weniger klaren Abgrenzungen untereinander und einer Unzahl mehr an Kombinationsmöglichkeiten. Diese Sets von Werkzeugen bilden sogenannten »Software-Stacks« oder [23]»TechStacks«. Zur groben Orientierung welches »System« genutzt wird, reicht oft schon ein einzelner Begriff als Bezeichner, wie etwa »Angular«. Oft wird jedoch auch ein ganzer Satz an Technologien angegeben (etwa im Akronym »LAMP« für die Komponenten Linux, Apache, MySQL und PHP).

In jedem IT-Projekt muss irgendwann entschieden werden, welchen TechStack man verwenden will. Dieser muss entweder zu den Fähigkeiten der Entwickler passen, oder die Entwickler müssen die bislang fehlenden Kompetenzen entwickeln. Ist beides nicht möglich, muss das Management sich andere, passende Entwickler suchen. Für Manager ist es diesbezüglich sehr nützlich zumindest zu verstehen, welche Tech-Stacks strukturelle Ähnlichkeiten aufweisen und in welchen Fällen der Unterschied zwischen dem verwendeten TechStack und den Fähigkeiten der Entwickler so groß ist, dass man zwingend neue Entwickler benötigt.

Entwicklungsunterstützung: Quality Assurance (QA), Testmanagement, Testautomatisierung, Tester

Es existiert keine fehlerfreie nichttriviale Software, ganz egal, welchen Aufwand man treibt. Fehlerhafte Excel-Berechnungen, abrupte Börsencrashs und abstürzende Raketen lagen sicherlich nicht (nur) an schlechtem Projektmanagement oder individueller Inkompetenz, sondern an der enormen inhärenten Komplexität von Software.

Noch 2004 gab Steve McConnell in seinem Buch »Code Complete« 15 bis 50 Fehler je Tausend Zeilen Code als Industriedurchschnitt an. Etliche der Projekte, an denen einer der Autoren in den letzten Jahren arbeitete, umfassten mehrere Millionen Zeilen Code. Auch wenn man heute in der Tendenz eher von etwa einem Fehler je Tausend Zeilen Code ausgeht, bleibt ein enormer Spielraum für Qualitätsverbesserungen.

Qualitätssicherung (englisch »Quality Assurance« oder »QA«) ist daher heute ein essenzieller Bestandteil jedes seriösen IT-Entwicklungsprojektes. Grob kann die Tätigkeit in der QA in drei Ebenen unterteilt werden:

Testmanager: Dieser Mitarbeiter definiert den Testansatz. Er gibt vor, wer wann welche Testfälle durchführt, was automatisiert werden soll, über welchen Workflow Testdaten beschafft werden, wie die Testabnahmekriterien festgelegt werden, wie Tests dokumentiert werden usw.Testautomatisierer: Dieser IT-Experte programmiert die automatischen Tests, sowohl der Benutzeroberflächen eines Programms als auch der Schnittstellen (APIs) zu anderen Programmen und gegebenenfalls auch einzelner Komponenten der Anwendung.Tester: Testet und dokumentiert manuell Programme auf Basis explorativer Tests sowie unter Verwendung vorgegebener Testfälle.

[24]Entwicklungsunterstützung: DevOps, Integration

Software wird kaum jemals »am Stück«, quasi als Monolith, hergestellt. In aller Regel besteht Software aus Komponenten, die miteinander in vielfältigster Art und Weise verbunden sein können, etwa statisch durch Linken (vergleichbar dem Zusammenstecken von Lego-Bausteinen) oder dynamisch durch gegenseitige Aufrufe von Diensten der jeweils anderen Softwarekomponente. Die notwendigen Komponenten beinhalten nicht nur selbstgeschriebene Anwendungsteile, sondern auch solche des Betriebssystems, der verwendeten Entwicklungstools oder im Einzelfall sogar spezieller Hardwarebestandteile. Letzteres betrifft insbesondere den sogenannten Embedded-Bereich, in dem spezielle Chips (Microcontroller) für das jeweilige Produkt eigens angepasst (bzw. »eingebettet«) werden. Das wird bei vielen Geräten so gehandhabt: vom Smartphone über die KFZ-Unterhaltungselektronik bis zur Waschmaschine.

Das Zusammenfügen aller notwendigen Komponenten nennt man Integration. Die zuständigen Mitarbeiter wurden naheliegenderweise oft Systemintegratoren genannt. Die Systemintegration war früher zumeist Teil des Aufgabengebiets der Entwickler. Im Zuge von sogenannten Integrationstests wurden die Ergebnisse auch von QA-Mitarbeitern getestet. Als die Anzahl und Komplexität der genutzten Entwicklungskomponenten und Werkzeuge über die Zeit anwuchs, wurde die Aufgaben oft an spezialisierte IT-Experten, eben die Systemintegratoren, übertragen.

Traditionell war die Systemintegration (zumindest für In-Haus-Entwicklungen) der letzte Schritt, bevor die Software an den IT-Betrieb übergeben wurde, der die neue Software dann eben in Betrieb nahm und die tagtägliche Wartung übernahm. In den letzten Jahren setzte sich jedoch die Einsicht durch, dass diese Übergabe vom Entwicklungsteam an das Betriebsteam oft eine Quelle von Problemen war. So zeigte sich oft eine Lücke im Know-how-Transfer und es kam zu einem Bruch in der Verantwortlichkeit. Das führte zu vermeidbaren Zeitverlusten, zu Fehlern aufgrund mangelhafter Kommunikation zwischen den Teams sowie daraus entstehenden Spannungen.

Es galt zu vermeiden, dass Software vom Entwicklungsteam den Kollegen vom IT-Betrieb quasi nur über den Zaun geworfen wird. Ein innovativer, sich rasch ausbreitender Ansatz war »DevOps«. Gab es bis dato für die Softwareentwicklung ausschließlich mit Testdaten arbeitende, nur für Entwickler zugängliche Systemumgebungen, und davon getrennt Produktivsysteme für den realen Einsatz echter Benutzer unter Verwendung realer Daten, so wurde es mithilfe neuer, spezialisierter Tools den Developmentteams ermöglicht, die von ihnen entwickelte Software direkt auch auf Produktivsystemen auszurollen und geeignet zu konfigurieren.

[25]1.2.5Entwicklungssteuerung: Product Owner, Requirement Engineer, Anforderungsmanager, Business Analyst

Die technische Kerntruppe – Entwickler und Architekten – samt der Kollegen in den technischen Unterstützungsfunktionen – DevOps, Quality Assurance – benötigt niemand anderen, um die Software herzustellen. Sie sind in diesem Sinne autonom. Was ihnen fehlt, ist das Wissen, das für eine Software benötigt wird.

Dieses Wissen muss den technischen Teams in Form von Anforderungen zugeführt werden. Aus Sicht der IT-Experten ist es egal, wer ihnen dieses Know-how zur Verfügung stellt, so lange dies für die Techniker verständlich, eindeutig und widerspruchsfrei geschieht.

In den inzwischen seltener anzutreffenden Wasserfallprojekten wurde in einer früheren Projektphase, also noch bevor die IT-Experten zum ersten Mal »in die Tastatur hauen«, zunächst ein Lastenheft, auch Anforderungsspezifikation genannt, erstellt. Dieses wurde dann – nach oft langwieriger Prüfung – an die IT-Teams übergeben zwecks Entwicklung. Für die Erfassung und Formulierung solcher Anforderungen war der Requirements Engineer (Anforderungsmanager) zuständig, der die Brücke zwischen fachlichen Anforderungen und technisch verständlicher Formulierungen ebendieser schlug. In manchen Branchen, etwa in vielen Banken, wurde diese Rolle auch noch allgemeiner als »Business Analyst« (kurz: BA) bezeichnet. Ein Anforderungsmanager hat typischerweise mittels Workshops und Interviews mit den jeweiligen Domänenexperten versucht, das zu lösende Problem sowie die Lösungsanforderungen aus fachlicher Perspektive zu analysieren. Die sich daraus ergebenden Anforderungen an eine gewünschte IT-Lösung wurden detailliert so in technischer Sprache dokumentiert, dass auf dieser Basis eine anschließende Implementierung durch das Entwicklungsteam möglich wurde.

Agile Methoden vermeiden die beschriebene Trennung von Analyse- und Implementierungsphase. Vielmehr wird eine fortwährende intensive Kommunikation zwischen Anforderungsgebern und Implementierern angestrebt. In Scrum handelt es sich dabei um den Product Owner (PO) als Anforderungsgeber einerseits und das Entwicklungsteam als umsetzender Gruppe von IT-Experten andererseits. Der Requirements Engineer arbeitet hierbei dann dem Product Owner zu, und bleibt neben dem PO auch weiterhin ein Scharnier zwischen Fachexperten und IT.

[26]1.2.6Betrieb: Administration, Support

Auch im laufenden Betrieb komplexer Software fallen Aufgaben an, insbesondere

vorhersehbare Routineaufgaben, z. B. reguläre Versionsupdates von Antivirensignaturen oder Sicherheitspatches, regelmäßige Updates von Nutzerdaten, NutzerschulungenAnalysen und idealerweise Lösungen von betrieblichen Störungen; Anpassungen an die sich verändernde betriebliche IT-Landschaft, z. B. der Umstieg auf andere Datenbanken oder die Nutzung neuer Hardware

Auch diese Aufgaben erfordern im Regelfall ausdifferenzierte Rollen. Diese sind meist nach zwei Aspekten zu gliedern:

Nutzerinteraktion: Den Fokus auf Nutzerinteraktion haben Trainer und die Mitarbeiter im Helpdesk bzw. im Support.Technik: Der technische Schwerpunkt wird vor allem von Systemadministratoren, Produktadministratoren und Datenbankadministratoren besetzt.

Die Supporttätigkeiten werden zudem oft nach First-, Second- und Third-Levelsupport unterschieden, die wie nacheinander geschaltete Filter jeweils versuchen, die Mehrzahl der Nutzeranfragen selbst erfolgreich abzuschließen, bevor möglichst wenige ungelöste Probleme an die nächsthöhere Ebene weitergegeben werden. In der dritten (oder gegebenenfalls sogar noch höheren) Stufe ist es nicht selten, dass für solche seltenen und schwierigen Ausnahmefälle auch direkt ein Entwickler der jeweiligen Software dem Support aushilft.

1.2.7Der ganze Rest: Wen man sonst noch braucht

Scrum-Master und agile Coaches

Scrum-Master haben keinerlei IT-spezifischen Aufgaben, sondern sind vor allem als Moderatoren und »Master of Ceremony« für das Einhalten der Methodik zuständig. Zudem unterstützen sie das Scrum-Team, indem sie Hindernisse (impediments) auf dem Weg zum Projekterfolg aus dem Weg zu räumen. Scrum-Master sind vor allem in der Einführungsphase nützlich, betreuen oft mehr als ein Team und müssen keineswegs zwingend einen beruflichen IT-Hintergrund haben. Einige der besten Scrum-Master, mit denen wir zusammenarbeiteten, waren Geisteswissenschaftler.

Der Wortbestandteil »Master« lässt annehmen, dass dem Scrum-Master in der Scrum-Methodik eine überragende Bedeutung zukommt. Dies ist nicht der Fall; der Scrum-Master ist eher vergleichbar mit einem Katalysator, der eine gute, schnelle und strukturierte Arbeit ermöglicht und vereinfacht. Unserer Erfahrung nach kommen [27]insbesondere erfahrene High-Performance-Teams oft ganz hervorragend ohne einen dedizierten Scrum-Master aus.

Agiler Coach ist eine allgemein gehaltene Rollenbezeichnung für Spezialisten, welche Management und Mitarbeiter im Rahmen des Changemanagements dabei unterstützen, bestehende Prozesse geeignet umzubauen und ein agiles Mindset in den Köpfen zu verankern.

Der Scrum-Master als Scrum-Master an sich: Erfahrungsbericht eines langjährigen IT-Freelancers

Ich habe in meiner Karriere schon mehr als ein Dutzend Scrum-Master erlebt – gute wie schlechte. Spannend ist zunächst die Frage: Kommen sie ursprünglich aus der IT oder nicht? Einer der besten war ein promovierter Psychologe: Seine People Skills waren einfach überwältigend gut. Der Schlechteste hat das Wort »Master« in Scrum-Master etwas zu wörtlich genommen und sich als Chef aufgespielt. Wenn das Team das merkt, überlebt so einer nicht lange.

Zum Teil hängt die Qualität der Scrum-Master auch davon ab, wie sie eingesetzt werden.

Wenn ein Scrum-Master vier Teams gleichzeitig betreuen soll, kann das nicht funktionieren.

Überdurchschnittlich häufig habe ich weibliche Scrum-Master als besonders gut erlebt.

Vielleicht haben diese im Allgemeinen dann doch eine höhere interpersonelle Kompetenz.

Das Gefühl jemand zu haben, der einen versteht, tut sehr gut.

Alter und Seniorität erscheinen mir gerade bei der Einführung von Scrum wichtig. Hier bedarf es auch guter Changemanagement-Skills. In existierenden Teams habe ich das Alter als weniger wichtiges Kriterium erlebt.

Wo habe ich die höchste Wertschöpfung in dieser Rolle erlebt? Bei jenen Personen, die Scrum einführen und auch die Rolle als Agile Coach gut ausfüllen. Und bei jenen, die einen wirklich breiten Rücken hatten und die Konflikte mit dem Management vom Team ferngehalten haben. Übrigens sind meiner Meinung nach nur Anfänger davon überzeugt, dass die Methoden megawichtig sind. Meiner Erfahrung nach ist der Mindset viel bedeutender. Es gibt ja zum Beispiel den »Retromat«, bei dem man sich zig Methoden wie man eine Retrospektive machen kann, runterladen kann.

IT-Compliance und IT-Governance

Mitarbeiter der IT-Compliance sorgen dafür, dass die IT bestimmte Regeln einhält. Oft als Untermenge der IT-Governance aufgefasst, sind durch die Compliance insbesondere externe gesetzliche Regelungen (z. B. die DSGVO) aber auch unternehmensinterne Regelungen (z. B. aus dem Bereich Controlling) zu überwachen, oft im Rahmen gegebener Rahmenwerke wie etwa COBIT (»Control Objectives for Information and Related Technology«, ursprünglich verfasst vom Verband der IT-Auditorem ISACA). Insbesondere in sensitiven Bereichen (etwa sicherheitskritischer Software oder in der Verarbeitung besonders sensitiver persönlicher Daten) beinhaltet diese Überwachung auch operative Eingriffe in die Softwareentwicklung, sodass in größeren IT-Entwicklungsprogrammen auch dedizierte IT-Compliance-Mitarbeiter die Entwicklung überwachen und unterstützen.

[28]Security Analyst, Security Engineer, Security Architect

Beschreibungen von Rollen, die sich schwerpunktmäßig mit Sicherheitsaspekten der Programmierung beschäftigen, erhalten meist den Vorsatz »Security« vor ihrer Rolle.

Am verbreitetsten sind Security Analysten, die sich vor allem mit der Analyse und Beurteilung möglicher Schwachstellen in der IT-Infrastruktur und der Software beschäftigen, um vorbeugend geeignete Lösungen und Maßnahmen vorzuschlagen. Des Weiteren beschäftigen sie sich mit der Analyse von sicherheitsrelevanten Vorkommnissen (z. B. Einbruch in die Computersysteme durch unautorisierte Personen), um den Schaden zu beurteilen, Ursachen zu analysieren und sich daraus ergebende Gegenmaßnahmen zu identifizieren.

IT-Management, Projektleitung

Last but not least gibt es auch in der IT das Führungspersonal. Projektleiter oder Projektmanager sind Rollenbezeichnungen, welche in agilen Umgebungen meist nicht vorgesehen sind. In Scrum etwa leitet niemand das Projekt, und die Projektmitarbeiter werden auch nicht gemanaged.

Doch auch in agilen Umgebungen verbleiben notwendige, zu erfüllende Aufgaben, wenn auch außerhalb des agilen methodischen Rahmens. Dazu gehören insbesondere die Formulierung der Projektvision als gemeinsames langfristiges Ziel, die Bereitstellung der für das Projekt notwendigen Mittel, das Anheuern passender Mitarbeiter sowie die Vertretung des Projekts innerhalb der Organisation.

1.3Wovon gerade alle sprechen: Aktuell wichtige Schlagworte in der IT

1.3.1Blockchain

Wir definieren Blockchain als eine erweiterbare, manipulationssichere Liste von Datensätzen, die Transaktionen chronologisch und unveränderlich speichert. Meist, jedoch nicht immer, ist diese Datenliste verteilt, also auf vielen Computern, gespeichert und öffentlich verfügbar. Die gespeicherten Transaktionen sind ebenfalls öffentlich durch interessierte Parteien verifizierbar. Trotz aller medialen Aufmerksamkeit muss dabei gesagt werden: Es existiert keine einheitliche Definition von Blockchain!

Je nach Interesse des Vortragenden wird die Blockchain irgendwo innerhalb eines Spektrums erwähnt werden, welches von »simpler Erweiterung der Idee eines Buchführungsjournals« bis hin zur »ökonomisch wichtigsten Erfindung der letzten Jahrzehnte« reicht.

[29]1.3.2Big Data

Big Data bezeichnet wirklich große Datensammlungen, von denen weder offensichtlich ist, wie man sie strukturieren und auswerten soll, noch, welche Algorithmen und Werkzeuge dafür notwendig sind. In vielen Fällen ist vorab sogar zunächst unklar, was für einen unmittelbaren Nutzen diese haben könnten. Man hofft jedoch, dass sich die Anwendung aus den noch unbekannten Ergebnissen ergibt. Und das klappt oft sogar.

1.3.3Bring Your Own Device (BYOD)

Bring Your Own Device (deutsch: Bring dein eigenes Gerät) bezeichnet die Möglichkeit, private mobile Endgeräte in den Netzwerken von Organisationen zu nutzen. Eigentlich eine schöne Sache, aber organisatorisch und unter Sicherheitsaspekten eine immense Herausforderung, da jeder neben seinem Lieblingsgerät auch seine eigene Software, seine eigenen Antivirenprogramme und seine eigenen Viren mitbringt. Andererseits trifft man immer wieder Mitarbeiter (und insbesondere IT-Experten), die es als signifikanten Benefit sehen, wenn es ihnen erlaubt wird, ihren individualisierten Lieblingscomputer zu nutzen.

1.3.4Cloud

Die Grundidee der Cloud: Der Computer steht nicht mehr beim Unternehmen im Büro, Keller oder Rechenzentrum, sondern bei jemand anderem, z. B. bei Amazon, Google oder Microsoft. Derjenige muss sich auch um den Computer kümmern, was ihm aber leichtfällt, da er Millionen davon hat. Bei diesen immensen Volumina entstehen ökonomische Skaleneffekt, d. h. es wird für die Cloud-Betreiber sehr günstig, solche riesigen Rechenzentren zu betreiben.

Wenn der Cloud-Kunde schnellere, größere und bessere Computer braucht (oder einfach auch nur ganz viele davon), besteht die Möglichkeit, diese vom Betreiber der Cloud innerhalb von ganz kurzer Zeit zu erhalten. Die Computer gehören den Kunden aber meist nicht mehr. Stattdessen mieten sie ihn entweder ganz oder sie zahlen gleich nur nach tatsächlicher Nutzung.

1.3.5Cyber-

Das Präfix »Cyber-« stammt vom Wort »Cybernetics« (deutsch: Kybernetik) ab. Die Kybernetik beschäftigt sich mit der Erforschung von Regelungs- und Steuerungsmechanismen. Inzwischen wird »Cyber-« jedoch vor allem als Verweis auf den »Cyberspace« [30]genutzt, einem durch Computer erzeugten virtuellen Raum bzw. eine virtuelle Realität. Entsprechend beziehen sich Wortneubildungen wir Cybersecurity, Cybercrime, Cyberdefense, oder Cyberwar auf IT-Vorgänge in virtuellen Räumen wie etwa dem Internet.

1.3.6Hybrid Computing

Hybride vereinen die Eigenschaften zweier unterschiedlicher Systeme oder Lebewesen. Im Kontext des Cloud-Computing ist damit eine gleichzeitige Nutzung verschiedener Modelle des IT-Betriebs gemeint. So können Rechen- und Speicherkapazitäten zu einem Teil in der sogenannten Public-Cloud vorgehalten werden (wo sie standardisiert von den Cloud-Betreibern angeboten und gemanagt werden), zu einem anderen Teil in der Private-Cloud (einer speziell auf die Bedürfnisse des Nutzers angepassten Cloud), und nicht zuletzt auch »on premise«, d. h. auf Computern vor Ort beim Nutzer.