Christiane: Hallo Merle, 
danke für deine Zeit. Du hast Medizinische Informatik studiert. Was heißt das?


Merle: Medizinische Informatik hilft dabei, medizinische Daten zu verarbeiten und zu analysieren. Ziel ist es z.B. medizinisches Personal auf Auffälligkeiten hinzuweisen und die Vorarbeit zur Diagnose zu vereinfachen. 
Im Studium hatte man grundsätzlich Informatik, also Mathe, Logik, theoretische Informatik etc. Parallel hatte ich Medizinfächer wie etwa Anatomie oder Pathologie. Sobald ein Grundwissen aufgebaut war, wurden die beiden Themenfelder verknüpft. 

So habe ich z.B. gelernt, wie Patientendaten gespeichert werden, wie digitale Prozesse in Krankenhäusern ablaufen oder wie medizinische Bildverarbeitung funktioniert. Konkreter bedeutet das etwa, wie man bei CT- oder MRT-Bildern automatisch Auffälligkeiten entdecken lassen kann. 

Christiane: Kannst du uns mehr darüber berichten, wie das geht?


Merle: Die Gewebe im Körper haben unterschiedliche Konsistenzen und Zusammensetzungen, die abgebildet und auf diesen Bildern anders dargestellt werde. Tumore, Läsionen im Gehirn – also wie es beim Schlaganfall ist – all das kann man auf den Bildern sehen. Und unsere Programmierung kann solche Auffälligkeiten kenntlich machen und die Ärztin unterstützen. Bei dem Thema geht es auch um  maschinelles Lernen. Denn zum Start, also vor dem Einsatz in der Klinik, lernen ebendiese Programme durch die Ärztin. Die Ärztin erhält dann z.B. verschiedene Bilder und gibt ein, ob es sich um einen Tumor handelt oder nicht. Sprich: Das Tool wird erst gründlich trainiert, bevor es in den Klinikalltag kommt.

Christiane: Danke, Merle. Wenn du nochmal zurück an dein Studium denkst: Was hat dich daran besonders gereizt?


Merle: Mir hat gefallen, dass es nicht nur abstrakt ist. Es verbindet Informatik, was natürlich tolle berufliche Zukunftsaussichten hat, mit spannenden, praktischen Themen. Deshalb hatte ich mich damals für das Studium in Lübeck entschieden. Medizinische Informatik ist nicht nur abstrakt. Wir sind Menschen, bestehen aus Gewebe und was kann uns alles passieren...?
Meine Abschlussarbeit vom Bachelorstudium war ebenfalls schön praktisch. Ich habe eine Mobile App gebaut, die die Ärztin nutzen kann, um Patientinnen direkt per Fragebogen zu befragen und in einem bestimmten medizinischen Standardformat weiterzusenden. Das sollte Ärztinnen die Interaktion am Krankenbett erleichtern.

Das Praktische ist, was ich wirklich gerne an Medizinischer Informatik mag. Man erwirbt coole Skills und Fähigkeiten, lernt immer mehr. Damit will ich gerne Dinge machen, wo ich ethisch dahinter stehen kann. Wo ma denkt: Das hilft jemandem. Medizin ist dafür natürlich prädestiniert. Wenn ich meine persönlichen Werte einbringen kann oder einer Person etwas Gutes tun kann, würde ich mich freuen. Es ist auch ein besonderes Feld, weil es viel um sichere Übertragung sensibler Daten geht. Deswegen, lasst und die Chance nutzen und daraus was cooles machen!

Christiane: Danke für die Erklärung. Ein Wort vorhin hat mich natürlich direkt hellhörig gemacht: Pathologie. Heißt das, ihr habt im Studium tatsächlich auch mit Körpern gearbeitet?


Merle: Ja, wir waren im Leichenschauhaus. Ein paar wollten nicht oder sind herausgegangen. Wir sind übrigens in Anatomie in die Pathologie gegangen. In Pathologie ging es um Krankheiten.

Dazu fällt mir auch gerade etwas ein. Unser Anatomie Professor kam irgendwann mit einem Wagen an auf dem ein Rumpf lag. Dann hat er da die Gedärme rausgeholt und sie nicht wieder richtig reingekommen. Ein bisschen so, wie wenn man alles aus dem Koffer rausholt. Dann will man es wieder reinpacken und es geht nicht mehr. Das ist mir im Kopf: Wie er gekämpft hat mit den ganzen Gedärmen... 

Christiane: Das klingt... erinnerungswürdig. Vielen Dank für deine Zeit!

Wie kann man lernen, herausragende digitale Medizinprodukte zu erschaffen? Meine Kollegin Merle berichtet im Interview vom Studium der Medizinischen Informatik. 

Medizinische Informatik: Gesundheitsvorsorge von morgen

Die Idee scheint fantastisch, die Sicherheit groß: Das ist genau das Produkt, das zu diesem Zeitpunkt am Markt gefehlt hat! Das wird ein Erfolg! Nun noch eben einen Anforderungskatalog schreiben und dann ab in die Entwicklung damit. 

Damit genau diese Entwicklung nicht zu einem mehrjährigen, kräftezehrenden Prozess wird – deren möglicher Erfolg sich erst nach Jahren zeigt – hat sich der Bau eines Minimal Viable Products (MVPs) bewährt.

Warum sollten wir mit einem MVP beginnen?

Die Entwicklung eines MVPs bietet sich insbesondere für den Neubau von Produkten und das Testen von Ideen an.  Der Bau eines MVPs umfasst dabei ein stabiles und marktreifes Produkt, das auf seinen essentiellen Funktionsumfang reduziert ist. 

Mit schlankem Umfang und Funktionen dauert die Konzeptionierung, Entwicklung und das Testen eines MVPs nur wenige Monate. Bereits dann wird das Produkt getestet. 

Sofern diese Tests erfolgreich sind, also zeigen, dass ein nachhaltiger Mehrwert generiert wird, können Schritt für Schritt weitere Funktionen hinzugefügt oder ausgetauscht werden. Eine skalierbare und durchdachte Architektur zahlt sich ab jetzt besonders aus.

Ihr habt euch schon Monate mit eurer Idee beschäftigt und sie durchdacht. Deswegen bitten wir euch im ersten Schritt die Ziele des Produkts aufzuzeigen. Gemeinsam entwickeln wir eine Feature-Übersicht sowie eine Liste mit groben Anforderungen: Dies bildet die Basis unseres MVPs.

Wie wird die Idee umgesetzt? Wie bewegen sich die NutzerInnen durch die Anwendung? Diese und weitere Fragen klären wir in einem gemeinsamen Workshop mit AuftraggeberIn, methodischer BeraterIn, ArchitektIn sowie KonzepterIn. 

Ziel ist es, ein gemeinsames Prozessbild, Verständnis und Kontext zu erlangen. Zudem werden technische Herausforderungen identifiziert, die in der folgenden Phase ergründet werden.

Die Konzeptphase ist das Herzstück der Entwicklung. Hier wird der Bauplan für das spätere Produkt entwickelt und Grundsatzentscheidungen getroffen. 


Die ArchitektIn überträgt die Systemanforderungen in eine Systemarchitektur.

Technische Herausforderungen werden erforscht. 

Die KonzepterIn baut erste Wireframes und durchdenkt User Flows. 

Der Agile Coach verfeinert und priorisiert das Backlog.

Nun beginnt die dynamische Entwicklungsphase, organisiert in agilen Sprintzyklen. Hier setzen wir auf bewährte Frameworks wie Scrum oder Kanban.

Die Anzahl der Sprints bis zum fertigen MVP hängt von den Anforderungen ab. In unserer Erfahrung sind schlanke MVPs nach etwa 6-8 Iterationen test- und einsatzbereit. 

Das MVP ist einsatzbereit und kann an NutzerInnen getestet werden. Das liefert wertvolle Einblicke, wie die Anwendung angenommen wird und welche Verbesserungspotentiale vorhanden sind.

