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

Diseño de un SGC según ISO 9001

Ya he hablado en otras entradas de este blog de los principios y fases de un proceso de implantación de un sistema de gestión de la calidad (SGC) según ISO 9001. También de la primera fase; la planificación. Para continuar con el ciclo, voy a dedicar esta entrada al diseño del sistema. La D del ciclo PDCA.

Una vez realizado el diagnóstico de la situación, después de haber logrado el compromiso efectivo de la dirección y tras haber llevado a cabo una buena planificación debemos pasar a la acción. En mi opinión hay 4 ingredientes imprescindibles es esta segunda fase: información a todo el personal de la organización, formación en gestión de la calidad adaptada a las necesidades de cada grupo de empleados, desarrollo de la documentación del sistema e implantación de los diferentes procesos de la empresa en base a la documentación desarrollada. Vamos a ver cada uno de estos 4 puntos con más detalle.

Información

En cualquier proyecto, un Director de Proyectos pasa la mayor parte de su tiempo gestionando las comunicaciones del proyecto. En un proyecto de implantación de un SGC ésto también es así. En esta fase es fundamental informar a todos los miembros de la organización de:

  • lo que se pretende conseguir,
  • el nivel de implicación que se espera de ellos,
  • cómo les va afectar el proyecto.

La información proporcionada debe ser adaptada al puesto de cada persona en la organización y debe mostrar el compromiso de la organización con el proyecto.

Comunicación con todos los interesados en el proyecto
Comunicación con todos los interesados en el proyecto

Fotografía cortesía de Paul Shanks bajo licencia CC BY-NC 2.0

Formación

La formación debe tener como objeto sensibilizar sobre la calidad en el trabajo y mejorar la comprensión del sistema de gestión, para que todos los afectados puedan comprender los cambios que se van a producir y actuar de forma favorable (o al menos no contraria) a los mismos.

Al igual que la información, la formación deberá adaptarse al puesto y responsabilidades de cada miembro de la organización. Su contenido y duración dependerán del tamaño de la organización pero también de su nivel de madurez en relación a la calidad.

Documentación

Una de las bases de la calidad es la estandarización. Una herramienta fundamental para la estandarización es la documentación, que un vehículo para lograr que las tareas se realicen siempre de la misma forma.

La documentación debe ser redactada en la forma más simple y comprensible, debe describir la forma correcta la forma de realizar las tareas, debe incorporar todo el conocimiento acumulado de la organización, informando de responsabilidades y relacionando unos procesos con otros.

Conforme se vayan redactando procedimientos (que son los documentos que describen los diferentes procesos de la organización) es bueno empezar con su implantación. No obstante, es importante remarcar que lograr la implantación requiere de mucho más tiempo que el de la simple redacción de los procedimientos, especialmente si se parte de un bajo nivel de madurez en relación a la calidad en la organización.

Implantación

Conforme se finaliza la redacción de los documentos y se arranca su puesta en marcha es preciso realizar una serie de actividades con objeto de fijar los nuevos procesos y cambios introducidos:

  • empezar a realizar las tareas cotidianas según se describe en los procedimientos e instrucciones,
  • realizar un seguimiento y verificar de forma distendida el nivel de aplicación,
  • corregir los procedimientos en base al feedback obtenido en el seguimiento.

¿Qué opinas de este modelo de diseño? ¿qué elementos utilizáis en tu organización?¿consideras que hay algún ingrediente importante que falte?

Diseño de un SGC según ISO 9001