Uw ideeën zijn altijd welkom

Een kleine "versnellingstip" voor vrienden die suggesties doen

Als ontwikkelaars van QuickPlanX is een van onze gelukkigste momenten elke dag het ontvangen van uw functiesuggesties voor deze iOS/macOS projectbeheer-app. Het geeft ons het gevoel dat het echt een deel van uw werk en leven is geworden.

Een uitstekende app vertrouwt op een grote hoeveelheid gebruikersfeedback. We verwelkomen alle ideeën met betrekking tot functieverbeteringen, zelfs als het maar een eenvoudige zin is.

Na ontvangst van feedback streven we ernaar de achtergrondinformatie achter uw suggestie te begrijpen, door de pijnpunten te analyseren die het beoogt op te lossen of de mogelijke voordelen. Als uw suggestie ons echter direct kan informeren over de op te lossen pijnpunten of de verwachte voordelen, zal de verwerkingssnelheid en de kans op acceptatie aanzienlijk worden verhoogd.

Waarom vragen we soms "Waarom"?

Dit verklaart waarom we, wanneer we geconfronteerd worden met een ogenschijnlijk eenvoudige suggestie, soms niet onmiddellijk "Ja" zeggen, maar in plaats daarvan details herhaaldelijk bevestigen. Dit is geen ontwijking, maar omdat vanuit een ontwikkelingsperspectief:

Er zijn vaak meerdere paden om hetzelfde doel te bereiken.

Als we ons alleen concentreren op de "specifieke functie" die u hebt voorgesteld, is het gemakkelijk om beperkt te worden tot een specifieke implementatiemethode. Maar als we uw "pijnpunten" en "voordelen" kennen, bezitten we een bredere visie:

• Een betere oplossing vinden: We zouden onze bekendheid met het ontwerp en de technologie van de app kunnen gebruiken om een geschiktere, snellere of evenwichtigere oplossing voor uw idee te ontwerpen.
• Bestaande oplossingen ontdekken: We zouden kunnen ontdekken dat andere bestaande functies al aan uw vereisten kunnen voldoen, waardoor u het probleem onmiddellijk kunt oplossen zonder te wachten.
• Misverstanden voorkomen: De mogelijkheid om uw suggestie verkeerd te begrijpen neemt aanzienlijk af, waardoor we ervoor zorgen dat wat we maken precies is wat u echt nodig hebt.
• Efficiëntie verbeteren: Door de communicatiekosten van herhaalde bevestigingen te verminderen, kunnen we evaluatie en besluitvorming sneller voltooien.

Een echt klein voorbeeld

Een gebruiker suggereerde eens sterk: "Ik hoop een e-mailintegratiefunctie toe te voegen zodat ik e-mails rechtstreeks in de app kan verzenden."

Hoewel deze functie intuïtief klinkt, vroegen we naar het scenario erachter: "Welke specifieke informatie wilt u verzenden? En naar wie?"

De gebruiker legde uit: "Ik moet gedetailleerde instructies voor specifieke taken naar outsourcingpersoneel sturen voor bevestiging."

Toen we dit hoorden, begrepen we het. Het bleek dat zijn pijnpunt niet was "e-mails in de app moeten schrijven", maar "hoe informatie snel te extraheren en te delen".

Als we alleen "e-mailintegratie" zouden doen, zou de functie zeer beperkt en opgeblazen zijn. In feite variëren de velden die iedereen moet delen enorm (sommigen willen datums, sommigen alleen notities), en de deelkanalen zijn niet beperkt tot e-mail (misschien ook WeChat, Slack).

Dus schakelden we over op het ontwikkelen van een flexibelere "Aanpasbare Taaktekstuitvoer" functie.

• Voor die gebruiker: Hij paste het uitvoerformaat aan (alleen "Taaknaam + Notities" behouden) en stuurde het rechtstreeks via e-mail via de systeemdeelfunctie, wat het probleem perfect oploste.
• Voor iedereen: Deze flexibele en configureerbare uitvoermethode voldeed ook aan de verschillende deelbehoeften van andere gebruikers, zoals het schrijven van dagelijkse rapporten of het verzenden van WeChat-berichten.

Dit is de magie van "achtergrondinformatie". Het hielp ons een oorspronkelijk smalle "e-mailvereiste" om te zetten in een "universele functie" die iedereen ten goede komt.

Praat meer over "Context", geen noodzaak om "Docs" te schrijven

Dus, de volgende keer dat u voelt dat een vereiste complex is of moeilijk uit te leggen in een of twee zinnen, probeer dan kort te praten over uw "Gebruikscontext".

U hoeft absoluut geen formeel vereistendocument te schrijven (natuurlijk, als u gewend bent om in detail en professioneel te schrijven, zouden we nog meer verheugd zijn).

Maar in de meeste gevallen is geen professionele terminologie nodig, en maak u geen zorgen of u gelijk of ongelijk hebt; noem gewoon de volgende twee punten terloops:

1. Welk probleem bent u tegengekomen? (bijv. De huidige operatie is te vermoeiend, foutgevoelig of onduidelijk.)
2. Hoe redt u zich nu? (bijv. Kan alleen handmatig berekenen met een pen, of moet naar instellingen gaan om schakelaars herhaaldelijk om te schakelen.)

Gewone suggestie: "Voeg een batchverwijderingsfunctie toe." Suggestie met context: "Ik moet elke dag tientallen oude gegevensitems opruimen. Het huidige ontwerp vereist één voor één naar links vegen, en mijn vingers doen pijn."

Zelfs met slechts deze ene extra zin, kunnen we vaak onmiddellijk oordelen: Dit is een hoogfrequent efficiëntieknelpunt, waardig voor prioriteitsevaluatie.

Uw ideeën zijn belangrijk, en de "Redenen" erachter zijn even kritiek

Soms kunnen enthousiaste gebruikers zoals u het niet helpen om zich zorgen om ons te maken: "Is dit beter voor de app?" of "Zal het toevoegen van deze functie de applicatie completer maken?"

In feite zijn de specifieke functiesuggesties die u voorstelt erg belangrijk; ze zijn vaak het startpunt van onze inspiratie.

Maar in vergelijking met een geïsoleerde "oplossing", wat we meer van u nodig hebben, is het "probleem zelf"—vooral wanneer we de onderliggende motivatie (pijnpunten en voordelen) niet eenvoudig kunnen begrijpen uit de functiebeschrijving, wordt deze achtergrondinformatie bijzonder kritiek.

Omdat vanuit een ontwikkelingsperspectief de "gewenste functie" slechts een van de opties is om het probleem op te lossen, terwijl het elimineren van uw "pijnpunt" ons gemeenschappelijke doel is.

Het hebben van duidelijke achtergrondinformatie (pijnpunten en voordelen) brengt twee directe voordelen:

1. Nauwkeuriger oordeel: We kunnen de echte waarde van deze functie voor u begrijpen. Sommige functies lijken "lastig", maar als we weten dat ze uw kernpijnpunten oplossen, zullen we hun prioriteit verhogen.
2. Superieure oplossingen: Net als het geval van de "Tekstuitvoer" hierboven, kunnen we misschien onze bekendheid met het systeem gebruiken om een eenvoudigere, betere oplossing voor u te vinden dan u zich oorspronkelijk had voorgesteld.

Daarom is dat echte moment waarop u vastloopt vaak belangrijker voor ons. We zullen uw voorgestelde functiesuggestie combineren met de werkelijke pijnpunten erachter om het meest geschikte technische implementatieplan voor u te bedenken.

Niet alleen suggesties doen, maar uw "Best Practices" delen

Er is nog een andere diepe reden die ik met u wil delen.

De reden waarom QuickPlanX een app kan worden die door iedereen geliefd is, is dat ons doel nooit is veranderd: De beste projectbeheerpraktijken van de industrie met iedereen delen in de vorm van een applicatie. We willen niet alleen een hulpmiddel zijn voor het "tekenen van Gantt-diagrammen", maar zijn toegewijd om een drager te zijn van efficiënt managementdenken.

Vanuit dit perspectief is elke suggestie die u doet in wezen het delen van uw exclusieve ervaring en best practices met de gemeenschap.

Daarom zijn we zo gretig om de pijnpunten en voordelen achter de suggesties te begrijpen—omdat we alleen door uw "praktijkmethoden" echt te begrijpen, ze kunnen omzetten in universele functies, waar uiteindelijk u en duizenden gebruikers zoals u van profiteren.

---

Bijlage: Onder welke voorwaarden wordt een suggestie geprioriteerd?

(Als u alleen wilt weten "waarom we om achtergrond vragen", is het lezen van het bovenstaande voldoende. De volgende inhoud is voor vrienden die geïnteresseerd zijn in productbesluitvorming.)

Om het proces transparanter te maken, willen we ook openhartig de "Beslissingscriteria" van het ontwikkelingsteam delen.

Als we de "pijnpunten" en "voordelen" achter uw suggestie niet begrijpen, kunnen we niet oordelen op basis van de volgende 7 kerndimensies, wat ertoe kan leiden dat een oorspronkelijk goed idee wordt opgeschort.

1. Kernuitlijning (Core Alignment)

Dit is het primaire principe. Hoewel onze applicatie extensies ondersteunt, moet deze draaien om kernfuncties.

• Sommige functies zijn geweldig, maar als ze te ver verwijderd zijn van de kernpositionering van de app, moeten we ze misschien met tegenzin opgeven om de software eenvoudig en gefocust te houden.

2. Gebruikersbereik (User Reach)

We moeten beoordelen of dit een "universeel pijnpunt" of een "speciaal geval" is.

