4 Reasons to prototype in mobile app projects

There are many situations when creating a prototype of the final product of a project is not possible, because of the costs, the timing or just because of the nature of the product. But if you have the chance I recommend you to do it.

Prototyping in software projects

Currently I manage projects whose goal is the creation of mobile apps for different kinds of clients. The product of our projects is a software and software by its nature allows prototyping and progressive development.

There are different kinds of prototype solutions for mobile apps. Frequently we use Marvel and Flinto. They both allow to create very high fidelity prototypes that can be tested in the intended devices as if they were the real app.

Why is this so interesting inside the project of creation of an app?

1. It is very frequent that the client (and/or the product owner) doesn’t know exactly how the final product should look like, exactly what kind of functionalities should it include and how should they be presented to the app user.
The prototype allows the client to rethink the product if necessary as the result of its interaction with the prototype.

2. It is a lot cheaper and faster to introduce changes in a prototype of this kind than in the final app (product).

3. Design is fundamental in a mobile app. This allows designers to go always at least 1 sprint ahead of developers during the project. If you can create a first project just for prototyping it will be even better.

4. As the designs are realistic, all the assets created for the prototype and approved by the client can be used by the developers during the following phases of the project without any additional work from the designers.

What is your opinion?

What do you think? Do you prototype in your projects? What kind of tools do you use? Do you know any more reasons in favor of prototyping? And against?
I would like to know your comments.

4 Reasons to prototype in mobile app projects

El factor humano en la gestión de riesgos / Human factor in risk management

(english version below)

Hace unos días asistí a la presentación de una herramienta de gestión de riesgos, aplicable a la gestión de proyectos pero también a otros ámbitos.

La herramienta, a partir de las estimaciones realizadas por el director de proyecto y su equipo de colaboradores, realiza un elevado número de simulaciones (configurable) siguiendo el método de Montecarlo.

Qué es la simulación de Montecarlo

La simulación de Montecarlo consiste en crear un modelo matemático del sistema a analizar, identificando aquellas entradas o variables del modelo cuyo comportamiento aleatorio determina el comportamiento global del sistema.

Una vez identificadas las mencionadas variables aleatorias, se procede a generar –mediante una aplicación informática- muestras aleatorias (valores específicos) para estas variables  y a analizar el comportamiento del sistema ante los resultados generados.

Repitiendo n veces este proceso, se obtienen n resultados sobre el comportamiento del sistema, permitiéndonos entender mejor el funcionamiento del mismo. A mayor número (n) de experimentos realizados, lógicamente, obtendremos más precisión en el análisis.

El Casino de Montecarlo dio nombre a la simulación
El Casino de Montecarlo dio nombre a la simulación

Foto de azugaldia bajo licencia CC BY 2.0

Cómo se aplica la simulación en la dirección de un proyecto

En nuestro caso, las variables de entrada al sistema serían, por ejemplo, las variaciones en el coste o en la duración de las actividades del proyecto en función de que se materialicen o no determinados riesgos. Como resultado, la aplicación proporciona, entre otros datos, una gráfica con las probabilidades de acabar el proyecto en determinada fecha o con un determinado coste.

Actualmente la tecnología nos puede ayudar mucho y, especialmente en proyectos de elevado coste y/o en los que no acabar en plazo pueda causar peligro para equipamientos o vidas humanas, este tipo de herramientas puede ser de gran ayuda.

El factor humano

Sin embargo, mi reflexión viene motivada porque toda la información de partida que utiliza la herramienta debe ser proporcionada por personas; la probabilidad y la estimación de impacto de que se materialice un determinado riesgo, la identificación exhaustiva de los riesgos que pueden afectar al proyecto, los criterios para definir la matriz de probabilidades e impactos … Si todo ésto no es acertado, todos los cálculos que muy afinadamente realicen las máquinas en base a esta información serán erróneos.

La experiencia del Director del Proyecto y de su equipo, su formación, la posibilidad de tener un equipo de proyectos multidisciplinar, que sea capaz de tener en cuenta todas las afectaciones e implicaciones del mismo, la posibilidad de disponer de una buena base corporativa de lecciones aprendidas de otros proyectos, el conocimiento de la organización en la que se desarrolla el proyecto y de su grado de aversión al riesgo…

¿Qué otros factores humanos consideras que pueden afectar a la gestión de riesgos de un proyecto? ¿utilizáis aplicaciones en vuestras organizaciones que os ayuden en este proceso?

—— ENGLISH VERSION —————

Some days ago I attended a presentation of a risk management tool, applicable to project management but also to other environments.

The tool performs a big number (configurable) of simulations based on the estimations made by the project manager and its team, according to the Montecarlo method.

What is Montecarlo simulation?

