Was wir auf der JAX London gelernt haben – Tag 1

„Als erstes bringen wir die Produktmanager um“

Coman Hamilton

Warum sind Post-its gelb? Und was bedeutet das für Produktmanager? Wie viel Code, den wir schreiben, macht wirklich einen Unterschied? Und was ist eigentlich der Sinn des Ganzen? Wir blicken zurück auf sechs Dinge, die wir am Tag Eins der JAX London gelernt haben.

1. Alles ist ein Service

Die Wirtschaft wird nicht länger von Produkten angetrieben, sondern von Services. Wenn es eine Sache gibt, die Besucher von der Eröffnungs-Keynote auf der diesjährigen JAX London mitnehmen, dann was es bedeutet, in einer post-industrielle Gesellschaft zu leben. Dein Unternemen, deine IT-Abteilung, deine Entwicklungspraktiken (egal ob QA, Ops oder Design), sogar die Microservice-Systeme sind auf Services aufgebaut, die miteinander kommunizieren, sagte Keynote-Sprecher Jeff Sussna.

Die Wertschöpfung funktioniert bei Services anders. Ein Service ist nicht ein Produkt, er ist nicht wie Wasser, das man in ein Glas gießt, sondern eine andauernde Erfahrung. Und es ist die Technik hinter den Services, die diese Erfahrung definiert. Wenn also das Helpdesk eines Unternehmens hauptsächlich daran interessiert ist, Tickets zu schließen, beeinflusst das die Erfahrung des Kunden. Und eine Sache, an die wir in dieser post-industriellen Ära denken sollten, ist, dass Erfahrung wichtig ist. Unternehmen müssen ihren Ansatz, dem Kunden zu helfen, auf den Kopf stellen. Anstatt sich Kundenunzufriedenheit vom Leib zu halten, müssen sie aktiv nach vorne treten und Feedback einholen, positiv oder negativ, und lernen, was der Kunde braucht.

Unterdessen verkompliziert die steigende Anzahl an Services die User Experience. Wenn dein Autoradio nicht funktioniert, wessen Schuld ist es dann? Ist es Hondas oder Spotifiys? Oder die deines Wi-Fi-Anbieters? Bevor Dinge einfacher werden, werden sie komplizierter.

Jeff Sussna’s opening keynote at the JAX London

Jeff Sussnas Eröffnungs-Keynote auf der JAX London

2. Warum Post-its gelb sind

Warum sind Post-its gelb? Weil es eine gut sichtbare Farbe ist? Weil es billiger ist? Nein. Es ist purer Zufall: Der Post-it-Erfinder Art Fry brauchte Papier für seine Idee, und sein Papierladen hatte zu später Sunde nur noch gelbes Papier.

In seiner Session „Le Mort du Product Management“ brachte Nigel Runnels-Moss, aka SleepyFox,  das Argument, dass viele bekannte technische Innovationen nicht aus sorgfältiger Forschung und einem perfekt geformten Design heraus entstanden sind – es gab keinen geleiteten Prozess. Projektmanagement muss sich ändern, um sich Innovationen zu Nutze zu machen. Produktmanagement, Marktforschung und Aufwandschätzungen sind oft weniger nützlich als wir denken.

„Als erstes sollten wir alle Produktmanager töten“, sagt Runnels-Moss, indem er lose Shakespeare zitiert und daran erinnert, dass Produktmanager nicht das A und O sind. Anstatt immer mehr Geld auszugeben, um unser Geschäft zu perfektionieren, sollten wir „eine Umgebung kreieren, in der es ok ist, Fehler zu machen, und keine, die fehlersicher ist“.

3. Überraschend viel Programmcode ist eigentlich sinnlos

„Nur 25 Prozent der Features werden jemals gebraucht.“ Das ist ein Fakt, der schwer zu akzeptieren ist. Und es ist nur einer von vielen, den Nigel Runnels-Moss auf der JAX London aufzeigte.

