archivo

Archivo de la etiqueta: valor

Para Bill Langley: “El plan de proyecto perfecto es posible si uno primeros documentos es una lista de todas las incógnitas”.

Quien no es consciente de eso realmente no es consciente de la realidad de un proyecto de desarrollo de software, ni.

Tampoco serán conscientes de que el objetivo final es conseguir el mayor valor posible del producto dentro del contexto en el que se ha desarrollado porque lo mismo el plan inicial impone restricciones que suponen una limitación o una resistencia si no se adapta a la realidad que nos estamos encontrando en el proyecto.

Y no solo se trata de que el contexto cambie y/o imponga una atmósfera diferente a la esperada, sino que también estamos las personas y no somos infalibles, los desarrolladores no lo son, los usuarios tampoco. Nos vamos a equivocar y por mucho que se pretenda prever eso, será muy complicado acertar cuándo, cuánto y cómo.

Se tiende a ir por el camino más corto que no es otro que conseguir facturación del cliente sea como sea: con funcionalidades que no necesita y/o en actividades que no generan valor. Esta cultura se ha consolidado en muchos proveedores de desarrollo de software, practicándola durante muchos años y no ha hecho otra cosa que hundir y desprestigiar nuestra profesión.

Sí, se ha ganado dinero con ella, pero la burbuja explotó hace años y ahora con la crisis económica nos está castigando con fuerza.

Se presiona para conseguir contratos, para conseguir beneficios, es normal, las empresas viven de eso, pero esa presión no debe justificar la elección del camino equivocado.

Soy de la opinión de que si se crea valor al cliente, si tiene retorno de la inversión, volverá a llamar a la puerta. Si en lugar de derrotas, los clientes contaran sus inversiones en software por victorias, no se lo pensarían tanto a la hora de tratar de conseguir ventajas mejorando o solicitando el desarrollo de nuevas aplicaciones.

Mary Poppendieck nos invita a que: “invirtamos el tiempo en lo que añada valor real al cliente”, creo que es un buen consejo.

Te puedes esforzar en un proyecto para cumplir una planificación y ceñirte a unos costes y sin embargo no conseguir nada, incluso desarrollando todas y cada de las funcionalidades tal y cual se especificaron en un principio.

¿Por qué? La idea inicial no tiene por qué funcionar, de hecho todos sabemos que es muy difícil acertar a la primera y todavía más conforme se incrementa el tamaño y/o complejidad de la solución. Esto es extensible tanto para el desarrollo de un producto propio como para el desarrollo de software para terceros.

Por tanto, afirmar que un producto que va acorde a unos plazos, unos costes y unas determinadas funcionalidades va bien, es mucho suponer si no se mide realmente el valor que se está obteniendo, de ahí el riesgo que supone, por ejemplo, un desarrollo en cascada cuando los desarrolladores y usuarios viven separados desde la finalización del análisis hasta etapas próximas a la entrega.

En los desarrollos iterativos incrementales, con entregas más frecuentes y con versiones en producción desde etapas tempranas el feedback permite evaluar el valor real que se está obteniendo y adoptar decisiones encaminadas a incrementarlo.

Otra cosa, es que pese a trabajar de esta forma se quiera seguir con el guión inicial prácticamente sin variaciones, en ese caso, poco importará la metodología porque predominará el seguimiento de un plan y esto es consecuencia muchas veces no de confiar ciegamente en él, sino por el afan de cumplir, de cubrir el expediente: “si al final se fracasa, la culpa no es nuestra, sino del plan”.

El proyecto se queda sin presupuesto, al menos, a corto y medio plazo y los responsables funcionales entienden que existen funcionalidades que son necesarias para que el producto sea de utilidad o para que la productividad en el uso del mismo sea aceptable.

¿El problema? No hay dinero para hacer todo lo que necesitan, ¿cuál es la primera consecuencia? Desgaste, incluso en situaciones donde el desarrollo haya sido fluído. A los usuarios les entra el síndrome de la última versión y el proveedor de servicios de desarrollo por muy flexible que sea tendrá que mirar por los resultados económicos del proyecto.

Gestionar bien esa circunstancia tanto por parte del cliente como del proveedor es esencial ya que se puede tirar por tierra todo el esfuerzo de meses de trabajo. No es sencillo porque todos sabemos lo complicado que resulta cerrar un proyecto.

No existen fórmulas mágicas, solo el sentido común, la búsqueda del beneficio mutuo y un autoanálisis crítico del trabajo que se ha realizado en el proyecto con el objeto de asumir responsabilidades (si existen). Si ambas partes quieren se puede alcanzar un acuerdo satisfactorio, si una de ellas se resiste probablemente terminen perdiendo ambas.

Además de lo anterior, la solución ideal pasaría por dotar al proyecto del presupuesto adicional necesario para terminar de manera adecuada los trabajos, si bien pueden existir circunstancias que lo impidan o, al menos, que lo impidan temporalmente.