Montecarlo simulation consists on the creation of a mathematical model of the system to be analyzed and the identification of the inputs or variables whose random behavior determines the behavior of the whole system.

After that, random samples (specific values) are generated using an application. Those samples are used as inputs of the system and the outputs are used to analyze its global behavior.

Repeating n times this same process it is posible to obtain n results that allow to understand better the way it works. The bigger the number of samples the more precision in the analysis.

Montecarlo casino named the simulation
Montecarlo casino named the simulation

Photo from azugaldia under license CC BY 2.0

How can we apply this to project management?

In our environment, the input variables would be, for instance, the variances in cost or in the duration of project activities depending on some risks that might finally materialize or not. As a result, the application provides some graphics with the probabilities to finish a project in a specific date or with a specific cost.

Nowadays technology can help us a lot, specially in projects of high cost and / or in those projects where not finishing on time may risk infrastructures or even human lifes. In these situations these kind of tools can be very helpful.

The human factor

But the reason that has motivated me to write this post is the thinking that all the information needed by the tool must be previously provided by humans; the probability and the estimation of the impact in the case that an specific risk may finally happen, the exhaustive identification of the risks that may affect to a project, the criteria to define the probabilities and impacts matrix … If there are important mistakes or gaps in this data the later calculations made by the machines will be wrong.

The experience of the project manager and its team, their training, the chance to have a multidisciplinary project team, capable to have in mind all the potential risks and the ways they would affect the whole project, the possibility to have a good base of lessons learned available for the whole organization, the knowledge of the organization that is developing the project and its risk aversion, …

What other factors do you think that may affect a proper risk management in a project? Do you use applications in your organizations that support you in this process?

El factor humano en la gestión de riesgos / Human factor in risk management

Using a Blog to support your Project Management Information System

Last summer I started reading “Social Media for Project Managers”, from Elizabeth Harrin. There were many concepts I already knew and some tools I was already using but the book gave me some ideas to use those tools for new purposes. One of them was using a Blog as a part of the PMIS (Project Management Information System) as a project log.

Blog image from http://www.sxc.hu/profile/svilen001
Blog image from http://www.sxc.hu/profile/svilen001

How we use a blog in our project

We started using a blog in a software development project I am managing. The team is young and they are used to these kind of tools so it was not difficult to convince them to start blogging everyday their project activities.

As we all are not working at the same office and also some team members have different working hours, we thought that this tool would help us with its universal accessibility (well, in fact we have limited the access to the blog to the project stakeholders).

These have been the results

After some months of work we have:

  • A project log, explaining what we have done and why we have done it that way. A knowledge repository.
  • A tool useful to train new team members is they are needed in the future.
  • A tool to collaborate. We can receive feedback from the community of project stakeholders through their comments at the blog posts.
  • A tool to build relationships between the team members, as not all of them are collocated.

Some difficulties and risks

But not everything has been easy. We have had establish some ground rules about what to post and how. As every stakeholder may read a post it is not easy to decide the kind of information to include as not all of them have the same needs.

There are some posts that are for internal use (just for the team members), some others are for everybody involved in the project and we are working now in the weekly project status reports, for the project sponsor and the final product users.

As everybody can read every post, the tool we use to filter are tags. If you want to read a project status report you must look for “status” tags in the blog. When a team member looks for some information about the data base he must use some of the tags we have previously agreed to use for these issues, and so on.

What’s your opinion?

What about you, are you using any social media tool to support your projects? What has been the most difficult challenge you have faced to deploy it? What have been the benefits for the project? Any negative result?

Using a Blog to support your Project Management Information System

Planificando la transición a IPv6

Tengo que reconocer que había subestimado las implicaciones de la inminente transición de IPv4 a IPv6. El pasado jueves (19/01/2012) tuve el privilegio de asistir a una jornada formativa sobre la transición a IPv6 de la mano de un reconocido experto mundial como Jordi Palet y mis impresiones previas sobre este asunto han cambiado por completo.

En este blog hablo exclusivamente de cuestiones profesionales por lo que voy a limitarme a analizar las implicaciones que este proceso de transición tiene en un entorno empresarial, dejando de lado las afectaciones a los usuarios domésticos.

El cambio es necesario y no negociable

No es una cuestión de decidir si me cambio o no a IPv6. Si no hacemos nada a nivel de empresa y seguimos trabajando con IPv4, en los próximos meses nos podemos encontrar con varios efectos:

1. Podemos empezar a tener problemas para acceder a determinadas páginas web. Por ejemplo, si tenemos proveedores en China podría darse el caso de que no pudiéramos acceder a sus páginas web. En la región de Asia Pacífico ya se han quedado sin direcciones IPv4. Eso significa que cuando un nuevo usuario de esa zona del mundo vaya a su ISP y le pida nuevas direcciones públicas éste le va a decir que ya no puede dárselas en IPv4. Este nuevo usuario podrá optar por implementar sus servicios con IPv6 (en China ya llevan años haciéndolo) o trabajar con IPv4 pero no con una dirección IP pública sino privada (asignada por el ISP y compartida con otros usuarios mediante NAT).

La consecuencia para mi es que si este usuario chino decide montar su portal web en IPv6 puede que yo no sea capaz de llegar hasta su portal (estamos suponiendo que nosotros nos quedamos en IPv4) o que si opta por trabajar con IPv4 bajo NAT determinados servicios y/o partes de su portal web no sean accesibles para mi (es bastante complejo desarrollar aplicaciones web que funcionen a través de varios niveles de NAT).

2. Si la web corporativa de mi empresa sólo funciona con IPv4 no podrá ser accedida por usuarios que trabajen exclusivamente con IPv6 (como ya empieza a pasar en algunas regiones del mundo). Las aplicaciones de mi organización, como por ejemplo el portal web corporativo, deben ser capaces de funcionar con una doble pila IPv4-IPv6 si quiero que sigan manteniendo su funcionalidad actual.

3. El próximo 6 de junio de 2012 los grandes proveedores de contenidos de internet (Google, Facebook, Yahoo, Microsoft Bing…) activarán de forma definitiva y permanente IPv6.

Ese es un primer paso que pretende forzar a los ISP a la transición a IPv6 y que antecederá al despliegue de nuevos servicios basados en las nuevas características de IPv6 de las que carece IPv4.

Eso significa que si no hago cambios y sigo en IPv4 no podré acceder a esos nuevos servicios.

Quiero que uses IPv6
Fotografía cortesía de Blacknight (CC BY 2.0)

Necesito un plan

Como consecuencia de lo expuesto en el apartado anterior, aunque sólo sea para seguir manteniendo los servicios actuales, necesitaremos elaborar un plan (un proyecto en sí mismo en el caso de organizaciones de cierto tamaño) para organizar la transición.

¿Qué elementos deberemos tener en cuenta? Siguiendo las recomendaciones de Jordi Palet, será conveniente que nuestro plan incluya los siguientes puntos:

1. Formar en IPv6 al departamento TIC.

2. Hacer un nuevo plan de direccionamiento IP.

Y no sirve intentar traspasar lo que hay en IPv4 de forma análoga a IPv6. Eso sería un error porque los cambios en el nuevo protocolo nos llevan a una nueva estrategia de direccionamiento de partida. Es muy recomendable utilizar un plan de direccionamiento NO contiguo (que puede ser gestionado por un dispositivo IPAM) y que nos permite aprovechar las nuevas prestaciones de IPv6 y dificultar ataques de escaneo de puertos

3. Obtener direcciones IPv6.

En el caso de una empresa que trabaje con varios ISP aquí hay una novedad. Hay que gestionar la obtención de las nuevas direcciones globales con RIPE NCC directamente (en el caso de Europa y Oriente Próximo y parte de Asia Central). Es lo que se llama direccionamiento IPv6 Independiente del Proveedor o “portable” y se regula mediante lo que se conoce como “contrato de usuario final”.

RIPE NCC nos va a entregar direciones IPv6 de tipo /48, por defecto. Si sólo trabajamos con un ISP y gestionamos la obtención de direccionamiento IPv6 con él deberemos exigirle ésto mismo.

4. Auditar la red.

Se trata de analizar si nuestro equipamiento actual (cortafuegos, balanceadores de carga, IDS, proxys, …) soporta IPv6.

5. Planificar actualizaciones y/o adquisiciones.

Aquí incluyo tanto aplicaciones (propias o ajenas) como sistemas operativos, firmware, o incluso certificados ssl.

Un punto importante es hacer las gestiones necesarias de forma que desde “ya” no se adquiera ningún nuevo equipamiento en la organización que no soporte IPv6.

Para empresas de gran tamaño todo este proyecto puede llevar tiempo y ser costoso. Parece, en ese caso, razonable abordarlo en 2 fases: primero asegurarme de que mis clientes y proveedores puedan acceder a mis servicios y aplicaciones y después conseguir que mis usuarios puedan acceder a internet con IPv6.

La estrategia de transición a IPv6 de mis ISP

¿Cómo nos afectará la estrategia de transición de nuestros proveedores de internet? Pues mucho. Los ISP españoles se van a quedar sin direcciones IPv4 a lo largo de los próximos meses (de hecho, Jordi Palet nos comentó que alguno de ellos ya las habría agotado) y han empezado a gestionar la solicitud de direcciones IPv6 a RIPE NCC.