Schritt für Schritt wird das Produkt um weitere Bausteine erweitert oder Funktionen werden ausgetauscht, stets an den Nutzerinteressen ausgerichtet. So werden dynamische Marktentwicklungen und Trends beachtet und unnötige Entwicklungskosten weiterhin vermieden.

Bisher haben wir sehr gute Erfahrungen mit dem Bau schlanker MVPs gemacht, die einen schnellen Markteintritt mit einem stabilen Produkt ermöglichen. Ob ein MVP auch für euch eine gute Lösung ist, besprechen wir gerne und unverbindlich mit euch persönlich. Wir freuen uns auf eure Nachricht!

Planen, Entwickeln und Testen in wenigen Monaten

Früh den Markteintritt wagen: Mit dem MVP Zeit & Kosten sparen

Das Angebot an Frontend Frameworks ist riesig. Da gibt es die ganz großen Player wie React, Vue, Angular und Ember. Aber auch kleine Frameworks gibt es zahlreich, bis hin zum inzwischen belächelten jQuery. 

Zu dieser langen Liste gesellt sich nun auch Svelte. Mit derzeit 37 k Stars auf github gehört es zwar zu den Frameworks, welche große Aufmerksamkeit erzeugen, aber mit  102 k Downloads pro Woche auf npm eher zu den kleinen Playern. Zum Vergleich: React hat derzeit 157 k Stars auf github und 8.344 k Downloads auf npm. 

Um zu verstehen was Svelte macht müssen wir in der Geschichte etwas zurück gehen, in eine Zeit, als PHP noch der heiße Scheiß war. Damals haben Web Developer bereits angefangen auf einer gewissen Art komponentenbasiert zu arbeiten. In HTML wurden layouts angelegt, die dann via PHP mit Daten angereichert wurden. Das alles konnte man auch in "echte" Komponenten aufteilen und so z.B. die Navigationsleiste in eine eigene Datei auslagern und diese in andere Komponenten wieder integrieren.
Bei jedem Page-Request von einem Klienten/Endgerät baute der Server die angefrage Seite neu aus den "Komponenten" zusammen und sendete eine vollständig neue HTML Seite zurück. Der Browser musste die Seite also komplett neu rendern.

Als JavaScript im Browser keine Randerscheindung mehr war und der DOM mit Frameworks wie jQuery für alles mögliche manipuliert wurde, erkannte man, dass die ständige DOM Manipulation die Seiten langsam machte. Man erfand also den virtuellen DOM. Dieser ist schnell berechnet und manipuliert bzw. komplett neu aufgebaut, da sein Ergebnis nicht gerendert wird. Die Idee dahinter war, dass nun ein Vergleichsalgorithmus (diffing) den virtuellen DOM und den echten DOM nach einer potentiellen Änderung vergleicht und nur die tatsächlichen Änderungen gezielt am echten DOM durchführt. All dies sollte zur Laufzeit im Browser passieren. Dies war die Geburtsstunde von React! Seit dem arbeiten alle großen Frameworks mit diesem Paradigma.

Das hat dazu geführt, dass Webseiten viel schneller geworden sind, da ja nur die tatsächlich benötigten Operationen auf dem echten DOM ausgeführt werden und alles Andere wird virtuell berechnet. Ebenso bleiben die unveränderten Elemente einfach da und die Seite wird so reaktiv.

Bei der Idee von Svelte entfällt nun der virtuelle DOM komplett. Denn anstatt einen aufwendigen Vergleichsalgorithmus zur Laufzeit ständig die Änderungen ermitteln zu lassen, wird bei Svelte dieser Prozess zur Buildtime ausgeführt. Will man nun z.B. ein ToDo in einer Anwendung hinzufügen, so baut sich kein virtueller DOM neu auf, keine Algorithmus lokalisiert die Änderungen und fügt dann im Anschluss eine Checkbox mit Label im echten DOM hinzu. Nein, nun passiert beim Klick direkt die Manipulation des echten DOMs. Bei einem Klick wird also direkt die Checkbox mit Label zum DOM hinzugefügt.

Was in diesem Beispiel Millisekunden an Zeitersparnis sind, sind in Facebook Dimensionen enorme Mengen an Leistungsoptimierung.

Aber damit nicht genug. Svelte kann durch diesen Ansatz auf große Teile an JS Code im Browser verzichten, denn alles was passiert sind direkte DOM Manipulationen. Das bedeutet Einsparungen in Dateigröße und damit Einsparungen in Traffic, Übertragungsdauer, Berechnungszeiten des Browser und am Ende eben auch ein Stück Stromsparen bei allen Beteiligten.

Um das alles zu gewährleisten und keine aufwendigen Übersetzungsalgorithmen zu verwenden, benutzt Svelte HTML und JavaScript/ECMAscript. Es gibt kein Boilerplate wie JSX oder Ähnliches, sondern wir benutzen das was die Browser können und was vom W3C standardisiert ist. Und das alles isoliert in einer Komponente. Hier ein Beispiel:

#!/usr/bin/env html
<script>
    const a = 2;
</script>

<p>{a}</p>

States? Kein Statemanagement nötig, wir haben ja JS, also definiere eine Variable und schreib sie später um, z.B. in einem Input field:

#!/usr/bin/env html
<script>
    let a = 2;
</script>

<input type="number" bind:value={a}>

<p>{a}</p>

CSS? Durch das Scoping auf die Komponente benutzen wir hier einfach standardisiertes CSS und benötigen in den meisten Fällen nicht einmal Klassen:

#!/usr/bin/env html
<script>
    let a = 2;
</script>

<style>
  p {
    color: red;
  }
</style>

<input type="number" bind:value={a}>

<p>{a}</p>

Natürlich brauchen wir an dieser Stelle Zahlen von Svelte und Vergleichszahlen um alles einzuordnen. Auf github gibt es die "real world app" welche ein reales Beispiel einer Webanwendung zeigen soll. Hier findet man so ziemlich jedes Framework und kann sie miteinander vergleichen.

Und weil hier die Performance in ihren unterschiedlichen Facetten wichtig ist, gibt es einmal im Jahr einen Performance Vergleich, der dann so aussieht:

Wir sehen, Svelte Spielt in der gleichen Liga wie React Angular und Vue, zumindest nach den Google Lighthouse Kriterien. Hier merken wir also als User keine sonderlichen Unterscheide bei dieser Anwendung.

Svelte steht hier ungeschlagen auf Platz 1, mit einer Übertragungsgröße von knappen 10 KB. Zum Vergleich Vue 42 KB, React 97 KB.

Auch in der Kategorie "Wie viel Codezeilen braucht die App" mischt Svelte ganz weit oben mit. Auch wenn dieser Wert kritisch gesehen werden darf (kürzer ist nicht gleich besser), zeigt es doch auf, dass die gleichen Funktionen der App in React fast doppelt so viel Zeilen an Code benötigen.

Allerdings hat auch Svelte seine Schwächen. Damit Svelte eine Manipulation im DOM durchführt muss eine Variable verändert werden. Im Oberen Beispiel wird also der Variable "a" ein neuer Wert zugewiesen. Der Svelte Kompiler versteht dies und hinterlegt die entsprechende DOM Manipulation. 
Anders sieht das z.B. bei Arrays aus. Fügt man hier z.b. ein Feld dem Array mit ".push" hinzu, registriert das Svelte nicht. Zwar wurde die Variable um das Feld erweitert, also JS wird hier nicht kaputt gemacht, aber der DOM wird nicht manipuliert. Man muss hier einen kleinen Workaround einbauen:

#!/usr/bin/env javascript
// does not work!
const a = [1,2,3]
a.push(4)

// works
let a = [1,2,3]
a = [...a, 4]

Das fühlt sich ziemlich unnatürlich an, denn ich kann hier nicht einfach die seit langem in Js vorhandenen Methoden benutzen. Aus meiner Sicht ein großer Punkteabzug, denn ich muss auch immer selbst daran denken, kein Kompilier warnt mich an dieser Stelle.

Svelte ist meiner Meinung nach ein Schritt in die richtige Richtung. Es verbindet die Vorteile eines Komponentenbasierten Frameworks mit den Vorteilen von Boilerplate freiem, standardisierten HTML, CSS und JS. Zusammen mit Sapper dem Next.js Klon für Svelte sieht es so aus, als würde svelte den nächsten logischen Schritt in der Frontend-Entwicklung gehen. Wir behalten die Entwicklungen im Auge und freuen uns auf den Release von Sapper. Dann kann man auch überlegen ein kleineres Projekt in Production damit umzusetzen und real-world Erfahrungen zu sammeln.

Weitere Beispiele, z.B. wie Komponenten importiert werden, props übergeben werden und viels vieles mehr, findet ihr auf der Beispiel-Seite von Svelte.

Svelte ist ein Frontend-Framework und erzeugt gerade viel Aufmerksamkeit. Ist der Hype begründet?

Open-source software means that the source code of a software is publicly available. Everyone can read, copy or change the source code which makes the software more trustworthy and long-living than closed source software. Famous and big examples of open-source software projects are the Linux kernel, Firefox, LibreOffice or Android but there are also many many small open-source software projects out there.

If you can read code, you are actually able to understand and evaluate what is happening when you execute that software. Not only what the software pretends to do but rather what it really does.

This feature also allows everyone to scan the source code for security vulnerabilities or other weaknesses of any kind, which adds to the trustworthiness mentioned above.

Another main advantage is that you are able to request help from basically every user/contributor of that software which is mostly faster and provides more creative solutions than most commercial support.

Also, the software is not only dependent on the original author and can be maintained and extended by the community. There can be even different versions of the same software with different features. If the community thinks it would not be a good idea to add a specific feature, someone can copy the source code and release their own version of it.

You can learn a lot, and I mean really a lot! 

Reading and understanding the source code of other programs may not be easy, especially if the software is relative complex, but you will learn a lot in the progress as you are confronted with ideas and solutions from many other people which spend sometimes hours, days or even longer with a specific problem and came up with a solution.

If you are also willing to contribute and not only to use the software you gain another few advantages.

You will be forced to think way more about your problem than with closed source. As the software will be used by many other people, it is not only your specific use case which is relevant. This forces you to gain a deeper understanding of the concrete problem and you are also forced to think of reasonable abstractions and edge cases as well as configurability.

Another important step, which is often not really recognized is that it is not only important to fix the problem or build that feature, it is also very important to write readable and maintainable code, otherwise no one will be able to touch it and as the software evolves it may be removed eventually because no one understands.

As everyone knows, good documentation is key, you actually need to write documentation, otherwise, no one will be able to use your cool new feature

and the community of that project will not be happy and may not even merge your cool new feature. This all may sound difficult, but I think you will learn key skills which are important or beneficial for your whole career as a software engineer.

It is especially beneficial for job applications because others can really see what you are doing rather than just talking about it or even worse, test your skills on a whiteboard.

Another major advantage is the joy you feel when others actually use the software you have written, especially if it will be used in ways you don't even consider.

What may be viewed as a disadvantage is the monetization of your product. As this is true at the first glance, there are also ways of making money with open-source software.

If your software is a service you could provide a hosted solution where users would have to pay money to use it, but if they really want and have the resources they could also host it themselves.

On the other hand, you are an expert in using, customizing and developing the software, so if others need support they could hire you to help them.

Some individuals or companies are also sponsoring open source software maintainer through GitHub Sponsors or Patreon for example.

If your software grows and more and more people are contributing to it you will have no other choice than to set up some processes, like: "When is someone allowed to merge a PR?", "Who decides if something will be added or not?", "Who has the last word in case a conflict arises?", "What documentation is mandatory?", "Do we raise money?"(In case of a non-profit open-source project), "What kind of merchandising are producing?" and there are many many more, that are all questions that came to my mind in less than 5 minutes. To set up such rules and processes will feel cumbersome at the beginning, but you will not be able to grow your project without. There is no silver bullet, you will need to think of processes and rules on your own, what is applicable to your project, but sure you can grab inspiration from other open-source software projects.

Open-source software is very popular because of the trust this gives its users. Contributing to it also has a bunch of advantages for the contributing

individuals although it is way harder than working on individual and closed source software as you need to pay attention to more and greater details and you can even earn some money with it. 

Open-source software is everywhere and it's hard to imagine a world completely without. In this article, I will describe what Open Source is, why we should use it and how it can help us to be better engineers.

Als junge Entwicklerin möchte ich vor allem eines: Das ganze Spektrum der mir zugänglichen Technologien lernen, ausprobieren und anwenden. Als Person weiß ich aber auch, dass ich nicht allein auf der Welt bin. Mit den erlernten und zu erlernenden Skills der Entwicklung digitaler Produkte bin ich in der Lage dazu, Anwendungen, Webseiten und sogar Künstliche Intelligenzen zu entwickeln, die den Alltag vieler Menschen beeinflussen. Zum großen Teil haben die Nutzerinnen dieser Produkte wenig oder kein Wissen über die dahinter liegenden Technologien und können nicht im Ganzen verstehen, was im Daten- und Algorithmengewusel passiert. Wenn auch kein Wissen darüber vorhanden ist, was potentiell technologisch möglich ist, können von den Nutzerinnen auch keine konkreten Sorgen formuliert werden.

Daher liegt es unter anderem in meiner Verantwortung als Entwicklerin Produkte zu entwickeln, welche genutzt werden können, ohne dass die Verwendung für die Nutzerinnen unabsehbare Folgen hat. Zum Beispiel durch das Preis geben nicht notwendiger persönlicher Daten oder die nicht nachvollziehbare Kombination der Daten mit weiteren Daten aus anderen Kontexten. Wenn ich mich dabei technologisch austoben kann ist das nur eine zweite Kirsche auf dem Eisbecher. Wichtig dabei: Ich kann, aber sollte ich?

Wer die Möglichkeiten bestimmt, beeinflusst die Entscheidung 

Wie können die Personen, die verantwortlich für die Entwicklung digitaler Produkte sind, denn sicherstellen, alle Beteiligten am Ende wertvolle Produkte in den Händen halten? Der Zwiespalt zwischen Daten sammeln, um daraus Informationen zu gewinnen, die den Nutzerinnen zu Gute kommen (z.B. um mich mit meinen Freunden und Freundinnen zu vernetzen) und Daten sammeln, um meine eigenen wirtschaftlichen Interessen zu vertreten (z.B. gezielt Werbung schalten), bleibt. Beim Entwickeln der Produkte können die Verantwortlichen aber einige Dinge beachten, um zu gewährleisten, dass die entwickelte Anwendung einen Nutzen hat.

Mittlerweile ist die Welt ein enges Zusammenspiel aus Computern und Menschen. In der Gesellschaft verankerte Vorurteile spiegeln sich auch in Maschinen wieder. Werden diese Maschinen nun genutzt, werden Nutzerinnen wiederum von den implementierten Vorurteilen beeinflusst. 

Dafür gibt es zahlreiche Beispiele. So wurde etwa ein automatischer Seifenspender hergestellt, der bei Händen einer Person of Color nicht auslöste. Des weiteren deckte im Herbst 2019 eine Studie des Science Magazins auf, dass sich die strukturelle Benachteiligung von PoC in den USA auch in einem Algorithmus zur Abschätzung der gesundheitlichen Bedürfnisse widerspiegelt. Auch weibliche Personen sind von mangelhaften Überlegungen in der Softwareentwicklung betroffen. Eine Studie der UN stufte die zumeist weiblichen Stimmen der Sprachassistentinnen, wie Siri und Alexa, als problematisch ein. Warum? Es festigt den (noch) sehr präsenten Stereotyp, Frauen in „dienenden” Positionen zu sehen. 

