archivo

Archivo de la etiqueta: priorización

El método MoSCoW es una técnica de priorización de requisitos basada en el hecho de que aunque todos los requisitos se consideren importantes es fundamental destacar aquellos que permiten darle un mayor valor al sistema, lo que permite enfocar los trabajos de manera más eficiente.

Lo que la diferencia de otras técnicas tradicionales como por ejemplo calificar los requisitos como de prioridad alta, media o baja es que en este caso la escala utilizada tiene un significado intrínseco, de manera que el usuario responsable de asignar la prioridad conoce el efecto real que producirá su elección.

M (Must): Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un éxito.

S (Should): Requisito de alta prioridad que en la medida de lo posible debería ser incluido en la solución final, pero que llegado el momento y si fuera necesario, podría ser prescindible si hubiera alguna causa que lo justificara.

C (Could): Requisito deseable pero no necesario, se implementaría si hubiera posibilidades presupuestarias y temporales.

W (Won’t): Hace referencia a requisitos que están descartados de momento pero que en un futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorías anteriores.

Esta clasificación puede ser modificada durante el proceso de desarrollo y definirse, en el caso de desarrollos iterativos incrementales, prioridades a nivel de iteración.

Contar con presupuesto te permite el suficiente margen de maniobra para solucionar los posibles problemas que puede tener un sistema de información. Sin embargo, el dinero por sí mismo no arregla nada si las decisiones que se toman son incorrectas, si no se desarrolla con intención o no se resuelven los problemas que existen de raíz.

Puedes echar decenas y decenas de miles de euros a un sistema y no incrementar proporcionalmente su valor.

Este antipatrón surge cuando se cuenta con un importante presupuesto que bien utilizado podría mejorar el producto pero que en lugar de centrarse en los problemas existentes en el sistema, se invierte en un crecimiento desproporcionado y/o difícil de controlar del sistema que mezcla la resolución de esos problemas con una ampliación funcional generalmente de aspectos secundarios.

En esta situación se divide el enfoque y el presupuesto entre lo principal y lo accesorio poniendo ambos al mismo nivel, a la que vez que se dota de una mayor complejidad al sistema, generándose resistencias que afectan al directamente al esfuerzo (y coste) necesario para desarrollar. Por tanto, el presupuesto para arreglar los verdaderos problemas del sistema queda debilitado a la vez que la deuda técnica va creciendo y en consecuencia los costes de desarrollo.

Llegado a un extremo (y a veces no es necesario escorarse tanto) nos habremos “comido” el presupuesto y los problemas (o la mayoría de ellos) seguirán ahí, y lo que es todavía peor, con otros nuevos que posiblemente se han añadido, con un producto más complejo de evolucionar y con una confianza muy erosionada por parte del cliente o del área usuaria (independientemente de que ellos hayan tenido mucho o poco que ver en la priorización de las tareas y en la estrategia utilizada).

Si hay disponibilidad presupuestaria en el proyecto o en el futuro se quiere seguir invirtiendo en el mismo siempre tendremos la posibilidad de desarrollar nuevas funcionalidades o herramientas dentro del sistema o seguir sacando brillo a las ya existentes.

Eso tiene sentido si hay un producto que funciona. Si el producto no funciona como debiera, invertir esfuerzo en lo que no es importante deja sin arreglar lo realmente significativo dejándonos con menos presupuesto y con un sistema más grande que costará más dinero corregir y evolucionar.

Es necesario que el usuario tome decisiones sobre lo que considera más prioritario. A muchos les costará porque ese miedo que existe a tomar decisiones y equivocarse pero no hay más remedio hacerlo porque es un error que sea el desarrollador el que elija ya que el sistema es para el usuario y él es quien sabe lo que necesita (al principio del proyecto una idea más general y conforme vaya avanzando irá despejando las mismas).

Tanto usuarios en lo funcional como desarrolladores en lo técnico deben tener los pies en el suelo y no hacer castillos en el aire. Es necesario que lo fundamental funcione muy bien porque a partir de ahí se construye lo demás, si pensamos en lo no trascendente y dedicamos atención y esfuerzo a ello comprometeremos las posibilidades de éxito del proyecto.

¿Por qué la necesidad de la figura de un responsable funcional, de un Product Owner o de un Product Manager? Pues porque incluso teniendo la organización unos objetivos bien definidos, en diferentes departamentos se tendrán prioridades distintas en cada momento no necesariamente incompatibles con los objetivos de la organización.

Si la situación de partida es el de una organización sin objetivos definidos (entiéndase objetivos definidos si están por escrito y son conocidos por el conjunto de la organización) resulta más complicado todavía armonizar las tareas de los diferentes departamentos.

Ken Schwaber describe perfectamente esta situación en la siguiente reflexión: “Ventas y marketing quieren respuestas rápidas a cada oportunidad que llama a la puerta. Los desarrolladores necesitan centrarse en el desarrollo del producto. El caos en una empresa es a menudo causada por la incapacidad de resolver estos conflictos”.

Tomando como base ese ejemplo, cada departamento se centra en sus objetivos: ventas y marketing quieren conseguir ventajas competitivas, desarrollo llevar a cabo de manera adecuada el producto. ¿Cuándo se produce el conflicto? Cuando son varias las personas de ventas y marketing la que llaman a la puerta de desarrollo, para cada una de las cuales lo suyo es lo más urgente y prioritario.

Por ese motivo cada producto debe tener un responsable que establezca las prioridades en la evolución del mismo (haciendo las consultas pertinentes dentro de su departamento) y si existen varias líneas de producto y la capacidad del departamento de desarrollo no puede satisfacer todas las necesidades que se plantean, se necesita un responsable que priorice las actuaciones a realizar sobre el conjunto de productos.

