Desarrollo de software. Sprints, pasos a producción y concienciación

¿Qué funcionalidades mínimas tiene que tener el sistema para que tras su paso a producción empiece a utilizarse de manera efectiva? Variará en función de la aplicación, en algunos casos bastará con un porcentaje reducido del producto, en otros se requerirá prácticamente una versión completa del mismo.

En cualquier caso, mi apuesta sigue siendo la misma: iteraciones cortas y pasos a producción tras la misma, si bien, siempre debe mandar el contexto.

Si el sistema no tiene la funcionalidad mínima necesaria no se va a utilizar en producción, se realizarán pruebas si el usuario tiene voluntad pero no será sometido a todos los casos de uso que se pueden producir con su uso intensivo. Las consecuencias de esto es que el feedback pierde fuerza y determinados bugs no se detectarán hasta que el producto tenga una utilización real.

Ante esta situación es necesario concienciar al usuario de que su voluntad en hacer pruebas intensivas del sistema debe ser firme, debe apostar por el sistema, invirtiendo esfuerzo incluso en realizar casos de uso reales aunque después ese trabajo lo tengan que realizar en paralelo con el sistema o método que vinieran utilizando hasta ahora. Resulta muy complicado convencer al usuario entre otras cosas porque si tiene que elegir entre dar solución a problemas reales de su día a día o dar solución a problemas futuros de un sistema de información que está en desarrollo, elegirá lo primero y tampoco debe de extrañarnos porque nosotros generalmente hacemos lo mismo.

También es importante hacerle entender al usuario que cuanto antes empiece a utilizarse el sistema en producción será mucho mejor. Aquí la complejidad la tenemos en hacerle ver que no necesita que el producto esté terminado al 100% para eso, si bien, como decía antes además de la voluntad del usuario dependemos de las características del sistema.

Uno de los principales miedos que tiene el usuario es que tras la puesta en producción los desarrolladores se desentiendan del resto de funcionalidades que hay que desarrollar o incluso de la evolución y mejora de las ya construidas. Para contrarrestar esto es importante que le expliquemos muy bien la estrategia de desarrollo y sobre todo que confíen en nosotros, aún así no terminarán de ver muy claro el asunto hasta que tengamos varias iteraciones tras la puesta en marcha efectiva del sistema y cumplamos con los compromisos.

Anuncios
1 comentario
  1. Se tiene en mente que un producto equivocado es aquel que no cumple las especificaciones funcionales del área usuaria, sin embargo, podemos encontrarnos con aplicaciones que satisfaciendo eso son productos equivocados. ¿Qué cómo es posible eso? Pues todos esos sistemas que son inmanejables (mala experiencia de usuario y/o baja productividad de uso), que tienen infinidad de errores (o los suficientes para hacerlo insufrible)o que tienen otro tipo de deficiencias no funcionales relevantes.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: