Was tun Sie, wenn ein Benutzer nach einer Funktion fragt, die Sie nicht implementieren werden?

Was tun Sie, wenn ein Benutzer nach einer komplexen Funktion fragt, die Sie implementieren könnten, dies jedoch nicht tun wird, weil 1) andere Benutzer dadurch unnötig komplex werden? 2) Sie dies auch nicht als Option tun, weil Sie möchten nicht, dass Ihr Einstellungsfeld kompliziert wird.

Ich habe eine iOS-App geschrieben und es gibt einige Benutzer, die mich nach einigen komplexen Funktionen gefragt haben, die ich aus den oben genannten Gründen nicht ausführen kann. Die meiste Zeit antwortete ich ihnen nur: "Wir werden das berücksichtigen." Es wird auch nicht helfen, ihnen zu erklären, dass sie in der Minderheit sind, die diese Funktion wünscht. Also, was machst du in diesem Fall?

Ich denke du machst das Richtige. Sie können nicht allen gefallen, und Sie sollten nicht! Seien Sie höflich und professionell, aber Sie müssen nicht alles tun, was Sie verlangen.

Sie müssen zu einem Kompromiss kommen. Ihr Benutzer (der Grund, warum die App existiert) sagt, dass sie nicht seinen Anforderungen entspricht.

Es gibt einen Unterschied zwischen der Berücksichtigung der Benutzeranforderungen und der Möglichkeit für den Endbenutzer, Ihre Anwendung zu entwerfen. Treffen Sie sich mit dem Benutzer und fragen Sie viele "Warum?" Fragen, bis Sie zum Kern der Aufgabe gelangen, die die Person ausführen möchte und nicht ausführen kann, oder die einfach zu umständlich ist, um sie in der aktuellen Benutzeroberfläche auszuführen. Machen Sie sich diese Notizen und verspotten Sie einige alternative Ansätze, mit denen Sie leben KÖNNEN, und präsentieren Sie sie dem Benutzer.

Vor allem: Denken Sie daran, dass die App nicht existiert, um Ihnen das Leben als Programmierer zu erleichtern. Die App ist da, um den Benutzer zu bedienen.

