Documentación de usuario para mi aplicación

ManualDurante los años que llevo en el desarrollo de software todavía no he dado con la forma “perfecta” para ofrecer una documentación clara y eficiente para los usuarios de la aplicación.

Una documentación de usuario efectiva debería permitir :

  • Resolver dudas sobre en que consiste la aplicación y cuales son sus características
  • Encontrar solución a los problemas generales que pueda encontrarme
  • Que tenga unos textos claros y concisos sin irse por las ramas
  • Aportar una información extra a lo que pueda ver en la aplicación
  • Consejos de como sacarle más partido a la aplicación
  • Indexable por los buscadores
  • Poder buscar por palabras internamente

Mantenimiento

Sin duda lo más complicado de una documentación de usuario es mantenerla. Un producto software esta vivo y se le van añadiendo funcionalidades, la documentación sea mucha o poca, debe ir actualizándose al mismo ritmo.

Elementos que van encontra del mantenimiento

  • El tamaño. Cuanto más grande sea la documentación más dificil será tenerla al día. Menos es más
  • Elementos gráficos, capturas de pantalla y vídeos son enemigos del mantenimiento, generalmente en poco tiempo quedan desfasados mostrando pantallas de versiones anteriores que confunden al usuario
  • Descripciones exageradas de las pantallas (Ejemplo. Pincha en el botón azul redondeado a la derecha del texto nombre ) esas descripciones no aportan mucho valor pero al igual que las capturas quedan desfasados al cabo de poco tiempo cuando un cambio en el interfaz de las aplicaciones provoca que la descripción no detalle lo que realmente ve el usuario.

Buenas ayudas que conozco

Ayudas de Google
Google se esmera en no incluir capturas de pantalla, siempre lo explica con texto, lo que facilita su mantenimiento respecto los constantes cambios que van añadiendo.

Jenkins
Esta documentación tiene una buena división general ( Conoce, Usa, Extiende ) que permite ubicarte facilmente en que información necesitas.

Usar un registro DNS CNAME para hacerte la vida más fácil

Velneo vClientLa nube de Velneo esta teniendo éxito y ya son muchos los que utilizan habitualmente v7cloud*.velneo.com, para desarrollar, ejecutar e implantar.

Esta sugerencia puede ayudarte a conseguir una dirección de Velneo Cloud más personal.

Si quieres acceder a tu vServer de una forma más directa, al estilo:

vatp://app.empresa.com:12345

Solamente debes añadir un registro CNAME en la configuración de DNS de tu dominio “empresa.com”

El registro DNS sería algo como esto:

app CNAME v7cloud1.velneo.com

Debes poner el nombre de v7cloud*.velneo.com que corresponde con tu vrl.

Un registro CNAME indica que las solicitudes de resolución para un nombre sea resueltas con el valor del dominio indicado.

De esta forma, no te tendrás que preocupar si Velneo cambia de ip alguno de sus servidores, tu DNS siempre estará correcta.

Hay muchas páginas en internet que nos dan pistas de como crear un registro CNAME, pero lo más cómodo es que consultes la información  donde tengas tu gestión de DNS

En este enlace de Google hay información de como configurar un registro CNAME en varios proveedores

¿Cómo repercute la latencia en mis aplicaciones?

Lo que dice Wikipedia de la latencia:

En redes informáticas de datos se denomina latencia a la suma de retardos temporales dentro de una red. Un retardo es producido por la demora en la propagación y transmisión de paquetes dentro de la red.

Vista de Gijón

En la era de las aplicaciones para internet hay que tener muy encuenta como la latencia puede ser nuestro enemigo.

Hasta hace poco tiempo el problema de una aplicación era el ancho de banda, que consiste en la cantidad de datos que podían viajar por segundo ( 1 Mb/s , 10 Mb/s ). Con el tiempo, en general, las conexiones ya permiten transmisiones de gran cantidad de datos por segundo.

Por otro lado la latencia es el tiempo que tarda en ir un paquete de un punto a otro.

¿Por qué es la latencia importante para las aplicaciones?

En las aplicaciones donde existe una parte cliente y servidora, la comunicación entre estos dos elementos es constante, enviandose y recibiendo datos para las distintas acciones del usuario. Si durante el desarrollo de la aplicación no se ha tenido en consideración la posible latencia, el usuario podrá llegar a odiar la aplicación ya que tendrá que sufrir constantes esperas entre una y otra acción.

¿Cuál es la latencia en red local?

