Usability-Tests – Empfehlung für die Praxis

​Heute wird so viel von Usability gesprochen und dass man überall Usability machen sollte, weil man damit alles etwas besser machen kann … JA, stimmt … und man sollte so viele Usability-Tests wie möglich machen, denn nur so kann man alle Fehler schnell finden … OK, das würde ich so nicht unterstützen … und außerdem bekommt man die Kosten, auch bei sehr vielen Tests, durch die verkürzte Entwicklungs- und Testzeit wieder rein … OK, jetzt bin ich raus!

Es gibt so viele Usability-Tests und die meisten haben bestimmt hier und da ihre Daseinsberechtigung, aber viele Tests können schnell teuer werden und bringen meist quasi keinen oder nur einen kleinen Nutzen. Oder bringen Verwirrung oder geben vielleicht sogar eine falsche Richtung vor.

Beispiel: EyeTracking

Die Personen sind alleine vor ihrem Rechner und arbeiten frei mit der Anwendung oder arbeiten Aufgaben ab. Jetzt schauen 2 oder 3 User der Gruppe häufig in dieselbe Ecke. OK, wir wissen jetzt, das der User in die Ecke schaut, aber warum können wir nur vermuten. Vielleicht ist da ein Icon was der Person gefällt oder sie an etwas erinnert, etwas das ihnen nicht gefällt … Alles Vermutungen und vielleicht hat jeder einen anderen Grund… In den meisten Fällen bringt dieser Test nur sehr wenig und Aufwand und Kosten sind recht hoch, weil es Zeit, Probanden und Ausstattung kostet.

Hier sind ein paar Tests, die Sie als Grundlage nutzen sollten. Je nach Einsatzgebiet könne Sie diese Tests natürlich sinnvoll erweitern. Aber halten Sie die Menge der Tests möglichst klein.

Für die Praxis empfehle ich 3 Schritte, die dann während der Entwicklung in einem Kreislauf durchlaufen werden können und auch sollten.

  1. Kundenworkshops
  2. Mockups und Reduzierte Prototypen
  3. Prototyp und Vereinfachte Benutzertests

 

1. Kundenworkshops

Einer der wichtigsten Punkte bei gutem Usability Engineering sollte immer der Kontakt mit dem Kunden bzw. dem wirklichen Endanwender sein. Auch wenn man glaubt die Probleme zu kennen, der Endanwender kennt sie immer etwas besser.

Erstkontakt und „Das Kind des Kunden“ erkennen… Als ersten Kontakt zwischen Kunde und Usability Engineer sollte der Workshop das Mittel der Wahl sein und die Besetzung durch den Kunden sollte möglichst homogen sein. Haben Sie im Workshop nur Personen aus dem Management, bekommen Sie zwar einen guten Überblick über die Anforderungen, erkennen aber vielleicht nicht alle Probleme der täglichen Arbeit, die nur der Endanwender kennt.

Bei Workshops in denen Sie die Probleme mit dem Kunden betrachten sollten die Lösungsvorschläge und Anforderungen auf rein fachlicher Ebene betrachten. Die Implementierung bzw. Umsetzung sollte in diesem Kontext nicht thematisiert werden! Als Außenstehender können Sie nicht einschätzen, ob es innerhalb des Kunden schon Meinungen für oder gegen eine Lösungsvariante gibt. Sollten Sie also so einen Punkt mit einer konkreten Umsetzungsmöglichkeit ansprechen, kann es schnell zu Diskussionen führen und der Workshop schnell in eine falsche Richtung gehen. Außerdem weiß der Kunde zwar oft was er will, aber nicht was er wirklich haben kann und was eigentlich möglich ist.

Bei einem Workshop mit ihrem Kunden, kommt es in erster Linie darauf an zu erkennen was der Kunde will und wonach er sucht. Die meisten Kunden haben ein Problem das gelöst werden soll und dafür werden Sie gerufen!

 

2. Mockups und Reduzierte Prototypen

Der nächste Schritt nach dem Workshop ist das Finden von potentiellen Lösungsmöglichkeiten. Da die möglichen Lösungen bisher nicht thematisiert wurden können Sie dem Kunden nun verschiedene Möglichkeiten aufzeigen. Häufig hat der Kunde zwar schon eine Vorstellung von dem was er haben möchte, aber eben nicht davon was er haben kann und was möglich wäre. Sie sollten dem User jetzt aber nicht nur Premiumlösungen zeigen, die später sein Budget sprengen. Erstellen Sie mehrere Varianten, damit der Kunde die für sich passende Lösung finden kann.

