Goulasz

Hallo Welt!
Nach einer längeren Zeit der Beitragsflaute mal wieder ein neuer Post. Dafür gibt es dieses mal auch etwas mehr und wieder einen Veranstaltungsbericht. Dieses mal jedoch nicht von einer Konferenz, sondern von einem Seminar mit anschließender Prüfung zur Zertifizierung.
Vom 05.07.2016 bis zum 07.07.2016 bin ich mit einem Kollegen in Köln auf einer prüfungsvorbereitenden Schulung zum Thema "Usability Engineering and User Experience" gewesen und habe dort einiges an Wissen erworben, das ich gerne auszugsweise(da sonst jeglichen Rahmen sprengend) mit euch teilen möchte.
Innovative Software braucht doch keine Kreativität "UX aus der Dose"
Im April 2016 habe ich mit zwei Kollegen die "OBJEKTspektrum information days" in Frankfurt am Main besucht und dort einen extrem interessanten Vortrag von einem mir recht sympathischen Sprecher gesehen.
In dem Vortrag mit dem provokanten Titel "Innovative Software braucht doch keine Kreativität – Ein Usability-Engineering How-to-Guide" beschrieb der Sprecher Herr Thomas Geis, wie man mithilfe der EN ISO 9241 und anderer Erkenntnisse aus dem Bereich "Entwicklung gebrauchstauglicher Produkte" mit rein methodischem Vorgehen sogenannte "Erfordernisse" an ein Produkt identifizieren kann, die unabhängig von bisherigen Lösungen oder Anforderungen oft exakt das beschreiben, was eigentlich vom Benutzer gewünscht wird.
Beispiel gefällig? Heizungsventile kennt ja so ziemlich jeder. Üblicherweise sind die irgendwie zum Drehen und haben von 0-5 eine Skala drauf, wobei man eigentlich nie weiß, welche Zahl welche Temperatur bedeutet.

< Ein beliebiges Standard-Thermostat
Ein Erfordernis an ein Heizungsventil oder eine "Heizeinrichtung" allgemein lautet jedoch eher so:
"Der Benutzer muss wissen, welchen Wert er eingeben muss um eine gewünschte Raumtemperatur zu erreichen."
Daraus ergibt sich, wenn man genau ist, nicht die Anforderung
"Der Benutzer muss am System an einem Drehregler einen Wert von 0-5 einstellen können", sondern eher etwas wie "Der Benutzer muss am System die gewünschte Zieltemperatur eingeben können."

Was passiert, wenn man so eine Anforderung konsequent zu einem sogenannten "interaktiven System" weiterentwickelt, sieht man beispielhaft hier. Das System ist bezüglich der Temperaturmessung im Raum zwar noch nicht zu 100% ausgereift, aber ein gefühlter Quantensprung an "Mehrkontrolle" gegenüber einem regulären Heizungsventil. Denn sind wir mal ehrlich, wer kennt die Situationen nicht, in denen man wie ein Verrückter zwischen "2.5" und "4.5" am Heizungsventil hin- und herdreht.
Noch spannender wird es, wenn man den Nutzungskontext einer "Heizung" genauer analysiert. Dann stellt man schnell fest, dass es nicht darum geht, eine "Zieltemperatur einzustellen", sondern dass es "angenehm temperiert ist". Analysiert man diesen Gedanken weiter, könnte es z.B. mit einem "Wearable Computer" verbinden um anhand der Körpertemperatur und der Entfernung zum Haus die Heizung so anzuschalten, dass die Wunschtemperatur immer automatisch gehalten wird. Fahre ich also weg, fährt die Heizung so weit herunter, dass sie, wenn ich jetzt umdrehen würde, bei der Ankunft zu Hause wieder auf der "Wohlfühltemperatur" steht. Boom! Innovation. Etwas, das als neu oder mit "Wow"-Effekt wahrgenommen wird, weil es bestehende Prozesse drastisch vereinfacht, verbessert oder einfach völlig anders löst als bisher bekannt.
Das Seminar - "Usability in a nutshell"
Angefixt von dem Talk auf der Konferenz haben mein Kollege und ich uns also ein gutes halbes Jahr später im Mietwagen nach Richtung Köln auf den Weg gemacht. Dadurch, dass der Talk auf der Konferenz so gut war, haben wir uns auch direkt dazu entschieden, das Training ebenfalls bei Herrn Geis von der Firma ProContext durchzuführen. Bevor jemand fragt, ich kassiere hier keine Provision, ich bin einfach wirklich begeistert von den Inhalten und der Art der Vermittlung.

"Human centered design process"
Nach dem Check-In im B&B-Hotel Köln/Messe und einem sehr geschmeidigen Abendessen in einem mexikanischen Restaurant ging es am nächsten Morgen ausgeschlafen und frisch gestärkt mit dem Zug Richtung Innenstadt zum Konferenzhotel direkt am Kölner Dom.
Tag 1 -  Usability-Basics
Bevor in tatsächliche Übungen eingestiegen werden konnte, gab es erstmal eine ordentliche Portion Theorie. Denn bei der Herstellung gebrauchstauglicher Produkte gibt es eine Menge Dinge, die einem begegnen können, die sehr präzise eingeordnet werden müssen, um sie richtig zu deuten. Die ISO-9241 und die Seminarinhalte vermitteln uns genau diese Sprache, diese Begriffe mit denen es möglich ist, solche Themen und diffusen Konzepte konkret zu benennen und damit zu arbeiten.

Programmübersicht Tag 1
Themen waren unter anderem "Erfordernisse", "Anforderungen" und was deren Unterschied ist. Ein Erfordernis z.B. ist oft unbewusst, ein sogenanntes "implied need" und muss systematisch im Nutzungskontext erhoben werden. Eine Anforderung wiederum befriedigt bei Erfüllung ein Erfordernis und basiert auf diesem. An 2 Beispielen möchte ich das kurz exemplarisch für andere erläuterte Begriffe darlegen. Alles ausführen kann und möchte ich hier nicht, das würde a) den Rahmen sprengen und müsste ich euch das vermutlich beim Lesen in Rechnung stellen.
Erfordernis
Syntax: Die <Benutzergruppe>, muss XXX wissen / verfügbar haben, um YYY entscheiden / tun zu können.
Es gibt also immer eine Voraussetzung und einen Zweck, die im Erfordernis festgehalten sind, welches wiederum im Nutzungskontext verankert sein muss.
Ein Beispiel für eine Vorrichtung zum Garen von Eiern:
Anforderung
Syntax: Der Benutzer muss am System ZZZ
erkennen/überblicken können auswählen können eingeben können Daraus ergäbe sich für unsere Garvorrichtung folgende beispielhafte Anforderung:
Wie diese Anforderung jetzt technisch umgesetzt wird, ist an dieser Stelle bewusst offen gehalten. Ob eine grafische Anzeige, eine Push-Mitteilung auf das Smartphone (IoT ist ja in aller Munde momentan), eine Melodie oder was auch immer das "Beste" ist, wird im Anschluss im Test überprüft.
Des weiteren wurden die 7 Dialogprinzipien und ihren Auswirkungen auf die Gestaltung von Nutzungsschnittstellen thematisiert.
Am Ende des ersten Workshop-Tages wurden gemeinsam in Übungen aus Nutzungskontextbeschreibungen Erfordernisse und aufbauend darauf Anforderungen her- bzw. abgeleitet. Interviews und Nutzerbeobachtungen spielen dabei im Vorfeld eine entscheidende Rolle.
Der Tag war also schon gefüllt mit ordentlich Inhalt, sowohl qualitativ als auch quantitativ. Und es zeichnete sich nicht ab, dass das weniger werden sollte. Im Gegenteil.
Um die Inhalte gebührend zu verarbeiten und Platz für Neues zu machen, gönnten wir uns mit einem Teil der Truppe nach einem Besuch des Weihnachtsmarktes am Kölner Dom gemeinsam im "Früh am Dom" noch das ein oder andere Kölsch.
Tag 2 - Entwickeln und Testen von UI/UX-Lösungen
Noch leicht schwammig im Kopf vom Kölsch ging es mit der Bahn zurück zum Hauptbahnhof und von da aus ins Schulungshotel.
Wenn Tag 1 den Fokus darauf legte, die Basis zu legen und Erfordernisse und Anforderungen zu sammeln, war der Hauptinhalt von Tag 2, zu erkunden, wie man dieses Wissen jetzt in ein Produkt, oder besser, einen Prototypen bzw. eine evaluierbare Geschäftsidee überführt.
Der oben schon verlinkte "Menschzentrierte Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme" war die Basis, auf der der zweite Tag basierte. 
Nachdem man Erfordernisse identifiziert und Anforderungen hergeleitet hat, ist der nächste Schritt im Prozess, eine Designlösung zur Evaluierung zu erarbeiten. Auf gut deutsch: "Einen Prototypen zum Testen bauen."
Dafür gibt es natürlich verschiedene Dinge, die man beachten muss. Ein paar Begriffe, Konzepte und Informationen, die dazu gehören, will ich hier exemplarisch auflisten.

Kippschalter - Benutzung offensichtlich
Affordance -Aufforderungscharakter Der Grad der Affordance beschreibt, wie sehr ein Element in einer Nutzungsschnittstelle zu seinem korrekten Gebrauch auffordert. Einem Schalter ist z.B. recht deutlich anzusehen, dass man ihn umlegen kann. Ich habe allerdings auch schon Dimmschalter gesehen, die man zum Anschalten nach unten "streicheln" musste und zum Abschalten bzw. dimmen nach oben. Aus Usability-Sicht ein ziemlicher Griff ins Klo.
Intuitiv
Im Usability-Sprech spricht man von Intuitivität, wenn die Benutzung eines interaktiven Systems unabhängig von der Erfahrung, vom Wissen, von den Sprachkenntnissen und dem momentanten Konzentrationsgrad des Benutzers unmittelbar verständlich ist.
Das heißt in der Praxis, dass ein Geldautomat dann intuitiv ist, wenn man ihn am Ballermann als 16-Jähriger, der zum zweiten mal in seinem Leben Geld abhebt, grade bierbedingt 2,5 Promille intus hat trotzdem bedienen kann. Obwohl der Automat grade in "Spanisch" eingestellt ist. Leichter gesagt als getan also.
Mentales Modell
Unter einem "Mentalen Modell" versteht man die Vorstellung, die ein Mensch von der Umgebung, den Menschen und Dingen hat, mit denen er interagiert. 

Wasserhahn mit klassischer "blau - kalt, rot - warm"-Färbung
Das Mentale Modell von einem Wasserhahn ist bei den meisten Menschen so konzipiert, dass es einen Griff zum Starten des Wasserflusses und einen Schieberegler zum Einstellen der Temperatur gibt. Das wäre das "Systemmodell". Ein Mensch, der zum ersten mal einen Wasserhahn mit Berührungssensor benutzen möchte, wird vermutlich Probleme damit haben, wenn er bis dahin noch keinen Kontakt zu dieser Technik hatte.
Ein paar Jahre vorher gab es z.B. noch nicht mal den stufenloser Schieberegler am Mischer. So musste man noch manuell heißes bzw. kaltes Wasser aufdrehen, bis man die gewünschte Zieltemperatur erreicht hat. Moderne Systeme bieten hier (zumindest in der Dusche) oft schon eine  auf den Regelmechanismus geätzte Temperaturskala an, die die Benutzung erleichtert. 
Wichtig ist für das mentale Modell jedoch diese Aussage.
Joel Spolsky, Gründer von Trello und Mitgründer von Stack Exchange, hat dazu vor 17 Jahren(!) einen Blogpost geschrieben, der immer noch Relevanz hat. 
Neben diesen Konzepten wurde den "7 Dialogprinzipien" an diesem Tag erneut verstärkt Zeit gewidmet. Dazu habe ich in meinem letzten Blogbeitrag aber schon ausführlich etwas geschrieben.
Ein weiteres Thema waren verschiedene Gestaltungsrichtlinien, sogenannte "Styleguides" oder "Design Patterns". Hierbei handelt es sich um Vorgaben, wie z.B. ein Button, eine Tabelle oder der gesamte Checkout Vorgang in einer Webseite (das wäre ein Design Pattern) aussehen sollte. Die meisten großen Hersteller von Software bieten so etwas übrigens an. Auf der Homepage unseres Trainingsanbieters findet ihr dazu einer super Übersicht.
Nach einer kurzen Exkursion zur Gestaltung verschiedener Prototypen (z.B. Papierskizze, Storyboard, Wireframe, etc.) ging es zum Ende hin dann zum großen Thema "Evaluierung der Designlösungen", also dem Test der Prototypen. Diesem Kapitel, das unter anderem Fokusgruppen, Benutzerbefragungen und Usability Tests beinhaltet, werde ich mich aber aufgrund des Umfangs in einem gesonderten Blogbeitrag widmen.
Wir schlossen den Tag mit einer Übersicht über die verschiedenen Rollen im Usability Engineering Prozess, ein paar Übungsaufgaben und einem prall gefüllten Kopf für den morgigen Prüfungstag.
Tag 3 - Prüfung zur Zertifizierung zum "UXQB® Certified Professional for Usability and User Experience – Foundation Level (CPUX-F)"
Den Vormittag und den ersten Teil des Nachmittags wendeten wir am Mittwoch zur Aufarbeitung der Inhalte zum Überprüfen der Gestaltungslösungen (also Usability Testing und co.) auf. 
Am Nachmittag wurde es dann spannend. Die Prüfung stand an. Dazu folgende Rahmenbedingungen.
40 Fragen Zum Bestehen müssen 28 von 40 Punkten erreicht werden (70%) 75 Minuten Keine Hilfsmittel erlaubt Jede Frage hat 6 Antwortmöglichkeiten, bei denen eine "signifikant richtiger" ist als die anderen Gibt es nur eine richtige Antwort, gibt es einen Punkt für eine richtige und null Punkte für eine falsche Antwort Manche Fragen haben 2 oder 3 "signifikant richtigere" Antworten, wenn dies der Fall ist, geht es aber aus der Aufgabe deutlich hervor Gibt es mehrere richtige Antwortmöglichkeiten, gibt es für jede richtige Antwort 1/AnzahlMöglichkeiten Punkte. Für jede falsche Antwort gibt es 1/AnzahlMöglichkeiten Punkte Abzug. Die Gesamtpunktzahl kann aber nie negativ sein. Die Fragen wurden, soweit ich das beurteilen kann allesamt durch die Übungen und Beispiele im Training im Vorfeld abgedeckt. So habe ich es dann auch geschafft, stolze 87,50% zu erreichen. Die Schwierigkeit der Fragen war allerdings stark gemischt. So gab es von relativ einfachen Fragen wie "Bei welchen der folgenden Begriffe handelt es sich um Dialogprinzipien?", wo die Lösung einfach aufgrund der Namen recht simpel war bis hin zu sehr schwierigen Fragen, wo mehrere Lösungen tatsächlich richtig waren, aber eine eben ein "Stückchen richtiger" als die anderen eine große Durchmischung. Da ging es z.B. um eine Fehlermeldung in Form eines Fehlercodes nach einer Datumseingabe in einer Webseite und einen Vorschlag zur Verbesserung. Gegeben waren von der ausführlicheren Fehlermeldung hin zum "Tutorial" verschiedene Möglichkeiten. Die richtige war jedoch, die Datumseingabe durch eine Datumsauswahl zu ersetzen, um Tippfehler, die erst validiert werden müssen überflüssig zu machen. So einfach kann's gehen.
Alles in allem machbar, aber knackig.
Fazit
Meiner Meinung nach waren das drei sehr gelungene Tage und wohl investiertes Geld. Geld heißt hier 1.500€ zzgl. MwSt. für das Training und 300€ zzgl. MwSt. für die Prüfung. Eine Rückerstattung bei Nicht Bestehen gibt es hier selbstverständlich nicht.
Obwohl die Möglichkeit besteht, sich extern auf die Prüfung vorzubereiten und die Unterlagen dafür im Internet frei verfügbar sind, halte ich ein vorbereitendes Training für sehr wertvoll, um das Wissen im Kontext richtig einordnen zu können. Darüberhinaus hat man durch den Kontakt mit anderen Teilnehmern die Möglichkeit, sich über Praxiswissen und echte Anwendungsfälle direkt austauschen zu können, was in der Gruppe sehr wichtig war.
Ich gucke heute noch regelmäßig in meine Schulungsmappe und das im Training bzw. für die Prüfung erworbene Seminar hilft mir tatsächlich, im Alltag bessere Entscheidungen zu treffen, wenn es um Produkt- oder Prozessgestaltung geht. Und da ist egal, ob es sich um digitale Produkte handelt oder "welche zum Anfassen".
Wenn ihr Fragen habt, zögert nicht, hier zu kommentieren oder mir zu schreiben.
Gruß, euer "devopsdad" Patrick

Hallo Welt!
Nach einer längeren Zeit der Beitragsflaute mal wieder ein neuer Post. Dafür gibt es dieses mal auch etwas mehr und wieder einen Veranstaltungsbericht. Dieses mal jedoch nicht von einer Konferenz, sondern von einem Seminar mit anschließender Prüfung zur Zertifizierung.
Vom 05.07.2016 bis zum 07.07.2016 bin ich mit einem Kollegen in Köln auf einer prüfungsvorbereitenden Schulung zum Thema "Usability Engineering and User Experience" gewesen und habe dort einiges an Wissen erworben, das ich gerne auszugsweise(da sonst jeglichen Rahmen sprengend) mit euch teilen möchte.
Innovative Software braucht doch keine Kreativität "UX aus der Dose"
Im April 2016 habe ich mit zwei Kollegen die "OBJEKTspektrum information days" in Frankfurt am Main besucht und dort einen extrem interessanten Vortrag von einem mir recht sympathischen Sprecher gesehen.
In dem Vortrag mit dem provokanten Titel "Innovative Software braucht doch keine Kreativität – Ein Usability-Engineering How-to-Guide" beschrieb der Sprecher Herr Thomas Geis, wie man mithilfe der EN ISO 9241 und anderer Erkenntnisse aus dem Bereich "Entwicklung gebrauchstauglicher Produkte" mit rein methodischem Vorgehen sogenannte "Erfordernisse" an ein Produkt identifizieren kann, die unabhängig von bisherigen Lösungen oder Anforderungen oft exakt das beschreiben, was eigentlich vom Benutzer gewünscht wird.
Beispiel gefällig? Heizungsventile kennt ja so ziemlich jeder. Üblicherweise sind die irgendwie zum Drehen und haben von 0-5 eine Skala drauf, wobei man eigentlich nie weiß, welche Zahl welche Temperatur bedeutet.

< Ein beliebiges Standard-Thermostat
Ein Erfordernis an ein Heizungsventil oder eine "Heizeinrichtung" allgemein lautet jedoch eher so:
"Der Benutzer muss wissen, welchen Wert er eingeben muss um eine gewünschte Raumtemperatur zu erreichen."
Daraus ergibt sich, wenn man genau ist, nicht die Anforderung
"Der Benutzer muss am System an einem Drehregler einen Wert von 0-5 einstellen können", sondern eher etwas wie "Der Benutzer muss am System die gewünschte Zieltemperatur eingeben können."

