Unsere Interview-Partner Lisa und Marten

Dev-Interview mit Lisa und Marten
In diesem Interview reden wir mit Lisa und Marten von queo über das, was sie an ihrer Arbeit so lieben, wie die Teams zusammenarbeiten und warum PHP gar nicht so schlecht ist – von Dev zu Dev.

Ilja: Hallo, ich bin Ilja von EntwicklerHeld. Heute wollen wir über queo reden und was die Arbeit dort so besonders macht. Es ist das erste Mal, dass wir zwei Interview-Partner haben – ich bin gespannt, wie das klappt.  Stellt euch beide vor und was ihr so macht. Lisa, möchtest du anfangen? Du bist die zweite Frau in meinen Developer-Interviews. Da freue ich mich sehr.

Lisa: Ja, ich finde das immer ganz schön, wenn Frauen auch als Beispiel genommen werden. Auch wenn ich mich dabei frage, bin ich jetzt hier, weil ich eine Frau bin oder weil ich kompetent bin? Aber andererseits ist es ja auch wichtig, dass junge Frauen das sehen und sich das als Vorbild nehmen. Ich bin Lisa und bin jetzt seit viereinhalb Jahren bei queo in Berlin und bin Backend-Entwicklerin und gleichzeitig noch Teamsprecherin von unserem Team. 

Ilja: Was macht eine Teamsprecherin bei queo?

Lisa: Wenn ein Team eine Frage an ein anderes Team hat oder da irgendwie Kapazitäten anfragt, dann soll es immer über den Teamsprecher gehen. Wir haben auch einen Termin einmal im Monat, wo sich alle Teamsprecher gegenseitig updaten, dass man weiß, was in den anderen Teams passiert. Doch in erster Linie entwickle ich Backend, hauptsächlich TYPO3, jetzt mittlerweile auch Neos.

Ilja: Okay. Marten, was machst du bei queo?

Marten: Ich bin Marten und bin seit siebeneinhalb Jahren bei queo. Ich bin gleich nach meiner Ausbildung hergekommen. Ich bin ebenfalls Backend-Entwickler, aber hauptsächlich im Symfony-Kontext. Ich hab früher viel TYPO3 gemacht, aber dann hat die AOK eine relativ große Suchmaschine für Ärzte, Krankenhäuser und ähnliches beauftragt. Unser Team war ohnehin schon relativ fit mit Elasticsearch. So sind wir in den Microservice / Symfony API Bereich reingekommen. Ansonsten bin ich ebenfalls Teamsprecher, wobei ich mich dabei vor allem als Sprachrohr des Teams nach außen betrachte.

Ilja: Vielleicht könnt ihr kurz erklären: Was macht queo?

Marten: Ich hänge natürlich nicht überall drin, aber ich erzähl mal, was ich weiß: Die größte Unit ist die Unit Web. Da haben wir unter anderem die AOK und die VBG als Kunden. Aber auch Eins Energie. Das sind zum Großteil CMS-Lösungen auf TYPO3 und Neos. Da arbeiten mit Abstand die meisten Teams dran. Und im AOK-Universum haben wir auch noch viele Microservices / APIs etabliert. Die sogenannten Zentralen Dienste. Das sind im Regelfall Symfony-Anwendungen, wo AOKs dann Daten anliefern und pflegen können. In unserem Fall die so genannten Navigatoren.  Da haben wir Krankenhausdaten. Dann gibt es auch einen zentralen Dienst (ZD) für Events und Veranstaltungen, wie zum Beispiel Rückenschulungen. Ich denke, es gibt um die 15 ZDs. Ansonsten ist queo natürlich auch noch groß im Marketing unterwegs. Und dann haben wir noch queo/xr. Die machen Augmented Reality und KI, beispielsweise für Messen und Ausstellungen. Lisa, fällt dir noch irgendwas ein, was ich vergessen habe?

Lisa: Ich finde, du hast das eigentlich ganz gut zusammengefasst. XR, Markenkommunikation und Web sind die Units in unserem Geschäftsbereich. Da sind so zehn Teams.