Warum nur Mockups und Reduzierte Prototypen?

Selbstverständlich macht ein Prototyp in Form eines professionellen Renderings oder gar in lauffähiger Form mehr her, aber bedenken Sie, dass Sie noch in der Phase der Lösungsfindung sind. Ein Prototyp sollte nur so konkret wie nötig sein. Zu viel Design lenkt von der Lösungsfindung ab und bietet Potential für die Diskussionen die nicht in den Kontext der Usability gehören. Das UX-Design ist ein Bereich der später einfließen kann und außerdem sind Mockups und Papierprototypen unschlagbar günstige Varianten, die zudem noch in Echtzeit änderbar sind.

Besprechen Sie die Mockups mit dem Kunden und lassen Sie Wünsche oder Verbesserungen des Kunden in die Konzepte einfließen. Diese Absprachen sollten Sie solange wiederholen bis der Kunde zufrieden ist. Durch die vielen möglichen Änderungszyklen zeigt sich wieder warum Mockups und Papierprototypen wesentlich billiger sind als Renderings oder lauffähige Prototypen.

 

3. Prototypen und vereinfachte Benutzertests

Jetzt ist ein erstes Lösungskonzept mit dem Kunden abgestimmt und Sie können sich mit der Umsetzung der ersten lauffähigen Prototypen beschäftigen. Auch hier sollten Sie noch nicht zu viel Zeit in die Schönheit der Oberflächen investieren, denn Usability ist nicht „Schöne Masken und runde Ecken“… aber die Zeiten von Windows 98 sind auch vorbei!

Bevor Sie mit der Implementierung starten ist es ratsam sich Aufgaben/Storys zu überlegen die die User später im Zuge der Benutzertests erledigen sollen. Hiermit legt man auch schon eine Reihenfolge für die Implementierung der Masken und Features fest.

Wenn alle Masken und Features zu einer Aufgabe/Story implementiert sind wird es Zeit für die Tests mit Usern. Hier eigenen sich besonders die „Thinking Aloud Tests“ um schnelle und günstige Ergebnisse zu erzielen. Durch diese Art der Tests gewinnen Sie aber nur Erkenntnisse aus den subjektiven Eindrücken der User. Aussagen über Punkte wie z.B. Performance können hierbei nicht getroffen werden. Ein System sollte weitestgehend selbsterklärend sein, den User bei seiner Arbeit unterstützen und ihm Aufgaben abnehmen und genau zu diesen Punkten liefert dieser Test die nötigen Erkenntnisse.

Da es die Nutzer meist nicht gewohnt sind alles zu kommentieren was Sie denken, startet ein Test meist schleppend und die Benutzer werden mit der Zeit auch wieder ruhiger oder verstummen. Um diesem Verhalten vorzubeugen kann es auch ein adäquates Mittel sein den Test mit 2 Usern pro System durchzuführen, da die User so in einen Gesprächsfluss kommen. Außerdem sollte ein Test immer anonym durchgeführt werden damit sich ein User sicherer fühlt. Der Usability Engineer macht sich während des gesamten Tests Notizen um die Aktionen und Auffälligkeiten zu protokollieren.

Die so gesammelten Daten wertet der Usability Engineer später aus und die Erkenntnisse fließen zurück in die Lösungskonzepte, die wieder mit dem Kunden im Zuge von Workshops und Mockups besprochen werden.

Wir wären also wieder bei den Workshops und der Kreislauf schließt sich.

Veröffentlicht unter Software Engineering | Kommentar hinterlassen

Datenmodellierungsübung an der der TH Köln

Heute sind Janine Ellner, Thomas Kopp, Fabian Hardt und ich nicht zum Kunden gefahren, sondern zur TH Köln (Campus Gummersbach). Wir haben dort eine Übung zu der Veranstaltung Betriebliche Anwendungssysteme 1 (BA1) gehalten.

Begonnen haben wir die Übung mit dem folgenden Architekturbild eines Data Warehouses:

DWH-Architektur.png

