Friederike Löwe

Was ich gerade mache

Seit März 2025 arbeite ich bei WLP Systems an Fachverfahren öffentlich-rechtlicher Rundfunkanstalten, etwa im Honorar- und Lizenzumfeld: in der Business-Analyse, in der Projektleitung für die Weiterentwicklung und Betreuung eines Fachverfahrens und in der Frontend-Entwicklung einer barrierefreien Webanwendung.

Schwerpunkte

• Requirements Engineeringvon der Vision bis zur Feinspezifikation: Anforderungen so klären, dass Fachbereich und Entwicklung dasselbe meinen · IREB CPRE und RE@Agile Practitioner
• Verlässliches Arbeiten mit KIvom Experiment zur Verlässlichkeit: wie sich Entwicklungsprozesse mit KI verändern und wo sie klare Prüfschritte brauchen
• Barrierefreie Webanwendungendamit alle gut mit einer Anwendung arbeiten können – auch mit Screenreader, Tastatur oder starker Vergrößerung · nach BITV

Wie ich arbeite

In einem meiner Projekte war mein wichtigster Gesprächspartner jemand, der später mit der Software arbeiten würde. Ich habe mir zeigen lassen, wie er arbeitet und was ihm wichtig ist, und mit ihm geprüft, ob die Software für seine Fälle fachlich das Richtige tut.

Im Gedächtnis geblieben ist mir vor allem, wie er Absagen formuliert: Auch wenn er selbst nicht helfen kann, verweist er die Anfragenden auf andere Möglichkeiten. Eine Software, deren Standardabsage klingt, als gäbe es keinen anderen Weg, hätte ihm widerstrebt.

Bei Lionizers habe ich die Entwicklungsergebnisse über viele Projekte hinweg verantwortet – vom Ein-Personen-Projekt bis zum Team, das über Jahre Embedded-Software entwickelt. Ich wollte einen Mindeststandard für Qualität und einen Schutz gegen bestimmte Risiken. Und ich wollte, dass alle mitkommen: ein gemeinsames Fundament für sehr unterschiedliche Projekte, statt dass jedes Projekt seinen eigenen Weg geht.

Deshalb haben wir den Prozess als Git-Projekt geführt, die Idee dazu kam aus dem Team. Die meisten Vorschläge habe ich geschrieben und vorher an verschiedenen Stellen nachgefragt, was die Leute brauchen. Jeder Bestandteil ging als Pull-Request durch das Review des ganzen Teams, und einige Änderungen kamen erst dort hinein. So kamen die Bedürfnisse der kleinen Projekte genauso in den Prozess wie die der großen.

Am Ende hatten wir einen Prozess, der sich auf unterschiedliche Randbedingungen zuschneiden ließ – mit einem klaren Fundament, das nicht gekürzt werden durfte.

Was ich lerne

Was mich an Weiterbildungen interessiert, sind die Arbeitstechniken – die Beschreibungen, wie man etwas gut macht. Als ich zu Beginn meiner Berufszeit UML, Entwurfsmuster, Softwarearchitektur und Refactoring kennengelernt habe, war ich begeistert. Diese Denkmuster helfen so sehr dabei, Probleme zu strukturieren und aus verschiedenen Perspektiven zu sehen. Dasselbe wollte ich für Anforderungen erreichen.

Beim RE@Agile kam eine Frage dazu, die mich lange begleitet hat: Warum gibt es so viel Abneigung gegen Requirements Engineering, und warum soll es mit agilem Arbeiten schwer vereinbar sein? Diese Diskussionen konnte ich nie ganz nachvollziehen.

Meine Antwort bisher: Agile Frameworks wie Scrum lassen offen, mit welchen Techniken Anforderungen entstehen – das heißt nicht, dass man darauf verzichten sollte. Anforderungen haben verschiedene Flughöhen und werden nach und nach verfeinert. Am Anfang stehen eine Vision, eine grobe Roadmap und eine Priorisierung nach Geschäftswert und Risiko. Die Feinspezifikation entsteht dann iterativ – so, dass immer genug für die nächsten ein, zwei Sprints bereitliegt und nicht zu viel vorher in Stein gemeißelt wird. Fehlt aber der grobe Rahmen, entwickeln wir womöglich so weit ins Blaue hinein, dass wir das eigentliche Warum aus den Augen verlieren. Das gibt das agile Mindset nicht vor – aber ich habe Menschen getroffen, die kaum weiter als bis zum nächsten Sprint planen wollten – und das hat mich immer gewundert.

Und es gibt einen ganz praktischen Grund: Wenn ich Anforderungen nicht nach Gefühl modelliere, sondern die Regeln verstehe, kann ich einen Weg finden, bei dem mich KI unterstützt – systematisch und nachvollziehbar.

Verantwortung

2015 haben Nils Löwe und ich das Manifest für verantwortungsvolle Softwareentwicklung geschrieben – gemeinsam mit vielen der ersten Unterzeichnenden. Es enthält fünf Versprechen:

• die Verantwortung für die Software übernehmen, die ich schaffe
• mich des Vertrauens würdig erweisen, das mir als Fachexpertin entgegengebracht wird
• keine Software entwickeln, die dazu dient, die persönlichen Rechte anderer zu verletzen
• nur die Daten erheben, die für eine Aufgabe nötig sind – und sie nur so lange speichern wie nötig
• zu einem verantwortungsvollen Energie- und Ressourcenverbrauch beitragen

