webfactory Neuigkeiten https://www.webfactory.de/assets-version-1502985602/bundles/webfactorywebsite/img/inside-logo.png Logo Webfactory http://www.webfactory.de Zend_Feed_Writer 2 (http://framework.zend.com) https://www.webfactory.de/blog/ © 2017 webfactory GmbH Ubiquitous Language in a non-english domain This is a translation of the original article in German.

As a German company with mostly German clients, this is a situation we encounter every day. Over the past twenty years, we have pursued different approaches to deal with language in our projects, some more successful than others.

The decision for a specific language in the domain model has far-reaching implications and a long life span, so we felt it was crucial to reach consensus within the team and establish a binding regulation.

It is also important to note that this regulation has no automatic consequences for related questions. For example, a decision for German does not mean that we will never employ non-German native speakers in the future. If our conditions change (e.g. different team composition, remote work), we will reopen the discussion.

The obvious question is whether we choose German or English. We quickly noticed that each of us has distinct personal habits and preferences.

Unfortunately, there are no definite rules that allow a clear decision for all use cases. Code, comments, commit messages and documentation are aimed at different audiences which can in turn benefit from different language choices.

The following is a (translated) excerpt from our internal knowledge base and documents our results.

Basics

The choice of language is an important topic in every project: The principle of Ubiquitous Language prescribes the use of an all-encompassing language from technical discussions and analysis with customers to writing code and documentation. Technical terms from the project's business domain should be used literally in the source code.

Building on the rationale behind Ubiquitous Language as a concept, we have coined this ground rule to help us in our discussions:

Our choice of language aims to minimize cognitive load (e.g. translations).

We want to avoid inconsistencies and miscommunication due to translation problems or misunderstandings and, if possible, even make a project glossary unnecessary.

That means that specialized concepts should not have to be "mentally mapped" to structurally different contexts in code, nor should there be translations of technical terms e.g. from German to English.

In our current setup, German is the native language for all team members. It is therefore also the language in which we can best assess linguistic nuances and differences of meaning and choose specific terms. When we express ourselves in English, we may not even notice the inaccuracies or ambiguities that we create for a native speaker.

Language in the code

We keep all terms, particularly in domain-specific parts of the code base, in the language we use to communicate with the customer.

This simple rule could get complicated if the customer is internationally positioned and has several internal languages. We will then take care to agree on English terms for the customer's technical concepts and also use these when we conduct a conversation in German.

It is helpful to consciously make this decision at the beginning of a project and document it in a kind of "charter", as in the end it is less important what language is chosen compared to the fact that there is a conscious and documented decision, which is also "lived" by all parties (customers and developers).

If we write code that we want to release as open source, we generally have an international (specialist) audience. It follows:

Open source code is written completely in English - unless it is aimed at a non-English domain.

Another rule that is derived directly from the principle of Ubiquitous Language is:

Language and terms are used uniformly and consistently in all parts of the code, e.g. PHP, HTML, Javascript, CSS etc.

As an example, it is considered bad practice to create a view template suchergebnis.twig.html and use search-result as class name inside the HTML.

On the other hand, most of the commonly used frameworks, tools, patterns etc. are created or conceived of in English. Because we still want to avoid cognitive load caused by translations, it follows that

Set professional expressions and framework conventions are preserved. Examples are get...() set...() ...Controller ...Factory ...FormType or common usages like click(), toggle(), submit() .

Perhaps one can say that the closer we are to the "infrastructure" layer, the more appropriate the language of English is in the code.

Documentation

For documentation that is intended to be shared with the customer, the same principle applies: We keep it in the language that we speak with the customer.

Language in comments, commit messages, and readme files

Comments, commit messages, readme files, etc. are nothing but postponed ("asynchronous") explanations to colleagues or our future self, which is why they should be written in the language that we would use to talk with the same person if she was sitting right in front of us.

Write a comment exactly how you would say it out loud in a conversation with a colleague.

The difference to the code is that we share terms from the code with the customer, while comments etc. are mostly notes for ourselves. 

Open source projects are, again, treated differently, as the audience is bigger than just our team: Comments, commit messages and all other documentation are written solely in English.

In closing

We are aware that this strong commitment to German might entail future costs of various kinds, if at any point German no longer were to be the intuitive choice of language for our team.

However, we do not think it makes sense to accept very real issues like ambiguous expressions, misunderstandings and translation errors just to avoid theoretical problems in the future.

Also, any non-German native speaker will most likely need to have at least sufficient command of German to be able to understand the key concepts of our German customers' domains - and then this problem is not any "worse" than an English term would be for us today

]]>
Mon, 07 Aug 2017 17:44:10 +0200 https://www.webfactory.de/blog/ubiquitous-language-in-a-non-english-domain https://www.webfactory.de/blog/ubiquitous-language-in-a-non-english-domain webfactory GmbH webfactory GmbH 0
Ubiquitous Language in einer nicht-englischen Fachdomäne: Unsere Herangehensweise This article is also available in English.

Wir haben in den vergangenen 20 Jahren verschiedene Ansätze verfolgt, mit Sprache im Projekt umzugehen. Manche haben sich bewährt, bei anderen sind wir auf Probleme gestoßen.

Da die Entscheidung für eine bestimmte Sprache bei der Begriffswahl im Domänenmodell eine lange Lebensdauer und weitreichende Auswirkungen hat, war es uns wichtig, im Team darüber Konsens herzustellen und eine für alle verbindliche Regelung zu finden.

Dieser Beitrag aus unserem Firmenwiki dokumentiert unsere Besprechungsergebnisse. 

Sprachwahl in Code, Kommentaren, Commits und Dokumentation

Für uns ging es um die Frage, ob wir als Sprache Englisch oder Deutsch wählen. Wie wir schnell gemerkt haben, hat dazu jeder starke persönliche Gewohnheiten und Präferenzen.

Daraus sollen aber keine weitergehenden Festlegungen folgen. So bedeutet eine Entscheidung für Deutsch nicht, dass wir nicht in Zukunft auch nicht-Deutsch-Muttersprachler beschäftigen können. Wenn sich die Rahmenbedingungen ändern (z. B. andere Team-Zusammensetzung, remote teams?) müssen wir das Thema erneut besprechen.

Leider gibt es keine scharfen Regeln, die in allen Fällen eine eindeutige Entscheidung ermöglichen. Wir haben aber gemerkt, dass sich Code, Kommentare, Commit Messages und Dokumentation u. U. an unterschiedliche Zielgruppen richten, was auch zu jeweils unterschiedlichen Entscheidungen führen kann.

Grundsätzliches

Die Sprachwahl ist ein wichtiges Thema: Das Prinzip der "Ubiquitous Language" bedeutet, eine alles durchdringende Sprache zu verwenden, und zwar von der fachlichen Diskussion und Analyse mit dem Kunden bis in den Code. Fachbegriffe der Domäne finden sich wörtlich im Code wieder.

Weder sollten fachliche Konzepte auf anders strukturierte technische Zusammenhänge "mental abgebildet" werden müssen, noch sollte es eine Übersetzung fachlicher Begriffe z. B. vom Deutschen in englische Begriffe geben, die dann im Code stehen.

Als Grundprinzip haben wir formuliert:

Wir wählen die Sprache so, dass wir die Notwendigkeit mentaler Transferleistungen (z. B. Übersetzungen) minimieren. 

Damit beugen wir Missverständnissen vor und reduzieren beispielsweise auch den Bedarf für ein Projekt-Glossar oder -Wörterbuch.

In unserer aktuellen Team-Zusammensetzung ist die Muttersprache für alle Mitarbeiter deutsch. Es ist daher auch die Sprache, in der wir sprachliche Nuancen und Bedeutungsunterschiede am besten beurteilen und Begriffe gezielt wählen können. Wenn wir uns in Englisch ausdrücken, bemerken wir unter Umständen gar nicht, welche Ungenauigkeiten oder Mehrdeutigkeiten wir damit für einen Muttersprachler erzeugen. 

Sprache im Programmcode

Alle Begriffe, insbesondere in Domänen-spezifischen Teilen des Codes, halten wir in der Sprache, die wir auch mit dem Kunden sprechen.

Schwierig könnte es dann sein, wenn der Kunde selbst international aufgestellt ist und evtl. intern mehrere Sprachen nutzt. Dann achten wir darauf, uns mit dem Kunden ggf. auf englische (= internationale?) Begriffe für fachliche Konzepte zu einigen. Diese Begriffe verwenden wir dann auch, wenn wir eine deutsche Unterhaltung führen. 

Es könnte hilfreich sein, diese Entscheidung einmal bewusst zu Beginn eines Projekts in einer Art "Charta" festzuhalten. Es ist dann fast weniger wichtig, welche Sprache festgelegt wird, als dass es überhaupt eine bewusste und dokumentierte Entscheidung gibt und diese auch von allen Beteiligten (Kunden und Entwicklern) gelebt wird.

Wenn wir Code schreiben, den wir quelloffen anbieten, haben wir in der Regel ein internationales (Fach-)Publikum. Dann gilt:

Veröffentlichter open source code nutzt Englisch als Sprache – es sei denn, er ist auf eine nicht-englische Fachdomäne ausgerichtet.

Eine weitere Regel, die direkt aus dem Prinzip der ubiquitous language folgt, ist:

Sprache und Begriffe werden in allen Code-Bereichen, d. h. in PHP, Twig, JavaScript, CSS etc. einheitlich genutzt.

Als Beispiel ist es ist nicht gut, eine View  suchergebnis.html.twig  anzulegen und darin dann die CSS-Klasse  search-result  einzuführen.