Der Sinn eines Data Warehouses ist die Konsolidierung und Aufbereitung verschiedener Datenquellen. Dies können hierbei ERP-Systeme, Flat Files, externe Schnittstellen und vieles mehr sein. Diese werden zunächst – in der Regel – 1:1 in die Staging Area geladen. Im Core-Data Warehouse werden die Daten aus der Staging Area klassicher Weiser in einem 3NF-Modell abgebildet. 3NF steht für die 3. Normalform und entspricht einem Normalisierungsgrad der Datenbank, welcher Redundanzen und Anomalien vermeidet.
Im Data Mart des Data Warehouses liegt der Fokus auf der Abbildung der fachlichen Welt. Hier bewegen wir uns im multidimensionalen Raum. Im Data Mart werden Dimensionen und Fakten aufgespannt, um so die Abfrageperformance für den Endanwender zu optimieren und eine einfache Auswertung der Daten zu ermöglichen.

Bevor die tatsächliche Modellierung beginnen konnte, haben wir Begriffe Dimensionen und Fakten noch einmal kurz erläutert. Dimensionen beschreiben ein Objekt, typische Beispiele hierfür sind Produkt, Kunde und die Zeit. Solche oder so ähnliche Dimensionen befinden sich in den meisten multidimensionalen Data Marts. Dimensionen enthalten Attribute, welche die Eigenschaften eines Objektes beschreiben. Dimensionen verändern sich über die Zeit und wenn man diese Veränderungen auch im Nachhinein betrachten möchte, benötigt man hierfür ein Historisierungskonzept. Dabei wird sehr häufig das Prinzip der „Slowly Changing Dimensions“ genutzt, insbesondere der Typ 2. In diesem Fall werden Gültigkeitsstempel beispielsweise „GÜLTIG_VON“ und „GÜLTIG BIS“ verwendet. Allerdings gibt es auch Data Warehouse-Systeme die stets nur den aktuellen Stand anzeigen und keine Historisierung benötigen.
Fakten hingegen enthalten Kennzahlen, also numerische und meist additive Werte.
Beispiele hierfür sind Anzahlen, Kosten und Mengen.  Der Primärschlüssel einer Faktentabelle setzt sich üblicherweise aus den Fremdschlüsseln zu den verknüpften Dimensionen zusammen. Wichtig bei Fakten ist die Granularität. Je atomarer die Faktentabelle aufgebaut wird, desto mehr Flexibilität hat der Anwender bei der Auswertung. Allerdings hat die Faktentabelle dadurch einen größeren Umfang und kann somit zu Performanceproblemen führen. Hier gilt es zwischen der fachlichen Notwendigkeit des Detailgrades und dem technischen Gegebenheiten abzuwägen.

Ziel der Übung war die Überführung eines Core-Datenmodells in ein Data Mart-Datenmodell.

Basierend auf dem folgenden Core-Datenmodell sollten die Studenten unter anderem folgende Fragestellungen mit einem Data Mart-Datenmodell abbilden:

  • Wie viele Buchungen gab es im letzten Monat?
  • Wie viele Buchungen gab es pro Agent im letzten Jahr?
  • Wie viele Stornierungen gab es im letzten Monat?

Core-Modell.png

Die Fragestellungen sind bewusst sehr unspezifisch gehalten, damit rege Diskussionen entstehen können.
Außerdem haben wir offen gelassen, ob ein Star- oder Snowflake Modell für den Data Mart entworfen werden soll. Allerdings sollten die Studenten Ihre Entscheidungen begründen können.

Bei einem Star Modell steht eine Faktentabelle im Zentrum und ist mit den dazugehörigen Dimensionen direkt verknüpft.

Star_Schema.png

Das Star-Modell ist dementsprechend ein denormalisiertes Modell. Es sind Redundanzen vorhanden und diese erzeugen einen etwas höheren Wartungsaufwand. Diesen nimmt man aber gern in Kauf, da die Queries eines Star-Modells weniger komplex sind als die eines Snowflake-Modells.

Das Snowflake-Modell ist eine Weiterentwicklung des Star-Modells. Hier werden die Dimensionen normalisiert, das heißt falls möglich in verschiedene Tabellen hinunter gebrochen.

Hier ein Beispiel für ein Snowflake-Modell:

Snowflake Schema.png

Dadurch, dass das Snowflake-Modell mehr Tabellen als das Star-Schema enthält, werden je nach fachlicher Fragestellung mehr Joins benötigt, um eine Query abzubilden.