In allen drei Fällen werden bereits vorhandene Ungleichgewichte durch Technologien reproduziert - und durch deren Wechselwirkung mit der Gesellschaft verstärkt. Nur ein divers aufgestelltes Entwicklungsteam ist sensibel für die Ungleichheiten in unserer Gesellschaft, macht diese für das gesamte Team sichtbar und kann somit Diskriminierung eindämmen. Eine Software ist nur so neutral und umsichtig wie sie geschaffen und trainiert wurde. Dieser Verantwortung sollte sich jede Entwicklerin bewusst sein.

Es ist wichtig, so früh und umfangreich wie möglich abzuschätzen, wie viel Schaden durch das Produkt entstehen könnte. Dabei kann es helfen, sich zu überlegen, was jemand mit andern Absichten als mir potentiell mit den gesammelten Daten anstellen könnte. Sind sie aus dem Kontext der Anwendung gegriffen noch genau so hilfreich? Zu welchen Schlüssen könnte man kommen, wenn sie mit anderen Daten kombiniert werden? Was sind die schlimmsten potentiellen Konsequenzen, die die neue Anwendung zu Folge haben kann? 

In Future Ethics führt Cennydd Bowles dazu das Beispiel AirBnB an, eine Webseite, die Nutzerinnen erlaubt ihre Wohnungen und Zimmer als Ferienwohnungen bereitzustellen. Werden Wohnungen zum Großteil an Urlauberinnen vermietet und stehen somit nicht mehr für Personen als Wohnraum zur Verfügung, hat dies wesentliche Folgen für die Wohnstruktur gesamter Städte. Dies fordert strikte Regulierungen zur Sicherung privaten Wohnraums. 

Unbeabsichtigt heißt nicht unvorhersehbar. Sicherheitslücken können nur rechtzeitig erkannt werden, wenn danach gesucht wird. Eine absichtliche Falschnutzung der entwickelnden Personen im Vorhinein kann verhindern, dass die Anwendung in anderen Händen missbraucht wird. So wie man nochmal kräftig am Stuhl ruckelt, den man gerade zusammen gebaut hat, um sicherzugehen dass er stabil ist.

Es gibt kein absolutes Pflichtenheft, es gibt keine Liste, die wir Entwicklerinnen durchgehen und abhaken können und dann sind wir ethisch auf der sicheren Seite. Es ist schwierig zu sagen, dass bestimmte Technologien ein Garant für einen sicheren Datenaustausch und eine Anwendung mit Mehrwert sind. So ist es mit Sicht auf Datenschutz besser, dezentralisiert Daten auf dem Gerät der Nutzerinnen zu speichern, gleichzeitig hat es aber auch viele Vorteile, Daten an einem zentralen Ort zu speichern, so dass zum Beispiel Gesundheitsdaten beim Arztwechsel oder beim spontanen Krankenhausaufenthalt sofort verfügbar sind. 

Es ist wichtig, sich mit allen beteiligten Expertinnen, sowie Nicht-Expertinnen auszutauschen, um Folgen richtig abzuschätzen. Dazu gehört Transparenz über die Funktion und den Hintergrund der Anwendungen, damit potentielle Nutzerinnen überhaupt wissen, was sie kritisch hinterfragen können. Aber auch zwischen Technologinnen muss es Absprachen geben. So wie es ein Pressekodex gibt, könnte es auch ein Technologiekodex, einen übergeordneten Code of Conduct, geben, bei dem sich die technologische Seite auf ein „Maß an Ethik“ einigt. Für brenzlige Fälle gibt es Gesetze auf die zurückgegriffen werden kann. So hat die EU im Vergleich zum Rest der Welt relativ strenge Bestimmungen zum Thema Datenschutz. 

Regulierungen müssen nicht immer nur zu Einschränkungen führen, sondern können auch unsere Freiheiten bewahren. So habe ich in Deutschland, die Freiheit meine Fitness-App zu nutzen und meine Gesundheit wie es mir beliebt verfolgen zu lassen. Dabei muss ich keine Angst haben, dass meine Krankenversicherung mir eine Kündigung schickt, sobald sie mitbekommt, dass ich nur 1000 Schritte in der ganzen Woche gehe, obwohl ich diese an einem Tag erfüllen sollte. Ein Dank an die gesetzlich vorgeschrieben Krankenversicherung. 

Allerdings sind auch Gesetze nicht immer moralisch auf der Höhe. Es ist noch gar nicht so lange her, dass Rosa Parks gegen das Gesetz verstieß, als sie sich als PoC in das Busabteil setzte, welches nur für weiße Personen bestimmt war. Es gilt an uns auch da, immer wieder zu überprüfen, ob diese ausreichen oder ihr Ziel verfehlen. Letztendlich kommen die ethischen Fragen nicht von den Maschinen, sondern von uns. Von den Entwicklerinnen, die absehen können wo unsere Daten landen und wozu. Das alles ist schwierig als Einzelkämpferin, deswegen ist es wichtig, unsere Kolleginnen auch auf die Verantwortung hinzuweisen und sich gemeinsam dafür einzusetzen, Produkte zu entwickeln, mit denen wir mit einem guten Gewissen ins Bett gehen können (also nicht wirklich, wegen den eckigen Augen). Hätte nur eine Google-Mitarbeiterin gegen die Arbeit mit Drohnen protestiert, hätte das wahrscheinlich niemanden interessiert.

Leider ist es nicht immer so einfach, nur Produkte zu entwickeln, welche moralisch einwandfrei vertretbar sind. Das Geld und die technologischen Ressourcen liegen dann doch bei großen Firmen, welche Nutzerinnen in manchen Fällen sogar gezielt manipulieren und bei denen persönlichen Daten eine Währung sind. Dennoch könnten wir uns als Entwicklerinnen, Designerinnen, Projektmanagerinnen etc. bewusst machen, dass wir sehr mächtige Skills haben, mit denen wir beeinflussen können was unsere Umwelt anklickt, und dass wir, auch wenn es vielleicht erstmal nur im kleinen Kreis ist, beeinflussen können ob und wie wir diese Skills einsetzen.

Bowles, Cennydd. (2018) Future Ethics. NowNext Press. (Große Empfehlung!)

Über die gesellschaftliche Verantwortung von Softwareentwicklerinnen. 

Ethik & Digitalisierung - Wo ein Weg ist, ist auch ein Wille?

Institutionen und viele Geschäfte bleiben geschlossen, immer mehr Firmen raten ihren Mitarbeiterinnen zum Homeoffice – sei es aus Schutz der Mitarbeiterinnen oder aus Rücksicht auf die Allgemeinheit.

Da wir Homeoffice bei farbenmeer schon lange selbst leben, teilen wir heute mit euch unsere Erfahrungen.

Natürlich kann nicht jede von heute auf morgen Homeoffice machen. Diese Dinge benötigt ihr:

Wenn Homeoffice bei euch eine Lösung ist, die eure Arbeitgeberin sich langfristig vorstellen kann, dann solltet ihr auf etwas mehr Komfort achten. Vielleicht beteiligt sich eure Arbeitgeberin ja sogar finanziell daran?

Webcam (auf dem Monitor positioniert; so könnt ihr auf sprichwörtlich auf Augenhöhe miteinander kommunizieren)

Beim gemeinsamen Arbeiten an verschiedenen Orten, ist es besonders wichtig, auf einen gelungenen Informationsaustausch zu achten. 

Bei uns ist das „Daily“  ein fester, täglicher Termin im Kalender. Dafür trifft sich das ganze Team jeden Tag zur selben Zeit in einem Google Meet und bespricht  alles, bei dem es wichtige Entwicklungen gab – von internen Belangen bis zu Kundenprojekten. So wissen wir immer, wer wofür die Verantwortung trägt. Zudem machen wir Abhängigkeiten klar und stellen heraus, wer auf die Arbeitspakete einer anderen angewiesen ist. Am besten ist, wenn ihr beim Daily die Kamera an habt. 

