Fachkräftemangel? IT-Experten kommen jetzt aus dem digitalen globalen Home-Office
Als Microsoft nach der LinkedIn-Übernahme ankündigte, mit GitHub für stolze 7,5 Milliarden US-Dollar eine IT-zentrierte Community zu übernehmen, war die Recruiting-Branche in heller Aufregung über die möglichen Implikationen. Will Microsoft lediglich Konsumenten-Gruppen für ihre B2C-Produktpalette wie Windows oder Office durch diese Akquisition gewinnen oder stehen in diesen Communities potentielle qualifizierte Kandidaten für das Recruiting durch Arbeitgeber zur Verfügung? Gibt es nach der Google Job Discovery bald auch eine Microsoft Job Discovery?
Die Übernahme-Meldung richtete die Scheinwerfer der Bling-Bling-Publicity auch auf eine andere Frage: Wer oder was ist Github, welche Vorteile bringt die Open-Source-Methode für die Software-Entwicklung? Und viel wichtiger noch für das Recruiting in ganz engen Arbeitsmärkten: Haben Remote-Work-Communities das Potential, den Fachkräftemangel im IT-Sektor nachhaltig zu beeinflussen? Wie funktionieren Open-Source-Community in der Gig-Economy?
Crosswater Job Guide sprach mit Carsten Bleek, Gründer und Geschäftsführer von Cross-Solution GmbH in Frankfurt über diese Zusammenhänge.
Crosswater Job Guide: Worin besteht eigentlich der Unterschied zwischen proprietärer Software-Entwicklung und dem Open-Source-Konzept?
Carsten Bleek: Augenscheinlich ist es die Sichtbarkeit des Quellcodes. Auf den ersten Blick also ein marginaler Unterschied. Aber er führt zum entscheidenden Punkt. Und zwar die Art und Weise der Software-Entwicklung.
Proprietäre Software wird immer intern entwickelt. Im Gegensatz dazu geschieht die Entwicklung bei Open Source öffentlich. Interne Entwicklung für sich genommen ist nicht negativ. Apple entwickelt fantastische Software. Bei Software Updates auf meinem Handy gab es noch nie Probleme. Das muss gute Software sein. Jetzt hat Apple aber auch genügend Entwickler, um Qualität bei einer internen Entwicklung zu gewährleisten.
Anders sieht es aus bei Unternehmen mit kleinen IT Abteilungen. Wenn die intern entwickeln, bleibt Qualität häufig auf der Strecke. Es kommt zu Aussagen wie „Dokumentation oder Tests können wir später machen“. Dabei wissen wir doch, dass sie später nie gemacht wird. Bei der internen Entwicklung steckt man häufig in dem Teufelskreis, dass man zu wenig lokale Entwickler hat, um ein Ziel in time zu erreichen. Der Zeitdruck, vielleicht vom Kunden vorgegeben, zwingt die interne Entwicklung manchmal Dokumentation auf Später zu verschieben.
Bei der öffentlichen Entwicklung existiert der Engpass an Manpower nicht, weil man sich nicht auf lokale Entwickler beschränken muss.
Crosswater Job Guide: Welches sind die wichtigsten Merkmale der Open-Source-Entwicklung?
Carsten Bleek: Das wichtigste Merkmal ist der öffentliche Quellcode. Weil das die Arbeitsweise ändert. Man benimmt sich in der Öffentlichkeit anders, als in den heimischen 4 Wänden. So ist das auch bei der Software Entwicklung. Wenn Code geschrieben wird, der öffentlich einsehbar ist, wird ein Entwickler ein größeres Augenmerk auf die „Schönheit“ seines Codes verwenden, als bei der proprietären Entwicklung. Ich glaube, viele anderen Merkmale wie bessere Dokumentation, kürzere Entwicklungszeit oder effizientere Kommunikation sind nach einiger Zeit Folge des öffentlichen Quellcode’s.
Aber man darf natürlich nicht den Fehler machen und glauben, dass man nur durch die Änderung der Verfügbarkeit von Quellcode morgen anders arbeitet. Eingespielte Arbeitsweisen ändern sich nicht von Jetzt auf Sofort. Erinnern wir uns. Der Quellcode vom Communicator der Firma Netscape wurde Ende der 90er veröffentlicht. Fast 10 Jahre später entstand daraus der Firefox. Das hat jetzt zwar nichts mit Arbeitsweise zu tun. Es soll nur zeigen, wie groß Zeiträume sein können, bis aus einem proprietären Produkt ein Open Source Produkt wird.
Crosswater Job Guide: Unter welchen Bedingungen kann Open-Source erfolgreich eingesetzt werden, wo funktioniert Open-Source nicht?
Carsten Bleek: Open Source ist eigentlich eine natürliche Sache. Schon immer wurden Programmabläufe irgendwo notiert und das Wissen weitergegeben. Man stelle sich nur vor, was passiert wäre, wenn unsere Vorfahren dies bei der Entdeckung des Feuers, unterlassen hätten.
Dass man Programmcode schützt, ist eine Erfindung aus dem Computerzeitalters. Und deshalb müssen wir unsere Handys auf unterschiedliche Weise entsperren.
Aber Spaß bei Seite. Damit Open Source, verstanden als Arbeitsweise, in einem Unternehmen erfolgreich funktioniert, muss der Chef von dieser Idee überzeugt sein. Warum? Ich versuche das zu erklären.
Ich behaupte KMUs arbeiten überwiegend mit einer internen IT. Die Formulierung von Stellenanzeigen und eine Präsenz auf z.B. Github sind Indikatoren, wie weit Open Source als Arbeitsweise in Unternehmen verstanden wurde. Ist kein öffentlicher Code zu finden, wird wahrscheinlich auch keiner veröffentlicht. Wenn es öffentlichen Code gibt, dann ist erkennbar, ob es eher die Initiative eines einzelnen Mitarbeiters oder die gewollte Entscheidung der IT Abteilung war. Und dann zählt natürlich, was veröffentlicht wurde. Sind es nur Guidelines und Demos, oder sind es wesentliche Komponenten wie zB das Bewertungssystem von Amazon.
Irgendwann kommt es zur Frage, ob Software zum Kern eines Unternehmens gehört und ob die Software veröffentlicht werden darf. Irgendwann muss also der Chef ganz oben von der Idee Open Source als Arbeitsweise überzeugt werden.
Open Source, verstanden als Software, wird schon lange erfolgreich in jedem Unternehmen eingesetzt.
Open Source funktioniert nicht, wenn man nicht veröffentlichen darf. Also beim Geheimdienst.
Vor ein paar Jahren war ich noch der Meinung, sicherheitsrelevante Dinge aus dem Finanzsektor wären ungeeignet. Aber seit ich erkenne, wie sich aus Open Source die Blockchain Technik entwickelt, ändert sich meine Meinung.
Crosswater Job Guide: Welches sind die bekanntesten Beispiele für erfolgreiche Open-Source-Projekte?
Carsten Bleek: Wie gesagt. Jede Firma verwendet Open Source. Mit Sicherheit auch der Geheimdienst. Deshalb verzichte ich mal auf eine Liste der erfolgreichsten Software Projekte.
Was aber in meinen Augen einen Meilenstein in der Entwicklung darstellt, ist die Firma und das gleichnamige Produkt Gitlab. Die Firma veröffentlicht nicht nur den gesamten Kern ihres Unternehmens, sondern auch ihre Strategie. Erfolgreiche Unternehmen, die ihr Kernprodukt veröffentlichen gibt es viele. Es sind hauptsächlich Anbieter spezieller Komponenten wie einer Datenbank oder einer Suchmaschine. Aber dass ein Unternehmen veröffentlicht, wie Arbeitsverträge gestaltet und dabei unterschiedliche Lohnniveaus berücksichtigt werden, ist neu.
Und kürzlich bin ich auch über ein Unternehmen aus Berlin gestolpert, welches ihr Kernprodukt als „Do It yourself“ Version zur Verfügung stellt. Zammad verbessert die Kommunikation mit dem Kunden. Ich habe da ein Auge drauf.
Anmerkung:
Anforderungen an die Lesbarkeit und Wartbarkeit von Computer-Programmen bzw. deren Source Code wurden schon 1971 von Gerald M. Weinberg in seinem wegweisenden Buch „The Psychology of Computer Programming“ postuliert. Diese Anforderungen sind auch heute wieder aktuell, wenn es um Fragen der Algorithmen geht, wie sich die Lesbarkeit und Verständnis von diesen Algorithmen im Kontekt von juristischen Auseinandersetzung geht (Stichwort: Diskriminierung / AGG, Schadensersatzforderungen bei Unfällen mit selbstfahrenden Automobilen)
Crosswater Job Guide: Können Open-Source-Communities wie Github usw. den IT-Expertenmangel reduzieren?
Carsten Bleek: Aktuell ist es schwierig, nur mittels Open Source Communities wie GitHub zu rekrutieren. Aber ein Blick in die Communities hilft zu lernen, wie andere z.B. dokumentieren, welche und wie Technologien eingesetzt werden. Man kann z.B. sehen, wie Zammad build und deploy Prozesse realisiert. Die bunten Badges sind so etwas wie eine Ampel der „Schönheit“ von Quellcode.
Aber zurück zur Frage. Den IT-Expertenmangel reduziert man durch den Einsatz von Remote Workern. Die kann man über Open Source Communities finden. Einfacher ist es aber, diese über Plattformen zu finden, die für Remote Worker gemacht sind. Gute Erfahrung haben wir hier mit Upwork.com gemacht. Aber es gibt natürlich noch viele andere Plattformen.
Crosswater Job Guide: Was muß ein IT-Manager machen, um von diesen Möglichkeiten zu profitieren?
Carsten Bleek: Ein IT Manager sollte die Vorstellung ablegen, dass die interne IT besser ist als die Remote Worker. In einem 2. Schritt muss er die interne IT in eine IT umformen, die den Regeln der Open Source Entwicklung folgt. Die eigene IT muss über den Tellerrand hinausblicken können.
Wenn sich eine intern arbeitende IT dazu entschließt, Remote Worker einzusetzen, dann wird häufig das Konzept für ein Software Projekt intern erstellt und dann ein Remote Worker für die Programmierung gesucht. Das geht oft schief. Jedenfalls dann, wenn in der intern arbeitenden IT diese bunten Badges nicht existieren.
Remote Worker sind meist viel näher an modernen Technologien, als Mitarbeiter einer intern arbeitenden IT. Das erfordert Änderungen in den Arbeitsprozessen. Der Mitarbeiter, der bisher Konzepte gemacht hat, muss plötzlich das Konzept eines Remote Workers reviewen. Der Software-Entwickler, der programmiert hat, soll plötzlich einen Task so beschreiben, dass man ihn zum rekrutieren nutzen kann.
Crosswater Job Guide: Wie funktioniert die Projektarbeit in einem Remote-Work-Umfeld?
Carsten Bleek: Die These, dass „Remote Work“ und „Open Source“ praktisch das selbe sind, vertrete ich seitdem ich Talks von Heiko Fischer gesehen habe.
Wenn wir also Open Source als eine Arbeitsweise verstehen, dann ergibt sich der wesentliche Unterschied bei der Ausschreibung in der Formulierung. Klassisch beinhaltet eine Stellenanzeigen eine Aufgabenbeschreibung, einen Anforderungskatalog und eine Liste von Benefits. Das muss man so machen, wenn man um eine begrenzte Anzahl Bewerbern buhlt, die lokal arbeiten sollen. Wenn man die Stelle global ausschreibt, sieht man sich mit einer ganz anderen Menge von potentiellen Entwicklern konfrontiert.
Ausschreibung
Wenn man darauf verzichten kann, dass ein Entwickler lokal arbeiten muss, dann kann man in den Ausschreibungstext das Problem beschreiben, welches gelöst werden muss. Ein Recruiter wird bei dem Beispiel einer 2 Jahre alten Anzeige schnell erkennen, was ich meine.
Auswahl der Experten
Wenn die Ausschreibung so formuliert ist, dass sie nur Experten verstehen, dann ist die Auswahl einfach. Das funktioniert aber nur, wenn man genügend Experten erreicht. Aber natürlich muss die Plattform, über welche man Experten sucht, auch die Möglichkeit bieten, die Qualität beurteilen zu können
Auftragserteilung
Für die Auftragserteilung braucht man etwas, was dem Remote Worker garantiert, dass er bezahlt wird. Es kann im großen Stil wie bei Gitlab laufen, die sich Gedanken über das Arbeitsrecht, Währungen und Inflationsraten in verschiedenen Ländern machen. Wenn man einfach nur anfangen will, dann nutzt man Remote Worker in Form von Freelancer. Die Plattform für die Auswahl muss die Funktion mitbringen Freelancer problemlos zu bezahlen.
Fortschrittskontrolle
Für die Fortschrittskontrolle solle eine Remote Worker Plattform nicht zuständig sein. Entscheidend ist übermittelter Quellcode, der automatische Tests besteht. Also Workflows im Github oder Gitlab. Die Remote Worker Plattformen bieten zwar viele Möglichkeiten der Kontrolle. Diese sollte ein IT Manager aber nicht nutzen, wenn er unabhängig bleiben will.
Kommunikation
Die Kommunikation zwischen Remote Workern ist anders. Im besten Fall nicht synchron sondern asynchron. Weil man ja davon ausgehen muss, dass man in anderen Zeitzonen arbeitet. Es ist anders als gewohnt. Aber am Ende besser.
Abschluss und Freigabe
Bei der internen Entwicklung kommt „Abschluss und Freigabe“ zum Mitarbeiter, der das Konzept gemacht hat, häufig zurück. Bei der Remote Entwicklung ist der DevOps Prozess besser. Die Freigabe findet automatisiert bei jeder Code Änderung statt. Der oft manuelle Prozess am Ende entfällt.
Crosswater Job Guide: Cross-Solution hat sich auf die Entwicklung und den Einsatz von Open-Source-Software spezialisiert. Welche Produkte und Dienstleistungen bieten Sie auf dieser Basis an?
Carsten Bleek: Wir sind seit gut 15 Jahren dabei. Open Source hatte schon immer Vorteile. Aber der wesentlichen Vorteil ist nicht mehr Kostenersparnis aufgrund von Lizenzen oder einfacherer Wartung, sondern die Arbeitsweise. Arbeit ist der größte Kostenfaktor in einem Unternehmen.
Unternehmen klagen, dass sie keine Entwickler finden. Wir können nachweisen, dass die Entwickler da sind. Wir wollen nicht in die Personalvermittlung. Wir wollen KMUs zeigen, wie man Remote Worker integriert. Unser Motto: „bezahlt nicht uns, dass wir euer Problem lösen. Bezahlt uns dafür, dass wir euch zeigen, wie ihr euer Problem mit Remote Workern löst.“. Wir können beides.
Unsere Liebe zu Open Source bleibt. Wir erkennen darin den Fortschritt im Internet und auf dem Handy.
Weiterführende Links:
Übernahme von GitHub: Microsoft investiert ins Image
GitHub und GitLab – was ist der Unterschied?
Weinberg, Gerald M.: The Psychology of Computer Programming. New York, 1971.