Recordemos que lo realmente importante es el valor del proyecto y su relación adecuada con la inversión realizada y no acertar con una estimación inicial que todos sabemos (cliente y proveedor) cómo está hecha. Si tu objetivo es hacer que la estimación sea acertada tal vez te lleves ese logro pero tal vez, también, el proyecto se quede a medias o se entregue un producto deficiente,

Estimar es difícil y resulta muy complejo cuando nuestro desconocimiento del sistema es importante.

Por eso, hacer un presupuesto inicial que condicione al proyecto y al producto y considerarlo como algo inamovible es temerario porque la probabilidad de un error sensible en la estimación es importante salvo que se haya optado por la opción de sobreestimar los costes con el objeto de tener un colchón al que acudir cuando nos encontremos con contingencias.

Veo necesario estimar porque es conveniente tener una referencia y tan necesario como eso es hacer un seguimiento del valor que vamos ganando con el producto con el objeto de ver que la inversión realizada va obteniendo sus resultados, a la par de que se tenga conciencia de que el desarrollo de software es un proceso evolutivo y que a veces un paso pequeño hacia atrás supone después un producto de mayor calidad y valor.

Si planteas un proyecto llave en mano con un alcance difuso y un presupuesto fijo, estás sentando las bases de un proyecto que producirá mucho desgaste entre las partes y donde el principal perjudicado de todo será el producto final que se obtiene.

Lo importante es el valor final del producto y que sea acorde con la inversión realizada dentro del contexto en el que se ha desarrollado el proyecto. Que sea acorde con la inversión y el contexto quiere decir que el retorno de la misma sea asumible teniendo en cuenta las condiciones en que se ha desarrollado el proyecto porque no es lo mismo encontrarnos con múltiples problemas y con gran incertidumbre que unas condiciones más favorables.

Si se está en el día a día del proyecto y no en la distancia se sabrá si efectivamente el incremento de la inversión inicialmente prevista está justificado. El problema es que quienes toman estas decisiones suelen estar lejos y no estar debidamente informados.

Conforme se va avanzando en el proyecto, se co.noce mejor sus casuísticas, la tecnología y si se acota suficientemente el trabajo, el nivel de acierto en las estimaciones crece considerablemente, por eso hay que tener paciencia al principio si hay sprints que no cumplen los objetivos marcados

Llega un momento en la evolución de un producto o en un proyecto de desarrollo de software donde echamos en falta todo ese esfuerzo que no se ha aprovechado de manera adecuada, ¿por qué? lo necesitamos ahora o prevemos que lo vamos a necesitar pronto y ya ha desaparecido.

Una de las causas que hacen que el aprovechamiento del esfuerzo no sea óptimo es trabajar con historias de usuario, requisitos o especificaciones que no están claros y en los que existe una probabilidad importante que la solución implementada requiera ser modificada de manera sensible más adelante.

Es mejor invertir el esfuerzo en aquellas tareas donde el retorno de la inversión sea más probable, en donde el efecto sobre el valor del producto sea más inmediato.

Lo que no esté claro debe tratar de solventarse hasta donde se pueda ya que de esta manera se desarrollará con una mayor intención y los ajustes posteriores serán de menor entidad.

Tampoco podemos estar paralizando indefinidamente el desarrollo de una funcionalidad que sea crítica o importante para el sistema pero sí podemos esperar hasta el último momento posible para tratar de que esté lo mejor definida posible.

Realizar una correcta gestión de las expectativas es fundamental en todo proyecto de desarrollo de software. Hay que ser muy constante en este aspecto porque aunque se piense que las expectativas están bajo control, las mismas van a variar con el tiempo, ya sea por la propia evolución del proyecto o por presiones que se reciban desde el exterior.

Los responsables funcionales te van a apretar porque tienden a exigirte un mayor alcance y en un menor tiempo de lo pactado. Tienen que comprender (y tener una cierta experiencia) cómo funciona un proyecto con prácticas de Scrum para que sean más moderados en sus peticiones de modificación del sprint, sin embargo, cuando ellos mismos están recibiendo presiones, les resulta complicado no traspasarte, aunque sea, parte de ellas.

Precisamente por este motivo se agiliza en muchos casos las prácticas de Scrum con Kanban, pero esto simplemente trata de definir determinadas reglas del juego, la complejidad realmente se encuentra en mantener un equilibrio entre lo que el usuario desea y lo que realmente se puede hacer (o lo que realmente se considera práctico realizar), porque está claro que el usuario manda, pero también debe ser consciente, y para eso estamos nosotros, de la complejidad que tiene la realización de una determinada solución.

Es importante poner las cartas sobre la mesa y a partir de ahí que decida. No vale con ser simplemente ejecutores de historias de usuario, también tenemos que proporcionar ese valor a los product owners porque se trata de aprovechar de la mejor manera posible la inversión, de manera que consigamos ganar el mayor valor posible con el menor esfuerzo y de no complicar de manera innecesaria el producto.