„Feature-Anfrage!!!“
Es ist oft der Schlachtruf, den wir Softwareingenieure verwenden, um die Dringlichkeit eines Kundenproblems herunterzuspielen. Schließlich ist keine Zeit, neue Funktionen hinzuzufügen, wenn wir auf das endlose Fehlerprotokoll blicken, vor dem wir stehen.
Für uns Softwareingenieure ist der Unterschied zwischen einem Bug und einem Feature Request glasklar. Ein Fehler ist eine Diskrepanz zwischen der tatsächlichen Funktionsweise des Codes und der Funktionsweise unseres Codes. Eine Funktionsanforderung erfordert neuen Code, um einen Fall zu erfüllen, der von der aktuellen Codebasis nicht behandelt werden kann.
Diese Art des Denkens führt uns immer zu der allgemeineren Frage, wie Software wie DoneDone verwendet werden sollte. Sollte Ihre Organisation eine Art von Software verwenden, um Fehler zu protokollieren, eine andere Art von Software, um anstehende Aufgaben zu verwalten, und noch eine andere Art von Software, um Feature-Anfragen zu verfolgen?
Wir verbringen viel mentale Energie damit, die von einem Kunden oder Kunden protokollierten Probleme zu durchsuchen und festzustellen, ob wir ein Problem in den Bucket „Bug“ oder in den Bucket „Feature Request“ werfen. Für Beratungsarbeiten, wenn wir eine vordefinierte Vereinbarung darüber treffen, wie sich Software verhalten soll, ist dies sinnvoll. Feature-Anfragen können einen Aufpreis erfordern.
Aber wenn es nur um die reine Praxis geht, gute Software zu erstellen, insbesondere wenn wir an unseren eigenen Produkten arbeiten, wie sehr sollten wir uns darum kümmern, ein Problem auf diese Weise zu kategorisieren?
Wir lassen technische (und technische) Probleme im Weg stehen.
Robert Martin (alias Onkel Bob) spricht viel über Software. Er betrachtet das Web lediglich als Übermittlungsmechanismus und nicht mehr. Es ist nicht die Endbenutzererfahrung, und es ist nicht der Zweck der Software. Es ist einfach ein winziges kleines dummes Detail. Wenn wir Programmierer programmieren, wird die Architektur unserer Anwendungen jedoch zu stark von der Tatsache beeinflusst, dass es sich um eine Webanwendung handelt.
Was wäre, wenn wir den Begriff, den wir für „eine Sache, die erledigt werden muss“ verwenden, als dummes Detail betrachten würden?
Ist es ihr aus der Sicht der Person, die dieses „Ding“ protokolliert, wirklich wichtig, dass sie eine neue Funktion anfordert, anstatt einen Fehler zu entdecken? Sie möchte nur, dass ihr Problem von einem anderen Menschen gelöst wird, und vorzugsweise, um zu wissen, wann ihr Problem gelöst werden könnte.
Sie könnten in der Lage sein, die Technik deutlicher zu sehen, wenn wir die Software-Welt verlassen. Wenn der Klempner kommt, um die undichte Dusche zu reparieren, würde ich mir vorstellen, dass Sie sich nicht um das Detail kümmern. Wenn der Duschkopf falsch installiert wurde (Bug) oder wenn die Dichtung defekt ist (Bug) oder wenn Teflonband in einem billigen Rohr fehlt (Feature), ist alles, was Sie interessiert, wie lange es dauern wird, um zu reparieren und wie viel Sie werden berechnet.
Fehler oder Anfrage? Es ist beides. Und, es spielt keine Rolle.
Letzte Woche haben wir Mammut veröffentlicht Kin, ein HR-Software-Tool für kleine Unternehmen. Kin bietet Ihnen eine einfache Möglichkeit, die Freizeitanforderungen jedes Mitarbeiters zu verfolgen. Eine Sache, die Kin derzeit nicht tut, ist, Wochenenden und Feiertage von Arbeitstagen zu unterscheiden. Wenn Sie also während Thanksgiving eine ganze Woche ausziehen möchten, müssen Sie die Anzahl der Stunden, die Sie ausziehen möchten, manuell eingeben.
Das Team hat bereits einige Anfragen erhalten, damit Kin dieses Tracking automatisch durchführt. In der Tat ist es in der Release-Warteschlange. Aber wenn es protokolliert wird, an welchem Ort auch immer es angemeldet ist, sollte das Kin-Team es als Fehler, Funktionsanforderung, Aufgabe oder Aufgabe betrachten?
Wenn ich meinen inneren Onkel Bob anrufe, ist meine Antwort einfach: Es spielt keine Rolle, wie Sie die Anfrage klassifizieren. Es ist nur ein dummes Detail.
Das heißt nicht, dass wir es überhaupt nicht klassifizieren sollten. Das Kin-Team markiert das Problem möglicherweise unter „Feature Request“ und arbeitet zuerst daran, kritischere Probleme zu beheben (z. B. einen Benutzer mit einem Autorisierungsproblem). Das ist in Ordnung und gut, und ein gültiger Ansatz.
Es wäre jedoch ein Fehler, automatisch anzunehmen, dass alle Dinge, die wir Feature-Anfragen nennen, weniger dringend sind als alle Dinge, die wir Bugs nennen. Das macht das eher kleine Detail, wie wir das Problem klassifizieren, zum Kernstück, wenn wir es lösen. So sollte es nicht sein. Am Ende des Tages sind all diese Anfragen einfach Dinge, die gelöst werden müssen.
Lassen Sie die Technik das dumme Detail sein
Zu diesem Zweck ist das Etikett, das wir all diesen Anfragen geben, weitgehend unwichtig. Was mehr zählt, ist, dass sich jemand um sie kümmert und es eine allgemeine Vorstellung davon gibt, wann diese Anfragen beantwortet werden. Was noch wichtiger ist, ist, dass 33% mehr Benutzer davon profitieren, wenn Artikel A angesprochen wird als Artikel B. Unabhängig davon, um welche Art von Dingen es sich bei Artikel A oder Artikel B handelt, ist Artikel A wertvoller anzusprechen. Das war’s. Nichts weiter.
Wenn Sie also das nächste Mal zu viel Zeit mit der Kategorisierung von Aufgaben, Fehlern, Funktionsanfragen und Aufgaben verbringen, denken Sie daran, die technischen Details zu vergessen. Es sind nur die dummen Details.
Melden Sie sich in 30 Sekunden für ein DoneDone-Konto an. Willst du mehr von Ka Wai Cheung lesen? Ka Wais neues Buch über den modernen Programmierer, Der Entwicklercode, ist als eBook und Print erhältlich. Sie können ihm auf Twitter @developerscode folgen.