El anti patrón “Mushroom Management”, también conocido como “Pseudo-Analysis” o “Blind Development”, es comúnmente descrito con la siguiente frase: “Mantén a tus desarrolladores en la oscuridad y aliméntalos con fertilizante”. Esto quiere decir que mantengan a los desarrolladores sin ningún tipo de contacto con los usuarios finales del software. Pero, ¿este tipo de gestión es positivo o negativo para el proyecto software?

Este anti-patrón se basa en que sin la participación del usuario final se asumen riesgos de que se termine construyendo el sistema incorrecto. Por ello, vamos a conocer la problemática de este tipo de gestión y las soluciones que podemos aplicar.

Problema del Mushroom Management

En algunos ambientes de gestión, existen políticas explícitas de las organizaciones para aislar a los desarrolladores del de los usuarios finales del sistema. Los requisitos del sistema se les hace llegar  través de intermediarios, incluidos arquitectos, gerentes o analistas de requisitos. Este caso asume que tanto los requisitos son bien entendidos y asumidos por los usuarios finales y por los involucrados en el proyecto, asumiendo que los requisitos son estables durante el proyecto.

Pero hay algunas suposiciones erróneas en este tipo de gestión:

• Los requisitos del sistemas cambian frecuentemente y estos cambios pueden generar alrededor del 30% del coste del proyecto. En este tipo de gestión, los cambios no son descubiertos hasta la entrega del sistema.
• Los documentos de requisitos rara vez son comprendidas por los usuarios finales, que pueden visualizar más fácilmente el significado de los requisitos cuando experimentan una interfaz de usuario con un prototipo. El prototipo permite a los usuarios finales articular sus necesidades reales en contraste con las características del prototipo, pudiendo dar feedback temprano sobre un sistema funcionando.
• Cuando los desarrolladores no comprenden los requisitos globales y la visión de un producto, raramente entienden las necesidades y tipos de interacciones de los componentes e interfaces necesarias. Debido a esto, se toman decisiones de diseño incorrectas y a menudo resultan en  interfaces débiles que no cumplen con los requisitos funcionales. Por ello se debería involucrar desde el comienzo del proyecto a los profesionales de UX, Diseño y Desarrollo.

Este anti-patrón afecta a los desarrolladores y otros roles creando un ambiente de incertidumbre sobre el proyecto. A menudo, los requisitos documentados no son lo suficientemente detallados, y no existe una forma efectiva de obtener una aclaración acerca de estos.

Para implementar las distintas funcionalidades, los desarrolladores deben hacer suposiciones, lo que puede conducir a un “pseudoanálisis”, es decir, un análisis que se lleva a cabo sin la participación del usuario final. Algunos proyectos  eliminan la fase de análisis por completo y pasan directamente de los requisitos de alto nivel al diseño y la codificación. ¡Gran error!

¿Como podemos obtener una solución al Mushroom Management?

El Risk Driven Development (a partir de ahora RDD) es un modelo de desarrollo basado en la creación de prototipos y comentarios de los usuarios para minimizar los riesgos. El RDD es una especialización del modelo de ciclo de vida iterativo-incremental.

Cada incremento del proyecto incluye extensiones de funcionalidad de la interfaz del usuario. El incremento incluye un experimento de interfaz de usuario, que incluye experiencia práctica del propio usuario. Este experimento evalúa la aceptabilidad y usabilidad de cada funcionalidad. Los resultados obtenidos influyen en la dirección del proyecto mediante la selección de la siguiente iteración. Dado que el proyecto evalúa con frecuencia la aceptación del usuario y utiliza esta información para influir en el software, el riesgo de rechazo del usuario se minimiza.

¿Todo este modelo de trabajo no os suena nada a Agile? Entrega continua de valor y funcionalidad al cliente, para poder evaluar que aporta valor, y re-priorizar las necesidades y poder absorber los cambios de requisitos de una manera temprana.

Otras soluciones

Incluir un experto de dominio en el equipo de desarrollo es una forma muy eficaz de tener un input del dominio en las decisiones del proyecto. Cada vez que hay una pregunta específica de dominio, los miembros del equipo tienen la capacidad de resolverlas con este experto. Un riesgo importante en este enfoque, sin embargo, puede ser el experto de dominio representa solo una opinión de la comunidad de dominio, por ello este debe representar  y defender las necesidades del negocio.

¿Y esta parte no  os suena al product owner dentro de la metodología ‘Scrum’?

Este artículo trata de ser una traducción del siguiente artículo relacionado con los anti-patrones de desarrollo software: https://sourcemaking.com/antipatterns/mushroom-management

Conclusión

Tradicionalmente, la gestión de proyectos han intentado separar en los proyectos la parte de gestión de la parte de desarrollo , algo así con lo que se conoce comúnmente como los “thinkers” y los “doers”. Sin embargo, hoy en día existen modelos de gestión totalmente renovados, que llevan las necesidades del cliente desde el comienzo con la parte técnica del proyecto, pudiendo proponer mejores soluciones y entender las necesidades para proporcionar las mejores soluciones.

Es importante estar alineados con el resto de departamentos involucrados en el proyecto, para proporcionar la mejor solución al cliente. Y tú, cuéntanos tu experiencia ¿Has sufrido el “Mushroom Management”?