• Als een functie slechts een zeer speciale behoefte voor een zeer klein aantal gebruikers kan oplossen, wordt de prioriteit meestal gerangschikt na functies die "de meerderheid ten goede komen".

3. Waardeomvang (Value Magnitude)

Zelfs als het nuttig is voor de meeste mensen, moeten we ook zien of de verbetering die het brengt significant genoeg is.

• Bijvoorbeeld: Eén klik besparen voor een functie die slechts één keer per week wordt gebruikt, is misschien geen hoge waarde; maar als het een bewerking is die tientallen keren per dag wordt herhaald, is zelfs het besparen van één seconde een enorme waarde.

4. ROI & Balans

Natuurlijk moeten we ook ontwikkelingsmiddelen in evenwicht brengen.

• We zullen de kosten van het implementeren van deze functie (ontwikkelingstijd, systeemcomplexiteit) evalueren en of deze in verhouding staat tot de voordelen die het met zich meebrengt.

5. Algemeenheid boven Specificiteit (Generality over Specificity)

Dit is waar onenigheid het gemakkelijkst ontstaat. Soms is de functie die u suggereert om een probleem "directer" op te lossen, maar de bestaande kern- of basisfuncties van de app ondersteunen die vereiste eigenlijk al.

• Het is niet dat bestaande functies slecht zijn, maar we neigen ernaar de algemeenheid van het systeem te handhaven. Als we voor elk specifiek scenario een "speciale snelkoppeling" toevoegen, wordt de software snel complex en moeilijk te gebruiken. Tenzij het scenario extreem frequent is, zullen we prioriteit geven aan het handhaven van universele basisondersteuning.

6. Specialisatie & Ecosysteem (Specialization & Ecosystem)

Vaak is een vereiste eigenlijk de kracht van een ander professioneel veld.

• Bijvoorbeeld, hoewel onze app tabelweergaven ondersteunt, is onze kern "projectplanning", en we kunnen (en mogen) de krachtige berekenings- en grafiekmogelijkheden van Excel niet repliceren; of voor complexe PDF-bewerking of afdruklay-out is er al zeer professionele software op de markt die het beter doet.
• In deze situatie geven we er de voorkeur aan om, in plaats van een "ruwe en opgeblazen" ingebouwde versie te ontwikkelen, de ervaring van "exporteren" of "samenwerken" te optimaliseren, waardoor het voor u gemakkelijker wordt om gegevens naar die professionele software te sturen voor verwerking.

7. Onafhankelijkheid & Best Practices (Independence & Best Practices)

QuickPlanX is geenszins een eenvoudige kloon van andere vergelijkbare apps op de markt. Ons doel is om de best practices van de industrie naar het publiek te brengen tegen een ongelooflijk betaalbare prijs.

• Om deze kosteneffectiviteit en lichtgewicht ervaring te behouden, moeten we voorkomen dat we functies opstapelen zoals die dure enterprise-software. Daarom is "andere apps hebben het" nooit een reden voor onze ontwikkeling. We blijven liever uniek en gestroomlijnd dan opgeblazen en duur te worden om aan alle behoeften te voldoen.

8. Geschiktheid & Naleving (Appropriateness & Compliance)

Wij behouden ons het recht voor om suggesties te weigeren die wij ongepast achten.

• Dit omvat suggesties die onduidelijk zijn, of die in strijd zijn met wetten, voorschriften of culturele normen.
• Alle andere suggesties die wij ongepast achten.

Het delen hiervan is om u duidelijker te laten weten met welke factoren we rekening houden tijdens de productplanning. We hopen uw "achtergrondverhaal" te gebruiken om ons te helpen de juiste beslissing te vinden te midden van deze complexe dimensies.

Elke stem weerkaatst (Every Voice Echoes)

Tot slot willen we oprecht uitdrukken:

Voor elke ontvangen suggestie zullen we ernaar streven te ontdekken hoe iedereen deze app gebruikt en de gedachte erachter.

Immers, hoewel we bekend zijn met code, bent u de expert van uw eigen workflow. Als we alleen een eenzame functie-instructie ontvangen, is het soms echt moeilijk voor ons om het mysterie ervan in uw werkelijke gebruik te doorgronden, en kunnen we jammer genoeg de kans missen om u te helpen.

Maar met slechts dat beetje extra achtergrondinformatie zou de situatie compleet anders kunnen zijn.

Zelfs als uw specifieke suggestie om verschillende redenen niet wordt aangenomen, is het nog steeds een enorme hulp voor ons. Uw feedback helpt ons een completer gebruikersprofiel samen te stellen en wijst op mogelijke blinde vlekken in bestaande ontwerpen. Deze verzamelde stukjes feedback kunnen op een dag een gloednieuw, beter idee baren.

Bedankt aan elke vriend die bereid is tijd te besteden aan het geven van feedback; het is uw echte ervaring die deze app beter en beter maakt.