Nach ungefähr einer Stunde Diskussionen, Austausch und Modellierungsarbeit haben wir gemeinsam die Ergebnisse besprochen. Wir haben bereits zu Beginn angekündigt, dass es vollkommen legitim ist, wenn die Gruppen unterschiedliche Ergebnisse hervorbringen. Auch unsere Lösung ist lediglich eine Beispiellösung, die auf verschiedenen Annahmen basiert.

Mart Modell.png

Mit dem obigen Datenmodell für den Data Mart können wir die Frage, wie viele Buchungen es im letzten Monat gab mit Hilfe der Tabelle Fact Booking (Booking Count) und der Dim Time (Month) abbilden. Um herauszufinden, wie viele Buchungen die jeweiligen Agenten im vergangenen Jahr getätigt haben, benötigen wir erneut die Fact Booking (Booking Count), die Dim Agent (Last Name) und die Dim Time (Year).

Damit wir die Anzahl der Stornierungen im letzten Monat berechnen können, benötigen wir den Cancellation Count aus der Fact Booking und dazu das Cancellation Date aus der Dim Booking.

Auch bei den Kennzahlen haben die Gruppen verschiedene Definitionen und Annahmen getroffen. In der Praxis würde man die Kennzahlendefinition mit dem Fachbereich des jeweiligen Unternehmens besprechen.

Wir hoffen, dass wir mit unserer Übung den Studenten unseren Alltag in der Praxis näher bringen konnten und der ein oder andere so viel Spaß an der Datenmodellierung hatte, dass er sich seine berufliche Zukunft in der BI-Welt vorstellen kann.

Clarissa

 

Veröffentlicht unter Analytics & BigData, News, OC Inside | Verschlagwortet mit , | Kommentar hinterlassen

AWS News KW 49 – 52

Nach der re:invent Anfang Dezember fühlt es sich an, also ob AWS sich in den Winterschlaf verabschiedet hat. Ganz ohne Neuigkeiten kamen aber auch die letzten Wochen des Jahres 2017 nicht aus.

Zwei neue Regionen

Im Dezember erblickten zwei neue AWS Regionen das Licht der Welt. Zum einen ist das China (Ningxia) und für den Europäer wichtiger EU (Paris).

Damit erhöht sich die Zahl der Regionen in Europa auf 4 und in China auf 2. Insgesamt stehen damit 17 Regionen zur verfügung.

Weitere Informationen zu den Regionen hier.

Neuer Amazon CloudWatch Agent

AWS hat einen neuen CloudWatch Agent veröffentlicht, der sowohl auf Cloud sowie on-premise Instanzen laufen kann. Er unterstützt dabei Linux sowie Windows Server. Die wichtigsten Features sind:

  • Single Agent: Der Agent sammelt Metriken und Logfiles gleichermaßen.
  • Cross-Platform / Cross-Environment: Der Agent läuft in der Cloud und on-premise. Unterstützt 64-bit Linux und 64-bit Windows
  • Configurable: Der neue Agent sammelt die wichtigsten Metriken automatisch, kann aber so konfiguriert werden, das viele andere ebenfalls überwacht werden.
  • CloudWatch-Friendly: Der neue Agent unterstützt 1-Minute Metriken sowie die neuen 1-Second high-resolution Metriken für CloudWatch.

Weitere Informationen zum neuen CloudWatch Agent hier.

Amazon Linux 2

Amazons Basis Linux Distribution ist in Version 2 verfügbar. Einige der neuen Features sind:

  • Long-Term Support: Der Amazon Linux 2 LTS build bietet Security Updates, Bugfixes und API Kompatibilität für 5 Jahre und ist für alle Nutzer gedacht die über einen längeren Zeitraum auf der gleichen Linux Basis bleiben wollen.
  • Systemd: Als init System.
  • Wide Availability: Amazon Linux 2 ist in allen AWS Regionen als AMI, Docker Image oder Virtual Maschine Image verfügbar.

Weitere Informationen zu Amazon Linux 2 hier.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

München Coding Dojo Meetup

In der Münchner Niederlassung hatten wir dieses Jahr schon viele spannende und spaßige Coding Katas. Am 30.11.2017 fand die Kata nun zum ersten Mal im neuen Meetup-Format statt. Für dieses Event reiste unser OC|Lab Guru Philipp Perez extra aus Hamburg an und gab uns eine Einführung in Docker.