Auf der anderen Seite bringen Frameworks, Tools, Patterns etc. Begriffe und Konzepte mit, die typischerweise englisch benannt sind. Weil wir auch hier mentale Transferleistungen vermeiden wollen – nur eben anders herum – gilt:

"Stehende Begriffe" und Konventionen der Frameworks etc. bleiben erhalten. Beispiele sind  get...() set...() ...Controller ...Factory ...FormType  oder übliche Dinge wie  click(), toggle(), submit() .

Vielleicht kann man sagen, dass Englisch als Sprache im Code um so passender ist, je näher wir an der "Infrastruktur"-Schicht sind. 

Dokumentation

Für Dokumentation, die maßgeblich dazu gedacht ist, mit dem Kunden geteilt zu werden, gilt das gleiche Prinzip: Wir halten sie in der Sprache, die wir auch mit dem Kunden sprechen.

Sprache in Kommentaren, Commit Messages und Readme-Dateien

Kommentare, Commit Messages, Readme-Dateien etc. sind im Prinzip zeitlich versetzt vorgetragene Erklärungen an Kollegen oder unser zukünftiges Selbst.

Daher sollten sie um so mehr in der Sprache verfasst sein, die wir mit der entsprechenden Person auch sprechen würden.

Schreibe den Kommentar so, wie du ihn jetzt auch laut deinen Kollegen am Schreibtisch gegenüber vortragen würdest.

Der Unterschied zum Code ist also, dass wir Begriffe aus dem Code mit dem Kunden gemeinsam nutzen, während Kommentare etc. vor allem Notizen für uns selbst sind.

Aber auch hier gilt wieder: In Open Source-Projekten schreiben wir Englisch.

Schlussbemerkung

Uns war bewusst, dass diese starke Festlegung auf Deutsch Kosten verschiedener Art nach sich ziehen kann, wenn es irgendwann nicht mehr die selbstverständliche Sprachwahl unseres Entwicklungsteams sein sollte.

Allerdings macht es keinen Sinn, deshalb jetzt schon mögliche Probleme wie eine unklarere Ausdrucksweise, Bedeutungsverluste bei der Übersetzung etc. einzugehen, um das in Zukunft zu vermeiden.

Außerdem wird vermutlich jeder fremdsprachliche Entwickler zumindest so viel Deutschkenntnisse mitbringen müssen, dass er (oder sie) die Schlüsselbegriffe einer Domäne verstehen kann – und damit ist das Problem nicht "schlimmer", als eine englische Begriffswahl heute für uns wäre.

]]>
Wed, 02 Aug 2017 12:23:16 +0200 https://www.webfactory.de/blog/ubiquitous-language-in-nicht-englischer-domaene https://www.webfactory.de/blog/ubiquitous-language-in-nicht-englischer-domaene webfactory GmbH webfactory GmbH 0
Ein einfaches Formular als Eintrittskarte zur Community Es gehört zu unserer Leidenschaft, Webanwendungen so zu programmieren und zu gestalten, dass sie für User intuitiv bedienbar sind. So dass sie gerne genutzt werden. Ohne dass sich der User verheddert und abbricht.

Ein aktuelles Beispiel dafür findet sich auf der Website EuroPeers.de unseres Kunden JUGEND für Europa. Wir haben dort ein neues Anfrageformular integriert und so das Angebot erweitert.

Die Website

EuroPeers.de ist eine Plattform für junge Menschen, die im EU Programm Erasmus+ JUGEND IN AKTION aktiv waren und ihre Erfahrungen weitergeben möchten. Über 400 Ehemalige sind auf der Website registriert und haben dort ein eigenes Profil angelegt. Ihre Erfahrungen geben sie unter anderem in Schulen weiter. Lehrer können über die Website EuroPeers aus ihrer Region finden, die dann Vorträge oder Workshops vor Ort halten.

Die Problemstellung

Zwar gab es eine Unterseite, auf der alle Profile der Community-Mitglieder aufgelistet wurden. Zusätzlich gab es eine Landkarte, auf der alle EuroPeers mit ihren Wohnorten verzeichnet sind. Wer allerdings als Schulvertreter Kontakt zu ortsnahen EuroPeers aufnehmen wollte, musste sich umständlich durch die Profile klicken und Kontaktdaten händisch herausschreiben.

Eine Alternative bestand darin, bei den Organisatoren direkt anzufragen und um eine Kontaktvermittlung zu einzelnen EuroPeers zu bitten. Dies verursachte jedoch bürokratische Kosten.

Ein weiterer Aspekt: Die Plattform wurde zwar immer attraktiver, je mehr EuroPeers sich angemeldet haben. Gleichzeitig wurde die Suche für externe Interessierte immer unübersichtlicher, weil sie sich durch immer mehr Profile klicken mussten.

Damit ergab sich die Anforderung eine Lösung zu entwickeln, über das Lehrer und andere Interessierte auf einfache Art EuroPeers aus der Region auswählen und anfragen können.

Die Lösung

Für die Suche gibt es jetzt in der rechten Spalte ein erweitertes Formular „EuroPeers finden“. Dort haben wir eine Orts- und Umkreissuche integriert. Wer seinen Ort oder seine Postleitzahl eingibt, erhält automatisch eine Auswahl der EuroPeers aus seiner Region.

 

Bildschirmfoto 2015-11-27 um 10.41.01.png

Anschließend beginnt die Anfrage. Die Profile können per Klick zur Anfrage hinzugefügt werden. Grüne Häkchen geben sofort den Überblick, wen man bereits ausgewählt hat. Das macht Spaß und sieht gut aus.

Über ein Formular wird dann die konkrete Anfrage formuliert. Die Anfrage geht zunächst an eine zentrale Redaktion, um Spam-Nachrichten zu verhindern. Wird sie freigegeben, erhalten die EuroPeers eine Mail.

Hinzu kam eine zweite erweiterte Such- und Anfragemöglichkeit: Über eine Landkarte werden alle EuroPeers angezeigt. Wer auf seine Stadt klickt, erhält die Mitglieder, die sich vor Ort angemeldet haben. Mit einem Klick werden sie jetzt sofort zur Anfrage hinzugefügt.

Lehrern und anderen Interessierten fällt es jetzt deutlich einfacher, nach passenden EuroPeers zu suchen. Das integrierte Anfrageformular ist ihre Eintrittskarte zur Community. Mit wenigen Klicks können Sie schnell Ihre Anfrage stellen.

Unser Fazit

Das Projekt ist ein Beispiel, wie sich Websites kontinuierlich weiterentwickeln lassen. Vorhandene Funktionen und Features werden genutzt und individuell erweitert, anstatt etwas komplett Neues zu entwickeln. Das spart Zeit und Kosten.

Auch die Zusammenarbeit mit unserem Kunden steht exemplarisch für die Art an Problemstellungen heranzugehen. Die Verbindung der existierenden “EuroPeers finden”-Funktion mit dem Anfrageformular war keine Vorgabe des Kunden. Sie hat sich in Gesprächen entwickelt. Es ist ein partnerschaftlicher und agiler Ansatz, der Raum schafft, nach der bestmöglichen Lösung zu suchen.

Das Feedback unseres Kunden

Unser Kunde Andreas Klünter sagt dazu:

Eine sinnvolle Kontaktmöglichkeit für die 200 über Deutschland verteilten EuroPeers hinzubekommen, war eine schwierige Aufgabe. Die Anfragefunktion löst dieses Problem sehr gut und wird regelmäßig genutzt. Auch von den EuroPeers selbst wird die Funktion sehr gut angenommen. Definitiv eine große Verbesserung, die auch zu einer deutlichen Steigerung der Anfragen bei EuroPeers geführt hat.

Dazu passend:

]]>
Fri, 12 May 2017 13:04:13 +0200 https://www.webfactory.de/blog/europeers-anfragefunktion https://www.webfactory.de/blog/europeers-anfragefunktion webfactory GmbH webfactory GmbH 0
Beschlossen und ausgezahlt: Gewinnbonus der webfactory für 2016 Dieses Jahr war es Ende April soweit, und die Entscheidung war vor dem Hintergrund der wirtschaftlichen Lage schnell gefällt: 

  • Die webfactory ist komplett schuldenfrei, es gibt keine Kredite zurückzuzahlen,
  • wir haben in den letzten Jahren bereits ein recht komfortables Finanzpolster für schlechte Zeiten aufgebaut, das uns mehr als ein halbes Jahr Überleben auch ohne Projektumsätze garantiert,
  • die Projekt-Pipeline ist voll, somit ist ein Ausbleiben von Umsätzen nicht zu erwarten,
  • nachdem wir schon bisher nie Dividende an die Anteilseigner ausgezahlt haben, haben Matthias und ich als Gesellschafter dieses Jahr beschlossen, auch grundsätzlich darauf zu verzichten. Da wir als Webagentur kein kapitalintensives Geschäft betreiben und das Stammkapital außerdem in der Firma selbst verdient haben, wäre es aus unserer Sicht nicht fair, darauf eine mehr als symbolische Verzinsung zu zahlen.

Da wir im Januar eine deutliche Gehaltserhöhung beschlossen haben, wollten wir dennoch vorsichtig sein. Es bestand daher schnell Einigkeit im Team über folgende Regel:

  • 50% des Gewinns nach Steuern legen wir zurück und erhöhen damit das Kapital, das für Notfälle zur Verfügung steht,
  • 50% zahlen wir als Bonus an die Mitarbeiter aus,
  • ehemalige Mitarbeiter berücksichtigen wir genau so wie aktuelle.

Für die Verteilung des Bonus sind wir bei der Regelung der Vorjahre geblieben: Der Gesamtbetrag wird anteilig nach den geleisteten Arbeitsstunden verteilt und zwar an alle Mitarbeiter des Unternehmens. 