Was passiert, wenn man so eine Anforderung konsequent zu einem sogenannten "interaktiven System" weiterentwickelt, sieht man beispielhaft hier. Das System ist bezüglich der Temperaturmessung im Raum zwar noch nicht zu 100% ausgereift, aber ein gefühlter Quantensprung an "Mehrkontrolle" gegenüber einem regulären Heizungsventil. Denn sind wir mal ehrlich, wer kennt die Situationen nicht, in denen man wie ein Verrückter zwischen "2.5" und "4.5" am Heizungsventil hin- und herdreht.
Noch spannender wird es, wenn man den Nutzungskontext einer "Heizung" genauer analysiert. Dann stellt man schnell fest, dass es nicht darum geht, eine "Zieltemperatur einzustellen", sondern dass es "angenehm temperiert ist". Analysiert man diesen Gedanken weiter, könnte es z.B. mit einem "Wearable Computer" verbinden um anhand der Körpertemperatur und der Entfernung zum Haus die Heizung so anzuschalten, dass die Wunschtemperatur immer automatisch gehalten wird. Fahre ich also weg, fährt die Heizung so weit herunter, dass sie, wenn ich jetzt umdrehen würde, bei der Ankunft zu Hause wieder auf der "Wohlfühltemperatur" steht. Boom! Innovation. Etwas, das als neu oder mit "Wow"-Effekt wahrgenommen wird, weil es bestehende Prozesse drastisch vereinfacht, verbessert oder einfach völlig anders löst als bisher bekannt.
Das Seminar - "Usability in a nutshell"
Angefixt von dem Talk auf der Konferenz haben mein Kollege und ich uns also ein gutes halbes Jahr später im Mietwagen nach Richtung Köln auf den Weg gemacht. Dadurch, dass der Talk auf der Konferenz so gut war, haben wir uns auch direkt dazu entschieden, das Training ebenfalls bei Herrn Geis von der Firma ProContext durchzuführen. Bevor jemand fragt, ich kassiere hier keine Provision, ich bin einfach wirklich begeistert von den Inhalten und der Art der Vermittlung.

"Human centered design process"
Nach dem Check-In im B&B-Hotel Köln/Messe und einem sehr geschmeidigen Abendessen in einem mexikanischen Restaurant ging es am nächsten Morgen ausgeschlafen und frisch gestärkt mit dem Zug Richtung Innenstadt zum Konferenzhotel direkt am Kölner Dom.
Tag 1 -  Usability-Basics
Bevor in tatsächliche Übungen eingestiegen werden konnte, gab es erstmal eine ordentliche Portion Theorie. Denn bei der Herstellung gebrauchstauglicher Produkte gibt es eine Menge Dinge, die einem begegnen können, die sehr präzise eingeordnet werden müssen, um sie richtig zu deuten. Die ISO-9241 und die Seminarinhalte vermitteln uns genau diese Sprache, diese Begriffe mit denen es möglich ist, solche Themen und diffusen Konzepte konkret zu benennen und damit zu arbeiten.

Programmübersicht Tag 1
Themen waren unter anderem "Erfordernisse", "Anforderungen" und was deren Unterschied ist. Ein Erfordernis z.B. ist oft unbewusst, ein sogenanntes "implied need" und muss systematisch im Nutzungskontext erhoben werden. Eine Anforderung wiederum befriedigt bei Erfüllung ein Erfordernis und basiert auf diesem. An 2 Beispielen möchte ich das kurz exemplarisch für andere erläuterte Begriffe darlegen. Alles ausführen kann und möchte ich hier nicht, das würde a) den Rahmen sprengen und müsste ich euch das vermutlich beim Lesen in Rechnung stellen.
Erfordernis
Syntax: Die <Benutzergruppe>, muss XXX wissen / verfügbar haben, um YYY entscheiden / tun zu können.
Es gibt also immer eine Voraussetzung und einen Zweck, die im Erfordernis festgehalten sind, welches wiederum im Nutzungskontext verankert sein muss.
Ein Beispiel für eine Vorrichtung zum Garen von Eiern:
Anforderung
Syntax: Der Benutzer muss am System ZZZ
erkennen/überblicken können auswählen können eingeben können Daraus ergäbe sich für unsere Garvorrichtung folgende beispielhafte Anforderung:
Wie diese Anforderung jetzt technisch umgesetzt wird, ist an dieser Stelle bewusst offen gehalten. Ob eine grafische Anzeige, eine Push-Mitteilung auf das Smartphone (IoT ist ja in aller Munde momentan), eine Melodie oder was auch immer das "Beste" ist, wird im Anschluss im Test überprüft.
Des weiteren wurden die 7 Dialogprinzipien und ihren Auswirkungen auf die Gestaltung von Nutzungsschnittstellen thematisiert.
Am Ende des ersten Workshop-Tages wurden gemeinsam in Übungen aus Nutzungskontextbeschreibungen Erfordernisse und aufbauend darauf Anforderungen her- bzw. abgeleitet. Interviews und Nutzerbeobachtungen spielen dabei im Vorfeld eine entscheidende Rolle.
Der Tag war also schon gefüllt mit ordentlich Inhalt, sowohl qualitativ als auch quantitativ. Und es zeichnete sich nicht ab, dass das weniger werden sollte. Im Gegenteil.
Um die Inhalte gebührend zu verarbeiten und Platz für Neues zu machen, gönnten wir uns mit einem Teil der Truppe nach einem Besuch des Weihnachtsmarktes am Kölner Dom gemeinsam im "Früh am Dom" noch das ein oder andere Kölsch.
Tag 2 - Entwickeln und Testen von UI/UX-Lösungen
Noch leicht schwammig im Kopf vom Kölsch ging es mit der Bahn zurück zum Hauptbahnhof und von da aus ins Schulungshotel.
Wenn Tag 1 den Fokus darauf legte, die Basis zu legen und Erfordernisse und Anforderungen zu sammeln, war der Hauptinhalt von Tag 2, zu erkunden, wie man dieses Wissen jetzt in ein Produkt, oder besser, einen Prototypen bzw. eine evaluierbare Geschäftsidee überführt.
Der oben schon verlinkte "Menschzentrierte Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme" war die Basis, auf der der zweite Tag basierte. 
Nachdem man Erfordernisse identifiziert und Anforderungen hergeleitet hat, ist der nächste Schritt im Prozess, eine Designlösung zur Evaluierung zu erarbeiten. Auf gut deutsch: "Einen Prototypen zum Testen bauen."
Dafür gibt es natürlich verschiedene Dinge, die man beachten muss. Ein paar Begriffe, Konzepte und Informationen, die dazu gehören, will ich hier exemplarisch auflisten.

Kippschalter - Benutzung offensichtlich
Affordance -Aufforderungscharakter Der Grad der Affordance beschreibt, wie sehr ein Element in einer Nutzungsschnittstelle zu seinem korrekten Gebrauch auffordert. Einem Schalter ist z.B. recht deutlich anzusehen, dass man ihn umlegen kann. Ich habe allerdings auch schon Dimmschalter gesehen, die man zum Anschalten nach unten "streicheln" musste und zum Abschalten bzw. dimmen nach oben. Aus Usability-Sicht ein ziemlicher Griff ins Klo.
Intuitiv
Im Usability-Sprech spricht man von Intuitivität, wenn die Benutzung eines interaktiven Systems unabhängig von der Erfahrung, vom Wissen, von den Sprachkenntnissen und dem momentanten Konzentrationsgrad des Benutzers unmittelbar verständlich ist.
Das heißt in der Praxis, dass ein Geldautomat dann intuitiv ist, wenn man ihn am Ballermann als 16-Jähriger, der zum zweiten mal in seinem Leben Geld abhebt, grade bierbedingt 2,5 Promille intus hat trotzdem bedienen kann. Obwohl der Automat grade in "Spanisch" eingestellt ist. Leichter gesagt als getan also.
Mentales Modell
Unter einem "Mentalen Modell" versteht man die Vorstellung, die ein Mensch von der Umgebung, den Menschen und Dingen hat, mit denen er interagiert. 

Wasserhahn mit klassischer "blau - kalt, rot - warm"-Färbung
Das Mentale Modell von einem Wasserhahn ist bei den meisten Menschen so konzipiert, dass es einen Griff zum Starten des Wasserflusses und einen Schieberegler zum Einstellen der Temperatur gibt. Das wäre das "Systemmodell". Ein Mensch, der zum ersten mal einen Wasserhahn mit Berührungssensor benutzen möchte, wird vermutlich Probleme damit haben, wenn er bis dahin noch keinen Kontakt zu dieser Technik hatte.
Ein paar Jahre vorher gab es z.B. noch nicht mal den stufenloser Schieberegler am Mischer. So musste man noch manuell heißes bzw. kaltes Wasser aufdrehen, bis man die gewünschte Zieltemperatur erreicht hat. Moderne Systeme bieten hier (zumindest in der Dusche) oft schon eine  auf den Regelmechanismus geätzte Temperaturskala an, die die Benutzung erleichtert. 
Wichtig ist für das mentale Modell jedoch diese Aussage.
Joel Spolsky, Gründer von Trello und Mitgründer von Stack Exchange, hat dazu vor 17 Jahren(!) einen Blogpost geschrieben, der immer noch Relevanz hat. 
Neben diesen Konzepten wurde den "7 Dialogprinzipien" an diesem Tag erneut verstärkt Zeit gewidmet. Dazu habe ich in meinem letzten Blogbeitrag aber schon ausführlich etwas geschrieben.
Ein weiteres Thema waren verschiedene Gestaltungsrichtlinien, sogenannte "Styleguides" oder "Design Patterns". Hierbei handelt es sich um Vorgaben, wie z.B. ein Button, eine Tabelle oder der gesamte Checkout Vorgang in einer Webseite (das wäre ein Design Pattern) aussehen sollte. Die meisten großen Hersteller von Software bieten so etwas übrigens an. Auf der Homepage unseres Trainingsanbieters findet ihr dazu einer super Übersicht.
Nach einer kurzen Exkursion zur Gestaltung verschiedener Prototypen (z.B. Papierskizze, Storyboard, Wireframe, etc.) ging es zum Ende hin dann zum großen Thema "Evaluierung der Designlösungen", also dem Test der Prototypen. Diesem Kapitel, das unter anderem Fokusgruppen, Benutzerbefragungen und Usability Tests beinhaltet, werde ich mich aber aufgrund des Umfangs in einem gesonderten Blogbeitrag widmen.
Wir schlossen den Tag mit einer Übersicht über die verschiedenen Rollen im Usability Engineering Prozess, ein paar Übungsaufgaben und einem prall gefüllten Kopf für den morgigen Prüfungstag.
Tag 3 - Prüfung zur Zertifizierung zum "UXQB® Certified Professional for Usability and User Experience – Foundation Level (CPUX-F)"
Den Vormittag und den ersten Teil des Nachmittags wendeten wir am Mittwoch zur Aufarbeitung der Inhalte zum Überprüfen der Gestaltungslösungen (also Usability Testing und co.) auf. 
Am Nachmittag wurde es dann spannend. Die Prüfung stand an. Dazu folgende Rahmenbedingungen.
40 Fragen Zum Bestehen müssen 28 von 40 Punkten erreicht werden (70%) 75 Minuten Keine Hilfsmittel erlaubt Jede Frage hat 6 Antwortmöglichkeiten, bei denen eine "signifikant richtiger" ist als die anderen Gibt es nur eine richtige Antwort, gibt es einen Punkt für eine richtige und null Punkte für eine falsche Antwort Manche Fragen haben 2 oder 3 "signifikant richtigere" Antworten, wenn dies der Fall ist, geht es aber aus der Aufgabe deutlich hervor Gibt es mehrere richtige Antwortmöglichkeiten, gibt es für jede richtige Antwort 1/AnzahlMöglichkeiten Punkte. Für jede falsche Antwort gibt es 1/AnzahlMöglichkeiten Punkte Abzug. Die Gesamtpunktzahl kann aber nie negativ sein. Die Fragen wurden, soweit ich das beurteilen kann allesamt durch die Übungen und Beispiele im Training im Vorfeld abgedeckt. So habe ich es dann auch geschafft, stolze 87,50% zu erreichen. Die Schwierigkeit der Fragen war allerdings stark gemischt. So gab es von relativ einfachen Fragen wie "Bei welchen der folgenden Begriffe handelt es sich um Dialogprinzipien?", wo die Lösung einfach aufgrund der Namen recht simpel war bis hin zu sehr schwierigen Fragen, wo mehrere Lösungen tatsächlich richtig waren, aber eine eben ein "Stückchen richtiger" als die anderen eine große Durchmischung. Da ging es z.B. um eine Fehlermeldung in Form eines Fehlercodes nach einer Datumseingabe in einer Webseite und einen Vorschlag zur Verbesserung. Gegeben waren von der ausführlicheren Fehlermeldung hin zum "Tutorial" verschiedene Möglichkeiten. Die richtige war jedoch, die Datumseingabe durch eine Datumsauswahl zu ersetzen, um Tippfehler, die erst validiert werden müssen überflüssig zu machen. So einfach kann's gehen.
Alles in allem machbar, aber knackig.
Fazit
Meiner Meinung nach waren das drei sehr gelungene Tage und wohl investiertes Geld. Geld heißt hier 1.500€ zzgl. MwSt. für das Training und 300€ zzgl. MwSt. für die Prüfung. Eine Rückerstattung bei Nicht Bestehen gibt es hier selbstverständlich nicht.
Obwohl die Möglichkeit besteht, sich extern auf die Prüfung vorzubereiten und die Unterlagen dafür im Internet frei verfügbar sind, halte ich ein vorbereitendes Training für sehr wertvoll, um das Wissen im Kontext richtig einordnen zu können. Darüberhinaus hat man durch den Kontakt mit anderen Teilnehmern die Möglichkeit, sich über Praxiswissen und echte Anwendungsfälle direkt austauschen zu können, was in der Gruppe sehr wichtig war.
Ich gucke heute noch regelmäßig in meine Schulungsmappe und das im Training bzw. für die Prüfung erworbene Seminar hilft mir tatsächlich, im Alltag bessere Entscheidungen zu treffen, wenn es um Produkt- oder Prozessgestaltung geht. Und da ist egal, ob es sich um digitale Produkte handelt oder "welche zum Anfassen".
Wenn ihr Fragen habt, zögert nicht, hier zu kommentieren oder mir zu schreiben.
Gruß, euer "devopsdad" Patrick

Hier geht es nun weiter mit dem Thema Praktikumssuche während der Umschulung. Diesmal geht es zuerst um die Suche nach passenden Betrieben. Mit dem richtigen Betrieb, könnt ihr bereits den Grundstein für eure spätere Karriererichtung legen.
Anschließend gebe ich einige Tipps, extrahiert aus eigenen Erfahrungen, wodurch Bewerber um einen Praktikumsplatz, aber auch um einen Ausbildungsplatz negativ aufgefallen sind.
Beachtet bitte auch hier: Dies stellt nur einen Leitfaden aus Erfahrungen dar, der euch keinen Erfolg garantiert, aber es euch hoffentlich ein gutes Stück leichter macht euer Praktikum und damit eure Umschulung erfolgreich zu absolvieren
Die Suche nach passenden Betrieben:
Viele Umschüler unterschätzen die Suche nach einem geeigneten Praktikum gewaltig, geraten unter Zeitdruck und müssen dann jedes Angebot annehmen, ob es ihnen nun zu ihnen passt oder nicht. Wer in solch eine Situation kommt, verliert den Einfluss darauf eine praktische Ausbildung zu erhalten, die zu den zukünftigen Karriereplänen passt. Ihr solltet euch daher bereits 5-8 Monate vor dem Praktikumsstart um einen Praktikumsplatz kümmern
Zuerst solltet Ihr eine Liste von potenziellen Praktikumsbetrieben erstellen. Voraussetzung hierfür ist normalerweise, dass dieser Betrieb in dem Beruf bereits ausbildet und auch in der Lage ist einen Praktikanten zu beschäftigen. Solche Firmen könnt Ihr über Eure IHK, diverse Lehrstellenbörsen oder Praktikumssuchmaschinen finden. Universitäten, Hochschulen und wissenschaftliche Institute bilden inzwischen auch oft aus und nehmen auch immer mal wieder Praktikanten aller Fachrichtungen.
Einer der sichersten und besten Möglichkeiten solche Firmen zu finden ist übrigens ein guter Umgang mit euren Mitumschülern der vorangegangenen Semester. Diese haben entweder bereits ein Praktikum hinter sich gebracht und können euch auch eine gute Einschätzung der dortigen Verhältnisse geben oder starten demnächst in ein Praktikum und haben dort dann bereits eine Zusage. Es lohnt sich hier eine weitere Liste anzulegen und alle diese Firmen separat zu sammeln. Eventuell mit einer kurzen Einschätzung der bisherigen Praktikanten. Frag doch auch einmal bei euren Dozenten nach, in welchen Firmen eure Vorgänger so waren. Gerade der Dozent, der für die Vorbereitung auf die Präsentationen zuständig ist, wird in den Übungen wohl den Namen des jeweiligen Praktikumsbetriebs mehrfach hören und sehen.
Beim Anlegen Eurer Adressenliste solltet ihr darauf achten, wenn möglich, E-Mail-Adressen und Ansprechpartner mit zu erfassen. Wenn ihr so vorgeht, könnt ihr in wenigen Stunden eine beachtliche Liste von 50 – 500 Adressen zusammentragen. Ich rate euch zudem die Adressen an den Anfang zu stellen, von denen ihr wisst, dass sie bereits Praktikanten genommen haben.
Auch solltet ihr hier bedenken, dass die meisten Firmen einfach keine Ressourcen für einen Umschüler haben, selbst wenn sie ausbilden. Hier kann bereits die zuständige IHK eine Grenze gesetzt haben. Die hiesige IHK sagt hierzu es sollte mindestens eine ausgebildete Fachkraft pro Azubi oder Umschüler vorhanden sein und einer der Fachkräfte muss zusätzlich Ausbilder im Betrieb sein. Ausnahmen bestätigen hier, wie immer, die Regel und letztendlich entscheidet eure IHK.
 Es kann daher sehr wohl vorkommen, dass ihr 40 Bewerbungen fertigmacht und 40 Absagen bekommt die nur der einfachen Tatsache geschuldet sind, dass es keine solche Stelle im Unternehmen gibt. Davon erfahrt ihr natürlich nichts und der Frust ist groß, da man sich die Mühe gemacht hat 40 Bewerbungen und Anschreiben anzupassen.  Um euch eine Menge Arbeit und Frust zu ersparen, rate ich euch die Bewerbungen in 2 Schritten anzugehen.
Statt jeder Adresse eine angepasste Bewerbung zukommen zu lassen, könnt ihr im 1. Schritt einen kleinen Text verfassen, indem ihr erklärt für welchen Zeitraum, warum und für welchen Beruf ihr einen Praktikumsplatz sucht. Und bei Interesse werdet ihr ihnen gerne eure kompletten Bewerbungsunterlagen zusenden. In dem Text könntet ihr beispielsweise ebenfalls unterbringen, dass ihr während des Praktikums über den Bildungsträger versichert seid, dieses Praktikum als Ausbildungspraktikum gilt und daher auch nicht unter das Mindestlohngesetz fällt und die Firma aufgrund anderweitiger Förderung auch ansonsten zu keinem finanziellen Ausgleich verpflichtet wäre. Diesen Text sendet ihr dann an alle Empfänger aus eurer Adressliste.
Ihr könnt dies übrigens auch gleich als Übung für eure Skriptkünste nutzen und ein kleines Skript schreiben, mit dem aus eurer Liste die Ansprechpartner und Mailadressen ausgelesen und passend in der Mail eingetragen werden.  Es gibt auch eine einfache Möglichkeit über Thunderbird mithilfe von Addons Mails zu personalisieren.
Alternativ könnt ihr die Liste natürlich auch einfach telefonisch durchgehen. Ihr erhaltet in so einem Fall die Antwort schneller und der Ansprechpartner bekommt einen ersten persönlichen Eindruck von euch. Andererseits kommt es auch sehr oft vor, dass ihr den Anprechpartner telefonisch nicht erreichen werdet. Dies kann ziemlich schnell frustrieren.
Wenn nun eine positive Antwort eintrifft, verfasst ihr im 2. Schritt eine persönliche und auf das Unternehmen zurechtgeschnittene Bewerbungen
Die Bewerbung
Als Ausbilder habe ich eine Menge Bewerbungen von Azubis und später von Umschülern auf der Suche nach einem Praktikum gelesen. Daher hier ein paar Ratschläge daraus:
Achtet darauf eine vernünftige E-Mailadresse zu verwenden. Mailadressen ohne Namensbezug oder Mails von der Domain einer anderen Firma machen oft einen schlechten ersten Eindruck. Legt euch lieber eine kostenlose Adresse an, die ihr nur für Bewerbungen benutzt. Signaturen mit witzigen Sprüchen oder der eigenen Firma haben in solchen Mails nichts zu suchen. Einige kostenlose E-Mailanbietern binden nach dem Versenden ihre eigene Werbesignatur in die Mail ein. Dies könnt ihr meist verhindern, indem ihr einen E-Mail-Client wie z.B. Thunderbird oder Outlook benutzt, anstatt der Weboberfläche. Ihr solltet euch erst einmal selber eine Mail senden, um zu sehen wie die Mail beim Empfänger ankommt.
Bitte legt euch auf einem Dateityp fest. Es hinterlässt einen schlechten Nachgeschmack beim Empfänger, wenn ihr ein Sammelsurium an diversen Dateiformaten versendet, für die er mehrere Programme benötigt oder die er eventuell gar nicht lesen kann ohne ein weiteres Programm zu installieren. Bedenkt dabei, ein Personaler hat eventuell nur ein modernes Microsoft Word installiert und kann im schlimmsten Fall eure Bewerbung als .doc oder .odt überhaupt nicht öffnen. Vorzugsweise schickt ihr eine einzelne Pfd. Dies wird jeder Ansprechpartner öffnen können und es sieht immer gleich aus.
Danach heißt es warten auf eine positive Antwort und auf den Start des Praktikums.
 