Damit auch Kolleginnen, die mal nicht am Daily teilnehmen können, immer up-to-date sind, verfassen wir einen täglichen Newsletter mit der Zusammenfassung. Diesen posten wir dann in unserem Slack-Channel „Newsletter“. Schriftlich, asynchron und sichtbar für alle Teammitglieder.

Organisation und Priorisierung der Informationen

Womit wir auch schon zu unserem nächsten Tool kommen, das uns das gemeinsame Arbeiten erleichtert: Slack.

Wir haben diverse Slack Channels, d.h. themenbezogene Chats. Diese reichen von „intern“ für alle bis hin zu projektbezogenen Channeln, in denen nur die Projektverantwortlichen sind. In diesen Channeln posten wir tagsüber, wenn es beendete Arbeitspakete oder andere relevante Entwicklungen gibt. Das stärkt den Austausch sowie die Motivation, wenn man den Fortschritt der anderen sehen kann.

Wichtige Informationen und Änderungen, die alle im Unternehmen betreffen, solltet ihr nicht in Slack teilen. Sendet lieber eine E-Mail an alle Kolleginnen und kommuniziert die Änderung noch einmal im Newsletter. Dann geht wirklich nichts unter.

Für Dokumente, an denen mehrere Kolleginnen parallel arbeiten, nutzen wir bei Textdokumenten Google Docs und für Tabellen Google Sheets.

Eine weitere Kunst bei der Organisation von Informationen ist das Bereitstellen von Dokumenten, wie z.B. Angeboten oder Verträgen. Diese sollten nicht nur in gedruckter Form abgelegt werden, sondern auch digital. Welche Tools euch dabei helfen, stellen wir euch im kommenden Blogbeitrag vor. Aus Erfahrung können wir nämlich sagen: Das ist gar nicht so leicht, wie man denkt. Aber das Thema bedarf besonderer Beachtung, da es die Grundlage für schnelles und effizientes Arbeiten ist.

Meetings und kurze Gespräche im Homeoffice können schnell zum Zeiträuber werden und dich bei deiner konzentrierten Arbeit unterbrechen. Deswegen plane ich mir gerne Blocker, also Zeiten ein, in denen ich nicht gestört werden möchte, sondern konzentriert und fokussiert bleiben kann. Ich bin also nicht immer erreichbar. Das ist auch völlig in Ordnung, wichtig ist nur: Teile das mit deinen Kolleginnen. Kommuniziere klar, was du vorhast und warum du nur per Telefon erreichbar sein wirst und teile am kommenden Tag deine Arbeitsergebnisse. Dann kommt bei deinen Kolleginnen gar nicht erst die Idee auf, dass „Homeoffice“ bei dir ein Synonym für „Game-of-Thrones-Ansehen“ sein könnte.

Auch Meetings sind im Homeoffice eine ganz eigene Herausforderung. Schwupps, stellt die Kollegin einen Termin zu einem Thema ein, aber keine bereitet es richtig vor. Um das zu vermeiden gilt: Termine sollten immer mit einer klaren Agenda, dem Ziel des Termins sowie Informationen zur notwendigen Vorbereitung versehen werden. Gegebenenfalls hilft es, auch eine Moderatorin zu bestimmen, die den Termin leitet und zielgerichtet vorantreibt.

Beziehungen pflegen und Vertrauen aufbauen

Beim Arbeiten im home office verfalle ich stets leicht in einen Effizienz-Trott. Ich arbeite still vor mich hin und plötzlich merke ich: Mir fehlt eine Information. Ohne die, geht es nicht weiter. In solchen Situationen schreibe ich meine Kollegin an, ob wir kurz telefonieren können. Wer gerade nicht völlig im konzentrierten Arbeiten versunken ist, meldet sich dann. Nun tappe ich besonders gerne in die Falle, meine Information abzuholen und wieder Tschüss zu sagen. Ein paar mal geht das, aber eine gute Beziehung erhält man so sicher nicht aufrecht. Ergo: Am Anfang des Gespräches erkundigen, wie es dem Gegenüber geht und sich selbst klar machen, dass man soziale Kontakte auch remote pflegen sollte. 

Leiden die sozialen Bindungen, leidet nämlich ganz schnell auch das Vertrauen innerhalb des Teams. Da remote zu arbeiten weniger Kontrolle für deine Teammitglieder und Vorgesetzten bedeutet, ist es deshalb unerlässlich, Vertrauen zu fördern und zu stärken.

Da wir bei farbenmeer eine sozialkontakt-suchende Herde sind, arbeiten die meisten von uns gerne auch mal im Büro. Alleine, um mit den Kolleginnen eine gemeinsame Mittagspause zu machen und zu erfahren, was bei ihnen – auch privat – gerade so los ist. Da das aufgrund von Corona aktuell verantwortungslos wäre, haben wir nun den 16 Uhr Kaffeetermin eingeführt. Zu diesem Anlass gibt es einen täglichen, 10-minütigen Kalendereintrag. Jede, die mag, wählt sich dann ins Google Meet ein und bringt ein Getränk mit. Dann trinken wir kurz einen Kaffee (oder was auch immer), besprechen Herausforderungen, Projekte oder auch einfach nur wie es der Katze geht.

https://www.heise.de/hintergrund/Erfolgreich-im-Homeoffice-arbeiten-4681061.html

https://www.businessinsider.de/karriere/arbeitsleben/coronavirus-ein-experte-erklaert-wie-euer-team-trotz-home-office-produktiv-bleibt/

https://coronavirustechhandbook.com/remote

Bei farbenmeer ist die Arbeit aus dem Homeoffice nicht ungewöhnlich. Im Gegenteil: Viele meiner Kolleginnen arbeiten oft und gerne von zu hause. Heute teilen wir mit euch unsere Erfahrungen und Tipps.

Homeoffice – wie gemeinsam Arbeiten getrennt gelingt

Vor über einem Jahr haben wir bei farbenmeer entschieden, dass jede Kollegin und jeder Kollege das eigene Gehalt selbst bestimmen darf. Wie wir nach langen Gedankenspielen zu diesem Entschluss kamen, könnt ihr im vorangegangenen Blogpost lesen. Hier will ich euch über unsere Erfahrungen mit dem Modell berichten, was wir daraus gelernt haben und wie wir in Zukunft damit weiter machen werden.

Eines vorweg: Entgegen aller ökonomischen Prophezeiungen, bei denen ein selbst gewähltes Gehalt ein Unternehmen in kurzer Zeit in die Ruinen treiben sollte - da alle ihr Gehalt auf ein Maximum aufstocken - ist bei uns genau das Gegenteil passiert. Niemand hat das eigene Gehalt verändert. Obwohl sich zuvor viele ein etwas höheres Gehalt gewünscht hatten. Auch die - allen bekannten - Finanzen standen sehr gut, die Auftragsbücher waren voll. Und trotzdem: Niemand entschied sich das Gehalt zu ändern.