La primera posibilidad que vamos a estudiar implica dejar muy claro a nivel contractual lo siguiente:

– Catálogo de objetivos y requisitos marco, debidamente priorizados por el cliente y con una valoración de esfuerzo realizada por el proveedor. Este catálogo de objetivos y requisitos, debe tener un nivel de detalle adecuado para poder ser evaluado de manera objetiva por el cliente y también para que pueda ser valorado por el proveedor.

Acertar con el nivel de detalle es importante, ya que no se pretende realizar un análisis en profundidad del sistema (de lo contrario estaríamos desarrollando en un híbrido entre la cascada y un enfoque iterativo incremental en la construcción), pero debe ser suficiente para que la valoración sea lo más acertada posible y para que no existan solapamientos entre requisitos o confusiones sobre su alcance real.

Es muy importante hacerle entender al cliente que resulta fundamental acertar con las prioridades, ya que permitirá obtener antes una versión del producto con sus aspectos más críticos ya implementados y tendrá margen de maniobra presupuestaria para poder hacer los ajustes que considere necesarios.

Lo anterior debe ser recordado al cliente durante todo el proceso de desarrollo.

Además se deberá presupuestar los costes de gestión por parte del proveedor al final de cada iteración: replanificación del proyecto en función de los cambios sobre el plan inicial o sobre el plan establecido hasta el momento, realización de un primer análisis y valoración de nuevos requisitos, revaloración de requisitos ya establecidos, etc…

Este catálogo de objetivos y requisitos, debe ser contratado aparte y antes de comenzar el proceso de desarrollo.

– Compromisos por parte del proveedor respecto a su participación en el proyecto: Esto podrá variar en función de la metodología utilizada, en algunos casos será suficiente su participación al principio de cada iteración (detallar los requisitos) y al final de la misma (evaluación de los resultados obtenidos y definición del alcance de la siguiente iteración), en otros casos requerirá que además de lo anterior, tengan participación dentro del propio equipo de desarrollo o tener un nivel de disponibilidad absoluto ante consultas o peticiones realizadas por los desarrolladores.

– Marco para el cambio del catálogo de objetivos y requisitos inicial y para la gestión de conflictos. Para reducir o evitar los conflictos es importante que quede claro y por escrito, cómo tratar las situaciones más comunes que se pueden producir en el proceso de desarrollo:

Cambio de prioridades. No tendría coste imputable al cliente.

Corrección de defectos. No tendría coste imputable al cliente.

Cambio de un requisito por otro nuevo, ampliación del alcance de un requisito ya existente y reajuste de un requisito ya implementado. Se tendría que evaluar el coste del cambio e intercambiarlo por requisitos todavía no implementados que tengan en suma un coste equivalente (sin pasarnos nunca del presupuesto restante para el proyecto).

Reducción del alcance de un requisito y eliminación de un requisito. Se generaría un “crédito” a favor del cliente que podría ser utilizado para los cambios indicados anteriormente.

Costes de gestión. Si los costes de gestión no superan el presupuesto establecido en cada iteración, pasarían a formar parte de ese “crédito” a favor del cliente. Si los superan y existe circunstancias motivadas para ello (cambios de enfoque en el proyecto, etc…) tendrá que compensarse el coste por créditos existentes o por requisitos.

Cumplimiento de plazos y de la calidad del producto. Siempre y cuando no existan circunstancias externas al proveedor, se debe garantizar por parte de éste un acuerdo de nivel de servicio que podría tener clausulas de penalización y también clausulas de excelencia.

También por el suelo… o en la papelera.

A este antipatrón se llega por la no asunción de sus responsabilidades por parte del área usuaria a la hora de definir las especificaciones del sistema, priorizar trabajos, responder dudas y realizar feedback.

Si se deja que el equipo de proyecto cubra los huecos en los requisitos el sistema solo cumplirá las expectativas del usuario por casualidad (es cierto que si se tiene en el equipo especialistas en el negocio se reduce el margen de error, pero no hay que olvidar que somos desarrolladores y nuestra visión es siempre de desarrollador, no de usuario).

Si el área usuaria no colabora tendremos una serie de requisitos (unos más completos que otros) y probablemente no exista una priorización de los mismos o la misma sea muy generalista, el efecto es como si tuviéramos una serie de requisitos en post-it esparcidos por una pared, sin orden ni concierto.

Cuando el área usuaria deja de colaborar o no lo hace de manera adecuada, hay que levantar la mano y escalar el problema a nivel directivo de los stakeholders ya que no se puede hacer un proyecto de espalda a los usuarios pese a que estos se la den al mismo.

Si no se pone remedio al final liberaremos un producto que rechazarán total o parcialmente los usuarios, que ahora sí, reclamarán aquel requisito que no se realizó, los que no se interpretaron de manera adecuada (algo que es tan malo como el propio hecho de que no harán feedback ni prestarán más atención que la simple advertencia de su no implementación, de aquellas funcionalidades no incorporadas en la versión liberada de la aplicación) y por qué se ha priorizado tal funcionalidad y no tal otra.

Por supuesto, no lo dudéis, todas las miradas se dirigirán a la parte más débil, el equipo de desarrollo.

Realizar primero aquellas funcionalidades más importantes para la aplicación y que sean más sencillas de implementar es lo que se denomina en el argot de la consultoría quick wins.

Para detectarlos Barry Boehm propone una estrategia simple, pero efectiva. Ante una funcionalidad solicitar al área usuaria que le asigne una prioridad de 1 a 10 (siendo 10 la mayor) y al equipo de desarrollo que le asigne un valor entre 1 y 10 en función de la complejidad del desarrollo (siendo un 10 la menor), ¿qué funcionalidad implementar primero? La que tenga un valor 10-10 (muy importante y sencilla de realizar) y así sucesivamente.