Hallo Welt!
Jetzt gab es eine ganze Weile lang keine neuen Inhalte hier aber inspiriert durch einen interessanten Thread im Fachinformatiker.de-Forum habe ich mich entschlossen, einen Beitrag zu einem allgemein gültigen Thema zu schreiben, das mir seit einer Weile sehr am Herzen liegt.
Den 7 Dialogprinzipien - Intro
Die 7 Dialogprinzipien, in ISO 9241-110 als "Grundsätze der Dialoggestaltung" beschrieben, beschreiben, wie Nutzer mit interaktiven Systemen interagieren und welche Prinzipien dieser Interaktion allgemein zu Grunde liegen.
Sie können positiv besetzt und erfüllt werden, oder verletzt. Werden sie verletzt, entstehen "Nutzungsfehler".

 Nicht so, Eierlegende Wollmilchsau, CC-BY-SA 2.5, Autor: Georg Mittendecker, Entnommen aus: https://commons.wikimedia.org/wiki/File:Wollmilchsau.jpg
Wichtig ist hier die feine Unterscheidung der Begrifflichkeiten. Ich spreche von "Nutzungsfehlern" nicht von "Nutzerfehlern". Interaktive Systeme, deren Benutzungsschnittstellen(User Interfaces) so gebaut sind, dass sie zum Nutzungskontext der angepeilten Benutzergruppe passen, sind wesentlich weniger fehleranfällig als Systeme, die versuchen, die eierlegende Wollmilchsau für "alle Benutzer jemals" zu sein. Eine nicht vollständige oder fehlerhafte Benutzergruppenanalyse ist einer der Hauptgründe für viele Usability-Probleme und unzufriedene Benutzer.
Aber genug Einführung. Hier kommen sie.
Die 7 Dialogprinzipien - Übersicht
Vorweg: Die Großzahl auftretender Nutzungsfehler entsteht aus Verletzungen der ersten 3 hier genannten Dialogprinzipien.
Zur Illustrierung der Dialogprinzipien halten wir uns an die folgende Aufgabe: "Einen Mietwagen buchen".
Aufgabenangemessenheit
Ein interaktives System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Arbeitsaufgabe zu erledigen, d. h., wenn Funktionalität und Dialog auf den charakteristischen Eigenschaften der Arbeitsaufgabe basieren, anstatt auf der zur Aufgabenerledigung eingesetzten Technologie. Es kommen keine unnötigen oder nicht zur Lösung der Aufgabe benötigten Schritte vor.

Standort-Buchung hertz.de, Screenshot, aufgenommen am 13.07.2017
Beispiel: Wenn ich bei hertz.de als Standort "Kassel" auswähle, kann ich die Standortgruppe "Kassel DE (4 locations)" anwählen. Erst wenn ich alle anderen Eingaben getätigt habe und im Formular weitergehen möchte, muss ich einen spezifischen Standort auswählen. Ein unnötiger Schritt, den man direkt im ersten Formular bearbeiten können sollte.
 
Selbstbeschreibungsfähigkeit
Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit offensichtlich ist, in welchem Dialog, an welcher Stelle im Dialog er sich befindet, welche Handlungen unternommen werden können und wie diese ausgeführt werden können.
Beispiel: In einem weißen Suchfeld zur Fahrzeugsuche steht neben einer Lupe der Text "Hier können Sie durch Texteingabe Fahrzeugtypen suchen"
Erwartungskonformität
Ein Dialog ist erwartungskonform, wenn er den aus dem Nutzungskontext heraus vorhersehbaren Benutzerbelangen sowie allgemein anerkannten Konventionen entspricht.
Beispiel: Ein Klick auf ein kleines Kalender-Icon in einem Auswahlbereich zur Abholung des Fahrzeugs öffnet ein Datepicker-Steuerelement.
Erlernbarkeit / Lernförderlichkeit
Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen der Nutzung des interaktiven Systems unterstützt und anleitet.
Beispiel: Wenn erkannt wird, dass der Benutzer die Webseite zum ersten mal besucht, wird er durch ein Assistenzprogramm und verschiedene Highlights durch den Buchungsprozess geleitet. (Abdunkeln von zum momentanen Zeitpunkt nicht benötigten Steuerelementen) 
Steuerbarkeit
Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.
Negativbeispiel: Eine fehlerhafte Eingabe in einem Kontaktformular führt dazu, dass der Nutzer das gesamte Formular erneut ausfüllen muss, anstatt an den Punkt zu springen, in dem die Falscheingabe liegt.
Fehlertoleranz
Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann.
Beispiel 1: Der Benutzer gibt im Texteingabefeld das Datum "23.12.2017" ein. Das System gibt einen Fehler aus und weist ihn darauf hin, dass das Datumsformat dem folgenden Schema genügen muss. "MM-DD-YYYY". Noch besser wäre hier allerdings, statt einer Benutzereingabe eine Auswahl durch z.B. ein Datepicker-Element zu ermöglichen.Beispiel 2: Der Benutzer gibt eine E-Mail Adresse im falschen Format  an und erhält eine Fehlermeldung, die als Beispiel ein korrektes Format anzeigt.
Individualisierbarkeit
Ein Dialog ist individualisierbar, wenn Benutzer die Mensch-System-Interaktion und die Darstellung von Informationen ändern können, um diese an ihre individuellen Fähigkeiten und Bedürfnisse anzupassen.
Beispiel 1: Ein Benutzer kann dauerhaft speichern, in welchem Format Zahlen und in welcher Sprache Texte in einer Anwendung dargestellt werden sollen.Beispiel 2: Ein Benutzer hat die Möglichkeit, ein Benutzerkonto anzulegen und dort Informationen zu speichern, die er beim nächsten Lösen der Aufgabe nicht mehr manuell eingeben muss.
Die 7 Dialogprinzipien - Fazit
So viel zu merken ist es eigentlich gar nicht. Und wenn man die ersten 3 Prinzipien verinnerlicht hat und weiß, worauf es beim Entwickeln von Benutzungsschnittstellen ankommt, kann man das Fehlerpotential seiner interaktiven Systeme drastisch senken.
In diesem Sinne, viel Spaß beim Überarbeiten und Entschuldigung im Voraus für all die Verletzungen der Dialogprinzipien, die ihr nach dem Lesen dieses Beitrags wahrnehmen werdet.
Gruß, euer "devopsdad" Patrick

Hallo Welt!
Jetzt gab es eine ganze Weile lang keine neuen Inhalte hier aber inspiriert durch einen interessanten Thread im Fachinformatiker.de-Forum habe ich mich entschlossen, einen Beitrag zu einem allgemein gültigen Thema zu schreiben, das mir seit einer Weile sehr am Herzen liegt.
Den 7 Dialogprinzipien - Intro
Die 7 Dialogprinzipien, in ISO 9241-110 als "Grundsätze der Dialoggestaltung" beschrieben, beschreiben, wie Nutzer mit interaktiven Systemen interagieren und welche Prinzipien dieser Interaktion allgemein zu Grunde liegen.
Sie können positiv besetzt und erfüllt werden, oder verletzt. Werden sie verletzt, entstehen "Nutzungsfehler".

 Nicht so, Eierlegende Wollmilchsau, CC-BY-SA 2.5, Autor: Georg Mittendecker, Entnommen aus: https://commons.wikimedia.org/wiki/File:Wollmilchsau.jpg
Wichtig ist hier die feine Unterscheidung der Begrifflichkeiten. Ich spreche von "Nutzungsfehlern" nicht von "Nutzerfehlern". Interaktive Systeme, deren Benutzungsschnittstellen(User Interfaces) so gebaut sind, dass sie zum Nutzungskontext der angepeilten Benutzergruppe passen, sind wesentlich weniger fehleranfällig als Systeme, die versuchen, die eierlegende Wollmilchsau für "alle Benutzer jemals" zu sein. Eine nicht vollständige oder fehlerhafte Benutzergruppenanalyse ist einer der Hauptgründe für viele Usability-Probleme und unzufriedene Benutzer.
Aber genug Einführung. Hier kommen sie.
Die 7 Dialogprinzipien - Übersicht
Vorweg: Die Großzahl auftretender Nutzungsfehler entsteht aus Verletzungen der ersten 3 hier genannten Dialogprinzipien.
Zur Illustrierung der Dialogprinzipien halten wir uns an die folgende Aufgabe: "Einen Mietwagen buchen".
Aufgabenangemessenheit
Ein interaktives System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Arbeitsaufgabe zu erledigen, d. h., wenn Funktionalität und Dialog auf den charakteristischen Eigenschaften der Arbeitsaufgabe basieren, anstatt auf der zur Aufgabenerledigung eingesetzten Technologie. Es kommen keine unnötigen oder nicht zur Lösung der Aufgabe benötigten Schritte vor.

Standort-Buchung hertz.de, Screenshot, aufgenommen am 13.07.2017
Beispiel: Wenn ich bei hertz.de als Standort "Kassel" auswähle, kann ich die Standortgruppe "Kassel DE (4 locations)" anwählen. Erst wenn ich alle anderen Eingaben getätigt habe und im Formular weitergehen möchte, muss ich einen spezifischen Standort auswählen. Ein unnötiger Schritt, den man direkt im ersten Formular bearbeiten können sollte.
 
Selbstbeschreibungsfähigkeit
Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit offensichtlich ist, in welchem Dialog, an welcher Stelle im Dialog er sich befindet, welche Handlungen unternommen werden können und wie diese ausgeführt werden können.
Beispiel: In einem weißen Suchfeld zur Fahrzeugsuche steht neben einer Lupe der Text "Hier können Sie durch Texteingabe Fahrzeugtypen suchen"
Erwartungskonformität
Ein Dialog ist erwartungskonform, wenn er den aus dem Nutzungskontext heraus vorhersehbaren Benutzerbelangen sowie allgemein anerkannten Konventionen entspricht.
Beispiel: Ein Klick auf ein kleines Kalender-Icon in einem Auswahlbereich zur Abholung des Fahrzeugs öffnet ein Datepicker-Steuerelement.
Erlernbarkeit / Lernförderlichkeit
Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen der Nutzung des interaktiven Systems unterstützt und anleitet.
Beispiel: Wenn erkannt wird, dass der Benutzer die Webseite zum ersten mal besucht, wird er durch ein Assistenzprogramm und verschiedene Highlights durch den Buchungsprozess geleitet. (Abdunkeln von zum momentanen Zeitpunkt nicht benötigten Steuerelementen) 
Steuerbarkeit
Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.
Negativbeispiel: Eine fehlerhafte Eingabe in einem Kontaktformular führt dazu, dass der Nutzer das gesamte Formular erneut ausfüllen muss, anstatt an den Punkt zu springen, in dem die Falscheingabe liegt.
Fehlertoleranz
Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann.
Beispiel 1: Der Benutzer gibt im Texteingabefeld das Datum "23.12.2017" ein. Das System gibt einen Fehler aus und weist ihn darauf hin, dass das Datumsformat dem folgenden Schema genügen muss. "MM-DD-YYYY". Noch besser wäre hier allerdings, statt einer Benutzereingabe eine Auswahl durch z.B. ein Datepicker-Element zu ermöglichen.Beispiel 2: Der Benutzer gibt eine E-Mail Adresse im falschen Format  an und erhält eine Fehlermeldung, die als Beispiel ein korrektes Format anzeigt.
Individualisierbarkeit
Ein Dialog ist individualisierbar, wenn Benutzer die Mensch-System-Interaktion und die Darstellung von Informationen ändern können, um diese an ihre individuellen Fähigkeiten und Bedürfnisse anzupassen.
Beispiel 1: Ein Benutzer kann dauerhaft speichern, in welchem Format Zahlen und in welcher Sprache Texte in einer Anwendung dargestellt werden sollen.Beispiel 2: Ein Benutzer hat die Möglichkeit, ein Benutzerkonto anzulegen und dort Informationen zu speichern, die er beim nächsten Lösen der Aufgabe nicht mehr manuell eingeben muss.
Die 7 Dialogprinzipien - Fazit
So viel zu merken ist es eigentlich gar nicht. Und wenn man die ersten 3 Prinzipien verinnerlicht hat und weiß, worauf es beim Entwickeln von Benutzungsschnittstellen ankommt, kann man das Fehlerpotential seiner interaktiven Systeme drastisch senken.
In diesem Sinne, viel Spaß beim Überarbeiten und Entschuldigung im Voraus für all die Verletzungen der Dialogprinzipien, die ihr nach dem Lesen dieses Beitrags wahrnehmen werdet.
Gruß, euer "devopsdad" Patrick

Hallo Welt!
Jetzt gab es eine ganze Weile lang keine neuen Inhalte hier aber inspiriert durch einen interessanten Thread im Fachinformatiker.de-Forum habe ich mich entschlossen, einen Beitrag zu einem allgemein gültigen Thema zu schreiben, das mir seit einer Weile sehr am Herzen liegt.
Den 7 Dialogprinzipien - Intro
Die 7 Dialogprinzipien, in ISO 9241-110 als "Grundsätze der Dialoggestaltung" beschrieben, beschreiben, wie Nutzer mit interaktiven Systemen interagieren und welche Prinzipien dieser Interaktion allgemein zu Grunde liegen.
Sie können positiv besetzt und erfüllt werden, oder verletzt. Werden sie verletzt, entstehen "Nutzungsfehler".

 Nicht so, Eierlegende Wollmilchsau, CC-BY-SA 2.5, Autor: Georg Mittendecker, Entnommen aus: https://commons.wikimedia.org/wiki/File:Wollmilchsau.jpg
Wichtig ist hier die feine Unterscheidung der Begrifflichkeiten. Ich spreche von "Nutzungsfehlern" nicht von "Nutzerfehlern". Interaktive Systeme, deren Benutzungsschnittstellen(User Interfaces) so gebaut sind, dass sie zum Nutzungskontext der angepeilten Benutzergruppe passen, sind wesentlich weniger fehleranfällig als Systeme, die versuchen, die eierlegende Wollmilchsau für "alle Benutzer jemals" zu sein. Eine nicht vollständige oder fehlerhafte Benutzergruppenanalyse ist einer der Hauptgründe für viele Usability-Probleme und unzufriedene Benutzer.
Aber genug Einführung. Hier kommen sie.
Die 7 Dialogprinzipien - Übersicht
Vorweg: Die Großzahl auftretender Nutzungsfehler entsteht aus Verletzungen der ersten 3 hier genannten Dialogprinzipien.
Zur Illustrierung der Dialogprinzipien halten wir uns an die folgende Aufgabe: "Einen Mietwagen buchen".
Aufgabenangemessenheit
Ein interaktives System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Arbeitsaufgabe zu erledigen, d. h., wenn Funktionalität und Dialog auf den charakteristischen Eigenschaften der Arbeitsaufgabe basieren, anstatt auf der zur Aufgabenerledigung eingesetzten Technologie. Es kommen keine unnötigen oder nicht zur Lösung der Aufgabe benötigten Schritte vor.

Standort-Buchung hertz.de, Screenshot, aufgenommen am 13.07.2017
Beispiel: Wenn ich bei hertz.de als Standort "Kassel" auswähle, kann ich die Standortgruppe "Kassel DE (4 locations)" anwählen. Erst wenn ich alle anderen Eingaben getätigt habe und im Formular weitergehen möchte, muss ich einen spezifischen Standort auswählen. Ein unnötiger Schritt, den man direkt im ersten Formular bearbeiten können sollte.
 
Selbstbeschreibungsfähigkeit
Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit offensichtlich ist, in welchem Dialog, an welcher Stelle im Dialog er sich befindet, welche Handlungen unternommen werden können und wie diese ausgeführt werden können.
Beispiel: In einem weißen Suchfeld zur Fahrzeugsuche steht neben einer Lupe der Text "Hier können Sie durch Texteingabe Fahrzeugtypen suchen"
Erwartungskonformität
Ein Dialog ist erwartungskonform, wenn er den aus dem Nutzungskontext heraus vorhersehbaren Benutzerbelangen sowie allgemein anerkannten Konventionen entspricht.
Beispiel: Ein Klick auf ein kleines Kalender-Icon in einem Auswahlbereich zur Abholung des Fahrzeugs öffnet ein Datepicker-Steuerelement.
Erlernbarkeit / Lernförderlichkeit
Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen der Nutzung des interaktiven Systems unterstützt und anleitet.
Beispiel: Wenn erkannt wird, dass der Benutzer die Webseite zum ersten mal besucht, wird er durch ein Assistenzprogramm und verschiedene Highlights durch den Buchungsprozess geleitet. (Abdunkeln von zum momentanen Zeitpunkt nicht benötigten Steuerelementen) 
Steuerbarkeit
Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.
Negativbeispiel: Eine fehlerhafte Eingabe in einem Kontaktformular führt dazu, dass der Nutzer das gesamte Formular erneut ausfüllen muss, anstatt an den Punkt zu springen, in dem die Falscheingabe liegt.
Fehlertoleranz
Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann.
Beispiel 1: Der Benutzer gibt im Texteingabefeld das Datum "23.12.2017" ein. Das System gibt einen Fehler aus und weist ihn darauf hin, dass das Datumsformat dem folgenden Schema genügen muss. "MM-DD-YYYY". Noch besser wäre hier allerdings, statt einer Benutzereingabe eine Auswahl durch z.B. ein Datepicker-Element zu ermöglichen.Beispiel 2: Der Benutzer gibt eine E-Mail Adresse im falschen Format  an und erhält eine Fehlermeldung, die als Beispiel ein korrektes Format anzeigt.
Individualisierbarkeit
Ein Dialog ist individualisierbar, wenn Benutzer die Mensch-System-Interaktion und die Darstellung von Informationen ändern können, um diese an ihre individuellen Fähigkeiten und Bedürfnisse anzupassen.
Beispiel 1: Ein Benutzer kann dauerhaft speichern, in welchem Format Zahlen und in welcher Sprache Texte in einer Anwendung dargestellt werden sollen.Beispiel 2: Ein Benutzer hat die Möglichkeit, ein Benutzerkonto anzulegen und dort Informationen zu speichern, die er beim nächsten Lösen der Aufgabe nicht mehr manuell eingeben muss.
Die 7 Dialogprinzipien - Fazit
So viel zu merken ist es eigentlich gar nicht. Und wenn man die ersten 3 Prinzipien verinnerlicht hat und weiß, worauf es beim Entwickeln von Benutzungsschnittstellen ankommt, kann man das Fehlerpotential seiner interaktiven Systeme drastisch senken.
In diesem Sinne, viel Spaß beim Überarbeiten und Entschuldigung im Voraus für all die Verletzungen der Dialogprinzipien, die ihr nach dem Lesen dieses Beitrags wahrnehmen werdet.
Gruß, euer "devopsdad" Patrick