Nach ein paar Wochen passierte es dann doch. Ein Kollege verkündete, dass sein Gehalt nun steigen solle. Ein langer und ausgefeilter Text folgte. Er beschrieb, wie lange der Kollege das farbenmeer Team schon begleitet hat, welche Erfolge er erzielte, wie hart manche Durststrecken waren und sogar mit welchen menschlichen Fähigkeiten er unser Team bereichert hat.
Wir waren alle sehr überrascht über diese Ausführlichkeit. Es wirkte wie eine Präsentation vor einem CEO, bei dem harte Fakten vorgelegt werden müssen, damit man überhaupt einen Termin bekommt, geschweige denn einen Termin zur Gehaltserhöhung.
Im Vorfeld war ab diesem Zeitpunkt kein Prozess mehr erdacht worden. Und so versammelten wir uns erst einmal, um zu entscheiden, wie mit dem Gehaltsvortrag umgegangen werden soll. 
Nach ein paar Gedankenspielen kamen wir zu dem Schluss, es sei das Beste, wenn wir jedem die Chance geben Kritik abzugeben. - Wohl gemerkt, Kritik ist immer sowohl negativ als auch positiv! - Man konnte sich entscheiden die Kritik direkt in der Runde zu äußern oder aber im Einzelgespräch zu Wort zu kommen. Jede Person entschied sich für ihre Form.
Später änderten wir diesen Prozess etwas ab. Die Person mit der Gehaltsentscheidung sagte den Anderen bescheid, dass sie nun im Konferenzraum sitzt und gerne die Meinungen der Anderen anhört, falls jemand etwas dazu zu sagen hat. Falls nicht, war dies auch okay und als Zustimmung zu verstehen.

Als dieser Prozess nun vorbei war und alle ihre Meinung abgeben konnten, konnte die Person mit dem neuen Wissen das Gehalt abändern, wenn sie wollte. Dies ist bei der ersten Gehaltsänderung nicht passiert und somit hat die Person entschieden, dass die ab dem nächsten Monat das neu gesetzte Gehalt bekam. Alle Kolleginnen und Kollegen waren sich einig, das Gehalt ist fair und gerechtfertigt. Es gab also sowieso keine Einwände.

Es schien, als haben alle nur auf diesen Moment gewartet. Denn nach dem das erste Gehalt geändert wurde, kam auch der Rest der Kollegschaft und passte ihr Gehalt an. Es gab nun einen Prozess und eine Person, die den Weg schon gegangen ist, an der man sich orientieren konnte. Auch ich selbst habe mein Gehalt erst dann angepasst. Vermutlich hatten wir alle etwas Angst davor die oder der Erste zu sein.
So wurden nach und nach alle Gehälter verändert. 

Einige Kollegen übten sich - wie erwartet - in großer Zurückhaltung. Dies war uns schon im Vorhinein klar, dass es solche Personen geben wird und wir darauf achten müssen, auch diese Menschen zu motivieren ihr Gehalt anzupassen. 

An dieser Stelle sei das Hochstapler-Syndrom angemerkt. Diese Menschen denken ihr Können sei nur eine schimmernde Fassade hinter der nichts steckt. Sie haben Angst, dass eines Tages die Maske fällt und heraus kommt, dass sie alles nur vorgegaukelt haben, nichts können und dafür utopische Gehälter kassieren. Sie denken sie sind Hochstapler - obwohl ihre Fähigkeiten im rationalen Vergleich ganz normal sind. 
Diese Menschen gibt es im IT Bereich wohl häufiger und vor allem bei Frauen in einer immer noch männlich geprägten Domäne, kein Einzelfall. 
Solltet ihr solche Menschen kennen, klärt sie auf, dass es dieses Syndrom gibt. Zu wissen, dass man damit nicht alleine ist, ist eine große Hilfe und ein erster Schritt in die Richtung, damit umzugehen! 

Wir haben unsere übrigen Kolleginnen ermutigen können, ihr Gehalt an denen der Anderen zu orientieren. Sie haben ihr Gehalt ebenfalls nach oben korrigiert, wenn auch manche Texte nicht mehr so ausführlich ausgefallen sind, wie der Erste.

Nein! Denn einen Fall einer sehr verzwickten Situation hatten wir dann doch.

Gegen Ende des Jahres 2019 wurde eine weitere Gehaltsentscheidung vorgebracht. Das Auszubildenengehalt sollte etwas erhöht werden. Der Grund hierfür war der, dass die Person mit dem aktuellen Gehalt noch einen weiteren Job am Wochenende machen musste, um ihre Rechnungen zu bezahlen.

An der Tatsache, dass wir nun nicht von einem "normalen" Gehalt redeten, sondern von einem Ausbildungsgehalt war ein Sonderfall. 

Daran zerrieben sich die Geister. Es gab große Gegner*innen einer Erhöhung, mit den Argumenten dass das Gehalt im Ausbildungsvertrag definiert sei und schon sehr sehr überdurchschnittlich bemessen ist. Außerdem bringe eine Ausbildung mit sich, dass man etwas zurück stecken müsse, da die Firma nicht nur Geld sondern auch viel Anstrengung in die Ausbildung der Person stecke.
Und es gab die Befürworter mit den Argumenten dass der Mindestlohn zwar per Gesetz nicht für die Ausbildung gelte, wir aber jedem Menschen bei uns ein passables Leben ermöglichen wollen. Außerdem stehe farbenmeer nicht für Labels und solle auch nicht dementsprechend vergüten, sondern nach den Bedürfnissen und Fähigkeiten

Die Diskussionen wurden zum Teil sehr emotional und hat sich auf mehrere Meetings ausgebreitet. 
Um das kurz zu erwähnen, natürlich haben beide Seiten mit ihren Argumenten recht. Trotzdem war es furchtbar schwierig einen rationalen Konsens zu finden, bei dem alles mit einfließen konnte. 
Zum Glück meldete sich dann eine Person zu Wort und meinte, warum wir bei dieser Gehaltsentscheidung denn nun auf einmal einen Konsens erwirken wollen, wo wir doch bei allen anderen Entscheidungen nur als Tippgeber fungieren, damit die Person ihre eigene Entscheidung noch einmal aus einem anderen Winkel reflektieren kann. 
Darauf gab es keine Antwort, denn die Person hatte recht. Wir sind durch die emotionalen Diskussionen in eine Situation abgerutscht, in der die Vollzeit-Angestellten über das Gehalt der auszubildenden Person entscheiden wollten. Also waren wir genau in der Situation, die wir eigentlich vermeiden wollten, als wir sagten: Jede/r entscheidet für sich selbst, was auf dem Lohnzettel steht.
Und so lösten wir die Knoten auch auf. Wir beendeten das Meeting kurz darauf und sagten, die auszubildende Person habe nun alle Sichtweisen gehört und solle selbst eine Entscheidung treffen, allerdings erst am darauf folgenden Tag, um die Emotionalität aus der Entscheidung zu nehmen.

Am drauffolgenden Tag wurde dann die Gehaltsentscheidung endgültig getroffen. Die Person entschied sich das Gehalt etwas weniger zu erhöhen, als sie es ursprünglich angedacht hatte.

Weiterentwicklung der Idee - Das Gehaltsgremium

Aus der beschriebenen Konfliktsituation haben wir später eine neue Idee geschaffen. Warum soll sich jede Person mit jeder Gehaltsentscheidung auseinandersetzen? Unter der Annahme eines wachsenden Unternehmens, ist dies irgendwann sowieso nicht mehr machbar und frisst nebenbei Unmengen an Zeit auf. Wir brauchen also eine Instanz, die sich damit beschäftigt, die Wissen hat und im Namen der Anderen mitwirken kann.
Warum also nicht jedes Jahr ein paar Personen via Zufall bestimmen, welche die Finanzlage des Unternehmens kurz wiedergeben und dann kalkulieren kann, welcher durchschnittliche "Orientierungslohn" pro Kopf für die nächsten 12 Monate realistisch wäre. Dieser "Orientierungslohn" dient dabei nur als Hinweis, z.B. um welchen Faktor sich die Möglichkeiten im Vergleich zum Vorjahr geändert haben. 

Und schon war die Idee eines "Gehaltsgremiums" geboren. Das Gremium besteht aus drei zufällig gezogenen Personen. Dabei gibt es jedoch Kriterien. Es muss mindesten ein Mann, eine Frau und eine Person die mindestens schon ein Jahr bei farbenmeer arbeitet im Gremium sein. Realisiert wird dies übrigens mit unserer eigenen kleinen Lotterie. 
Neben den genannten Aufgaben sollen die Kolleginnen und Kollegen ihre Gehaltsänderungen an das Gehaltsgremium geben. Das geschieht ebenfalls einmal im Jahr. Das Gremium prüft dann, ob das neue Gehalt:

im Vergleich zu anderen Personen zu niedrig oder zu hoch ist

Sind die Punkte in Ordnung, wird das Gehalt geändert und die Änderung allen Kolleginnen und Kollegen mitgeteilt. Sollte es einen Konflikt mit den Punkten geben, kann das Gremium einen Gegenvorschlag machen. Wird dieser jedoch abgelehnt, so können beide Parteien entscheiden die Situation zu eskalieren und weitere Kolleginnen und Kollegen hinzuzuziehen. 
Dieses Gremium tagt zum ersten mal in diesem Jahr, also 2020. Es soll helfen Konflikte zu minimieren und allen eine Übersicht des Möglichen zu geben. Dabei kann das Gremium selbst empfehlen ein Gehalt hoch zu setzen, sollte die betroffene Person dies aus Zurückhaltung nicht tun, hat jedoch auch die Möglichkeit eine utopische Summe mit einem Gegenvorschalg auszubremsen und gegebenfalls zu eskalieren, also weitere Teammitglieder zu dieser Entscheidung hinzuzuziehen. Durch die zufällige Auswahl der Mitglieder wird eine Machtkonzentration verhindert. 

Achja und die Gehaltsentscheidungen der einzelnen Mitglieder des Gremiums werden von den anderen beiden Mitgliedern geprüft. Auch hier wird durch das jährlich zufällig gewählte Gremium ein Missbrauch - durch übermäßige Erhöhungen innerhalb des Gremiums - verhindert.

Wie ihr seht ist der Gehaltsprozess immernoch im Wandel. Wir versuchen ihn weiter zu verfeinern und sehen im Gehaltsgremium ein gutes Werkzeug um Extreme abzufangen aber trotzdem allen Kolleginnen und Kollegen die Möglichkeit zu geben selbst zu entscheiden.

Ich bin mir ziemlich sicher, dass ich in einem Jahr auch hierüber unsere Erfahrungen berichten kann und weitere feine Anpassungen vorstellen werde, die wir gemacht haben.

Seit über einem Jahr sind unsere Gehälter selbstbestimmt. Was haben wir in dieser Zeit gelernt?

Wir haben bereits viele Unternehmen bei ihrer digitalen Transformation begleitet. Häufig gehörte dazu die Einführung des Frameworks Scrum. Scrum bricht mit den Regeln des klassischen Projektmanagements und setzt unter anderen auf mehr Flexibilität und Selbstmanagement der Teams. Stets unter der Vorgabe, dass regelmäßig Prozesse, Aufgabenumsetzung und Teamwork unter die Lupe genommen werden: Vom Team selbst und nicht vom Chef.

Eine Möglichkeit, damit stetiges Verbessern gut gelingt – auch wenn ihr nicht in Scrum arbeitet – sind aus unserer Sicht Retrospektiven. Diese unterstützen euch, durch eine klare Struktur und das Einbeziehen der Teammitglieder, das Ziel einer konsequenten Optimierung und eines gut funktionierenden Teams zu erreichen.

In unserem Tagesworkshop stellt unsere Scrum Masterin euch die Etappen einer Retrospektive vor. 

Ihr lernt den Sinn und Zweck der einzelnen Etappen kennen und erfahrt, welche Phasen des Teambuildings es gibt und was diese für eure Moderation bedeuten. Ihr erarbeitet Methodenbausteine und stellt diese den anderen Teilnehmerinnen vor. Im Anschluss machen wir eine Mini-Retrospektive zum Workshop, damit ihr das Format einmal ganz in der Praxis durchgespielt habt. Zum Abschluss erhaltet ihr von uns eine Checkliste und zwei Retrospektiven mit Anleitung zum Mitnehmen.

Ort: unser gemütlicher Workshop-Raum in der alten Rinderschlachthalle am Neuen Kamp 30

Ihr erhaltet: Dokumentation des Workshops, Checkliste zur Vorbereitung einer Retrospektive, 2 Retrospektiven inklusive Anleitung zum Mitnehmen und eine Teilnahmebestätigung

Mindestteilnehmerzahl: 3 Personen; Höchstteilnehmerzahl: 8 Personen

Nächste Termine: 25. März 2020; 22. April 2020; 20. Mai 2020

Euch betreut an dem Tag unsere zertifizierte Scrum Masterin Christiane.

Kontaktiert sie gerne unverbindlich bei Fragen und um herauszufinden, ob der Workshop der richtige für euch ist.

Aufgrund der aktuellen Situation findet der Workshop remote statt. Eine stabile Internetverbindung und ein Computer mit Mikrofon genügen, um daran teilzunehmen.

Viele Unternehmen sind stark durch die aktuelle Krise betroffen. Arbeitnehmerinnen arbeiten von zu hause, aber leiden eventuell unter Leerzeiten. Damit so viele von euch wie möglich diese Zeiten zu produktiven Lehrzeiten umwandeln können, bieten wir den Workshop zum Sonderpreis von 249 € exkl. MwSt. pro Teilnehmerin an.

Ein Grundsatz agiler Methodik lautet: Schau in die Vergangenheit, lerne aus deinen Fehlern und verbessere dich. Genau hier setzen Retrospektiven an. Wie eine Retrospektive gelingt, zeigen wir euch in unserem Workshop "Retrospektiven moderieren".

Workshops bei farbenmeer: Erfolgreiche Retrospektiven

„Evolutionärer Zweck“ statt reinem Gewinnstreben

In vielen Unternehmen werden Ziele vorgegeben. Die Grundidee dahinter ist, dass die Organisation gesteuert und vorangetrieben wird. Laloux stellt jedoch die These auf, dass Organisationen lebende Organismen seien, die eigenständig in eine Richtung streben. Deswegen sei statt starrer Zielvorgaben ein Verständnis über den evolutionären Zweck des Unternehmens wesentlich sinnvoller.

Wir bei farbenmeer leben ganz eindeutig von der Vielfalt und den zahlreichen Ideen unserer Kolleginnen. Natürlich möchten wir auch Geld verdienen. Dabei möchten wir aber immer partnerschaftlich und auf Augenhöhe agieren und unsere Kultur leben und anderen zugänglich machen. Wir setzen uns für Gleichberechtigung ein und jede Mitarbeiterin bringt ihre eigenen Ideen mit ein: Aktuell ist ein Zweck etwa, Teams Werkzeuge an die Hand zu geben, selbstständig offener und besser miteinander arbeiten zu können.

Wir leben in einer komplexen Welt. Das macht Planen und Kontrollieren schwer und fordert von uns, aufmerksam Veränderungen und Möglichkeiten wahrzunehmen und darauf zu reagieren. 

Eine Manifestation dieses Wandels sehen wir bereits in der Softwareentwicklung: Agile Prinzipien zeigen uns, dass Inspizieren, Prüfen und Adaptieren oft besser funktionieren als langfristiges Planen und Kontrollieren. 

Wir bei farbenmeer schauen regelmäßig, wie gut die Zusammenarbeit und unsere Prozesse – intern und extern – funktionieren und wo wir etwas besser machen könnten. So entwickelt sich farbenmeer ständig weiter, wächst und nimmt neue Formen an. 

Selbstführung statt hierarchischer Vorgesetzter

Zahlreiche Organisationen sind heutzutage selbstgeführt. Das heißt, die einzelnen Mitarbeiterinnen arbeiten ohne hierarchische Bindung an einen Vorgesetzten. Laut Laloux mache zunehmende Komplexität das Selbstführungsprinzip notwendig. Während die Mitarbeiterinnen dabei die Möglichkeit haben, Neues anzufangen und zu testen, werden sie von "oben" lediglich geschützt und gefordert.

