Nuevos tipos de contenedores en radMaker

Hemos creado dos nuevos tipos de contenedores: MAP y SIMPLE que amplían las funcionalidades de las aplicaciones creadas con radMaker.

El contenedor MAP nos permite mostrar un mapa en nuestra aplicación y posicionarnos en él a partir de las coordenadas que se recuperan de un FileData.  Para su implementación se ha utilizando el API de Google Maps.

mapa

El contenedor SIMPLE es un contenedor que nos permite definir una zona de un componente donde podemos insertar información procedente de cualquier origen. Resulta de utilidad para visualizar información procedente de APIs de otras aplicaciones.

Dejar un comentario

Mejoras a nivel de contenedores Tree

Hemos estado trabajando para mejorar el comportamiento de los contendores Tree.

Hemos introducido un nueva característica en los controles de tipo Tree que es que además del texto se pueda introducir un icono a la izquierda del mismo. Con esta mejora este tipo de contenedores mejoran su aspecto visual

Un ejemplo del cambio de aspecto lo podemos ver en las siguientes imágenes:

Antes:

arbol_antes

Despues:

arbol_ahora

Hasta ahora era posible insertar un evento click para todo el contenedor Tree, pero esto no es suficiente en algunos casos si no que es necesario que cada uno de los niveles del arbol cuente con sus propios eventos. Por ello, ahora además de poder insertar un evento click a nivel del contenedor Tree, es posible definir eventos click para cada uno de los contenedor Level con los que cuenta el contenedor principal.

Comentarios (1)

Gestionando los requisitos de un proyecto

Unas de las primeras fases de cualquier proyecto es la definición de los requisitos. ¿Para qué sirve esta fase? El objetivo es sencillo, definir el alcance del proyecto.

Si consideramos el proyecto como un viaje, los requisitos tienen que definir el destino del viaje y los puntos principales por donde vamos a viajar. Siguiendo con el símil, difícilmente llegaremos a donde queremos ir si no definimos ni donde queremos ir ni una ruta mínima.

Los requisitos  pueden ser una fuente de problemas por no darles la importancia necesaria y en ocasiones se realiza de una forma muy ligera o incluso se salta esta fase.

¿Por qué es importante esta fase? Porque todo proyecto tiene unos costes, ya sean económicos o simplemente de tiempo. Pero aun sobrándonos el dinero y el tiempo, necesitamos saber donde vamos, que deseamos hacer y hasta donde queremos llegar.

Hay un ejemplo clásico de una mala definición de requisitos que fue la primera versión de Word para Windows. En su primera versión, el procesador de texto solo tenía un requisito: ser el mejor procesador de textos del momento. En aquella época, era WordPerfect quien lideraba el procesamiento de textos y Bill Gates actuó como jefe de proyecto con este único objetivo. Se consumieron recursos y tiempo, se sacó al mercado pero el producto no tuvo el éxito esperado, a un coste quizás excesivo. Posteriormente, con la definición de requisitos más claros, Microsoft si fue capaz de crear el mejor procesador de texto.

Otro error habitual en los desarrollos a medida, es no hacer la fase de requisitos porque “solo se trata de un cambio mínimo”. Siempre es difícil precisar que significa “un cambio mínimo”, pero un problema que tiene este tipo de actuaciones es que se pierde la trazabilidad de los cambios que se introducen en las aplicaciones. Un cambio mínimo puede ser cambiar un literal, es un cambio sencillo rápido y sin muchas implicaciones, casi siempre, porque qué ocurre si al equipo de desarrollo le llega el cambio directamente por un correo, se implementa pero cuando llega a producción otra persona de la empresa cliente piensa que no había que haber cambiado el literal. Normalmente la empresa que desarrolla tiene que buscar el correo donde se le indicaba el cambio remitirlo, que el cliente se ponga de acuerdo y si no es el literal correcto, volver a dejar el literal anterior. Todo esto supone un consumo de tiempo y dinero. Si las entradas llegan a la empresa de desarrollo a través de requisitos y si esos requisitos tienen que ser validados por el cliente antes del envío, estos problemas se evitan. Por supuesto, esto se consigue con una fase previa a lo que sería el inicio del proyecto que es establecer un marco de comunicación entre ambas partes de cara a afrontar el proyecto.

