Llegamos a ustedes gracias a:



Reportajes y análisis

5 errores en el desarrollo de aplicaciones móviles

Y cómo puede evitarlos

[24/07/2017] El futuro de la tecnología empresarial radica en las aplicaciones -principalmente en las aplicaciones móviles que proveen las mismas funciones en prácticamente todas las plataformas para dispositivos móviles, desktops y online. Pero el pasado, en la forma de procesos antiguos y carteras de aplicaciones que tienen décadas de antigüedad, aún puede obstaculizar el camino hacia el futuro.

Modernizar una cartera de aplicaciones nunca es fácil, pero si se hace correctamente, puede ser una ventaja para la compañía -o escuela u otra organización-, ya que potencia la productividad, la interacción con los empleados y la satisfacción del cliente.

Aunque ahora muchas organizaciones se concentran rutinariamente en desplegar soluciones móviles, usualmente desarrolladas para despliegues en la nube, no toda iniciativa es exitosa. A veces, los empleados o clientes rechazan las nuevas aplicaciones. En otros casos, los usuarios deciden trabajar esquivando las aplicaciones empresariales para cumplir sus tareas sin tener que usarlas.

Cuando las iniciativas de aplicaciones fallan, usualmente lo hacen por razones diversas. En resumen, los departamentos de TI y los desarrolladores empresariales que buscan adoptar una nueva manera de hacer las cosas no planean con anticipación.

Aquí tenemos cinco de las razones más comunes que pueden ocasionar el fracaso de las iniciativas de desarrollo -y cómo puede evitarlas.

Crear en lugar de comprar

Uno de los conceptos erróneos más grandes cuando se está definiendo la estrategia de aplicaciones de la empresa, es pensar que uno tiene que crear todo internamente. La necesidad de aplicaciones personalizadas, diseñadas para procesos internos específicos que son propiedad de la empresa, es una perspectiva muy antigua. Por años, incluso décadas, este nivel de desarrollo interno no era una alternativa. Se trataba de una necesidad. Incluso cuando las soluciones externas fueron parte de la ecuación, muchas requerían de una personalización extensa. Esto dio como resultado que muchas organizaciones grandes continúan asumiendo que deben crear sus propias aplicaciones internamente.

No es necesariamente así.

En el mundo de hoy, que se centra en dispositivos móviles y que tiene a la nube como base, este enfoque es muy anticuado. Con servicios de nube altamente capaces y flexibles que ofrecen sus propias API y SDK, es fácil tomar productos existentes, vincularlos y divisar soluciones en un tiempo mucho más reducido. La necesidad central aquí es realmente entender los flujos de trabajo de los usuarios.

También existen aplicaciones que las compañías pueden desplegar con una personalización mínima. Las soluciones de nube para gestionar gastos como Concur, aplicaciones como ADP e incluso la suite de herramientas de Google, son soluciones bastante formadas que encajan fácilmente dentro de una estrategia de aplicaciones móviles; no existe la necesidad de trabajar en el desarrollo de una nueva herramienta cuando ya las tiene disponibles y además se actualizan con regularidad.

Empezar con algo demasiado grande

Cuando se trata de decidir qué aplicaciones se van a desplegar, no piense en grande. Eso ayuda a evitar un gran error, donde 'gran' es la palabra importante. Muchas organizaciones intentan cambiar sus aplicaciones más importantes y más utilizadas al ámbito móvil -y a la nube- primero. O intentan desarrollar demasiadas aplicaciones al mismo tiempo. A veces ambas cosas. Esto es un error. Es importante empezar por algo pequeño y simple. De esa manera, los desarrolladores, el equipo de TI y los usuarios finales pueden obtener una sensación de los cambios que se están realizando, aprender con el progreso y enfrentar desafíos en situaciones de pequeña escala -no en sistemas de misión crítica.

La otra ventaja es que puede lograr una victoria fácil. Si escoge un problema que es relativamente fácil de resolver, uno que hará que la vida de los usuarios sea mucho mejor, puede obtener la experiencia que necesita mientras demuestra que puede manejar el desarrollo de aplicaciones y la transición hacia un enfoque de negocios que prioriza a los dispositivos móviles. Eso le hace ganar capital político que puede ser crucial para obtener respaldo -y financiamiento- para proyectos futuros y de mayor tamaño.

No involucrar a los usuarios

La tendencia de vinculación entre el área de TI y los consumidores involucra permitir que los usuarios tomen el control de la tecnología para crear soluciones y flujos de trabajo por cuenta propia. Esto hace que sea crucial reconocer que los usuarios finales de las aplicaciones empresariales son los interesados más importantes en todos los proyectos de aplicaciones. La razón es simple: Si una aplicación no se amolda a sus necesidades, o se tiene una experiencia de usuario incómoda, los usuarios no la utilizarán. Peor aún, terminarán por encontrar soluciones que son menos seguras e incapaces de integrarse con otras soluciones.