Das bedeutet:

  • Mitarbeiter, die gleich viel gearbeitet haben, bekommen auch den gleichen Bonus – unabhängig von ihrem Grundgehalt.
  • Das gilt auch für Auszubildende und Aushilfen, z. B. unsere Reinigungskraft.

Wir haben uns vor einigen Jahren für diese Regel entschieden, weil sie

  • leicht operationalisierbar ist (Teilzeit, unterjähriger Ein- oder Austritt brauchen keine Sonderregelungen),
  • bestehende Unterschiede im Grundgehalt nicht weiter verstärkt (im Gegensatz zu einem Bonus, der proportional zum Grundgehalt ist)
  • für Bezieher geringer Einkommen, z. B. Auszubildende und Aushilfen, ein besonderes Dankeschön darstellt.

Im Ergebnis führt diese Regelung für das Jahr 2016 dazu, dass jeder Mitarbeiter eine Größenordnung von 1-1,5 Monatsgehältern als Bonus erhält. Unser Azubi Konstantin kann sich glücklich schätzen und bekommt sogar fast drei Monatsgehälter. Und unsere beiden Ehemaligen Dominik und Sebastian haben unabhängig voneinander einen Fehler in der Abrechnungssoftware vermutet, als sie überraschend eine Gehaltszahlung der webfactory auf ihren Kontoauszügen fanden ;-)

]]>
Mon, 08 May 2017 17:59:16 +0200 https://www.webfactory.de/blog/gewinnbonus-2016 https://www.webfactory.de/blog/gewinnbonus-2016 webfactory GmbH webfactory GmbH 0
Ceci n'est pas une agence "Das Bild hat man so im Kopf: Überstunden, die man vielleicht mal abfeiern darf, wenn man Glück hat. [In der Stellenausschreibung] steht zwar 'Qualität vor Masse und Hetzerei' aber das muss ja nichts heißen. Wenn es genau 40 Stunden sind, dann kann man das meiner Meinung nach so schreiben und wenn es 60 sind dann sollte man es sogar so schreiben :D"

Wir legen seit über fünf Jahren großen Wert darauf, Überstunden soweit wie möglich zu vermeiden. Dies erreichen wir dadurch, dass wir eng mit unseren Kunden im Gespräch sind und in Überlastungssituationen ausloten, welche Projekte wirklich dringend sind und bei welchen die Umsetzung noch etwas warten kann. Die Verzögerungskosten (cost of delay), die unser Kunde erleiden würde, sind dabei das wichtigste Kritierium. Wir vermeiden harte Deadlines, soweit es geht. Natürlich kann man Pressekonferenzen nicht verschieben, aber die wenigsten unserer Projekte werden mit einer Pressekonferenz gelauncht.

Da man als Agentur ja alles mögliche behaupten kann, belegen wir das auch gerne: In der folgenden Grafik seht Ihr die Verteilung der Wochenarbeitsstunden unserer Mitarbeiter im Jahr 2016. Die X-Achse zeigt die Kalenderwochen, auf der Y-Achse ist sind die durchschnittlichen und maximalen Wochenarbeitszeiten unserer Vollzeitmitarbeiter abgetragen. Arbeitszeiten deutlich oberhalb von 40 Stunden kommen wie man sieht extrem selten vor. Durchschnittswerte deutlich unter 40 Stunden sind durch Urlaube und Feiertage bedingt, die in der Auswertung nicht berücksichtigt sind.

In diesem Zusammenhang vielleicht nicht unwichtig: Abweichungen in der Wochenarbeitszeit können natürlich auch dadurch entstehen, dass man freiwillig einige Stunden mehr arbeitet, um in der nächsten Woche mehr Freizeit zu haben.

Nachhaltige Projektdurchführung

Ein weiterer Punkt, der für eine Agentur nicht selbstverständlich ist: Wir legen großen Wert auf langfristige Kundenbeziehungen und wartbare Software. Bei uns gibt es kein "schnell, schnell, hauptsache halbwegs funktional fertig". Wir identifizieren uns mit den Produkten unserer Kunden, entwickeln diese iterativ weiter und achten auf hohe Codequalität. Um Projekte langfristig aktuell halten zu können, investieren wir in Tools wie den Zauberlehrling und das Legacy-Integration-Bundle, die wir grundsätzlich open sourcen.

Investition in Ausbildung

Bei uns bedeutet Ausbildung intensives Mentoring und nicht Ausbeutung billiger Arbeitskräfte. Azubis sind von Tag eins an vollwertige Teammitglieder, die die besondere Unterstützung und Aufmerksamkeit aller ihrer erfahrenen Kollegen genießen. 

Das sind nicht die einzigen Punkte, die uns von anderen Agenturen unterscheiden. So haben wir z. B. Gehaltstransparenz eingeführt, entscheiden gemeinsam über die Verwendung des Jahresgewinns, haben eine sehr offene Fehlerkultur, kochen jeden Mittag reihum, fahren bei voller Kostenübernahme in der Arbeitszeit auf Konferenzen und vieles mehr. Hierüber berichten wir auch in unserem Inside-Blog.

Doch eine Agentur?

Es gibt natürlich nicht nur Dinge, die uns von anderen Agenturen unterscheiden, sondern auch solche, die uns verbinden. Besonders die Abwechslung bei der Arbeit: Wir arbeiten für eine gute Handvoll großer Kunden an unterschiedlichsten Projekten von der klassischen Website bis hin zur internen Bestellanwendung. Das ermöglicht uns, Lösungen, die wir für ein Projekt entwickeln, auch in weiteren eigenen Projekten einzusetzen, zu perfektionieren und zu open sourcen. Aufgrund unserer Größe passiert es nicht, dass man jahrelang nur an dem gleichen Projekt für den gleichen Kunden arbeitet. Und jeder Kunde hat seine eigenen fachlichen Herausforderungen und seine eigene spannende Domäne, die es zu entdecken gilt.

Hier übrigens die Stelle, um die es geht: PHP-Entwickler gesucht.

Mehr über uns

]]>
Sat, 06 May 2017 08:59:34 +0200 https://www.webfactory.de/blog/keine-agentur https://www.webfactory.de/blog/keine-agentur webfactory GmbH webfactory GmbH 0
Suchen: Softwareentwickler. Bieten: tolle Projekte. Heute möchten wir aus diesem Anlass noch mal einen kleinen Einblick geben, welche Projekte bei uns in den nächsten Monaten anstehen. Alle Projekte sind übrigens Symfony-basiert und bei Amazon Web Services gehostet - und werden für die nettesten Kunden der Welt entwickelt. Vielleicht mit dir als Team-Mitglied?

Websites für die Staatsoper Berlin, ein zweites großes Theater – und ein neues webfactory-Produkt

Letztes Frühjahr haben wir der Staatskapelle Berlin mit ihrem Dirigenten Daniel Barenboim nach 450-jährigem Bestehen zu ihrer ersten Website verholfen. Für dieses Projekt haben wir überwältigend positives Feedback bekommen. Nun dürfen wir auch der Staatsoper Berlin rechtzeitig zu ihrem Umzug ins modernisierte Opernhaus unter den Linden ein neues Fundament im Web verschaffen. Parallel dazu hat sich ein weiteres großes 3-Sparten-Theater entschieden, mit uns zusammenzuarbeiten.

Websites für Theater, Opern und Konzerthäuser sind für uns eine sehr interessante Domäne, da sie uns gleichermaßen technisch wie gestalterisch fordern. Hohe Ansprüche an das Design und die Usability auf der einen Seite treffen auf ein facettenreiches Content-Modell (Produktionen, Spielpläne und Spielzeiten, Besetzungen) und viele APIs (zu Ticketplattformen, Content-Brokern, Theater-Planungssoftware)... Kurz: für jeden Geschmack ist etwas dabei.

Natürlich wollen wir das Rad nicht für jedes Theater neu erfinden, sondern entwickeln hierfür ein Produkt in Form mehrerer Bibliotheken, die die Kernanforderungen abdecken und auf die die individuellen Kundenwebsites aufbauen können. Hierfür sehen wir großes Potenzial und freuen uns auf die Herausforderungen, die die Produktentwicklung mit sich bringt.

Extranetsysteme für den Gemeinsamen Bundesausschuss (G-BA)

Von der Kultur ins Herz des Gesundheitswesens: Im Gemeinsamen Bundesausschuss entwickeln Vertreter von Ärzten und Krankenkassen den Leistungskatalog der gesetzlichen Krankenversicherung in Deutschland. Hierfür ist viel Gremienarbeit erforderlich, zu der die Delegierten aus ganz Deutschland in Berlin zusammenkommen. Vorbereitet werden die Gremiensitzungen über ein von uns entwickeltes Extranetsystem. 

Dieses Extranet haben wir im letzten Jahr auf eine verteilte Architektur mit getrennten Instanzen pro Gremium umgestellt, die auf einer einheitlichen Softwarebasis basieren. Im Hintergrund läuft eine zentrale Benutzerverwaltung mit einem Single-Sign-On-System, vorgeschaltet ist eine Portalseite. Die einzelnen Systeme kommunizieren über Web APIs und Amazon SNS/SQS miteinander. Heruntergeladene Dokumente werden über einen Microservice automatisch mit personalisierten Wasserzeichen versehen.

Nachdem der Fokus in den letzten Jahren auf der Umstellung der Gesamtarchitektur lag, wollen wir jetzt für unseren Kunden die Früchte ernten und die Funktionalität des Extranets weiterentwickeln. Auch dieses System hat für uns Produktpotenzial.

Umstellung von www.salto-youth.net auf Microservices