„Es kommt nicht darauf an, was du gemacht hast, sondern wohin du willst!“, sagte unser Gründer Roman mal zu mir. 

Dabei ging es um die Grundidee, dass Interessen und Fähigkeiten, den Weg zu den Aufgaben leiten – nicht der Lebenslauf und die Anordnung von oben. Wir haben den Raum, Aufgaben selbst zu wählen und umzusetzen. Gerade für mich, jemanden mit klassischer hierarchischer Berufsvergangenheit, ist das äußerst erfrischend. Zudem ist es unglaublich motivierend, wenn die Grenzen deiner Karriere nicht durch deine Studienauswahl, sondern deine Fähigkeiten definiert sind – die durch Hegen und Pflegen dein ganzes Leben wachsen.
Das Entwicklungspotential, dass man dem einzelnen damit zugesteht, ist nahezu unbegrenzt und liegt in der Verantwortung des Individuums. 

Wer sich nicht darum kümmern muss, dass die Maske richtig sitzt, hat mehr Energie – so lautet im Wesentlichen Lalouxs These zum ganzheitlichen Verständnis von Mitarbeiterinnen. In herkömmlichen Unternehmen trägt man laut ihm oft eine Maske. Man sei in einer Rolle und verstecke sein authentisches Ich. Je leichter man es den Mitarbeiterinnen macht, so sein zu können wie sie wirklich sind, desto mehr Zeit, Leidenschaft und Energie haben sie für die täglichen Aufgaben.

Den Mitarbeiterinnen diesen Raum zu schaffen, ist sicherlich nicht leicht. Bei farbenmeer setzen wir das – nach meinem Empfinden – schon gut um. Der Partner ist krank, die Katze hatte einen Unfall, man freut sich auf den Sri Lanka Urlaub: Wir teilen unsere Probleme und Freuden miteinander, wenn uns danach ist. Denn farbenmeer schafft etwa durch eine sehr gezielte Mitarbeiterauswahl, Team-Building-Events und ein hohes Bewusstsein für sensiblen und freundlichen Umgang miteinander die offenen, authentischen Räume. Das ist sicherlich nicht von heute auf morgen machbar, aber auch kleine Schritte helfen. Ein Start könnte z.B. ein Workshop zum Thema gewaltfreie Kommunikation sein.

Willst du mehr über unsere Zusammenarbeit erfahren? Schreib mir einfach und lass uns schnacken!

farbenmeer Gründer Roman hat sein Unternehmen stark an Fréderic Lalouxs Idee der selbstführenden Organisation angelehnt. Um farbenmeer zu verstehen, stellen wir euch deswegen heute Lalouxs Ideen vor und erklären, wie wir sie bei uns umsetzen.

I'm writing this article because I have the feeling that not many people know about this convention even if it exists for years and can lead to a very clear directory structure and file paths instead of a cluttered home directory with thousands of files.

Everyone knows that feeling, you type a ls -la in your home directory, or something similar which lists also hidden files and you get back huge list of files where you have no idea what it is, where it came from and what it does.  The problem is that most programs simply use your home directory as a data storage for any kind of data. That leads to exactly this problem, no one has an overview of their home directory anymore. When I run ls -la | wc -l I get 109 files and/or directories and I even clean it up regularly.

XDG Base Directory Specification to the rescue

The XDG Base Directory Specification is a widely used specification which specifies where your files should be located depending on their usage published by the freedesktop.org-organization. 

freedesktop.org, formerly known as X Desktop Group (XDG), is an organization which has many open source projects including the X Window System, Wayland or systemd.

They published a specification which mainly consists of three important points:

Write user-specific data in $XDG_DATA_HOME

Write configuration files in $XDG_CONFIG_HOME

If these environment variables are not set, the specification says it should go in these directories:

$XDG_DATA_HOME should be $HOME/.local/share

They are also writing about other things like $XDG_RUNTIME_DIR which is used for communication and synchronization, $XDG_CONFIG_DIRS which is used to indicate where configuration files should be searched and $XDG_DATA_DIRS which is used to search for data files. But for me, the main points are the three from above. What you will do is you will read the environment variable, if it is present use this directory or use the fallback, create a directory with your program name in it, it should be relatively unique to not clash with programs of the same name. Save data there.

Read environment variable or use fallback

Create a directory with your program name in this directory

Place your caching/data/configuration files there.

As this is very common among Unix systems and also partly adapted in Windows (at least as far as I know) you really should consider using it. This has the advantage that if you search for configuration files for program x you will look either in your custom set $XDG_CONFIG_HOME/x or in $HOME/.config/x, because you know it will be there. Similarly, you will know where data files (sound files, datasets, save points, ...) or caching files will be located.

So, if you will ever write a tool which needs some configuration files, caching files or data files remember this specification, look it up again and implement a proper way to handling these cases rather than cluttering the $HOME of your users. If don't want to do it yourself you could also use a library for that, there is a library for every major programming language out there.

The full specification can be read here: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

The Power of the XDG Base Directory Specification

In this Blog-post we will use create-react-app to demonstrate how you could use Elm inside and while doing that how to patch your node_modules in a proper,  reusable way by using patch-package.

This gives us a basic react-app with everything out of the box.

Note that we are using react-scripts at version 3.1.1 here, future versions might have different line numbers we are using later on.

Switch into your newly created react-app with cd elm-react-app. We will use elm so that you don't need to install Elm globally on your system. We will also use react-elm-components to use Elm inside our react components.

#!/usr/bin/env bash
yarn add --dev elm && \
yarn add react-elm-components

We now want to initialize the Elm part of our project. Think of it as a package.json for Elm. We can do this by running: ./node_modules/.bin/elm init.

The initializer will ask if you are already familiar with Elm and provides you with a link in case you want to read how you can use Elm. Let's assume we 

Alle Blogartikel

Medizinische Informatik: Gesundheitsvorsorge von morgen

Früh den Markteintritt wagen: Mit dem MVP Zeit & Kosten sparen

Svelte - Hype oder Hoffnung?

The Underestimated Value of Open-Source

Ethik & Digitalisierung - Wo ein Weg ist, ist auch ein Wille?

Homeoffice – wie gemeinsam Arbeiten getrennt gelingt

Faire Löhne - Ein Nachtrag

Workshops bei farbenmeer: Erfolgreiche Retrospektiven

Die Philosophie hinter farbenmeer

The Power of the XDG Base Directory Specification

Using Elm inside create-react-app or: How to properly patch your `node_modules`

Einführung in die Kryptografie

Gute Idee? Teste in nur 5 Tagen, ob sie funktioniert!

Weltfrauentag 2019

Faire Löhne

Next.js + Prismic CMS

Social Media Präsenz

Eine Ode an den Gesprächsmut

Wir freuen uns
euch kennenzulernen!

Alle Blogartikel

Medizinische Informatik: Gesundheitsvorsorge von morgen

Früh den Markteintritt wagen: Mit dem MVP Zeit & Kosten sparen

Svelte - Hype oder Hoffnung?

The Underestimated Value of Open-Source

Ethik & Digitalisierung - Wo ein Weg ist, ist auch ein Wille?

Homeoffice – wie gemeinsam Arbeiten getrennt gelingt

Faire Löhne - Ein Nachtrag

Workshops bei farbenmeer: Erfolgreiche Retrospektiven

Die Philosophie hinter farbenmeer

The Power of the XDG Base Directory Specification

Using Elm inside create-react-app or: How to properly patch your `node_modules`

Einführung in die Kryp­to­grafie

Gute Idee? Teste in nur 5 Tagen, ob sie funktioniert!

Weltfrauentag 2019

Faire Löhne

Next.js + Prismic CMS

Social Media Präsenz

Eine Ode an den Gesprächsmut

Wir freuen unseuch kennenzulernen!

Einführung in die Kryptografie

Wir freuen uns
euch kennenzulernen!