Jaroslaw Kroczek von Boldare: "Gute Bezahlung reicht heute nicht mehr aus"
(Bild: Boldare)
Ein Interview von Maja Hoock veröffentlicht am
Ein Produkt, das niemand braucht, oder eine Recruitingstrategie, die nichts bringt: Jaroslaw Kroczek hilft mit seiner Entwicklerfirma Unternehmen als CTO as a Service, typische Fehler zu vermeiden.
In einer Interview-Reihe befragen wir CTOs zu ihrer Arbeit, Tipps für Jobsuchende und Trends in der Technikwelt. Zum Schluss gibt es noch ein Ein-Antwort-Spiel. Lasst uns im Forum wissen, welche Kandidaten und Fragen ihr euch zusätzlich fürs nächste Interview wünscht. Alle CTO-Interviews der Reihe sind hier zu finden.
Ein häufiger Grund für gescheiterte Software-Projekte ist laut Studien, dass Kunden ein Produkt in Auftrag geben, das niemand braucht. Jaroslaw Kroczek und sein Team wollen solche Fehlschläge vermeiden und treten deswegen nicht nur als reine Entwickler auf, sondern auch als "CTO as a Service".
Mit zwei weiteren CTOs und rund 180 Mitarbeitern, darunter Scrum Master, agile Coaches, Software-Architekten und Entwicklerinnen und Entwickler, wollen sie eine typische Lücke schließen: die zwischen den Auftraggebern, die das Business verstehen, und Programmierern, die die Anwender verstehen.
Als Kind sei er immer der Nerd gewesen, der lieber Zeit mit seinem PC verbrachte als draußen beim Spielen, sagt Jaroslaw Kroczek. Jetzt ist er 36, hat einen Master in Informatik und war bereits Qualitätsanalyst, Software-Entwickler, Funktionsdesigner, Software-Entwicklungsmanager, technischer Leiter und Leiter der Produktentwicklung. Seit fast drei Jahren ist er Chief Technology Officer (CTO) von Boldare.
Das Unternehmen für Software-Entwicklung, UX- und UI-Design, Scrum und Geschäftsentwicklung bietet auch CTO as a Service an: Diese Dienstleistung, bei der Kroczek mit einem von ihm zusammengestellten Team verschiedene technologische und strukturelle Probleme angeht, ist für Kunden kostenfrei. "Häufig entwickeln wir erst ein Produkt für die Kunden und dabei fallen uns Herausforderungen auf, die wir mit CTO as a Service angehen", sagt Kroczek.
Dabei setzt nicht eine einzelne Person ihre Expertise als Consultant ein, sondern das gesamte Unternehmen als eine Art "Super Consultant". Expertenteams entwickeln unter der Leitung von Kroczek Strategien für Entwicklungsprojekte, Team-Aufstellungen oder die Skalierung von Systemen in Unternehmen. Dabei übernehmen sie kollektiv klassische CTO-Aufgaben oder unterstützen CTOs bei größeren Herausforderungen. So hat Boldare etwa dem Mitfahr-Startup BlaBlaCar geholfen, in 27 Märkte weltweit zu expandieren, und arbeitet aktuell mit TUI zusammen.
Golem.de: Boldare bietet zusätzlich zum Entwicklungsgeschäft CTO as a Service an. Was genau unterscheidet CTO as a Service von normalem Consulting?
Kroczek: Häufig werden wir gar nicht direkt als CTO as a Service beauftragt, sondern zunächst erst einmal nur mit konkreten Aufgaben im Frontend oder Backend. Fallen uns dabei strukturelle Hürden auf, bieten wir CTO as a Service kostenfrei an. Wir helfen den Kunden, mehrere Produkte aufzubauen oder ein ganzes Portfolio. Manchmal haben die Unternehmen bereits eigene CTOs, mit denen wir dann eng zusammenarbeiten. Manchmal gibt es auch keinen CTO. Aber in jedem Fall kommen sie mit einem bestimmten Grund zu uns - entweder haben sie wenig Erfahrung mit Kollaborationen mit anderen Unternehmen, oder sie wissen vielleicht nicht genau, welche Kompetenzen sie gerade benötigen; zum Beispiel einen Scrum Master.
Golem.de: Was wird vom CTO as a Service verlangt? Gibt es Themen, die immer wieder auftauchen?
Kroczek: Häufige Themen sind der Aufbau eines Teams und wie man die Arbeit strukturieren kann, um schnell auf die Herausforderungen des Kunden zu reagieren. Ein anderes Thema ist, welcher Ansatz jeweils am besten zur aktuellen Produktphase passt. Zum Beispiel brauchen wir einen anderen Ansatz für den Aufbau eines MVP als für eine Skalierung eines Produkts.
Golem.de: Wie sieht das in der Praxis aus?
Kroczek: In meiner Rolle als CTO as a Service komme ich in Unternehmen, die ein neues Feld oder Produkt entwickeln möchten, aber nicht die nötigen Strukturen haben. Ich steige also für kurze Zeit dort ein, um die Herausforderungen und Ziele zu verstehen. Dann entwickle ich mit den verfügbaren Ressourcen meines Unternehmens eine Projektstrategie: Ich stelle Teams auf, bewältige organisatorische Herausforderungen durch die Leitung einer agilen Transformation, optimiere Prozesse für die Umsetzung in mehreren Teams und führe fachliche Designelemente ein. Im Gegensatz zu einem traditionellen CTO-Ansatz bieten wir eher Führung als eigene Entscheidungen zu treffen.
Golem.de: Für welche Unternehmen haben Sie bereits als CTO as a Service gearbeitet?
Kroczek: Für Startups und etablierte Unternehmen mit eigenem CTO oder auch ohne, zum Beispiel für BlaBlaCar, Matic Services, Leaseweb und zahlreiche andere Unternehmen aus Europa, USA, dem Mittleren Osten und Nordafrika.
Golem.de: Könnten Sie ein konkretes Beispiel für einen Ihrer Kunden nennen?
Kroczek: Ein Kunde stellt unter anderem Tools für Bots und SMS-Benachrichtigungen zur Verfügung, zum Beispiel wenn eine Bank jemanden über ungewöhnliche Aktivitäten in seinem Account informieren möchte. Er bietet außerdem Zwei-Faktor-Authentifizierung für Banken und ein Tool der Regierung, um Unwetterwarnungen an die Bevölkerung zu schicken - also viele verschiedene Use-Cases und Lösungen für unterschiedliche Kundschaft. Wir arbeiten jetzt seit vier oder fünf Jahren mit diesem Unternehmen zusammen, am Anfang gar nicht als CTO as a Service. Wir sollten sie ursprünglich nur als Partnerfirma beim Aufbau des Frontend-Parts der Systeme unterstützen.
Golem.de: Wie kam es dann dazu, dass CTO as a Service nachgefragt wurde?
Kroczek: Unser Kunde hatte keine direkte Erfahrung mit den Systemen, die aber für einen Großteil seiner Einnahmen verantwortlich waren. Es lag alles in den Händen eines anderen Partnerunternehmens mit herstellereigenen und lizenzierten Lösungen für das Backend. Der Partner war skeptisch gegenüber Neuerungen im Entwicklungsprozess, die unseren Kunden dazu befähigt hätten, schnell auf den Markt zu reagieren. Wir haben festgestellt, dass diese Arbeitsweise nicht sonderlich effektiv ist. An dieser Stelle war CTO as a Service gefragt, um dem Kunden zu helfen, agiler und eigenständiger auf den Markt zu reagieren.
Golem.de: Wie sind Sie als CTO as a Service vorgegangen?
Kroczek: Wir haben eine Agenda ausgearbeitet, welche Punkte wir ändern würden und wie moderne Software-Entwicklung aussehen kann, wenn wir auf agile Prozesse umstellen. Die größte Aufgabe war, mit allen Stakeholdern des Kunden und seiner Partner zusammenzuarbeiten. Mit den technischen Teams und den Architekten haben wir evaluiert, wie wir die Strukturen auseinandernehmen und Architektur und technische Lösungen anpassen, um etwa die Deployments zu automatisieren, die Zusammenarbeit zwischen den Teams ohne aufwendige Dokumentation zu koordinieren - die Wochen an Zeit gekostet hat und keinen eigentlichen Wert brachte - oder auch, um agil Änderungen vornehmen zu können.
Golem.de: Wie lange dauert so etwas?
Kroczek: Es hat Monate, viele Meetings und Workshops gebraucht.
Golem.de: Wie lange dauert es normalerweise, sich als Service-CTO in Strukturen fremder Unternehmen hineinzudenken?
Kroczek: Meistens müssen wir einen bis vier Tage in erste Workshops investieren, um das Produkt, Team-Zusammenhänge und den Bereich, in dem wir tätig sind, zu verstehen. Dann dauerte es einige Tage, bis wir etwas liefern können, das im Repository gepusht werden kann. Unser Ziel ist es immer, wertvolle Inkremente zu produzieren - also etwas, das innerhalb der ersten zwei Wochen, also dem ersten Sprint, nutzbar ist.
Golem.de: Was muss Ihr Expertenteam drauf haben?
Kroczek: Das sind erfahrene Führungskräfte, die in der Lage sind, Teamstrukturen zu etablieren und Kompetenzen zu verwalten. Sie unterstützen unsere Kunden auch in den schwierigsten Phasen der Produktentwicklung. Dafür braucht man einen technischen Hintergrund und Erfahrung im Team- und Projektmanagement, die man bei Produktentwicklungen mit internationalen Teams über viele Länder und Kulturen hinweg gesammelt hat.
Golem.de: Welche Aufgaben übernehmen Sie normalerweise als CTO? Sind Sie noch aktiv am Frontend und Backend beteiligt?
Kroczek: Meistens bin ich nicht zu sehr in die technischen Details involviert. Es kommt auf das Abstraktionslevel an: Ich bewege mich normalerweise im Bereich von Architektur-Entscheidungen; zum Beispiel, ob es sich lohnt, die Zeit zu investieren, auf Microservices umzustellen. Ich stelle nicht die konkreten technischen Lösungen her, sondern erkenne Änderungsbedarf, trage alle Informationen zusammen und stelle die Teams aus Software-Architekten und anderen zusammen, um das umzusetzen. Meine Rolle ist es also, das Gesamtbild im Auge zu haben, eine Schnittstelle zu bilden und Entscheidungen zu treffen, welche Änderungen Investitionen wert sind und welche nicht.
Golem.de: Sich in die technischen Strukturen fremder Unternehmen hineinzudenken und gleichzeitig als CTO die Entwicklung des eigenen Unternehmens im Auge zu behalten, erfordert einige Tech-Skills. Wie sind Sie überhaupt zur Technik gekommen?
Kroczek: Ich war schon als Kind ein Nerd. Ich glaube, ich war der Streber und Technikfreak unter meinen Freunden. Von Anfang an war ich der Typ, der alles am Computer machte und die meiste Zeit damit verbrachte, Dinge auszuprobieren, manchmal auch seltsame Dinge. Ich war also das Kind, das lieber dasaß und auf den schwarzen Bildschirm mit der Befehlseingabe schaute, als sich mit Freunden zu treffen.
Golem.de: Wann haben Sie Ihren ersten Computer bekommen und was haben Sie damit angestellt?
Kroczek: Ich hatte einen guten alten Intel 386er mit MS-DOS und einer der ersten Windows-Versionen, ausgestattet mit CRT-Bildschirm und Floppy-Disk-Laufwerk. Es war ein paar Jahre, bevor Pentium-Mikroprozessoren die Welt veränderten. Für mich bleibt der 386er aber die wichtigste Erfahrung.
Golem.de: Was ist Ihnen bei Ihrer Tätigkeit als CTO as a Service in Unternehmen aufgefallen: Woran hakt es bei IT-Projekten?
Kroczek: Probleme entstehen oft durch die Art, wie Unternehmen ihre Arbeit organisieren. In den meisten Fällen können sie von einer besseren Abstimmung zwischen den technischen Teams und dem Business profitieren, von besseren Kommunikations- und Kooperationsprozessen und von mehr Vertrauen, dass die technischen Teams gute fachliche Entscheidungen treffen.
Golem.de: Wo sollten die Projektbeteiligten den Tech-Teams mehr Vertrauen schenken?
Kroczek: Ein weit verbreiteter Irrglaube ist, dass eine gut konzipierte Struktur und ein gut konzipierter Code in naher Zukunft kein größeres Update benötigen. Wegen dieser falschen Erwartungshaltung überinvestieren technische Teams am Anfang oft und verzögern die Markteinführung unfreiwillig. Doch irgendwann ändern sich die Anforderungen so, dass Teile ohnehin neu entwickelt werden müssen. Dieser Ansatz wird häufig von der Unternehmensführung verstärkt, die Änderungen am bereits geschriebenen Code als Fehler empfindet.
Golem.de: Welche Konsequenzen kann so etwas haben?
Kroczek: Ein häufiger Grund für das Scheitern von Produkten ist die Abgabe von etwas, das letztendlich nicht benötigt wird. Ein Entwicklungsprojekt, das pünktlich, mit dem angenommenen Umfang und Budget geliefert wird, kann lediglich einige Führungskräfte und Stakeholder zufriedenstellen, hat aber eine große Chance zu scheitern, wenn es vom realen Geschäft und den Usern losgelöst ist. Um das Scheitern von Produkten zu vermeiden, brauchen wir ein Team, das mit der Business-Perspektive und den Anwendern verbunden ist, das in der Lage ist, qualitativ hochwertige Produktinkremente in kurzen Zyklen zu liefern und Feedback einzubeziehen.
Golem.de: Wie stellen Sie das sicher?
Kroczek: Wir bestehen darauf, dass unsere Teams am eigentlichen Produkt arbeiten und agile Entwicklungsmethoden nutzen. Wenn möglich, verbinden sie sich mit den Anwendern oder den Vertretern der Zielanwender, dem Geschäft und den Stakeholdern und arbeiten mit ihnen zusammen. Diese Teams arbeiten zwar mit festen Grenzen wie Budget, Zeitplan, mit Geschäftszielen und Produkthypothesen. Sie arbeiten jedoch nicht mit einem festen Umfang. Sie lernen, während sie arbeiten, erhalten mindestens alle zwei Wochen Feedback von Anwendern und Stakeholdern und priorisieren ständig die wichtigsten Funktionen und Änderungen mit dem Product Owner. Mit diesem Ansatz maximieren wir die Chancen, den tatsächlichen Wert zu liefern, und vermeiden nicht nur das Scheitern des Projekts.
Golem.de: Wie würden Sie mit einem Team umgehen, das immer zu spät Projekte liefert?
Kroczek: Die Vorhersage und Planung detaillierter Ergebnissen der Entwicklungsarbeit viele Monate im Voraus ist immer eine Herausforderung und scheitert, wie viele marktweite Analysen zeigen, in den meisten Fällen. Andererseits erwarten Unternehmen, dass die Entwicklung anpassungsfähig ist und auf Feedback reagiert. Ich konzentriere mich stärker darauf, den maximalen Produktwert in einer gegebenen Zeit und einem gegebenen Budget zu liefern, als ein fixes Projekt abzuschließen.
Golem.de: Was sind für Sie die häufigsten Symptome von Problemen in Teams?
Kroczek: Ein Team kann seine Sprint-Ziele nicht erreichen, schafft es nicht, Produktinkremente zu liefern und bereitzustellen, tut sich schwer, Feedback und Änderungen in seine Backlogs einzuarbeiten. Oder es ist nicht in der Lage, bei Sprints mit Budget- und Zeitbeschränkungen zu arbeiten.
Golem.de: Was tun Sie, wenn Sie mit einem dieser Probleme konfrontiert werden?
Kroczek: Wir verwenden viele Werkzeuge, um solche Probleme zu verhindern und schnell zu lösen, zum Beispiel: Sprint-Reviews, Retros, Brainstorming, 5-Whys, Fishbone und Rollen wie Scrum Master und Agile Coach. Mir hilft außerdem eine kurze Checkliste: Wie sind wir bezüglich der Erwartungen und des aktuellen Problems ausgerichtet? Ist das Team in der Lage, es selbst zu beheben oder mit externem Coaching oder Mentoring? Wie muss die Organisation das Team unterstützen, führen oder managen?
Golem.de: Was sind die größeren Herausforderungen bei der IT-Sicherheit, wenn Sie Unternehmen beraten?
Kroczek: Ich denke, es ist die Zahl der Tools, Plattformen und Geräte, die jeder nutzt. Wir alle müssen Wissen über Informations- und Zugriffsmanagement etablieren. Wir haben bei Boldare ein eigenes Team, das sich um Ausbildung, Überwachung, Mentoring, die Auflistung aller von uns verwendeten Tools, die Überprüfung der Konfiguration und Ähnliches kümmert. Dafür gibt es ein eigenes Budget. Technologische Nachlässigkeit in der Verwaltung und Kommunikation von Tools können für jedes Unternehmen extrem schädlich sein, nicht nur für solche wie uns, die mit Produktentwicklung oder IT-Dienstleistungen arbeiten.
Golem.de: Sie arbeiten mit agilen Methoden. Welche Skills sind Ihnen da besonders wichtig?
Kroczek: Wir erwarten, dass jedes Team-Mitglied T-förmige Fähigkeiten hat, im Gegensatz zu I-förmigen Fähigkeiten. Zum Beispiel müssen Software-Ingenieure nicht nur Experten in einem bestimmten Bereich wie Backend und Datenbanken sein, sondern zumindest grundlegende Kenntnisse in anderen Aspekten der Technologie, des Prozesses und der Geschäftsbereiche haben. Sie müssen auch offen dafür sein, bei Bedarf tiefer einzusteigen.
Golem.de: Sie lernen mit dem CTO-Service ständig neue Unternehmen kennen. Tun diese sich schwer, feste Mitarbeiter mit dem nötigen Know-how zu finden?
Kroczek: Meiner Beobachtung nach auf jeden Fall. Ich sehe, dass einige Unternehmen deshalb versuchen, Teams über verschiedene Zeitzonen hinweg zu bilden - wobei ich nicht glaube, dass das langfristig praktikabel ist. Auf der anderen Seite eröffnet die aktuelle Pandemiesituation die Möglichkeit, Menschen aus der ganzen Welt einzustellen - was eine Chance für Unternehmen sein kann, die mit der Verwaltung von Remote-Teams mit Leuten aus verschiedenen Kulturen gut zurechtkommen. Für diese Unternehmen besteht die beste Lösung meiner Meinung nach jedoch darin, Teams zu bilden, die gelegentlich zusammenarbeiten und einen ähnlichen kulturellen Hintergrund haben - oder einen Partner zu finden, der solche Teams bereitstellen kann.
Golem.de: In welchem Bereich gibt es das größte Defizit an geeigneten Kandidaten?
Kroczek: Bei den meisten Positionen, die mit Produktentwicklung zu tun haben, also bei Produktdesignern, Software-Ingenieuren, Backend- und Frontend-Entwicklern sowie Dev-ops. Dies gilt vor allem für Senior-Level, denn der aktuelle Trend ist, Mediors oder Seniors zu beschäftigen, obwohl es auf dem Markt deutlich mehr Juniors gibt.
Golem.de: Woran könnte das liegen?
Kroczek: Angesichts der unsicheren Zukunft und der Pandemiesituation zögern Unternehmen offenbar, langfristig in Talente zu investieren, und konzentrieren sich eher auf das Hier und Jetzt.
Golem.de: Neben Geld - was erwarten IT-Mitarbeiter von ihrem Arbeitsplatz und Arbeitgeber?
Kroczek: Es ist offensichtlich, dass eine gute Bezahlung heute nicht mehr ausreicht. Man muss auch eine tolle Kultur und etwas Besonderes und Einzigartiges zu bieten haben, um die passenden Kandidaten und Kandidatinnen anzuziehen.
Golem.de: Wichtig ist für viele potenzielle Mitarbeiter sicher auch, wie sehr sie in einer Firma mitbestimmen können. Wie führen Sie Ihr Team?
Kroczek: Wir nutzen Holacracy als unternehmensweites "Betriebssystem" - und damit also lieber die Vorteile verteilter Autorität, als durch Hierarchie zu kontrollieren und zu lenken.
Golem.de: Holokratie oder Holocracy meint transparente Entscheidungsfindung mit partizipativen Beteiligungsmöglichkeiten in Unternehmen.
Kroczek: Ja, eine Person kann verschiedene Rollen auf vielen Organisationsebenen ausfüllen, wo die Kompetenzen in einem bestimmten Moment am wichtigsten sind.
Golem.de: Was gilt es dabei zu beachten?
Kroczek: Es ist sinnvoll, Ziele zu setzen. Teams sind verpflichtet, in ihrem Verantwortungsbereich eine Strategie zu schaffen, die zur Strategie des Unternehmens beiträgt. Der Ansatz ist ähnlich wie bei OKRs, wir legen den Schwerpunkt auf die Bereitstellung von strategischem Kontext und einer Richtung. Spezifische Ergebnisse werden von Kreisen, also Teams, zusammen mit ihren vierteljährlichen Investitionsbudgets geplant.
Golem.de: Welche Priorität hat diese Holocracy-Strategie in Ihrem Unternehmen?
Kroczek: Die Strategie wird im gesamten Unternehmen geteilt und von allen Teams wird erwartet, dass sie sie in ihren Prioritäten, Projekten, Strukturen und Budgets befolgen. Die Strategie ist in den allgemeinen Unternehmenskreis integriert - ein Äquivalent zu einem Team von Leitern der Abteilungen: Produktentwicklung, Business, People and Community, Operations und andere.
Golem.de: Wie sieht das in Ihren Entwicklerteams konkret aus?
Kroczek: Ein Entwicklungsteam könnte zum Beispiel den Wissensaustausch und die Mitarbeit in Communities of Practice priorisieren, wenn die technischen Teams skalieren. Oder es könnte mit dem Erlernen neuer Fähigkeiten beginnen, wenn die Produktstrategie neue Richtungen vorgibt. Oder die technische Herangehensweise in Abhängigkeit von den Produktzielen ausbalancieren: ob sie also einen Prototyp erstellen, um grundlegende Produktannahmen zu validieren, oder ein Produkt vorbereiten, das im kommenden Monat einen Peak an Usern erreichen soll.
Golem.de: Akzeptieren Sie eine Koryphäe mit Defiziten bei den Soft Skills im Team?
Kroczek: Die kurze Antwort lautet: nein. Der wichtigste Erfolgsfaktor bei der Entwicklung von digitalen Produkten ist die richtige Balance zwischen Hard Skills und Kreativität, Teamwork und fundierten Kompetenzen. Mit jemandem zu arbeiten, der in einem Bereich brillant ist, dem es aber an Kommunikation, Teamwork und Werten mangelt, kann auf lange Sicht destruktiv sein, und das ist es unserer Meinung nach nicht wert.
Golem.de: Was tun Sie, wenn es an manchen Stellen an Hard Skills fehlt?
Kroczek: Bei anspruchsvollen Themen, die nicht in unserem Fachgebiet liegen, arbeiten wir für eine begrenzte Zeit mit externen Beratern zusammen. Auf diese Weise können wir Wissen und Expertise gewinnen und gleichzeitig unsere Kultur konsistent halten.
Golem.de: Wie würden Sie mit Entwicklern umgehen, die nicht produktiv sind oder ständig Fehler machen?
Kroczek: Wenn es um einen einzelnen Entwickler geht, würde ich erwarten, dass das Team nachzieht, da wir ohne Manager in selbstorganisierten Strukturen arbeiten. Wir versuchen, eine Kultur zu schaffen, in der das Team Feedback austauscht und der Scrum Master hilft, Schwachstellen, falsche Prozesse und mangelnden Wissensaustausch zu beheben. Wenn das Team nicht in der Lage ist, das zu beheben, würde ich prüfen, was die Ursache ist: ein Mangel an Fähigkeiten? Brauchen wir ein Training? Ein Mangel an Kommunikation? Ich denke, dass es oft nicht die Schuld von jemandem ist, sondern eher etwas, das dazu führt, dass einige Mitarbeiter nicht ihr volles Potenzial entfalten können.
Golem.de: Mit welchen Tools verfolgen Sie den Projektfortschritt und den Code selbst?
Kroczek: Entwicklungsteams verwenden Jira und Release Burnup Chart beziehungsweise Sprint Burndown Chart als tägliches Werkzeug, um das Product Backlog zu speichern und den Fortschritt zu verfolgen; Epics, User Stories, Akzeptanzkriterien. Mural ist seit Kurzem unser wichtigstes Tool für das allgemeine visuelle Management. Wir verwenden es für den Austausch von Geschäfts- und Produktwissen, also Produkt-Roadmaps, Business Canvas, Product Persona, User Story Mapping, Impact Mapping und für die kreative Zusammenarbeit in fortgeschritteneren Szenarien wie Analyse-Brainstorming.
Golem.de: Welche Entwicklungsprozesse würden Sie automatisieren, wenn Sie könnten?
Kroczek: Ich würde in der Qualitätssicherung noch weiter gehen. In vielen Fällen ist der QA-Prozess bis zu einem gewissen Grad automatisiert. Wir haben verschiedene Arten und Stufen von Tests. Das ist ein anhaltender Trend, Qualität und Tests mit vielen verschiedenen Tools in den Prozess einzubauen. Glücklicherweise ist die menschliche Präsenz im Prozess immer noch nicht ersetzbar, aber jeder könnte von einer weiteren Automatisierung in diesem Bereich profitieren.
Golem.de: Kann eine KI vielleicht sogar bald Programmierer ersetzen?
Kroczek: Um ehrlich zu sein, sehe ich nicht, dass Programmierer in naher Zukunft ersetzt werden - das ist zu kompliziert. Außerdem ist der menschliche Faktor, das Einfühlungsvermögen gegenüber den Nutzern, immer noch etwas, das nicht ersetzt werden kann und sollte!
Golem.de: Zum Schluss bitte ich Sie noch um ein paar ganz schnelle Antworten. Denken Sie nicht lange nach, schießen Sie einfach los!
Golem.de: Das beste Fachbuch
Kroczek: Machine, Platform, Crowd: Harnessing Our Digital Future von Andrew McAfee und Erik Brynjolfsson
Golem.de: Das beste IT-Blog
Kroczek: InfoQ
Golem.de: Der beste IT-Podcast
Kroczek: InfoQ Podcast
Golem.de: Die beste IT-Messe
Kroczek: Domain-Driven Design Europe - ich freue mich schon auf den Besuch!
Golem.de: Der beste Youtube-Channel oder Influencer
Kroczek: Seit ein paar Jahren unumstritten Robert C. Martin (Uncle Bob)
Golem.de: Worin sollte man sich 2021 weiterbilden?
Kroczek: Mindfulness
Golem.de: Erreichbarkeit für Sie nach Dienstschluss: ja oder nein?
Kroczek: Wenn wir nur unseren Kopf in den "Flugmodus" versetzen könnten ...
Golem.de: Welcher Passwortmanager?
Kroczek: KeePassX
Golem.de: Welches VPN?
Kroczek: NordVPN
Golem.de: Was darf auf Ihrem Schreibtisch neben dem Arbeitsgerät nicht fehlen?
Kroczek: Pomodoro Timer
Golem.de: Lieblingsfigur/Lieblingsfilm aus Star Wars oder Star Trek?
Kroczek: James T. Kirk aus der Original-Serie von Star Trek
Golem.de: Erste Programmiersprache
Kroczek: Batch-Scripten in MS-DOS (nicht wirklich eine Programmiersprache), TurboPascal
Golem.de: Liebste Programmiersprache
Kroczek: C#
Golem.de: Lieblings-Open-Source-Software?
Kroczek: GIMP
Golem.de: Kubernetes oder Openstack?
Kroczek: Chapter architecture
Golem.de: Android oder iOS?
Kroczek: Android by heart, iOS aus Pragmatismus
Golem.de: Clickpad oder Trackpoint?
Kroczek: Im Ernst? :D, ich denke: Touchpad.
Golem.de: Windows, MacOS oder Linux?
Kroczek: MacOS - reiner Pragmatismus
Golem.de: Tabs oder Spaces?
Kroczek: Tabs
Golem.de: Viel ausprobieren oder Never change a running System?
Kroczek: Es ist so offensichtlich ... viel ausprobieren!
Golem.de: Sprint
Kroczek: schrittweise
Golem.de: Agile
Kroczek: Offenheit
Golem.de: Scrum
Kroczek: Team
Golem.de: Waterfall
Kroczek: Urlaub
Golem.de: Monolit
Kroczek: Space Odyssey
Golem.de: Change
Kroczek: schnell
Golem.de: Kubernetes
Kroczek: layer
Golem.de: Headless
Kroczek: verzichtbar
Golem.de: TechStack
Kroczek: Konzept
Golem.de: Standup
Kroczek: Ziele