Es gibt eine Regel, die ich bei der Arbeit so oft wiederhole, dass Kollegen den Satz f\u00fcr mich beenden k\u00f6nnten: Beim Software-Produktdesign entwirft man nicht f\u00fcr die exotischsten F\u00e4lle. Man entwirft f\u00fcr die h\u00e4ufigsten F\u00e4lle und f\u00fcgt die exotischen nur hinzu, wenn sich genug Leute dar\u00fcber beschweren, dass sie fehlen.<\/p>\n\n\n\n
Laut ausgesprochen klingt das fast unh\u00f6flich. Irgendwo da drau\u00dfen gibt es einen Nutzer mit einem wirklich ungew\u00f6hnlichen Bed\u00fcrfnis, und meine Regel sagt ihm, er soll sich hinten anstellen und sich beschweren. Aber ich arbeite an HR- und Gehaltsabrechnungssoftware f\u00fcr Unternehmen in der gesamten Golfregion, und die Gehaltsabrechnung besteht durch und durch aus Randf\u00e4llen: Mitarbeiter, die in mehreren W\u00e4hrungen bezahlt werden, unbezahlter Urlaub mitten im Abrechnungszeitraum, r\u00fcckwirkende Gehalts\u00e4nderungen, Berechnungen zum Dienstende, die davon abh\u00e4ngen, wann ein Vertrag unterzeichnet wurde.<\/p>\n\n\n\n
Die Falle ist, dass einen niemand jemals bittet, ein Produkt aufzubl\u00e4hen. Jeder exotische Fall kommt mit einem Menschen daher: ein Kunde mit einem echten Problem, ein Verk\u00e4ufer mit einem Deal, der von einem fehlenden Kontrollk\u00e4stchen abh\u00e4ngt, ein Berater mit einer starken Meinung. Jede Anfrage f\u00fcr sich genommen ist klein und vern\u00fcnftig. Aufbl\u00e4hung (Bloat) entsteht, wenn man zu Hunderten von einzelnen, vern\u00fcnftigen Anfragen \u201eJa\u201c sagt, ohne das Gesamtbild sorgf\u00e4ltig im Auge zu behalten.<\/p>\n\n\n\n
Als Pendo die Feature-Nutzung bei 615 Softwareunternehmen f\u00fcr seinen 2019 Feature Adoption Report<\/a>, analysierte, stellte es fest, dass 80% der Funktionen in einem durchschnittlichen Produkt selten oder nie genutzt werden. Pendo bezifferte diese Verschwendung auch: Sch\u00e4tzungsweise $29,5 Milliarden der Entwicklungsausgaben von Public-Cloud-Unternehmen flie\u00dfen in Funktionen, die meistens nur ungenutzt bleiben. Vier von f\u00fcnf Funktionen, entwickelt und bezahlt, warten auf Nutzer, die niemals kommen.<\/p>\n\n\n\n Microsoft hat aus seiner eigenen Telemetrie dasselbe gelernt. Vor der Entwicklung der Men\u00fcband-Oberfl\u00e4che f\u00fcr Office 2007 ma\u00df das Team, was die Leute in Word 2003 tats\u00e4chlich taten. Von den Tausenden verf\u00fcgbaren Befehlen machten die Top F\u00fcnf \u2013 Einf\u00fcgen, Speichern, Kopieren, R\u00fcckg\u00e4ngig, Fett \u2013 rund 32% von allem aus, was die Nutzer taten<\/a>. Allein das Einf\u00fcgen machte \u00fcber 11% der gesamten Befehlsnutzung aus, mehr als doppelt so viel wie das zweitplatzierte Speichern. Word konnte Serienbriefe, Makros und Zentraldokumente erstellen; was die Menschheit aber haupts\u00e4chlich wollte, war Strg+V.<\/p>\n\n\n\n Ich finde diese Zahlen eher kl\u00e4rend als deprimierend. Aus Nutzersicht ist der h\u00e4ufigste Fall im Grunde das Produkt, und jede Stunde, die man damit verbringt, den Long Tail zu polieren, ist eine Stunde, die man nicht damit verbringt, daf\u00fcr zu sorgen, dass sich das Einf\u00fcgen verz\u00f6gerungsfrei anf\u00fchlt.<\/p>\n\n\n\n Die zweite H\u00e4lfte der Regel \u2013 f\u00fcge die exotischen F\u00e4lle nur hinzu, wenn sich genug Leute beschweren \u2013 klingt passiv, m\u00f6glicherweise arrogant. Aber wenn man \u00fcber die grobe Formulierung hinwegsieht, steckt viel Wahrheit darin. <\/p>\n\n\n\n Eine Funktionsanfrage, die gestellt wird, bevor das Ding existiert, kostet den Anfragenden nichts. Eine Beschwerde bedeutet, dass jemand nach der Funktion gesucht hat, feststellte, dass sie fehlt, und es ihm wichtig genug war, es einem mitzuteilen. Beschwerden sind offenbarte Pr\u00e4ferenzen.<\/p>\n\n\n\n Apple hat dieses Spiel \u00f6ffentlich durchgespielt. Das urspr\u00fcngliche iPhone wurde 2007 ohne Kopieren und Einf\u00fcgen ausgeliefert; einer der urspr\u00fcnglichen Ingenieure gab sp\u00e4ter zu<\/a> , dass dem Team schlichtweg die Zeit ausging, um es richtig zu machen. Die Nutzer beschwerten sich zwei Jahre lang lautstark. Als iPhone OS 3.0 es im Juni 2009 endlich lieferte<\/a>, entschuldigte sich Apple nicht \u2013 sie packten Kopieren und Einf\u00fcgen in einen Fernsehwerbespot. Zwei Jahre an Beschwerden hatten dem Unternehmen genau gezeigt, was die Funktion wert war und wie genau sie funktionieren musste.<\/p>\n\n\n\n Einige Einschr\u00e4nkungen:<\/p>\n\n\n\n Erstens verdienen die Beweise dieselbe Skepsis wie eine Funktionsanfrage. Die ber\u00fchmteste Statistik in diesem Genre \u2013 die Behauptung der Standish Group, dass 64% der Funktionen selten oder nie genutzt werden \u2013 geht auf einen Konferenzvortrag aus dem Jahr 2002 und eine Stichprobe von vier internen Anwendungen zur\u00fcck<\/a>, woran Mike Cohn die Leute seit Jahren erinnert. Die Pendo-Daten, die aus 615 Live-Produkten stammen, sind robuster. Aber die ehrliche Zusammenfassung ist, dass wir wissen, dass der Long Tail kaum genutzt wird, aber nicht genau, wie kaum.<\/p>\n\n\n\n Zweitens, und das ist noch wichtiger, deckt die Regel nur Annehmlichkeiten ab. Einige exotische F\u00e4lle sind Verpflichtungen: Sicherheit, Barrierefreiheit, gesetzliche Vorschriften \u2013 und bei der Gehaltsabrechnung die Richtigkeit selbst. Ein Randfall in einem Dokumenteneditor ist ein fehlender Men\u00fcpunkt; ein Randfall in einem Gehaltslauf ist ein falsch ankommendes Gehalt einer Person. Der Mitarbeiter am empfangenden Ende empfindet das nicht als exotisch. Beschwerden sind ein gutes Instrument f\u00fcr fehlende Annehmlichkeiten, aber nutzlos bei Sch\u00e4den: Niemand sollte sich dar\u00fcber beschweren m\u00fcssen, dass sein Gehalt falsch berechnet wurde, bevor der Fall ernst genommen wird. Wenn ein Randfall Geld, Recht oder Sicherheit ber\u00fchrt, entwickelt man ihn, egal wie wenige Leute jemals darauf sto\u00dfen.<\/p>\n\n\n\nBeschwerden sind Daten<\/h2>\n\n\n\n
Wo die Regel nicht greift<\/h2>\n\n\n\n