Ein Ideal – vermutlich eins, das man nie ganz erreicht. Elf Jahre später prüfe ich in einer Serie auf LinkedIn, was davon in der KI-gestützten Entwicklung noch trägt. Meine Vermutung bisher: KI macht keines der Versprechen überflüssig, sie verschiebt nur die Stelle, an der sie im Alltag in Gefahr geraten. Ich schreibe die Serie, um dabei selbst zu lernen – und Widerspruch hilft mir dabei.

Mein Weg

1. seit 2025WLP Systems · Business-Analystin und ProjektleiterinFachverfahren öffentlich-rechtlicher Rundfunkanstalten
   Was ich dort gelernt habe

   Hier habe ich gemerkt, wie gern ich teile, was ich gerade lerne – in kurzen Vorträgen im Kollegium. Ich freue mich, wenn jemand später mit einer konkreten Frage zu mir kommt und ich merke, dass ich etwas angestoßen habe.

2. seit 2023FUMP · Mitgründerin und DesignerinKonzeption und Design, 2024 Projektleitung der Produktentwicklung – fump.io
   Was ich dort gelernt habe

   An FUMP gestalte ich seit 2024 mit: erst die Leerzustände und Fehlermeldungen der ersten App-Version, zusammen mit zwei Entwicklern, dann 2026 das neue visuelle Design – Farben, Gestaltungselemente, Illustrationen –, das Nils in die von ihm neu aufgesetzte Oberfläche eingearbeitet hat.

3. 2016 – 2024Lionizers GmbH · Mitgründerin, operative VerantwortungSoftware für mittelständische B2B-Unternehmen. Agile Entwicklungsprozesse unternehmensweit aufgebaut, alle Projektleitungen begleitet, bis zu 15 Personen geführt.
   Was ich dort gelernt habe

   Wie wir unseren Entwicklungsprozess gebaut haben, steht oben unter Wie ich arbeite.

   Gegen Ende meiner Zeit bei Lionizers habe ich interimsweise die Projektleitung in einem EU-geförderten Verbundprojekt übernommen. Gemeinsam mit einem externen Projektleiter, den die Forschungspartner hinzugezogen hatten, haben wir offene Anforderungen geklärt und den nächsten Meilenstein geplant.

4. 2013 – 2016E&K Automation · Software-Entwicklerin und -ArchitektinFahrerlose Transportsysteme; eine einheitliche Architektur, die Projektierung und Qualitätssicherung standardisiert
   Was ich dort gelernt habe

   Systematisches Arbeiten ist in der Softwareentwicklung überhaupt nicht selbstverständlich. Der Neubau sollte eine gewachsene Systemlandschaft vereinheitlichen, und dort habe ich verstanden, warum eine gemeinsame Architektur und saubere Versionsverwaltung keine Formalien sind. Ich habe auch gemerkt, wie schwer meine Fragen, meine Risikoanalysen und meine Ratlosigkeit für andere wiegen können.

   Heute übe ich, anders zu fragen: einzeln statt mit dem ganzen Berg, offen statt mit fertigem Urteil – und damit zu rechnen, dass die andere Seite etwas sieht, das mir fehlt.

5. 2012 – 2013Philips Medical Systems · SoftwareentwicklerinModellbasierte Software für Röntgengeneratoren nach V-Modell XT
   Was ich dort gelernt habe

   Ich habe gelernt, was ein streng geregelter Entwicklungsprozess leistet und was er kostet – und viel darüber nachgedacht, wie beides besser zusammengeht.

6. 2007 – 2012HAW Hamburg · Bachelor of Engineering, Informations- und Elektrotechnik
   Was ich dort gelernt habe

   Mit der Vertiefung Ingenieursinformatik habe ich Software-Entwicklung für ein sehr technisches Umfeld studiert. Gewählt hatte ich Elektrotechnik, weil ich dachte, das sei wie Programmieren, nur eine Ebene tiefer. Dass das ein Trugschluss war, habe ich unterwegs gelernt – und auch, dass man eine Sache nicht automatisch besser versteht, je tiefer man gräbt.

   Nebenher habe ich in Projekten gearbeitet, auf die sich andere verlassen müssen: Steuergeräte für Tsunami-Frühwarnsysteme, Offshore-Seismik, Solartechnik, Patientenbetreuung.

Aus dem Archiv

Von 2017 bis 2022 hat Nils Löwe im Podcast Software for Future mit über hundert Menschen aus Unternehmen, Forschung und Politik gesprochen – über die Frage, wie Digitalisierung und Nachhaltigkeit zusammengehen. Der Podcast ist abgeschlossen, alle Folgen sind mit Transkript weiter hörbar.

Ich habe ihn mit aufgebaut, produziert und vermarktet – und dafür einen Produktionsprozess entworfen, der alles rund um die Interviews strukturiert hat. Nils’ Zeit war unser Engpass, und so konnte er sie ganz für die Gespräche nutzen. Die Perspektiven unserer Gäste haben unser Bild von den Menschen, für die wir damals Software gebaut haben, deutlich geschärft.

Für mich selbst habe ich entdeckt, wie froh mich das Zeichnen macht: Ich habe die Illustrationen für die Episodenbilder gezeichnet, und unsere Designerin hat daraus die fertigen Cover gemacht. Außerdem, dass „Always have something to invite“ ein großartiger Rat ist – leider weiß ich nicht mehr, von wem er stammt. Und dass es wirklich eine Kunst ist, die richtigen Fragen zu stellen.

Mit Lars Lemmermann und Nils Löwe zusammen ist zu Digitalisierung und Nachhaltigkeit ein Fachartikel bei Informatik Aktuell erschienen.