Wenn Sie den Blog von Seth Godins ( http://sethgodin.typepad.com/ ) lesen , wird immer wieder dieselbe Nachricht angezeigt:

1. Versende etwas (und höre auf das Feedback)
2. Versuchen Sie nicht, alle Menschen die ganze Zeit zufrieden zu stellen.

Ich hatte ein ähnliches Problem wie Sie mit einem Produkt, das ich verkaufe. Ich hatte alle möglichen Anfragen nach allen möglichen Funktionen. Die Anwendung ist komplexer geworden, als ich wirklich wollte. Jede Option erhöht die Komplexität, was ich vermeiden wollte. Und jetzt habe ich mehr Komplexität als ich möchte.

Dies gefällt mehr Benutzern. Und vertreibt Benutzer, deren Einrichtung zu schwierig ist.

Eine einfache / erweiterte Einrichtung ist ein Ausweg aus der Bindung. Bis zu einem Punkt. Dies macht Ihre Entwicklung jedoch komplexer.

In allen Fällen, in denen ich eine Anfrage bekomme, antworte ich immer höflich. Manchmal werde ich mich sofort weigern, obwohl dies selten ist. Und wo ich das mache, erkläre ich, warum es normalerweise eine Antwort auf eine Anfrage ist, bei der die gesamte Benutzeroberfläche überarbeitet werden muss, ein Unternehmen, das so massiv ist, dass ich einfach nicht dorthin gehe. In diesem Fall erkläre ich meine Gründe, danke aber dem Benutzer für die Anfrage.

In ALLEN Fällen, einschließlich der Fälle, die ich sofort ablehne, logge ich sie in der Datenbank für Funktionen und Fehler ein, um sie für die nächste Version zu berücksichtigen. Dies gibt etwas mehr Zeit, um über alles nachzudenken, und vielleicht später eine Alternative zu finden, die nicht genau den Anforderungen entspricht, aber möglicherweise einen Mehrwert bietet.

Wenn eine Feature-Anfrage berücksichtigt, kommentiert und schließlich (zur Entwicklungszeit) entschieden wurde, sie zu beenden, schließe ich sie. Andernfalls werden sie später zur erneuten Prüfung offen gelassen.

Dies ist kein perfekter Ansatz, aber letztendlich haben Sie als Software-Autor bestimmte Designprinzipien, an die Sie sich entweder halten oder die Sie aufgeben müssen. Die Wahl jedes Ansatzes sollte sorgfältig abgewogen werden.

Ich denke, dass Sie mit Ihren Benutzern ehrlich sein sollten. Sagen Sie ihnen nicht: "Wir werden das berücksichtigen", wenn Sie bereits entschieden haben, dass Sie dies nicht tun werden. Das wird die Benutzer glauben lassen, dass die Funktion eines Tages kommen wird, und wird enttäuscht, weil sie niemals kommt.

Auf lange Sicht wird Ihnen das am meisten nützen, glaube ich.

Ich würde ihnen nur für den Vorschlag danken, aber sagen, dass er momentan nicht auf Ihrer Roadmap steht. Die Leute werden meistens verstehen, dass Sie nur begrenzte Ressourcen haben.

Normalerweise mache ich drei Dinge, wenn ich in einer solchen Situation bin:

1. Ich überlege zweimal, ob die Idee des Benutzers doch eine gute Idee sein könnte. Ich habe gelernt, meinem ersten Instinkt nicht zu vertrauen. Manchmal hat der Benutzer Recht und ich liege falsch.
2. Erklären Sie dem Benutzer, warum Sie diese Funktion nicht einschließen können.
3. Erklären Sie dem Benutzer, wie er mit seiner Software erreichen kann, was er benötigt

Ich denke, der letzte Punkt ist am wichtigsten. Die meisten Benutzer möchten nicht, dass genau ihr Vorschlag umgesetzt wird. Sie brauchen nur eine Lösung für ein Problem und schlagen die einfachste Lösung vor, die sie sich vorstellen können. Vielleicht finden Sie eine bessere Lösung, die Sie implementieren können.

Für jedes unserer Produkte haben wir eine "Liste mit Ideen für zukünftige Versionen". Wir sagen unseren Nutzern also: "Wir werden Ihren Vorschlag auf diese Liste setzen" - und das ist ehrlich, wir tun das tatsächlich.

Die Liste hat keine Prioritäten, aber wir wählen regelmäßig Dinge daraus aus und verwenden sie, um unseren Rückstand zu füttern. Wir nehmen sie nicht "in Ordnung", sondern versuchen herauszufinden, welche Ideen das "Beste fürs Geld" bieten - den größten Nutzen für möglichst viele unserer Benutzer bei angemessenem Entwicklungsaufwand.

Funktionsanforderungen gegen die konzeptionelle Integrität des Produkts bleiben wahrscheinlich für immer bestehen. Gelegentlich kommt es jedoch vor, dass zumindest einige der in diesen Funktionsanforderungen enthaltenen Ideen verwirklicht werden können, möglicherweise nicht genau so, wie es die Person, die sie vorgeschlagen hat, gedacht hat, sondern auf eine Weise, die besser in die Produktarchitektur passt.

Mein Vorschlag hier lautet also: Sagen Sie nicht nur "Wir werden das berücksichtigen." und vergessen Sie die Idee, sobald Sie den Anruf beenden. Verwenden Sie stattdessen ein Tool, mit dem Sie Ideen und Funktionsanfragen speichern können, möglicherweise in einem Issue-Tracker, möglicherweise in einem Wiki, möglicherweise in einer Tabelle, je nachdem, was Ihren Anforderungen am besten entspricht.