Amazons Alexa als Vertriebsunterstützung?

Intelligente Assistenten, wie Amazons Alexa, Apples Siri oder Google ziehen in immer mehr Haushalten ein.

Auf Zuruf kann man den Wetterbericht abrufen, nach der Uhrzeit fragen oder sich nach den Abfahrtszeiten der Bahn erkundigen.

Bei RockingBit experimentieren wir damit, ob sich diese digitalen Assistenten für die Beratung komplexer Produkte eignet.

Hierfür verwenden wir Amazons Echo Dot.

Amazon stellt für Entwickler ein umfangreiches Ökosystem zur Verfügung, mit dem man sogenannte Alexa Skills entwickeln kann.

Diese Skills werden dann vom Anwender für den Echo Dot konfiguriert und sind dann als neue Fähigkeit (Skill) nutzbar.

Damit Alexa weiß, welche Skill aktiviert werden soll, wird ein Schlüsselwort konfiguriert. Erkennt Alexa ein Schlüsselwort, werden die Daten an den entsprechenden Dienst weitergeleitet.

Hierbei werden die gesprochenen Daten in Text umgewandelt und an den entsprechenden Server geschickt.

Beispiel:

Alexa, frage Paketdienst, wann kommt mein Paket 4711 an?

Paketdienst ist hierbei das Schlüsselwort zur Auswahl des Skills
wann kommt mein Paket ist der sogenannte Intend, die eigentliche Frage.
4711 ist ein variabler Parameter, der an den Backend-Service übergeben wird.

Der Backend-Service sucht die entsprechenden Daten heraus und gibt sie in Textform an den Alexa-Dienst zurück. Dieser wandelt die Antwort in Sprache um und gibt sie an den Echo Dot zurück.

Durch bestimmte Markup-Angaben im Antworttext kann man die Antwort lebendiger erscheinen lassen.

Für die ersten Tests ist der Amazon Lambda Service sehr gut geeignet. Man muß dabei keine eigene Server Infrastruktur aufbauen, sondern nutzt die Lambda Funktion.

Hierbei lädt man eine entsprechende Jar-Datei hoch und verbindet diesen Lambda-Dienst mit der Alex-Skill.

Für einfache Sprach-Interaktionen ist Alexa schon ziemlich gut geeignet.

Bei komplexeren Aufgaben, z.B. bei der Wertpapierberatung, klappt es noch nicht ganz so gut.

Komplexe Dialoge folgen anderen Regeln als einfache Frage- / Antwort-Paare. Der Kontext des Dialogs muss beibehalten werden, falsche Angaben müssen korrigiert werden können.

So wurden mir statt eintausend Audi-Aktien in den Warenkorb gelegt, eintausend Audi auf die Einkaufsliste gesetzt.

Die Entwickler von Alexa hatten vermutlich so komplexe Interaktionen noch nicht auf dem Radar, bestimmt aber schon im Hinterkopf.

Gerade im Deutschland ist der Erwerb von Wertpapieren gesetzlich strengen Regeln unterworfen.

Einen Teil davon interaktiv und automatisiert durchzuführen wäre sowohl für Käufer, als auch für Berater eine enorme Erleichterung.

Zum Beispiel könnte Alexa einem Interessenten Informationen über Aktienverläufe, Risiken und Preise sagen und bei weiterem Interesse Produktinformationen per E-Mail versenden.

Im Prinzip kann Alexa bei richtig programmierten Skills und entsprechenden Backend-Daten durchaus aus Vertriebsunterstützung eingesetzt werden. Die Einsatzszenarien sind allerdings noch begrenzt und man muß sehr genau auf eine gute User-Experience achten. Cool ist es auf jeden Fall und hat sehr viel Potential für die nähere Zukunft.

Wir arbeiten weiter an diesem Thema und schauen, ob uns die anderen Angebote von Amazon auf dem Gebiet der künstlichen Intelligenz – wie Lex oder Amazon Polly – weiterbringen.

Architekturkonzepte aus der Vergangenheit

Beim Durchsuchen alter Projektunterlagen ist mir dieser Entwurf eines Architekturkonzeptes in die Hände gefallen.

Es handelte sich um eine ziemlich komplexe Anwendung für Bankberater und Beratungsprotokolle nach WpHG – und dies war nur ein kleiner Ausschnitt.

Solche Bilder entstehen oft innerhalb weniger Minuten und zeigen die einzelnen Komponenten und wie sie zusammenspielen. Zudem unterschiedliche Arten von Dokumenten, Übertragungsarten, usw.

Auf den ersten Blick total krakelig, besitzen diese Grafiken eine sehr hohe Informationsdichte.

Die Ausarbeitung jeder hier dargestellten Komponente füllt noch einmal viele weitere Seiten und sie bilden immer nur einen Blick aus 20.000 m auf das System ab.

Nachdem dieses Grobkonzept fertig ist, werden die Epics und Stories dazu geschrieben und in die Entwicklung gegeben.

Auch in Zeiten der agilen Programmierung werden so komplexe Architekturkonzepte benötigt, damit das Gesamtkonzept klar ist und alle benötigten Komponenten und Kommunikationswwege bekannt (aber nicht unbedingt spezifiziert) sind.

Diese Konzepte bilden die Landkarte, mit der man durch den Entwicklungsprozess navigiert.

Über die Jahre habe ich viele Notizbücher mit Ideen und Skizzen gefüllt.

Für diese Architekturkonzepte gibt es eine Apps, die bei er Erstellung helfen würden. Die Bedienung der Programme kostet einen großen Teil der Aufmerksamkeit und Kreativität, daher sind Papier und Bleistift das Mittel der Wahl.

Wobei auch hier der Fortschritt Einzug gehalten hat: Mittlerweile entstehen Skizzen dieser Art bei mir auf dem iPad Pro mit Stifteingabe.

Nur wenn es ganz komplex wird greife ich lieber wieder zu Papier und Bleistift.

First Things First

First things first – das wichtigste zuerst.

Dieser Grundsatz gilt in Projekten mit komplexen Schnittstellen zu Fremdsystemen – besonders, wenn diese von externen Firmen angeboten werden und über das Internet erreichbar sind.

Das „wichtigste“ in diesem Fall wäre der „technische Durchstich“, z.B. das Aufrufen der Schnittstelle mit Hilfe eines einfachen Prototypen.

Da zumeist alle weiteren Funktionen des Systems um diese zentrale Schnittstellenfunktion herum aufgebaut werden, ist der technische Durchstich von großer Wichtigkeit.

Das zum Einsatz kommende Programm muss dabei keine Produktionsqualität haben, ein einfach zusammengebastelter Prototyp als Proof of Concept ist vollkommen ausreichend.

Mit Hilfe des PoCs wird u.a. geprüft, ob …

  • die benötigten Ports und IP-Ranges in der Firewall freigeschaltet sind.
  • die Schnittstellendokumentation korrekt ist.
  • auf der Gegenseite die Schnittstellen verfügbar sind.
  • die Zugangsdaten korrekt sind.
  • SLAs bezüglich der Verfügbarkeit und Performance eingehalten werden.
  • VPN Tunnel funktionieren.

Gerade in großen Unternehmen kann jedes dieser Punkte das Projekt sofort um Wochen aus dem Zeitplan bringen, müssen z.B. Ports in der Firewall freigeschaltet werden.

Zu Beginn eines Projektes ist in der Regel noch genügend Zeit, die notwendigen Schritte einzuleiten ohne, dass es das Projekt beeinträchtigt.

Werden diese Punkte erst zum Start der Testphase erkannt, ist der Terminplan oft nicht mehr zu halten.

Die Erkenntnis, ob und wie diese Schnittstellen angesprochen werden können, hat oft einen direkten Einfluss auf die gesamte Architektur des zu implementierenden Systems.

Wenn z. B. Datenklassen angepasst werden müssen, weil die Dokumentation nicht ganz korrekt war, hat das Auswirkungen auf die Persistenzschicht, was oft enorm zeitaufwendig ist und weitreichende Änderungen zur Folge hat.

Schlechte Performance auf der Gegenseite kann z.B. dazu führen, dass eine extra Caching-Funktionalität implementiert werden muß.

Es hilft übrigens nichts, diesen ersten Prototypen gegen einen Mock laufen zu lassen, weil ein Mock das erwartete Verhalten simuliert, was vom tatsächlichen Verhalten der Gegenseite deutlich abweichen kann.

Wann Kanban eine Alternative zu Scrum ist

Seit vielen Jahren bin ich in Scrum-Projekten unterwegs,  dem aktuellen Standard in der Software-Entwicklung.

Dabei muss ich sagen, dass die „Reine Scrum Lehre“ in keinem Kundenunternehmen wirklich gelebt wird. Es gibt überall Anpassungen an das eigene Vorgehensmodell und an die Unternehmenskultur.

Kanban kenne ich schon seit vielen Jahren, als es für die Produktionsplanung bei einem Kunden eingeführt wurde. Damals wurde extra ein Trainer aus Japan eingeladen, damit das Know-how möglichst aus erster Hand stammte.
In einem Kundenprojekt habe ich jetzt die Kanban-Methode live erlebt.
Kanban wurde 1947 in Japan entwickelt.
Im Wesentlichen geht es um eine optimale Produktionssteuerung.
Die einzelnen Aufgaben / Tätigkeiten werden auf einer Karte notiert und dann auf den jeweiligen Produktionsschritt verschoben.

Die Anzahl der Karten pro Produktionsschritt ist begrenzt. Wenn die maximale Anzahl erreicht wird, darf keine weitere Karte in diesem Schritt platziert werden.
Dadurch entsteht natürlich ein Stau in den vorgeschalteten Produktionsschritten. Diese Mitarbeiter sind nun aufgerufen den Produktionsstau mit abzubauen, bis sie wieder neue Karten im geblockten Produktionsschritt platzieren dürfen.

Kanban in der Software-Entwicklung

Kanban in der Software-Entwicklung ist relativ leicht umsetzbar. Die einzelnen Prozessschritte sind oft bekannt, z. B.

  • Anforderungen
  • Anforderungsanalyse
  • Bereit zur Entwicklung
  • Entwicklung
  • QS
  • Fertig

Im Schritt Anforderungen werden die Kundenwünsche gesammelt. Sobald ein Businessanalyst oder Requirements-Engineer frei ist, nimmt er sich eine Karte aus dem Pool „Anforderungen“ und verschiebt sie nach „Anforderungsanalyse“. Dem WiP = Work in Progress wurde eine Karte hinzugefügt.

Bereits hier sollte man die Anzahl der in der Analysephase befindlichen Karten pro Analysten begrenzen, um einer Überlastung vorzubeugen und die Qualität zu gewährleisten.

Ist die Anforderungsphase beendet, wandert die Karte in den Prozessschritt „Bereit zur Entwicklung“.
Die einzelnen Anforderungen sind unterschiedlich priorisiert, was sich in ihrer vertikalen Position innerhalb der Spalte ausdrückt. Wichtige Features sind oben angeordnet.

Ist ein Entwickler mit seiner Arbeit fertig, nimmt er sich die nächste zu entwickelnde Funktion von oben aus dem Prozessschritt „Bereit zu Entwicklung“.
Nachdem die Entwicklung abgeschlossen ist, wandert die Karte mit der Anforderung in die Qualitätssicherung, usw.

In regelmäßigen Abständen – z. B. einmal pro Woche oder auch kontinuierlich – werden die fertigen Artefakte nach Produktion deployed.

Vorteile gegenüber Scrum

Das Vorgehen bei Scrum ist sehr ähnlich, unterscheidet sich aber an einem wichtigen Punkt: Bei Scrum gibt es zeitlich definierte Sprints, meistens von 2-3 Wochen.

Product-Owner versuchen oft so viele Features wie möglich in den nächsten Sprint zu platzieren. Projektleiter ohne das richtige Standing knicken dann ein und damit ist ein Sprint überladen.

Das Ergebnis ist, dass das Team mehr oder weniger unter Druck gesetzt wird, bzw. die einzelnen Entwickler sich selber unter Druck setzen, um die geplanten Funktionen im Sprint unterzubringen. Erfahrungsgemäß gibt es in jedem Sprint solche „dringenden“ Features, was zu einer dauerhaften Überlastung des Teams führen kann.

Mit Kanban umschifft man diese Klippe. Wenn die einzelnen Prozessschritte im Kanban-Board gut gefüllt sind, entsteht fast automatisch ein ruhiger, kontinuierlicher Wertschöpfungsprozess.

Neue Funktionen können problemlos jederzeit priorisiert werden, was bei Scrum nur vor dem Sprint-Start möglich ist, will man das Scrum-System nicht destabilisieren.

Damit die Projektleitung einen besseren Überblick über den Aufwand machen kann, der für jedes Feature entsteht, ist es sinnvoll eine ungefähre Aufwandsschätzung pro Funktion zusammen mit den Entwicklern durchzuführen.

Hier können schon vorab Fragen gestellt, und Meinungen der unterschiedlichen Fachleute eingeholt werden.

Dies ist besonders sinnvoll, wenn man mit verteilen Systemen, z. B. mit Microservices arbeitet und die geplante Funktion mehrere dieser Services betreffen.

Fazit

Das ganze Vorgehen klingt zunächst nicht wirklich spektakulär – und genau das ist der Vorteil dieser Arbeitsweise: Es ist ein unspektakulärer, kontinuierlicher Prozess, der eine Überlastung der Mitarbeiter verhindert.

Durch die gleichmäßige Fertigstellung von Programm-Features eignet sich die Methode auch sehr gut für das Continous-Delivery.

Gerne beraten wir Sie über die Möglichkeiten von Kanban in Software-Entwicklungsprozessen. info@rockingbit.com

Hier noch eine Buchempfehlung für alle, die gerne tiefer in die Thematik einsteigen möchten:

http://www.hanser-fachbuch.de/buch/Kanban+in+der+IT/9783446438262