Ein Projekt, über das Malte letztens schon in der Symfony User Group Cologne berichtet hat: Für unseren Kunden JUGEND für Europa betreuen wir die Website salto-youth.net. Derzeit ist das ein noch weitgehend monolithisches großes System, das eine Vielzahl unterschiedlicher Anwendungen unter einem Dach vereint.

Um diese Anwendungen unabhängig voneinander weiterentwickeln zu können, trennen wir sie sukzessive aus dem Monolithen heraus und entwickeln für Querschnittsfunktionen wie Login/Benutzerverwaltung API-basierte Lösungen. Ein gutes Stück des Weges haben wir schon geschafft, aber es warten noch viele spannende Fragen auf Beantwortung.

Anwendung zur Einkaufsunterstützung

Für einen Industriekunden planen wir die Entwicklung einer Webanwendung zur Unterstützung des Einkaufs bei routinemäßigen Ausschreibungen und Preisanfragen bei den Lieferanten. Auch wenn es hier keine außergewöhnlichen technischen Herausforderungen gibt, mögen wir solche Aufgaben, weil sie sehr unmittelbar sichtbaren Business Value haben und die Mitarbeiter unserer Kunden in ihrer täglichen Arbeit enorm entlasten.

Content-Management-System wfDynamic

Unser Content-Management-System wfDynamic erfreut sich bei unseren Kunden (und denen, die wir neu gewinnen) nach wie vor großer Beliebtheit. Der Ansatz, die Content-Pflege technisch getrennt von der Auslieferung des Contents zu halten, hat sich durchgesetzt. Daher sind wir überzeugt, dass wir in die Weiterentwicklung des Systems investieren sollten. Die Umstellung auf einen Symfony-Kernel ist bereits geschafft. Was wfDynamic derzeit fehlt, ist eine "Plug & Play" Anbindung an Messaging-Systeme wie Amazon SNS/SQS. Auch Themen wie eine Versionierung von Inhalten (bei flexiblem Datenmodell) stehen auf der Wunschliste unserer Kunden und warten darauf, begonnen zu werden. 

Über den Tellerrand

Wir haben hier vor allem die Backend-lastigen Projekte beschrieben. Parallel arbeiten wir an eher designorientierten Website-Projekten unter anderem für den Stifterverband der Deutschen Wissenschaft, die Erasmus+-Nationalagentur JUGEND für Europa, den Gemeinsamen Bundesausschuss und eine Münchener Investmentgesellschaft.

Hosting

Wir hosten fast alle unsere Projekte (ca. 50) in einer selbst entworfenen und betriebenen Umgebung bei Amazon Web Services und versuchen, dabei so weit wie möglich Amazon-Dienste statt selbst gepflegter Instanzen einzusetzen - aus unserer Sicht ist AWS eine absolut faszinierende Plattform. Wenn du das genau so siehst und Spaß daran hättest, unser Hosting mit zu betreuen und weiterzuentwickeln: Bewirb dich gerne initiativ, auch wenn Du kein Backend-Entwickler bist.

Wir freuen uns riesig, so viele herausfordernde Aufgaben für tolle Kunden realisieren zu dürfen. Um diese Projekte möglichst schnell, aber auch gut und gründlich und ohne Hetze umsetzen zu können, wünschen wir uns neue Kollegen, und zwar ganz besonders Softwareentwickler (PHP/Symfony).

Außerdem gern gesehen jederzeit Bewerbungen als

Hast du direkt Lust bekommen, anzufangen? Schreib' uns!

Willst du uns bei der Nachwuchssuche unterstützen oder kennst du Leute, denen du einen besonderen Arbeitgeber empfehlen möchtest? Hilf uns, diesen Aufruf zu streuen!

Vielen herzlichen Dank.

Dein webfactory-Team

Mehr zum Arbeiten bei der webfactory

]]>
Fri, 21 Apr 2017 16:57:35 +0200 https://www.webfactory.de/blog/suchen-softwareentwickler-bieten-tolle-projekte https://www.webfactory.de/blog/suchen-softwareentwickler-bieten-tolle-projekte webfactory GmbH webfactory GmbH 0
Spannender Blick über den Tellerrand des Alltags: Jahrestagung für sozialorganische Unternehmensführung Direkt zur Begrüßung fiel mein Blick auf das "Leitbild für ein sozialorganisches Unternehmen", das das Institut entwickelt hat:

"Die sich bewusst selbst entwickelnden und ganzheitlich denkenden und handelnden Mitarbeiter bilden eine Sinn-geführte Arbeitsgemeinschaft, die das Unternehmen evolutionär gemeinsam für ihre Kunden permanent gestalten (sic!)"

Prof. Götz E. Rehn: Die sieben Prinzipien sich selbst führender Unternehmen

Rehn leitet das Institut für Sozialorganik an der Alanus-Hochschule und ist Gründer der Bio-Supermarktkette Alnatura. Er sieht Alnatura als Modellunternehmen, das zeigen soll, dass das "Erfolgsritual des Materialismus" überwindbar und ein "anderes" Wirtschaften möglich ist. Gewinn soll nicht Zweck, sondern Ergebnis eines sinnvollen Handelns sein und der Mensch im Mittelpunkt stehen.

Ist die Welt fertig ohne das Denken? "Nein", sagt Rehn – es hänge vom Denken und Handeln des Menschen ab, in welcher Welt er lebt.

Rehn fragt weiter: "Wie kann man erreichen, dass der Einzelne sich als Individuum einbringen kann und trotzdem das Gemeinschaftsziel erreicht wird? Wie schaffen wir Organisationen, die beseelt sind, in denen die Menschen mit Freude arbeiten?", und postuliert: Wenn Menschen selbst Antworten finden, fühlen sie sich auch verantwortlich

Sozialorganisches Wachstum kann man sich veranschaulichen wie das Wachstum eines biologischen Organismus, also einer Pflanze, die man täglich beim Wachsen beobachten kann. Rehn fasziniert, wie viel Detailentwicklung es jeden Tag gibt. Jeder Wachstumsschritt der Pflanze ist eine Gestaltmetamorphose, d. h. es kommt nicht einfach etwas hinzu, sondern die bereits existierenden Teile der Pflanze verändern sich.

Solche Organismen erreichen ein homöostatisches Gleichgewicht, haben also die Eigenschaft, sich selbst zu heilen und zu erhalten. Dabei gibt es allerdings Grenzen, wenn die externen Veränderungen so groß werden, dass sie den Rahmen der Selbstanpassung überschreiten.

Bei Unternehmen ergibt sich das nicht von alleine.

Er ist überzeugt, dass Unternehmen umso erfolgreicher sind, je mehr es ihnen gelingt, nahe am Kunden zu sein und an dem, was er sucht. Dieses Interesse am Kunden und das Verantwortungsgefühl muss in den Menschen leben, diese müssen es aktivieren – das geht nur auf freiwilliger Basis. Von entscheidender Bedeutung hierfür ist, eine "Angstfreie Zone" zu schaffen.

Rehn stellt anschließend sieben Prinzipien sich selbst führender Unternehmen und ihre Einflussfaktoren vor. 

Sieben Prinzipien sich selbst führender Unternehmen
und ihre Einflussfaktoren

  1. Sinnvolles Gestalten
    setzt Interesse an der Welt voraus.
  2. Ich-Entwicklung
    ermöglicht die Übernahme von Verantwortung
  3. Ganzheitliches Denken
    wird bewirkt durch das Streben nach Erkenntnis
  4. Kundenorientierung
    ergibt sich aus der Liebe zum Kunden
  5. Im Netzwerk agieren
    durch statusfreies Arbeiten
  6. Strukturen formen
    und Entwicklung ermöglichen
  7. Evolution permanent gestalten
    hierbei hilft Freude an Entwicklung.

Einige Anmerkungen von Rehn hierzu:

  • Die Liebe zum Kunden ist gar nicht so einfach – sie ist eine seelische Haltung, die geübt werden muss. Der Kunde spürt aber den Unterschied!
  • Arbeiten im Netzwerk statt in einer Hierarchie benötigt sehr gute, transparente Informationen in Echtzeit (z. B. aus der Wertbildungsrechnung).
  • Konfliktkompetenz muss geübt werden

Folgen aus der Umsetzung der Prinzipien bzw. der Realisierung eines sich selbst führenden Unternehmens:

  • Mehr begeisterte Kunden, die sich mit dem Unternehmen (freiwillig!) verbinden
  • Mehr erfüllte, zufriedene Kollegen
  • Schönere Läden
  • Bessere Wirtschaftlichkeit

Bei Alnatura hat sich 2015 eine erste Filiale aufgrund von externem Stress (extremes Umsatzwachstum von 35%, leere Regale, Kapazitätsprobleme) selbstständig so umorganisiert, dass die Aufgaben der Filialleitung durch das Team selbst wahrgenommen wurden. Prof. Rehn hat auf diese Entwicklung seit der Gründung von Alnatura 1984 "gewartet", sie kann aber nicht aufgezwungen werden.

Entscheidend ist zu jedem Zeitpunkt die Frage "Was ist jetzt wesentlich, zu denken und zu tun?". Eine Entwicklung ist nur Schritt für Schritt möglich, wenn die Zeit für den nächsten Schritt Reif ist.

Rehn schließt seinen Vortrag mit einem Zitat von Albert Einstein:

"Alles wirklich Große und Inspirierende wird von Menschen geschaffen, die in Freiheit arbeiten können."

Dr. Reinhard K. Sprenger

Dr. Sprenger ist ein renommierter Management-Autor, der viele Bestseller zu Wirtschaftsthemen verfasst hat. Seine Aufgabe bei der Tagung sah er als Störer und "Querdenker".

