archivo

Archivos diarios: agosto 18, 2013

El responsable funcional siempre va a querer incrementar el valor del producto que se está desarrollando y/o con el que está trabajando, para ello lo evolucionará buscando incrementar la eficiencia y productividad en su utilización y para ello modificará funcionalidades ya implementadas, eliminará algunas que no tengan utilidad o desarrollará otras nuevas.

Ese incremento del valor será consecuencia de una inversión y tendrá como objetivo obtener un retorno de la misma traducido como una reducción de costes y/o una ventaja competitiva con respecto a la competencia.

No hay que esperar a tener una versión más o menos estable del producto, el responsable funcional conforme vaya viendo y trabajando con versiones del mismo, ya sea en producción (preferentemente) o en un entorno de demo, buscará incrementar ese valor (lo hará incluso cuando trabaje con prototipos de pantallas en la definición de una historia de usuario), por lo que los requisitos, las especificaciones, las mismas historias de usuario, siempre deben estar abiertos a una modificación y esa será la realidad con la que nos encontremos en cualquier sistema de información, hasta que termine su ciclo de vida.

Sobre esto, Roy Miller realizó la siguiente reflexión: “Los requisitos son una conversación que nunca termina”.

Decía Platón que: “Una buena decisión está basada en el conocimiento y no en los números”.

Yo soy de la opinión de que son complementarias y en muchos casos se necesitan mutuamente porque en determinadas decisiones tendremos más posibilidades de acertar si tenemos una base objetiva que permita reforzar o descartar una determinada teoría que surge desde nuestro conocimiento.

¿Por que no complementar nuestro conocimiento con esas mediciones si se encuentra dentro de nuestras posibilidades obtenerlas? No hacerlo es como querer jugar con desventaja.

Es cierto que los números no significan gran cosa si no se sabe cómo analizarlos dentro del contexto en el que estamos trabajando y no se conoce cómo se han obtenido (no se sabe qué fórmula o qué procedimiento ha dado lugar a esos valores o no se verifica cómo se recogen los datos de partida).

A veces nos encontramos con sistemas de información donde vemos de manera clara que hay que realizar modificaciones sensibles en su arquitectura y diseño porque de lo contrario no se van a poder resolver los problemas de base que tiene el producto.

Las estrategias utilizadas pueden ser variopintas, si bien todos los caminos no están abiertos, ya que hay una restricción muy importante a tener en cuenta que no es otra que el presupuesto con el que contamos.

Una posible estrategia puede ser la de desarrollar el producto de nuevo. Es la más limpia, pero para poder aplicarla es necesario que el sistema anterior realmente se haya desechado y no lo utilice nadie o bien que si se utiliza tengamos presupuesto suficiente para desarrollar el nuevo sistema manteniendo el actual (todo eso evaluando el tiempo que sería necesario para realizar la sustitución de uno por otro, al menos en aquellas funcionalidades que se consideren esenciales).

Si no se dan esas condiciones (puede que sea la que quisiéramos aplicar pero por mucho que hayamos solicitado fondos no se han conseguido), toca trabajar sobre lo que hay.

No se debe caer en la precipitación y querer cambiar de golpe partes importantes del sistema porque probablemente estaremos apostando todo a una sola carta. Lo mejor es que el cambio sea gradual, persiguiendo el objetivo que tenemos pensado (en consenso con los usuarios) porque será más fácil hacerlo dando saltos cortos, ya que de esta forma analizamos de manera más objetiva el siguiente paso que debemos dar y tendremos recursos económicos para atender otras necesidades que requiera el sistema.