archivo

Archivo de la etiqueta: producto

Sin embargo, pese a todo, el problema de fondo se sitúa más allá del enfoque, sino en la importancia real que se le da al proceso de desarrollo sobre el producto software, que no es más, en esencia, que la importancia real que se le da a las personas en todo esto.

Cuando se mira más al procedimiento que a las personas no me extraña que se nos considere recursos porque da una idea de servicio a un fin distinto al que se pretende con el desarrollo de software (se sirve al proceso), que es conseguir un producto final que proporcione el mayor valor posible al usuario final (ahora hablo de valor, antes lo hice de calidad, al final de esta serie de artículos, los trataré de manera conjunta).

Independientemente de que haya determinados desarrollos, como por ejemplo, soluciones que se obtienen a través de configuración de productos base, donde el procedimiento puede tener gran interés (al fin y al cabo el producto ya existe), el desarrollo de software es una actividad intelectual que se lleva a cabo interactuando y colaborando con otras personas, tratando de eliminar fronteras entre ellas que creándolas de manera artificial.

Tenemos un producto que ha sido desarrollado con todos los entregables documentales que solicita el proceso, ¿debería ser un sistema fantástico? Sabemos que no es así o por lo menos que no es necesariamente así. Si todo fuera tan fácil como seguir una receta, no hubiera existido el concepto de crisis del software y la misma no hubiera llegado hasta nuestros días y no hubieran aparecido movimientos como el ágil que entienden que el desarrollo de software se basa en el producto y en las personas.

El valor de un producto se mide realmente cuando entra en producción aunque se ponga en funcionamiento una parte pequeña del mismo. Todo valor anterior son perspectivas, hipótesis y expectativas.

Sobre esa base, toda suposición inicial sobre el valor final del producto no deja de ser una idea abstracta, teniendo en cuenta que todavía lo que se tienen son ideas, con más o menos detalles, definidas con mayor o menor formalidad.

El valor del producto no crece linealmente, es más, puede reducirse y todo ello sin que se tenga que tocar una sola línea de código.

Mantener y/o incrementar ese valor es el objetivo del desarrollo de software mientras exista una rentabilidad entre la inversión necesaria y los resultados obtenios.

Con un enfoque iterativo incremental se pretende que el valor del producto crezca en cada iteración (digo que se pretende, ya que iterar por iterar no supone, de base, nada) a través de una mejora continua del mismo tomando como base el feedback del usuario con la mejora de funcionalidades ya realizadas y del desarrollo de otras nuevas.

El valor está intimamente relacionado con la utilidad que tiene el producto para el usuario y/o para su organización en un momento dado del tiempo.

Con este planteamiento el proceso de desarrollo de un producto parece no tener fin teniendo en cuenta que su fundamento es el valor, que siempre es posible mejorar un sistema (hasta que llega un punto donde la mejora produce menos que el esfuerzo realizado para llevarla a cabo) y que el valor de un producto, aún siendo estable, aún no tocándose, puede variar (nuevos contextos).

Realmente considerar que no existe versión final (salvo la existente al final del ciclo de vida) de un sistema es ajustarnos a lo que pasa habitualmente (otra cosa es que a nivel de proyecto si haya una versión final, si bien una cosa es el proyecto y otra el producto).

Es cierto que el enfoque ágil en los proyectos de desarrollo de software pone en primera línea al producto que se está desarrollando poniendo a su servicio el conjunto de actividades y tareas que se realizan.

Pero, ¿quiere decir esto que solo me debo fijar y centrar en el producto con el que estoy trabajando? Sobre esto conozco opiniones de todos los gustos. Desde mi punto de vista hay que mirar un poco más allá, sobre todo si eres parte de la organización para la que se está desarrollando el producto ya que no comparto la idea de que cada iniciativa sea un producto independiente y que no tenga en cuenta todo lo demás que se ha desarrollado (sé que es un extremo, pero creo que se me entiende lo que quiero decir).

La propia especificación del producto probablemente hará necesaria la integración con terceros sistemas de la organización, el problema existe cuando más allá de esas especificaciones conocemos elementos con los que deberíamos integrarnos o soluciones que podríamos reutilizar y nos negamos a ello por el simple hecho de que siempre parece (y generalmente) resulta que cuanto menos dependencias tengamos mejor (o mejor dicho, más fácil).