Wie vor ihm bereits Rehn nennt Sprenger den Antroposophen Herbert Witzenmann als Lehrer und Mentor. Seine Leitaussage ist: "Alles, was aus der Wurzel wächst, hat Kraft – alles, was lediglich vom Ziel gezogen wird, bleibt kraftlos.

Sprenger beginnt seinen Vortrag mit der Feststellung, dass er zu jeder Aussage, die er trifft, auch das Gegenteil behaupten könnte, und es ebenso "wahr" ist. Die Erkenntnis, dass wir in einer multipolaren Welt leben, ist aus seiner Sicht essenziell für Führungskräfte: "Führen können Sie nur, wenn Sie davon überzeugt sind, dass es die absolute, eindeutige Wahrheit nicht gibt". 

Für den Erfolg eines Unternehmens spielt der Zufall eine "immens wichtige" Rolle: "Um erfolgreich zu sein, braucht man Glück oder zumindest die Abwesenheit von Pech". 

Auch wenn alle die "Erfolgsrezepte" der bekannten Startups übernehmen und anwenden, scheitert die große Mehrheit der aller Startups. Doch von den 30-40 Unternehmen, die im Silicon Valley täglich scheitern, schreibt keines Bücher.

Generell wird sehr häufig ohne Beweise von Korrelation auf Kausalität geschlossen. 

Ein Beispiel: In einem ganzseitigen Bericht in der NZZ darüber, dass Unternehmen, die mindestens eine Frau im Vorstand haben, deswegen im Schnitt um 9% erfolgreicher seien als Unternehmen ohne Frau im Vorstand. Tatsächlich könnte man aber auch genau die gegenteilige Behauptung aufstellen: Diese Unternehmen sind um 9% erfolgreicher, obwohl eine Frau im Vorstand ist. Es könnte andere Faktoren geben, die sowohl die Frau im Vorstand als auch den Erfolg erklären, und die Kausalität Frauen → Erfolg ist nicht belegt.

Häufig kämen Unternehmen nach Sprengers Überzeugung nicht weiter und sind "stuck", weil sie ihre bisherige Erfolgsgeschichte durch Kausalitäten erklärten und den Faktor Zufall nicht berücksichtigten. Das führt dazu, dass sie sich an vermeintlich bewährte Erfolgsrezepte klammern, obwohl in einer neuen Situation möglicherweise anderes Handeln geboten wäre.

Im Unterschied zu Rehn sieht Sprenger die Arbeitswelt ein ganzes Stück weniger idealistisch, zumindest erweckt er in seinem Vortrag den Eindruck. Sprenger ist überzeugt, dass es bei allem menschlichen Handeln in letzter Konsequenz in ausschließlich um Selbsterhaltung geht, und nicht etwa um Sinn o. ä..

Insofern tut ein Unternehmen gut daran, sich so aufzustellen, dass auch unabhängig von der Sinnfrage die richtigen Anreize zu produktiver Zusammenarbeit bestehen. "Musst du eventuell eine Organisation schaffen, in der sogar Feinde zusammenarbeiten?"

Sprenger fährt fort mit einem kurzen Einstieg in die Systemtheorie. Deren Grundannahme: Die Menschen reagieren auf Verhaltensweisen anderer Menschen, die ihrerseits auf Verhalten anderer reagieren. Das Verhalten ist innerhalb des Systems sinnvoll, außerhalb des Systems sinnlos.

Zwei Beispiele: In einer Kirche ist es sinnvoll, leise oder zu sprechen oder zu schweigen. Verletzt man diese Regel, wird man entsprechende Reaktionen spüren. Auf dem Börsenparkett hingegen muss man laut schreien. Tut man es nicht, wird man in dem System mit Erfolglosigkeit bestraft.

Zur Systemtheorie bringt Sprenger auch ein Beispiel aus seiner Familie: Seine zwei Kinder haben sich, als sie jung waren, häufig "glücklich gezofft" und das beide genossen. Sobald sie aber merkten, dass ihr Vater die Situation beobachtete, sind beide zu ihm gelaufen, haben sich als Opfer dargestellt und dem jeweils anderen Fehlverhalten vorgeworfen.

Die meisten Manager, so Sprenger, seien sich nicht bewusst, dass sie durch ihre bloße Existenz das Verhalten anderer beeinflussen. Sich selbst als Ursache der Phänomene wahrzunehmen, die in der Umwelt stattfinden, ist sehr schwierig.

Systeme sind hierbei so stark, dass das Individuum sich mit abweichendem Verhalten kaum durchsetzen kann.

Sprenger zeichnet ein Schaubild, nach dem Leistung durch die Faktoren Individuum und Institution zustande kommt. Aus Leistung folgt Erfolg.

Die heutzutage dominierende Betrachtungsweise sei, dass es für den Erfolg auf die Individuen ankommt. Auch Misserfolg wird dementsprechend individualisiert. Dabei wird die große Bedeutung des institutionellen Rahmens ignoriert, in dem die Mitarbeiter aktiv sind.

Eine Feststellung am Rande: Aus Mitarbeitersicht repräsentiert die Führungskraft den institutionellen Rahmen.

Entgegen der klassischen Lehre, die das Individuum als den weichen Faktor und die Institution als den harten, schwer veränderbaren Rahmen sieht, postuliert Sprenger das genaue Gegenteil: Das Individuum kann man als Führungskraft nicht verändern, den institutionellen Rahmen, in dem das Individuum seine Talente entfalten oder auch nicht entfalten kann, sehr wohl.

"Menschen widersetzen sich nicht dem Wandel, sondern dagegen, gewandelt zu werden."

Anpassung an ein System ist keinesfalls mit Lernen gleichzusetzen.

Was die Motivation als Leistungsfaktor angeht, "läuft heutzutage eine Ablenkungsdiskussion". Untersucht und beschrieben werden stets die Motivationsfaktoren für den einzelnen Mitarbeiter, hierzu werden auch entsprechende Trainings angeboten. Eine Untersuchung der Demotivationsfaktoren in der Institution würde allerdings viel mehr bringen. "Zynismus als Wachstumsbremse" wäre aus Sicht von Sprenger als Dissertationsthema ein Hit.

Bei Problemen sollte immer erst die Institution betrachtet und ggf. angepasst werden, erst dann das Individuum. Natürlich gibt es auch individuelles Fehlverhalten, aber sehr häufig können Dinge durch Veränderungen in der Organisation verbessert werden.

Führung zu Selbstführung bedeutet erst einmal die Anerkennung des Dilemmas, dass Menschen Veränderung selbst wollen müssen und diese nicht befohlen werden kann.

"Ich gehe davon aus, dass Erziehung nicht funktioniert, weil meine Kinder entscheiden, ob und von wem sie erzogen werden möchten".

Sprenger beklagt: "Wir sind ein Entweder-oder-Land. Nicht mehr oder weniger, nicht sowohl-als-auch, nicht und". Es gibt keine Freiheit ohne Grenzen. Vertrauen ist nicht zu haben ohne Misstrauen (Kontrolle ist notwendig) – es ist aber alles eine Frage des Mehr oder Weniger, nicht des ja oder nein.

Eine zentrale Frage auch für Sprenger: Wie schaffen wir angstfreie Territorien?

Warum gibt es Unternehmen? Weil es Aufgaben gibt, die für den Einzelnen zu groß sind. Zusammenarbeit ist nicht die Addition von Einzelleistungen.

Mit Blick auf den wichtigsten Motivationsfaktor Selbsterhalt stellt Sprenger fest, dass das Bezahlungssystem eines Unternehmens die entscheidende Bedeutung für seine Funktionsweise hat. "Wenn du ein Unternehmen in 10 Minuten kennen lernen möchtest, schau dir sein Bezahlungssystem an".

Hierzu ein Beispiel aus dem Fußball: Ein Spieler erobert im Mittelfeld den Ball, kämpft sich durch die gegnerischen Linien und kommt bis 20 Meter vors Tor. Sein Teamkamerad ist mitgelaufen und hat eine hervorragende Position. Statt zu passen, versucht der Spieler es selbst und schießt über die Latte. Im Nachhinein stellt sich heraus, dass der Trainer nach einer Serie verlorener Spiele eine Torprämie ausgelobt hat.

Was aber ist ein gutes Bezahlungssystem? "Jedes Entlohnungssystem ist eine intellektuelle Sünde". Es kann nicht fair sein, nicht den Einzelfall berücksichtigen etc. Ein erfolgreiches Entlohnungssystem sollte den Arbeitsplatzwert, den Arbeitsmarktwert, die Seniorität des Mitarbeiters und die Leistung in einem langwelligen (wenig volatilen) Festgehalt abbilden und alle variablen Bestandteile am Unternehmenserfolg festmachen - und das sowohl im Positiven als auch im Negativen.

Unsere Vorfahren, die Jäger waren, haben ein Tier in Zusammenarbeit erlegt. Danach dominiert das Individuum und versucht dafür zu sorgen, dass es möglichst wenig von der Beute an die anderen abgeben muss. Hier setzt Moralisierung ein.

Kurzer Exkurs dazu auf Nachfrage eines Zuhörers: Die Ethik ist der Diskurs über (mögliche) Werte. Moral ist das Ergebnis dieses Diskurses. Moralisieren bedeutet, ein Lippenbekenntnis zur Moral abzugeben ohne zu beachten, ob moralisches Handeln in der Situation überhaupt möglich ist.

Die Anthropologie sage, Menschen arbeiten zusammen, wenn sie ein gemeinsames Problem haben (nicht: ein gemeinsames Ziel!). Nur dann sind Egoismus und Hilfe für andere gleichgerichtet. Warum Problem und nicht Ziel? Ziele kann man erreichen (nice to have), Probleme muss man angehen.

