Lo prioritario es Priorizar.

14:33:00 Miquel A. Mora 6 Comments



Hace unos días mi hijo, de 6 años escogía los regalos de reyes de un catalogo de regalos.
Marcaba con un circulo los regalos que el  quería. Este.. Huy este también... Este.... Sobre todo este.... y este...
TODOS los regalos de niño estaban seleccionados. Esto a quien tenga el placer de tratar con "esos locos bajitos" seguro que le suena.
Le comente a mi hijo la necesidad de macar solo los más importantes para él, que los reyes solo eran tres (recursos limitados) y tenían que repartir los regalos de todos los niños en una sola noche (tiempo limitado). No podrían entregar TODOS los regalos, solo los verdaderamente importantes. Después de asegurarme de que lo había entendido, le di un rotulador fluorescente "rosita" y le dije que marcara solo los regalos importantes.
En dos minutos tenia TODOS los regalos para niños marcados (de nuevo)

Y no se por que extraña razón me acorde de algún Product Owner priorizando su product backlog (...)
Me viene a la cabeza algún tablero de Kanban con todas las tareas agrupadas incluso apiladas unas sobre otras en la parte superior de la columna "Pendiente". Le dijeron al product que pusiera arriba las tareas prioritarias... Y no es un caso aislado.
El pasado mes de noviembre, Pau Cervera de teoce consultores, en su conferencia sobre Critical Chain Project Mangement, comentaba su experiencia con un Product Manager, que pidió algún método para marcar las tareas prioritarias. Pongamos un pequeño adhesivo rojo, acordaron. En pocos días la practica totalidad de tareas estaba marcada con el adhesivo rojo.

Técnicas de priorizacion

Sabemos de la importancia de priorizar efectivamente, de reconocer lo que es verdaderamente prioritario en cada momento, de distinguir entre urgente e importante.
No es tarea trivial. Utilizar alguna técnica de priorizacion, puede traer orden a este caos de demanda ilimitada, recursos limitados y tiempo siempre escaso.
Existen muchísimas técnicas de priorización o herramientas, Paired Comparison Analysis, Análisis de Pareto, The Action Priority Matrix, Cost-Value Approach. Algunas técnicas de priorizacion especificas para proyectos de desarrollo según BABOK (Business Analysis Body of Knowledge) son MoSCoW Analysis, Timeboxing/Budgeting, Voting y Decision Analysis and Risk Analysis...
Siendo una de las más interesantes el MoSCoW Analysis
Este sistema nos permite priorizar funcionalidades según la importancia real de cada requerimiento, se detectan qué funcionalidades son imprescindibles para el éxito del proyecto o como afectaría al proyecto la no inclusión de algunas funcionalidades.
MoSCoW define las funcionalidades como
Must have (Imprescindibles)
Should have (Importante, pero no critica)
Could have (Podrian incluirse)
Won’t have (para más adelante)

Priorizando Agilmente
Los que practicamos entornos de desarrollo ágiles, tenemos un sistema de priorizacion esta muy claro. El primer principo Agil expone:
Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y contínua de software con valor
Entregar primero lo que retorne mayor valor de negocio.
-El Product Owner es el encargado de priorizar el Product Backlog.
-Se prioriza el Product Backlog según valor de negocio. 

Priorizar por ROI
Siguiendo esta máxima, y desde un punto de vista exclusivamente financiero, podríamos priorizar según Retorno de la inversión, ROI.
A mayor retorno, mayor prioridad. Bien ¡Ya lo tenemos! hagamos una previsión de ROI para cada historia de usuario, y asignemos mayor Valor de negocio, a mayor ROI y ya esta.
Pero no, no es tan sencillo. Este modelo presenta varios problemas de difícil solución.
En primer lugar el ROI es solo una estimación futura. Se basa en un coste de desarrollo, que mas o menos se puede estimar, pero si estimamos Temas o Epics (poco detalle, mucha incertidumbre), el margen de error puede ser grande. Y se basa en una predicción de beneficio, y obtener esta previsión de beneficio o ingresos realista y fiable, es dificilísimo, especialmente si tratamos funcionalidades o novedades que todavía no existen en el mercado.
En segundo lugar, no es posible comparar eficazmente el ROI de una funcionalidad que dará un beneficio económico, con el ROI de otra funcionalidad que nos dará una ventaja competitiva u otra que nos permitirá fidelizar a nuestros usuarios.
Por último, el ROI puede no ir siempre alineado con la estrategia de la empresa. Podemos tener otros objetivos o prioridades inmediatas diferentes a maximizar el ROI en nuestros proyectos (internacionalización, cuota mercado, branding...).

Tecnicas de priorizacion Agiles
Aquí es donde llega Mike Cohn a rescate, con sus técnicas de priorización para entornos Agiles "Agile Estimating and Planning (2006)".


En “Prioritizing Your Product Backlog” (Scrumalliance), Cohn exponía 4 interensatisimas soluciones para priorizar el Product Backlog en SCRUM; Relative weighting, Theme screening, Theme scoring y Kano Analysis. Ademas en su web de Mountain Goat Software existen herramientas gratuitas para utilizar dichas técnicas.
Mi preferencia sin duda es el metodo de priorización basadio en el Modelo Kano. Me gustaria explicarlo ampliamente en otra entrada exlusiva (creo que realmente se la merece)
Otra de las técnicas que he descubierto recientemente, en el libro Agile software Requirements de Dean Leffingwell, y que me ha llamado la atención es priorizar según Cost of Delay, Coste del retraso. En su blog, Dean explica detalladamente esta técnica, donde se pondera la prioridad para las tareas según variables como el valor que el usuario otorga a la funcionalidad, el valor de oportunidad de mercado o el esfuerzo del desarrollo. De manera que conseguimos el objetivo de priorizar según el mayor valor de negocio, las tareas "criticas" o con mayor coste de retraso primero.


Podemos escoger la técnica o método que mejor se adapte a nuestras necesidades, cualquiera nos ayudara a cambiar de paradigma, y es que NO TODAS las funcionalidades son prioritarias, SOLO las que son realmente IMPORTANTES.

Articulos similares
Tercera parte "Mejorando el Modelo Kano"

You Might Also Like

6 comentarios:

  1. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  2. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  3. The SBOK guide of scrumstudy.com will give you a clear understanding of how to run effective daily standup meetings. It also provides you detailed information on Agile Project Management methodologies suchas planning/review/retrospective meeting, and how to take advantages of related tools and so on.

    ResponderEliminar
  4. I would say that a PMP Certification is highly respected within both IT & non-IT communities where strong project management skills are required. If you plan on a long term career as a project manager, then yes, even with your level of experience, I would suggest getting your PMP. You can prepare yourself for the exam in one of the PMP trainingproviders like www.pmstudy.com/. You can do minimal prep-work to get 40 PMI® Contact Hours and apply to PMI for PMP Exam before the class begins.

    ResponderEliminar
  5. It will definitely ease your work of handling a big project. As a project manager I use scrum in my projects. One of my friends referred me to use the Guide to Scrum Body of Knowledge by http://www.scrumstudy.com. I like the concepts of sprints, daily standup meetings, etc. the SBOK Helped me alot in Understanding how Agile Project Management works.

    ResponderEliminar
  6. Hi , I am pondering over attending any PMP prep course / PMP classes to get PMP credentials. What are your thoughts? Would that be worth the money spent professionally?

    ResponderEliminar