Ihre Ideen sind immer willkommen

Ein kleiner "Beschleunigungs"-Tipp für Freunde, die Vorschläge machen

Als Entwickler von QuickPlanX ist einer unserer glücklichsten Momente jeden Tag der Erhalt Ihrer Funktionsvorschläge für diese iOS/macOS Projektmanagement-App. Es gibt uns das Gefühl, dass sie wirklich ein Teil Ihrer Arbeit und Ihres Lebens geworden ist.

Eine exzellente App ist auf eine große Menge an Benutzerfeedback angewiesen. Wir begrüßen jede Idee zur Funktionsverbesserung, auch wenn es nur ein einfacher Satz ist.

Nach Erhalt des Feedbacks bemühen wir uns, die Hintergrundinformationen hinter Ihrem Vorschlag zu verstehen und analysieren die Schmerzpunkte, die er lösen soll, oder die potenziellen Vorteile. Wenn Ihr Vorschlag uns jedoch direkt über die zu lösenden Schmerzpunkte oder die erwarteten Vorteile informieren kann, werden die Verarbeitungsgeschwindigkeit und die Wahrscheinlichkeit der Annahme erheblich erhöht.

Warum fragen wir manchmal "Warum"?

Dies erklärt, warum wir bei einem scheinbar einfachen Vorschlag manchmal nicht sofort "Ja" sagen, sondern Details wiederholt bestätigen. Dies ist kein Ausweichen, sondern weil aus Entwicklungssicht:

Es gibt oft mehrere Wege, um dasselbe Ziel zu erreichen.

Wenn wir uns nur auf die von Ihnen vorgeschlagene "spezifische Funktion" konzentrieren, ist es leicht, sich auf eine bestimmte Implementierungsmethode zu beschränken. Aber wenn wir Ihre "Schmerzpunkte" und "Vorteile" kennen, besitzen wir eine breitere Vision:

• Eine bessere Lösung finden: Wir könnten unsere Vertrautheit mit dem Design und der Technologie der App nutzen, um eine passendere, schnellere oder ausgewogenere Lösung für Ihre Idee zu entwerfen.
• Bestehende Lösungen entdecken: Wir könnten feststellen, dass andere vorhandene Funktionen Ihre Anforderungen bereits erfüllen können, sodass Sie das Problem sofort lösen können, ohne warten zu müssen.
• Missverständnisse vermeiden: Die Möglichkeit, Ihren Vorschlag misszuverstehen, verringert sich erheblich, wodurch sichergestellt wird, dass das, was wir machen, genau das ist, was Sie wirklich brauchen.
• Effizienz verbessern: Die Reduzierung der Kommunikationskosten wiederholter Bestätigungen ermöglicht es uns, die Bewertung und Entscheidungsfindung schneller abzuschließen.

Ein echtes kleines Beispiel

Ein Benutzer schlug einmal nachdrücklich vor: "Ich hoffe, eine E-Mail-Integrationsfunktion hinzuzufügen, damit ich E-Mails direkt in der App senden kann."

Obwohl diese Funktion intuitiv klingt, fragten wir nach dem Szenario dahinter: "Welche spezifischen Informationen möchten Sie senden? Und an wen?"

Der Benutzer erklärte: "Ich muss detaillierte Anweisungen für bestimmte Aufgaben zur Bestätigung an Outsourcing-Personal senden."

Als wir das hörten, verstanden wir. Es stellte sich heraus, dass sein Schmerzpunkt nicht war, "E-Mails in der App schreiben zu müssen", sondern "wie man Informationen schnell extrahiert und teilt".

Wenn wir nur "E-Mail-Integration" machen würden, wäre die Funktion sehr eingeschränkt und aufgebläht. Tatsächlich variieren die Felder, die jeder teilen muss, stark (einige wollen Daten, andere nur Notizen), und die Sharing-Kanäle sind nicht auf E-Mail beschränkt (vielleicht auch WeChat, Slack).

Also wechselten wir zur Entwicklung einer flexibleren Funktion "Anpassbare Aufgaben-Textausgabe".