Zur Natur der Zusammenarbeit: Kein Mensch "arbeitet in einem großen Unternehmen". Menschen arbeiten in Nachbarschaften von ca. 30-40 Menschen. Diese Nachbarschaften bestimmen die Qualität der Arbeit, nicht das gesamte Unternehmen.

Um eine kollektive Identität aufzubauen, muss man eine Abgrenzung des "Wir" von den "anderen" zulassen. Auf diese Weise können Nachbarschaften und damit gute Zusammenarbeit entstehen.

Um die Auswirkungen, die ein Leitmotto haben kann, zu illustrieren, stellt Springer eine Studie vor: diese hat gezeigt, dass das Gefangenendilemma-Spiel zu anderen Ergebnissen führt, wenn es unter dem Titel "The Wall Street Game" durchgeführt wird, als wenn der Titel "The Community Game" lautet. Sogar Probanden, die von Natur aus eher misstrauisch sind, verhalten sich unter dem Titel "The Community Game" eher kooperativ und vertrauensvoll (Studien-Abstract unter http://psp.sagepub.com/content/30/9/1175.abstract).

Sprenger geht anschließend noch kritisch auf einige Punkte aus dem eingangs zitierten "Leitbild für ein sozialorganisches Unternehmen" ein, zuerst auf den Sinnbegriff:

  • Sinn ist etwas, was das Individuum einer Situation gibt
  • Sinn kann man nicht oktroyieren
  • Es ist auch legitim, wenn ein Mitarbeiter mit dem "Unternehmenssinn" nichts anfangen kann, sondern nur seine Familie ernähren möchte, dann ist das seine Sinnzuschreibung. Ohne individuelle Sinngebung ist kein Überleben möglich. "Wenn seine Handlungen das Gemeinsame stärken, ist mir die Motivationslage egal." Hier ist die Unterscheidung zwischen Denken und Handeln wichtig!
  • Es gibt keine administrative Erzeugung von Sinn

Eine Passung zwischen individuellen und Unternehmenszielen kann erleichtert werden, wenn bei Leistungsbeurteilungen nicht die individuelle Leistung zu Grunde gelegt wird, sondern die Frage gestellt wird "Was hast du getan, um die Gemeinschaft voranzubringen und den Gemeinschaftserfolg zu steigern?"

"Wer anderen nicht dienen kann, versucht, sie zu beherrschen" - besonders gefährlich, wenn ich selbst von etwas begeistert bin; dann neigen Menschen dazu, andere zu "überfahren".

Fremdoptimierung ist für Führungskräfte, die im Unternehmensinteresse handeln wollen, wichtiger als Selbstoptimierung: "Wie kann ich die Andersartigkeit des Mitarbeiters zum Erfolg des Unternehmens einsetzen?".

Wichtig ist bei all dem die Fähigkeit, nach Konflikten wieder Anschluss zu suchen.

Sprenger betont, dass es ihm schwer fällt, sich an etwas Positivem zu orientieren. Seine Management-Maxime lautet, möglichst viel Schaden zu verhindern: "Ich komme auf dem Weg zum Positiven weiter, wenn ich auf das Verhindernde schaue." Es muss alles weggeräumt werden, was "Kundenverhinderungsenergie" erzeugt. Denn als Unternehmen hat man ausschließlich eine Existenzberechtigung durch den Kundennutzen, den man erzeugt.

Orga-Scrabble

Nach den beiden Vorträgen und einem Mittagessen findet eine von Liven Quell und Till Stauffer vom "Institut für angewandte Zukunft" vorbereitete "Kunsterfahrung" statt: Ein Organisations-Scrabble, bei dem alle 180 Teilnehmer einen Buchstaben ziehen und innerhalb von 30 Minuten alle Buchstaben zu einem großen Kreuzwort-Bild zusammensetzen sollen. Es ist faszinierend zu sehen, welche unterschiedlichen Herangehensweisen es gibt und welche Rollen sich herausbilden. Z. B. bemerkt der "Buchstaben-Broker" fehlende Buchstaben für Worte bemerkt und findet Menschen, die den passenden Buchstaben haben). Andere halten ihren Buchstaben hoch und warten, bis jemand sie findet. Wieder andere bilden die Ideen für Worte und suchen aktiv die Menschen, die passende Buchstaben haben. Insgesamt eine sehr spannende Erfahrung, und in unserem Fall löste die Gruppe die Aufgabe vollständig schon nach der Hälfte der Zeit; kein einziger Buchstabe blieb übrig.

Workshops

Im Anschluss gibt es 5 parallele Workshops zur Vertiefung einzelner Themen, die ich aber nicht mitgeschrieben habe:

  • Ganzheitliche Menschen- und Weltsicht als Führungsaufgabe - Matthias Gasche (Heiligenfeld Kliniken)
  • Sinn für Sinnhaftigkeit – Paradigmenwechsel in der Sinnfrage - Gerhard Heid & Oliver Groß (Sonett GmbH)
  • Herausforderung der (Selbst-)Führungskultur - Henning Wolf & Nadine Wolf (it-agile GmbH)
  • Gemeinsamkeit leben - Paul Habbel (Gutmann Aluminium Draht GmbH) & Andreas Terhoeven (Holistischer Organisationsberater)
  • Sozialorganische Entwicklung am Beispiel eines Alnatura Super Natur Marktes - Prof. Dr. Götz E. Rehn & Nicole Tritschler (Alnatura GmbH)
]]>
Thu, 20 Apr 2017 18:24:44 +0200 https://www.webfactory.de/blog/jahrestagung-2016-institut-fuer-sozialorganik https://www.webfactory.de/blog/jahrestagung-2016-institut-fuer-sozialorganik webfactory GmbH webfactory GmbH 0
Bericht zur Beyond Tellerrand 2016 in Düsseldorf Nein, ich brauchte kein Visum, um nach Düsseldorf zu fahren. War tatsächlich ganz einfach da hin zu kommen, in die "verbotene Stadt", aber ob ein bönnsches/kölsches Herz das unbedingt möchte, sei mal dahingestellt...
Auf nach Düsseldorf also. Am 9. und 10. Mai 2016 fand die Beyond Tellerrand statt.

Nachdem ich letztes Jahr im November in Berlin war und positiv berichtete, hatten wir die Tickets für Düsseldorf schon gekauft, als noch so gut wie gar keine Speaker feststanden... Ich kannte bisher keinen der Namen der Speaker, die dann announced wurden, abgesehen von Val Head und Jeremy Keith, den ich sehr gerne zu meinen Freunden zähle :).

Die Location war super erreichbar und davor gab es viel Platz, um die Sonne zu genießen. In der Location selbst gab es mehrere Bars und man konnte sogar MarioKart spielen, was Stefan und ich uns nicht haben nehmen lassen. Dome und meinen alter Ausbilder Søren hat man natürlich am Kicker gefunden.

13 Talks auf zwei Tage verteilt ist angenehm. Da hat man abends noch genug Energie, um nach Hause zu fahren oder sich für den Tag mit einem, zwei oder mehr Bierchen zu belohnen. Gerne auch mit Jeremy Keith, Christian Heilmann, der diesmal für Microsoft da war, und ein paar Mitarbeitern der Konferenz.

Manche Talks waren ziemlich js-lastig, weshalb ich (mit meinen Anfänger jQuery skills) nichts verstand, andere habe ich leider grundsätzlich nicht verstanden. Manchmal sitzt man in einem Talk und weiß gar nicht so recht, was man denn jetzt daraus mitnehmen soll. Sachen gibts...

Nach jedem Talk hat der grandiose Baldower wieder seine Live-Mixes rausgehauen. In Berlin 2015 habe ich ihn das erste Mal gesehen und war fasziniert von diesem Mann. Ihn diesmal wieder zu sehen und zu hören war ein Fest!

 

Vier Talks habe ich mir rausgepickt.

Vier richtig gute, wie ich finde. Ich hatte mir vorgenommen, die Talks, die ich gut fand, als Poster zu designen. Ich war mir anfangs unsicher, ob ich das auch hinbekomme, da ich nie Poster oder typografische Gestaltung gemacht hatte. Resilience war das Erste. Als ich es auf Twitter veröffentlichte, fand Jeremy Keith es so schön, dass er es retweetete. Dadurch ist mein Twitter binnen kürzester Zeit buchstäblich explodiert! Fast 30.000 Leute haben dieses Poster gesehen und ich habe eine Menge positives Feedback bekommen, auch von einigen guten Speakern, die man so kennt. Von da an war ich mir sicher, dass die Idee mit den Postern eine ziemlich gute war :)

"Time + Creativity" by  Christopher Murphy @fehler

Christopher Murphy, der Kopf hinter tinybooks.com, ist Author, Designer und Lehrer für Ineraction Design.
Sein Talk "Time + Creativity" ging um Zeit. Die Zeit zwischen dem Briefing und wann wir tatsächlich anfangen zu arbeiten. Die Zeit, die Designer rumdoodlen zum Ideen entwickeln und Webdevs unerwartete Bugs fixen. Zeit, die auf erstem Blick, verschwendet wird also. Die typische Fuckoff Phase. Jeder kennt die Memes dazu.

Was Christoper Murphy in seinem Talk sagte war: Die Verzögerung, die Fuckoff Phase, ist gut! Gut, sofern man die Zeit effizient nutzt. Effizientes Zeitverschwenden also, oder: Yak Shaving. In dieser Zeit sollte man seine Fähigkeiten erweitern, sich von dem was kommt leiten lassen und draus lernen. Ideen, die man schon hatte neu kombinieren, denn Ideen sind nichts weiter als eine neue Kombination von alten Elementen. Das sagte schon Vilfredo Pareto. Magic ist das Zauberwort, wenn Dinge unerwartet aufeinandertreffen.

