archivo

Archivo de la etiqueta: valor

Nuestro objetivo y el del cliente debe ser tratar de conseguir el mayor valor posible para el producto, lo cual requiere que se haga un uso racional de la inversión ya que de esta forma tendremos la posibilidad de obtener un mayor rendimiento de las iteraciones.

Para eso es muy importante desarrollar con intención, lo que requiere una alta implicación de todos los stakeholders del proyecto, sobre todo del responsable funcional, de las personas que colaboran con él y del equipo de desarrollo.

Sin embargo, la falta de intención no es el único factor que puede hacer que no se extraiga el mayor aprovechamiento posible de la inversión, hay otro muy importante que son las actividades de proceso o metodología, ya sea incluidas por el propio equipo de desarrollo o por la organización, que generan entregables que no aportan un valor real al producto y al proyecto.

Este mal es muy común en organizaciones que entienden que la singularidad de los proyectos es algo secundario y que todos deben tener un cuerpo de procesos común. Esto es lo mismo que pretender que una misma talla de ropa sirva para todos los componentes de una familia.

Parto de la base de que la organización necesita armonizar determinadas actividades de los proyectos, requiere recibir unos inputs necesarios para su gestión y para mantener un cuerpo de conocimiento. Soy de la opinión de que la base deben ser unos mínimos, comunes a todos los proyectos, con la mentalidad abierta a crear excepciones si fuera necesario (teniendo en cuenta que la excepción no se debe convertir en la norma) y que a partir de ahí, sea el proyecto quien mande, alcanzándose acuerdos para ampliar esa base de procesos si todas las partes entienden que aporta valor.

El problema lo tenemos cuando no se parte de mínimos y cuando se intenta encorsetar el desarrollo con actividades, sean pocas o muchas, que no solo restan flexibilidad al proyecto sino que originan costes en tareas y entregables cuyos coste de realización (y mantenimiento) son superiores al valor que proporcionan al producto y a la organización.

Anuncios

Hace un par de días publiqué un artículo en el que indicaba que las especificaciones contractuales, por regla general (y con las matizaciones que hice), suponen un freno o una resistencia al objetivo de tratar de conseguir el mayor valor posible con la inversión realizada.

En este artículo voy a tratar de exponer que una situación diferente (que no necesariamente contraria), que no otra es la pérdida de una visión global de lo que se pretende conseguir, también supone un riesgo importante.

¿Por qué? La clave se centra igualmente en el valor. El valor de cada historia de usuario desarrollada junto a las expectativas de lo que se pretende conseguir en el proyecto, siempre y cuando estas se adapten a la propia evolución de los trabajos y de la propia organización, es lo que permite conseguir el equilibrio.

Esa pérdida de visión de sus propias expectativas por parte de un product owner, cuando se empeña, por ejemplo, en refinar sobremanera funcionalidades que, siendo importantes, ya funcionan de manera adecuada, provoca que se sobrevaloren historias de usuario que puestas en contexto tienen un valor muy
inferior porque existen otras necesidades en el sistema que pueden que no tengan todavía un funcionamiento aceptable o ni siquiera se han abordado.

Pero la búsqueda de la perfección no es el único problema, también lo tenemos cuando el product owner se centra en aspectos relacionados con lo que le puede gustar o dominar más, dejando de lado, otros más ásperos, complejos o que requieran un consenso que no resulta siempre facil de conseguir pero que también resultan necesarios para tener un sistema de mayor valor.

La visión del proyecto y expectativas no son fijas pero existen o deben existir para poder dar el valor adecuado a cada historia de usuario en la que se trabaja y para ir orientando la línea de desarrollo del producto hacia lo que se pretende conseguir, de lo contrario es posible que no se centren los esfuerzos y la inversión en lo realmente importante.

Siempre comento que la importancia del valor del producto resultante es mayor que la del presupuesto, siempre y cuando estén compensado o exista una descompensación a favor del valor (cuánto más virada esté la balanza en esta dirección, mucho mejor).