• Für diesen Benutzer: Er passte das Ausgabeformat an (behielt nur "Aufgabenname + Notizen" bei) und sandte es direkt per E-Mail über die Systemfreigabefunktion, was das Problem perfekt löste.
• Für alle: Diese flexible und konfigurierbare Ausgabemethode erfüllte auch die verschiedenen Sharing-Bedürfnisse anderer Benutzer, wie das Schreiben von täglichen Berichten oder das Senden von WeChat-Nachrichten.

Das ist die Magie von "Hintergrundinformationen". Sie half uns, eine ursprünglich enge "E-Mail-Anforderung" in eine "universelle Funktion" zu verwandeln, von der alle profitieren.

Sprechen Sie mehr über "Kontext", keine Notwendigkeit, "Docs" zu schreiben

Also, wenn Sie das nächste Mal das Gefühl haben, dass eine Anforderung komplex ist oder schwer in ein oder zwei Sätzen zu erklären ist, versuchen Sie kurz über Ihren "Nutzungskontext" zu plaudern.

Sie müssen absolut kein formelles Anforderungsdokument schreiben (natürlich, wenn Sie es gewohnt sind, detailliert und professionell zu schreiben, würden wir uns noch mehr freuen).

Aber in den meisten Fällen ist keine professionelle Terminologie erforderlich, und machen Sie sich keine Sorgen, ob Sie richtig oder falsch liegen; erwähnen Sie einfach die folgenden zwei Punkte beiläufig:

1. Auf welches Problem sind Sie gestoßen? (z. B. Die aktuelle Operation ist zu anstrengend, fehleranfällig oder unklar.)
2. Wie kommen Sie jetzt zurecht? (z. B. Kann nur manuell mit einem Stift rechnen oder muss zu den Einstellungen gehen, um Schalter wiederholt umzuschalten.)

Gewöhnlicher Vorschlag: "Fügen Sie eine Batch-Löschfunktion hinzu." Vorschlag mit Kontext: "Ich muss jeden Tag Dutzende von alten Datenelementen bereinigen. Das aktuelle Design erfordert das Wischen nach links eins nach dem anderen, und meine Finger tun weh."

Selbst mit nur diesem einen zusätzlichen Satz können wir oft sofort beurteilen: Dies ist ein hochfrequenter Effizienzbeschränkung, der einer Prioritätsbewertung würdig ist.

Ihre Ideen sind wichtig, und die "Gründe" dahinter sind ebenso kritisch

Manchmal können begeisterte Benutzer wie Sie nicht anders, als sich Sorgen um uns zu machen: "Ist das besser für die App?" oder "Wird das Hinzufügen dieser Funktion die Anwendung vollständiger machen?"

Tatsächlich sind die spezifischen Funktionsvorschläge, die Sie vorschlagen, sehr wichtig; sie sind oft der Ausgangspunkt unserer Inspiration.

Aber im Vergleich zu einer isolierten "Lösung" brauchen wir von Ihnen mehr das "Problem selbst" – insbesondere wenn wir die zugrunde liegende Motivation (Schmerzpunkte und Vorteile) nicht einfach aus der Funktionsbeschreibung verstehen können, werden diese Hintergrundinformationen besonders kritisch.

Denn aus Entwicklungssicht ist die "gewünschte Funktion" nur eine der Optionen, um das Problem zu lösen, während die Beseitigung Ihres "Schmerzpunkts" unser gemeinsames Ziel ist.

Klare Hintergrundinformationen (Schmerzpunkte und Vorteile) bringen zwei direkte Vorteile:

1. Genauere Beurteilung: Wir können den wahren Wert dieser Funktion für Sie verstehen. Einige Funktionen scheinen "lästig" zu sein, aber wenn wir wissen, dass sie Ihre Kernschmerzpunkte lösen, werden wir ihre Priorität erhöhen.
2. Überlegene Lösungen: Genau wie der Fall der "Textausgabe" oben können wir vielleicht unsere Vertrautheit mit dem System nutzen, um eine einfachere, bessere Lösung für Sie zu finden, als Sie ursprünglich dachten.