Hallo Welt!
Jetzt gab es eine ganze Weile lang keine neuen Inhalte hier aber inspiriert durch einen interessanten Thread im Fachinformatiker.de-Forum habe ich mich entschlossen, einen Beitrag zu einem allgemein gültigen Thema zu schreiben, das mir seit einer Weile sehr am Herzen liegt.
Den 7 Dialogprinzipien - Intro
Die 7 Dialogprinzipien, in ISO 9241-110 als "Grundsätze der Dialoggestaltung" beschrieben, beschreiben, wie Nutzer mit interaktiven Systemen interagieren und welche Prinzipien dieser Interaktion allgemein zu Grunde liegen.
Sie können positiv besetzt und erfüllt werden, oder verletzt. Werden sie verletzt, entstehen "Nutzungsfehler".

 Nicht so, Eierlegende Wollmilchsau, CC-BY-SA 2.5, Autor: Georg Mittendecker, Entnommen aus: https://commons.wikimedia.org/wiki/File:Wollmilchsau.jpg
Wichtig ist hier die feine Unterscheidung der Begrifflichkeiten. Ich spreche von "Nutzungsfehlern" nicht von "Nutzerfehlern". Interaktive Systeme, deren Benutzungsschnittstellen(User Interfaces) so gebaut sind, dass sie zum Nutzungskontext der angepeilten Benutzergruppe passen, sind wesentlich weniger fehleranfällig als Systeme, die versuchen, die eierlegende Wollmilchsau für "alle Benutzer jemals" zu sein. Eine nicht vollständige oder fehlerhafte Benutzergruppenanalyse ist einer der Hauptgründe für viele Usability-Probleme und unzufriedene Benutzer.
Aber genug Einführung. Hier kommen sie.
Die 7 Dialogprinzipien - Übersicht
Vorweg: Die Großzahl auftretender Nutzungsfehler entsteht aus Verletzungen der ersten 3 hier genannten Dialogprinzipien.
Zur Illustrierung der Dialogprinzipien halten wir uns an die folgende Aufgabe: "Einen Mietwagen buchen".
Aufgabenangemessenheit
Ein interaktives System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Arbeitsaufgabe zu erledigen, d. h., wenn Funktionalität und Dialog auf den charakteristischen Eigenschaften der Arbeitsaufgabe basieren, anstatt auf der zur Aufgabenerledigung eingesetzten Technologie. Es kommen keine unnötigen oder nicht zur Lösung der Aufgabe benötigten Schritte vor.

Standort-Buchung hertz.de, Screenshot, aufgenommen am 13.07.2017
Beispiel: Wenn ich bei hertz.de als Standort "Kassel" auswähle, kann ich die Standortgruppe "Kassel DE (4 locations)" anwählen. Erst wenn ich alle anderen Eingaben getätigt habe und im Formular weitergehen möchte, muss ich einen spezifischen Standort auswählen. Ein unnötiger Schritt, den man direkt im ersten Formular bearbeiten können sollte.
 
Selbstbeschreibungsfähigkeit
Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit offensichtlich ist, in welchem Dialog, an welcher Stelle im Dialog er sich befindet, welche Handlungen unternommen werden können und wie diese ausgeführt werden können.
Beispiel: In einem weißen Suchfeld zur Fahrzeugsuche steht neben einer Lupe der Text "Hier können Sie durch Texteingabe Fahrzeugtypen suchen"
Erwartungskonformität
Ein Dialog ist erwartungskonform, wenn er den aus dem Nutzungskontext heraus vorhersehbaren Benutzerbelangen sowie allgemein anerkannten Konventionen entspricht.
Beispiel: Ein Klick auf ein kleines Kalender-Icon in einem Auswahlbereich zur Abholung des Fahrzeugs öffnet ein Datepicker-Steuerelement.
Erlernbarkeit / Lernförderlichkeit
Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen der Nutzung des interaktiven Systems unterstützt und anleitet.
Beispiel: Wenn erkannt wird, dass der Benutzer die Webseite zum ersten mal besucht, wird er durch ein Assistenzprogramm und verschiedene Highlights durch den Buchungsprozess geleitet. (Abdunkeln von zum momentanen Zeitpunkt nicht benötigten Steuerelementen) 
Steuerbarkeit
Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.
Negativbeispiel: Eine fehlerhafte Eingabe in einem Kontaktformular führt dazu, dass der Nutzer das gesamte Formular erneut ausfüllen muss, anstatt an den Punkt zu springen, in dem die Falscheingabe liegt.
Fehlertoleranz
Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann.
Beispiel 1: Der Benutzer gibt im Texteingabefeld das Datum "23.12.2017" ein. Das System gibt einen Fehler aus und weist ihn darauf hin, dass das Datumsformat dem folgenden Schema genügen muss. "MM-DD-YYYY". Noch besser wäre hier allerdings, statt einer Benutzereingabe eine Auswahl durch z.B. ein Datepicker-Element zu ermöglichen.Beispiel 2: Der Benutzer gibt eine E-Mail Adresse im falschen Format  an und erhält eine Fehlermeldung, die als Beispiel ein korrektes Format anzeigt.
Individualisierbarkeit
Ein Dialog ist individualisierbar, wenn Benutzer die Mensch-System-Interaktion und die Darstellung von Informationen ändern können, um diese an ihre individuellen Fähigkeiten und Bedürfnisse anzupassen.
Beispiel 1: Ein Benutzer kann dauerhaft speichern, in welchem Format Zahlen und in welcher Sprache Texte in einer Anwendung dargestellt werden sollen.Beispiel 2: Ein Benutzer hat die Möglichkeit, ein Benutzerkonto anzulegen und dort Informationen zu speichern, die er beim nächsten Lösen der Aufgabe nicht mehr manuell eingeben muss.
Die 7 Dialogprinzipien - Fazit
So viel zu merken ist es eigentlich gar nicht. Und wenn man die ersten 3 Prinzipien verinnerlicht hat und weiß, worauf es beim Entwickeln von Benutzungsschnittstellen ankommt, kann man das Fehlerpotential seiner interaktiven Systeme drastisch senken.
In diesem Sinne, viel Spaß beim Überarbeiten und Entschuldigung im Voraus für all die Verletzungen der Dialogprinzipien, die ihr nach dem Lesen dieses Beitrags wahrnehmen werdet.
Gruß, euer "devopsdad" Patrick

Hallo zusammen,
um den Fachinformatiker-Blog mit etwas mehr Leben zu füllen, würde ich gerne wissen, welche Themen euch interessieren.
Womit können wir euch am besten helfen? Eher technische Themen oder Tipps zur Prüfungsvorbereitung? Lieber Projektdokumentation oder Fachgespräch? Besser Blog-Beiträge oder Podcast-Episoden? Oder, oder, oder...
Ich freue mich über euer Feedback! Schreibt mir gerne eure Wunschthemen oder Vorschläge für deren Gestaltung! Und auch Kritik an den bisherigen Blog- und Podcastinhalten nehme ich gerne an. Dadurch könnten wir im nächsten Jahr diese Seite mit noch mehr relevanten Inhalten für alle Azubis und Prüflinge da draußen füllen.
Viele Grüße!
Stefan

Freunde, Bürger, Member,
mit den Worten Shakespeares, leicht gewandelt,  will ich den 1. Teil meines Blogs einläuten: Das berufsbegleitende Studium an der FOM (Hochschule für Ökonomie und Management). Aber wie bin ich überhaupt auf die FOM gekommen? Naja, direkt am Anfang war mir eins klar. Ich bin ein geldgeiler Sack, der niemals aus seinem Job in ein ärmliches Studentenleben wechseln könnte. Also war vom ersten Moment an klar, dass ich nur berufsbegleitend studieren würde. Außerdem besteht bei mir auch ein gesunder Selbstzweifel, der dafür gesorgt hat, dass ich nicht den Job aufgebe, um dann eventuell an der Last eines Studiums zu scheiten. Wer will schön diese allseits bekannte und berüchtigte Lücke im Lebenslauf erklären müssen?
Was bietet die FOM?
Ganz einfach, für den monatlichen Beitrag von 360€ (abhängig vom Studiengang) bekommt man eine ziemlich intensive Betreuung. Man sitzt nicht in einem engen Hörsaal, der viel zu warm für 350 Studenten ist, sondern mit 22 Mann in einem Klassenraum, der klimatisiert ist. Für einen Feind der warmen Räume wie mich also perfekt! Die Dozenten rattern ihr Skript nicht einfach durch, sondern weisen darauf hin, dass Zwischenfragen nicht erlaubt, sondern erwünscht sind. Wenn's also mal hängt, dann kann man einfach fragen, der Dozent oder Professor nimmt sich gerne die Zeit. Die Räumlichkeiten sind äußerst modern, so zumindest am Standort Bonn. Jeder Hörsaal verfügt über einen Beamer, einen Großbild-Fernseher für die hinteren Reihen und einen Overhead-Projektor, sodass der Dozent auch bequem von seinem Platz aus mal eine Rechnung außerhalb des Skripts erklären kann. Das Team der FOM ist, zumindest in den vier bisherigen Modulen, jung(-geblieben), motiviert und breit aufgestellt. Bisher sind es nämlich nicht die reinen Theoretiker, die alles besser wissen, sondern gestandene Menschen der Praxis, die lange in ihren Berufen gearbeitet haben, somit also ein beträchtliches Wissen einstreuen können.
Die Kommilidingsbums
Wie jeder Studiengang, steht und fällt das Ganze mit denen, die vor, hinter oder neben einem selbst sitzen. Die Kommilitonen sind ja quasi die Mitschüler, die das gleiche Ziel verfolgen wie man selbst. Da kann ich nur sagen: Wer berufsbegleitend studiert, der weiß ganz genau was er will. Keiner der 22 Männer und Frauen, die sich für Wirtschaftsinformatik eingeschrieben hat, wankte nur eine Sekunde als er/sie gefragt wurde, warum er/sie denn studieren wolle. Hätte mich auch gewundert, bei 360€ die nicht in allen Fällen der Betrieb trägt, überlegt man sich ja mehr als nur einmal was man dort beginnt.
Gibt’s schon was Negatives?
Ja, wo Licht ist, da ist auch Schatten, wenn auch nur ein kleiner. Bei einem solchen Betrag, da erwartet man schon dass man sein Auto nicht für 1,50€ die Stunde im Parkhaus abstellen muss, sondern ein paar reservierte Plätze für die zahlungswilligen Kunden. Hab ich Kunden gesagt? Ich meine natürlich Studenten… :P. Naja, am zweiten Tag wurde uns dann das Rabattier-Gerät vorgestellt, mein neuer bester Freund, der mir das Ticket auf 50 Cent die Stunde heruntersetzt. Also ist das auch nicht mehr ganz so schlimm.
Fazit - ohne geht's ja heute nicht mehr
Ich bin bisher wirklich zufrieden mit dem Modell der FOM. Auch wenn es teilweise hart ist, Samstagnachmittag noch 4 Stunden Mathe zu machen, während man sich am Morgen durch die Theorie der Wirtschaftsinformatik gequält hat. Dennoch: Ich bin froh, dass ich den Schritt gewagt habe, denn ich habe schon viele neue Menschen kennen gelernt, die alle samt ehrgeizig, zielstrebig und freundlich sind.
In der nächsten Episode beschreibe ich dann das Modul „Management Basics“. Und entschuldigt dass ich keine Bilder eingepflegt habe, der Text-Editor und ich sind momentan noch keine Freunde, aber ich habe ihm die Friedenspfeife angeboten. :-) Aber immerhin konnte ich euch unten die Links zu meiner FH und dem Studiengang da lassen, ist ja schon ein Anfang, oder?
Es grüßt euch
SebastianB.
Hauptseite der FOM
Studiengang Wirtschaftsinformatik

Hallo liebe FI-Member,
bevor ich mich hier vorstellen möchte, ein großes Dankeschön an das Blogger-Team, für die Aufnahme in euren Kreis. Nun aber zu dem, was der Titel verspricht. Mein Name ist Sebastian, ich bin 24 Jahre jung, komme aus der Nähe von Koblenz, genauer gesagt einem Randgebiet des wunderschönen Westerwaldes. Ich habe die Ausbildung zum Fachinformatiker - AE im Jahr 2012 beendet und bin seither auch in dieser Sparte tätig. Privat bin ich ein begeisterter Läufer, spiele Fußball und genieße die Zeit die mir auf unserer Erde gegeben ist. Ich möchte euch hier einen kleinen Einblick in das geben, was ich mir für die kommenden Jahre vorgenommen habe.
Wie ein jeder sicher schon selbst an sich erfahren hat, gibt es einen Zeitraum nach der Ausbildung, in dem man "satt" ist. Prüfung geschafft, jetzt nie mehr lernen, nur noch Kohle verdienen und das Leben genießen! Da war ich keine Ausnahme, ich hab mir am Tag der mündlichen geschworen, das war es jetzt. Endlich Freizeit, kein Lerndruck mehr, nie mehr in Noten an Themen gemessen werden, die mich mal so gar nicht interessieren. Und das Ganze hielt erstmal an, für genau zwei Jahre. Dann kam etwas in mir hervor, was ich so noch nicht kannte. Ich fühlte mich irgendwie leer, der einzige Antrieb den ich hatte war das Geld, das große Ziel immer nur der nächste Urlaub. Woran hat das gelegen? Ganz einfach: Ein Schiff ohne Ziel braucht auch keinen Antrieb...
 
 
„Stillstand ist Rückschritt.“
 
Rudolf von Bennigsen-Foerder (1926-89), dt. Topmanager, Vorstandsvors. Veba AG
 
 
Als ich dann bei Twitter über den oben stehenden Spruch gestolpert bin, dann wurde es mir klar, hier muss noch was kommen! Und mein Ziel war schneller gefunden als ich dachte. Über verschiedene Gespräche habe ich mir immer wieder Gedanken gemacht, was ich denn an Weiterbildungen anstreben könnte. Doch eigentlich gab es für mich nur eins, was mich wirklich reizen konnte. Das Studium - Wirtschaftsinformatik sollte es sein.

Damit das nicht gleich scheitert, habe ich mir viele Gedanken gemacht, wie ich mich sinnvoll darauf vorbereiten kann. Ohne Hochschulreife studieren, das war mir zu riskant, auch wenn’s der Abschluss hergegeben hätte. Also dann, zwei Jahre Abends die Schulbank drücken, das war nicht unbedingt einfach, vor allem wenn die Tage sich dann noch mit dem Fußball schnitten, aber naja, was man beginnt, soll man auch zu Ende bringen... Zwischendurch musste dann noch der AdA-Schein her und ich bekam zwei Azubis ins Team. Im Frühjahr erhielt ich dann meine Hochschulreife und es konnte endlich starten, die große Aufgabe, welche mich nun die nächsten 3 1/2 Jahre begleiten sollte. An der FOM in Bonn schrieb ich mich für Wirtschaftsinformatik ein, für das Modell am Freitagabend und Samstag. So, das nun zu meinem Vorhaben. Ich glaube viele stehen vor einem ähnlichen Problem wie ich es tat, daher hoffe ich euch in meinem Blog einen Einblick in das Leben eines dualen Studenten zu geben.
In diesem Semester behandeln wir die Module
Wirtschaftsinformatik Basics Management Basics Mathematik für Wirtschaftsinformatiker Konzepte der prozeduralen Programmierung Ich werde versuchen, zu jedem dieser Module einen entsprechenden Blog-Eintrag zu veröffentlichen, aber ich kann euch eins sagen: Zeit hat man als dualer Student nicht besonders viel... Dennoch werde ich versuchen, euch immer auf dem Laufenden zu halten, sodass ich vielleicht dem ein oder anderen bei der Entscheidung zum Thema Weiterbildung helfen kann.
Es grüßt euch
Sebastian B.
 
 

Hallo Welt!
In einer Zeit, in der eine unüberschaubare Menge an Informationen im Internet verfügbar und jederzeit abrufbar ist, verlieren Bücher oft zunehmend an Stellenwert. Ich sehe das anders. Ich mag Bücher, momentan besonders Fachbücher zum Thema Organisationsentwicklung und "Umgang mit Dynamik".
Komplexithoden, Organisation für Komplexität und das titelgebende "Denkwerkzeuge der Höchstleister", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Meinen Liebling aus dieser Kategorie möchte ich euch heute vorstellen. Hierbei handelt es sich um die "Denkwerkzeuge der Höchstleister" von Gerhard Wohland und Matthias Wiemeyer mit dem bedeutungsschwangeren Untertitel "Warum dynamikrobuste Unternehmen Marktdruck erzeugen"; vorliegend in der dritten Auflage, 2012 erschienen im Unibuch Verlag.
Vorweg: Das Buch ist kein Buch, das man einfach nur liest und dann weglegt. Es ist ein Arbeitsbuch, das man immer wieder aufschlägt, darin nachliest, stöbert und studiert, um sich immer und immer wieder teils ungläubig von den plakativ klingenden aber so einleuchtenden Thesen zu überzeugen. Ich habe es förmlich verschlungen, es bereitet mir heute teilweise noch schlaflose Nächte.
Aber genug gewarnt, jetzt wird angefixt! Worum geht es bei den "Denkwerkzeugen der Höchstleister"?
Inhalt
Beschrieben werden im Buch Ansätze, die sogenannten "Denkwerkzeuge", die dienlich sein können, um Dynamik und Systeme besser verstehen zu können und mit Ihnen umzugehen. Das ganze idealerweise ohne daran zu verzweifeln oder wirtschaftlich daran zu Grunde zu gehen. Es bietet Impulse und Ansätze, die man in der eigenen Organisation unter Einbeziehung der eigenen Umgebung und der Fakten nutzen kann, um eine für sich funktionierende Lösung für verschiedene Probleme zu finden. Das ganze vor einem einfachen, nachvollziehbaren, geschichtlichen und wirtschaftlichen Hintergrund. Wieso sind die Märkte heute, wie sie sind; wieso können Unternehmen, die flexibel und agil aufgestellt sind, besser mit den engeren Märkten der Globalisierung umgehen als klassische, hierarchisch aufgebaute Konzerne, und wieso passen viele Management-Instrumente aus der klassischen BWL nicht mehr zu heutigen Anforderungen? Für all diese Fragen und mehr findet der Leser hier plausible Theorien, die als Erklärung dienen.
"Es gibt nichts Praktischeres als eine gute Theorie" - Kurt Lewin Auf keinen Fall werden hier aber "Best Practices" angeboten, die man in seinem Unternehmen umsetzt, auf einmal geschieht ein Wunder und der Umsatz steigt wie von Zauberhand in einem Jahr um 150%. So etwas gibt es nicht, bzw. wenn es funktioniert passten glücklicherweise viele Parameter beim Anwenden des Denkwerkzeugs. Unternehmen sind bedingt durch die verschiedenen Typen von Menschen, die in ihnen arbeiten, hochkomplexe Systeme, die keinen "Wenn > Dann"-Mustern folgen. Man kann vielleicht vermuten, welche Wirkung eine Maßnahme hat, sicher sein kann man sich jedoch nie.
Und das ist auch völlig in Ordnung so. Komplexität und Dynamik sind weder schlecht noch gut. Sie sind einfach da. Wie das Wetter.
Schlecht ist nur, darauf als Organisation nicht vorbereitet zu sein und dann nicht reagieren zu können. Denn dann steht man im Zweifel ohne Schirm und Jacke "im Regen".
Aufbau
Ein Hauptteil des Buches ist der Glossar, auf dem die präzisen Begriffe, die in diesem(sytemtheoretischen) Kontext genutzt werden, erläutert und eingeordnet werden. Dem voran gehen ein Vorab-Bereich in dem der Aufbau im Detail erläutert wird und 13 kurze, 10 Seiten nicht übersteigende Kapitel, die klassische Management-Thesen im Kontext moderner, dynamischer Märkte beleuchten. In diesen Kapiteln gibt es zusätzlich zu den im Fließtext sehr anschaulich formulierten Thesen und Vergleichen die sogenannten "Denkzettel". Diese beschreiben ein Problem und geben einen Hinweis, in welche Richtung man sich bewegen kann, um eine mögliche Lösung im eigenen Unternehmenskontext zu finden.
Denkzettel "Zentrum und Peripherie" samt Kapitelresümee "Taylorismus - Aufstieg und Fall einer genialen Idee", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Das klingt erstmal recht kompliziert, wenn man jedoch begriffen hat, dass man das Buch weder am Stück noch in der geschriebenen Reihenfolge lesen muss, sondern es immer und immer wieder als Nachschlagewerk und Referenz nutzen kann, passt dieses gut sortierte Format ganz hervorragend.
Die Denkzettel sind ein großartiger Einstieg, um sich mit der Systemtheorie und den Denkwerkzeugen auseinanderzusetzen, wenn man in diesem Umfeld noch völlig unbedarft ist. Wer in die Tiefe gehen will, liest einfach die umspannenden Kapitel.
Zielgruppe und Fazit
Das Buch ist für alle geeignet, die das Gefühl haben, Projekte in ihrer Organisation laufen "irgendwie schlecht", verfehlen oft das Ziel, Kunden und Mitarbeiter sind unzufrieden, die Konkurrenz überholt uns ständig, Sarkasmus ist an des Tagesordnung, es gibt "zu viele Meetings"; aber keiner weiß so richtig wieso, etc.
Das Buch ist definitiv nicht für Menschen geeignet, die sich eine schnelle Lösung per "Best Practice" erhoffen und der Meinung sind, man könnte per steuernder Direktive "von oben" Dinge wie Unternehmens- und Wertekultur der Mitarbeiter ändern oder steuern. Das dies nicht funktioniert, machen die Autoren immer wieder mit vielen Beispielen zum Thema "Kultur" und "Steuerung" im Unternehmen klar.
Mir selbst hat das Buch viele Ansätze und Handlungsräume eröffnet, die mir helfen zu verstehen, wieso im Beruf so oft so viel "Theater" um Probleme gemacht wird, die eigentlich mit dem berühmt-berüchtigten "gesunden Menschenverstand" einfach zu beheben sein sollten.
Ich nutze es regelmäßig und gehe schon fast missionarartig damit hausieren, weil ich es schlicht und einfach großartig und unendlich wertvoll finde.
Ganz akut Interessierten aus der Umgebung kann ich mein Exemplar zum Reinschnuppern gerne auch Ausleihen. Für alle anderen gibt es in der Linksektion noch mehr Futter. Viel Spaß beim Stöbern!
Euer "devopsdad" Patrick aka Goulasz
Weiterführende Links zum Thema
Hier gibt es die Denkzettel im PDF-Format: Denkzettel bei dynamikrobust.com Hier der Link zum Buch bei Amazon: Denkwerkzeuge der Höchstleister Intrinsify.me-Netzwerk zum Thema "Moderne Unternehmensführung" und "Sinnkopplung im Job": Intrinsify.me Wikipedia-Artikel zur Systemtheorie zum Warmwerden und Einlesen: Systemtheorie

