Meine Rolle bei RomSoft umfasst ein gutes Stück „Übersetzungsarbeit“. Nicht von einer Sprache in eine andere, sondern vom Ingenieurssprech in die Alltagssprache. Ich helfe meinen Kolleginnen und Kollegen, das, was sie tun, aus der Sprache ihrer technischen Dokumente und ihres Teamalltags zu den Menschen zu bringen, die das Produkt nutzen oder entscheiden, ob sie es mit uns entwickeln.
Das bedeutet viele Gespräche hin und her, vor allem wenn es darum geht, welche Geschichten es wert sind, im RomSoft-Blog erzählt zu werden. Unsere Ingenieurinnen und Ingenieure schreiben ihre Artikel selbst. Gemeinsam finden wir die Geschichte: In Brainstormings und Interviews entdecken wir die Themen und Blickwinkel, die sich zu vertiefen lohnen, und danach unterstütze ich beim Redigieren und Korrekturlesen.
Teambesprechung bei RomSoft
In den vergangenen Jahren habe ich mich mit Ingenieurinnen und Ingenieuren sowie F&E-Fachleuten aus unseren Teams zusammengesetzt – von Kolleginnen und Kollegen, die Software an echter medizinischer Hardware testen, bis hin zu denen, die KI-gestützte Dokumentationstools für Kliniken entwickeln. Als Außenstehende, die das Privileg hat, einen Blick in diese Projekte zu werfen, fallen mir immer wieder die unterschiedlichen Wahrnehmungen auf. Die Details, die sie für selbstverständlich oder zu technisch halten, sind oft genau die, die ich am spannendsten finde.
Hier ist ein solcher Austausch mit unserer Kollegin Simona, die seit Jahren Software für Medizinprodukte entwickelt. Das Detail findet sich auch in ihrem Artikel Programming for Medical Devices Is a Whole Different Game:
– Wow, ich hatte keine Ahnung, dass Open-Source-Frameworks bei der meisten Software für Medizinprodukte ein No-Go sind! – Na ja, klar, wegen der regulatorischen Vorgaben! – Ist das nicht ziemlich ärgerlich? – Schon. Aber es macht auch Spaß, weil man seine eigenen Bibliotheken oder Frameworks schreiben kann. |
Wenn ich meinen Kolleginnen und Kollegen sage, dass genau solche Details ihre Geschichte interessanter und nahbarer machen, schauen sie mich überrascht an. Mit der Zeit lernen sie aber, die Muster zu erkennen, die ihre Fälle überzeugender machen, und nutzen sie immer wieder in ihren Projektgeschichten.
Drei davon tauchen immer wieder auf:
„Es kommt darauf an“ ist keine Ausrede
Fragt man eine Ingenieurin oder einen Ingenieur, ob ein Projekt KI-Agenten einsetzen sollte oder wie lange eine Migration dauern wird, lautet die erste Antwort fast immer: „Es kommt darauf an.“ Früher habe ich das als Ausweichen verstanden.
Heute verstehe ich es als Respekt gegenüber dem Gegenüber. Der eigentliche Mehrwert liegt darin, wovon es abhängt: von den beteiligten Daten, dem regulatorischen Umfeld, dem Team und dem Risiko, das jemand bereit ist zu tragen. Genau das muss ein Kunde hören, bevor er eine Entscheidung trifft. Wir machen es uns nicht leicht: Wir behalten die vollständige, ehrliche Antwort bei und machen sie für unser Publikum verständlich.
Die Grenzen sind oft der glaubwürdigste Teil
Wenn jemand erzählt, was nicht funktioniert hat, welchen Edge Case er noch im Blick behält oder warum die Wahl auf die unspektakuläre Option fiel, liegt der erste Impuls oft darin, genau diese Teile wegzulassen.
Wir haben gelernt, sie zu behalten. Eine Geschichte, die offen zeigt, wo ihre Grenzen liegen, ist an allen anderen Stellen viel glaubwürdiger. Für Kunden in regulierten Branchen, die schon jedes Versprechen des Marktes gehört haben, ist gerade die ehrliche Grenze oft das, was den Rest der Geschichte überzeugend macht.
Als Simona erzählte, wie sie die gesamte Dokumentation für die Vollständige Softwareneuentwicklung für ein Medizinprodukt der Klasse C verantwortet hat, erwähnte sie ein Detail, das viele andere als unwichtig abgetan hätten: Ihr Team konnte keine moderneren, leistungsfähigeren Kommunikationsprotokolle einsetzen, weil die alte LAN-Verkabelung zwischen dem CT-Raum und dem Kontrollraum des Assistenzpersonals in den Wänden der Klinik verbaut war und nicht ersetzt werden konnte. Genau das wurde zu einem der überzeugendsten Teile ihrer Geschichte: eine reale Einschränkung, die sich durch keine Technik der Welt wegentwickeln ließ.
Vertraulichkeit sorgt für besseres Storytelling
Ein Großteil unserer Arbeit unterliegt einem NDA. Oft dürfen wir weder den Kunden noch das Gerät oder das Produkt nennen. Anfangs fühlte sich das an, als würden wir mit einer gebundenen Hand schreiben. Mit der Zeit wurde daraus eine Disziplin. Ohne ein Logo, auf das man sich stützen kann, muss man herausfinden, worauf es wirklich ankommt: das Problem, die Einschränkung, die Entscheidung und was sich dadurch verändert hat. Genau diese Teile kann ein künftiger Partner in seiner eigenen Situation wiedererkennen, und sie funktionieren auch ganz ohne Namen.
Was die drei Lektionen verbindet
Alle drei Lektionen weisen in dieselbe Richtung. Die Details, die einer glatten Geschichte scheinbar im Weg stehen – die Bedingungen, die Grenzen, die fehlenden Namen –, sind meist genau das, was sie vertrauenswürdig macht. Eine gute Übersetzung bewahrt sie.
Über meine Arbeit
Kurz gesagt: Ich kommuniziere technische Themen verständlich. Etwas ausführlicher: In fast jedem Softwareentwicklungsprojekt steckt unter vielen Schichten technischer Dokumentation eine menschliche Geschichte, die es wert ist, entdeckt zu werden – und ich liebe es, danach zu graben. Am liebsten frage ich immer wieder: „Moment, kannst du das noch mal erklären?“, bis es selbst für eine Nicht-Ingenieurin wie mich Sinn ergibt. Das und unsere Gruppenfotos nach Herzenslust zu bekritzeln.