Normalmente es menor a 1 ms, 50 veces más rapido que una conexión nacional y 100 veces más rápido que una conexión intercontinental.

¿Cómo podemos reducir la latencia entre el servidor y el cliente?

Esto está en manos de las redes de comunicaciones, y parece un problema complejo, porque nos encontramos con limites físicos ( Velocidad de la luz y esas cosas ;-) )
Siempre te queda la opción de poner el servidor más cerca de los usuarios.

¿Cómo puedo reducir los efectos de la latencia?

Existen muchas técnicas, pero basicamente debemos de buscar que los efectos de la latencia no afecten a las acciones del usuario.

  • Evitar las multiples llamadas consecutivas al servidor.
  • Utiliza procesos en segundo plano.
  • Utiliza procesos en el servidor.
  • Programa en un entorno hostil para detectar en desarrollo los pequeños detalles que hacen una gran aplicación.

Te recomiendo el post de Jarboleya sobre consejos para programar aplicaciones en la nube

No es un sprint es una maratón

ZapatillaEn el desarrollo ágil de software, se habla de sprint al periodo de tiempo de una iteración, es la parte repetible y que debe ir mejorando poco a poco.
Pero cuando hablamos de un desarrollo de software podemos buscarle también una perspectiva mayor y hablar que esos sprints están dentro de una gran maratón.

  • Hay que dosificar las fuerzas, el desarrollo dura mucho tiempo.
  • Contar con el dinero o los recursos para llegar a meta ( o como repostar recursos en el camino )
  • Pensar bien a que grupo te unes para equiparar fuerzas.
  • El muro de los 30 km
  • Una estrategia de carrera clara pero flexible a las circunstancias.
  • Saber cuando has llegado a meta y no correr a lo Forest Gump.

¿Corres maratones o solo haces sprints?

Una vez quieras vender tu producto tendrás que correr otro maratón

¿El cliente prefiere que desarrolles con calidad o rapidez?

Sencillez

Generalmente son dos parámetros que se contradicen, si hago un producto más rápidamente lo hago con menos calidad y si lo hago con calidad requiere mayor tiempo de desarrollo.

Existe el factor coste, invierto más dinero y lo consigo con más calidad y menos tiempo. Pero en el mundo real con más dinero tendrás más gente, más gente es más tiempo, más gestión y posiblemente menos calidad.

Si le preguntamos al cliente te dira que lo quiere rápido, pero asume que tiene calidad, si no funciona bien, ¿para que le vale?

Una posible solución a este dilema es menos.

  • Si entregas algo con menos funcionalidades, lo podrás hacer en menos tiempo y con más calidad
  • Si tienes menos funcionalidades las podrás probar mejor
  • Si tienes menos funcionalidades tendrás menos errores
  • Si tienes menos funcionalidades tendrás menos código que mantener

Pero aunque la idea parece fácil, es extremadamente complicado saber cuales son las mínimas funcionalidades que conseguirán satisfacer las necesidades de tu cliente.

Menos, es más cálidad y más rapidez!

La calidad del software es responsabilidad de toda la empresa

Normalmente pensamos que la calidad de un software es responsabilidad exclusiva del departamento de desarrollo, ellos son los responsables de programar y de hacer un producto de calidad.

Pero en realidad el resto de departamentos son complices de la calidad del producto:

  • Si el departamento de soporte presiona para cambios rápidos y sin probar, no esta ayudando a la calidad.
  • Si la dirección estratégica de la empresa va en el camino de más y más funcionalidades, no esta ayudando a la calidad.
  • Si los comerciales piden incorporar en tiempo record las nuevas funcionalidades que tiene la competencia, no esta ayudando a la calidad.
  • Si el departamento de diseño exige que se incorporen imagen y videos super atractivos sin importar los recursos, no esta ayudando a la calidad.

¿Quien lucha por dedicar tiempo a la calidad de las apps?

Todo el equipo tiene que ser consciente que existen muchos trabajos relacionados con la programación que nos ayudan a tener un producto de calidad.

  • Mejorar la usabilidad
  • Refactorizar código
  • Quitar código obsoleto
  • Actualizar librerías
  • Mejorar la velocidad de los procesos
  • Realizar pruebas de carga
  • Automatizar procesos de prueba

Estos trabajos consumen mucho tiempo y toda la empresa debe darse cuenta que son necesarios para que el producto mejore día a día.

La calidad de un producto debería nacer desde la estrategia de la empresa e ir descendiendo por los departamentos hasta su aplicación directa en los departamentos más técnicos. No es un trabajo aislado de unos locos de la programación.