Marten: Ja, 90 oder 100 Leute, allein im Web.

Ilja: Wie viele Teams sind das?

Lisa: Ich glaube, Dresden macht das ein bisschen anders als Berlin. Marten, korrigiere mich, wenn das falsch ist. Wir haben ein festes Support-Team und ich glaube, in Dresden rotiert das ein bisschen. Zumindest bei der AOK.

Marten: Genau, bei der AOK rotiert das. Ich glaube, es gibt insgesamt vier oder fünf Teams, die in dieser Rotation drin sind. Da machen die einen mal Feature-Sprint A, die anderen machen Feature-Sprint B und das nächste Team macht wieder Support und so weiter und dann rotiert das die ganze Zeit.  Ansonsten ist mein Navigatoren-Team losgelöst. Wir machen wirklich nur Navigatoren, also wahrscheinlich ähnlich wie in Berlin. Ein Team, ein festes Projekt.

Lisa: Bei uns ist es so, dass der Kunde oder das Projekt fest in dem Team ist und der Support ist ein eigenes Team. Projektteams machen in der Regel keinen Support.

Ilja: Verstehe. Was macht denn bei queo besonders Spaß? Vielleicht auch im Vergleich zu vorherigen Arbeitgebern?

Lisa: Ich kann das immer tatsächlich am besten mit meinem vorherigen Arbeitgeber vergleichen, denn ich war vorher bei einer sehr kleinen Butze. Da waren fünf Leute oder so. Und da habe ich mein Praxissemester angefangen, hatte das Glück, dass sich ein Projekt verschoben hat, für das ich eigentlich die Doku hätte schreiben sollen, und deswegen von Anfang an programmieren durfte. Das Unternehmen war ziemlich klein und irgendwann habe ich mir etwas Größeres gewünscht. Nur das Arbeitsklima konnte ruhig so bleiben – familiär, mit flachen Hierarchien. Ich meine, mein Chef saß einen Raum weiter, so ungefähr. Und dann war ich bei queo. Damals waren queo Berlin und Dresden noch ein bisschen getrennter. Und dort hat es sich genauso familiär angefühlt, nur mit 25 Leuten. Das ist perfekt. 25 Leute ist eine schöne Größe, da sitzen auch alle nah beieinander. Ich kann jederzeit zu meinem Vorgesetzten gehen und mit ihm reden. Der weiß auch, wer ich bin, nicht nur eine Nummer. Und das fand ich ziemlich cool. Wir mögen uns alle, wir verbringen auch gern Zeit außerhalb von der Arbeitszeit miteinander, aber trotzdem hat jeder noch sein Privatleben und das weiß auch jeder zu schätzen und respektiert jeder. Man arbeitet sich hier nicht kaputt. Diese Work-Life-Balance kann man gut ausleben. Wir haben ja viele Leute, die nicht Vollzeit arbeiten. Ich hatte zum Beispiel letztes Jahr auch drei Monate Sabbatical, das ich zwei Jahre vorher angekündigt und angespart habe.

Das ist perfekt. 25 Leute ist eine schöne Größe, da sitzen auch alle nah beieinander.

Ilja: Was könnte man jemandem mitgeben, der gerade überlegt, wo er/sie als nächstes hingeht? Was ist eine typische Aufgabe oder was ist das Spannendste, was ihr gemacht habt?

Marten: Wir bekommen zum Beispiel Hilfsmitteldaten geliefert, das sind dann einfach 50 Gigabyte große Zip-Dateien, die du nicht entpacken darfst und auch nicht so ohne Weiteres transferieren darfst, sondern du musst erstmal chunken, dann musst du die irgendwie im Stream entpacken und dann importieren. Dann musst du auch noch darauf achten, dass du für die ganzen Entitäten eine passende Versionierung hast.  Zum Beispiel: Der Name des Leistungserbringers, der darf nicht überschrieben werden, wenn der einmal vom Leistungserbringer editiert worden ist. Wir sind mittlerweile wirklich eine so große Datenplattform, wir haben über 200 verschiedene Datenquellen. Das alles miteinander zu vereinen, das ist eigentlich eine fortlaufende, große technische Challenge.