De ahí la importancia de tener un buen product owner, con criterio y que también sepa dejarse aconsejar por otros usuarios y por el equipo de desarrollo.

El valor muchas veces se encuentra limitado por las especificaciones contractuales, cuando éstas marcan una serie de objetivos, que lo mismo resultaban interesantes en el momento en que se redactó el contrato, pero que tal vez, durante la ejecución del proyecto dejen de serlo, o al menos, pierdan peso respecto a otras necesidades sobrevenidas o que aparecen como consecuencia de la utilización de la aplicación.

Cuando nos encontramos en circunstancias así, llegará el momento donde el contrato, salvo que se hagan (si se puede) modificaciones sobre el mismo, predominará sobre la posibilidad de conseguir un mayor valor.

El contrato es un elemento estático, el mundo no lo es y, en consecuencia, los proyectos de desarrollo de software tampoco lo son. Lo mejor es establecer especificaciones contractuales más abiertas, que permitan una mayor flexibilidad y margen de maniobra.

Eso no es lo mismo que firmar un cheque en blanco, sino de saber leer mejor el contexto y expresarlo en un contrato.

Como siempre, no hay soluciones absolutas, lo mismo puede ser conveniente en desarrollos concretos, ser extremadamente meticuloso con especificaciones y alcance (sobre todo en desarrollos llave en mano).

Un enfoque iterativo incremental de ciclos cortos y el feedback que se obtiene a partir de ellos permite probar la efectividad de los enfoques de los usuarios (que inicialmente no son más que hipótesis sobre lo que quieren) y realizar ajustes que nos van acercando progresivamente a una solución que realmente satisface las expectativas del usuario.

En los enfoques clásicos las hipótesis no se compruebas hasta etapas finales del desarrollo en donde los presupuestos están casi agotados y en donde el tamaño del producto dificulta la realización de modificaciones. Menos dinero, más envergadura del producto, más deuda técnica, menos margen de maniobra.

Todos los que hemos trabajado con ciclos de vida en cascada y/o con contratos llave en mano hemos sufrido esa situación. Da igual lo bien que trates de hacer el análisis que siempre habrá funcionalidades que no se han definido correctamente, que ni siquiera se han definido o que son mejorables y, además, siempre existirán circunstancias a lo largo de la ejecución del proyecto que impliquen cambios de prioridades.

El conocimiento real del producto se va obteniendo conforme se va desarrollando, ¿por qué? pues porque se contrastan las hipótesis y con ello se va mejorando y adquiriendo nuevo conocimiento.

Está bien tener una visión de lo que se quiere pero el detalle se debe trabajar poco a poco, lo demás es correr un riesgo importante de desperdiciar esfuerzo y no nos podemos permitir ese lujo porque en el propio devenir del proyecto y del desarrollo del producto habrá esfuerzo que no proporcione un valor directo, ya que a veces la solución elegida para una determinada funcionalidad deberá cambiar de orientación o ser perfilada en diferentes iteraciones, algo que es normal en cualquier proyecto y que, por tanto, debe contar con suficiente respaldo presupuestario que, como no andará sobrado, es conveniente cuidarlo desde un principio.

La reducción de costes no va en dirección opuesta a la generación de valor.

Tal vez el problema podría estar inicialmente en una mala gestión de los recursos económicos disponibles, si bien, si no se cambian comportamientos, enfoques y estrategias a todos los niveles, muy difícilmente se conseguirá que la reducción de costes vayan de la mano de una mayor capacidad de generar valor.

Y eso ha pasado una y otra vez en este período de crisis, en el cual, se ha optado por lo fácil que es recortar, sin que exista un plan alternativo que tenga como objetivo hacer las cosas mejor y siempre es posible, si se tiene una mínima capacidad de autocrítica, de hacer las cosas mejor.