"Advice from a young designer to younger designers" by Lil Chen @lil_chen

Lil Chen ist noch recht jung, Interaction Designer für ein Youtube Gaming Team und zockt auch selbst Games. Davor war sie Designer für TED.

Ihr Talk "Advice from a young designer to younger designers" war eine Motivationsbombe für junge Menschen, die sich in der Designbranche etablieren wollen. Selbst wenn man schon lange Designer ist, tat es gut, all das noch mal zu hören.

10 Ratschläge umfasste ihr Talk.

  1. Lerne mit nicht-Designern über Design zu reden.
  2. Teile anderen mit, was du kannst.
  3. Benutze deine Stimme, sag was du denkst.
  4. Bestimme deine Zukunft, indem du handelst.
  5. Zeige anderen, wie du arbeitest.
  6. Lege keinen Wert auf Pixelperfektion, 5 grobe Ideen sind besser als eine Perfekte.
  7. Verstehe die Prozesse deiner Kollegen.
  8. Sei ein Advokat für deine Designs.
  9. Arbeite an persönlichen Projekten.
  10. Nehme Kritik an. Aber vertrete auch deinen Standpunkt.

"Designing meaningful animation" by Val Head @vlh

Val Head ist Designer und Web-Animation Berater, macht Motion Design Workshops und schrieb u.a. The Pocket Guide to CSS Animations.

Ihr Talk "Designing meaningful animation" beinhaltete drei Prinzipien: Timing & Spacing, Follow Through und Secondary Actions. Warum eine Animation implementieren? Wie animiere ich? Wie animiere ich mehrere Elemente gleichzeitig? Wie verläuft eine Animation? Was passiert während oder nach der Animation?

Animationen sollten subtil sein und den Gesetzen der Physik folgen. Sie ermöglichen Emotionen und Stimmungen. Mehrere Elemente können gleichzeitig animiert werden, sollten aber insgesamt stimmig sein. Dabei ist drauf zu achten, dass Elemente, die unterschiedlich starten, auch unterschiedlich stoppen. Animierte Elemente dürfen die Zielposition vor Ende der Animation überschießen.
Alles, was während oder nach der primären Animation passiert, nennt man Secondary Action. Die Secondary Action bestärkt die ursprüngliche Animation. Bestes Beispiel dafür ist das Like-Heart von Twitter.

Val hat uns auch einige Pro-Tips gegeben:

  1. Cubic-Bezier macht eine Animation zwar zahlenmäßig unübersichtlicher, aber das Endergebnis ist schöner.
  2. Muss man eine Animation inspizieren, kann sie in den Browser Dev-Tools verlangsamt und verändert werden.
  3. Der ultimative Pro-Tip: Animationen austanzen! Ganz recht, austanzen. Muss man jemandem eine Animation erklären, hilft es sehr, wenn man die Fähigkeiten der Gestik einsetzt. Bei komplizierteren Animationen kann es zwar schnell zu einem Full-Body-Workout werden, aber wenn Val Head das auf der Bühne schafft, schaffen wir das auch im Office ;).

"Resilience" by Jeremy Keith @adactio

Jeremy Keith, mein Lieblings-Talk-Mensch, ist Web Developer bei clearleft in Brighton, schrieb u.a. HTML5 For Web Designers, ist Blogger und spielt in einer Band.

Sein Talk "Resilience" war, wie immer eigentlich, ein großartiger Talk. Resilience, die Ausfallsicherheit, handelte um die Robustheit von HTML & CSS, die Fragilität von JavaScript und die Art und Weise, wie wir robuste Websites bauen sollten.

Drei Schritte stellte er vor:

  1. Hauptfunktionalität identifizieren. Hierbei gibt es kein “zu leicht” oder “zu schwer”.
  2. Diese Funktionalität mit der simpelsten Technologie verfügbar machen. Kein fancy JavaScript, nur mit HTML & CSS.
  3. Erweitern. Jetzt erst kommt JavaScript. Auch Layout sollte in manchen Fällen als Enhancement angesehen werden.

JavaScript ist fragil und kurzlebig. Oft ändert sich etwas. Oft werden winzige Fehler produziert, die die komplette Website crashen. Ein fehlendes Semikolon zum Beispiel stoppt das Parsing. HTML & CSS wurden über die Jahre erweitert, aber nie verändert. Ein kleiner Fehler im HTML & CSS stoppt das Parsing nicht. Es wird ignoriert. Das mag in bestimmter Sichtweise auch keine gute Idee sein, aber Robustheit betreffend ist diese Herangehensweise besser. Zu häufig werden Elemente auf Webistes mit kompliziertem JavaScript gebaut, wo simples HTML und CSS reichen würde. Wieso einfach, wenn es auch kompliziert geht? Falsch.

Jeremy stellte klar, dass die Bedürfnisse des Users viel höher gestellt sind als Gewohnheiten der Developer. Probleme sind unsere Probleme, nicht die der User! Das ist unser Job als Developer und das dürfen wir nicht vergessen.

Oft stehen wir vor vermeintlichen Problemen und sagen “dass ist nicht machbar”. Es ist machbar. Wir sehen es nur vor lauter komplizierten Technologien nicht mehr, weil es eigentlich ganz einfach ist. Man sieht den Wald vor lauter Bäumen nicht. Verdeutlicht wird das gut durch das kleine Pony im Apple Store. Das Web ist das kleine Pony im Apple Store.

Zum Ende sagt er noch: “Leave behind a web that lasts. A web that is persistent.” Ein Web, was überdauert. JavaScript kann sich bald schon wieder ändern und Websites crashen. HTML & CSS wird immer HTML & CSS bleiben. Daher ist es besser, sich auf eine Technologie zu verlassen, bei der man sicher sein kann, dass sie auch Jahre später noch funktionieren wird.

 

Zwei wunderbare Tage

Ich gehe sehr gerne zu Konferenzen, weil man so viele nette Menschen kennenlernt und einfach Spaß hat, obwohl man lernt und aufpassen und Notizen machen muss. Die meisten Talks (wie die vier die ich vorgestellt habe) sind einfach super gut. Und da tut es ganz und gar nicht weh, dass ich die Talks von Val und Jeremy schon in Oxford auf der Render gesehen hatte.
Ich freue mich immer besonders auf Jeremy und Christian. Zwei sehr liebe und angenehme Menschen, mit denen man sehr gern auf ein Bier absackt und lange, lange quatscht. Ich habe mich auch sehr darüber gefreut, Søren, meinen alten Ausbilder, dort zu treffen.
Die zwei Tage in Düsseldorf waren wunderbar und wenn ich kann bin ich nächstes Jahr auf jeden Fall wieder dabei!

Und sonst?

Essen kann man in Düsseldorf auch. Wer auf japanische Nudelsuppen, oder generell auf japanisches Essen steht, ist in Düsseldorf sehr gut aufgehoben. In Düsseldorf verbirgt sich nämlich mit über 6500 Japanern die einzige Japantown Deutschlands. Dementsprechend gibt es massig japanische Restaurants.
Ein sehr sehr Gutes (wenn nicht sogar das Beste) ist das Takumi 2nd Tonkotsu. Ein absolutes Muss für jeden Suppen-Fan! Ich empfehle die Tonkotsu Ramen, die beste Nudelsuppe, die ich jemals gegessen habe.

 

 

 

 

 

 

 

Links

Alle Talks auf Vimeo
https://vimeo.com/channels/beyondtellerrand/

Notes von Talks
http://www.sketchnotesbook.com/blog/2016/5/11/speaking-at-leandus-and-sketching-at-beyond-tellerrand-2016

]]>
Fri, 10 Jun 2016 14:24:46 +0200 https://www.webfactory.de/blog/bericht-zur-beyond-tellerrand-2016-duesseldorf https://www.webfactory.de/blog/bericht-zur-beyond-tellerrand-2016-duesseldorf webfactory GmbH webfactory GmbH 0
Kurzbericht zur SymfonyLive Cologne 2016 Die Konferenz wurde im KOMED im Kölner Mediapark veranstaltet. Mit rund 300 Teilnehmern hatte das Event eine für mein Empfinden angenehme Größe: Der Saal war gut gefüllt, trotzdem war es fast ein bisschen familiär. Das lag natürlich mit daran, dass das Event für uns praktisch vor der Haustür stattfand und wir viele bekannte Gesichter aus anderen Bonner und Kölner Agenturen, Softwarefirmen und nicht zuletzt der Symfony User Group Köln treffen konnten.

Es gab einen einzigen Track mit Vorträgen, was – positiv gesehen – die Entscheidung zwischen konkurrierenden Talks erspart. Aber nach 10 Vorträgen in 10 Stunden war ich abends spürbar erschöpft.

Hier also meine Kurzzusammenfassung der einzelnen Vorträge. Folien gibt es erst zum Teil online, sie lassen sich sicher in Kürze googlen. Ich gehe auch davon aus, dass es in einiger Zeit wieder die Videomitschnitte frei im Netz geben wird.

In seiner Keynote "Superhelden im Porzellanladen" zeigt Christian Schäfer, nach welchen Kriterien Entwickler auf Jobsuche Unternehmen beurteilen können. Daraus lassen sich interessante Rückschlüsse ziehen, welche Erwartungen im Hinblick auf Gehalt, Sicherheit, Spaß und Herausforderungen angemessen sind. Interessantes Takeaway: Das Unternehmen-Wachstumsmodell nach Greiner.