Involucrar a los usuarios puede ser tan simple como invitarlos a una o dos reuniones. Uno tiene que entender las funciones de sus trabajos, requisitos, puntos problemáticos -que debería intentar resolver- y flujos de trabajo. Seguir los pasos de los usuarios por unos cuantos días o una semana, hacer preguntas y comprometerse con ellos por completo le permitirá entender qué es lo que reamente necesita hacer una aplicación.

Otra manera de entender lo que una aplicación móvil debería hacer es revisar las especificaciones y requisitos originales de su contraparte de escritorio -en el caso que exista-. Esta información, junto con el conocimiento institucional, puede generar un entendimiento aún más profundo del que se necesita -e incluso podría guiarle hacia el desarrollo de una aplicación de una forma mucho más efectiva que simplemente observar cómo trabajan los usuarios.

No asegurarse de que la infraestructura/sistema de backend estén listos

Este error se comete frecuentemente con cualquier despliegue de aplicación, ya sea para móviles, escritorio o para la web. Independientemente de sus sistemas backend a los que sus aplicaciones tendrán que conectarse -dentro de las instalaciones, nube privada, nube pública, proveedor externo, etcétera- uno tiene que cerciorarse de que pueda tolerar la carga de nuevos usuarios. También debe asegurarse de que su infraestructura inalámbrica sea lo suficientemente sólida como para manejar el tráfico adicional generado por una aplicación. Al igual que con dicho despliegue, una de las mejores opciones es un lanzamiento en fases, donde grupos discretos reciben acceso en periodos separados. Eso le permite visualizar las necesidades de infraestructura y hacer ajustes en el camino.

No hacer pruebas en todos los dispositivos

Este error con frecuencia es un desafío particular. Cuando se desarrolla una aplicación o se considera a un producto existente para un despliegue, las pruebas previas son cruciales. En la era del escritorio, esto era bastante fácil. Uno tenía un número establecido de configuraciones de estaciones de trabajo que estaban bajo el completo control del área de TI. Simplemente se realizaban pruebas en los escritorios apropiados y no necesitaba hacer nada más.

El ámbito móvil y el BYOD han volteado de cabeza ese enfoque. Ahora, las compañías tienen que lidiar con varios dispositivos con especificaciones que varían de acuerdo con su hardware, tamaño de pantalla, versión de sistema operativo, aplicaciones instaladas por usuarios, operadores y otras redes, así como accesorios. En el caso de BYOD y los dispositivos de uso mixto, uno tiene que competir con los datos personales que se encuentran en los dispositivos, así como con el comportamiento del usuario. Las pruebas se han vuelto más relevantes.

Este problema es particularmente severo con Android, que es una razón por la cual iOS es más común en los ámbitos empresariales. La fragmentación del sistema operativo de Android es producto de una amplia gama de versiones en uso (aún puede encontrar dispositivos siendo enviados con Android KitKat), así como las personalizaciones del fabricante y del operador, junto a un proceso de actualización bastante draconiano que complica las cosas. Existen miles de variaciones de Android en uso, lo que significa que su aplicación podría funcionar excelente en los dispositivos más comunes -digamos, el Pixel o en los últimos teléfonos Galaxy- pero podría fallar a la hora de operar en algunos dispositivos más antiguos o de gama baja.

iOS tiene menos desafíos porque existe un conjunto limitado de dispositivos y Apple proporciona actualizaciones de sistema operativo directamente, asegurándose de que la vasta mayoría de iPhones e iPads estén operando la última versión. Aun así, puede que haya problemas con algunos dispositivos más viejos de Apple que difieren en tamaños de pantalla y hardware.

Después existen plataformas como Windows 10 Mobile o incluso solo tabletas con Windows 10. Aunque son pequeñas en número, probar el software en ellas sigue teniendo sentido si es que es posible hacerlo.

Idealmente, la prueba de hardware debería incluir a todos los teléfonos de bandera actuales y recientes, una selección de los dispositivos de rango medio más comunes pertenecientes a los principales fabricantes, y si es posible, varios dispositivos de gama baja. La mezcla debería incluir una variedad de versiones de sistemas operativos que tengan tres años de antigüedad, así como versiones diferentes de configuraciones de hardware.

Haciendo un recuento

Las aplicaciones empresariales son un prospecto emocionante, con un enorme potencial para casi todas las organizaciones. Éstas ofrecen nuevas y mejores maneras de cumplir tareas, incrementar la eficiencia y la productividad y crear mejores interacciones con los clientes y empleados. Pero implican un desafío. Si no funcionan bien o no satisfacen las necesidades de los usuarios, existe el riesgo de distanciar a los empleados y a los ejecutivos. Evitando estos cinco errores, uno podrá asegurarse de estar en el camino correcto hacia una estrategia de aplicación exitosa.