Ilja: Cool. Wie sieht es mit Scrum bei euch aus? Macht ihr das? Unterscheidet es sich von Team zu Team? Lisa, du hast ja vor Kurzem den Kurs zur Scrum-Masterin gemacht.

Lisa: Was wir halt auf jeden Fall machen ist so eine Sprint-Iteration, aber mehr für uns, weil die Projekte sind fest. Das sind keine agilen Projekte, die wir machen. Du hast eine Deadline, du hast ein Angebot, das schon feststeht, mit einem Preis und mit Anforderungen. Das ist dann wirklich mehr für uns, um zu planen, was wollen wir jetzt die nächsten vier Wochen machen. Wir haben einen Vier-Wochen-Sprint. Wir versuchen am Ende des jeweiligen Sprints auch eine Retro zu machen. Reviews haben wir inzwischen auch etabliert.  Was wir noch zusätzlich machen, ist einmal im Quartal oder einmal im Monat eine Team-Retro. Also dass wir uns im Team einfach mal sehen und wirklich reden, ungeachtet von Homeoffice. Weil: Wenn du jeden Tag für 15 Minuten so einen Daily Stand-Up hast, da redest du jetzt vielleicht nicht über den Elefanten, der da im Raum steht, was vielleicht im Team gerade schlecht läuft.

Ilja: Marten, wie ist das bei euch?

Marten: Bis Juni letzten Jahres waren wir noch ein großes Navigatorenteam, mutiert auf bis zu neun Leute. Und da haben wir auch Scrum versucht. Wir hatten Daily, wir hatten eine Retro, eine Sprintplanung und so weiter. Aber mit allen Meetings war das sehr anstrengend und das war sehr ineffizient. Genauso bei der Sprintplanung. Da gibt es dann immer dieselben zwei, drei Leute, die Tickets mit refinen und sich bei einer Planung beteiligen. Und die anderen schalten dann halt einfach weg. Mitte des Jahres haben wir uns dann geteilt in zwei verschiedene Teams.  Und ich kann jetzt nur aus unserem Vierer-Team – ich bin im kleineren Team – berichten. Die Dailys sind jetzt begrenzt auf fünf bis zehn Minuten; megacool, megaeffizient. Ich bin da auch ein Freund von kurzen, knackigen Meetings mit vielen Informationen pro Minute. Und genauso die Sprintplanung, die machen wir auch nur in unserem Vierer-Team. Das macht es qualitativ besser. Auch die Tickets sind besser refined, weil halt wirklich jeder dieser vier Leute mit dran sitzt und ein Interesse daran hat, dass das Meeting auch schnell durch ist. Es muss nicht immer direkt „richtiges” Scrum sein, damit es sich im Arbeitsalltag gut anfühlt, sondern man muss auch auf die Bedürfnisse des Teams eingehen. 

Ilja: Schätzt ihr Tickets? Oder rechnet Gesamtbudgets für einen Sprint aus?

Lisa: Wir schätzen in Story Points. Wenn ein Change Request reinkommt, müssen wir das natürlich trotzdem auch in Zeiten für den Kunden schätzen, weil natürlich nicht über Story Points abgerechnet wird, sondern über Stunden oder Personentage.

Ilja: Und bei euch, Marten?

Marten: Bei uns ist das ein bisschen anders, tatsächlich. Grundlegend haben wir ein großes Projekt, wo eigentlich von 2020 an über die nächsten drei Jahre feststand, was wir ungefähr wann fertig haben wollen, was wir ablösen müssen. Aber hin und wieder kommen natürlich auch Sonderbeauftragungen rein. Unsere Kundin ist in ihrer Domain superkompetent und versteht auch unsere technischen Zusammenhänge. Da haben wir auf der Kundenseite wirklich einen richtigen Glückstreffer gelandet. Wenn wir uns dann irgendwie auf ein Feature-Set geeinigt haben, dann nehmen wir das nochmal mit ins Team. Dann wird es dort nochmals zwischen allen Entwicklern diskutiert. Im Anschluss erarbeiten wir einen Kostenvoranschlag anhand von Aufwandsschätzung. Der trifft es aufgrund unserer Erfahrungen meist ziemlich genau.

