So erhalten Sie die Qualität im Maßstab

Wenn Sie in einem schnell wachsenden Startup-Unternehmen arbeiten, ist es einfach schwierig, ein fehlerfreies Produkt über einen längeren Zeitraum zu erhalten. Es erfordert Entschlossenheit und Intentionalität - aber die gute Nachricht ist, dass es nicht wirklich zu komplex ist. Brian Culler, unser Director of Engineering, erklärt, wie wir das hier bei SalesLoft machen.

Typischer Lebenszyklus eines Startups - und wie es schief geht

Wenn Sie sich die verschiedenen Phasen ansehen, die Ihr Produkt durchläuft, scheint es fast immer eine höhere Priorität zu geben als das Beheben einiger Fehler. In der Anfangsphase, wenn Sie nur versuchen, eine marktgerechte Lösung zu finden, muss jede Sekunde dafür aufgewendet werden, MVP-Funktionen schnell auf den Markt zu bringen, um herauszufinden, was wichtig ist. Wenn Sie dann das Glück haben, an Traktion zu gewinnen, werden Sie von neuen Feature-Anfragen überflutet, es sei denn, beide potenziellen Kunden bewerten Sie und bestehende Kunden, die mehr Funktionalität benötigen.

Sobald die Dinge ernst werden, kommen die Skalierungsprobleme - die Entkopplung Ihrer MVP-App in Dienste, der Übergang zu einer skalierbaren Architektur und die Umgestaltung nicht performanter Komponenten zur Bewältigung der ständig wachsenden Benutzerlast.

Und wenn Sie dann wirklich Glück haben und auf einen aufkommenden Bereich von Software gestoßen sind, der ein neues Problem löst, ist höchstwahrscheinlich jemand anderes mit Ihnen hineingestolpert. Dies bedeutet, dass Sie 1 oder 2 Hauptkonkurrenten haben, die versuchen, Ihr Mittagessen zu essen. Es ist ein Landraub, also müssen Sie jetzt mit der Feature-Parität in einem sich schnell bewegenden innovativen Bereich Schritt halten.

Sie bewegen sich schnell, Sie brechen ein paar Dinge, aber na und? Der Verkauf läuft weiter und das meiste funktioniert. Bei allen Showstoppern, um die Sie sich wahrscheinlich kümmern, werden die restlichen Randbugs (möglicherweise) aufgeschrieben und irgendwo in einen Rückstand gesteckt. Wir werden sie eines Tages erreichen, wenn sich die Dinge abgekühlt haben und wir Zeit haben. Momentan müssen drei wichtige Funktionen veröffentlicht werden, und wir müssen unser SSO-System neu aufbauen, um größere Kunden bedienen zu können.

Ihr Kundensupport-Team beginnt wahrscheinlich klein und schlank, aber dann sind sie unerklärlicherweise ständig überarbeitet und müssen weiter einstellen. Die Support-Tickets wachsen weiter. Bugs, bei denen eine Menge Tickets erhältlich sind, können auf Ihrer überfüllten Roadmap priorisiert werden, aber nur, wenn sich die Leute wirklich beschweren.

Der Defektbestand wächst. Jedes neue Problem betrifft immer mehr Menschen, da Sie immer mehr Kunden haben. Ihr Support-Team spricht es wöchentlich an - die Probleme, für die Sie keine Zeit haben, werden immer häufiger. Und bevor Sie es wissen, ist es einfach zu spät. Du hast dich in ein Loch gegraben, aus dem du niemals herauskommst. Sie haben kein Bug-Backlog, Sie haben eine Bug-Datenbank. Es ist unmöglich, dass das Führungsteam jemals eine dreimonatige Pause einlegt, um das Schiff wieder in Ordnung zu bringen. In der Zwischenzeit führt jedes neue Feature dazu, dass überall Regressionen auftreten.

Ihre Kunden werden unglücklich. Sie hinterlassen negative NPS-Bewertungen mit der Aussage "So fehlerhaft, dass nichts jemals repariert wird!". Es wird schwieriger, gute Entwickler zu halten, da die Codebasis so pingelig geworden ist. Alles brennt die ganze Zeit. Sie fangen an, Marktanteile zu verlieren. Die Abwanderungsraten steigen. Sie verstehen nicht, wie sich Ihre Konkurrenten schneller als Sie bewegen können, obwohl sie ein kleineres Team haben.