Pero no van a dar soporte IPv6 de la noche a la mañana. Eso significa que utilizarán mecanismos de transición (generalmente basados en túneles) como NAT444 o Dual Stack Lite. Son mecanismos que, en general, trasladan el NAT del CPE a la propia red del operador, lo que se conoce como Carrier Grade-NAT (CGN).

Como consecuencia, las mismas direcciones ip son compartidas entre varios usuarios del ISP repartiendo el conjunto de puertos entre ellos (a razón de 2000 puertos por cliente). En este escenario muchas aplicaciones dejan de funcionar, no es posible hospedar servidores en “puertos conocidos” y es preciso utilizar complejos mecanismos como ALG para traspasar el NAT del ISP y lograr que algunas cosas funcionen.

Conclusiones

1. No podemos esperar más. Hay que planificar y ejecutar la transición a IPv6 en nuestras organizaciones.

2. Debemos informarnos detalladamente de los planes de transición de nuestros ISP para ver cómo nos van a afectar y decidir si nos conviene su estrategia o si será necesario un cambio de proveedor.

Para acabar esta entrada, os dejo un enlace hacia un buen libro introductorio a IPv6 que se puede descargar de forma gratuita; “IPv6 para todos“.

Planificando la transición a IPv6

Google Wallet, ¿el sistema definitivo de pago mediante el móvil?

¿El final de las tarjetas de plástico?

A principios de este año uno de los analistas más influyentes de este país en el mundo de las TIC ya lo anunciaba; se espera un avance importante en el ámbito del pago mediante el teléfono móvil durante 2011. Mi interés por las tecnologías relacionadas con el comercio electrónico, incluyendo los medios de pago, me ha llevado a ir siguiendo las novedades que es están produciendo y las previsiones para el futuro.

En esta infografía que he encontrado en G+ se resume muy bien la evolución esperada de los medios de pago por móvil, los players más importantes a nivel internacional y el funcionamiento de la tecnología NFC.

Lo cierto es que el reciente anuncio del estreno de Google Wallet ha puesto este asunto en todos los medios. Tras la experiencia del fracaso de la iniciativa Mobipay en España es posible que se necesite el impulso de alguien como Google para implantar un sistema de este tipo a nivel mundial.

Requerimientos de un sistema de pago

De un sistema de pago, electrónico o no, se debe esperar que tenga las siguientes propiedades:

  • Reconocimiento, por una comunidad lo suficientemente grande (masa crítica)
  • Apoyo, por parte de las principales entidades bancarias, estados, agentes económicos, etc.
  • Versatilidad, para adaptarse a distintos tipos de pagos (de importe pequeño y mediano)
  • Facilidad de uso, para que sea accesible al máximo número de usuarios potenciales
  • Facilidad de implantación, basándose en elementos que el usuario ya conoce o de los que dispone (como el teléfono móvil o la tarjeta de crédito)
  • Seguridad, que le haga resistente a los ataques informáticos

Dos propiedades deseables adicionalmente serían:

  • Grado de anonimato, que permite al comprador
  • Lincabilidad de los pagos, que permite relacionar los diferentes pagos realizados por un mismo comprador aunque éste sea anónimo.

Google Wallet puede llegar a cumplir con todas estas propiedades, pero todavía es pronto para saber si lo logrará. En este vídeo podemos comprobar su facilidad de uso:

Conclusiones

Creo que para que un sistema de este tipo triunfe es necesario que no esté ligado ni a un sistema operativo, ni a una tecnología de pago concreta, ni a un terminal o familia de terminales específico. Cuanto más abierto sea mucho mejor para que sea ampliamente reconocido y utilizado.

Google Wallet funciona por el momento en el terminal Nexus S, con sistema operativo Android, utilizando la tecnología de MasterCard, con tarjetas de Citi o prepago de la propia Google y en la red del operador norteamericano Sprint.

Parece ser que Google está abierto a que Wallet pueda funcionar con otros sistemas operativos. En este sentido, que otros players como Apple puedan estar pensando en incorporar el pago por móvil en sus nuevos dispositivos sería positivo, siempre que su tecnología sea compatible con la de Google. Sin embargo, la utilización de paypass deja fuera, por el momento, a un actor importante de los medios de pago como Visa.

Finalmente, no estaría mal que las operadoras de telecomunicaciones de nuestro país, tras el cierre de Mobipay, y la irrupción en el negocio de Google, se pusieran las pilas si no quieren verse nuevamente en poco tiempo quejándose del negocio que otros hacen con los contenidos que ellas se limitan a transmitir a través de su red.

Tal vez estoy pidiendo demasiado, ¿o no?

Google Wallet, ¿el sistema definitivo de pago mediante el móvil?