Daher ist dieser reale Moment, in dem Sie stecken bleiben, oft wichtiger für uns. Wir werden Ihren vorgeschlagenen Funktionsvorschlag mit den tatsächlichen Schmerzpunkten dahinter kombinieren, um den geeignetsten technischen Implementierungsplan für Sie zu konzipieren.

Nicht nur Vorschläge machen, sondern Ihre "Best Practices" teilen

Es gibt noch einen weiteren tiefen Grund, den ich mit Ihnen teilen möchte.

Der Grund, warum QuickPlanX eine von allen geliebte App werden kann, ist, dass sich unser Ziel nie geändert hat: Die besten Projektmanagement-Praktiken der Branche in Form einer Anwendung mit allen zu teilen. Wir wollen nicht nur ein Werkzeug zum "Zeichnen von Gantt-Diagrammen" sein, sondern verpflichten uns, ein Träger effizienten Managementdenkens zu sein.

Aus dieser Perspektive ist jeder Vorschlag, den Sie machen, im Wesentlichen das Teilen Ihrer exklusiven Erfahrung und Best Practices mit der Community.

Deshalb sind wir so begierig darauf, die Schmerzpunkte und Vorteile hinter den Vorschlägen zu verstehen – denn nur wenn wir Ihre "Praxismethoden" wirklich verstehen, können wir sie in universelle Funktionen verwandeln, die letztendlich Ihnen und Tausenden von Benutzern wie Ihnen zugutekommen.

---

Anhang: Unter welchen Bedingungen wird ein Vorschlag priorisiert?

(Wenn Sie nur wissen wollen, "warum wir nach Hintergrund fragen", reicht das Lesen des Obigen aus. Der folgende Inhalt ist für Freunde gedacht, die an Produktentscheidungen interessiert sind.)

Um den Prozess transparenter zu gestalten, möchten wir auch ehrlich die "Entscheidungskriterien" des Entwicklungsteams teilen.

Wenn wir die "Schmerzpunkte" und "Vorteile" hinter Ihrem Vorschlag nicht verstehen, können wir nicht auf der Grundlage der folgenden 7 Kerndimensionen urteilen, was dazu führen kann, dass eine ursprünglich gute Idee auf Eis gelegt wird.

1. Kernausrichtung (Core Alignment)

Dies ist das primäre Prinzip. Obwohl unsere Anwendung Erweiterungen unterstützt, muss sie sich um Kernfunktionen drehen.

• Einige Funktionen sind großartig, aber wenn sie zu weit von der Kernpositionierung der App entfernt sind, müssen wir sie möglicherweise widerstrebend aufgeben, um die Software einfach und fokussiert zu halten.

2. Benutzerreichweite (User Reach)

Wir müssen beurteilen, ob dies ein "universeller Schmerzpunkt" oder ein "Spezialfall" ist.

• Wenn eine Funktion nur ein sehr spezielles Bedürfnis für eine sehr kleine Anzahl von Benutzern lösen kann, wird ihre Priorität in der Regel nach Funktionen eingestuft, die "der Mehrheit zugutekommen".

3. Wertgröße (Value Magnitude)

Selbst wenn es für die meisten Menschen nützlich ist, müssen wir auch sehen, ob die Verbesserung, die es bringt, signifikant genug ist.

• Zum Beispiel: Das Speichern eines Klicks für eine Funktion, die nur einmal pro Woche verwendet wird, ist möglicherweise kein hoher Wert; aber wenn es sich um eine Operation handelt, die Dutzende Male am Tag wiederholt wird, ist selbst das Sparen einer Sekunde ein riesiger Wert.

4. ROI & Balance

Natürlich müssen wir auch Entwicklungsressourcen ausgleichen.

• Wir werden die Kosten für die Implementierung dieser Funktion (Entwicklungszeit, Systemkomplexität) bewerten und ob sie proportional zu den Vorteilen ist, die sie bringt.

5. Allgemeinheit vor Spezifität (Generality over Specificity)

Hier entsteht am leichtesten Uneinigkeit. Manchmal soll die von Ihnen vorgeschlagene Funktion ein Problem "direkter" lösen, aber die vorhandenen Kern- oder Basisfunktionen der App unterstützen diese Anforderung tatsächlich bereits.