Ilja: Zum Schluss vielleicht noch ein kleines technisches Thema. PHP-Entwickler:innen, die sind ja fast „ausgestorben”. Vielleicht kann jeder von euch, da ihr damit arbeitet, eine kleine Liebeserklärung an PHP richten?

Lisa: Also ich habe natürlich jetzt nicht so einen großen Vergleich. In meinem Arbeitsleben habe ich nur PHP gemacht. Ich habe natürlich in meiner Ausbildung C und C++ gelernt, in meinem Studium Java und fand es ganz furchtbar. Ich meine, mit C++ habe ich objektorientierte Programmierung gelernt. Die Syntax ist halt anders, aber groß was anderes ist es ja im PHP dann auch nicht. Ich programmiere ja nicht in reinem PHP, ich habe ja immer ein Framework. Das heißt, ich habe auch immer Methoden, die ich nicht selber schreiben muss, die schon da sind. Ich habe in TYPO3 Extbase. In Neos heißt das Flow.  Ich möchte mich jetzt auch mal ganz gerne mehr mit Symfony beschäftigen, weil das ja auch mehr kommt und ich auch bei den ZDs einfach mehr verstehen möchte, dass ich nicht immer jemanden fragen muss. Diesen Korb an Frameworks, den ich da habe, finde ich eigentlich ganz cool. Und auch einfach, dass man so simple Datenbankabfragen in Doctrine machen kann. Da muss ich kein SQL-Statement mehr schreiben, das ist doch cool. Ich verstehe nicht, warum da so schlecht geredet wird.

Marten: Was soll ich sagen? Ich bin an PHP gar nicht so fest gebunden, aber wenn ich jetzt noch ein paar schlagkräftige Argumente für PHP nennen müsste, wäre es auf jeden Fall einmal die große Community. Was dir an Tools bereitgestellt wird. Ich denke da an solche Sachen wie Deployer, was dir bei der Release-Automatisierung hilft. Der Einstieg in PHP ist supercharmant, gerade als Programmieranfänger, weil du erst mal nicht unbedingt statisch typisieren musst. Das kann man bei späteren PHP-Versionen.  Und da ist der Einstieg supereinfach, im Vergleich zu Java. Warum schreibe ich da jetzt nochmal Public String und nicht einfach Public und meine Variable? Wie erkenne ich denn jetzt, dass das eine Variable und keine Methode ist? Da hast du bei PHP einfach das Dollarzeichen davor. Das ist relativ eingängig zu erklären. Im privaten Umfeld mache ich relativ wenig mit PHP. Da bin ich eher bei C# mit Unity und vielleicht mal mit Python. Mittlerweile ist es so: Wenn ich mir kurz irgendein kleines Script bauen will, irgendeinen Crawler oder sowas, dann nutze ich halt Python. Ich nutze, das, was mich am schnellsten ans Ziel bringt. Mal ist es C#, mal ist es Python, mal ist es Java, selten auch mal ist R.

Lisa: Dass eines besser als das andere sei, hat man ja eigentlich immer. Das hat man ja nicht nur bei Programmiersprachen, das hast du ja auch bei Marken, welche dieselben Dinge herstellen. Ich habe das auch im Studium ganz viel gehört. Als ich gesagt habe, dass ich bei einer Firma, die mit TYPO3 arbeitet, mein Praktikum mache, haben alle gesagt: „Was willst du denn mit TYPO3, das ist in zwei Jahren tot und mach doch lieber WordPress.“ Es ist jetzt sieben Jahre her, ich bin immer noch hier, also so schlimm kann es ja nicht gewesen sein.

Ilja: Hauptsache, man löst das Kundenproblem. Der Hersteller des Bohrers beim Zahnarzt ist mir letztlich auch egal.

Vielen Dank an euch, hat Spaß gemacht.