En estos últimos años me he dedicado precisamente a esto, a llevar funcionalidades del ERP a dispositivos móviles, y no me he llevado un batacazo… más bien han sido varios, en los cuales uno siempre intenta no volver a caer.
A la hora de acometer un proyecto de software móvil no te puedes centrar en lo meramente técnico, en que lenguaje utilizar, en que sistema operativo vas a basar tu desarrollo, en este tipo de proyectos tendemos a olvidarnos del factor humano, (si, esos seres bípedos que resultan ser los usuarios finales), por otro lado tenemos que tener encuentra que dispositivo se adecua más a su modo de trabajo y sobre todo a su entorno, en este post espero resumir lo más posible todos estos pequeños factores en lo que he querido llamar Decálogo de desarrollo móvil.
1º Un usuario no es un Geek 😉
Por mucho que nos empeñemos un usuario final de, por ejemplo, una aplicación de gestión de un matadero, no es precisamente un maquinitas, esto es importante a la hora de diseñar el interfaz de usuario, los nombres a utilizar y el TAMAÑO de los botones, en el caso de que el dispositivo a utilizar carezca de hardbuttons (ver el segundo mandamiento). Por lo tanto por mucho que nos empeñemos si creamos una aplicación difícil de manejar (con más de tres saltos de menú es sencillo que se pierdan) lo más probable es que el proyecto se alargue eternamente en el tiempo ya que los propios usuarios lo van a rechazar.
2º Dime que herramienta tienes y te diré como programarla.
Supongo que esto es mundialmente conocido pero es importante elegir el dispositivo antes de empezar a plantearse tirar una sola línea de código. Si vamos a trabajar en un entorno industrial es lógico (sentido común o como queráis llamarlo) que orientemos a nuestro cliente a elegir un dispositivo de este tipo, por ejemplo de Motorola/Symbol, Psion, Intermec, Datalogic… Es importante tener un conocimiento previo de estos equipos, suelen contar con sus propios SDKs de desarrollo (los cuales es muy importante a la hora de reducir tiempo de desarrollo y el famoso ciclo de reinventar la rueda)
El dispositivo depende del entorno (no quiero imaginarme una flamante Diamond como herramienta de trabajo en una cámara frigorífica), de la finalidad del programa (tampoco visualizo a un elegante comercial ataviado con un equipo industrial de medio kilo) así que ante la duda lo mejor es ponerse en contacto con los comerciales de alguna de las casas y en la mayoría de los casos tan solo es necesario aplicar como he dicho el sentido común.
También es importante destacar las características técnicas del dispositivo, si esta escaso de recursos deberíamos olvidarnos de programar con Compact Framework y optar por algo más «compacto» como c++
3º Dejar que los usuarios (FINALES) se acerquen a mi
Esta muy bien escuchar las ideas de los administrativos, gerentes, jefes de producción y del personal técnico de la empresa…. ¿Pero quién va a utilizar la aplicación? quien va a tener que estar día a día trabajando con lo que nosotros pobres artistas del software creemos, está claro, aquí aplicamos la solución al primer punto de este decálogo, es importante reunirse con al menos alguno de los usuarios finales del programa, lo más lógico no siempre es acudir al mas «avispado» sino al que mejor se lleve con los compañeros… (si lo se… suena un poco manipulador, pero no es lo que pensáis) la idea de formar, enseñar y co-diseñar (sí, he dicho co-diseñar) al que más trato tenga, es que esa persona os ahorrará horas de trabajo tras la puesta en marcha.
La idea es involucrar al usuario final en el diseño de la aplicación, este después podrá explicar el mismo a sus compañeros el uso de la misma, y por supuesto explicarte a ti de donde cojea la aplicación… Pero CUIDADO, que no se convierta en una carta a los reyes magos!!!
4º Un anillo para dominarlos a todos… Simplificando las comunicaciones
El tema de las comunicaciones siempre es peliagudo, aunque en los últimos tiempos esto ha mejorado considerablemente, así que solo cabe decir aquí que es importante (siempre que sea posible) utilizar un UNICO sistema de comunicación, no hablo de si utilizar WIFI, GPRS, UMTS ect. Sino del sistema, WebServices, Replicación SQL, MSMQ, o transferencia de archivos de texto… insisto en que solo siempre que sea posible, ya que es de cajón de que cuantos más métodos incluyamos más complicado será escalar nuestra aplicación, mantenerla y detectar los posibles errores, que en la parte de comunicaciones suelen aparecer con más frecuencia de la que nos gustaría. Lo ideal es establecer simpre que nos sea posible un unico canal y establacer las interpretaciones en las entradas y las salidas de datos.
Nuestros usuarios agradecerán no tener que realizar complicadas configuraciones.
5º Planifica bien tu proyecto
Si alargamos demasiado el desarrollo de nuestra aplicación corremos el riesgo de que para cuando la terminemos ya estemos utilizando tecnología obsoleta…. (si, algunos ya sabréis que no es tan raro) un desarrollo de una aplicación móvil comercial no deberíais alagarla más de 3-4 meses (por supuesto esto depende del proyecto a acometer y es solo una media, del tiempo real, que mi equipo y yo hemos dedicado, por supuesto en estos meses no se incluye el tiempo de segundas fases y ampliaciones, sino al tiempo de tener lista la primera release puesta en el cliente)
La reducción de los tiempos en este tipo de proyecto evitan el cansancio del equipo de desarrollo, y evitan «la dispersión mental» y el perder del norte el objetivo.
Nuestros clientes no se desesperaran al ver que pasan las semanas y siguen sin tener nada, si el proyecto es muy largo desde que hablamos con ellos a la presentación del mismo no recordarán nada de lo que te contaron.
6º Se hace camino al andar… pero si ya lo han andado otros pa’ que
Aprovecha las funcionalidades del SO, dedica algún tiempo (se puede vivir durmiendo 5 horas) a estudiar las funcionalidades que te ofrecen los SDK del sistema operativo a utilizar. En alguna ocasión me he encontrado con desarrollos muy originales…. sobre algo que ya estaba resuelto en una nueva versión del Compact Framework, o desarrollos de Windows Mobile 5 muy currados pero que luego corrían sobre Windows Mobile 6 y con funcionalidades ya resueltas en su SDK
7º Estar atento a las novedades y desarrollos de terceros.
Más de lo mismo que el punto 6… pero es que muchas veces está muy bien desarrollar tus propios componentes pero dependiendo del alcance del proyecto a veces es interesante ver que componentes ya existen y adquirirlos. El trabajo de los demás también debe ser valorado. Un claro ejemplo es OpenNetCF (aunque ya ha perdido un poco de su espiritú de código abierto que tanto exito les dió)
8º Crea manuales SENCILLOS
Si puedes hacer que el manual entre en un folio mejor que mejor, y esto incluyendo capturas de pantalla, el equipo de soporte te lo agradecerá, y será más fácil que los usuarios finales «al menos» le echen un ojo.
Si no es posible reducirlo tanto, siempre está bien crear una hoja de guía rápida en la primera página de tal modo que puedan utilizarla de chuleta.
9º Valora a tu equipo
Insistiendo en el valor humano, si los desarrolladores no comprenden la aplicación difícilmente podrán darse cuenta de los «agujeros» con los que pueda contar la misma, es importante dedicar un tiempo a explicar el modo de trabajo actual de los usuarios finales, de este modo siempre nos podremos ahorrar el trabajo extra de corregir después errores (que suelen suponer replantear toda la aplicación…)
10º Aquí sois vosotros los que decidís este punto del factor humano en el desarrollo de un proyecto
¿Sugerencias?….
Un saludo a todos y perdonar por esta pequeña chapa, a veces me pongo a escribir y pierdo un poco el norte.
José Antonio Gallego
Yo también estuve metido en un tema de ERP para móviles en .NET y estoy de acuerdo punto por punto con lo que dices, aunque creo que la mayoría de los consejos son aplicables a cualquier proyecto de desarrollo.
Por desgracia no conozco mucha gente que tenga las ideas así de claras, así que me alegra especialmente leer tu artículo.