DEV Community

loading...
Cover image for Técnicas de priorización (Parte 1)

Técnicas de priorización (Parte 1)

Othoniel Cazares
Agilista de corazón y Agile Rockstar de profesión
Updated on ・4 min read

Una parte fundamental en la gestión de proyectos ágiles es saber cómo priorizar las tareas que componen el proyecto, sabemos que existe constantemente la necesidad de utilizar metodologías para este fin por esa razón debemos conocer algunas técnicas que nos serán de utilidad a lo largo de la planeación de nuestro proyecto.

Un punto importante a considerar es a los stakeholder los cuales son los interesados en obtener valor del proyecto y en algunas ocasiones nos enfrentamos a la problemática en la cual los stakeholders no le dan la importancia que se debe a este punto o simplemente para ellos todo es prioritario, es nuestra obligación transmitir la importancia de priorizar las tareas para obtener el mayor beneficio aceptable en el menor tiempo posible.

En dado caso de que la responsabilidad recaiga mayormente en nosotros es fundamental utilizar alguna metodología de priorización, por lo tanto, a lo largo de estas semanas te estaré exponiendo algunas técnicas esenciales para esta tarea las cuales de seguro te serán valiosas en tu día a día.

MoSCoW

Esta semana iniciaremos con una de las técnicas mas populares en la industria y una de las dos que siempre debemos tener en cuenta como nuestras herramientas básicas a la hora de priorizar (La siguiente semana estaremos viendo la técnica RICE que es una de las dos fundamentales que debemos conocer).

MoSCoW se entiende básicamente como Must, Should, Could & Won’t que en español se entendería como Debo, Debería, Podría y No a lo que podemos asumir que tendremos tareas que debo estrictamente contemplarlas, tareas que debería contemplarlas pero no son contundentes para el optimo funcionamiento, tareas que podría incluir en el desarrollo pero no afecta el resultado si no las contemplamos y tareas que NO debemos contemplar por el momento en el desarrollo.

Ahora de nada sirve saber como catalogar las tareas si no entendemos realmente que tareas son totalmente relevantes y cuales no. Una manera de determinar que tareas se consideraran relevantes en el desarrollo próximo es hacernos las siguientes preguntas:

¿Mi proyecto puede funcionar sin determinada tarea?
¿Esta tarea agrega valor al proyecto?
En base a estas dos preguntas podemos determinar si es una tarea que “Debo” (Must) realizar. Supongamos que la tarea es primordial para el funcionamiento y agrega gran valor al proyecto, entonces definitivamente estamos hablando de un “Must”. En otro ejemplo supongamos que una tarea su funcionamiento es primordial para el proyecto, pero NO agrega valor al mismo estaremos hablando de una tarea “Should” ya que deberíamos trabajar en ella para continuar con el proyecto aunque NO nos aporte valor.

Ahora para determinar las tareas que seria un “Could” o que podríamos trabajar en ella tenemos que tener en cuenta las circunstancias, es decir, dependiendo de lo que queramos lograr es cuando podríamos echar mano de estas tareas, por ejemplo: Si tenemos una entrega para un MVP y queremos cautivar a nuestros stakeholders podríamos tomar en cuenta algunas tareas de esta sección ya que no aportan valor final a los stakeholders y no son funcionalidades criticas del sistema pero si logramos cautivar con alguna funcionalidad extra nos podría dar la continuidad que estamos buscando o algún otro beneficio que se esté planteando logra, otro ejemplo sería una mediación en este caso con el cliente a fin de un beneficio mutuo, es decir, si el cliente desea tener una funcionalidad que no es relevante pero nosotros podríamos dedicarle tiempo para logra alguna autorización de otro desarrollo o algún beneficio monetario entonces estaríamos considerando estas tareas como parte del desarrollo para lograr un fin.

Ahora las tareas que cataloguemos como “Wont” no quiere decir que son funcionalidades que vamos a deshacernos de ellas simplemente no son necesarias de momento ya que posiblemente no agregan valor al negocio en ese momento predeterminado, puede que en los meses venideros cobre valor y sea catalogada de nuevo como también existe la posibilidad de que el proyecto haya tomado un giro distinto y ya no sean requeridas algunas de estas tareas, esto solo el tiempo y la evolución del proyecto marcaran la pauta a seguir.

En conclusión esta técnica de priorización es muy efectiva para poner orden en el proyecto ya que se enfoca en las propiedades cualitativas de las tareas por lo cual la hace ideal para realizar una priorización inicial y con ello llevar un orden que permita iniciar el trabajo de manera adecuada, en nuestro próximo articulo hablaremos un poco de métodos de priorización enfocados en la reducción de costos los cuales nos ayudaran no solamente priorizar en base al valor y funcionalidad sino también nos permiten agregar valor a la gestión del proyecto.

IG:@agile.rockstar
FB:@AgileRockstar
TW:@ocazares

Discussion (0)