Das Event

Die Meetup-Gruppe München Coding Dojo Meetup hatten wir drei Tage zuvor spontan gegründet und das Event gepostet. An dem Tag der Kata schneite es in München zum ersten Mal (siehe Fotos). Trotzdem kamen von den 28 angemeldeten Teilnehmern fast 20, was in unseren Augen einen echten Erfolg darstellt. Den übrigen war es wahrscheinlich zu kalt 😉 und zu weit draußen.

11
Tagsüber war das Wetter noch ok.
2
Am Abend schneite es und war echt kalt und winterlich …
3
Und wir sorgten dafür, dass die Teilnehmer bei uns in der Niederlassung gut mit Knabbersachen und Getränken versorgt waren.

Der Abend

Um 18 Uhr fingen wir an. Die erste halbe Stunde begrüßten wir die Gäste und begannen mit der Networking-Session. Aus Nürnberg schalteten sich unsere Kollegen Waldemar, Karina, Attila und Dong dazu, die an der Kata remote teilnahmen.

Wir hatten auch mit technischen Problemen zu kämpfen. Die Anmeldung in unserem Gast-WLAN klappte nicht bei allen Besuchern unseres Meetups. Und die Skype-Verbindung nach Nürnberg war leider sehr instabil. Die Bildübertragung funktionierte. Die Audio-Übertragung brach aufgrund von Netzwerkproblemen häufig ab, sodass wir auf ein Handy umsteigen mussten. Auch der Handyempfang war leider nicht optimal, doch auf jeden Fall konnten unsere Nürnberger Kollegen uns wieder hören, wohingegen auf unserer Seite der Leitung nur „Klingonisch“ ankam.

Überraschend war für uns, dass die meisten Teilnehmer die Software VirtualBox von Oracle weder kannten noch installiert hatten. Durch diesen Umstand verloren wir zum Anfang der Veranstaltung etwas Zeit, bis wir dann beginnen konnten. Unser Learning hieraus: Bei der Meetup-Einladung ganz klar alle technischen Voraussetzungen (VirtualBox sollte installiert sein) angeben und eventuell unsere VM bereits im Voraus zum Download anbieten.

Im ersten Teil der Kata erläuterte Philipp die Theorie und Funktionsweise von Docker.

4
Die theoretische Einführung dauerte bis 20 Uhr.

Agenda (1. Teil):

  • Getting Started with Docker (Theory)
  • Docker Container Platform
  • Containers vs. Virtual Machines
  • Docker Terms: Docker Layer, Docker Image, Docker Container and Dockerfile
5
Wo sind denn alle?
ok
Ach ja, wir hatten Pizza für das Abendessen und dabei lernten wir auch die externen Gäste kennen.

Im zweiten Teil gingen wir gemeinsam Schritt für Schritt den Workflow von Docker anhand einer Golang-Anwendung durch. Zum Abschluss bekamen alle die Aufgabe, eine Python-Anwendung in einem Container zu verpacken und das fertige Image über eine Docker Registry bereitzustellen.

Agenda (2. Teil):

  • Working with Docker (Practice)
  • Pulling Docker Images
  • Running Docker Containers
  • Building Images
  • Publishing Images to a Docker Registry
  • Sharing Data with your containers
  • Useful Docker Commands
  • Docker on Windows
  • Exercise: creating a Docker image for a python app
7
Philipp half jedem gern. Arthur programmierte sogar ohne Laptop. Mit Docker und OC ist alles möglich, oder? 😉
8
Die Aufgaben waren nicht einfach. Dank des guten Teamworks schafften es alle.
9
Das Event dauerte bis 22 Uhr. Was uns sehr gefreut hat, ist, dass fast alle externen Gäste bis zum Ende geblieben sind!

An dieser Stelle abschließend noch ein Dankeschön an:
Philipp, der eine super Veranstaltung vorbereitet und durchgeführt hat!
Verena für Inspiration und Vorbereitungen.
Ulli für Snacks!

Das Feedback von MeetUp Event

(München Coding Katas MeetUp)

Zitat von Teilnehmer Ludwig:

„Das Meetup hat mir trotz technischer Schwierigkeiten gefallen und war sehr informativ. Hier könnte man vielleicht vorab in der Beschreibung bereits die Voraussetzungen für das Meetup nennen um eine Vorbereitung vor allem für außenstehende zu ermöglichen. Sonst top und (hoffentlich) bis zum nächsten Mal.“

Zitat von Teilnehmer Alois:

„Ich hatte keine techn. Probleme. Ludwig’s Feedback ist eine gute Idee. (Tech und Know-how Voraussetzungen)
Gibt‘s die Folien noch? Den Part mit der Docker Registry konnte ich nicht mitmachen.
Orga, Location sowie Vortrag waren echt klasse.“

Die Zukunft

Wir haben den Eindruck gewonnen, dass alle Teilnehmer mit der Kata glücklich und zufrieden waren. Das motiviert uns, direkt weiter zu machen. Daher wird es am 09.01.2018 bereits das nächste München Coding Dojo Meetup zu Amazon Alexa 101 geben! Vorgetragen wird das Thema von unserem Developer und Bastler Tomasz Krajewski. Und es sind weitere Meetups für 2018 in Planung – es lohnt sich also in Hörweite zu bleiben 😉!

Veröffentlicht unter News, OC Inside | Verschlagwortet mit , , | Kommentar hinterlassen

Alle Jahre wieder… was macht ein Berater so bei OC? (3. Advent)

In den letzten zwei Beiträgen habe ich euch über die Zeit von Ende 2016 bis hin zum September diesen Jahres berichtet. Heute möchte ich euch erzählen, wie mein Jahresende bei OC ausgesehen hat bzw. aussehen wird.

Oktober bis November 2017
Im Oktober hat für mich ein kleiner Schulungs- und Konferenzmarathon begonnen. Ich habe dieses Jahr an der TDWI Advanced BI-Engineering Schulung teilgenommen. Diese setzt sich zusammen aus einem Pflichtmodul Strategie & Governance sowie zwei Wahlmodulen. Bei den Wahlmodulen habe ich mich für Big-Data-Technologien und ETL- Architektur und Modellierung von ETL-Prozessen entschieden. Die Seminare sind sehr interessant gewesen und sind von sehr fachkundigen Referenten gehalten worden. Für Big-Data-Technologien hat es mich nach Frankfurt verschlagen, für Strategie & Governance nach Stuttgart und für das ETL-Seminar nach Hamburg. Drei sehr verschiedene Städte, aber alle mit ihrem ganz eigenen Charme. Die Schulung wird mit einer Zertifizierungsprüfung abgeschlossen, welche aktuell noch aussteht.

Außerdem habe ich im Oktober noch die Data Modeling Zone in Düsseldorf besucht. Das ist eine zweitägige internationale Konferenz mit diversen Vorträgen zum Thema Datenmodellierung. Bei der Data Modeling Zone hat insbesondere Data Vault im Vordergrund gestanden. Hier ist es spannend gewesen über die internationalen Unterschiede zu diskutieren. Denn so verbreitet wie das 3NF-Core Modell in Deutschland ist, so ist es das in den USA nämlich nicht. Neben interessanten Vorträgen und sehr guten Speisen hat es genügend Gelegenheit gegeben neue Kontakte zu knüpfen. Außerdem haben dort Anbieter von Data Vault-Automatisierungstools dort ihren Stand aufgebaut gehabt und sind bereit gewesen Fragen zu beantworten.

Im Oktober hat es noch eine sehr abwechslungsreiche und spaßige Aufgabe für mich gegeben. Ich habe Teil unserer Marketing-Kampagne für #meinlieblingsjob sein dürfen. Im Rahmen dieser Kampagne wollen wir auf einem eher unkonventionellen Weg zeigen, für welche Werte wir im Unternehmen stehen. Ja, wir bieten hochprofessionelle Dienstleistungen an, aber wir sind trotzdem eine Familie! Die OC-Familie ist füreinander da und hat gemeinsam Spaß! Vor dem Videodreh war ich doch etwas aufgeregt. Ich bin mit drei verschiedenen Outfits und jeder Menge Vorfreude nach Gummersbach angereist. Vor Ort ist dann schon ein Profi-Team mit einer Kamera, Drohne und einer Tonangel, die ich sonst nur aus dem Fernsehen kannte gewesen. Der Videodreh hat sehr viel Spaß gemacht und schaut selbst was dabei herum gekommen ist: #meinlieblingsjob  (auf “ Spiel Starten“ klicken).