Hallo Welt!
In einer Zeit, in der eine unüberschaubare Menge an Informationen im Internet verfügbar und jederzeit abrufbar ist, verlieren Bücher oft zunehmend an Stellenwert. Ich sehe das anders. Ich mag Bücher, momentan besonders Fachbücher zum Thema Organisationsentwicklung und "Umgang mit Dynamik".
Komplexithoden, Organisation für Komplexität und das titelgebende "Denkwerkzeuge der Höchstleister", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Meinen Liebling aus dieser Kategorie möchte ich euch heute vorstellen. Hierbei handelt es sich um die "Denkwerkzeuge der Höchstleister" von Gerhard Wohland und Matthias Wiemeyer mit dem bedeutungsschwangeren Untertitel "Warum dynamikrobuste Unternehmen Marktdruck erzeugen"; vorliegend in der dritten Auflage, 2012 erschienen im Unibuch Verlag.
Vorweg: Das Buch ist kein Buch, das man einfach nur liest und dann weglegt. Es ist ein Arbeitsbuch, das man immer wieder aufschlägt, darin nachliest, stöbert und studiert, um sich immer und immer wieder teils ungläubig von den plakativ klingenden aber so einleuchtenden Thesen zu überzeugen. Ich habe es förmlich verschlungen, es bereitet mir heute teilweise noch schlaflose Nächte.
Aber genug gewarnt, jetzt wird angefixt! Worum geht es bei den "Denkwerkzeugen der Höchstleister"?
Inhalt
Beschrieben werden im Buch Ansätze, die sogenannten "Denkwerkzeuge", die dienlich sein können, um Dynamik und Systeme besser verstehen zu können und mit Ihnen umzugehen. Das ganze idealerweise ohne daran zu verzweifeln oder wirtschaftlich daran zu Grunde zu gehen. Es bietet Impulse und Ansätze, die man in der eigenen Organisation unter Einbeziehung der eigenen Umgebung und der Fakten nutzen kann, um eine für sich funktionierende Lösung für verschiedene Probleme zu finden. Das ganze vor einem einfachen, nachvollziehbaren, geschichtlichen und wirtschaftlichen Hintergrund. Wieso sind die Märkte heute, wie sie sind; wieso können Unternehmen, die flexibel und agil aufgestellt sind, besser mit den engeren Märkten der Globalisierung umgehen als klassische, hierarchisch aufgebaute Konzerne, und wieso passen viele Management-Instrumente aus der klassischen BWL nicht mehr zu heutigen Anforderungen? Für all diese Fragen und mehr findet der Leser hier plausible Theorien, die als Erklärung dienen.
"Es gibt nichts Praktischeres als eine gute Theorie" - Kurt Lewin Auf keinen Fall werden hier aber "Best Practices" angeboten, die man in seinem Unternehmen umsetzt, auf einmal geschieht ein Wunder und der Umsatz steigt wie von Zauberhand in einem Jahr um 150%. So etwas gibt es nicht, bzw. wenn es funktioniert passten glücklicherweise viele Parameter beim Anwenden des Denkwerkzeugs. Unternehmen sind bedingt durch die verschiedenen Typen von Menschen, die in ihnen arbeiten, hochkomplexe Systeme, die keinen "Wenn > Dann"-Mustern folgen. Man kann vielleicht vermuten, welche Wirkung eine Maßnahme hat, sicher sein kann man sich jedoch nie.
Und das ist auch völlig in Ordnung so. Komplexität und Dynamik sind weder schlecht noch gut. Sie sind einfach da. Wie das Wetter.
Schlecht ist nur, darauf als Organisation nicht vorbereitet zu sein und dann nicht reagieren zu können. Denn dann steht man im Zweifel ohne Schirm und Jacke "im Regen".
Aufbau
Ein Hauptteil des Buches ist der Glossar, auf dem die präzisen Begriffe, die in diesem(sytemtheoretischen) Kontext genutzt werden, erläutert und eingeordnet werden. Dem voran gehen ein Vorab-Bereich in dem der Aufbau im Detail erläutert wird und 13 kurze, 10 Seiten nicht übersteigende Kapitel, die klassische Management-Thesen im Kontext moderner, dynamischer Märkte beleuchten. In diesen Kapiteln gibt es zusätzlich zu den im Fließtext sehr anschaulich formulierten Thesen und Vergleichen die sogenannten "Denkzettel". Diese beschreiben ein Problem und geben einen Hinweis, in welche Richtung man sich bewegen kann, um eine mögliche Lösung im eigenen Unternehmenskontext zu finden.
Denkzettel "Zentrum und Peripherie" samt Kapitelresümee "Taylorismus - Aufstieg und Fall einer genialen Idee", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Das klingt erstmal recht kompliziert, wenn man jedoch begriffen hat, dass man das Buch weder am Stück noch in der geschriebenen Reihenfolge lesen muss, sondern es immer und immer wieder als Nachschlagewerk und Referenz nutzen kann, passt dieses gut sortierte Format ganz hervorragend.
Die Denkzettel sind ein großartiger Einstieg, um sich mit der Systemtheorie und den Denkwerkzeugen auseinanderzusetzen, wenn man in diesem Umfeld noch völlig unbedarft ist. Wer in die Tiefe gehen will, liest einfach die umspannenden Kapitel.
Zielgruppe und Fazit
Das Buch ist für alle geeignet, die das Gefühl haben, Projekte in ihrer Organisation laufen "irgendwie schlecht", verfehlen oft das Ziel, Kunden und Mitarbeiter sind unzufrieden, die Konkurrenz überholt uns ständig, Sarkasmus ist an des Tagesordnung, es gibt "zu viele Meetings"; aber keiner weiß so richtig wieso, etc.
Das Buch ist definitiv nicht für Menschen geeignet, die sich eine schnelle Lösung per "Best Practice" erhoffen und der Meinung sind, man könnte per steuernder Direktive "von oben" Dinge wie Unternehmens- und Wertekultur der Mitarbeiter ändern oder steuern. Das dies nicht funktioniert, machen die Autoren immer wieder mit vielen Beispielen zum Thema "Kultur" und "Steuerung" im Unternehmen klar.
Mir selbst hat das Buch viele Ansätze und Handlungsräume eröffnet, die mir helfen zu verstehen, wieso im Beruf so oft so viel "Theater" um Probleme gemacht wird, die eigentlich mit dem berühmt-berüchtigten "gesunden Menschenverstand" einfach zu beheben sein sollten.
Ich nutze es regelmäßig und gehe schon fast missionarartig damit hausieren, weil ich es schlicht und einfach großartig und unendlich wertvoll finde.
Ganz akut Interessierten aus der Umgebung kann ich mein Exemplar zum Reinschnuppern gerne auch Ausleihen. Für alle anderen gibt es in der Linksektion noch mehr Futter. Viel Spaß beim Stöbern!
Euer "devopsdad" Patrick aka Goulasz
Weiterführende Links zum Thema
Hier gibt es die Denkzettel im PDF-Format: Denkzettel bei dynamikrobust.com Hier der Link zum Buch bei Amazon: Denkwerkzeuge der Höchstleister Intrinsify.me-Netzwerk zum Thema "Moderne Unternehmensführung" und "Sinnkopplung im Job": Intrinsify.me Wikipedia-Artikel zur Systemtheorie zum Warmwerden und Einlesen: Systemtheorie

Hallo zusammen,
aktuell laufen die Vorbereitungen auf die mündlichen Prüfungen 2016 (Projektpräsentation und Fachgespräch) auf Hochtouren. Daher dachte ich, es wäre vielleicht hilfreich, ein paar allgemeine Tipps bzgl. der Vorbereitung zu geben und habe die zweite Episode des Podcasts von fachinformatiker.de aufgenommen.
FI-Podcast_002_Vorbereitung_muendliche_Pruefung.mp3 (Länge ca. 25 Minuten, für Play/Pause einfach den Link anklicken)
Vorbereitung auf die Projektpräsentation
Zeige nur die Highlights deines Projekts. Orientiere dich am Ablauf der Projektarbeit (Phasen, Prozessmodell). Verwende so wenig Text wie möglich und nutze stattdessen Grafiken. Üben, üben, üben: Mit Ausbilder/in, Kollegen, Freund/in, Eltern. Ist der Aufbau nachvollziehbar und sinnvoll? Ist das Foliendesign ansprechend? Sind alle Folieninhalte klar erkennbar und lesbar? Wird die Zeit eingehalten? Ist der fachliche Inhalt korrekt? Feedback einholen zu: Augenkontakt mit dem Publikum, Körpersprache, deutliche Sprache, Gestik, Mimik usw. Vorbereitung auf das Fachgespräch
Sind alle verwendeten Begriffe aus der Projektpräsentation klar (und zwar nicht nur scheinbar)? Die üblichen Verdächtigen durchgehen (am besten mit Ausbilder/in). Objektorientierung (FIAE) Datenbanken Netzwerkgrundlagen (FISI) Stundensatz Praxisbeispiele für häufige Fragen bereitlegen (z.B. Vererbung in der Objektorientierung oder IP-Adressbereiche für Subnetting). Fragen der Prüfer wie ein Wasserfall beantworten ohne nötige Rückfragen. Ich hoffe, es sind einige interessante Inhalte für euch dabei. Für weitere Tipps und Anregungen bin ich immer offen. Hinterlasst einfach einen Kommentar!
Viele Grüße!
Stefan
PS: Noch mehr Tipps zur konkreten Gestaltung der Projektpräsentation gibt es in der aktuellen Episode des Anwendungsentwickler-Podcasts: Ansprechende Gestaltung der Projektpräsentation.

Hallo Welt!
Ein unfassbar anstrengendes, aber inspirierendes und motivierendes Wochenende liegt hinter mir. Nachdem mich ein sehr geschätzter Kollege bei einer firmeninternen Vorstellung des "Augenhöhe"-Films und des Projekts im Frühjahr 2014 sehr mit der ganzen "New Work, Systemtheorie, Sinnkopplung im Job"-Materie angefixt hatte, fasste ich den Entschluss, mich damit stärker zu befassen.

Seit Montag bin ich jetzt Mitglied dieses Netzwerks, das sich "intrinsify.me" nennt, und ich möchte diesen Blogpost nutzen, um euch gleichermaßen das Netzwerk und das "Wevent" vom Wochenende vorzustellen. Der Post fällt daher etwas länger aus als gewohnt, aber ich kann mich hier nicht kürzer fassen, ohne den Kern der Sache ordentlich zu beschreiben.
happy working people - Das Netzwerk
Das intrinsify.me-Netzwerk, welches seit 2011 besteht, hat es sich zur Aufgabe gemacht, eine Austausch- und Vernetzungsplattform für Menschen anzubieten, die sich mit den Themen "Sinnkopplung im Job" und vielen anderen, die sich dem Buzzword "New Work" zuschreiben lassen, beschäftigen. Gegründet wurde es von Mark Poppenborg und Lars Vollmer ursprünglich als Beratungsunternehmen. Im Laufe der Zeit hat sich dieser Zweck jedoch hin zu der jetzt so existierenden Austauschplattform gewandelt, die natürlich auch noch Beratungs- und Schulungsleistungen anbietet.
Dabei gilt stets die Annahme, dass ein erfolgreiches Unternehmen nicht aufgrund seiner Kultur erfolgreich ist und die Kollegen deswegen gut zusammenarbeiten, sondern die Kultur eine Begleiterscheinung des Erfolgs ist. Eine Firma, die durch Freiräume eine "gesunde", auf echtem Vertrauen basierte Kultur ermöglicht, wird in aller Regel nicht oder weniger mit "unter den Tisch gekehrten" Problemen zu tun haben. "Die haben so eine gute Kultur bei Google, deswegen sind die so erfolgreich." ist nach dieser Auffassung nämlich ein Trugschluss. Ich skizziere mal ein Beispiel:
Fall 1:
Das Unternehmen "BuzzwordSoft", eine aus einem 250.000 Mitarbeiter starken Konzern ausgegliederte Tochtergesellschaft, hat zuletzt eine hohe Rate an Fehlern und Reklamationen im Produktivsystem ihrer Datenbewirtschaftungssoftware festgestellt. Ein besonders kritischer Fehler führte dazu, dass ein Kunde sich beschwerte und mit Kündigung des Systems drohte. Während der Analyse fällt auf, dass aufgrund von akutem Kundendruck ein Entwickler "unter der Hand" Änderungen ins Produktivsystem eingespielt hat, ohne dies mit seinen Kollegen abzusprechen oder einen ausführlichen Test der Anwendung nach dem Testprotokoll 27.4, Version 12, Paragraph 3, Absatz 5 durchzuführen.
Das Unternehmen mahnt seinen Mitarbeiter ab, schickt dann aber als Versöhnungsmaßnahme die ganze Abteilung im Anschluss verpflichtend in den Kletterwald, um Vertrauen untereinander zu schaffen.
Der Mitarbeiter begibt sich aktiv auf Jobsuche.
Fall 2:
Das Team im Startup "DataNerds from outer space" hat die gleiche Situation wie die Firma BuzzwordSoft. Nur gehen sie damit anders um.
Sie erkennen, dass zwar letztendlich der Mitarbeiter den "Bock geschossen hat", in einem klärenden Gespräch unter Kollegen kommt jedoch heraus, dass dieser privat momentan viel Stress hat und der direkte Kundendruck das Fass zum Überlaufen brachte. Er wollte das Problem einfach schnell beheben; leider war er damit nicht erfolgreich.
Das Team stellt fest, dass der einzelne zwar "den Fehler" begangen hat, dieser jedoch mit einem Prozess aus Unit Tests, Integrationstests, einer automatisierten Build Pipeline und 4(oder mehr)-Augen-Reviews gar nicht erst passiert wäre, unabhängig von der privaten Situation des Kollegen. Statt den Kollegen zu vergraulen beschwichtigt man den Kunden und beginnt, das Produkt robuster zu designen und eine automatisierte Buildpipeline mit frei verfügbaren Open Source Tools zu erstellen.
Der Mitarbeiter fühlt sich als Mensch wahrgenommen und geht trotz des Vorfalls gern zur Arbeit.
Anfahrt nach Berlin. Autobahn A2. Hagel. Gewitter. Die Frisur hält. Natürlich sind die beiden Beispiele stark überzeichnet. Jedoch dienen sie meiner Meinung nach gut der Veranschaulichung, wie unterschiedlich man je nach Kontext, Systemumgebung und Sozialisierung mit Problemen umgehen kann. Solche und ähnliche Fragestellungen werden oft von den Mitgliedern des Netzwerks beleuchtet. Der Hintergrund hier ist, dass wir in unserer modernen, von Dynamik geprägten Arbeitswelt mit den Methoden klassischen Managements oft nicht mehr weiterkommen.
Und damit man sich dazu nicht nur im Internet oder auf den sogenannten "intrisify.meetups"(eine Art Stammtisch, ähnlich wie User Group-Treffen) austauscht, gibt es mittlerweile im 2-Monats-Turnus die sogenannten "Wevents", auf denen man mit dem Rahmen "Open Space" diskutieren, Lösungen erarbeiten und sich mit seinen unterschiedlichen Hintergründen und Fragen begegnen kann.
"Ich will nicht nach Berlin♪♫" - Das Wevent
Ein paar Entscheidungen zur Planung und Finanzierung, eine Buchung per AirBnb, eine gepackte Reisetasche und 5 Stunden Autofahrt durch Gewitter und Hagel später waren mein Kollege und ich dann endlich in Berlin angekommen. Freitag Abend gab es ein Warm-Up zum Kennenlernen im Wirtshaus Max und Moritz. Hier konnte man sich schon mal gegenseitig zu Speis und Trank beschnuppern und bekam einen kleinen Eindruck vorab, wie die Stimmung am Wochenende werden sollte(Spoiler: Verdammt gut).
Sessionsammlung vom Samstag - Entscheiden, du dich musst! Samstag "früh" um 9:00 war dann Einlass in der Forum Factory, einer ziemlich coolen Location, die als Tagungs-, Seminar- oder Gallerieraum dienen kann. Nach einer kurzen Vorstellung der Open Space-"Grundsätze" ging es dann auch schon an die Sessionplanung. Jeder konnte Themen einbringen, die dann parallel in verschiedenen Räumen diskutiert werden konnten. Der Charakter der Session war jedem selbst vorbehalten. So gab es z.B. eine Session "Wieviel(sic!) Persönlichkeit braucht Future Leadership?", in der eine Diskussion im Fishbowl-Format der Kern war. Andere Sessions waren ein "einfacher" Erfahrungsaustausch im Gespräch, die Möglichkeiten zur Moderation und zum Austausch waren jedem selbst überlassen.
Neben dem eigentlichen Inhalt der Sessions hat mich am stärksten die Haltung der Teilnehmer im Gespräch beeindruckt. Es herrschte eine unfassbar große Offenheit, eine hohe Reflexionstiefe und ein sehr ehrlicher Umgang mit Kritik. Bei vielen Gesprächen war implizit eine Vertrauensebene vorhanden, auch mit persönlichen Themen "nach außen" zu gehen, weil einfach eine Wohlfühlstimmung und ein "Hier kann ich ich sein"-Gefühl im Raum standen.
Vegane Leckereien, bereitgestellt vom "Supermarkt-Team" Samstag Abend gab es die Option, sich im Café brennBar zu Abendessen und weiterem informellen Austausch und Netzwerken zu versammeln, was auch von vielen wahrgenommen wurde. Ich selbst hatte viele Gespräche zum Thema "Beruf und Familie", die mich in meinem Selbstbild als Vater und Berufstätiger teils bestätigten, aber auch viele neue Impulse legten, über mein Handeln unter neuen Gesichtspunkten zu reflektieren.
Sonntag gab es noch einmal die Möglichkeit, neue Sessions oder Folgeangebote vom Vortag anzubieten. Da man sich schon etwas besser kannte, ging es auch hier wieder ordentlich "in die Tiefe", und gefühlt waren die Gespräche noch eine Spur bedeutsamer und "impulsgebender"(gibt es das Wort?) als am Vortag. Zu dem Zeitpunkt machte sich in meinem Kopf aber schon das Gefühl breit, ob der Menge an Input nicht mehr so ganz auf der Höhe zu sein. Ich nutze eine Zwischenpause, um auf meinem Surface(das sich das Wochenende als treuer Begleiter erwiesen hat) die bisherigen Gedanken zu strukturieren und in Form zu bringen.
Die Teilnehmer hatten die Möglichkeit, ihre Lieblingsbücher auszulegen... Eine weitere, aber prägnante Besonderheit im Gegensatz zu anderen Veranstaltungen dieser Art möchte ich noch erwähnen, da sie meiner Meinung nach viele Gedanken, die dieses Netzwerk antreiben, sehr gut wiederspiegelt. Nämlich die Bezahlung.
...und Heidewitzka, waren das viele gute Bücher. Im Eingangsbereich der Forum Factory liegen Excel-Listen aus, welche die Reinkosten des Wevents darstellen. An der Wand hängt dazu passend ein Flipchart, das anzeigt, wie viel die Veranstaltung insgesamt kostet und was bisher an Einnahmen erfolgt ist. Während der Veranstaltung wird dieser Stand ständig aktualisiert. Der Hintergrund ist hier, dass die Veranstaltung zum einen als selbsttragend angelegt ist(also keine Profitveranstaltung) und zum anderen, dass es keine festen Beiträge gibt. So waren am Wochenende 185€ als empfohlener Betrag angegeben. Wer mehr zahlen kann und möchte, darf das genauso tun, wie jemand, der das nicht kann oder mag. Und man mag es kaum glauben, das funktioniert.
Fazit - TL;DR
Was habe ich von dem Wochenende mitgenommen und was erhoffe ich mir von der Mitgliedschaft bei intrinsify.me(die übrigens kostenlos ist)?
Ich habe viele unfassbar aufgeschlossene Menschen mit tollen Ideen und Gedanken getroffen. Ich habe ein Netzwerk kennengelernt, dass es zu schaffen scheint, dabei zu helfen, diesen Ideen Form zu verleihen und über den Status der "Spinnerei" hinauszuwachsen. Ich hatte ein geniales Wochenende in Berlin, obwohl ich von der Stadt außer dem Checkpoint Charlie beim Abholen unseres Autos nicht wirklich etwas gesehen habe. Und ich habe sehr viel über mich selbst gelernt. In meiner Position als Angestellter, als Vater und als Mensch überhaupt. Wenn ihr in eurer Nähe mal ein Wevent und dazu Interesse an dem Thema "Neue Arbeitswelt" habt, ich kann euch nur empfehlen, euch das ganze mal anzusehen.
Gruß, euer "devopsdad" Patrick aka Goulasz

