Tus ideas son siempre bienvenidas

Un pequeño consejo de "aceleración" para amigos que hacen sugerencias

Como desarrolladores de QuickPlanX, uno de nuestros momentos más felices cada día es recibir tus sugerencias de funciones para esta aplicación de gestión de proyectos para iOS/macOS. Nos hace sentir que realmente se ha convertido en parte de tu trabajo y tu vida.

Una excelente aplicación depende de una gran cantidad de comentarios de los usuarios. Damos la bienvenida a cualquier idea sobre mejoras de funciones, incluso si es solo una frase simple.

Después de recibir comentarios, nos esforzamos por comprender la información de fondo detrás de tu sugerencia, analizando los puntos débiles que pretende resolver o los beneficios potenciales. Sin embargo, si tu sugerencia puede informarnos directamente sobre los puntos débiles a resolver o los beneficios esperados, la velocidad de procesamiento y la probabilidad de adopción aumentarán considerablemente.

¿Por qué a veces preguntamos "¿Por qué"?

Esto explica por qué, cuando nos enfrentamos a una sugerencia aparentemente simple, a veces no decimos inmediatamente "Sí", sino que confirmamos detalles repetidamente. Esto no es una evasión, sino porque desde una perspectiva de desarrollo:

A menudo hay múltiples caminos para lograr el mismo objetivo.

Si solo nos enfocamos en la "función específica" que propusiste, es fácil limitarse a un método de implementación específico. Pero si conocemos tus "puntos débiles" y "beneficios", poseemos una visión más amplia:

• Encontrar una mejor solución: Podríamos usar nuestra familiaridad con el diseño y la tecnología de la aplicación para diseñar una solución más adecuada, más rápida o más equilibrada para tu idea.
• Descubrir soluciones existentes: Podríamos encontrar que otras funciones existentes ya pueden cumplir con tus requisitos, permitiéndote resolver el problema inmediatamente sin esperar.
• Evitar malentendidos: La posibilidad de malinterpretar tu sugerencia disminuye significativamente, asegurando que lo que hacemos sea exactamente lo que realmente necesitas.
• Mejorar la eficiencia: Reducir el costo de comunicación de las confirmaciones repetidas nos permite completar la evaluación y la toma de decisiones más rápido.

Un pequeño ejemplo real

Un usuario sugirió una vez encarecidamente: "Espero agregar una función de integración de correo electrónico para poder enviar correos electrónicos directamente dentro de la aplicación."

Aunque esta función suena intuitiva, preguntamos sobre el escenario detrás de ella: "¿Qué información específica quieres enviar? ¿Y a quién?"

El usuario explicó: "Necesito enviar instrucciones detalladas para tareas específicas al personal de subcontratación para confirmación."

Al escuchar esto, entendimos. Resultó que su punto débil no era "deber escribir correos electrónicos en la aplicación", sino "cómo extraer y compartir información rápidamente".

Si solo hiciéramos "integración de correo electrónico", la función sería muy limitada e inflada. De hecho, los campos que todos necesitan compartir varían ampliamente (algunos quieren fechas, otros solo notas), y los canales para compartir no se limitan al correo electrónico (tal vez también WeChat, Slack).

Entonces, cambiamos a desarrollar una función más flexible de "Salida de texto de tarea personalizable".

• Para ese usuario: Personalizó el formato de salida (manteniendo solo "Nombre de la tarea + Notas") y lo envió directamente por correo electrónico a través de la función de compartir del sistema, resolviendo perfectamente el problema.
• Para todos: Este método de salida flexible y configurable también satisfizo las diversas necesidades de compartir de otros usuarios, como escribir informes diarios o enviar mensajes de WeChat.

Esta es la magia de la "información de fondo". Nos ayudó a transformar un "requisito de correo electrónico" originalmente estrecho en una "función universal" que beneficia a todos.

Habla más sobre el "Contexto", no es necesario escribir "Documentos"

Entonces, la próxima vez que sientas que un requisito es complejo o difícil de explicar en una o dos oraciones, intenta charlar brevemente sobre tu "Contexto de uso".

Absolutamente no necesitas escribir un documento de requisitos formal (por supuesto, si estás acostumbrado a escribir con detalle y profesionalmente, estaríamos aún más encantados).

Pero en la mayoría de los casos, no se necesita terminología profesional, y no te preocupes por tener razón o no; solo menciona los siguientes dos puntos de pasada:

1. ¿Qué problema encontraste? (por ejemplo, La operación actual es demasiado agotadora, propensa a errores o poco clara.)
2. ¿Cómo te las arreglas ahora? (por ejemplo, Solo puedo calcular manualmente con un bolígrafo, o tengo que ir a la configuración para alternar interruptores repetidamente.)

Sugerencia ordinaria: "Agregar una función de eliminación por lotes." Sugerencia con contexto: "Tengo que limpiar docenas de datos antiguos todos los días. El diseño actual requiere deslizar hacia la izquierda uno por uno, y me duelen los dedos."

Incluso con solo esta frase adicional, a menudo podemos juzgar inmediatamente: Este es un cuello de botella de eficiencia de alta frecuencia, digno de una evaluación prioritaria.

Tus ideas son importantes, y las "Razones" detrás de ellas son igualmente críticas

A veces, los usuarios entusiastas como tú no pueden evitar preocuparse por nosotros: "¿Es mejor para la aplicación hacer esto?" o "¿Agregar esta función hará que la aplicación sea más completa?"

En realidad, las sugerencias de funciones específicas que propones son muy importantes; a menudo son el punto de partida de nuestra inspiración.

Pero en comparación con una "solución" aislada, lo que más necesitamos de ti es el "problema en sí"—especialmente cuando no podemos entender simplemente la motivación subyacente (puntos débiles y beneficios) a partir de la descripción de la función, esta información de fondo se vuelve particularmente crítica.

Porque desde una perspectiva de desarrollo, la "función deseada" es solo una de las opciones para resolver el problema, mientras que eliminar tu "punto débil" es nuestro objetivo común.

Tener información de fondo clara (puntos débiles y beneficios) trae dos beneficios directos:

1. Juicio más preciso: Podemos entender el valor real de esta función para ti. Algunas funciones parecen "problemáticas", pero si sabemos que resuelven tus puntos débiles principales, aumentaremos su prioridad.
2. Soluciones superiores: Al igual que el caso de la "Salida de texto" anterior, tal vez podamos usar nuestra familiaridad con el sistema para encontrar una solución más simple y mejor para ti de lo que imaginaste originalmente.

Por lo tanto, ese momento real en el que te quedas atascado es a menudo más importante para nosotros. Combinaremos tu sugerencia de función propuesta con los puntos débiles reales detrás de ella para concebir el plan de implementación técnica más adecuado para ti.

No solo hacer sugerencias, sino compartir tus "Mejores Prácticas"

Hay otra razón profunda que quiero compartir contigo.

La razón por la cual QuickPlanX puede convertirse en una aplicación amada por todos es que nuestro objetivo nunca ha cambiado: Compartir las mejores prácticas de gestión de proyectos de la industria con todos a través de la forma de una aplicación. No queremos ser solo una herramienta para "dibujar diagramas de Gantt", sino que estamos comprometidos a ser un portador de pensamiento de gestión eficiente.

Desde esta perspectiva, cada sugerencia que haces es esencialmente compartir tu experiencia exclusiva y mejores prácticas con la comunidad.

Es por eso que estamos tan ansiosos por entender los puntos débiles y los beneficios detrás de las sugerencias, porque solo al comprender realmente tus "métodos de práctica" podemos transformarlos en funciones universales, beneficiando finalmente a ti y a miles de usuarios como tú.

---

Apéndice: ¿Bajo qué condiciones se priorizará una sugerencia?

(Si solo quieres saber "por qué pedimos antecedentes", leer lo anterior es suficiente. El siguiente contenido es para amigos interesados en la toma de decisiones de productos.)

Para hacer el proceso más transparente, también queremos compartir francamente los "Criterios de Decisión" del equipo de desarrollo.

Si no entendemos los "puntos débiles" y los "beneficios" detrás de tu sugerencia, no podemos juzgar en base a las siguientes 7 dimensiones clave, lo que puede causar que una idea originalmente buena sea archivada.

1. Alineación central (Core Alignment)

Este es el principio principal. Aunque nuestra aplicación admite extensiones, debe girar en torno a las funciones principales.

• Algunas funciones son geniales, pero si están demasiado lejos del posicionamiento central de la aplicación, es posible que tengamos que renunciar a ellas a regañadientes para mantener el software simple y enfocado.

2. Alcance del usuario (User Reach)

Necesitamos evaluar si este es un "punto débil universal" o un "caso especial".

