Buscar

Blog de Alfonso Tienda

Marketing, Startups, Proyectos y Tecnología.

Etiqueta

gestión de proyectos

Ingeniería de requerimientos: La priorización MoSCoW

Cuando se trabaja con requerimientos en gestión de proyectos software hay que tener muy en

Moscú - Krásnaya plóshchad’ (Plaza bonita, aunque se suele traducir como roja)  CC-A por Guyal
Moscú – Krásnaya plóshchad (Plaza bonita, aunque se suele traducir como roja) CC-A por Guyal

cuenta con quién hablamos: con el usuario. El usuario raramente pondrá requerimientos del 1 al 10, jugará a las cartas de estimación Scrum o usará complicadas Excel. Sin embargo, hay que enseñar al usuario a Priorizar.

La técnica que más me gusta para priorizar requerimientos (o requisitos… ya veremos si algún día hay acuerdo sobre la palabra a usar) es una técnica llamada MoSCoW.

En realidad, MoSCoW no hace referencia a la capital Rusa, ni es una técnica fundada en Moscú ni nada parecido. Realmente, la técnica fué creada por Dai Clegg mientras trabajaba en Oracle, en el Reino Unido. Es un acrónimo que hace referencia a:

  • Must haves (Debe tener…)– Requisitos fundamentales para el éxito del proyecto
  • Should haves (Debería tener…)– Importantes pero puede que no críticos para el éxito del proyecto
  • Could have (Pueden tener…)– Pueden ser eliminiados fácilmente sin dañar al proyecto
  • Won’t have (No tendrá… por el momento)– Pueden ser pospuestos. Son los requisitos que serían buenos, pero los dejamos para más tarde.

¿Qué significa cada prioridad de MoSCoW?

Los Must Have se pueden considerar aquellos sin los cuales no existe la funcionalidad. Una especie de MVP en Lean Startup. Si quitas alguno de ellos, el sistema carece de sentido. Por otra parte, los Should Have son muy importantes, pero el sistema funciona sin ellos. De hecho, se puede probar el software y el resto de las funcionalidades sin estos requerimientos. La funcionalidad básica está definida por los Must y los Should, pero se podría probar una primera versión sin los Should.

La anterior es la frontera más compleja, el resto de requerimientos los podemos entender. Son todos aquellos requerimientos que aportan valor a la solución pero no forman parte de la funcionalidad básica y del sentido de la aplicación. Estos requerimientos los dividiremos en dos grupos: los Could, que vendrían a ser los requerimientos que el director de proyecto podría sacrificar en el supuesto caso de que tuviese que hacerlo por limitaciones en tiempo o coste, y los Won’t, que son las grandes ideas que no entrarán en esta fase de proyecto y se dejarán en lo que en Scrum sería el backlog.

Trucos para aplicar MoSCoW

MoSCoW es una técnica diferente y tiene sus ventajas e inconvenientes. Por una parte, es fácil de entender para un usuario. Qué es lo básico y que no. Y dentro de cada grupo, por una parte, que es lo que da sentido al sistema y qué es básico y, por otra parte, cuales descartamos ya y qué requerimientos podrán ser descartados por razones de tiempo y coste. Hay que intentar nivelar muy bien cada parte, que no se vaya todo al Must. Con paciencia y bien explicado, seguro que el usuario puede pasar requerimientos a otra parte.

Pero es una técnica en la que el usuario, ante la toma de requerimientos, se encuentra que, de partida, ya va a descartar requerimientos. ¿Es eso un inconveniente? No del todo. Se descartan requerimientos contínuamente. En todas las sesiones de brainstorming en una toma de requerimientos aparecen buenas ideas que se descartan inmediatamente porque hay otros desarrollos más importantes. Es mucho más agradable ver que tu idea pasa al Won’t que cuando sencillamente no se escribe en ningún sitio. Tomando el Won’t como eso, buenas ideas que no estarán por el momento pero que ‘tomamos nota’, el usuario quedará más satisfecho y se acostumbrará a pasar requerimientos a esta última clasificación.

Otro truco es combinar este método con cualquier otro, lo que nos puede dar una priorización completa. Se ve a menudo combinarlo con elementos de riesgos técnicos y de negocio (el riesgo de la no incorporación del requerimiento a tiempo). Esto daría una priorización ‘completa’, una lista ordenada, pero en la mayoría de los casos no lo considero necesario.

Conclusión

A modo de conclusión, tan sólo comentar que, bien utilizada y en un entorno en que los usuarios sean capaces de ‘sacrificar‘ alguno de sus requerimientos, es una técnica rápida y suele dar buenos resultados. Además, el Won’t provee a las nuevas versiones de información poderosa.

La toma de riesgos en las decisiones del emprendedor

Riesgo
CC- Atribución Algunos derechos reservados por epSos.de

El riesgo es inherente al emprendimiento. Es extraño que podamos conocer todos los posibles resultados, con lo que esta falta de información de las consecuencias de nuestras decisiones conlleva mucho riesgo.

El riesgo, por otra parte, es subjetivo. Lo que uno puede ver como mucho riesgo otro lo puede ver como menor. ¿Tenemos los emprendedores mayor tendencia al riesgo? ¿Es la mente del emprendedor diferente? Esto podría parecernos, pero según Lowel Busenitz en “Entrepreneurial Risk and Strategic Decision Making” esto no es exactamente así. Sencillamente es una percepción diferente del riesgo. Para alguna gente, el sentarse en un puesto de funcionario durante 40 años, haciendo lo mismo y en el mismo lugar, es atractivo. Para otra gente representa el infierno. Es una percepción distinta de dónde está el riesgo, más que una vocación natural para enfrentarse al mismo. 

Las decisiones estratégicas de los emprendedores tienen riesgo por varios factores, como la falta de información, pero los emprendedores solemos ignorar hechos que no queremos ver. Queremos ver una perspectiva más optimista para los objetivos que perseguimos. Favorecemos el resultado que mejor nos conviene. 

¿Cómo se debe entonces enfrentar un emprendedor a sus riesgos? Mediante un procedimiento de evaluación serio. Cualquier metodología de riesgos de Gestión de Proyectos puede funcionar bien. Hay que evaluar correctamente cual es el impacto de nuestra decisión (en este caso tanto beneficios como perjuicios)  y la probabilidad de que esto suceda.

En el caso de un emprendedor hay que hacerse preguntas con las consecuencias, más allá de los posibles perjuicios económicos. Por ejemplo ¿Qué me costaría volver a hacer lo que estoy haciendo? ¿Perdería o ganaría mi experiencia si salgo a emprender y vuelvo a trabajar si fracaso?

Otro riesgo es pensar ¿Qué es lo que me puede sacar del negocio? Es posible que, con innovaciones, pueda producirse otra que literalmente nos pueda dejar fuera de la contienda. Los mapas de TomTom… bueno… por poco está fuera. Puede haber un Google Maps que nos deje fuera. Estos riesgos se pueden mitigar abriendo el mercado y diversificando este riesgo.

¿Qué debo hacer entonces para tomar mejores decisiones?

  1. Estar informado de lo que acontece en tu mercado.
  2. Aplicar múltiples perspectivas. Habla con la gente, pide su opinión y tenla en consideración. Recuerda que a la gente le encanta hablar de su trabajo.
  3. Usa puntos de vista más generales y más concretos. 

Para terminar, recordar que la peor decisión es la que no se toma. 

 

 

 

 

 

Blog de WordPress.com.

Subir ↑