Cómo pruebo aplicaciones

Hace un tiempo me preguntaron en Twitter (o tal vez en App.net) cómo pongo a prueba varias aplicaciones. A lo largo de los años, he reunido algunas tácticas para ayudarme en el proceso. No hay manera de que pueda trabajar con varios administradores de tareas y otras aplicaciones al mismo tiempo sin configurarme para hacerlo de antemano.

Muchos de ustedes no necesitarán llegar a los niveles que yo he alcanzado con esto. Pero si puede adoptar algún elemento de este enfoque para decidir si una aplicación, servicio o producto funcionará para usted a largo plazo, entonces estará mejor en términos de eficiencia y (lo más importante) efectividad. .

Tu PROPIA prueba

Una de las primeras cosas que hago al evaluar una aplicación o servicio es someterlo a un proceso de control. Inicialmente, usé el acrónimo AHORA para recordar ese proceso, pero desde entonces lo cambié a PROPIO (principalmente debido al año AHORA). ¹

Esto es lo que representa PROPRIO:

• O es Obvio: miro una aplicación o servicio y decido si será lo suficientemente obvio como para usarlo. Aquí es donde brillan aplicaciones como Day One y Sleep Cycle porque sé claramente para qué sirven, ya que hacen una cosa y la hacen bien. Pero aplicaciones como Evernote y Drafts pueden tener problemas aquí porque si sus casos de uso no son obvios (o lo suficientemente obvios en comparación con otra cosa), tienen una verdadera batalla cuesta arriba que enfrentar.
• W es de por qué: el “por qué” sirve como control visceral más que cualquier otra cosa. Me pregunto: “¿Por qué realmente necesito esta aplicación?” y “¿Por qué no puedo usar esta otra aplicación que ya tengo?” para asegurarme de que me tomo el tiempo para familiarizarme con la aplicación o el servicio.
• N de Necesidad: esta es la prueba de fuego final. Si no necesito la aplicación o el servicio, no será suficiente. Esto también se aplica a las aplicaciones existentes cuando se enfrentan a nueva competencia. Mis aplicaciones de escritura han pasado por este proceso varias veces, y las aplicaciones con más funciones (como Writing Kit) finalmente fueron eliminadas en favor de otra aplicación con menos funciones (como Byword) porque entran en juego otros factores. ² No considero este aspecto hasta que haya terminado con todas las demás evaluaciones, que van mucho más allá de lo obvio y el por qué. Hay más exploración que hago y comienza con un uso constante. Este uso constante se rastrea con el uso de patrones y contextos dentro de, bueno… una aplicación o servicio.

Modelos

Usar plantillas también puede resultar útil. Las plantillas vienen en todas las formas y tamaños, según la aplicación o el servicio que utilice. Por ejemplo, Asana permite la duplicación de proyectos, por lo que cuando quiero probar varios componentes, simplemente duplico un proyecto existente y juego con él. Asana permite el uso de colores, por eso utilizo esta función para indicar con qué jugar y con qué trabajar.

Contextos

Creo firmemente en utilizar la menor cantidad de contextos posible, y con los que me he alineado durante el último año han sido los niveles de energía (alto, normal, bajo), recados y algún día/tal vez.

Pero los que van y vienen suelen tener el nombre de las aplicaciones y servicios que estoy probando.

Para asegurarme de prestar la atención adecuada a las aplicaciones y servicios, asignaré ciertas tareas y proyectos a una aplicación. A la aplicación se le asignará su propio contexto (o etiqueta, según la solución de gestión de tareas que utilice). Cuando miro mis tareas diarias, a menudo uso una vista que coloca contextos/etiquetas al frente y al centro, lo que me da un disparador visual para, en este caso, ir a la aplicación en cuestión para trabajar en la tarea.

Si decido que la aplicación o el servicio pasará el corte y seguirá siendo parte de mi flujo de trabajo, asignaré las tareas y proyectos dentro de él a mis contextos habituales y también arrastraré la aplicación como contexto/etiqueta. Si decido que la aplicación no se cortará, dejo de lado la aplicación y la aplicación como contexto/etiqueta y, en algunos casos, asigno las tareas adjuntas a esa aplicación a otra aplicación (que también sería un contexto en este punto).

Básicamente, al utilizar aplicaciones como contextos/etiquetas, desencadenan su uso. De lo contrario, no se usarían lo suficiente como para evaluarlos adecuadamente y ciertamente no se usarían como parte de mis rutinas y flujo de trabajo reales.

Cuando las aplicaciones y servicios tengan la capacidad de usar plantillas de alguna forma, las usaré. Pero la mayoría de las veces, uso contextos, ya que interrumpen menos mi flujo de trabajo que trabajar con modelos. Sé que siempre puedo crear un contexto o etiqueta para una aplicación o servicio; No sé si puedo crear un modelo. En este caso, la certeza siempre vence a la incertidumbre, porque ya existen muchas otras incertidumbres involucradas al introducir una nueva aplicación o servicio.

Así es como experimento las aplicaciones. Este proceso me permite hacerlo de manera rápida y efectiva, y si bien me tomó algún tiempo aumentar esa velocidad, la efectividad ha sido bastante alta desde que comencé a usarlo porque ya construí mi estructura de resultados con anticipación.

Si ya tiene una base sólida, utilice algunas (o todas) de estas tácticas cuando pruebe nuevas aplicaciones y servicios. Podría ayudarte a encontrar aplicaciones para mejorar tu trabajo y tu vida, y eliminar las que no lo harán… o no lo harán.

Crédito de la foto: greshoj vía SXC.HU

¹ Gracias a Nick Wynja y Michael Schechter por ayudarme a comprender el orden de las siglas.
² Byword funciona en todos los dispositivos Apple que tengo sin problemas. Kit de escritura, de momento, no.

En ocasiones te puede interesar:

1. Pausa y efecto ( 1 )
2. Mejorando en 2013: ThisLife ( 1 )
3. Excepto… ( 1 )
4. Revisión: el iSlider ( 1 )

Tal vez te puede interesar:

1. Una lista de tareas pendientes no es suficiente
2. Los pros y los contras de utilizar un administrador de tareas colaborativo
3. Cómo un editor hace que la escritura en línea sea más productiva
4. solo iOS