• Es ist nicht so, dass vorhandene Funktionen schlecht sind, aber wir neigen dazu, die Allgemeinheit des Systems beizubehalten. Wenn wir für jedes spezifische Szenario eine "dedizierte Verknüpfung" hinzufügen, wird die Software schnell komplex und schwer zu bedienen. Sofern das Szenario nicht extrem hochfrequent ist, werden wir die Aufrechterhaltung der universellen Basisunterstützung priorisieren.

6. Spezialisierung & Ökosystem (Specialization & Ecosystem)

Oftmals ist eine Anforderung tatsächlich die stärke eines anderen professionellen Feldes.

• Zum Beispiel, obwohl unsere App Tabellenansichten unterstützt, ist unser Kern "Projektplanung", und wir können (und sollten) nicht die leistungsstarken Berechnungs- und Diagrammfähigkeiten von Excel replizieren; oder für komplexe PDF-Bearbeitung oder Drucklayout gibt es bereits sehr professionelle Software auf dem Markt, die das besser kann.
• In dieser Situation ziehen wir es vor, anstatt eine "grobe und aufgeblähte" eingebaute Version zu entwickeln, die "Export"- oder "Zusammenarbeits"-Erfahrung zu optimieren, damit Sie Daten einfacher zur Verarbeitung an diese professionelle Software senden können.

7. Unabhängigkeit & Best Practices (Independence & Best Practices)

QuickPlanX ist keineswegs ein einfacher Klon anderer ähnlicher Apps auf dem Markt. Unser Ziel ist es, Best Practices der Branche zu einem unglaublich erschwinglichen Preis an die Öffentlichkeit zu bringen.

• Um diese Kosteneffizienz und leichte Erfahrung aufrechtzuerhalten, müssen wir vermeiden, Funktionen wie diese teure Unternehmenssoftware anzuhäufen. Daher ist "andere Apps haben es" niemals ein Grund für unsere Entwicklung. Wir bleiben lieber einzigartig und rationalisiert, als aufgebläht und teuer zu werden, um allen Bedürfnissen gerecht zu werden.

8. Angemessenheit & Compliance (Appropriateness & Compliance)

Wir behalten uns das Recht vor, Vorschläge abzulehnen, die wir für unangemessen halten.

• Dazu gehören Vorschläge, die unklar sind oder die gegen Gesetze, Vorschriften oder kulturelle Normen verstoßen.
• Alle anderen Vorschläge, die wir für unangemessen halten.

Das Teilen dieser Informationen dient dazu, Ihnen klarer zu machen, welche Faktoren wir bei der Produktplanung berücksichtigen. Wir hoffen, Ihre "Hintergrundgeschichte" zu nutzen, um uns zu helfen, die richtige Entscheidung unter diesen komplexen Dimensionen zu finden.

Jede Stimme hallt wider (Every Voice Echoes)

Schließlich möchten wir aufrichtig ausdrücken:

Für jeden erhaltenen Vorschlag werden wir uns bemühen, zu entdecken, wie jeder diese App nutzt und welche Gedanken dahinterstecken.

Schließlich sind Sie, obwohl wir mit Code vertraut sind, der Experte Ihres eigenen Workflows. Wenn wir nur eine einsame Funktionsanweisung erhalten, ist es für uns manchmal wirklich schwer, ihr Geheimnis in Ihrer tatsächlichen Nutzung zu durchdringen, und wir könnten die Gelegenheit verpassen, Ihnen zu helfen.

Aber mit nur diesem kleinen Stück zusätzlicher Hintergrundinformationen könnte die Situation völlig anders sein.

Selbst wenn Ihr spezifischer Vorschlag aus verschiedenen Gründen nicht angenommen wird, ist er für uns dennoch eine riesige Hilfe. Ihr Feedback hilft uns, ein vollständigeres Benutzerprofil zusammenzustellen und potenzielle blinde Flecken in bestehenden Designs aufzuzeigen. Diese gesammelten Feedback-Teile könnten eines Tages eine brandneue, bessere Idee hervorbringen.

Danke an jeden Freund, der bereit ist, Zeit zu investieren, um Feedback zu geben; es ist Ihre echte Erfahrung, die diese App immer besser macht.