Published 16 years ago
(updated 13 years ago)
¿Cuál es la última moda en tecnología?, ¿qué nuevo estilo dictan las corrientes comerciales de nuestra distinguida y glamorosa tecnología de software?, ¿recuerdas el revuelo que había por incorporar las ideas de análisis y diseño estructurado?, ¿y más tarde el apuro por presentar en términos de orientación a objetos todo lo que se moviera en software? La lista de tendencias ha incluido categorías tanto de diseño y arquitectura como de procesos y productos.Lo interesante es indagar, con una visión crítica,los costos y beneficios de cada tendencia.
Un nuevo paradigma
¿Qué tal nos caería ahora una tendencia en la categoría de las personas? Una que podríamos nombrar como: “Programación orientada a finanzas” o “Programación orientada a valor de negocio”. Una tendencia que derive
en un nuevo paradigma, en uno que responda a necesidades en nuestro contexto actual. Después de todo, los paradigmas o esquemas mentales que organizan nuestra concepción del mundo, como los plantea Thomas S. Kuhn , se forman precisamente en respuesta al contexto.
Hoy en día, un programador de computadoras junto con cualquiera que decida aspectos de diseño y arquitectura durante la creación de software —dentro de un contexto de negocio— necesita contar con, al menos, el entendimiento básico de los términos financieros relacionados con dichas decisiones. Esta es mi tesis en este artículo. La razón filosófica de fondo detrás de dicha tesis es una de tipo ético, es decir, una que base en un sistema de valores determinado (por eso la tendencia propuesta cae en la categoría de las personas).
La razón práctica es que si el diseñador de software sólo valora los aspectos técnicos y primorosos de la tecnología, tendrá resultados significativamente diferentes a si valora también los aspectos financieros en sus decisiones de diseño.
Para presentar evidencia de soporte para tal razón, déjame comenzar poniendo un ejemplo
simple: Un requerimiento de negocio en un banco implica conectarse a una base de datos para obtener información de la línea de crédito de un cliente determinado. El diseñador de software, —muy entusiasta de
la última moda tecnológica— determina:
“...lo que el banco necesita desarrollar es un ‘framework’ de acceso para conectarse a dicha base de datos pues éste le va a aportar un sinfín de beneficios gracias a su gran flexibilidad proyectada y poder de extensibilidad que le permitirá acomodar una plétora de requerimientos futuros fácilmente, sin preocuparse más por volver a considerar diferencia alguna con respecto al acceso a esa base de datos en particular o a cualquier otra, aun si fuera de otro proveedor. Por tanto, no invertir en el desarrollo de esta infraestructura
aplicativa sería un grave error por parte del banco, una falta de visión en la evolución y la modernidad de la tecnología de software...”
¿En realidad este banco necesitaría invertir en el desarrollo de tal infraestructura aplicativa para acceso a datos?, ¿a eso se dedica?, ¿debería ser el foco de sus esfuerzos desarrollar este tipo de piezas? ¿ese es su
negocio? ¿o tal vez debería mejor enfocarse en desarrollar, de la mejor manera posible, la lógica de soporte a su negocio? Hay muchas piezas de software cuyo diseño y desarrollo es algo muy interesante para un programador, pues permiten experimentar con técnicas y conceptos novedosos. El programador puede realmente disfrutar pasar una noche o un fin de semana programando y avanzando en su oficio, pero cabe la pregunta ¿es justificable hacer eso a cuenta del negocio del cliente o empleador?
Valor de negocio
En el nuevo paradigma propuesto, la pregunta básica que el diseñador de software se debe hacer en cada decisión significativa de diseño es: ¿cómo aporta esta decisión al valor de negocio tanto en forma cualitativa
como cuantitativa? Pero, ¿qué es el valor de negocio? Aquí empezamos a notar uno de los rasgos que hace diferente a este paradigma, pues si bien en otros esquemas no se espera que el diseñador de software tenga alguna noción del significado del concepto de valor de negocio, en este se asume que posee un entendimiento básico de términos como: valor presente neto de una inversión, tasa interna de retorno, periodo de reembolso, retorno o rentabilidad de inversión, punto de equilibrio y otros indicadores clave de
un negocio o de una propuesta de valor de negocio.
El valor de negocio es por lo que existen las asociaciones, lucrativas o no. Está compuesto por los beneficios de acuerdo a la misión establecida para la organización en cuestión, ya sean ganancias económicas y de otro tipo (servicios públicos, responsabilidad ambiental, productividad, etcétera). Cualquier cosa puede representar valor de negocio, la clave es que esté debidamente formulado como parte de un esquema cuantitativo con el cual se proyecta la sostenibilidad de dicho negocio.
En el ejemplo, si el banco aceptara la supuesta necesidad de desarrollar él mismo sus propias piezas de infraestructura aplicativa para acceso a datos, tendría entonces que (1) esperar a que tal cosa estuviera lista para entonces empezar a contar los supuestos beneficios, (2) asignar el tiempo y esfuerzo de su gente para el desarrollo correspondiente, tiempo y esfuerzo que no estarán dedicados a atender el desarrollo de piezas con una autentica prioridad de negocio, (3) aumentar su nivel de inventario con piezas que deben mantenerse correctas durante todo el tiempo que duren hasta ser retiradas, cada línea de código nueva en la organización es una línea de código que debe ser mantenida correcta con cargo a la propia organización (está bien documentado el efecto que tiene el nivel de inventario sobre el valor de negocio), (4) correr el riesgo de que todo ese tiempo y esfuerzo se derroche si al paso del tiempo no se entregan los beneficios esperados por causa de una deficiente administración de la complejidad en el desarrollo de ese tipo de componentes de infraestructura aplicativa.
Un objetivo móvil
Lo único constante es el cambio. El valor de negocio entregado a través de software usualmente posee el peculiar rasgo de ser susceptible de indefinición y ambigüedad.
La razón es que el negocio puede tener una idea de lo que quiere, pero existen un cierto número de factores externos reales que no le van a pedir permiso para cambiar, al contrario, el negocio tiene que adaptarse o morir. Por otro lado, hay factores internos; por ejemplo, la sola presencia de una solución tecnológica para un problema X, provoca que se redefina dicho problema y sufra una especie de mutación tal que ahora tenemos un problema Y para el cual se requiere una nueva solución. Es el modelo de co-evolución solución/problema planteado ya por Frederick P. Brooks, Jr. (autor del clásico libro The Mythical Man-Month: Essays on Software Engineering) desde hace décadas.
El negocio necesita un proceso de desarrollo de software que sea capaz de seguirle el ritmo, no al revés, el negocio ajustándose a los dictados de un proceso rígido. Un proceso de desarrollo adaptativo, que mantenga una proporción razonable entre flexibilidad y disciplina y que principalmente esté enfocado en atesorar los aprendizajes sobre la marcha. Aprendizajes tanto del lado tecnológico como del lado del negocio. Uno que desde el inicio contemple que el negocio diga: “sí, eso es lo que pedimos, pero ahora queremos otra cosa y es esta...” y al mismo tiempo el grupo de desarrollo domine las técnicas de diseño para mantener una estructura limpia, estable y flexible para el software, cuyo costo de cambio no crezca exponencialmente.
Construyendo confianza
Un paradigma de programación orientada a valor de negocio tiene también como premisa que el proceso de desarrollo de software consiste en un proceso de construcción de confianza, no directamente en los individuos sino en que el proyecto de desarrollo en su conjunto —la colaboración y conjunción de personal de negocio y personal técnico— será capaz de entregar el valor de negocio en los términos requeridos.
La capacidad de entrega de valor de negocio implica tanto la capacidad del personal de negocio para escoger prioridades, especificar funcionalidad, definir criterios de aceptación, verificar funcionalidad, como la capacidad del personal técnico para crear el software que satisface lo prioritario a la fecha, sin derrochar tiempo o dilatar la entrega por estar construyendo cosas que no entregan valor de negocio hoy.
Una manera para construir dicha confianza en el proyecto es por medio de lograr y mantener un ritmo periódico de entrega de valor de negocio, el cual represente la serie de pasos con los cuales se aborda una aproximación sucesiva a lo que el negocio se va dando cuenta de lo que realmente quiere.
Conclusión:
Las conclusiones, junto con un planteamiento más extenso de esta idea de programación orientada a valor de negocio, son desarrollados en el texto de un servidor: “Beneficios sostenibles y desarrollo de software. ¿Cómo obtener beneficios sostenibles por los servicios que incluyen desarrollo de software? Parte I. El modelo adaptativo de desarrollo”, el cual está publicado en forma electrónica en la sección de artículos en línea del sitio web de SG. Los invito a que lo revisen y me hagan saber sus comentarios.
Referencias
[Kuhn, Thomas S. “La estructura de la revoluciones científicas” ISBN 9681675991]
[Denne, Mark.; Cleland-Huang, Jane. “Software by Numbers: Low-Risk, High-Return Development” ISBN 0131407287]
[Poppendieck, Mary; Poppendieck, Tom. “Implementing Lean Software Development: From Concept to Cash” ISBN 0321437381]
Acerca del Autor
Marco A. Dorantes es un consultor en el diseño y formulación de software desde 1987, oficio que lo llevó a la investigación aplicada en el campo de los métodos sistemáticos para diseño de software. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software, por ejemplo AutoTest for .Net y CppUnit for C++Builder disponibles desde www.xprogramming.com. Publica un diario electrónico en blogs.msdn.com/marcod
Un nuevo paradigma
¿Qué tal nos caería ahora una tendencia en la categoría de las personas? Una que podríamos nombrar como: “Programación orientada a finanzas” o “Programación orientada a valor de negocio”. Una tendencia que derive
en un nuevo paradigma, en uno que responda a necesidades en nuestro contexto actual. Después de todo, los paradigmas o esquemas mentales que organizan nuestra concepción del mundo, como los plantea Thomas S. Kuhn , se forman precisamente en respuesta al contexto.
Hoy en día, un programador de computadoras junto con cualquiera que decida aspectos de diseño y arquitectura durante la creación de software —dentro de un contexto de negocio— necesita contar con, al menos, el entendimiento básico de los términos financieros relacionados con dichas decisiones. Esta es mi tesis en este artículo. La razón filosófica de fondo detrás de dicha tesis es una de tipo ético, es decir, una que base en un sistema de valores determinado (por eso la tendencia propuesta cae en la categoría de las personas).
La razón práctica es que si el diseñador de software sólo valora los aspectos técnicos y primorosos de la tecnología, tendrá resultados significativamente diferentes a si valora también los aspectos financieros en sus decisiones de diseño.
Para presentar evidencia de soporte para tal razón, déjame comenzar poniendo un ejemplo
simple: Un requerimiento de negocio en un banco implica conectarse a una base de datos para obtener información de la línea de crédito de un cliente determinado. El diseñador de software, —muy entusiasta de
la última moda tecnológica— determina:
“...lo que el banco necesita desarrollar es un ‘framework’ de acceso para conectarse a dicha base de datos pues éste le va a aportar un sinfín de beneficios gracias a su gran flexibilidad proyectada y poder de extensibilidad que le permitirá acomodar una plétora de requerimientos futuros fácilmente, sin preocuparse más por volver a considerar diferencia alguna con respecto al acceso a esa base de datos en particular o a cualquier otra, aun si fuera de otro proveedor. Por tanto, no invertir en el desarrollo de esta infraestructura
aplicativa sería un grave error por parte del banco, una falta de visión en la evolución y la modernidad de la tecnología de software...”
¿En realidad este banco necesitaría invertir en el desarrollo de tal infraestructura aplicativa para acceso a datos?, ¿a eso se dedica?, ¿debería ser el foco de sus esfuerzos desarrollar este tipo de piezas? ¿ese es su
negocio? ¿o tal vez debería mejor enfocarse en desarrollar, de la mejor manera posible, la lógica de soporte a su negocio? Hay muchas piezas de software cuyo diseño y desarrollo es algo muy interesante para un programador, pues permiten experimentar con técnicas y conceptos novedosos. El programador puede realmente disfrutar pasar una noche o un fin de semana programando y avanzando en su oficio, pero cabe la pregunta ¿es justificable hacer eso a cuenta del negocio del cliente o empleador?
Valor de negocio
En el nuevo paradigma propuesto, la pregunta básica que el diseñador de software se debe hacer en cada decisión significativa de diseño es: ¿cómo aporta esta decisión al valor de negocio tanto en forma cualitativa
como cuantitativa? Pero, ¿qué es el valor de negocio? Aquí empezamos a notar uno de los rasgos que hace diferente a este paradigma, pues si bien en otros esquemas no se espera que el diseñador de software tenga alguna noción del significado del concepto de valor de negocio, en este se asume que posee un entendimiento básico de términos como: valor presente neto de una inversión, tasa interna de retorno, periodo de reembolso, retorno o rentabilidad de inversión, punto de equilibrio y otros indicadores clave de
un negocio o de una propuesta de valor de negocio.
El valor de negocio es por lo que existen las asociaciones, lucrativas o no. Está compuesto por los beneficios de acuerdo a la misión establecida para la organización en cuestión, ya sean ganancias económicas y de otro tipo (servicios públicos, responsabilidad ambiental, productividad, etcétera). Cualquier cosa puede representar valor de negocio, la clave es que esté debidamente formulado como parte de un esquema cuantitativo con el cual se proyecta la sostenibilidad de dicho negocio.
En el ejemplo, si el banco aceptara la supuesta necesidad de desarrollar él mismo sus propias piezas de infraestructura aplicativa para acceso a datos, tendría entonces que (1) esperar a que tal cosa estuviera lista para entonces empezar a contar los supuestos beneficios, (2) asignar el tiempo y esfuerzo de su gente para el desarrollo correspondiente, tiempo y esfuerzo que no estarán dedicados a atender el desarrollo de piezas con una autentica prioridad de negocio, (3) aumentar su nivel de inventario con piezas que deben mantenerse correctas durante todo el tiempo que duren hasta ser retiradas, cada línea de código nueva en la organización es una línea de código que debe ser mantenida correcta con cargo a la propia organización (está bien documentado el efecto que tiene el nivel de inventario sobre el valor de negocio), (4) correr el riesgo de que todo ese tiempo y esfuerzo se derroche si al paso del tiempo no se entregan los beneficios esperados por causa de una deficiente administración de la complejidad en el desarrollo de ese tipo de componentes de infraestructura aplicativa.
Un objetivo móvil
Lo único constante es el cambio. El valor de negocio entregado a través de software usualmente posee el peculiar rasgo de ser susceptible de indefinición y ambigüedad.
La razón es que el negocio puede tener una idea de lo que quiere, pero existen un cierto número de factores externos reales que no le van a pedir permiso para cambiar, al contrario, el negocio tiene que adaptarse o morir. Por otro lado, hay factores internos; por ejemplo, la sola presencia de una solución tecnológica para un problema X, provoca que se redefina dicho problema y sufra una especie de mutación tal que ahora tenemos un problema Y para el cual se requiere una nueva solución. Es el modelo de co-evolución solución/problema planteado ya por Frederick P. Brooks, Jr. (autor del clásico libro The Mythical Man-Month: Essays on Software Engineering) desde hace décadas.
El negocio necesita un proceso de desarrollo de software que sea capaz de seguirle el ritmo, no al revés, el negocio ajustándose a los dictados de un proceso rígido. Un proceso de desarrollo adaptativo, que mantenga una proporción razonable entre flexibilidad y disciplina y que principalmente esté enfocado en atesorar los aprendizajes sobre la marcha. Aprendizajes tanto del lado tecnológico como del lado del negocio. Uno que desde el inicio contemple que el negocio diga: “sí, eso es lo que pedimos, pero ahora queremos otra cosa y es esta...” y al mismo tiempo el grupo de desarrollo domine las técnicas de diseño para mantener una estructura limpia, estable y flexible para el software, cuyo costo de cambio no crezca exponencialmente.
Construyendo confianza
Un paradigma de programación orientada a valor de negocio tiene también como premisa que el proceso de desarrollo de software consiste en un proceso de construcción de confianza, no directamente en los individuos sino en que el proyecto de desarrollo en su conjunto —la colaboración y conjunción de personal de negocio y personal técnico— será capaz de entregar el valor de negocio en los términos requeridos.
La capacidad de entrega de valor de negocio implica tanto la capacidad del personal de negocio para escoger prioridades, especificar funcionalidad, definir criterios de aceptación, verificar funcionalidad, como la capacidad del personal técnico para crear el software que satisface lo prioritario a la fecha, sin derrochar tiempo o dilatar la entrega por estar construyendo cosas que no entregan valor de negocio hoy.
Una manera para construir dicha confianza en el proyecto es por medio de lograr y mantener un ritmo periódico de entrega de valor de negocio, el cual represente la serie de pasos con los cuales se aborda una aproximación sucesiva a lo que el negocio se va dando cuenta de lo que realmente quiere.
Conclusión:
Las conclusiones, junto con un planteamiento más extenso de esta idea de programación orientada a valor de negocio, son desarrollados en el texto de un servidor: “Beneficios sostenibles y desarrollo de software. ¿Cómo obtener beneficios sostenibles por los servicios que incluyen desarrollo de software? Parte I. El modelo adaptativo de desarrollo”, el cual está publicado en forma electrónica en la sección de artículos en línea del sitio web de SG. Los invito a que lo revisen y me hagan saber sus comentarios.
Referencias
[Kuhn, Thomas S. “La estructura de la revoluciones científicas” ISBN 9681675991]
[Denne, Mark.; Cleland-Huang, Jane. “Software by Numbers: Low-Risk, High-Return Development” ISBN 0131407287]
[Poppendieck, Mary; Poppendieck, Tom. “Implementing Lean Software Development: From Concept to Cash” ISBN 0321437381]
Acerca del Autor
Marco A. Dorantes es un consultor en el diseño y formulación de software desde 1987, oficio que lo llevó a la investigación aplicada en el campo de los métodos sistemáticos para diseño de software. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software, por ejemplo AutoTest for .Net y CppUnit for C++Builder disponibles desde www.xprogramming.com. Publica un diario electrónico en blogs.msdn.com/marcod
- Log in to post comments