Incluso cuando el proyecto es un proyecto personal conviene definir qué requisitos queremos cubrir. Principalmente, porque definimos que queremos hacer y hasta donde queremos llegar. Sin eso, puede que le dediquemos mucho tiempo pero cuando alguien nos pregunte como vamos, digamos: “ya está casi”. Ese casi es demasiado ambiguo, porque el casi puede ser un día o dos meses, y ¿donde se origina esa indefinición? en que los requisitos no se encuentran bien definidos.

Dejar un comentario

Cosas a evitar

El uso de Internet para la comunicación con los clientes/usuarios no es un camino sencillo, aunque aparentemente ¡que mejor modo de comunicarse que a través de él!. Para realizar una buena comunicación puede haber muchos factores, pero uno principal, querer escuchar.

La comunicación en Internet puede ser desde un correo hasta una aplicación, pero lo mas importante es que se preste atención a lo que el cliente/usuario nos comunica.

En la práctica existen muchos casos en los que esto no funciona de esta forma, y sobre todo en la tramitación y recogida de incidencias:

  • Se ofrece como parte del servicio un soporte técnico 24×7, los clientes esperan que cuando tengan una queja se puedan comunicar y que su queja sea tramitada. Pero el servicio técnico está tan saturado que solo tramita tu petición a las 24 horas y al contestarles con alguna aclaración, vuelve a tardar otras 24 horas en dar respuesta.

Esto no es un servicio 24×7, es simplemente un correo o una aplicación disponible a todas horas, trabaja mas como un buzón de correo postal que como un servicio disponible en cualquier momento. Al final el cliente tiene la percepción de haber sido engañado.

  • Distintos sistemas de comunicación para resolver una incidencia. También es algo usual que uno tenga que comenzar a comunicarse con una compañia para un incidencia por un modo y seguir por otro. Por ejemplo, tienes que llamar para abrir la incidencia y luego sigues por correo. O bien, abres la incidencia con un correo pero si la incidencia no es habitual tienes que llamar a un 902.

Esto es algo que tampoco tiene mucho sentido. En el primer caso, porque si al final la incidencia se tramita por un correo, ¿por qué no empezarla por un correo? Se supone que de esta forma se hace un primer filtro o ayuda a las incidencias, pero en aquellos casos que se considere que esto es necesario se debería dar al cliente la posibilidad de elegir si quiere crear la incidencia por la web o por teléfono y no obligarle a hacerlo telefónicamente.

El segundo caso, es peor aún, porque abres la incidencia, te contestan pero si lo que les solicita no cumple ciertos criterios  te dicen que llames a un algun número de teléfono que encima te supone un coste, pero ¿quien se tiene que preocupar del servicio?  ¿quien debería llamar?

  • En algunos casos la gestión se hace con una web que te permite indicar las incidencias, en teoría este debería ser el mejor modo para la gestión de las mismas porque permite un registro de toda la información de forma centralizada.

El principal problema que puede surgir en una solución de este tipo es que esperan que el cliente/usuario haga parte del trabajo, por ejemplo teniendo que catalogar de una cierta forma la incidencia o teniendo que añadir gran cantidad de información.

En muchas ocasiones puede ser necesario una cierta catalogación de la incidencia a lo mejor simplemente indicando sobre que producto se desea crear la misma, pero en otros casos además se obliga a decir información que al usuario le resulta costoso saber o consultar. Esto se debería evitar para arrancar la incidencia, porque normalmente la companía que presta el servicio ya conoce el origen de donde pueden proceder las incidencias, algo que el cliente/usuario puede costarle un buen rato.

Al ofrecer un servicio hay que dar al cliente las máximas facilidades no intentar marearle o complicarle el uso de nuestro servicio. No es un problema técnico, no por hacer la aplicación mas grande se va a dar mejor servicio, simplemente se trata de escuchar al cliente y resolver los problemas que le surgen.

Comentarios (1)

Nuevos Tipos de Entradas

Cuando se aborda un proyecto hay distintas fases que varian dependiendo del proyecto en el cual uno se embarque. En radMaker trabajamos para crear la mejor herramienta para la creación de aplicaciones web, pero sabemos que por muy buena que sea la herramienta no es lo único importante.

Por ello vamos a empezar a tratar temas que no siendo propios de la creación de una web si estan ligados a ellos. Temas como la gestación de la idea, la comercialización, el servicio post-venta, etc…

Esperemos que estas entradas sean de vuestro agrado.

Comentarios (1)

Entradas más antiguas »