• Si una función solo puede resolver una necesidad muy especial para un número muy pequeño de usuarios, su prioridad generalmente se clasificará después de las funciones que "benefician a la mayoría".

3. Magnitud del valor (Value Magnitude)

Incluso si es útil para la mayoría de las personas, también necesitamos ver si la mejora que aporta es lo suficientemente significativa.

• Por ejemplo: Ahorrar un clic para una función utilizada solo una vez a la semana podría no ser de alto valor; pero si es una operación repetida docenas de veces al día, incluso ahorrar un segundo es un valor enorme.

4. ROI y Equilibrio

Por supuesto, también necesitamos equilibrar los recursos de desarrollo.

• Evaluaremos el costo de implementar esta función (tiempo de desarrollo, complejidad del sistema) y si es proporcional a los beneficios que aporta.

5. Generalidad sobre Especificidad (Generality over Specificity)

Aquí es donde surge el desacuerdo más fácilmente. A veces, la función que sugieres es para resolver un problema más "directamente", pero las funciones principales o básicas existentes de la aplicación en realidad ya admiten ese requisito.

• No es que las funciones existentes sean malas, pero tendemos a mantener la generalidad del sistema. Si agregamos un "atajo dedicado" para cada escenario específico, el software se volverá rápidamente complejo y difícil de usar. A menos que el escenario sea extremadamente frecuente, priorizaremos mantener el soporte básico universal.

6. Especialización y Ecosistema (Specialization & Ecosystem)

Muchas veces, un requisito es en realidad la fortaleza de otro campo profesional.

• Por ejemplo, aunque nuestra aplicación admite vistas de tabla, nuestro núcleo es la "planificación de proyectos", y no podemos (y no debemos) replicar las poderosas capacidades de cálculo y gráficos de Excel; o para la edición compleja de PDF o el diseño de impresión, ya hay software muy profesional en el mercado que lo hace mejor.
• En esta situación, en lugar de desarrollar una versión integrada "cruda e inflada", preferimos optimizar la experiencia de "exportación" o "colaboración", facilitando el envío de datos a ese software profesional para su procesamiento.

7. Independencia y Mejores Prácticas (Independence & Best Practices)

QuickPlanX no es de ninguna manera un simple clon de otras aplicaciones similares en el mercado. Nuestro objetivo es llevar las mejores prácticas de la industria al público a un precio increíblemente asequible.

• Para mantener esta rentabilidad y experiencia ligera, necesitamos evitar acumular funciones como ese costoso software de nivel empresarial. Por lo tanto, "otras aplicaciones lo tienen" nunca es una razón para nuestro desarrollo. Preferimos seguir siendo únicos y optimizados en lugar de volvernos inflados y caros para satisfacer todas las necesidades.

8. Idoneidad y Cumplimiento (Appropriateness & Compliance)

Nos reservamos el derecho de rechazar sugerencias que consideremos inapropiadas.

• Esto incluye sugerencias que no son claras, o que entran en conflicto con leyes, regulaciones o normas culturales.
• Cualquier otra sugerencia que consideremos inapropiada.

Compartir esto es para informarte más claramente sobre los factores que consideramos durante la planificación del producto. Esperamos usar tu "historia de fondo" para ayudarnos a encontrar la decisión correcta entre estas complejas dimensiones.

Cada voz resuena (Every Voice Echoes)

Finalmente, queremos expresar sinceramente:

Para cualquier sugerencia recibida, nos esforzaremos por descubrir cómo todos usan esta aplicación y el pensamiento detrás de ella.

Después de todo, aunque estamos familiarizados con el código, tú eres el experto de tu propio flujo de trabajo. Si solo recibimos una instrucción de función solitaria, a veces es realmente difícil para nosotros penetrar su misterio en tu uso real, y podemos perder lamentablemente la oportunidad de ayudarte.

Pero con solo ese poco de información de fondo adicional, la situación podría ser completamente diferente.

Incluso si tu sugerencia específica no se adopta por varias razones, sigue siendo de gran ayuda para nosotros. Tus comentarios nos ayudan a armar un perfil de usuario más completo y señalan posibles puntos ciegos en los diseños existentes. Estos bits de comentarios reunidos podrían algún día dar a luz a una idea nueva y mejor.

Gracias a cada amigo dispuesto a dedicar tiempo a dar su opinión; es tu experiencia real la que hace que esta aplicación sea cada vez mejor.