Para Michael Bolton (traducción libre): “Si estás implacablemente centrado en la reducción de costes,rápidamente te convertirás en alguien ajeno a las oportunidades que permitan aumentar el valor”.

Esta reflexión va en la línea de lo comentado anteriormente, es decir, si tu objetivo único es recortar, sin centrarte en el crecimiento, enfocarás tu atención en eso y no en los cambios necesarios para invertir la tendencia de la organización porque la misma tendrá, tal vez, menos costes pero seguirá sin crecer y, lo más probable, es que como sigue sin hacerse nada para adaptarse al nuevo contexto, la situación no hará más que empeorar, lo que llevará inexorablemente a la realización de nuevos recortes. Hasta que ya no quede más que recortar.

En el campo de los proyectos de desarrollo de software, muchas organizaciones están optando por recortar la inversión. De entrada no es ni bueno ni malo, racionalizar la inversión, habría que analizar cada situación en particular.

El problema nos lo encontramos en el momento en que a proyectos concretos se les mete la tijeras, sin que vaya de la mano de una recorte proporcional en las expectativas. Ese desequilibrio solo puede moderarse a costa del esfuerzo de los que participan en el proyecto, que incluso haciéndolo muy bien, no podrán, en todos los casos, hacer un producto satisfactorio porque precisamente los recortes han obligado a hacer un sobreesfuerzo y a renunciar a ciertos patrones de calidad que han impactado en la capacidad de generar valor en cada iteración del producto.

Para Donald Norman: “Los objetos bien diseñados son fáciles de interpretar y de comprender ya que contienen pistas visibles de su funcionamiento”.

Un código fácil de leer y de entender en entornos altamente colaborativos como son los equipos de trabajo ágiles resulta esencial. También lo es para otros tipos de enfoques.

No es sencillo, se requiere tiempo, conocimientos y experiencia, también nos podemos apoyar con herramientas que nos ayuden a aplicar buenas prácticas y también se requiere ser sistemático y creer en los beneficios que aporta hacer el trabajo de esta manera, de lo contrario se te pondrá muy en cuesta arriba refactorizar, tanto tanto, que no lo harás.

Hacer esto bien requiere dedicarle el tiempo que necesita, cuando estamos en proyectos ligados a plazos y los recursos disponibles son muy limitados, se convierte en objetivo ejecutar todo el trabajo posible y se deja de lado la calidad del código ya que en esos momentos conceptos como la deuda técnica no se encuentran entre las prioridades del desarrollador. Es cierto que es contraproducente ya que una deuda técnica elevada hace más pesado el proceso de desarrollo pero cuando el fuego te está llegando a los pies solo piensas en correr.

Por ese motivo creo mucho más en el valor del software que en las agendas, un buen software requiere del tiempo y de las personas necesarias para hacerlo, sin equilibrio la calidad del software sufre (también la cuenta de resultados del proyecto).

Comenta Mary Poppendieck que: “Si quieres saber lo que el cliente quiere, dale lo que crees que quieren y escucha lo que te tienen que decir al respecto”.

Esa es la esencia del feedback: el usuario da una especificación, ejecutas según la interpretación que has hecho de la misma, obtienes un resultado y el usuario opina sobre el mismo, solicitando aquellos ajustes que consideres necesario.

En el caso de que desarrolles un producto y no te bases en especificaciones directas, el proceso es el mismo.

Recuerda que el sistema que desarrollas no es para ti. Tal vez las decisiones del usuario no te gusten, tal vez pienses que hay otras soluciones más adecuadas, si es así, exponlas, porque lo mismo ese punto de vista no se ha tenido en cuenta, pero no las impongas o manipules para que ese sea el camino elegido. Todos tenemos derecho a equivocarnos, pero más quien paga.

El objetivo es incrementar el valor del producto y la mejor forma de hacerlo es centrarnos en quiénes van a ser sus usuarios porque son ellos los que van a tener que convivir con él todos los días.