Hört sich schrecklich an? Es ist. Und es wird Ihre Firma töten.

So stellen Sie sicher, dass dies nicht passiert.

Es ist nicht kompliziert. Es ist jedoch harte Arbeit. Sie müssen um jeden Preis mit jeder Faser Ihres Wesens sicherstellen, dass Ihr bekannter Defektbestand niemals außer Kontrolle gerät. Wenn Sie es nicht sehen und keine Prozesse einrichten, um es zu verwalten, wird es zu 100% wachsen. Sie müssen absichtlich darüber sein.

Bei SalesLoft ist uns dies bisher gelungen. Wir haben keine bekannten vom Kunden gemeldeten Mängel in unserem Auftragsbestand, die nicht priorisiert sind oder bearbeitet werden. Jedes Unternehmen ist anders. Passen Sie daher die folgenden Variablen an, die zu Ihrem Produkt und Ihrem Unternehmen passen. Sie müssen Ihren Platz berücksichtigen. (Sind Sie eine Bank? Oder schreiben Sie eine Social-App für Emojis?) Was werden Ihre Kunden tolerieren? Wie oft lässt du los? Melden sich Ihre Benutzer einmal am Tag an oder sind ihre Erfahrungen eher transaktionsbezogen? All dies sollte in Ihre Entscheidungsfindung einfließen, aber so machen wir es:

Bleiben Sie in der Nähe des Supports.

Ihre Kundenbetreuer sind Ihre Augen und Ohren. Sie werden schneller wissen, wenn etwas nicht stimmt, als Sie es manchmal tun werden. Sie werden die wahren Schmerzpunkte kennen. Sie werden immer wieder wissen, welche Tickets sie beantworten. Es ist ein entscheidender erster Schritt, Ihr Support-Team physisch an Ihr Engineering-Team zu binden.

Während meiner ersten Woche hier setzte ich mich mit den Ingenieuren zusammen und bekam ein Gefühl dafür, wie die Anwendung funktionierte. Wo waren die Engpässe? Was bekommt die meiste Aufmerksamkeit? Was ist die höchste Priorität?

Und schließlich - wie viele ausstehende Fehler haben wir? Die Antwort: „Nun, keine. Nicht, dass wir sowieso wüssten. Wir regeln die Dinge ziemlich schnell. “Schön.

Ich drehte meinen Stuhl in den Nebenzimmer, in dem Support saß. Ich warf der gesamten Gruppe dieselbe Frage zu: „Hallo allerseits, gibt es irgendwelche Fehler, von denen ihr alle wisst? Die Technik sagt, dass es keine gibt. "

Das Lachen war drei Stockwerke entfernt zu hören.

Es stellt sich heraus, dass ein Fehler von Support zu Engineering eskaliert wurde, der gerade nicht vorhanden war. Das Beste, was es gab, war, wenn etwas wirklich kaputt ging, jemand gegen das Glas zwischen den Zimmern klopfte und es ausrief. Außerdem würde der Support einem Techniker beim Kaffeetrinken oder in einer zufälligen Besprechung möglicherweise defekte Dinge mitteilen.

Sie müssen den Support dazu bringen, mit dem Engineering zu sprechen, und Sie sollten dazu Software verwenden. Unabhängig davon, welches Ticketing-System der Support verwendet (wir sind bei Zendesk), können Sie es über eine Push-Integration in Ihr Prozessmanagementsystem (JIRA, Pivotal usw.) einbinden. Bringen Sie dem Support-Team bei, wie man Fehler aufschreibt. Geben Sie die betroffene Komponente, die Reproduktionsschritte und die Anzahl der betroffenen Kunden an. Lassen Sie sie einen Schweregrad festlegen. Stellen Sie sicher, dass Ihre Integration bidirektionale Updates unterstützt. Wenn sich das Problem in Ihrem Prozessverwaltungssystem befindet, werden alle Supporttickets automatisch mit Status und Lösung aktualisiert. Wir können sogar alle Support-Tickets direkt aus unserem Prozessmanagementsystem (in unserem Fall JIRA) kommentieren. Dieser Teil muss so einfach und nahtlos wie möglich zu bedienen sein. Sie möchten keinen zusätzlichen Aufwand nur durch die Verfolgung und Verwaltung Ihrer Fehlerliste erzeugen.