Hallo Welt!
Nach langem Prokrastinieren und diversen mehr oder minder gut passenden Ausreden ist hier endlich der Eröffnungsbeitrag auf meinem Blog(bzw. in angepasster Form hier im Fi.De-Blog). Ich möchte an dieser Stelle ein bisschen was über mich erzählen, was ich hier schreiben möchte und warum ich das tue.
Mein Name ist Patrick, die älteren kennen mich hier noch unter "Zieg0re", die nicht ganz so alten unter "Goulasz". Ich bin mittlerweile fast 30 Jahre alt, verheiratet, Vater dreier bezaubernder Kinder(ein Sohn, knapp 3 1/2, zweieiige Zwillingstöchter im Alter von 20 Monaten) und hauptberuflich zumindest auf dem Papier "Datenbankentwickler". Das mache ich bei einem mittelständischen (IT-)Dienstleister für die Automobilindustrie im schönen Nordhessen.
Tja, und wie das in der IT(und eigentlich allem, wenn ich so drüber nachdenke) eben so ist, gibt es immer wieder Neuerungen, Änderungen, Anpassungen, die dein Weltbild in Schutt und Asche zu legen in der Lage sind. Darüber möchte ich hier schreiben. Dinge, die ich im Beruf oder privat erlebe, erfahre und die in Resonanz mit mir und meinem Leben geraten.
DevOps als namensgebendes Thema ist so ein "Ding". Jeder kennt das, in den meisten Fällen ist die unternehmenseigene IT ein "Mittel zum Zweck", eine nicht einsehbare, undurchsichtige Kiste, ja, Abteilung, in die man ein Problem reinwirft, sich ein bisschen darüber aufregt, wieso man keine Antwort bekommt, dann irgendwann doch eine bekommt und sich dann mehr oder weniger darüber freut. DevOps als Ansatz versucht, diesen unheiligen Zirkel zu durchbrechen, wieder echt und ehrlich miteinander zusammenzuarbeiten und Wert zu schaffen.
Die Allgemeine Systemtheorie ist noch so ein Thema. Durch einen guten Kollegen von mir und dessen Überzeugungsarbeit im Punkt Organisationsentwicklung bin ich auf Gerhard Wohlands "Denkwerkzeuge der Höchstleister" gestoßen. Das Buch, die Inhalte und die Art, Dinge zu betrachten begleiten mich seitdem in meinem Leben und machen mich, da bin ich der festen Überzeugung, ähnlich wie das Erfahren agiler Methoden zu einem besseren Entwickler, Vater und Menschen.
Dann gibt es da natürlich noch viel, viel technischen Krempel, der mich umtreibt und interessiert. Tools für automatische Tests, Datenqualität, Monitoring... Dinge wie Docker, Hadoop, die Sprache "R" und allgemeine Dinge zur Datenverarbeitung und -visualisierung beschäftigen mich akut sehr und ich gehe davon aus, bald einiges dazu zu bloggen und damit zu experimentieren.
Und last but not least gibt es natürlich auch viel, was mich in meiner Rolle als Vater und (Ehe-)Mann so beschäftigt. Seien es abgefahren nützliche Dinge wie dieser mitnehmbare Kindersitz für unterwegs, tolle Locations für Eltern mit ihren Kindern, Bücher und Filme zum Thema Bildung und Erziehung oder Erlebnisse, die für mich einschneidend waren.
Was das hier auf dem Blog zu suchen hat? Bei vielen Themen, die für mich eigentlich primär arbeitsrelevant sind(Agile Methoden, Systemtheorie, DevOps, Augenhöhe, etc.) stelle ich fest, dass die Inhalte sich auch auf mein Selbstbild als Vater beziehen lassen und andersrum. Grade die Themen, in denen "Empathie" eins der Hauptthemen ist - daher auch der Untertitel dieses Blogs "empathy rocks".
Denn sind wir mal ehrlich, ohne Empathie und ein Einfühlen und Eindenken in unser gegenüber, sei es das eigene Kind, ein Kollege, ein Kunde, der grade eine Anforderung beschreibt, kommen wir einer echten Lösung unserer Probleme auf Dauer nicht näher sondern bekämpfen nur Symptome, keine Ursachen.
Also, ich hoffe den ein oder anderen zum Schmunzeln zu bringen, Impulse zu stiften, zum Nachdenken anzuregen oder einfach nur zu unterhalten. Für Kritik bin ich immer zu haben, scheut euch also nicht, mit mir in Kontakt zu treten oder Beiträge hier zu teilen oder zu kommentieren!
Euer "devopsdad" Patrick aka Goulasz  

Hallo Welt!
In einer Zeit, in der eine unüberschaubare Menge an Informationen im Internet verfügbar und jederzeit abrufbar ist, verlieren Bücher oft zunehmend an Stellenwert. Ich sehe das anders. Ich mag Bücher, momentan besonders Fachbücher zum Thema Organisationsentwicklung und "Umgang mit Dynamik".
Komplexithoden, Organisation für Komplexität und das titelgebende "Denkwerkzeuge der Höchstleister", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Meinen Liebling aus dieser Kategorie möchte ich euch heute vorstellen. Hierbei handelt es sich um die "Denkwerkzeuge der Höchstleister" von Gerhard Wohland und Matthias Wiemeyer mit dem bedeutungsschwangeren Untertitel "Warum dynamikrobuste Unternehmen Marktdruck erzeugen"; vorliegend in der dritten Auflage, 2012 erschienen im Unibuch Verlag.
Vorweg: Das Buch ist kein Buch, das man einfach nur liest und dann weglegt. Es ist ein Arbeitsbuch, das man immer wieder aufschlägt, darin nachliest, stöbert und studiert, um sich immer und immer wieder teils ungläubig von den plakativ klingenden aber so einleuchtenden Thesen zu überzeugen. Ich habe es förmlich verschlungen, es bereitet mir heute teilweise noch schlaflose Nächte.
Aber genug gewarnt, jetzt wird angefixt! Worum geht es bei den "Denkwerkzeugen der Höchstleister"?
Inhalt
Beschrieben werden im Buch Ansätze, die sogenannten "Denkwerkzeuge", die dienlich sein können, um Dynamik und Systeme besser verstehen zu können und mit Ihnen umzugehen. Das ganze idealerweise ohne daran zu verzweifeln oder wirtschaftlich daran zu Grunde zu gehen. Es bietet Impulse und Ansätze, die man in der eigenen Organisation unter Einbeziehung der eigenen Umgebung und der Fakten nutzen kann, um eine für sich funktionierende Lösung für verschiedene Probleme zu finden. Das ganze vor einem einfachen, nachvollziehbaren, geschichtlichen und wirtschaftlichen Hintergrund. Wieso sind die Märkte heute, wie sie sind; wieso können Unternehmen, die flexibel und agil aufgestellt sind, besser mit den engeren Märkten der Globalisierung umgehen als klassische, hierarchisch aufgebaute Konzerne, und wieso passen viele Management-Instrumente aus der klassischen BWL nicht mehr zu heutigen Anforderungen? Für all diese Fragen und mehr findet der Leser hier plausible Theorien, die als Erklärung dienen.
"Es gibt nichts Praktischeres als eine gute Theorie" - Kurt Lewin Auf keinen Fall werden hier aber "Best Practices" angeboten, die man in seinem Unternehmen umsetzt, auf einmal geschieht ein Wunder und der Umsatz steigt wie von Zauberhand in einem Jahr um 150%. So etwas gibt es nicht, bzw. wenn es funktioniert passten glücklicherweise viele Parameter beim Anwenden des Denkwerkzeugs. Unternehmen sind bedingt durch die verschiedenen Typen von Menschen, die in ihnen arbeiten, hochkomplexe Systeme, die keinen "Wenn > Dann"-Mustern folgen. Man kann vielleicht vermuten, welche Wirkung eine Maßnahme hat, sicher sein kann man sich jedoch nie.
Und das ist auch völlig in Ordnung so. Komplexität und Dynamik sind weder schlecht noch gut. Sie sind einfach da. Wie das Wetter.
Schlecht ist nur, darauf als Organisation nicht vorbereitet zu sein und dann nicht reagieren zu können. Denn dann steht man im Zweifel ohne Schirm und Jacke "im Regen".
Aufbau
Ein Hauptteil des Buches ist der Glossar, auf dem die präzisen Begriffe, die in diesem(sytemtheoretischen) Kontext genutzt werden, erläutert und eingeordnet werden. Dem voran gehen ein Vorab-Bereich in dem der Aufbau im Detail erläutert wird und 13 kurze, 10 Seiten nicht übersteigende Kapitel, die klassische Management-Thesen im Kontext moderner, dynamischer Märkte beleuchten. In diesen Kapiteln gibt es zusätzlich zu den im Fließtext sehr anschaulich formulierten Thesen und Vergleichen die sogenannten "Denkzettel". Diese beschreiben ein Problem und geben einen Hinweis, in welche Richtung man sich bewegen kann, um eine mögliche Lösung im eigenen Unternehmenskontext zu finden.
Denkzettel "Zentrum und Peripherie" samt Kapitelresümee "Taylorismus - Aufstieg und Fall einer genialen Idee", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Das klingt erstmal recht kompliziert, wenn man jedoch begriffen hat, dass man das Buch weder am Stück noch in der geschriebenen Reihenfolge lesen muss, sondern es immer und immer wieder als Nachschlagewerk und Referenz nutzen kann, passt dieses gut sortierte Format ganz hervorragend.
Die Denkzettel sind ein großartiger Einstieg, um sich mit der Systemtheorie und den Denkwerkzeugen auseinanderzusetzen, wenn man in diesem Umfeld noch völlig unbedarft ist. Wer in die Tiefe gehen will, liest einfach die umspannenden Kapitel.
Zielgruppe und Fazit
Das Buch ist für alle geeignet, die das Gefühl haben, Projekte in ihrer Organisation laufen "irgendwie schlecht", verfehlen oft das Ziel, Kunden und Mitarbeiter sind unzufrieden, die Konkurrenz überholt uns ständig, Sarkasmus ist an des Tagesordnung, es gibt "zu viele Meetings"; aber keiner weiß so richtig wieso, etc.
Das Buch ist definitiv nicht für Menschen geeignet, die sich eine schnelle Lösung per "Best Practice" erhoffen und der Meinung sind, man könnte per steuernder Direktive "von oben" Dinge wie Unternehmens- und Wertekultur der Mitarbeiter ändern oder steuern. Das dies nicht funktioniert, machen die Autoren immer wieder mit vielen Beispielen zum Thema "Kultur" und "Steuerung" im Unternehmen klar.
Mir selbst hat das Buch viele Ansätze und Handlungsräume eröffnet, die mir helfen zu verstehen, wieso im Beruf so oft so viel "Theater" um Probleme gemacht wird, die eigentlich mit dem berühmt-berüchtigten "gesunden Menschenverstand" einfach zu beheben sein sollten.
Ich nutze es regelmäßig und gehe schon fast missionarartig damit hausieren, weil ich es schlicht und einfach großartig und unendlich wertvoll finde.
Ganz akut Interessierten aus der Umgebung kann ich mein Exemplar zum Reinschnuppern gerne auch Ausleihen. Für alle anderen gibt es in der Linksektion noch mehr Futter. Viel Spaß beim Stöbern!
Euer "devopsdad" Patrick aka Goulasz
Weiterführende Links zum Thema
Hier gibt es die Denkzettel im PDF-Format: Denkzettel bei dynamikrobust.com Hier der Link zum Buch bei Amazon: Denkwerkzeuge der Höchstleister Intrinsify.me-Netzwerk zum Thema "Moderne Unternehmensführung" und "Sinnkopplung im Job": Intrinsify.me Wikipedia-Artikel zur Systemtheorie zum Warmwerden und Einlesen: Systemtheorie

Hallo Welt!
Nach langem Prokrastinieren und diversen mehr oder minder gut passenden Ausreden ist hier endlich der Eröffnungsbeitrag auf meinem Blog(bzw. in angepasster Form hier im Fi.De-Blog). Ich möchte an dieser Stelle ein bisschen was über mich erzählen, was ich hier schreiben möchte und warum ich das tue.
Mein Name ist Patrick, die älteren kennen mich hier noch unter "Zieg0re", die nicht ganz so alten unter "Goulasz". Ich bin mittlerweile fast 30 Jahre alt, verheiratet, Vater dreier bezaubernder Kinder(ein Sohn, knapp 3 1/2, zweieiige Zwillingstöchter im Alter von 20 Monaten) und hauptberuflich zumindest auf dem Papier "Datenbankentwickler". Das mache ich bei einem mittelständischen (IT-)Dienstleister für die Automobilindustrie im schönen Nordhessen.
Tja, und wie das in der IT(und eigentlich allem, wenn ich so drüber nachdenke) eben so ist, gibt es immer wieder Neuerungen, Änderungen, Anpassungen, die dein Weltbild in Schutt und Asche zu legen in der Lage sind. Darüber möchte ich hier schreiben. Dinge, die ich im Beruf oder privat erlebe, erfahre und die in Resonanz mit mir und meinem Leben geraten.
DevOps als namensgebendes Thema ist so ein "Ding". Jeder kennt das, in den meisten Fällen ist die unternehmenseigene IT ein "Mittel zum Zweck", eine nicht einsehbare, undurchsichtige Kiste, ja, Abteilung, in die man ein Problem reinwirft, sich ein bisschen darüber aufregt, wieso man keine Antwort bekommt, dann irgendwann doch eine bekommt und sich dann mehr oder weniger darüber freut. DevOps als Ansatz versucht, diesen unheiligen Zirkel zu durchbrechen, wieder echt und ehrlich miteinander zusammenzuarbeiten und Wert zu schaffen.
Die Allgemeine Systemtheorie ist noch so ein Thema. Durch einen guten Kollegen von mir und dessen Überzeugungsarbeit im Punkt Organisationsentwicklung bin ich auf Gerhard Wohlands "Denkwerkzeuge der Höchstleister" gestoßen. Das Buch, die Inhalte und die Art, Dinge zu betrachten begleiten mich seitdem in meinem Leben und machen mich, da bin ich der festen Überzeugung, ähnlich wie das Erfahren agiler Methoden zu einem besseren Entwickler, Vater und Menschen.
Dann gibt es da natürlich noch viel, viel technischen Krempel, der mich umtreibt und interessiert. Tools für automatische Tests, Datenqualität, Monitoring... Dinge wie Docker, Hadoop, die Sprache "R" und allgemeine Dinge zur Datenverarbeitung und -visualisierung beschäftigen mich akut sehr und ich gehe davon aus, bald einiges dazu zu bloggen und damit zu experimentieren.
Und last but not least gibt es natürlich auch viel, was mich in meiner Rolle als Vater und (Ehe-)Mann so beschäftigt. Seien es abgefahren nützliche Dinge wie dieser mitnehmbare Kindersitz für unterwegs, tolle Locations für Eltern mit ihren Kindern, Bücher und Filme zum Thema Bildung und Erziehung oder Erlebnisse, die für mich einschneidend waren.
Was das hier auf dem Blog zu suchen hat? Bei vielen Themen, die für mich eigentlich primär arbeitsrelevant sind(Agile Methoden, Systemtheorie, DevOps, Augenhöhe, etc.) stelle ich fest, dass die Inhalte sich auch auf mein Selbstbild als Vater beziehen lassen und andersrum. Grade die Themen, in denen "Empathie" eins der Hauptthemen ist - daher auch der Untertitel dieses Blogs "empathy rocks".
Denn sind wir mal ehrlich, ohne Empathie und ein Einfühlen und Eindenken in unser gegenüber, sei es das eigene Kind, ein Kollege, ein Kunde, der grade eine Anforderung beschreibt, kommen wir einer echten Lösung unserer Probleme auf Dauer nicht näher sondern bekämpfen nur Symptome, keine Ursachen.
Also, ich hoffe den ein oder anderen zum Schmunzeln zu bringen, Impulse zu stiften, zum Nachdenken anzuregen oder einfach nur zu unterhalten. Für Kritik bin ich immer zu haben, scheut euch also nicht, mit mir in Kontakt zu treten oder Beiträge hier zu teilen oder zu kommentieren!
Euer "devopsdad" Patrick aka Goulasz  

Hallo Welt!
In einer Zeit, in der eine unüberschaubare Menge an Informationen im Internet verfügbar und jederzeit abrufbar ist, verlieren Bücher oft zunehmend an Stellenwert. Ich sehe das anders. Ich mag Bücher, momentan besonders Fachbücher zum Thema Organisationsentwicklung und "Umgang mit Dynamik".
Komplexithoden, Organisation für Komplexität und das titelgebende "Denkwerkzeuge der Höchstleister", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Meinen Liebling aus dieser Kategorie möchte ich euch heute vorstellen. Hierbei handelt es sich um die "Denkwerkzeuge der Höchstleister" von Gerhard Wohland und Matthias Wiemeyer mit dem bedeutungsschwangeren Untertitel "Warum dynamikrobuste Unternehmen Marktdruck erzeugen"; vorliegend in der dritten Auflage, 2012 erschienen im Unibuch Verlag.
Vorweg: Das Buch ist kein Buch, das man einfach nur liest und dann weglegt. Es ist ein Arbeitsbuch, das man immer wieder aufschlägt, darin nachliest, stöbert und studiert, um sich immer und immer wieder teils ungläubig von den plakativ klingenden aber so einleuchtenden Thesen zu überzeugen. Ich habe es förmlich verschlungen, es bereitet mir heute teilweise noch schlaflose Nächte.
Aber genug gewarnt, jetzt wird angefixt! Worum geht es bei den "Denkwerkzeugen der Höchstleister"?
Inhalt
Beschrieben werden im Buch Ansätze, die sogenannten "Denkwerkzeuge", die dienlich sein können, um Dynamik und Systeme besser verstehen zu können und mit Ihnen umzugehen. Das ganze idealerweise ohne daran zu verzweifeln oder wirtschaftlich daran zu Grunde zu gehen. Es bietet Impulse und Ansätze, die man in der eigenen Organisation unter Einbeziehung der eigenen Umgebung und der Fakten nutzen kann, um eine für sich funktionierende Lösung für verschiedene Probleme zu finden. Das ganze vor einem einfachen, nachvollziehbaren, geschichtlichen und wirtschaftlichen Hintergrund. Wieso sind die Märkte heute, wie sie sind; wieso können Unternehmen, die flexibel und agil aufgestellt sind, besser mit den engeren Märkten der Globalisierung umgehen als klassische, hierarchisch aufgebaute Konzerne, und wieso passen viele Management-Instrumente aus der klassischen BWL nicht mehr zu heutigen Anforderungen? Für all diese Fragen und mehr findet der Leser hier plausible Theorien, die als Erklärung dienen.
"Es gibt nichts Praktischeres als eine gute Theorie" - Kurt Lewin Auf keinen Fall werden hier aber "Best Practices" angeboten, die man in seinem Unternehmen umsetzt, auf einmal geschieht ein Wunder und der Umsatz steigt wie von Zauberhand in einem Jahr um 150%. So etwas gibt es nicht, bzw. wenn es funktioniert passten glücklicherweise viele Parameter beim Anwenden des Denkwerkzeugs. Unternehmen sind bedingt durch die verschiedenen Typen von Menschen, die in ihnen arbeiten, hochkomplexe Systeme, die keinen "Wenn > Dann"-Mustern folgen. Man kann vielleicht vermuten, welche Wirkung eine Maßnahme hat, sicher sein kann man sich jedoch nie.
Und das ist auch völlig in Ordnung so. Komplexität und Dynamik sind weder schlecht noch gut. Sie sind einfach da. Wie das Wetter.
Schlecht ist nur, darauf als Organisation nicht vorbereitet zu sein und dann nicht reagieren zu können. Denn dann steht man im Zweifel ohne Schirm und Jacke "im Regen".
Aufbau
Ein Hauptteil des Buches ist der Glossar, auf dem die präzisen Begriffe, die in diesem(sytemtheoretischen) Kontext genutzt werden, erläutert und eingeordnet werden. Dem voran gehen ein Vorab-Bereich in dem der Aufbau im Detail erläutert wird und 13 kurze, 10 Seiten nicht übersteigende Kapitel, die klassische Management-Thesen im Kontext moderner, dynamischer Märkte beleuchten. In diesen Kapiteln gibt es zusätzlich zu den im Fließtext sehr anschaulich formulierten Thesen und Vergleichen die sogenannten "Denkzettel". Diese beschreiben ein Problem und geben einen Hinweis, in welche Richtung man sich bewegen kann, um eine mögliche Lösung im eigenen Unternehmenskontext zu finden.
Denkzettel "Zentrum und Peripherie" samt Kapitelresümee "Taylorismus - Aufstieg und Fall einer genialen Idee", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Das klingt erstmal recht kompliziert, wenn man jedoch begriffen hat, dass man das Buch weder am Stück noch in der geschriebenen Reihenfolge lesen muss, sondern es immer und immer wieder als Nachschlagewerk und Referenz nutzen kann, passt dieses gut sortierte Format ganz hervorragend.
Die Denkzettel sind ein großartiger Einstieg, um sich mit der Systemtheorie und den Denkwerkzeugen auseinanderzusetzen, wenn man in diesem Umfeld noch völlig unbedarft ist. Wer in die Tiefe gehen will, liest einfach die umspannenden Kapitel.
Zielgruppe und Fazit
Das Buch ist für alle geeignet, die das Gefühl haben, Projekte in ihrer Organisation laufen "irgendwie schlecht", verfehlen oft das Ziel, Kunden und Mitarbeiter sind unzufrieden, die Konkurrenz überholt uns ständig, Sarkasmus ist an des Tagesordnung, es gibt "zu viele Meetings"; aber keiner weiß so richtig wieso, etc.
Das Buch ist definitiv nicht für Menschen geeignet, die sich eine schnelle Lösung per "Best Practice" erhoffen und der Meinung sind, man könnte per steuernder Direktive "von oben" Dinge wie Unternehmens- und Wertekultur der Mitarbeiter ändern oder steuern. Das dies nicht funktioniert, machen die Autoren immer wieder mit vielen Beispielen zum Thema "Kultur" und "Steuerung" im Unternehmen klar.
Mir selbst hat das Buch viele Ansätze und Handlungsräume eröffnet, die mir helfen zu verstehen, wieso im Beruf so oft so viel "Theater" um Probleme gemacht wird, die eigentlich mit dem berühmt-berüchtigten "gesunden Menschenverstand" einfach zu beheben sein sollten.
Ich nutze es regelmäßig und gehe schon fast missionarartig damit hausieren, weil ich es schlicht und einfach großartig und unendlich wertvoll finde.
Ganz akut Interessierten aus der Umgebung kann ich mein Exemplar zum Reinschnuppern gerne auch Ausleihen. Für alle anderen gibt es in der Linksektion noch mehr Futter. Viel Spaß beim Stöbern!
Euer "devopsdad" Patrick aka Goulasz
Weiterführende Links zum Thema
Hier gibt es die Denkzettel im PDF-Format: Denkzettel bei dynamikrobust.com Hier der Link zum Buch bei Amazon: Denkwerkzeuge der Höchstleister Intrinsify.me-Netzwerk zum Thema "Moderne Unternehmensführung" und "Sinnkopplung im Job": Intrinsify.me Wikipedia-Artikel zur Systemtheorie zum Warmwerden und Einlesen: Systemtheorie

Hallo Welt!
In einer Zeit, in der eine unüberschaubare Menge an Informationen im Internet verfügbar und jederzeit abrufbar ist, verlieren Bücher oft zunehmend an Stellenwert. Ich sehe das anders. Ich mag Bücher, momentan besonders Fachbücher zum Thema Organisationsentwicklung und "Umgang mit Dynamik".
Komplexithoden, Organisation für Komplexität und das titelgebende "Denkwerkzeuge der Höchstleister", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Meinen Liebling aus dieser Kategorie möchte ich euch heute vorstellen. Hierbei handelt es sich um die "Denkwerkzeuge der Höchstleister" von Gerhard Wohland und Matthias Wiemeyer mit dem bedeutungsschwangeren Untertitel "Warum dynamikrobuste Unternehmen Marktdruck erzeugen"; vorliegend in der dritten Auflage, 2012 erschienen im Unibuch Verlag.
Vorweg: Das Buch ist kein Buch, das man einfach nur liest und dann weglegt. Es ist ein Arbeitsbuch, das man immer wieder aufschlägt, darin nachliest, stöbert und studiert, um sich immer und immer wieder teils ungläubig von den plakativ klingenden aber so einleuchtenden Thesen zu überzeugen. Ich habe es förmlich verschlungen, es bereitet mir heute teilweise noch schlaflose Nächte.
Aber genug gewarnt, jetzt wird angefixt! Worum geht es bei den "Denkwerkzeugen der Höchstleister"?
Inhalt
Beschrieben werden im Buch Ansätze, die sogenannten "Denkwerkzeuge", die dienlich sein können, um Dynamik und Systeme besser verstehen zu können und mit Ihnen umzugehen. Das ganze idealerweise ohne daran zu verzweifeln oder wirtschaftlich daran zu Grunde zu gehen. Es bietet Impulse und Ansätze, die man in der eigenen Organisation unter Einbeziehung der eigenen Umgebung und der Fakten nutzen kann, um eine für sich funktionierende Lösung für verschiedene Probleme zu finden. Das ganze vor einem einfachen, nachvollziehbaren, geschichtlichen und wirtschaftlichen Hintergrund. Wieso sind die Märkte heute, wie sie sind; wieso können Unternehmen, die flexibel und agil aufgestellt sind, besser mit den engeren Märkten der Globalisierung umgehen als klassische, hierarchisch aufgebaute Konzerne, und wieso passen viele Management-Instrumente aus der klassischen BWL nicht mehr zu heutigen Anforderungen? Für all diese Fragen und mehr findet der Leser hier plausible Theorien, die als Erklärung dienen.
"Es gibt nichts Praktischeres als eine gute Theorie" - Kurt Lewin Auf keinen Fall werden hier aber "Best Practices" angeboten, die man in seinem Unternehmen umsetzt, auf einmal geschieht ein Wunder und der Umsatz steigt wie von Zauberhand in einem Jahr um 150%. So etwas gibt es nicht, bzw. wenn es funktioniert passten glücklicherweise viele Parameter beim Anwenden des Denkwerkzeugs. Unternehmen sind bedingt durch die verschiedenen Typen von Menschen, die in ihnen arbeiten, hochkomplexe Systeme, die keinen "Wenn > Dann"-Mustern folgen. Man kann vielleicht vermuten, welche Wirkung eine Maßnahme hat, sicher sein kann man sich jedoch nie.
Und das ist auch völlig in Ordnung so. Komplexität und Dynamik sind weder schlecht noch gut. Sie sind einfach da. Wie das Wetter.
Schlecht ist nur, darauf als Organisation nicht vorbereitet zu sein und dann nicht reagieren zu können. Denn dann steht man im Zweifel ohne Schirm und Jacke "im Regen".
Aufbau
Ein Hauptteil des Buches ist der Glossar, auf dem die präzisen Begriffe, die in diesem(sytemtheoretischen) Kontext genutzt werden, erläutert und eingeordnet werden. Dem voran gehen ein Vorab-Bereich in dem der Aufbau im Detail erläutert wird und 13 kurze, 10 Seiten nicht übersteigende Kapitel, die klassische Management-Thesen im Kontext moderner, dynamischer Märkte beleuchten. In diesen Kapiteln gibt es zusätzlich zu den im Fließtext sehr anschaulich formulierten Thesen und Vergleichen die sogenannten "Denkzettel". Diese beschreiben ein Problem und geben einen Hinweis, in welche Richtung man sich bewegen kann, um eine mögliche Lösung im eigenen Unternehmenskontext zu finden.
Denkzettel "Zentrum und Peripherie" samt Kapitelresümee "Taylorismus - Aufstieg und Fall einer genialen Idee", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Das klingt erstmal recht kompliziert, wenn man jedoch begriffen hat, dass man das Buch weder am Stück noch in der geschriebenen Reihenfolge lesen muss, sondern es immer und immer wieder als Nachschlagewerk und Referenz nutzen kann, passt dieses gut sortierte Format ganz hervorragend.
Die Denkzettel sind ein großartiger Einstieg, um sich mit der Systemtheorie und den Denkwerkzeugen auseinanderzusetzen, wenn man in diesem Umfeld noch völlig unbedarft ist. Wer in die Tiefe gehen will, liest einfach die umspannenden Kapitel.
Zielgruppe und Fazit
Das Buch ist für alle geeignet, die das Gefühl haben, Projekte in ihrer Organisation laufen "irgendwie schlecht", verfehlen oft das Ziel, Kunden und Mitarbeiter sind unzufrieden, die Konkurrenz überholt uns ständig, Sarkasmus ist an des Tagesordnung, es gibt "zu viele Meetings"; aber keiner weiß so richtig wieso, etc.
Das Buch ist definitiv nicht für Menschen geeignet, die sich eine schnelle Lösung per "Best Practice" erhoffen und der Meinung sind, man könnte per steuernder Direktive "von oben" Dinge wie Unternehmens- und Wertekultur der Mitarbeiter ändern oder steuern. Das dies nicht funktioniert, machen die Autoren immer wieder mit vielen Beispielen zum Thema "Kultur" und "Steuerung" im Unternehmen klar.
Mir selbst hat das Buch viele Ansätze und Handlungsräume eröffnet, die mir helfen zu verstehen, wieso im Beruf so oft so viel "Theater" um Probleme gemacht wird, die eigentlich mit dem berühmt-berüchtigten "gesunden Menschenverstand" einfach zu beheben sein sollten.
Ich nutze es regelmäßig und gehe schon fast missionarartig damit hausieren, weil ich es schlicht und einfach großartig und unendlich wertvoll finde.
Ganz akut Interessierten aus der Umgebung kann ich mein Exemplar zum Reinschnuppern gerne auch Ausleihen. Für alle anderen gibt es in der Linksektion noch mehr Futter. Viel Spaß beim Stöbern!
Euer "devopsdad" Patrick aka Goulasz
Weiterführende Links zum Thema
Hier gibt es die Denkzettel im PDF-Format: Denkzettel bei dynamikrobust.com Hier der Link zum Buch bei Amazon: Denkwerkzeuge der Höchstleister Intrinsify.me-Netzwerk zum Thema "Moderne Unternehmensführung" und "Sinnkopplung im Job": Intrinsify.me Wikipedia-Artikel zur Systemtheorie zum Warmwerden und Einlesen: Systemtheorie

Hallo Welt!
Besser spät als nie möchte ich euch von der DevOpsCon 2015 in München berichten. Dort habe ich zum ersten mal "ernsthaft" den Entschluss gefasst, unter die Blogger zu gehen und die ganzen Gedanken, die mir im Kopf rumschwirren, zu "Papier" zu bringen.
Disclaimer: Aufgrund der Menge an Infos, Tools und Eindrücke der Konferenz kann und werde ich hier nur einen Einblick in die für mich interessantesten Themen geben und über das allgemeine Konferenzfeeling schreiben. Für mehr müsst ihr schon selbst dahin.  Es lohnt sich aber, die Themen für Sommer/2016(Berlin) sind im Verhältnis zum Termin Winter/2015 noch recht ähnlich.
Pool im 23ten Stock des Hotels - Nicht DAS, aber definitiv eins der Highlights der 3 Tage Vorwort
Vom 23.11 - 25.11 2015 waren zwei Kollegen von mir(einer der zwei bloggt übrigens auch schon eine ganze Weile) im Sheraton Hotel München im Arabellapark und hatten den Plan, in den zwei Tagen Konferenz und einem Tag Praxis-Workshop so viel wie möglich mitzunehmen, ohne angesichts der Menge an Informationen zu verzweifeln.
Von München selbst haben wir außer einem Besuch im "Burger House 2", was ja auch nicht wirklich "typisch München" ist, nicht wirklich viel mitbekommen. Das ist in Anbetracht der vollgepackten Tage aber auch normal, die BASTA! Spring, die ich 2014 besucht habe, hat einen ähnlichen Effekt verursacht. Außer nem Hefeweizen abends in der Lobby war da nicht mehr viel zu holen bei mir.
Nach dem Abendessen ging es mit den Kollegen eine Runde im Pool schwimmen, den grandiosen Ausblick auf den Liegen um den Pool genießen, den nächsten Tag planen und damit war der Abend meistens auch schon rum.
Tag 1(Workshop)
Zum geschmeidigen Start in den Montag gab es den "Docker-Basis-Workshop" von und mit Peter Roßbach, seines Zeichens Systemarchitekt, Docker-Experte der ersten Stunde und "DevOps"-Enthusiast. Selbst bis dato auf *nix-Systemen völlig unbedarfte Entwickler(wie mich) waren mit Peters Anleitung und aufgrund der Einfachheit der Docker-Syntax in der Lage, in Kürze Container für Webserver, Datenbankserver mit entsprechenden Befehlen zu erzeugen und die Netzwerke gleich mit zu konfigurieren. Mächtiges Tool und mächtige Architektur diese Container-Technologie. Mit einer verhältnismäßig niedrigen Hemmschwelle zum Einstieg und Unmengen an Blogs, Snippets und Infomaterial zu Docker selbst im Netz scheinen die Docker-Container in *nix-Umfeldern eine echte Bereicherung zu sein, wenn es darum geht, skalierbar schnell Infrastruktur bereitzustellen. Obwohl ich mit Infrastruktur und mit Linux bisher wenig zu tun hatte, das hat definitiv mein Interesse geweckt. Der Raspi liegt im Warenkorb. Bücher zu Docker übrigens nicht, die sind oft schon beim Erscheinen veraltet.
Nicht vorenthalten möchte ich euch noch folgendes Zitat von Peter zur Frage , wie man diese Technologie in einer abgeschotteten, kontrollierten Konzern-IT-Infrastruktur implementieren könnte:
¯\_(ツ)_/¯
Tag 2&3(Konferenz, Expo)
Nach einem überschaubaren ersten Tag gab es an den Tagen 2 und 3 ausschließlich Vorträge, Keynotes und informell gestaltete Treffen zum Austausch(Open Space-ig).
Gemeinsam war allen von mir besuchten Vorträgen, das sie unglaublich viel Lust aufs "Basteln" machten. Was sich in der Praxis aufgrund der Open Source-Natur vieler genutzten Tools als gar nicht so schwierig herausstellen sollte.
Am interessantesten waren für mich die Talks zum Thema Unternehmenskultur und Veränderung in der Organisationsstruktur des "DevOps"-Unternehmens. Besonders hervorstechend waren da für mich zum einen Wix.com(WYSIWYG-Baukasten für Webseiten) und zum anderen dm(Ja, die Drogerie). Bei Wix war sehr interessant, wie der Referent Aviran Mordo klar und einfach zeigte, dass man nicht jedes Tool benutzen muss, solange man nicht den "Schmerz spürt", den der Einsatz des Tools zu lindern vermag. Wenn deine Idee grundsätzlich Mist ist, bringen dir die besten Tools nichts, deine Idee bleibt Mist.
Das Bild spricht denke ich für sich. dm im Kontrastprogramm merkte recht schnell, dass man als "Drogerie" mit offenen Augen und Ohren durchaus Gewinn mit ordentlichen Onlineportalen und Webshops machen kann. Ein Onlineshop, der schnell auf die Bedürfnisse der verschiedenen Kunden reagieren kann und in kurzen Abständen qualitativ hochwertige Stände online stellen kann war hier das Credo. Daraus folgte fast natürlich und logisch eine Umstellung des Deployment-Prozesses in Richtung Continuous Delivery und ein damit einhergehendes Umdenken in der Unternehmensorganisation.
Im Verlauf des Talks wurde klar, dass zum einen Vertrauen und Offenheit für ein solches Umdenken notwendig sind. Zum anderen auch, dass dafür nicht jeder bereit ist. Unterm Strich kam jedoch eine effizientere Organisation bei dem Prozess heraus.
Fazit - TL;DR
Das nicht immer alles eitel Sonnenschein ist, war bei allen Vorstellungen von Tools oder Prozessen, die durchlebt wurden, immer zu erkennen. DevOps an sich bedeutet in erster Linie, Verantwortung gemeinsam zu übernehmen für ein geteiltes Bild eines Produkts oder eines Prozesses. Was oft vergessen wird, ist aber, dass dieses Bild manchmal gar nicht existiert oder abteilungsübergreifend völlig anders wahrgenommen wird.
Empathie, echtes Verständnis füreinander und für die Anforderungen des Gesprächspartners waren immer wiederkehrende Merkmale, die notwendig sind, damit so etwas wie Continuous Delivery funktionieren kann.
 