Soy de la opinión de que no conviene fragmentar las soluciones ni estar continuamente reinventando la rueda por lo que cualquier decisión a este respecto que se aleje de ese objetivo no me parece, de primeras, acertada. Ahora bien, tampoco me muestro inflexible, no es ágil cerrar las puertas a determinadas opciones (siempre y cuando no se superen determinadas líneas rojas y para mi, en este caso no lo supone) porque siempre puede haber un proyecto donde la opción más acertada sea esa y si lo es, es viable y los inconvenientes se encuentran lejos de las ventajas y/o son minimizados, ¿por qué no aplicarlo?.

Cuando en la definición y puesta en práctica de un proceso se habla de todo menos del producto algo está fallando. Si en tu organización aplicáis procesos relacionados con el desarrollo de software, échale un vistazo a lo que dedica realmente a cuidar el producto.

Los procesos tienden a cuidarse a sí mismos. Si tenemos en cuenta que los procesos son instrumentos y no objetivos quiere decir que estamos cuidando los instrumentos y no lo que pretendemos conseguir haciendo uso de ellos, teniendo en cuenta que ningún proceso puede asegurar la calidad del software (por mucho que se diga que están precisamente para eso).

Los que definen y fiscalizan los procesos tienden a cuidar a los procesos, no tanto porque crean en ellos sino por protegerse a sí mismos convirtiendo a los procesos como un fin en el que los productos son solo una excusa para preservar su existencia.

Y si los procesos no funcionan se termina echando más leña al fuego: se extienden, se hacen más rígidos, la fiscalización se realiza con más celo, etc… porque se entiende que la culpa no es del proceso sino de las personas que lo aplican y como las personas fallan, ahí están los procesos para solucionarlo todo.

La solución a los procesos no es la ausencia de procesos. Como he comentado en más de una ocasión, unos procesos lo suficientemente flexibles, que admiten excepciones, donde su supervisión tiene en cuenta el día a día de lo que acontece en los proyectos de desarrollo de software es interesante porque proporciona una base común para armonizar ciertos aspectos en los trabajos. Los procesos pierden su utilidad y se convierten en una carga cuando cobran más importancia de la que deben tener y le quiere robar el papel de protagonista al producto.

La respuesta puede parecer evidente pero, ¿a qué conocéis muchos casos en los que precisamente parece que el objetivo es satisfacer un proceso?.

¿Por qué se llega a esa situación? Por el convencimiento de que a través del proceso es cómo se obtienen productos de calidad.

Si esto fuera así el desarrollo de software no tendría historia, no tendría la complejidad que tiene y la inmensa mayoría de los proyectos terminarían con éxito.

El proceso puede ayudar a armonizar los desarrollos dentro de una organización, lo cual puede ser interesante siempre y cuando se determinen líneas a seguir de alto nivel y siempre al servicio del proyecto. También puede ser interesante para establecer un background en la realización de los proyectos pero de igual forma que en el caso anterior siempre que se vea como un instrumento que determina ciertas pautas y que ofrece flexibilidad para poder ser adaptado al proyecto en el que estamos trabajando y que puedan existir excepciones si estuviera justificado.

El objetivo es el producto, siempre el producto, pero no con una visión del mismo como una entidad única tras la cual no hay nada más, eso es un error ya que en la organización habrá otros sistemas de información, habrá otras soluciones sobre las que sera necesario o conveniente integrarse y que si no se tienen en cuenta provocará duplicación de funcionalidades, problemas a la hora de integrar datos, fragmentación de soluciones, etc…

Producto, siempre el producto, por encima de los procesos, sin que estos deban obviarse o dejarse de lado.

Se ha enfocado y asociado de manera errónea la calidad del producto a la calidad del proceso, lo que ha provocado que los esfuerzos se hayan centrado en el proceso, de tal forma que en muchos casos se considera un fin y no un medio para conseguir el verdadero objetivo que es desarrollar software de calidad.

Y todavía peor que eso, se asocia en muchos casos la calidad del proceso a la cantidad del papel generado y por tanto, de manera transitiva, el producto software era tan bueno como kilos de papel se hubieran generado en el desarrollo.

Por ese motivo, la realización de análisis o conclusiones finales sobre proyectos que se centren exclusivamente o principalmente en aspectos procedimentales me parece un error, entre otras cosas porque incluso en aquellas circunstancias en las cuales el proyecto haya ido bien y haya sido a nivel de proceso ejemplar nos podemos encontrar con que el producto final es muy costoso de mantener por tener una deuda técnica alta o por tener una arquitectura no escalable.

El proceso debe estar al servicio del producto y a las necesidades que se tengan en su proceso de desarrollo, las cuales estarán muy condicionadas por las circunstancias y contexto en que se realiza.