Sehen wir uns einen typischen Fall an: In einem Informatikunternehmen stöhnen Abteilungen, dass sie personelle Unterstützung brauchen, und nach einigen Monaten ringt sich die Personalabteilung (HR) endlich dazu durch, eine Stellenanzeige zu schalten. Um es allen recht zu machen, werden die Anforderungen der Abteilungen gesammelt. Abteilung A sucht einen AWS-Cloud-Spezialisten mit Netzwerkkenntnissen, Security, Ansible und GitHub, Abteilung B braucht einen Java-Entwickler mit Jakarta-EE-Erfahrung sowie Administratorenfähigkeiten für Oracle-Datenbanken, und Abteilung C wünscht sich einen DevOps-Ingenieur, der fit in Debian-Linux ist, viele Jahre Jenkins-Erfahrung hat und weiß, wie sich Spring-Boot-Applikationen native als Microservices auf die Cloud deployen lassen.
Was kommt dabei heraus? Die Eier legende Wollmilchsau. Der Jakarta-EE- und Spring-Profi, der sich mit Microservices sowohl auf AWS als auch auf GitHub als auch auf Jenkins austoben kann, der mit Linux-, Netzwerk- und Oracle-Datenbankadministration gleichermaßen zurechtkommt und auch sonst "jahrelange Erfahrung" vorweisen kann in einem Dutzend diverser Nebentechnologien, die hier aus Platzgründen gar nicht aufgezählt sind. Dass diese Person Informatik studiert haben und nebst Java und TypeScript auch noch andere elementare Programmier- und Skriptsprachen beherrschen muss, geht in diesem Dickicht an Anforderungen fast schon unter.
Konsequenzen und wichtige Fragen
Wir alle kennen solche unrealistischen Stellenausschreibungen, doch was sind die Konsequenzen?
- Wenn es einen solchen Bewerber wirklich geben sollte, dann wird er wohl eine entsprechende Honorarforderung stellen. Diese liegt dann aber oft außerhalb des Budgets.
- Der Bewerber trägt in seinem Lebenslauf genauso dick auf wie das ausschreibende Unternehmen. War die Kandidatin oder der Kandidat mal in einer Firma beschäftigt, die auch etwas mit AWS, Oracle und Angular gemacht hat? Gleich in den CV schreiben! Es ist egal, ob man damit wirklich zu tun hatte oder es „nur mal gesehen hat“. Überprüfen kann sowieso keiner, was in der alten Firma lief.
- Auf der anderen Seite gibt es die "Bescheidenen", die – ganz im Gegensatz zu obiger Person – unter dem Impostor-Syndrom leiden, bei dem "Betroffene von massiven Selbstzweifeln hinsichtlich eigener Fähigkeiten, Leistungen und Erfolge geplagt werden und unfähig sind, ihre persönlichen Erfolge zu internalisieren" [WikiHSS]. Sie sehen in der Ausschreibung ein paar Technologien, von denen sie noch nie etwas gehört haben oder die sie zwar schon kennen, aber nicht aus dem Effeff beherrschen. Das reicht für solche Menschen meist schon aus, um von einer Bewerbung abzusehen.
Jedes Unternehmen muss daher für sich beantworten:
- Will es lieber mehr Geld in die Hand nehmen (Kandidat Nr. 1), den grellen Lichtblitz (Kandidat Nr. 2) oder den ungeschliffenen Diamanten (Kandidat Nr. 3) beschäftigen?
- Ist es wirklich zielführend, Stellenanzeigen zu schalten, auf die sich guten Gewissens bewerben soll, wer nur 60 Prozent der Anforderungen erfüllt? Welchen Charakter – und welches Geschlecht – an Kandidaten zieht es an, wenn schon im Bewerbungsverfahren regelrecht erwartet wird, schriftliche Anforderungen nicht für bare Münze zu nehmen?
- Was sagt das "Technologiedickicht" über das Unternehmen selbst aus? Versteht die HR-Abteilung überhaupt, was sie da Widersprüchliches von sich gibt? Muss die Firma nicht hochgradig chaotisch sein, wenn es ihr nicht mal gelingt, ihre Datenbanken, DevOps-Umgebungen und Programmiersprachen zu konsolidieren?
Suchen wir also nach Lösungen, nachdem der Pain Point jetzt ausgiebig bearbeitet wurde. Die folgende Aufzählung kann natürlich nur meine subjektive Sicht wiedergeben. Dennoch behaupte ich, in den letzten 15 bis 20 Jahren durchaus einiges gesehen, miterlebt und mich darüber ausgetauscht zu haben, inklusive des Auf- und Abstiegs diverser Architekturparadigmen, der Agilitätsmethodik sowie der dämmernden Erkenntnis, dass das alles wohl doch nicht die ultimativen Lösungen für alle Probleme sind.
Ein kurzer Exkurs zur Agilität
Habe ich in den letzten Jahren diese Aussage noch unter vorgehaltener Hand gemacht, treffe ich sie heute öffentlich: Die Summe aller Umtriebe rund um das Thema „Agilität“ hat der Informatik meines Erachtens mehr geschadet als genützt.
Klar gibt es viele positive Errungenschaften: Endlich wird nicht mehr ein ganzes Jahr spezifiziert und drei Jahre entwickelt, ehe dann mit dem Monsterprodukt das böse Erwachen kommt, "weil der Kunde sich das eigentlich ganz anders vorgestellt hat". Endlich werden die Teammitglieder dazu angehalten, mehr miteinander zu reden. Und natürlich ist es sinnvoll, mit seinen Methodiken schneller auf sich ändernde Umgebungsbedingungen reagieren zu können.
Das alles hat aber auch seinen Preis. Neben eigentlichen monetären Kosten für Agile Coaches und diverse Umstrukturierungen haben agile Methoden wie Scrum nicht nur gefühlt, sondern auch als schlechte Praxis in der Literatur belegt hervorragende "Ausreden" geboten, um unstrukturiert arbeiten zu können: Ein Minimum Viable Product (MVP) geht vor sauberer Softwarearchitektur, und Dokumentation braucht es sowieso nicht mehr [Zoe22]. Der geistige Horizont für ein Softwarefeature beträgt nur noch wenige Tage, maximal einen Sprint, und reicht nicht mehr über den Tellerrand hinaus: Code reverseengineeren, Feature hinzufügen, und sobald der Test grün ist, Deckel drauf und fertig. Multipliziert man dieses Vorgehen mit einigen Tausend, dann ist der unwartbare Flickenteppich komplett.
Verstärkt wird das Ganze durch den Anspruch, dass jeder (oder zumindest jedes Team) alles können müsse: Frontend, Backend, Datenbanken, Infrastruktur und sogar Build-Pipeline – jeder darf und soll alles anpassen dürfen. So sehr solche liberalen Einstellungen auch verständlich sein mögen, so sehr sind sie ein Albtraum für Qualität, Wartbarkeit und Sicherheit. Denn wie heißt es so schön: "Viele Köche verderben den Brei."
Aus meiner didaktischen Ausbildung und Erfahrung weiß ich: Menschen funktionieren nicht so. Die kognitive Kapazität eines jeden Menschen ist beschränkt. Und wer erwartet, dass sich (hier) Entwickler in allen Bereichen gleich gut auskennen, muss davon ausgehen, dass es in vielen Bereichen höchstens zum Mittelmaß reicht, ganz getreu dem Motto: "Wer alles macht, macht nichts richtig."
Agile Coaches werden beim Lesen meiner Worte jetzt wohl einwenden, dass das alles nicht stimmt, und "man es nur richtig machen müsse". Das Problem ist, dass schon seit über einem Jahrzehnt probiert wird, "es richtig zu machen". Keine IT-Konferenz, keine IT-Fachzeitschrift und keine IT-Firma, bei der das Thema Agilität nicht mit erstaunlicher Regelmäßigkeit durchgekaut wird. An fehlenden Informationen und fehlendem Bemühen liegt es also sicher nicht.
Neuerdings fordern Agile Coaches sogar einen Reset. Das in der Vergangenheit war alles nichts, Ihr müsst richtig agil denken und handeln! Und so dreht es sich im Kreis. Aber jetzt mal ehrlich: Ist das Thema nicht irgendwann ausgelutscht?
1. Lösungsansatz: Spezialisieren
Der größte Feind der Agilität ist das Silo. Silodenken in der Informatik bezieht sich auf die isolierte Aufbewahrung von Informationen oder Ressourcen in separaten, abgeschotteten Bereichen, die eine effektive Kommunikation und Zusammenarbeit erschweren. Typische Aussagen, wie wir sie wohl alle kennen, lauten: "Dafür sind wir nicht zuständig" oder "Das macht bei uns Abteilung X".
Ich will keinesfalls eine Wiederkehr der alten Silozeiten gutheißen, aber mich doch dafür aussprechen, den Mut zu haben, technische Kompetenzen und Verantwortungen wieder auf einzelne Experten zu verteilen. Diese können zum Beispiel Datenbank-, Frontend-, Build-Pipeline-, AWS-, aber auch Dokumentations- oder Testexperten sein. Wie sie aufgeteilt werden, ist eine organisatorische Frage. Zu viele Experten pro Thema sollten es allerdings nicht sein, weil sonst die eigentliche Expertenrolle verloren geht. Im Gegensatz dazu ist es durchaus möglich, dass eine Person zwei oder drei Expertenstatus innehat.
Bleiben wir bei den Datenbankexperten: Dann sind sie es, die sich mit den Interna und allen Oracle-Eigenheiten bestens auskennen, die die Server und Schemata im Überblick haben, die Konventionen bei Namensgebungen und Skripten formulieren und durchsetzen, sowie die einzigen, die administrativen Zugriff auf die Datenbank haben. Bedingungen sind eine uneingeschränkte Hilfsbereitschaft der Experten und keinerlei Kommunikationsbarrieren. Wer sich in seiner Rolle verkriecht und nur via Ticketsystem mit drei Wochen Verzögerung antwortet, hat das alte Silowesen in das Unternehmen zurückgebracht. Letztlich ist das aber eine Führungsfrage.
Übertragen auf Bewerberinterviews: Muss ein Kandidat wirklich alles können? Oder ist es nicht sinnvoller, ihn nach seinen zwei bis drei (potenziellen) Expertenrollen zu befragen, und ihn dann dort einzusetzen? Ist seine oder ihre Expertenrolle gerade nicht gefragt? Kein Problem! Als Experte muss man weder geboren sein noch unzählige Jahre „Erfahrung“ vorweisen können. Entscheidend ist, dass man bis auf Weiteres ein abgestecktes Gebiet hat, in das man sich vertiefen und mit Kompetenz ausgestattet agieren kann.
Dabei ist der Expertenstatus meines Erachtens schnell erreicht: Grundlegendes SQL kann jeder, und sich jetzt zum Beispiel mit den Microsoft-SQL-Server-Eigenheiten vertraut zu machen, ist auch kein Hexenwerk. Auch das Studieren der hausinternen Jenkins-Pipeline darf kein Ding der Unmöglichkeit sein. Ich behaupte, dass – ungestörte und konzentrierte Einarbeitungszeit vorausgesetzt – 40 bis maximal 80 Stunden ausreichen, um zu den kompetentesten fünf Prozent der jeweiligen Technologie zu gehören – zumindest hausintern. Womit wir schon beim nächsten Thema wären.
2. Lösungsansatz: systematisches Lernen
Es ist wichtig zu verstehen, dass sich meine Behauptung jeweils auf eine Nebentechnologie wie Hibernate, Apache Maven oder Jenkins und nicht auf eine Haupttechnologie wie Java , Spring oder Netzwerk-Administration bezieht. Ich definiere einen Experten als jemanden, der sich sattelfest in seinem Gebiet bewegt, der die Möglichkeiten und Grenzen seiner Technologie kennt und darin mit klarem Abstand kompetenter als die anderen Mitarbeiter ist.
Darf er oder sie Wissenslücken haben? Selbstverständlich! Niemand kann alles wissen. Der hausinterne Docker-Experte muss also weder vom Hersteller Docker Inc. abgeworben werden noch "10 Jahre Docker-Erfahrung" vorweisen können. Jemand mit akademischem Hintergrund muss das allerdings nach spätestens 40 Stunden Studium im Detail verstanden haben, sonst ist entweder an dieser Person oder an der hausinternen Docker-Infrastruktur etwas faul.
Was sagen im Gegenzug "X Jahre Erfahrung in Technologie Y" aus? Wird damit auch der Kaffeeschlürfer vom Vollzeitarbeiter unterschieden? Lässt sich sicherstellen, dass eine Person eine Technologie auch wirklich in ihrer Gesamtheit und nicht nur in einem kleinen Teilbereich oder einer eigenartigen Anwendung aus der letzten Firma beherrscht
Fehlende Fachkenntnisse in einigen Nebentechnologien sollen kein Maßstab sein. Diese lassen sich schnell "nachrüsten". Viel wichtiger ist doch, welchen Bildungshintergrund eine Person mitbringt und ob und wie sie sich in ihrer Laufbahn weitergebildet hat. Dabei ist weniger entscheidend, was genau die Inhalte waren, sondern vielmehr, ob sich diese Person effektiv Wissen aneignen kann und will, ob sie autodidaktisch veranlagt ist, ob sie sich konzentrieren und Ausdauer zeigen kann und ob sie für sich selbst einen Anspruch auf „objektive Richtigkeit“ in den jeweiligen Technologien erhebt.
Namhafte IT-Zertifikate sind in meinen Augen ein hervorragendes Gütesiegel für einen definierten Wissensstand. Ich weiß, dass die Meinungen zu Zertifikaten sehr weit auseinandergehen, erstaunlicherweise sind es aber meist nur diejenigen, die keine Zertifikate haben, die sich negativ darüber äußern. Prüfungsfreie Zertifikate aus LinkedIn- und Udemy-Feierabendkursen sind in der Tat relativ wertlos, da ihnen der Leistungsnachweis fehlt. Qualitativ hochwertige Zertifikate hingegen bestehen aus einem sinnvoll zusammengestellten Curriculum mit realistischen Prüfungsaufgaben. Soweit ich von mir sprechen kann, konnte ich mir durch die "erzwungene" Vorbereitung immer einen enormen Wissenszuwachs aneignen, den ich ohne den Druck einer Zertifizierungsprüfung wohl nicht auf mich genommen hätte. Namhafte Zertifikate (meist vom Hersteller direkt) stellen zudem sicher, dass wirklich die wichtigen und aktuellen Themen behandelt werden und unwichtige oder veraltete Themen rausfliegen. Sie sind somit auch gute Trendbarometer.
Von den im Anstellungsprozess involvierten Personen und den Vorgesetzten darf erwartet werden, dass sie die einschlägigen Zertifizierungen kennen. Gute Zertifikate können in der Tat viele Jahre an "Erfahrung" wettmachen, denn bekanntlich gilt: "Es gibt nichts Praktischeres als eine gute Theorie."
Übertragen auf Bewerberinterviews: Der wirklich objektive Maßstab zum Kenntnisstand einer Technologie eines Bewerbers ist ein technisches Assessment. Das können Unternehmen selbst gestalten, lässt sich heute aber auch über Drittanbieter einkaufen (zum Beispiel bei [CodB], [CodG] oder [Codi]).
Viel aussagekräftiger als alle Buzzwords im CV erachte ich, dem Kandidaten beim Lösen längerer Aufgaben zuzusehen. Kommt er oder sie auch ohne Copy & Paste, Code Completion, Stack Overflow und Copilot zurecht? Hat er Clean Code nur erwähnt, weil es gut klingt, oder lebt er das wirklich? Welche namhafte IT-Literatur kennt er und kann sie inhaltlich im Kern wiedergeben? Liest er Fachbücher? Und Hand aufs Herz: Welche Rolle spielen IT-Bücher im eigenen Unternehmen?
3. Lösungsansatz: Schulungen
Wie werden Mitarbeiter mit neuen Technologien vertraut gemacht? Ich kenne bis heute leider nur den Ansatz, ins kalte Wasser geworfen zu werden und sich dann über Monate bis Jahre mit Halbwissen, Google, Stack Overflow und vielen Wissensfragmenten vom Hörensagen durchzuwurschteln. Außer man bringt die Eigenmotivation auf und liest in seiner Freizeit ein entsprechendes Fachbuch oder besucht eine externe Schulung, wobei offenbleiben kann, wer das bezahlt.
Noch nie habe ich (als Teilnehmer) firmeninterne Bootcamps erlebt, bei denen man als Mitarbeiter an die Hand genommen und systematisch in die verwendeten Technologien eingearbeitet wird: "Schaut her, das ist unsere Build-Pipeline. Am Vormittag lernt ihr Allgemeines zu GitLab. Am Nachmittag zeige ich euch den Aufbau, wie wir ihn bei uns in der Firma haben, samt aller Eigenheiten. Auf unserem Wiki ist das alles auch noch mal beschrieben. Ihr bekommt ebenfalls dieses Buch, mit dem wir in der Vergangenheit sehr gute Erfahrungen gemacht haben. Für uns im Haus sind insbesondere die Kapitel 3, 5 und 8 wichtig."
Es liegt auf der Hand, welche Variante effizienter ist. Selbst wenn ein ganzer Monat in reine Technologieschulungen investiert würde, wäre das finanziell und qualitätsmäßig immer noch attraktiver, als weitere Monate (vergeblich) auf den Wunschkandidaten zu warten oder die Mitarbeiter für viele kommende Monate und Jahre ungeschult herumwurschteln zu lassen.
Schulungen lassen sich schubladenfertig bei externen Schulungsanbietern besuchen oder werden vor Ort im eigenen Unternehmen durchgeführt. Bei Letzterem besteht die Wahl zwischen einem externen Schulungsdienstleister, der auch gerne individuelle Schwerpunkte berücksichtigt, oder selbst durchgeführten Schulungen. Zu eigenen Schulungen sei aber bemerkt, dass der Vorbereitungsaufwand, insbesondere für eine didaktisch ausgereifte Schulung, beträchtlich sein kann.
Ein gutes Schulungsprogramm stellt sicher, dass sich die Teilnehmer auf die wirklich wichtigen Themen konzentrieren können. Durch Übungen können sie das Erlernte gleich selbst ausprobieren, umgehend Rückmeldung erhalten und so besser verinnerlichen. All das können Internetrecherchen, "Hacken" und Online-Feierabendkurse nicht bieten. Effizienter als mit individuellen Schulungen kommt ein Unternehmen wohl nicht ans Ziel.
4. Lösungsansatz: Softwaredokumentation
Zu Softwaredokumentation und ihrer Begründung habe ich in den letzten beiden Jahren einiges geschrieben und Vorträge gehalten [HeiJS22] [HeiITS23] [HeiSPS23]. Das Stellenportal SwissDevJobs hat letztes Jahr seine Reichweite von damals 18 000 Followern auf LinkedIn für eine kleine von mir erstellte Umfrage zur Verfügung gestellt (siehe Abbildung 1).
Abb.1 : LinkedIn-Umfrage zu Softwaredokumentation [SDJ23]
Auf die Frage "What is the state of the software documentation at your workplace?" sind von den knapp 300 Umfrageteilnehmern demnach nur 22 Prozent der Ansicht, dass es gut um ihre Dokumentationssituation bestellt ist ("We are doing pretty well :-)"). 78 Prozent hingegen haben offenbar noch nie etwas von Softwaredokumentation gehört ("Software what?"), wissen um ihr veraltetes Firmenwiki ("Our wiki is outdated…") oder sitzen dem längst widerlegten Trugschluss auf, dass allein der Quellcode als Dokumentation ausreichend sei ("Code is the documentation!").
Auch ich habe als Softwareentwickler immer wieder gesehen, wie gefühlt 95 Prozent der Entwicklungszeit damit verschwendet wird, undokumentierten Quellcode gedanklich zu "dekompilieren". Das ist bei unkommentierten Klassen schon schlimm, bei ganzen Softwarearchitekturen geradezu unverantwortlich. Derartige Sisyphusarbeit ist nicht nur hochgradig ermüdend, sondern auch sehr zeitintensiv, fehleranfällig und damit teuer. Wer zu Zeiten des Fachkräftemangels seine Entwickler wie Aschenputtel Erbsen suchen lässt, darf sich über fehlende Mitarbeiter und Effizienz nicht wundern.
Als IT-Unternehmen muss das Thema Softwaredokumentation unbedingt auf die Tagesordnung! Es ist die einzige verlässliche Versicherung gegen Know-how-Verlust, ausufernde Einarbeitungszeiten und Zeitverschwendung durch Reverse-Engineering. Die Kompetenz "Dokumentation" gehört in jede IT-Stellenanzeige und sollte im Rahmen eines Assessments unbedingt geprüft werden. Kann eine Person einen technologischen Sachverhalt oder eine Architektur mündlich wie schriftlich verständlich beschreiben? Das ist für einen Entwickler mindestens genauso wichtig wie die eigentliche Programmiertätigkeit.
Fazit
Fehlende Nebentechnologien lassen sich mit vertretbarem Zeitaufwand nachlernen, überfachliche Kompetenzen eher nicht. Ist das Material des Rohdiamanten (Bewerbers) von guter Qualität, dann fehlt ihm letzten Endes nur noch der Feinschliff. Mit einer Organisation aus fachdiversen Experten, systematischen Lernkonzepten, einem zielführenden Schulungsprogramm und der Forcierung von Softwaredokumentation hat es ein IT-Unternehmen selbst in der Hand, nach welchem Muster der Schliff erfolgen soll. Der Aufwand hierfür ist überschaubar, das Resultat hingegen mehr als vielversprechend.
Bei der Vielzahl der heute verfügbaren IT-Technologien und deren nahezu unendlichen Kombinationsmöglichkeiten ist es allein mathematisch schon so gut wie ausgeschlossen, den idealen Match zu finden. Das hat aber nichts mit fehlenden Fachkräften zu tun, sondern mit teilweise widersinnigen Anforderungen, die überfachliche Kompetenzen nicht von grundlegenden Technologien, und jene wiederum nicht von einfach zu erlernenden Nebentechnologien unterscheiden. Ist sich ein Unternehmen erst einmal bewusst, dass es mit dem Anforderungsprofil einer Stellenanzeige im Grunde ein Bild seiner eigenen internen Organisation abgibt, und nimmt es die entsprechenden Anpassungen vor, dann klappt es sicher auch mit der Fachkräftesuche.
Weitere Informationen
[CodB] Coderbyte, www.coderbyte.com
[CodG] CodinGame, www.codingame.com/work/
[Codi] Codility, www.codility.com
[HeiITS23] C. Heitzmann, Dokumentation wie Code behandeln – Auszeichnungssprachen in der Softwaredokumentation, in: IT Spektrum, 4/2023, SIGS DATACOM, www.sigs.de/artikel/auszeichnungssprachen-in-der-softwaredokumentation
[HeiJS22] C. Heitzmann, Javadoc mit Stil, in: JavaSPEKTRUM, 6/2022, SIGS DATACOM, link.simplexacode.ch/ne6c
[HeiSPS23] C. Heitzmann, Documenting Python Code, Swiss Python Summit, 2023, link.simplexacode.ch/jwh6
[SDJ23] LinkedIn, SwissDevJobs, What is the state of the software documentation at your workplace?, 2023, www.linkedin.com/posts/swissdev-jobs_activity-7112353654023553024-BQYI
[WikiHSS] Wikipedia, Hochstapler-Syndrom, de.wikipedia.org/wiki/Hochstapler-Syndrom
[Zoe22] S. Zörner, Softwarearchitekturen dokumentieren und kommunizieren, 3. Auflage, Hanser, 2022