Tools, Tools, Tools!
Zum Abschluss noch ein paar Links und Einzeiler zu vorgestellten Tools, falls jemand bastelwütig wird:
Docker - Software, mit der man andere Software(z.B. Betriebssysteme, Webserver, Datenbankserver,...) virtualisiert in "Containern" verpacken kann, die dann auf jedem System funktionieren Hadoop -  Framework für verteilte Software. Man nehme 10 Raspis, schalte sie zusammen und e voilá: Man hat einen Hadoop-Cluster-Datenbankserver ELK-Stack - Bestehend aus Elasticsearch, Logstash und Kibana zum Durchsuchen, Ablegen und Visualisieren von Logs aller Art OWASP ZAP - Zum manuellen oder automatisierten Security-Scan(aktiv, passiv) von Webanwendungen, auch automatisiert in Jenkins verwendbar Jenkins - Tool für Continuous Integration und so ziemlich alles, was dazu gehört. Lächerlich viele und gute Plugins verfügbar Consul - Service Discovery-Tool, das neue Dienste, die verfügbar werden, automatisch erfasst und diese verwalten kann. Nützlich aber erst, wenn man schon mehrere Microservices im Einsatz hat, sonst tut es auch ein DNS-Eintrag Github - Viel mehr als nur das, aber hauptsächlich ein Repository-Server für GIT Euer "devopsdad" Patrick aka Goulasz
 

Hallo zusammen,
wenn man diesem Forum nur lang genug folgt, liest man irgendwann immer wieder die gleichen Fragen. Daher habe ich mich dazu entschieden, in der ersten Episode des Podcasts von fachinformatiker.de einige dieser häufigen Fragen zu beantworten.
 
FI-Podcast_001_Haeufige_Fragen.mp3 (Länge ca. 35 Minuten, für Play/Pause einfach den Link anklicken)
 
Sehr empfehlenswert ist in diesem Zusammenhang übrigens auch diese FAQ zum Forum: Uli's Prüfungspage für IT-Berufe.
Hier nun also meine Liste der häufigen Fragen mit kurzer Antwort. Wenn du mehr wissen willst, hör doch mal in die Podcast-Episode rein.
Die Sache mit der IHK. Es gibt nicht die IHK, sondern 79 verschiedene. Jede kocht ihr eigenes Süppchen. Liste der Industrie- und Handelskammern in Deutschland Muss ich für eine Ausbildung schon programmieren können? Nein. Sollte das anders sein, wirst du wahrscheinlich als billige Arbeitskraft eingestellt. Warum muss ich so viel Wirtschaftskram lernen? Weil die IT-Berufe zu den kaufmännischen Berufen zählen. In einem Monat ist die Prüfung. Was soll ich lernen? Du fängst viel zu spät an. Lern mit alten Prüfungen und einschlägiger Literatur. Was kommt in der schriftlichen Prüfung dran? Das weiß leider nur der Ausschuss, der die Prüfung erstellt. Woher bekomme ich alte Prüfungen? Vom U-Form-Verlag. Könnt ihr mir ein Projektthema empfehlen? Nein. Es muss sich um ein Thema aus deiner Praxis handeln. Ich muss nächste Woche mit meinem Projekt anfangen und habe kein Thema. Das ist ein Problem, das wir nicht lösen können. Warum wurde mein Projektantrag abgelehnt? Wahrscheinlich, weil die fachliche/wirtschaftliche Tiefe deines Themas nicht deutlich wird oder du eine unrealistische Zeitplanung hast. Welche Vorgaben gibt es für die Ausbildung? Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik Welche Vorgaben zur Projektdokumentation muss ich einhalten? Das kann dir nur deine IHK sagen. Wie viel verdient ein Fachinformatiker? Das kommt auf die Branche, die Aufgaben, die Region, die Vorbildung usw. an. Warum wird meine Bewerbung immer abgelehnt? Wahrscheinlich, weil du ständig nur über dich redest und die Anforderungen des Unternehmens nicht berücksichtigst.  
Hast du zu den obigen Themen auch eine Meinung? Dann immer her damit! Antworte einfach auf diesen Beitrag. Ich würde mich über einen Austausch freuen.
Wenn du konkrete Themenvorschläge oder Fragen für den Podcast hast, dann immer her damit. Und wenn du selbst am Podcast mitarbeiten möchtest, melde dich einfach!
 
Viele Grüße!
Stefan
PS: Auf eine Vorstellung meiner Person habe ich an dieser Stelle verzichtet. Ich bin Stefan! Wenn dich im Detail interessiert, wer hier schreibt und spricht, schau einfach auf meiner Website vorbei: Über mich.

Ich mach's kurz:
Stefan Eling, Fachinformatiker Systemintegration, wohne im Münsterland, 46 Jahre, verheiratet.
Anfang bis Mitte der Neunziger habe ich nach dem Fachabitur zunächst Elektrotechnik / Nachrichtentechnik in an der damaligen Gesamthochschulue Duisburg studiert, und nach dem Vordiplom abgebrochen. Ein blöder Fehler, aus heutiger Sicht.
Anschließend begann ich eine Ausbildung zum Fachinformatiker Systemintegration. Der Beruf des Fachinformatikers war gerade erst entstanden, wir waren der zweite Jahrgang, der in Nordrhein-Westfalen startete. Bevor der "Fachinformatiker" aufgelegt wurde, war eine Ausbildung zum "Datenverarbeitungskaufmann" Mitte der 90iger der Weg in der EDV zu arbeiten.  Zu den damaligen Bedingungen der Ausbildung werde ich nochmal einen separaten Beitrag schreiben, das war stellenweise schon sehr abenteuerlich. Um 1999 registrierte ich dann auch mal die noch brachliegende Domain "Fachinformatiker.de". Vermutlich hätte ich damals auch eine Karriere als Domain-Broker starten können. Irgendwie hatten die Leute das Handeln mit den Domains noch nicht so auf dem Schirm, oder nur Wenige waren dort aktiv.
Ich habe mich dann doch für die IHK-Ausbildung entschieden und die Abschlussprüfung erfolgte im Mai 2000. Ich kann mich heute noch gut an die Prüfung, und insbesondere die Präsenation erinnern, der Eindruck ist geblieben, während z.B. die Erinnerung an die Zwischenprpüfung komplett fehlt. Anschließend schrieb ich zwei Bewerbungen, hatte dann ein Vorstellungsgepräch und wurde direkt genommen. War damals irgendwie ganz easy, oder vielleicht hatte ich einfach nur Glück. Den Arbeitgeber habe ich bis heute nicht gewechselt.

Ich startete als "IT-Support" in "meiner" Geschäftsstelle und betreute die Engeräte der Mitarbeiter, das Netzwerk und die Server.

Etwa 2005 wurde das Unternehmen durch einen französischen Konzern mit Hauptsitz in Paris gekauft, sowie Niederlassungen in D-A-CH, England, Frankreich, Spanien, Singapur. Support Prozesse wurden industrialisiert, wir haben ein "Global Delivery Center" in Polen und Indien.

2010 besuchte eine Fortbildung zum ITIL - Expert, und bin heute als "IT Service Manager" in einer international ausgerichteten Support Organsiation tätig.

Ich möchte hier bloggen über alle Themen die ich spannend finde, sowohl beruflich, als auch privat, eher organisatorisch, nicht zu technisch. Ich bin per PN oder über "Kontakt" erreichbar.

Hallo Community,

Ich bin der Zweite aus einem bisher schmalen Team von Bloggern auf fachinformatiker.de. Von mir gibt es in erster Linie fachliche Themen im Bereich der Windows-Administration, gepaart mit meinen Erfahrungen aus der Ausbildung, aber kommen wir erstmal zu meiner Person:
Bevor mein Username bei irgendjemandem die Party von letzter Woche, die leider auf der Toilette vorzeitig enden musste, wieder in Erinnerung ruft, eine kurze Erklärung: der Name und der zugehörige Avatar stammen von einem “Monster” aus Super Mario World für den SNES (Super Nintendo Entertainment System).
Ich bin der Lukas, ich bin 21 Jahre alt und stehe kurz vor meiner Abschlussprüfung. Das Fachinformatiker.de Forum verfolge ich seit Beginn meiner Ausbildung, lange Zeit ohne Account. Angestellt bin ich bei einem mittelständischen IT-Dienstleister in Schleswig-Holstein. Zurzeit bin ich offiziell noch Auszubildender Fachinformatiker für Systemintegration, in nur wenigen Monaten dann “IT-Systemadministrator”. Zu meinen primären Aufgabengebieten werden die Automatisierung mit Powershell, sowie die Verantwortung für unsere SharePoint-Infrastruktur gehören.
Was soll jetzt genau das Thema hier sein? In vielen Köpfen steckt immer noch Batch wie verankert fest. Ich habe heute noch Alpträume von dem Logon-Skript meiner Firma, das aus einem 2000 Zeilen Batch-Monster besteht. Viele Aufgaben die sonst viele Zeilen Code benötigen, werden durch Powershell auf meist eine Zeile reduziert. Das möchte ich hier demonstrieren. Das Ganze in Form von Beispielen, Erklärungen und best-practice-Empfehlungen. Best practice ist gleichzeitig der Untertitel des Blogs.

Ich stelle euch Lösungen aus der Arbeitswelt vor, die so funktionieren und eingesetzt werden. Das Microsoft TechNet ist zwar auch toll, teilweise aber sehr unübersichtlich und überladen, oft weicht die Praxis von dem ab was Microsoft sich vorstellt. Ganz nebenbei dürft ihr auch noch mit mir leiden, falls ich mir bei einem Problem den Kopf zerbrechen muss (das wird GARANTIERT passieren).





Desweiteren gibt es jedes Jahr die gleichen Themen im Forum. "Warum wurde mein Antrag abgelehnt?" oder "Wie lerne ich am besten für die Abschlussprüfung?". Mit meinen Erfahrungen aus der Zeit möchte ich angehenden Azubis eine Mischung aus Wissensdatenbank und Sammelstelle für immer-wieder-Problem-XYZ bieten. Kommentare mit eigenen Erfahrungen und speziellen Tipps und Tricks sind dort ausdrücklich erwünscht.
Zu guter Letzt möchte ich das Thema SharePoint mit einfließen lassen, allerdings erst zu einem späteren Zeitpunkt. Für viele ist SharePoint DAS Hassthema Nummer Eins, ich werde euch etwas die Panik davor nehmen und zeigen, dass in dem Produkt mehr steckt als nur nervige Berechtigungsstrukturen und Funktions-Wirr-Warr.
Natürlich behalte ich mir vor auch mal Themen anzuschneiden, die nicht genau in den Rahmen passen. Generell bleibt es selbstverständlich in der IT-Schiene, aber falls irgendeine Firma von heute auf morgen ein funktionsfähiges Hoverboard für 100$ anbietet, werdet ihr davon hier lesen!
Ich hoffe, dass ich euer Interesse wecken konnte. Ich freue mich auf den ersten “richtigen”, fachbezogenen Blog-Eintrag, eine mitwirkende Community und einen spannenden Austausch.
Grüße,
Blaaaaaargh aka Lukas 

Hallo Welt!
Nach langem Prokrastinieren und diversen mehr oder minder gut passenden Ausreden ist hier endlich der Eröffnungsbeitrag auf meinem Blog(bzw. in angepasster Form hier im Fi.De-Blog). Ich möchte an dieser Stelle ein bisschen was über mich erzählen, was ich hier schreiben möchte und warum ich das tue.
Mein Name ist Patrick, die älteren kennen mich hier noch unter "Zieg0re", die nicht ganz so alten unter "Goulasz". Ich bin mittlerweile fast 30 Jahre alt, verheiratet, Vater dreier bezaubernder Kinder(ein Sohn, knapp 3 1/2, zweieiige Zwillingstöchter im Alter von 20 Monaten) und hauptberuflich zumindest auf dem Papier "Datenbankentwickler". Das mache ich bei einem mittelständischen (IT-)Dienstleister für die Automobilindustrie im schönen Nordhessen.
Tja, und wie das in der IT(und eigentlich allem, wenn ich so drüber nachdenke) eben so ist, gibt es immer wieder Neuerungen, Änderungen, Anpassungen, die dein Weltbild in Schutt und Asche zu legen in der Lage sind. Darüber möchte ich hier schreiben. Dinge, die ich im Beruf oder privat erlebe, erfahre und die in Resonanz mit mir und meinem Leben geraten.
DevOps als namensgebendes Thema ist so ein "Ding". Jeder kennt das, in den meisten Fällen ist die unternehmenseigene IT ein "Mittel zum Zweck", eine nicht einsehbare, undurchsichtige Kiste, ja, Abteilung, in die man ein Problem reinwirft, sich ein bisschen darüber aufregt, wieso man keine Antwort bekommt, dann irgendwann doch eine bekommt und sich dann mehr oder weniger darüber freut. DevOps als Ansatz versucht, diesen unheiligen Zirkel zu durchbrechen, wieder echt und ehrlich miteinander zusammenzuarbeiten und Wert zu schaffen.
Die Allgemeine Systemtheorie ist noch so ein Thema. Durch einen guten Kollegen von mir und dessen Überzeugungsarbeit im Punkt Organisationsentwicklung bin ich auf Gerhard Wohlands "Denkwerkzeuge der Höchstleister" gestoßen. Das Buch, die Inhalte und die Art, Dinge zu betrachten begleiten mich seitdem in meinem Leben und machen mich, da bin ich der festen Überzeugung, ähnlich wie das Erfahren agiler Methoden zu einem besseren Entwickler, Vater und Menschen.
Dann gibt es da natürlich noch viel, viel technischen Krempel, der mich umtreibt und interessiert. Tools für automatische Tests, Datenqualität, Monitoring... Dinge wie Docker, Hadoop, die Sprache "R" und allgemeine Dinge zur Datenverarbeitung und -visualisierung beschäftigen mich akut sehr und ich gehe davon aus, bald einiges dazu zu bloggen und damit zu experimentieren.
Und last but not least gibt es natürlich auch viel, was mich in meiner Rolle als Vater und (Ehe-)Mann so beschäftigt. Seien es abgefahren nützliche Dinge wie dieser mitnehmbare Kindersitz für unterwegs, tolle Locations für Eltern mit ihren Kindern, Bücher und Filme zum Thema Bildung und Erziehung oder Erlebnisse, die für mich einschneidend waren.
Was das hier auf dem Blog zu suchen hat? Bei vielen Themen, die für mich eigentlich primär arbeitsrelevant sind(Agile Methoden, Systemtheorie, DevOps, Augenhöhe, etc.) stelle ich fest, dass die Inhalte sich auch auf mein Selbstbild als Vater beziehen lassen und andersrum. Grade die Themen, in denen "Empathie" eins der Hauptthemen ist - daher auch der Untertitel dieses Blogs "empathy rocks".
Denn sind wir mal ehrlich, ohne Empathie und ein Einfühlen und Eindenken in unser gegenüber, sei es das eigene Kind, ein Kollege, ein Kunde, der grade eine Anforderung beschreibt, kommen wir einer echten Lösung unserer Probleme auf Dauer nicht näher sondern bekämpfen nur Symptome, keine Ursachen.
Also, ich hoffe den ein oder anderen zum Schmunzeln zu bringen, Impulse zu stiften, zum Nachdenken anzuregen oder einfach nur zu unterhalten. Für Kritik bin ich immer zu haben, scheut euch also nicht, mit mir in Kontakt zu treten oder Beiträge hier zu teilen oder zu kommentieren!
Euer "devopsdad" Patrick aka Goulasz  

Hallo Welt!
Nach langem Prokrastinieren und diversen mehr oder minder gut passenden Ausreden ist hier endlich der Eröffnungsbeitrag auf meinem Blog(bzw. in angepasster Form hier im Fi.De-Blog). Ich möchte an dieser Stelle ein bisschen was über mich erzählen, was ich hier schreiben möchte und warum ich das tue.
Mein Name ist Patrick, die älteren kennen mich hier noch unter "Zieg0re", die nicht ganz so alten unter "Goulasz". Ich bin mittlerweile fast 30 Jahre alt, verheiratet, Vater dreier bezaubernder Kinder(ein Sohn, knapp 3 1/2, zweieiige Zwillingstöchter im Alter von 20 Monaten) und hauptberuflich zumindest auf dem Papier "Datenbankentwickler". Das mache ich bei einem mittelständischen (IT-)Dienstleister für die Automobilindustrie im schönen Nordhessen.
Tja, und wie das in der IT(und eigentlich allem, wenn ich so drüber nachdenke) eben so ist, gibt es immer wieder Neuerungen, Änderungen, Anpassungen, die dein Weltbild in Schutt und Asche zu legen in der Lage sind. Darüber möchte ich hier schreiben. Dinge, die ich im Beruf oder privat erlebe, erfahre und die in Resonanz mit mir und meinem Leben geraten.
DevOps als namensgebendes Thema ist so ein "Ding". Jeder kennt das, in den meisten Fällen ist die unternehmenseigene IT ein "Mittel zum Zweck", eine nicht einsehbare, undurchsichtige Kiste, ja, Abteilung, in die man ein Problem reinwirft, sich ein bisschen darüber aufregt, wieso man keine Antwort bekommt, dann irgendwann doch eine bekommt und sich dann mehr oder weniger darüber freut. DevOps als Ansatz versucht, diesen unheiligen Zirkel zu durchbrechen, wieder echt und ehrlich miteinander zusammenzuarbeiten und Wert zu schaffen.
Die Allgemeine Systemtheorie ist noch so ein Thema. Durch einen guten Kollegen von mir und dessen Überzeugungsarbeit im Punkt Organisationsentwicklung bin ich auf Gerhard Wohlands "Denkwerkzeuge der Höchstleister" gestoßen. Das Buch, die Inhalte und die Art, Dinge zu betrachten begleiten mich seitdem in meinem Leben und machen mich, da bin ich der festen Überzeugung, ähnlich wie das Erfahren agiler Methoden zu einem besseren Entwickler, Vater und Menschen.
Dann gibt es da natürlich noch viel, viel technischen Krempel, der mich umtreibt und interessiert. Tools für automatische Tests, Datenqualität, Monitoring... Dinge wie Docker, Hadoop, die Sprache "R" und allgemeine Dinge zur Datenverarbeitung und -visualisierung beschäftigen mich akut sehr und ich gehe davon aus, bald einiges dazu zu bloggen und damit zu experimentieren.
Und last but not least gibt es natürlich auch viel, was mich in meiner Rolle als Vater und (Ehe-)Mann so beschäftigt. Seien es abgefahren nützliche Dinge wie dieser mitnehmbare Kindersitz für unterwegs, tolle Locations für Eltern mit ihren Kindern, Bücher und Filme zum Thema Bildung und Erziehung oder Erlebnisse, die für mich einschneidend waren.
Was das hier auf dem Blog zu suchen hat? Bei vielen Themen, die für mich eigentlich primär arbeitsrelevant sind(Agile Methoden, Systemtheorie, DevOps, Augenhöhe, etc.) stelle ich fest, dass die Inhalte sich auch auf mein Selbstbild als Vater beziehen lassen und andersrum. Grade die Themen, in denen "Empathie" eins der Hauptthemen ist - daher auch der Untertitel dieses Blogs "empathy rocks".
Denn sind wir mal ehrlich, ohne Empathie und ein Einfühlen und Eindenken in unser gegenüber, sei es das eigene Kind, ein Kollege, ein Kunde, der grade eine Anforderung beschreibt, kommen wir einer echten Lösung unserer Probleme auf Dauer nicht näher sondern bekämpfen nur Symptome, keine Ursachen.
Also, ich hoffe den ein oder anderen zum Schmunzeln zu bringen, Impulse zu stiften, zum Nachdenken anzuregen oder einfach nur zu unterhalten. Für Kritik bin ich immer zu haben, scheut euch also nicht, mit mir in Kontakt zu treten oder Beiträge hier zu teilen oder zu kommentieren!
Euer "devopsdad" Patrick aka Goulasz