Dezember 2017
Nun sind wir schon im Dezember. Wenn ich mir so anschaue, wie viel Spannendes, Weiterentwicklung und Lehre darin steckt, bin ich baff.

Am zweiten Wochenende im Dezember hat unsere Weihnachtsfeier statt gefunden! Für die Kollegen aus der Niederlassung Gummersbach hieß es : „Ab aufs Schiff!“. Wir sind von Köln nach Düsseldorf geschippert und haben uns dabei an einem sehr reichhaltigen und leckerem Buffet die Bäuche voll geschlagen. Begleitet wurde das gute Essen mit dem Duft von Glühwein, den es an Board gab. Auf dem Rückweg von Düsseldorf nach Köln habe ich die Zeit genutzt mit den Kollegen zu sprechen, die ich nicht allzu oft sehe. Trotzdem habe ich auch spannende Gespräche mit den Kollegen, die ich täglich im Büro sehe, geführt. Das Schöne an der Weihnachtsfeier – wie auch beim Sommerfest – ist, dass auch hier die Partner und Partnerinnen herzlich Willkommen sind. Die Weihnachtsfeier auf dem Schiff ist etwas Besonderes gewesen und hat viel Spaß gemacht!

Nun freue ich mich auf die letzten drei Tage beim Kunden und dann heißt es Entspannung und Festessen für mich!

Euch allen einen schönen 3. Advent und frohe Weihnachten. Und einen guten Rutsch!
Clarissa

Veröffentlicht unter News, OC Inside | Kommentar hinterlassen

Alexa for Business: was ich jetzt wissen muss

Amazon hat Ende November auf der AWS Reinvent neben der Ankündigung von Notifications und Stimmerkennung  auch Alexa for Business (A4B) enthüllt.

Mit dieser Plattform sollen Amazons Sprachassistenten nicht mehr nur in zig privaten Haushalten, sondern zukünftig auch im Büro Einzug nehmen. Dort können zum Beispiel Besprechungen per Sprache gestartet, Geräte in Konferenzräumen gesteuert oder wiederkehrende Aufgaben am Schreibtisch automatisiert werden.

 

Was muss ich wissen, wenn ich Alexa for Business jetzt in meinem Unternehmen einführen möchte?

Weiterlesen

Veröffentlicht unter IoT & Industry 4.0 | Verschlagwortet mit , , , , , , | Kommentar hinterlassen

Global Day of Coderetreat der JUG Essen

Am 18.11.2017 haben wir an unserem Standort in Essen erneut am Global Day of Coderetreat (GDCR) teilgenommen.

Neben Kollegen von OPITZ CONSULTING konnten wir auch mehrere Studenten aus Bochum und Dortmund als Teilnehmer gewinnen. Moderiert und durch den Tag geführt haben unser Experte Halil Hancioglu und Birgit Kratz von der JUG Essen – Vielen Dank an dieser Stelle!

Beim GDCR haben Entwickler aller Erfahrungsstufen die Möglichkeit, ohne Zeitdruck an ihren Fertigkeiten zu feilen. Es wird generell im Paar und idealerweise „Test first“ gearbeitet. Unter Beachtung der Four Rules of Simple Design haben wir auch diesmal die Kata Game of Life bearbeitet. An diesem Tag ging es wie immer um das Meistern der Übungen ohne den täglichen beruflichen Stress. Der Fortschritt stand nicht im Fokus. Nach jedem 45-Minuten-Block wurde der Code gelöscht und es wurden neue Paare gebildet. Für jede Iteration überlegten sich die Moderatoren neue Challenges.

fullhalf

Insgesamt war das Feedback für die Veranstaltung sehr positiv, und wir überlegen gerade, ob wir Veranstaltungen dieser Art im kleineren Rahmen – kein kompletter Samstag – öfter anbieten sollten. Das Feedback der Studenten war sehr positiv, und der Wunsch nach mehr Werbung an den Unis für solche Events wurde auch mehrmals geäußert.

Ich möchte mich noch einmal bei allen Beteiligten bedanken, besonders bei Hannes für die Unterstützung bei der Organisation und Petra für die super Verpflegung.

Die Planungen für das nächste Jahr laufen bereits! Weitere Infos gebe ich gerne auf Anfrage.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen