Cómo obtener beneficios sostenibles por los servicios que incluyen desarrollo de software?

Transcripción

1 Negocio sostenible 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 negocio de entregar soluciones tecnológicas que incluyen desarrollo de software ha evolucionado y muchas nociones populares establecidas por tradición ya no aplican, ahora existen nuevas perspectivas en la relación entre cliente y proveedor que ofrecen oportunidades para mejorar especialmente los términos financieros del valor de negocio proyectado para ambos; ofreciendo bases más claras para cimentar mayores niveles de satisfacción del primero y mejores resultados para el negocio de servicios empresariales del segundo. Por eso, existe un número creciente de clientes en la industria que reportan experiencias superiores debidas a la adaptabilidad del proceso de desarrollo y a la demostrada capacidad del proveedor para entregar periódicamente; las estrategias de venta y entrega de los proyectos provienen del esmero por entender y por comportarse congruentemente con los valores, principios y prácticas de las nuevas perspectivas. Contenido Audiencia... 2 Objetivos... 2 Motivación... 2 Desarrollo de software en los negocios... 3 Modelo adaptativo de desarrollo y sus perspectivas financieras... 4 Definición de Unidad con valor de negocio... 4 Mejorando el ROI: Valor presente neto... 5 Mejorando el ROI: Reducción de costos y tasa de retorno constante... 8 Mitigando riesgos... 8 Reduciendo el Costo total de propiedad... 8 Estrategia para el proceso de desarrollo y entrega... 9 Conclusiones generales Nota filosófica Referencias Marco Antonio Dorantes Martínez Octubre 2008 México

2 Audiencia La audiencia principal de este artículo es la comúnmente referida como gente de negocio y por lo tanto se asume un entendimiento 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 (además de lo básico en finanzas, se recomienda entender los términos de un caso de negocio [A]). La audiencia puede encontrarse en los siguientes roles: Personas con la perspectiva del cliente o patrocinador, así como en la perspectiva de inversionista o controlador financiero. Personal a cargo de venta o entrega de servicios que incluyen desarrollo de software. Usuarios interesados en un mayor dinamismo en la entrega de los beneficios funcionales del software. Personal técnico interesado en aspectos económicos del proceso de diseño y desarrollo de software. Objetivos Resumir perspectivas clave de la creación de software cuando es parte de las soluciones de negocio. Explicar el comportamiento de los modelos financieros propuestos por las nuevas perspectivas y cómo éste puede formar parte de modernas propuestas de valor para ambos, cliente y proveedor. Mostrar los puntos clave a considerar durante la ejecución de una estrategia de venta y entrega de proyecto para que el valor de negocio proyectado sea, en efecto, realizable. Motivación El presente artículo contiene observaciones y reflexiones del autor hechas desde la perspectiva de la ejecución de diversos proyectos de desarrollo de software; pero más importante, éstas observaciones y perspectivas han sido corroboradas por su trabajo de investigación mantenido a lo largo de varios años que abarca análisis y crítica en comunidades profesionales de desarrollo de software, publicaciones personales, e indagación rigurosa sobre el trabajo de autores reconocidos como líderes de opinión y práctica. La formación profesional del autor es técnica, por lo que de antemano es oportuno advertir que las siguientes perspectivas financieras necesitan un desarrollo adicional, sin embargo, dicho desarrollo adicional tendrá mejor resultado en manos de profesionales dedicados a finanzas y negocios; a quienes se les invita: a continuar el trabajo examinando seriamente lo señalado aquí en referencia a las aportaciones y logros de otros profesionales en nuestra industria, y a adoptar las ideas que tengan el potencial de mejorar nuestro propio negocio de servicios empresariales. Negocio sostenible y desarrollo de software Página 2 de 12

3 Desarrollo de software en los negocios Un cliente al requerir una solución de negocio que incluya la creación de software hará bien en tomar en cuenta experiencias pasadas, no sólo experiencias locales sino las experiencias que reportan numerosos clientes con la misma necesidad en la industria; estos clientes reportan la necesidad de disponer de mucha más flexibilidad durante el proyecto para cambiar de opinión con base en nueva información recién confirmada en su propio ambiente de negocio y que, de haber contado con dicha flexibilidad, la solución entregada tendría el valor de negocio que en realidad se necesitaba pero que no se conocía con certeza cuando fueron establecidos los acuerdos y las especificaciones funcionales. Para cuando tomaron conciencia de esto y lograron reaccionar con procesos tradicionales, la ventana de oportunidad de negocio ya se había cerrado. Quienes crean soluciones y aplicaciones empresariales de software, han reportado repetidamente que su proceso de creación implica la necesidad de amplios espacios para el aprendizaje sobre la marcha, para el descubrimiento y evaluación de alternativas y en no pocas ocasiones para la invención y la creatividad a lo largo de todo el proceso, no solamente en las etapas iniciales. Llegar al final del esfuerzo y concluir que la solución entregada ya no es la adecuada para el negocio es un grave problema de insatisfacción para el cliente y deterioro de la relación con su proveedor. La causa raíz del problema no siempre está en alguno de los involucrados, sino en el esquema en el que ellos mismos se encajonan, uno en donde la inflexibilidad para ajustar el rumbo en el camino y la insuficiente autonomía durante el proceso creativo provocan los estragos típicos. Difícilmente alguien tendrá objeción con estas observaciones hasta que se encuentre con la necesidad de responder por sí mismo una sola vez, al principio, y para todo el proyecto: Cuánto cuesta? Cuánto tiempo? Cuál es el valor de negocio en términos financieros? Es en este punto donde se requiere toda la ayuda disponible para ofrecer respuestas atractivas para el cliente y al mismo tiempo no tropezar con un estado de negación donde la naturaleza del proceso de creación de software se trivialice tal que sin dolo y sin conciencia se incurra desde la apertura del proyecto en un esquema para el perjuicio de alguno o todos los involucrados. Asumiendo como inmutable la condición de responder de esa forma una sola vez, al principio, y para todo el proyecto a las preguntas mencionadas, los clientes creen que el costo fijo es una técnica asequible para mitigar los riesgos. La justificación, en ocasiones, está basada en una propuesta de valor de negocio que proyecta un comportamiento idealizado de la creación del software pero que, aun con suficientes colchones y trade-offs, no refleja lo que en realidad sucede cuando se lleva a cabo. El cliente se encontrará entonces en la situación donde, aspirando a obtener una solución que en realidad le sirva, debe hacer las solicitudes de cambio necesarias. De hecho, los clientes se percatan que no pocos proveedores toman ventaja al cobrar por cada solicitud de cambio pues por experiencia saben que habrá un número considerable de éstas. Entonces, los proveedores que promueven el así llamado control de cambios en realidad inician la negociación con el cliente desde una posición en desventaja con respecto a otros proveedores más creativos o actualizados, quienes evitan la percepción o realidad de querer tomar ventaja de la situación a costa del negocio del cliente. Negocio sostenible y desarrollo de software Página 3 de 12

4 En el otro extremo está el esquema por tiempo y materiales, permite mayor flexibilidad pero los abusos le han dado mala fama entre algunos clientes. Los escenarios con proveedores oportunistas que practican sistemáticamente la dilación, resultando en deterioros irreversibles para el negocio del cliente, han fundamentado los riesgos. Así mismo, por supuesto, el comportamiento de algunos clientes al dilatar los pagos puede causar serios daños al negocio de sus proveedores. Los retos a los que nos enfrentamos no son inéditos. Irónicamente, en industrias cuyos productos están hechos de materiales que no cuentan con la maleabilidad inherente al software como la industria moderna de manufactura, e.g., Toyota [1, 2] han enfrentado exitosamente retos similares, adoptando valores, principios y prácticas que ofrecen la flexibilidad para el negocio y la autonomía para los creadores, necesarias no sólo para mantener sino aun para mejorar el valor de negocio obtenido para sus inversionistas. Entre los aprendizajes esenciales que se pueden desprender de esas experiencias, hay dos en particular que son esenciales para el tema que nos ocupa: Primero, los ingredientes que han aportado significativamente hacia el valor de negocio en proyectos donde el desarrollo de software está presente coinciden con los de oficios de naturaleza intelectual y no con los de naturaleza mecánica; típicamente pertenecen a alguno de los siguientes tipos de enfoque: resolución de problemas, creatividad, ejecución táctica [3]. Estos, combinados con un balance entre confianza, autonomía y claridad como rasgos dominantes entre los miembros del grupo de proyecto (que incluye al cliente por supuesto), ayudan a formar una brigada de profesionales de alto desempeño que según muchos conocedores es la fuerza más poderosa en desarrollo de software [4]. Segundo, crear propuestas basadas en el potencial del punto anterior, con un modelo financiero que proyecte el comportamiento del proceso desarrollo de software cuando lo que se maximiza es el valor de negocio. De esa manera, el negocio en su totalidad estará alineado y sustentado por no en contra de las reglas conocidas en los oficios de naturaleza intelectual como lo es la creación de software. A continuación se presentan las perspectivas de un modelo adaptativo de desarrollo para considerarse al elaborar un modelo financiero que ayude a sustentar mejores propuestas con valor de negocio. Modelo adaptativo de desarrollo y sus perspectivas financieras Definición de Unidad con valor de negocio Una premisa para el siguiente modelo consiste en que se pueden identificar unidades de funcionalidad discretas e independientes que representen valor de negocio para el cliente y se les puede asignar una prioridad por sí mismas. Una unidad tiene un tamaño máximo igual a lo que se pueda desarrollar a grado de ambiente productivo en un periodo no mayor a un mes calendario, incluyendo toda su documentación y entregables asociados. Una unidad podría ser descompuesta en unidades más básicas siempre y cuando cada una mantenga sus propiedades de unidad con valor de negocio (el concepto aquí presentado es similar al concepto Capacidad autónoma de negocio por Roger Sessions [B]). Negocio sostenible y desarrollo de software Página 4 de 12

5 Importante: una tarea completada durante el proyecto no es igual a una unidad con valor de negocio. El valor para una unidad empieza a contar a partir de que los responsables de la perspectiva de negocio la hayan identificado como tal y le hayan asignado prioridad. De otro modo, si el valor se mide en términos de tareas completadas estaríamos confundiendo esfuerzo por progreso. Además, si se mide por tareas completadas se provoca que las tareas más fáciles se realicen primero, aumentando el riesgo de que dicho esfuerzo se derroche si el valor de negocio asociado a esas tareas no tiene prioridad identificada. Por tanto, decir tenemos completo el 90% del análisis ó alcanzamos el 80% del desarrollo podría en lo absoluto carecer de significado en términos de valor de negocio. Mejorando el ROI: Valor presente neto Contar con un peso hoy, vale más que contar con el mismo peso en un futuro; un beneficio ganado hoy vale más que el mismo beneficio ganado más tarde. La métrica financiera llamada Valor presente neto nos indica el costo del dinero en inversión conforme transcurre el tiempo. Por tanto, entre más rápido se alcance el Punto de equilibrio, mayores los beneficios. (Figura 1.) Una lista de unidades con valor de negocio en orden de prioridad es el combustible que alimenta al proceso de desarrollo de software. La lista de unidades con valor de negocio no tiene que estar completa; de hecho, intentar concebir todas Figura 1. Punto de equilibrio de una inversión es una trampa muy común que causa derroche al restar atención del valor de negocio confirmado hoy por dársela al fútil intento de conseguir un imposible. La realidad nos dice que el cliente no sabe qué es lo que quiere, por tanto, el cliente no tiene que saber todo lo que quiere en un solo punto en el tiempo usualmente al principio, precisamente cuanto menos sabe acerca de lo que quiere y pedírselo es irreal. La realidad también nos dice que el cliente no sabe ni la mitad de lo que quiere, tal vez sepa una cuarta parte, pero lo que sí sabe con certeza es que dentro de esa cuarta parte están las unidades de valor más prioritarias para el negocio en el presente; del resto, a lo mucho tiene conocimiento especulativo [5]. La cuarta parte quizá una fracción menor de las unidades de valor con prioridad de negocio alta y con mayor certidumbre, ofrecen la oportunidad de acercar el Punto de equilibrio en el tiempo por medio de concentrarse en la entrega únicamente de esa fracción y empezar a cosechar los beneficios asociados tempranamente, al mismo tiempo que el desarrollo de las subsecuentes fracciones continua (Figura 2). Negocio sostenible y desarrollo de software Página 5 de 12

6 Figura 3. Valor presente neto mejorado Figura 2. Costos y beneficios en el tiempo por unidad con valor de negocio entregada Una excelente ventaja asociada a enfocarse sólo en la fracción más prioritaria de la solución a la fecha consiste en que se abren los espacios necesarios para hacer ajustes con base en nueva información confirmada durante el trecho recién recorrido. Es decir, por explorar de principio a fin cada fracción aprendemos más del ambiente de negocio, de las posibilidades tecnológicas, y damos espacio para que el ambiente externo cambie cuanto quiera sin exponer el proyecto peligrosamente a los riesgos asociados; dejándonos cada vez en una posición óptima donde nuevamente se puedan confirmar las prioridades con más claridad y mucho menor especulación para la siguiente fracción de la solución; además, el proyecto va avanzando con referencia a la situación hacia donde el cliente está aprendiendo que realmente quiere llegar. De esta manera, cada punto de entrega suma beneficios expeditamente al acumulado total; además, permite monitorear la satisfacción del cliente ofreciendo la posibilidad de hacer adaptaciones oportunas. El Valor presente neto mejora con cada entrega de unidades con valor de negocio debido a que los beneficios inyectados a la organización disminuyen el acumulado de Negocio sostenible y desarrollo de software Página 6 de 12

7 costos a la fecha. Los beneficios para el proveedor también son evidentes por el ingreso adelantado de la facturación correspondiente al punto de entrega. Esto describe el Rendimiento de la inversión y la salud del proyecto actualizados, y representa un excelente punto de inicio para el siguiente ciclo de entrega que abarcará la subsecuente fracción en la lista de unidades de valor, ordenada por prioridad de negocio. El resultado global es un Valor presente neto mejorado en comparación con el correspondiente de un proyecto con una sola y única entrega (Figura 3); además, por supuesto, de una mayor satisfacción del cliente y una mayor frecuencia de facturación de ganancias por parte del proveedor. Lateralmente, se produce un efecto de mayor envergadura: el aprendizaje continuo del dinámico término valor de negocio. Dicho proceso se ilustra en la siguiente figura y se conoce como el modelo adaptativo para desarrollo de software. Figura 4. Aprendizaje continuo del valor de negocio en el modelo adaptativo Negocio sostenible y desarrollo de software Página 7 de 12

8 Mejorando el ROI: Reducción de costos y tasa de retorno constante El modelo adaptativo de desarrollo ofrece beneficios aun en un esquema de costo fijo por medio de la reducción de costos producto de la entrega de beneficios más rápida y más constantemente, de ahí, una tasa constante de retorno. Mitigar los riesgos del proyecto por defectos o bugs agrega costos, el modelo adaptativo ayuda a disminuirlos en las siguientes maneras: (a) previniendo que los defectos crezcan al permitir el aprendizaje constante y hacer los ajustes sobre la marcha, (b) ofreciendo un sistema con capacidad funcional probada y creciente en cada punto de entrega, y (c) evitando la complejidad innecesaria al no considerar las unidades de valor que aún no han sido elegidas para entrega [2]. De esta forma se disminuye la brecha que hay entre el momento en que es insertado un defecto, el momento en que es descubierto y el momento en que es corregido; está bien documentada [3] la diferencia exponencial de costo entre más grande sea la brecha entre estos momentos. Una creencia muy generalizada, debido en parte al concepto de división de trabajo en procesos antiguos de manufactura con trabajos puramente mecánicos, consiste en que entre más personas estén trabajando en paralelo, más eficiente estamos siendo: si con dos desarrolladores lo acabo en dos meses, con cuatro lo acabo en un mes!. Sin embargo, también está extensamente documentado que para el caso del trabajo intelectual, lo contrario es más cierto: el grupo de desarrollo trabaja más eficientemente con menos paralelismo; esto se debe, en esencia, a dos causas. Primero, el trabajo intermedio representa un pasivo hasta ser completado al punto de convertirse en valor de negocio, así que se debe disminuir el trabajo en estado intermedio en lugar de aumentarlo [7, 8]. Segundo, los costos por interacción entre personas, a mayor número de personas mayor número de líneas de interacción. De ahí que los grupos pequeños en este oficio pueden con la educación adecuada hacer más con menos costos por personal [9]. Mitigando riesgos Además de la reducción de costos por mitigación de riesgos mencionada anteriormente, el modelo adaptativo de desarrollo permite abordar la mitigación de riesgos con más efectividad al requerir un enfoque continuo en el valor de negocio, la disminución de complejidad interna del software, la disminución del trabajo intermedio que podría nunca llegar a convertirse en activo de negocio, la constante información disponible para responder a En dónde estamos con respecto a nuestro objetivo?, y un patrón sostenido de entregas que fundamentan una creciente confianza del cliente y usuarios, hacen de este modelo uno con mejores propiedades de predictibilidad que otros modelos tradicionales. Reduciendo el Costo total de propiedad Otra creencia curiosa que también es muy popular consiste en considerar que la mayor parte del trabajo intelectual interesante en desarrollo de software sucede únicamente durante la creación inicial del mismo y que posteriormente sólo resta trabajo tedioso de mantenimiento. Pero, por el contrario, durante esta etapa también se presentan desafíos que requieren un esfuerzo intelectual similar o tal vez mayor al inicial para abordar los cambios en requerimientos, cambios por la detección de defectos, cambios en la tecnología, etcétera, y al Negocio sostenible y desarrollo de software Página 8 de 12

9 mismo tiempo conservar la estabilidad del software evitando que el costo del cambio paralice la cadena de valor de negocio entregada por el software. Un cambio importante ocurre en el modelo financiero de la inversión una vez que el software empieza a entregar los beneficios proyectados al negocio, de métricas de Retorno de inversión a métricas de Costo total de propiedad. Un buen trabajo de diseño y arquitectura entrega sus frutos precisamente en este punto pues si el software está aprovisionado para aceptar cambios de forma sostenible, es decir, sin incrementar desproporcionadamente el esfuerzo por introducir dichos cambios, entonces el costo del software permanecerá en umbrales similares durante su vida útil. Por el contrario, si el esfuerzo para lograr que el software siga el ritmo de la dinámica del negocio se hace incosteable a tal grado que incluso hacer un nuevo sistema substituto es más económico significa que el trabajo original de diseño y arquitectura necesitaba estar más enfocado a la dinámica realidad del negocio y no basarse en la creencia referida al inicio de esta sección, por la cual el trabajo de diseño y arquitectura está ausente precisamente cuando es más necesario. El modelo adaptativo, en contraste con modelos tradicionales, busca llevar al software lo más pronto posible a esa así llamada etapa de mantenimiento y traslada el grueso de la capacidad de diseño y arquitectura precisamente ahí, donde la brecha entre el momento de las decisiones de diseño y el momento de confirmar las consecuencias de dichas decisiones todavía es reducida y no existe una miríada de decisiones subsecuentes que impiden su modificación. De esa manera, el cambio forma parte habitual del ciclo de vida del software y crea la provisión que ampara un Costo total de propiedad en umbrales sostenibles [6]. En este modelo, la transición de software en desarrollo a software liberado no implica, en realidad, cambios drásticos en el ritmo y naturaleza del trabajo a su alrededor, como se verá ilustrado en la siguiente sección de estrategias para el proceso de desarrollo. Estrategia para el proceso de desarrollo y entrega La definición de Unidad con valor de negocio describió, lo que podría denominarse, la moneda de cambio para las transacciones en el proceso creativo del software. Por motivos de espacio, a continuación describimos únicamente la estrategia genérica para la evolución de las unidades de valor, ésta representa la piedra angular sobre la que se sustenta el modelo adaptativo de desarrollo y que sostiene el modelo económico planteado. Una sección posterior ofrece referencias para que los interesados puedan ahondar en más detalles de modelos financieros completos o los pormenores del carácter iterativo e incremental del modelo adaptativo para desarrollo y entrega de software. Negocio sostenible y desarrollo de software Página 9 de 12

10 La siguiente figura ofrece una perspectiva de las propiedades esenciales en la evolución del desarrollo de una unidad con valor de negocio. Los bloques en serie representan unidades con valor de negocio que forman parte de una agrupación representada por el bloque mayor que las contiene. Un ejemplo de agrupación en una aplicación podría corresponder a Registrar producto en el carrito de compra. Mientras que las unidades agrupadas serían variantes del mismo flujo como Registrar producto en promoción o también Registrar producto de temporada. Cada unidad representa una manera particular de interacción con el sistema que da como resultado algo que se considera de valor en el dominio de la aplicación de negocio. El enfoque del desarrollo procede como si cada unidad de valor fuera un corte vertical de la totalidad de la solución, donde cada rebanada es una función de negocio completa con toda la calidad y nivel de utilidad necesaria para ser puesta en producción si así se decidiera. El calendario de proyecto se divide en iteraciones (bloques verticales en la figura), cada una entrega el siguiente subconjunto prioritario de unidades con valor de negocio. Las actividades para hacer especificación funcional, diseño, integración, validación y verificación, suceden en cada iteración, por lo que no son etapas de un proyecto según la tradición popular sino acciones que ocurren por demanda simultáneamente. Las unidades de valor se añaden, conforme transcurre el tiempo, al todo de la solución; la cual crece digamos, orgánicamente en capacidad funcional acumulada a un ritmo constante, tal que, en un momento arbitrario se puede nombrar versión 0.5 al estado actual de la solución y ser liberada internamente para revisión como una versión candidato a liberación pública. De esa manera, se designa como versión 1.0 al estado de la solución que contiene lo previsto para ser visible a sus usuarios en el ambiente de producción. Para versiones posteriores, el proceso y el ritmo de desarrollo de hecho continúan intactos, ya sea para agregar las siguientes unidades de valor en la lista por prioridad o para incorporar cambios a las existentes. Esto es el aspecto incremental del modelo adaptativo de desarrollo. Conclusiones generales Qué puede uno llevarse de todo esto? Para el cliente, patrocinador o inversionista que requiere software a la medida desde un conjunto de reportes hasta los múltiples sistemas detrás de una arquitectura empresarial orientada a servicios, su siguiente inversión o esfuerzo en software aplicativo tiene más oportunidad de traducirse en un aumentado valor de negocio si solicita propuestas basadas en el modelo aquí planteado y con igual importancia si está Negocio sostenible y desarrollo de software Página 10 de 12

11 dispuesto a adueñarse de una nueva educación con derechos y obligaciones diferentes a las nociones tradicionales. Para vendedores de servicios profesionales, el modelo adaptativo aporta elementos adicionales a las propuestas de valor de negocio que pueden llegar a ser más atractivas para los clientes. Además, el modelo adaptativo procura un ritmo de facturación más expedito. Para gerentes de proyecto, en la constante búsqueda por la satisfacción del cliente el modelo adaptativo ofrece principios y prácticas para cimentar la confianza mutua que sostiene relaciones de largo plazo entre organizaciones. También, la ejecución del proyecto se sucede a pasos más firmes y constantes. Para el arquitecto o desarrollador, una manera para ejercer el derecho a únicamente crear software de calidad al mismo tiempo que tener una vida balanceada, es tomando en serio los valores, principios y prácticas del modelo adaptativo de desarrollo. Así, no sólo se puede estar orgulloso de respaldar con tu nombre el tipo de software que liberas, sino que se pueden realizar proyectos capaces de transformar organizaciones en su totalidad. Hay mucho, mucho más material qué exponer y discutir acerca del modelo adaptativo de desarrollo de software desde un punto de vista de negocios. Por ejemplo, las técnicas de estimación así como los diferentes tipos de contrato que ya han sido utilizados en la industria y que como escala de gris varían entre costo fijo y tiempo-materiales, son temas por mucho interesantes, pero los dejaremos para una siguiente oportunidad. Nota filosófica Por favor nótese que el título del presente artículo tiene forma de pregunta pues no pretende ofrecer una respuesta tajante que prometa eximirnos de cualquier esfuerzo adicional en éste tan demandante tema de la creación de tecnología de software como solución para problemas de negocio. Si la pregunta sugerida y el planteamiento del presente artículo nos ayudan a continuar con la reflexión y la perpetua búsqueda de la respuesta considerando los hallazgos de la industria aquí presentados entonces habrá cumplido su objetivo esencial de aportar un atisbo hacia dónde puede encontrarse dicha respuesta. Referencias [1] The Toyota Production System: Beyond Large-Scale Production. Taiichi Ohno. Productivity Press, Originalmente publicado en Japonés en [2] The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster. Ward, Allen, Jeffrey K. Liker, John J. Cristaino, and Durward K. Sobek, II. Sloan Management Review 36(3): Spring 1995, [3] Rapid Development - Taming Wild Software Schedules. Steve McConnell. ISBN: Negocio sostenible y desarrollo de software Página 11 de 12

12 [4] Artful Making - What Managers Need to Know About How Artists Work. Robert Austin, Lee Devin. ISBN: [5] Software Requirements, 2 nd Edition. Karl E. Wiegers. ISBN-13: [6] Software by Numbers: Low-Risk, High-Return Development. Mark Denne, Jane Cleland- Huang. ISBN: [7] Implementing Lean Software Development: From Concept to Cash. Mary Poppendieck, Tom Poppendieck. ISBN: [8] Lean Software Development: An Agile Toolkit. Mary Poppendieck, Tom Poppendieck. ISBN: [9] The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Frederick P. Brooks Jr. ISBN: [A] Making the Software Business Case: Improvement by the Numbers. Donald J. Reifer.ISBN- 13: [B] Simple Architectures for Complex Enterprises. Roger Sessions. ISBN: [C] Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. David J. Anderson, Eli Schragenheim. ISBN: [D] Software Measurement and Estimation: A Practical Approach. M. Carol Brennan, Linda M. Laird. ISBN: [E] The Business Case for Agility. Alan Shalloway Net Objectives. [F] Applied Software Measurement. Capers Jones. ISBN [G] Agile Software Development: The Cooperative Game, 2 nd Edition. Alistair Cockburn. ISBN: [H] Optional Scope Contracts. Kent Beck, Dave Cleal [I] Economics of XP. William C. Wake [J] Agile Fixed Price Projects. Pascal Van Cauwenberghe Nayima [K] Exploring requirements - Quality before design. Donald C. Gause, Gerald M. Weinberg. ISBN Negocio sostenible y desarrollo de software Página 12 de 12