Bernhard Schussek, Lead-Entwickler der Symfony Form-Component, gibt in seinem Vortrag "Symfony Forms: Do's and Don'ts" zunächst einen Überblick über die wesentlichen Neuerungen und Umstellungen ab Symfony 2.7. Viele der Änderungen zielen dabei darauf ab, die mit Symfony im Backend erzeugten Formulare einfacher von JavaScript aus weiterverwenden zu können. Die zweite Hälfte brachte dann eine Reihe von Tipps und Empfehlungen, wie die verschiedenen Aspekte von Formularen (Validierung, HTML-Labels, …) zwischen Controller-Code und Views aufgeteilt werden können und wie sich die Form Component mit komplexeren Modell-Klassen zusammenbringen lässt, die z. B. nach dem Domain Driven Design-Paradigma entwickelt wurden.

"Maßgeschneiderte Testdaten mit Faker und Alice" von Philipp Rieber zeigt, wie einfach Faker "echt" aussehende Testdaten beispielsweise zur anfänglichen Befüllung von Demo-Datenbanken erzeugen kann. Mit Alice wird es einfach, solche Daten in YAML-Dateien zu beschreiben und dann mit Doctrine in Datenbanken zu laden. Ein interessanter Überblick, wenn man Faker und Alice noch nicht kennt – die Inhalte kann man sich dann aber auch schnell aus der Dokumentation aneignen.

Benjamin Eberlei stellt in "Go lernen für einen Symfony Websocket Proxy" zunächst die Vor- und Nachteile der "shared-nothing"-Architektur von PHP gegenüber. Für den Anwendungsfall asynchroner oder lange laufender Kommunikation begründet er damit dann, warum sich der Einsatz von anderen Sprachen wie Go oder Node.js besser eignet. Es folgt ein Go-Crash-Kurs, in dem ein kleiner Websocket-Proxy entsteht. Dieser erlaubt es, von einer Symfony-Anwendung aus Push-Nachrichten an eine große Anzahl gleichzeitig aktiver Websocket-Clients zu schicken. Auf jeden Fall eine technisch interessante Idee!

Kore Nordmann zeigt in "Wie wir Code analysieren" den Quality Analyzer, der bei Code Reviews Hinweise auf kritische Codestellen geben soll. Er verarbeitet dazu unter anderem die Metriken anderer Tools und versucht daraus abzuleiten, welche Stellen bei Änderungen potenziell Auswirkungen auf andere Teile der Anwendung haben. Am wichtigsten war mir persönlich eine Bemerkung von Kore im Rahmen des Fazits: Jede Zeile Code, sei sie auch noch so schlecht, ist nicht mit der Absicht entstanden, den heutigen Entwicklern das Leben schwer zu machen – sondern als Ergebnis der damaligen Situation mit eventuell hohem Zeitdruck, unzureichendem Können, anderen Anforderungen und ähnlichem. Eine Einsicht, die leider oft fehlt.

In "Modernisieren mit Symfony" von Alexander Turek ging es um eine Möglichkeit, wie sich alte PHP-Anwendungen mit Symfony verbinden lassen, um so eine schrittweise Migration zu ermöglichen. Die Ansätze waren altvertraut, wir haben selbst schon darüber berichtet.

Christoph Reinartz berichtet in "Pattern Library meets Symfony", wie das Team bei trivago eine Pattern Library entwickelt hat und welche Ansätze es gibt, um diese Komponenten allen Entwicklungsteams zur Verfügung zu stellen. Ein unterhaltsamer und humorvoller Vortrag, der viele spontane Lacher und Applaus bekommen hat. Leider gab es aber wenig Aufschluss darüber, wie genau das Ganze jetzt funktioniert und mit welchen Tools das Projektteam dabei gearbeitet hat.

Christian Flothmann gab in "FOSRest 2.0" einen Überblick über die Möglichkeiten und Neuerungen des FOSRestBundle 2.0. Ein Blick in das Changelog dürfte die Inhalte gut zusammenfassen.

Jan van Thoor erzählte in "Open Heart Surgery (In Production)" eine Reihe unterhaltsamer "war stories": Wie lässt sich eine geschäftskritische, gewachsene Anwendung, die noch dazu einer hohen Änderungsrate unterworfen ist, schrittweise aufräumen, entkoppeln und mit Tests untermauern? Das Ganze war mit vielen Codebeispielen aus der echten Codebasis von trivago.de unterlegt. Ich persönlich war überrascht, wie schlimm solche großen Systeme unter der Haube wirklich aussehen können.

Marco Pivetta, der aktuelle Release Manager des Doctrine Projects, gab in "Doctrine ORM Good Practices and Tricks" viele wertvolle Denkanstöße für objektorientiertes Design (OOD) im Allgemeinen und über das Doctrine ORM hinaus. Es ist schön zu sehen, dass viele Ideen des Domain Driven Design langsam in der PHP-Welt ankommen und es inzwischen einige renommierte Speaker gibt, die auf hohem Level über OOD sprechen können. Dieser Talk (und übrigens auch andere Vorträge von Marco wie dieser) ist definitiv die Zeit wert, setzt aber auch schon etwas Entwicklungserfahrung voraus.

]]>
Fri, 29 Apr 2016 10:41:30 +0200 https://www.webfactory.de/blog/notizen-symfony-live-cologne-april-2016 https://www.webfactory.de/blog/notizen-symfony-live-cologne-april-2016 webfactory GmbH webfactory GmbH 0
Warum wir (und unsere Kunden) uns nicht vor dem Erpressungs-Trojaner CTB-Locker fürchten Der genaue Weg, über den die Schadsoftware die Server befällt, ist noch nicht bekannt. Daher können wir nicht 100% sicher sein, sicher zu sein. Das ist aber kein Grund zur Besorgnis, sondern der Normalzustand in der IT.

Bezüglich CTB-Locker sehen wir keine konkrete Gefahr. Denn:

1. CTB-Locker ist auf Masse ausgerichtet. Diese Schadsoftware nutzt bekannte Sicherheitslücken in weit verbreiteter Software aus. Im heise-Artikel werden Wordpress und Joomla genannt, die schon in der Vergangenheit beliebte Angriffsziele waren. Beide (und vergleichbare Programme) haben wir auf unseren Servern nicht installiert.

Unsere Webseiten und Webanwendungen sind individuell programmierte Software. Sie werden eigene Sicherheitslücken haben, aber eben keine allgemein bekannten. Daher dürfte es für die Erpresser nicht lohnenswert erscheinen, diese heraus zu finden und gezielt dafür einen Schädling zu programmieren.

2. Um effizient zu arbeiten und robuste Lösungen zu schaffen, entwickeln aber auch wir nicht jede Komponente unserer Webanwendungen neu. Beispielsweise lieben wir das Symfony-Framework und setzen Symfony in den allermeisten Projekten ein. Symfony ist weit verbreitet - und wenn darin ein Fehler bekannt wird, könnte es theoretisch auch Ziel von Schadsoftware wie dem CTB-Locker werden.

Deshalb informieren wir uns täglich über die Sicherheitslage in der IT-Welt und haben dabei ein besonderes Augenmerk auf die von uns eingesetzte Software. So können wir rechtzeitig handeln, unsere Systeme absichern und ggf. mit betroffenen Kunden Kontakt aufnehmen. 

Generell empfehlen wir unseren Kunden regelmäßige Updates der wichtigen Komponenten. Bei aktuellen Aufträgen erledigen wir das auch gerne nebenher.

3. Da der konkret Angriffsweg des CTB-Lockers noch unbekannt ist, können wir zwar nicht konkret dazu Stellung nehmen. Aber wir können allgemein fest halten, dass wir unsere Server in der Amazon Cloud und damit in einem vernünftigen Sicherheitsrahmen hosten lassen. Die fachmännische Konfiguration unserer Server ergänzt dann den Schutz unserer Lösungen.

4. Selbst wenn so ein Schädling einmal in einen Server eindringen und dort wüten sollte - haben wir von allen wichtigen Dateien Backups, auf die der Schädling keinen Zugriff hat.

  • Code speichern wir in einem komplett getrennten Repository-System, der dann während der Installation/eines Updates auf den jeweiligen Webserver kopiert wird.
  • Für Datenbanken haben wir tagesaktuelle Backups, die auch mehrere Tage zurück reichen. Diese Backups werden nach ihrer Erstellung vom Server getrennt und sind für einen etwaigen Schädling nicht erreichbar.
  • Binär-Dateien (wie z.B. Bilder und PDFs) speichern wir vorzugsweise in Amazons S3-System, das wiederum getrennt ist, so dass ein Schädling ebenfalls keinen Zugang dazu hätte.

Die Prozedur, Daten aus Backups wiederherzustellen, führen wir alle etwa alle 2-3 Monate aus, wenn ein Kunde versehentlich seine Daten gelöscht hat und sie weiderhergestellt haben möchte. Daher haben wir darin eine gewisse Routine darin und können unsere Schritt-für-Schritt-Anleitung dafür aktuell halten. Eine solche Anleitung ist wichtig, damit man in einer solchen Stress-Situation nichts mehr falsch machen und die Daten schnellstmöglich wiederherstellen kann.

Insofern – bleiben wir wachsam, sehen aber keine aktuelle Gefahr durch CTB-Locker. Und selbst wenn er oder ein anderer Schädling es einmal schaffen sollte, in unsere Server einzudringen und dort wichtige Dateien zu verschlüsseln oder löschen - sind wir auch darauf vorbereitet. Helms Klamm hatte ja auch nicht nur eine Mauer.

 

]]>
Fri, 26 Feb 2016 12:37:04 +0100 https://www.webfactory.de/blog/warum-wir-und-unsere-kunden-uns-nicht-vor-dem-erpressungs-trojaner-ctb-locker-fuerchten https://www.webfactory.de/blog/warum-wir-und-unsere-kunden-uns-nicht-vor-dem-erpressungs-trojaner-ctb-locker-fuerchten webfactory GmbH webfactory GmbH 0