Definieren Sie Ihr Service Level Agreement.

In diesem Fall ist eine SLA nur eine originelle Art zu sagen: „Wir versprechen, bestimmte Dinge in einer bestimmten Zeit zu erledigen.“ Wir haben eine SLA mit unserem eigenen Support-Team, die wir uns als Team gesetzt und entschieden haben. Das Engineering versprach, alle Mängel innerhalb einer bestimmten Zeit zu beheben. Wir haben 3 verschiedene Schweregrade entwickelt - diese können sich von den Anforderungen Ihres Unternehmens oder Produkts unterscheiden, aber auf hohem Niveau:

Ein Schweregrad 1 bedeutet im Grunde, dass die Anwendung nicht funktioniert. Es ist alles an Deck und wir reparieren es sofort.

Schweregrad 2 bedeutet, dass etwas wirklich schlimm ist - Sie können keine Daten in das System importieren oder Telefonanrufaufzeichnungen werden nicht gespeichert. Wir antworten immer noch fast sofort auf Sev 2s, aber normalerweise ist es nur eine Person in einem Team, die das ablehnt, was sie tun, um eine Fehlerbehebung zu starten. Wir haben ein Maximum von 2 Tagen festgelegt, um das Problem zu beheben. In der Realität gehen die Korrekturen jedoch normalerweise innerhalb von ein paar Stunden aus.

Der Schweregrad 3 ist die überwiegende Mehrheit der Mängel, die uns gemeldet werden. Etwas ist technisch kaputt, aber es ist kein Showstopper. Man kann es irgendwie umgehen usw.

Der entscheidende Schlüssel für alle drei ist, dass sie zeitgebunden sind. Sofort, 2 Tage oder 14 Tage, spielt es fast keine Rolle - aber ohne diese zeitbasierte Zwangsfunktion funktioniert nichts. Was dann zum letzten Stück der Lösung führt ...

Holen Sie sich ein Buy-in und bleiben Sie dabei!

Wenn Sie eine SLA ausarbeiten, sollten Sie alle Beteiligten in den Raum einbeziehen. Beginnen Sie mit der These, dass Qualität wichtig ist, bringen Sie das Team dazu, zuzustimmen, dass es wichtig ist und dass jeder die Vereinbarung befolgt. Holen Sie sich Ihr Produktteam an Bord, Ihr Support-Team, alle. Es spielt keine Rolle, wie groß Ihr Prozess ist, wenn niemand ihn ernst nimmt.

Und schließlich - nimm es sehr, sehr ernst. Wenn Sie ein Maximum von 14 Tagen haben und ein Defekt 14 Tage alt ist, suchen Sie buchstäblich den Ingenieur, dem er zugewiesen ist, und lassen Sie ihn die von ihm ausgeführten Funktionsarbeiten fallen lassen und auf den Defekt springen. Das erfordert Disziplin. Die Idee ist, nicht jeden Fehler 14 Tage lang auftreten zu lassen, aber es ist genug Zeit, um sicherzustellen, dass das Team die Flexibilität hat, vorrangige Entscheidungen zu treffen. Haben Sie ein riesiges Feature vor dem Ausgehen? Gut, schieben Sie den Defekt für ein paar Tage ab. Wenn es 10 oder 11 Tage alt wird, sollten Sie es sich genauer ansehen.

Wir haben tatsächlich eine technische Metrik namens "Alterungsfehler", die wöchentlich aufzeichnet, wie viele von Kunden gemeldete Fehler älter als 14 Tage sind. Unser Ziel ist es, Woche für Woche Null zu sein. So wichtig ist das.

Sobald Sie es von sich lassen, ist es so unglaublich schwierig, es jemals zurückzubekommen. Wenn Sie dies richtig machen und die Qualität ernst nehmen, bleibt Ihnen eine frustrationsfreie Plattform für Ihre Kunden, eine vertrauenswürdige Codebasis für Ihr Produktentwicklungsteam und um Größenordnungen weniger Tickets für Ihr Support-Team. Wenn Sie sich am Ende die Zeit nehmen, um Dinge zu reparieren, die brechen - wenn sie brechen -, können Sie sich auf lange Sicht schneller bewegen.