Woran du sterbende Tech-Produkte rechtzeitig erkennst

Grundlagen

In der Softwareentwicklung ist man auf andere Software und Onlinedienste angewiesen:

Man kommt also kaum umhin, sich mittelfristig von anderen Anbietern und deren Entscheidungen abhängig zu machen. Aber wie lässt sich rechtzeitig erkennen, was eine nachhaltig strategische Wahl ist? Welchen Klotz kann man sich problemlos ans Bein binden und welcher wird für Komplikationen sorgen? Welche produkte sind gut und zuverlässig, welche nicht?

Der Qualitätszyklus von Tech-Produkten

Ich stelle in der Qualitätsentwicklung solcher produkte i.d.R. einen umgekehrt u-förmigen Verlauf fest, der sich in drei Phasen unterteilen lässt:

  1. Aufstieg: Kundenzufriedenheit wird angestrebt, es gibt aber noch deutliche Lücken.
  2. Zenit: Ein hohes Maß an Kundenzufriedenheit und Akzeptanz wurde erreicht und wird aufrechterhalten.
  3. Abstieg: Das Produkt und auch die Kundenzufriedenheit lassen nach, es lebt aber noch von seinem guten Namen.

Typisch für die dritte Phase ist, dass Qualitätssicherung eigentlich gar keine Rolle mehr spielt. Diese Produkte tun so, als ob sie gut wären, degradieren aber in Wirklichkeit längst Gerade bei Software und Diensten aus dem Silicon Valley lässt sich der Abstieg gut beobachten. Dabei hat der Einkauf durch diese Konzerne z.B. bei GitHub und YouTube ursprünglich dafür gesorgt, dass sie aus dem aufstieg in den Zenit gehoben wurden.

Das Erkennungszeichen für den Beginn des Abstiegs

Ich habe das längst vorausgesehen, indem ich die Entwicklung der Barrierefreiheit beobachtet habe.

Barrierefreiheit degradiert als erstes Qualitätsmerkmal im schleichenden Abstieg, und sie wird zuletzt zum Eintritt in den Zenit hinzugefügt.

Am Beispiel von GitHub demonstriere ich diese Entwicklung.

Barrierefreiheit ist eine strategische Führungsangelegenheit

Barrierefreiheit ist kein Hexenwerk, aber sie muss immer wieder im Entwicklungsprozess aktiv gepflegt und eingefordert werden. Sie degradiert, sobald niemand konstant darauf achtet. Fast jeder glaubt, dass sich das Thema komplett an die Entwickler auslagern und dann vergessen ließe. Wir spendieren den Entwicklern einen Wochenendworkshop, und dann „können die Barrierefreiheit“ und werden das schon irgendwie von allein machen. Pardon, aber das ist dummer und ärgerlicher Bullshit! Kurz gesagt: Barrierefreiheit ist Chefsache und muss dein der Gesamtstrategie sein.

Was ist Strategie?

Ein gutes produkt entwickelt sich nicht einfach willkürlich, sondern ist Ergebnis der gesetzten prioritäten und Features, die sich aus einer Zielsetzung und Ausrichtung ergeben. In der agilen Terminologie werden diese prioritäten und Requirements z.B. durch einen Product Owner vorgegeben. Vorausgesetzt, Scrum wird gut umgesetzt, ist ein Product Owner eine Art Kundenbeauftragter, wobei das natürlich etwas weniger sexy klingt. Jemand in einer solchen Position muss einen erweiterten Blick haben und die Bedarfe der unterschiedlichen Kundengruppen einschätzen und antizipieren können.

Wer ist der Kunde?

Die angesprochene kundschaft gibt Ausschlag darüber, welche Prioritäten auf der Führungsebene gesetzt werden: Die Bedarfe variieren abhängig von der Kundenzielgruppe und deren Motivation:

Anhand von GitHub lässt sich dieser Prioritätenwechsel sehr gut aufzeigen. Vor einigen Monaten hat dort ein Führungswechsel stattgefunden. Der CEO Thomas Dohmke hatte GitHub verlassen. Sein Fortgang korreliert deutlich mit degradierender Nutzerfreundlichkeit und Barrierefreiheit. Dohmke hatte offensichtlich im Auftrag der Nutzer priorisiert und Wert auf Barrierefreiheit und Inklusion gelegt. Man schaue sich nur den GitHub-Blog an:

Meine Empfehlungen für strategische Entscheidungen

##Meine Empfehlungen für strategische Entscheidungen

So vermeidest du Abhängigkeiten, die mittelfristig zum Problem werden:

Mache aussagekräftige Tests auf Barrierefreiheit, bevor du dich an ein solches produkt bindest. Wenn möglich, versuche an Nutzertests zu kommen oder Betroffene nach ihren Erfahrungen zu befragen, statt auf einen formalen Konformitätstest zu setzen. Auch interessant ist, ob kürzlich eine Degradierung beobachtet wurde.

Bei eigener Produktentwicklung: betrachte barrierefreiheit nicht als ausschließlich technische angelegenheit, sondern auch beziehe sie in Führungsentscheidungen mit ein. So kommst du langfristig ohne externe Berater für Barrierefreiheit aus.