Fast zwei Drittel (64 Prozent) der Anwendungen werden nie oder nur selten genutzt. Indes zeigt eine Studie des Department of Defense, dass nur zwei Prozent des Codes von 35,6 Milliarden US-Dollar an Software wie ausgeliefert benutzt wird, während 75 Prozent entweder nie eingesetzt oder vor Auslieferung gestrichen wurde.

Fakten wie diese führen uns zu einer interessanten Frage: Was würde passieren, wenn wir uns auf das Drittel konzentrieren könnten, das auch wirklich genutzt wird? Würde das unser Budget verdreifachen? Und was würden wir mit all dem zusätzlichen Geld machen?

4. Schlechte Architektur führt zu hoher Mitarbeiter-Fluktuation

Wer möchte mit einer komplizierten Architektur arbeiten und einen unendlich komplexen Alptraum aufrecht erhalten, der einen großen Teil der Entwicklungszeit frisst? „Architektur-Schulden sind eine besonders giftige Art der technischen Schulden“, sagt Alexander von Zitzewitz. Aber perfekten Code, ohne technische Schulden zu schreiben, ist schwierig. Tatsache ist, dass in vielen Unternehmen Entwickler dafür bestraft werden, guten Code zu schreiben. Es bedeutet, mehr Zeit mit dem Code zu verbingen, wählerisch zu sein  – und in vielen Fällen erntet man dafür den Ruf, ein „Code-Fetischist“ zu sein. Situationen wie diese führen dazu, Architektur-Schulden aufzubauen. Und wenn gute Entwickler dazu gezwungen sind, mit einer schuldenbelasteten Architektur zu arbeiten, finden sie schnell ein Projekt, das mehr Spaß macht. „Normalerweise gehen die Besten als erstes“, stellt von Zitzewitz fest.

5. Es dauert vier Monate, um Zugriff auf Server bei Goldman Sachs zu bekommen

Es ist schwierig, agil und adaptiv zu sein, wenn man sich nicht schnell an den Bedarf des Systems anpassen kann. In Unternehmen wie Goldmann Sachs, wo es vier Monate dauern kann, bis man einen Server bekommt, muss man vorausplanen, erklärt Vinita Rathi, ehemalige Vice President bei Goldman Sachs. Später nach mehr zu fragen, ist schwierig. Wenn man also zwei Server braucht, fragt man besser nach vier.

„Viel mehr, als es unsere Fähigkeiten beeinträchtigte, Anwendungen auszurollen, war es eine Verschwendung an Infrastruktur, weil wie versuchten, mehr Server anzufragen. Das bedeutete, dass wir immer Server hatten, die wir nicht voll ausnutzten“, erzählt Vinita. Goldman Sachs versucht nun, das Problem zu lösen, indem es die Server in die Cloud schiebt.

Coffee and tea between sessions

Kaffee und Tee in der Pause

6. Warum wir IT machen

Sacha Labourey, CloudBees founder, speaking at the JAX London

Warum machen wir Software? Wofür ist IT überhaupt gut? Es ist bloß ein Geschäft, zumindest, wenn man Sacha Labourey fragt. „99 Prozent dessen, was wir machen, ist dafür da, mehr Geld zu verdienen und weniger auszugeben“, sagt Labourey. Um das zu beweisen, bat Labourey das Publikum, zehn Jahre nach vorne zu spulen. Auto A ist ein selbstfahrendes Auto, das wirklich super aussieht, aber ein paar Leute umbringt. Auto B sieht wirklich mies aus, aber die Software für den Autopilot ist so gut, dass es keine Unfälle gibt. Werden Menschen trotzdem das hübschere Auto kaufen? Nein, sagt Labourey. „Die Software differenziert das Produkt.“

Geschrieben von
Coman Hamilton
Coman Hamilton
Coman was editor of JAXenter.com at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous websites and magazines, as well as several ad agencies.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: