DSN_XP y los escenarios

 Metodología de escenarios

Escenario es el espacio/tiempo donde se presenta la acción

DSN_XP llega a reconocer como artefacto al concepto de escenario cuando comenzamos a profundizar en el modelado avanzado de casos de uso.

Este es un texto que tomamos de referencia del estudio de Alexandra C. Cely

Revista Ingeniería e Investigación Nº. 44 Diciembre 1999

Modelado Avanzado

Existen diferentes formas de aproximarse al futuro, siendo la prospectiva la única que lo aborda como una realidad múltiple e indeterminada, obtenida como resultado de las infinitas posibilidades de acción humana, reflejada en los diferentes proyectos (acciones concretas), anhelos y temores de los grupos sociales. Para desarrollar estudios de prospectiva existen diferentes metodologías entre las que se encuentra la de escenarios, cuyo uso se ha venido generalizando durante los últimos diez años gracias a la claridad en la presentación de los resultados y a la articulación de los mismos con la intencionalidad de la acción humana.

Nociones de tiempo futuro

DSN_XP resalta un patrón de comportamiento en las investigaciones realizadas sobre los factores que apoyan al proceso creativo de modelar y diseñar software como solución tecnológica, el patrón está relacionado con la noción del tiempo y de forma especial con la necesidad de proyectarse a futuro para conocimiento prospectivo.

Desde el principio de la civilización, la especie humana ha intentado acercarse al futuro de diferentes maneras utilizando la magia, las artes adivinatorias, los oráculos y finalmente la proyección matemática y la extrapolación de tendencias. Al avanzar el tiempo, la concepción y del futuro cambia como reflejo de los cambios realizados en la humanidad, así se ha conceptuado este espacio-tiempo ya no solo como una realidad única, sino que, se la considera actualmente como múltiple e indeterminado.

La nueva "manera de abordar el futuro" surgida de este cambio de mentalidad, es la prospectiva, cuya premisa principal se basa en que el futuro no sucede ciegamente, sino que depende de la acción del hombre. Por esta razón, la prospectiva se convierte en una herramienta fundamental de planeación, que además de dilucidar el futuro, permite orientar las acciones humanas que conducirán a la realización del mismo.

La metodología de escenarios se diseñó inicialmente utilizando los conceptos del análisis de sistemas, nacido en los Estado Unidos durante los años cincuenta y sesenta, posteriormente, dicha metodología demostró ser la mejor forma de expresar los resultados de un ejercicio prospectivo.

Un modelo de escenarios posee tres aspectos fundamentales:

1. Analizar el fenómeno en estudio, desde un punto de vista retrospectivo y actual.
2. Analizar la influencia de los grupos sociales que son gestores del desarrollo del fenómeno así como de los factores de cambio.
3. Presentar los resultados finales en forma de escenarios.

Definiciones

• Escenario: constituye la descripción de un futuro posible y de la forma de alcanzarlo.
• Escenarios Posibles: son todos aquellos escenarios que se puedan imaginar sin importar si su probabilidad de ocurrencia es alta o baja .
• Escenarios Realizables: son los escenarios cuya ocurrencia es factible, teniendo en cuenta todas las restricciones del sistema.
• Escenarios Deseables: son los escenarios a los que los actores desean llegar, también pueden ser calificados como los escenarios más convenientes. Forman parte de los escenarios posibles y no necesariamente son realizables.
• Sistema: el sistema es el conjunto de elementos cuya interacción genera nuevas cualidades que no poseen sus componentes a nivel individual y, por tanto, se debe estudiar como un todo. De esta forma, las partes son explicadas en términos del todo. Dentro de la metodología prospectiva, el sistema está constituido por el fenómeno, área o tema en estudio y su entorno explicativo; éste involucra factores políticos, demográficos, políticos, económicos, industriales, sociales, tecnológicos, etc.
• Actores: son todas las personas que pueden influir significativamente sobre el sistema mediante la toma de decisiones o la realización de proyectos. Son los gestores del desarrollo y pueden pertenecer a cuatro grandes grupos:
• El poder: organismos del estado
• La producción: sector industrial
• El saber: entidades que generan conocimiento, universidades, etc.
• La comunidad: beneficiarios de los productos o servicios.
• Variables: también denominados factores de cambio, son fenómenos que orientan la evolución o mutación del sistema en estudio. Pueden ser de orden económico, social, político, cultural, administrativo, científico, tecnológico, ambiental, jurídico, etc. Estos factores de cambio se perciben como proyectos, tendencias, gérmenes de cambio, temores y problemas de cada uno de los actores.
• Anhelo: es la Intención que tiene un actor de hacer algo que solucione un problema concreto en un sector determinado.
• Invariante: fenómeno que se supone permanente, más no constante en cuanto a sus características y/o magnitud, hasta el horizonte de tiempo estudiado.
• Gérmenes de futuro: factores de cambio escasamente perceptibles hoy, pero que constituirán las tendencias dominantes del mañana; también se denominan hechos portadores de futuro.
• Conflicto: es una relación que se establece entre dos o más actores que presenten posiciones antagónicas frente a una misma variable. Esta disfunción también se denomina ruptura de tendencias.
• Alianza: es una relación que se establece entre dos o más actores que presenten posiciones coincidentes respecto a una variable del sistema.
• Evento: es una solución concreta a un problema determinado, cuya única característica radica en su ocurrencia o no.
• Experto: son aquellas personas que conocen a profundidad el sistema en estudio o parte de él y que generalmente pertenecen a alguno de los actores.

Fases y objetivos del método

La metodología de escenarios posee tres objetivos fundamentales, los cuales deben desarrollarse a cabalidad; dichos objetivos son:

• Descubrir y vincular las variables claves que caracterizan al sistema en estudio mediante un análisis explicativo global.
• Determinar a partir de las variables clave, los actores fundamentales y los medios de que disponen para concretar sus proyectos.
• Describir, en forma de escenarios, la posible evolución del sistema en estudio a partir de la observación y análisis de las variables claves y de los comportamientos de los actores, respecto a un juego de hipótesis.

Para lograr estos objetivos, la metodología de escenarios se desarrolla en dos fases principales: la construcción de la base analítica y la elaboración de los escenarios.

Construcción de la base analítica

En esta primera fase se pretende realizar una imagen de la situación actual del sistema y su entorno.  Incluye la delimitación del sistema, el análisis de influencia y subordinación de las variables claves o fundamentales y la descripción actual del sistema.

Inicialmente se elabora una lista completa de las variables que influyen sobre el sistema y que deben ser atendidas sin importar si pueden ser cuantificables o no. El propósito es obtener una visión global del sistema y su entorno consiguiéndose así, una definición bastante precisa del mismo.

• Listado de variables (entrevistas, expertos, etc.)
• Análisis de dependencia, influencia, relación entre las variables y su jerarquización de acuerdo a niveles de impacto y profundidad.
• Análisis estructural
• Análisis de situación actual y los gérmenes de cambio y estrategia de actores.
• Construcción de un cuadro de estrategias de los actores, síntesis del análisis de situación actual, retos a futuro.

Nota: se deben tomar en cuenta datos cualitativos como factores económicos, sociológicos, políticos, ecológicos, etc. Deberá considerarse el uso del método de análisis del juego de actores.

Elaboración de escenarios

Una vez obtenidos los resultados de las fases anteriores se procede a la elaboración de hipótesis y la obtención de los escenarios, tal como la figura.

Esto se logra mediante la formulación de hipótesis, las cuales dirigen los escenarios.  Estos escenarios deben estar dimensionados en términos de sus componentes esenciales y pueden ser de tipo demográfico, técnicos, social, político, económico, etc.

Dado que algunos elementos del sistema, tales como el resultado de los posibles conflictos entre actores, son inciertos en el futuro del mismo; se deben formular hipótesis sobre la evolución de tendencias y sobre dichos elementos inciertos.  De esta forma, a cada juego de hipótesis le corresponderá un escenario que se puede construir y cuya realización es más o menos probable.

DSN_XP y la experimentación

 La experimentación en DSN_XP

Experimentación base

Un principio del método que dirige el proceso de diseño para DSN_XP radica en la experimentación con el modelo que fue diseñado para poder abstraer un contexto de usabilidad.

Experimentación

Nuestro contexto de experimentación, está íntimamente relacionado con el proceso de codificación y la racionalización mediante la algoritmia, para efectos de lograr crear una solución como sistema, utilizando los principios de cálculo y de modelado que el lenguaje de programación lo permita.

Fue la experimentación la única forma que encontramos para lograr desarrollar nuestras habilidades de programación, ya que no todos teníamos acceso al hardware necesario para un aprendizaje continuo.  

Debido a que, los programas que codificábamos eran sencillos en base a nuestra limitada comprensión de la semántica que se sujetaba al lenguaje de programación escogido para el efecto.

Parte del proceso de aprendizaje radica en la observación del código realizado por una fuente de conocimiento que estudiamos (tutor o libros o videos u observaciones al proceso de codificar de un tercero), por ello, es nativo para DSN_XP el pensamiento inverso o la capacidad de leer código de terceros para efectos de establecer un modelo de solución a problemas específicos por experimentación.

Prototipar

DSN_XP entiende por prototipar justamente al concepto que deseamos expresar como experimentación, ya que parte de la comprensión del lenguaje de programación radicaba justamente en trabajar con las ventajas que determinan la usabilidad de un lenguaje de programación, esto es programar una abstracción y la capacidad del dominio de la sintaxis del lenguaje de programación.

Ahora bien, el prototipado para nosotros podía tener varios contextos de uso y uno de ellos era justamente el utilizar el lenguaje de programación para generar una secuencia de eventos y así lograr un comportamiento por parte del sistema programado.

DSN_XP y el PETI

 El proceso de planificación

Componentes del Plan y su estrategia

Este es solo un referente del proceso de planificación que puede desarrollarse para lograr armar un PETI o Plan Estratégico de los Sistemas de Información (SI) dentro de las Tecnologías de Información (TI).

Componentes de planificación

¿Cuáles son los componentes básicos de un plan estratégico? Aunque el plan estratégico de los sistemas de información SI difiere de un plan de negocios en muchos aspectos, existen varios conceptos a tener en cuenta:

• Identificación de dónde se encuentra hoy: evalúe el entorno para responder la pregunta, ¿Dónde estamos ahora?, en un plan estratégico de SI, esto incluye el mirar interna y externamente desde la perspectiva tanto del negocio como de los SI. Una vista externa responderá a la preguntas ¿Qué es posible?, y ¿Cuáles son las mejores prácticas? Debido a que la empresa debe impulsar SI, debe entonces comprender a fondo los objetivos y desafíos comerciales, además de donde se encuentran los sistemas de información actualmente.
• Identificación de dónde quiere estar en el futuro: a través del proceso de planificación, se puede desarrollar la visión y la estrategia para responder a la pregunta ¿Dónde queremos estar? En un plan estratégico de SI, responda la pregunta desde una perspectiva empresarial y de los SI.  La dirección a futuro debe ser el principal determinante en el establecimiento de la dirección  de los SI.

La CEPAL en su documento titulado “Planificación estratégica e indicadores de desempeño en el sector público”, define la Planeación Estratégica, PE, como “una herramienta de gestión que permite apoyar la toma de decisiones de las organizaciones en torno al quehacer actual y al camino que deben recorrer en el futuro para adecuarse a los cambios y a las demandas que les impone el entorno y lograr la mayor eficiencia, eficacia y calidad en los bienes y servicios que se proveen. 

Desde el punto de vista metodológico, la planificación estratégica consiste en un ejercicio de formulación y establecimiento de objetivos de carácter prioritario, cuya característica principal es el establecimiento de los cursos de acción (estrategia) para alcanzar dichos objetivos. Desde esta perspectiva la PE es una herramienta clave para la toma de decisiones de las instituciones públicas

DSN_XP y la documentación técnica

Modelado avanzado 

Esta sección está destinada a explicar los diversos modelos y artefactos adoptados por DSN_XP para la documentación de proyectos, el modelado ágil para el desarrollo de software y el modelado de procesos del negocio.

El arte de modelar ideas o documentación

La arquitectura documental surge como una importante práctica relacionada a la arquitectura. En el 2002, investigadores de Carnegie Mellon Software Engineering Institute completaron la investigación "Documenting Software Architectures: Views and Beyond".

Un enfoque que sostiene que documentar una arquitectura software consiste en configurar perspectivas relevantes de la arquitectura, documentando cada una de estas perspectivas y documentando información que aplica a más de una perspectiva del total de perspectivas disponibles.

DSN_XP y Lean Inception

 Lean Inception

DSN_XP adopta como artefacto para la planificación de esfuerzos, a la noción de INCEPTION como aquel primer esfuerzo realizado en el proceso creativo de diseño de soluciones a necesidades mediante un producto o un proyecto.

Inception

Puede ser traducida como "comienzo" y es la etapa inicial que propone RUP para abordar un proyecto de desarrollo conforme al entendimiento mutuo de las partes por los objetivos y metas a ser alcanzados mediante un esfuerzo continuo en una  jornada de tiempo.

Ahora bien, RUP propone en su método de gestión de proyectos, 4 fases base para efectos de completar un ciclo y en base a la repetición del ciclo lograr abordar de forma incremental los diversos criterios necesarios para definir una arquitectura de software que pueda satisfacer las demandas esperadas del desarrollo de un proyecto para la entrega de un producto funcionando en base a la ingeniería del software.

Esquema estratégico de RUP por fases

Adoptamos el modelo de gestión de proyectos de TI propuesto por RUP para poder negociar con terceros el esfuerzo requerido para comprender la industria y la problemática del cliente y con ello poder realizar una aproximación al esfuerzo que puede ser encapsulado en una propuesta comercial, aunque el producto final no sea software o una solución basada en la ingeniería del software.

RUP como propuesta del proceso de un producto

DSN_XP en su versión 1.0 solo podía cubrir las etapas de diseño y análisis requeridas para desarrollar una tesis de grado que implique la ingeniería de software, como tal, estas fases debían ser sintetizadas y adoptadas como propuesta para el reglamento del régimen académico.

Adicionalmente, se requería adoptar UML como la herramienta de modelado que permitiría sintetizar la documentación requerida o una gran cantidad de texto que sería referido como marco teórico para efectos de plantear el modelo de gestión para el desarrollo del producto de tesis mediante las recomendaciones de un método de desarrollo reconocido en el mercado ecuatoriano.

Tomamos prestado entonces el esquema planteado y decidimos adoptar el enfoque LEAN para lograr controlar nuestra capacidad productiva durante una iteración en una jornada de tiempo corta para el desarrollo de soluciones en base a la experimentación.

Dicho esto, los flujos de trabajo que dan soporte a la propuesta INCEPTION y su configuración son:

• Estudio del entorno de desarrollo dependiente de la capacidad del cliente y su participación en la industria.
• Planteamiento de un esquema para la gestión del proyecto que determinará la propuesta comercial a ser revisada por el cliente.
• La capacidad de delimitar al mínimo la gestión de cambios desde el cliente cuando no existe una visión profunda aceptada por las partes.

Ahora bien el proceso de desarrollo del producto o servicio requiere analizar las siguientes disciplinas, a saber:

• Modelado del negocio y su cadena de valor para comprender su capacidad productiva.
• Entendimiento de los requerimientos que configuran la negociación por entregables cubierta por la propuesta comercial.
• Análisis y diseño base de la arquitectura inicial que dará soporte a todo el proceso productivo a ser implementado en fases posteriores.
• Definición de los criterios de implementación y las pruebas de su acoplamiento.
• Desarrollo de informes sobre el esfuerzo realizado durante la jornada contratada.

DSN_XP y el pensamiento basado en DATA

 El desarrollo de software y la DATA

Perspectiva orientada a los datos como tipo y estructura

DSN_XP considera esta entrada como el principio de una serie de análisis que re realizan a los componentes pilares de la industria del software y su desarrollo.

Referente al artículo:

¿Desarrollo orientado a procesos u orientado a datos? 

Breogán Gonda.

Tercera Generación

Honeywell H200 (Tercera generación)

La historia refleja que es a partir de 1963 que los fabricantes de (software/hardware) comenzaron a pensar que empresas normales podrían beneficiarse del uso de las informática (restringida a enormes proyectos de carácter estratégico y asociados usualmente a temas de militares)

¿Qué trajo consigo esta tercera generación?, algo que es importante rescatar y que tendría que ver en un tiempo después con temas de documentación, madurez organizacional y su cultura y que se trata de la "formalidad" que motivará la estandarización o compatibilidad más tarde y por ende, a la lucha de un nuevo mercado naciente para la industria del software de la mano con los procesos tecnológicos de control y la automatización mediante los circuitos integrados y finalmente, un nuevo elemento en dicha cultura aparece y se trata de la DATA y su tecnología aplicada para los objetivos del negocio.

La formalización se considera una perspectiva adicional e independiente del hardware y de los conceptos del software y del sistema operativo en general y de lenguajes de programación estándares particularmente que ya existían pero que recientemente se  aplicarían para el diseño de aplicaciones.

Almacenamiento integrado de datos

Bachman y el sistema integrado de datos

Al crear el Integrated Data Store (IDS) y defender enérgicamente los conceptos subyacentes, Charles W. Bachman tuvo una influencia única en el establecimiento del concepto del sistema de gestión de bases de datos. Durante una carrera larga y variada, dirigió una planta química, creó sistemas de contabilidad de costos de capital, dirigió un grupo de procesamiento de datos temprano, fue pionero en la aplicación de computadoras al control de fabricación, dirigió esfuerzos para estandarizar los conceptos de bases de datos y comunicación por computadora, ganó el más alto honor en computación ciencia y fundó una empresa que cotiza en bolsa.

DSN_XP en su proceso investigativo de las escuelas de diseño y métodos de desarrollo de software, desde las actividades requeridas para la codificación, encontró que la DATA como estructura mental, se desprende tanto de la practicidad de los conceptos que son analizados en el proceso de abstracción,  se comienza a desarrollar la influencia de la perspectiva que más tarde la denominaríamos como BUSINESS VIEW y los requerimientos de información para la toma de decisiones.

Formó parte de un equipo responsable de experimentar con nuevos enfoques, como la investigación de operaciones, la simulación, la previsión y la automatización, para su posible aplicación en las distintas unidades de negocio de la empresa.

Es importante recalcar justamente la necesidad de la presencia del BUSINESS VIEW ya que usualmente en la ingeniería del software, esta necesidad se transforma en todo un modelo para el desarrollo de la aplicación basada en la programación (habilidad requerida para capacitación futura de la estructura de la empresa o la cotización de un servicio externo que lo oferte como competencia) y que involucra lo que fue denominado como "áreas de conocimiento" bajo los estudios del SWEBOK.

Durante la década de 1950, cientos de empresas estadounidenses se apresuraron a encargar computadoras. Hubo mucha publicidad sobre los beneficios potenciales, pero lograr que las máquinas hicieran algo útil fue mucho más difícil de lo esperado. A menudo terminaron usándose solo para automatizar tareas administrativas limitadas como nómina o facturación. En 1960, los expertos en administración se dieron cuenta de que para justificar los enormes costos de personal y hardware de la informatización, las empresas necesitarían usar computadoras para unir procesos comerciales como ventas, contabilidad e inventario para que los gerentes tengan acceso a información integrada y actualizada. Este fue el gran sueño de la informática corporativa en la década de 1960.

La noción de metadata

Dado que, los conceptos utilizados como esquemas de la información requerida para la toma de decisiones requería persistirse, para luego ser invocados, para luego ser asociados, etc., motivó a pensar en "ahorrar tiempo" para la capa de negocio para la toma de decisiones que el mismo proceso estructurado y matemático de agrupación de conceptos, motivó al siguiente nivel de abstracción que trata de organizar dichos conceptos en elementos que luego semánticamente se unirán para lograr reportes tipo de contenido de datos que en conjunto representan los atributos de la información que se requiere para su procesamiento y entendimiento, a esto se lo denominó como los datos sobre los datos y actualmente se conceptúa como metadata.

DSN_XP y el desempeño climático

El reto climático de ciudades en todo el mundo

Dentro del estudio de movimientos de transición, las ciudades y sus ciudadanos tienen el reto ante el cambio climático de desarrollar acciones a nivel de ciudad, para ello, las ciudades (incluyendo sus ciudadanos) complementan o incluso pueden superar el déficit de acciones a nivel de gobierno local respecto al cambio climático.

Las ciudades y el cambio climático

Es ampliamente reconocido que las ciudades y sus ciudadanos deben desempeñar un papel clave en la adaptación y mitigación del cambio climático. Las ciudades son ampliamente consideradas como un actor destacado en la sostenibilidad global.

Es mucho más posible lograr emprender acciones a nivel de gobiernos locales que acciones a nivel de Estado, pero ¿Qué estamos haciendo y qué se ha logrado hasta ahora?

Sistemas socio-técnicos 

La vida en la ciudad se basa en un conjunto de sistemas socio-técnicos para el desarrollo de iniciativas en alimentación, la energía y el aprovechamiento del agua. Estos sistemas actualmente se ven desafiados por los efectos del cambio climático.

Es evidente que las ciudades están lidiando con estos efectos, en el mundo se han reportado ya casi continuamente impactos de olas de calor y el aumento de las precipitaciones con graves consecuencias.

Ahora bien, si las ciudades son desafiadas por el cambio climático y sus efectos, también las ciudades tienen la capacidad para mitigar y adaptarse a gran escala. Cuando las ciudades comprenden su rol y su capacidad de cambio, se han introducido ambiciosos objetivos para la reducción de emisiones de carbono, para lograr estos objetivos, las ciudades deben activar experimentos con enfoques novedosos de gobernanza e intervenciones políticas.

Un ejemplo típico de tales experimentos es el Fondo de energía y clima de Ámsterdam desarrollado por el gobierno de la ciudad de Ámsterdam. El Fondo busca solucionar un problema acuciante que viven los ciudadanos y las empresas que deseen desarrollar edificios o infraestructuras innovadores y con bajas emisiones de carbono.

 

DSN_XP y Sostenibilidad en ciudades

 Ciudades sostenibles

¿Cómo reconocer si tu ciudad es una ciudad sostenible?

• ¿Ves energías renovables que reemplazan los sistemas de energía basados en fósiles?
• ¿Ves formas más saludables de cocinar en los barrios marginales periurbanos?
• ¿Conoces si se aplican sistemas circulares de reciclaje de agua y residuos?
• ¿Se puede observar ciclistas e infraestructura para la movilidad lenta?
• ¿Existen espacios verdes que permiten la recreación pero que también enfrían la ciudad cuando sube la temperatura?

En gran medida, esta es una imagen del futuro. Hoy, las autoridades de la ciudad y los académicos trabajan en colaboración para prevenir inundaciones, para combatir la fuerte contaminación del aire y brindar a los ciudadanos acceso a alimentos seguros, saneamiento y agua potable.

Para ser sostenibles, las ciudades necesitan transiciones en lo que llamamos su tejido urbano.

El tejido urbano es sinónimo de materiales, tecnologías, infraestructuras junto con la actividad humana que hacen de la ciudad lo que es, un complejo sistema funcional que alberga a sus ciudadanos.

Para que ocurran las transiciones de sostenibilidad urbana, las innovaciones tecnológicas y sociales son igualmente importantes. Las soluciones innovadoras solo serán efectivas cuando son avalados por los ciudadanos y cuando se adapten a sus estilos de vida y a sus rutinas de la vida diaria.

Las personas y su rol en la transición

las personas son importantes para las transiciones de la sostenibilidad en las ciudades de muchas maneras. Los ciudadanos importan, cuando adoptan innovaciones y les dan un lugar en su vida cotidiana, como en el caso cuando se introduce un nuevo sistema de saneamiento basado en inodoros.

Las personas también importan cuando actúan como innovadores, cuando organizan eventos ciclistas semanales para presionar a las autoridades locales para que haya más carriles para bici en las ciudades.

Además, las personas importan como coproductores de productos y servicios. Este es el caso cuando los propietarios colocan paneles fotovoltaicos en sus techos para producir energía renovable. En otra instancia, las personas importan cuando inician un banco de alimentos local que brinden a las personas de bajos ingresos acceso a alimentos seguros, saludables y más sostenibles.

Estos son solo algunos ejemplos de cuándo y cómo las personas son importantes y contribuyen a las transiciones de sostenibilidad.

El objetivo será siempre tejer iniciativas de transición junto a otros interesados como empresas, ONGs, autoridades municipales, juntas de agua, proveedores de energía desarrolladores de software, urbanistas, agricultores académicos, etc.

Finalmente la cocreación se presenta en dos dimensiones, a saber:

• La cocreación de la política pública de la ciudad o participación ciudadana
• La cocreación de los sistemas socio-técnicos de energía, agua y alimentos

Transición

Concepto que surge ampliamente en la investigación y política relacionada con la sostenibilidad. El término transición se deriva de estudios demográficos en los que se lo utilizó para describir los principales cambios en las poblaciones a lo largo del tiempo: combinaciones de aumento de mortalidad y disminución de las tasas de natalidad condujo a una transición en los patrones de crecimiento de la población y las sociedades en su conjunto.

Una definición común de transición en los estudios de sostenibilidad lo describe como el conjunto de procesos de transformación en los que las sociedades cambian de manera fundamental durante un lapso de tiempo de una generación o más.

Estos cambios no son incrementales o marginales, sino que son cambios fundamentales en las sociedades y toman su tiempo.

¿Cómo se producen las transiciones?

Frank Geels Modelo de transiciones

El componente fundamental del modelo Geels implica un cambio de un régimen socio-técnico a otro, un régimen comprende todo el conjunto de mercados, industrias, cadenas de suministro, políticas, tecnologías, así como los hábitos y las prácticas de las personas rutinariamente en un determinado sector de la sociedad.

Para la energía, implica por ejemplo el sistema actual de redes de transmisión eléctrica basadas en los combustibles fósiles, nuestras prácticas domésticas energéticas, las empresas de servicios públicos y los mercados de energía, las regulaciones y reglas en torno a la producción y consumo energético. 

El conjunto de cambios requerido representan las flechas en la parte central del modelo, yendo desde la izquierda (régimen actual) hacia la derecha (nuevo régimen), ahora bien si esto representa una transición, ¿Cómo surge?

Nichos

El concepto de desarrollo de nichos en el modelo, una transición es "impulsada" por innovaciones que vienen desde fuera del régimen actual y que se originan en nichos.  Estas innovaciones pueden perturbar una o más dimensiones del régimen.  Los nichos se representan en el modelo como las flechas en la mitad del campo, por tanto, se deduce que las transiciones se inician en los denominados nichos, representados en la parte inferior izquierda del modelo.

Los nichos son espacios protegidos en los que múltiples actores prueban y aprenden novedades. Los denominados laboratorios de vida urbana son ejemplos de este tipo de desarrollos especializados.

Protección de nichos

Se necesitan protección porque pase lo que pase en los nichos, lo que pase no está alineado con el régimen actual y no puede beneficiarse fácilmente de las economías de escala. Subvenciones a la innovación, exenciones fiscales, exenciones de normas y reglamentos, todas estas pueden ser formas de protección de un nicho.

Muchos de estos proyectos fracasan (representado como que no todas las flechas logran llegar) pero algunos pueden escalar, madurar y lograr hacer una grieta en el régimen actual.

Es justamente a través de estas "grietas" y la adopción de novedades, que eventualmente el régimen cambiará a un nuevo régimen.

Paisajes socio-técnicos

Junto al nivel de nichos y regímenes, existe un tercer nivel llamado "paisaje socio-técnico". Este es otro componente del modelo que abarca todos los regímenes juntos. a este nivel macro se piensa en la economía mundial, el panorama político, el calentamiento global, como los factores a gran escala a partir del nivel del paisaje y puede ejercer presión sobre los regímenes actuales y así abrir el régimen para que la innovaciones de nicho entren desde abajo.

Cambios de nivel

Los cambios de nivel pueden verse como un proceso de abajo hacia arriba, pero a veces los cambios provienen directamente del nivel del régimen o incluso a nivel de paisaje.

Los desastres naturales pueden acelerar la innovación a nivel de nicho, además, los actores del régimen actual pueden aspirar a una transición y ayudar a poner en marcha innovaciones de nicho.  Después de todo, muchos de los laboratorios urbanos son iniciados por consorcios de partes interesadas del régimen.  Estos desarrollos son mapeados en el modelo como las flechas punteadas a la izquierda del modelo. 

Puedes ver la transición de un régimen como un cambio en el curso de un río, los ríos pueden cambiar el paisaje, ero solo a muy largo plazo, los caudales de los ríos se pueden ajustar en un período de tiempo más corto, construyendo ingles para ajustar el caudal.

Los regímenes vienen siendo el río que se  guía y se curva a través del paisaje, los proyectos de nicho son las medidas para ajustar o reorientar el caudal del río.

La teoría se ha aplicado a desarrollos urbanos sostenibles, como en energía, agua, vivienda, transporte, alimentación y reciclaje.

DSN_XP y las tiendas de comercio electrónico

 eCOMMERCE

DSN_XP debe resolver como integrar un carrito de comparas a nuestro sitio Web, pese a que buscamos opciones que puedan ser implementadas bajo código, no teníamos resuelto el hospedaje de dicho código por lo que miraremos en esta jornada de trabajo los aspectos que debemos considerar para la gobernanza de nuestro sistema de comercio electrónico.

Tienda electrónica

Dadas las nuevas circunstancias, como DESSINE nos vimos obligados a volvernos digitales, para ello comenzamos con la búsqueda de aliados estratégicos para ello y dentro de este camino hemos logrado ya poder iniciar con el armado de nuestra tienda electrónica, si este es un caso parecido al tuyo y nuestra experiencia puede servirte, pues por nosotros encantados.

Terapia de Negocios

Todo este proceso fue inicialmente levantado por nuestros amigos de Terapia de Negocios, de ellos aprendimos las herramientas con las que estaban jugando e incluso nos pusimos como socios estratégicos de su organización para avanzar con esta temática, por ello nuestro agradecimiento y reconocimiento público oficial que estos temas surgen desde su esfuerzo e iniciativa y que nosotros solo cosechamos sus logros para implementarlos en nuestro diseño.

Propuesta de valor

Como local de ventas o tienda, ante la existencia de mucha competencia (millones), nuestra propuesta de valor debe coexistir con la propuesta de valor de muchos otros colegas que desean vender sus servicios o productos, en consecuencia, qué haría que nuestros posibles clientes nos prefieran a nosotros sobre la competencia?

Nota: A partir de este momento, DESSINE deja en claro que su DRIVER de negocios está guiado por los conceptos de la permacultura y su aplicación más allá de la sustentabilidad.

Para la mayoría de nuestros clientes y amigos, la propuesta de valor es aquella estrategia comercial que se oferta al cliente para que con su interacción pueda ingresar más ingresos en nuestra organización.

Aunque puede sonar coherente, uno de los factores que impulsan a DESSINE es el principio ético de diseño de cuidar por nuestra gente y por ello es preciso primero cuidarnos a nosotros mismos y esto implica un trato justo y en respeto para con todos los miembros de nuestra comunidad sean clientes o no e incluso abarca a proveedores también.

DSN_XP y Diseño guiado por el Dominio

 Domain Driver Design

DSN_XP entra en contacto con este marco de trabajo para diseño de software que considera un concepto que nos impactó mucho y se trata de la noción de DOMINIO y la presencia de "objetos del negocio" existentes dentro de un lenguaje organizacional tanto transversalmente como verticalmente, capacidad de información que  la denominaron como "lenguaje ubicuo".

Dan Haywood, Haywood Associates Ltd

http://danhaywood.com/

Introducción al diseño basado en dominios

Las aplicaciones empresariales de hoy son sin duda sofisticadas, dependen de algunas tecnologías especializadas (persistencia, AJAX, servicios web, etc.) para hacer lo que hacen. 

Como desarrolladores, es comprensible que tendamos a centrarnos en estos detalles técnicos. Pero la verdad es que un sistema que no resuelve las necesidades comerciales..., no le sirve a nadie, sin importar lo bonito que se vea o lo bien que esté diseñada su infraestructura.

Filosofía de diseño DDD

La filosofía del diseño impulsado por dominios (DDD), descrita por primera vez por Eric Evans en su libro [1] del mismo nombre, consiste en colocar nuestra atención en el corazón de la aplicación, centrándose en la complejidad intrínseca del dominio empresarial. sí mismo. También distinguimos el dominio central (exclusivo de la empresa) de los subdominios de soporte (generalmente de naturaleza genérica, como dinero o tiempo) y colocamos apropiadamente más de nuestros esfuerzos de diseño en el núcleo.

El diseño dirigido por dominios consta de un conjunto de patrones para crear aplicaciones empresariales a partir del modelo de dominio. En su carrera de software, es posible que ya se haya encontrado con muchas de estas ideas, especialmente si es un desarrollador experimentado en un lenguaje OO. Pero aplicarlos juntos le permitirá crear sistemas que realmente satisfagan las necesidades de la empresa.

En este artículo voy a repasar algunos de los patrones principales de DDD, recoger algunas áreas donde los novatos parecen tener dificultades y destacar algunas herramientas y recursos (uno en particular) para ayudarlo a aplicar DDD en su trabajo.

De código y modelos

Con DDD buscamos crear modelos de un dominio de problemas. La persistencia, las interfaces de usuario y la mensajería pueden llegar más tarde, es el dominio lo que debe entenderse, porque esa es la parte del sistema que se está construyendo que distingue el negocio de su empresa de sus competidores. (Y si eso no es cierto, considere comprar un producto empaquetado).

Por modelo no nos referimos a un diagrama o conjunto de diagramas; Claro, los diagramas son útiles pero no son el modelo, solo diferentes vistas del modelo (ver Figura). No, el modelo es el conjunto de conceptos que seleccionamos para ser implementados con el software, representados en código y cualquier otro artefacto de software utilizado para construir el sistema entregado. 

En otras palabras, el código es el modelo. 

Los editores de texto proporcionan una forma de trabajar con este modelo, aunque las herramientas modernas también proporcionan muchas otras visualizaciones (diagramas de clases UML, diagramas entidad-relación, Spring beandocs [2], flujos Struts / JSF, etc.).

Modelo frente a perspectivas del modelo

Diseño basado en modelos

Este es el primero de los patrones DDD: un diseño basado en modelos . Significa poder mapear, idealmente de manera bastante literal, los conceptos del modelo con los del diseño / código. Un cambio en el modelo implica un cambio en el código; cambiar el código significa que el modelo ha cambiado. 

DDD no exige que se modele el dominio utilizando la orientación a objetos; podríamos construir modelos utilizando un motor de reglas, por ejemplo, pero dado que los lenguajes de programación empresarial dominantes están basados ​​en OO, la mayoría de los modelos serán de naturaleza OO. Después de todo, OO se basa en un paradigma de modelado. 

Los conceptos del modelo se representarán como clases e interfaces, las responsabilidades como miembros de la clase.

Hablar el idioma

Veamos ahora otro principio fundamental del diseño impulsado por dominios. En resumen: queremos construir un modelo de dominio que capture el dominio del problema del sistema que se está construyendo y vamos a expresar esa comprensión en artefactos de código / software. 

Para ayudarnos a hacer eso, DDD aboga por que los expertos en el dominio y los desarrolladores se comuniquen conscientemente utilizando los conceptos dentro del modelo. Por lo tanto, los expertos en dominios no describen una nueva historia de usuario en términos de un campo en una pantalla o un elemento de menú, sino que hablan sobre la propiedad o el comportamiento subyacente que se requiere en un objeto de dominio. De manera similar, los desarrolladores no hablan de nuevas variables de instancia de una clase o columnas en una tabla de base de datos.

Haciendo esto de forma rigurosa conseguimos desarrollar un lenguaje ubicuo. Si una idea no se puede expresar fácilmente, indica un concepto que falta en el modelo de dominio y el equipo trabaja en conjunto para descubrir cuál es ese concepto que falta. Una vez que esto se ha establecido, el nuevo campo en la pantalla o columna en la tabla de la base de datos sigue a eso.

Como gran parte de DDD, esta idea de desarrollar un lenguaje ubicuo no es realmente una idea nueva: los XPers lo llaman un "sistema de nombres" y los DBA durante años han elaborado diccionarios de datos. 

Pero el lenguaje ubicuo es un término evocador y algo que se puede vender tanto a los empresarios como a los técnicos. También tiene mucho sentido ahora que las prácticas ágiles de "todo el equipo" se están generalizando.

Modelos y contextos

Siempre que hablamos de un modelo, siempre está dentro de algún contexto. Este contexto generalmente se puede inferir del conjunto de usuarios finales que utilizan el sistema. Por lo tanto, tenemos un sistema comercial de atención al público implementado para los comerciantes o un sistema de punto de venta utilizado por los cajeros en un supermercado. Estos usuarios se relacionan con los conceptos del modelo de una manera particular y la terminología del modelo tiene sentido para estos usuarios, pero no necesariamente para cualquier otra persona fuera de ese contexto. 

DDD llama a esto el contexto acotado (BC) . Cada modelo de dominio vive precisamente en un BC, y un BC contiene precisamente un modelo de dominio.

Debo admitir que cuando leí por primera vez sobre los BC no entendí el sentido: si los BC son isomórficos a los modelos de dominio, ¿por qué introducir un nuevo término? Si solo los usuarios finales interactuaran con los BC, entonces quizás no habría necesidad de utilizar este término. Sin embargo, diferentes sistemas (BC) también interactúan entre sí, enviando archivos, pasando mensajes, invocando API, etc. Si sabemos que hay dos BC interactuando entre sí, entonces sabemos que debemos tener cuidado de traducir entre los conceptos en un dominio y los del otro.

Poner un límite explícito alrededor de un modelo también significa que podemos comenzar a discutir las relaciones entre estos CB. De hecho, DDD identifica un conjunto completo de relaciones entre BC, de modo que podamos racionalizar lo que debemos hacer cuando necesitamos vincular nuestros diferentes BC juntos:

Lenguaje publicado 

Los BC que interactúan acuerdan un lenguaje común (por ejemplo, un grupo de esquemas XML sobre un bus de servicio empresarial) mediante el cual pueden interactuar entre sí;

Servicio de host abierto 

Un BC especifica un protocolo (por ejemplo, un servicio web RESTful) mediante el cual cualquier otro BC puede utilizar sus servicios;

Kernel compartido 

Dos BC usan un kernel común de código (por ejemplo, una biblioteca) como una lengua franca común, pero por lo demás hacen sus otras cosas de una manera específica;

Cliente / proveedor 

Un BC utiliza los servicios de otro y es un interesado (cliente) de ese otro BC. Como tal, puede influir en los servicios prestados por ese BC;

Conformista 

Un BC utiliza los servicios de otro pero no es un interesado de ese otro BC. Como tal, utiliza "tal cual" (se ajusta a) los protocolos o API proporcionados por ese BC;

Capa anticorrupción 

Un BC utiliza los servicios de otro y no es un interesado, pero tiene como objetivo minimizar el impacto de los cambios en el BC del que depende mediante la introducción de un conjunto de adaptadores: una capa anticorrupción.

A medida que avanzamos en esta lista, puede verse que el nivel de cooperación entre los dos CB se reduce gradualmente (consulte la Figura 2). Con un lenguaje publicado partimos de los BC que establecen un estándar común mediante el cual pueden interactuar; ninguno de los dos posee este idioma, sino que es propiedad de la empresa en la que residen (incluso podría ser un estándar de la industria). Con el host abierto todavía lo estamos haciendo bastante bien; el BC proporciona su funcionalidad como un servicio en tiempo de ejecución para que cualquier otro BC lo invoque, pero (presumiblemente) mantendrá la compatibilidad con versiones anteriores a medida que el servicio evolucione.

Espectro de relaciones contextuales limitadas

Sin embargo, para cuando nos volvemos conformistas, simplemente estamos viviendo con nuestra suerte; un BC está claramente subordinado al otro. Si tuviéramos que integrarnos con el sistema de contabilidad general, comprado por ACME, esa podría ser la situación en la que viviríamos. 

Y si usamos una capa anticorrupción, generalmente nos estamos integrando con un sistema heredado, pero introducimos un capa extra para aislarnos lo mejor que podamos de ella. Eso cuesta dinero para implementar, por supuesto, pero reduce el riesgo de dependencia. Una capa anticorrupción también es mucho más barata que volver a implementar ese sistema heredado, algo que, en el mejor de los casos, distraería nuestra atención del dominio central y, en el peor, terminaría en falla.

DDD sugiere que elaboremos un mapa de contexto para identificar nuestros CB y aquellos de los que dependemos o dependemos, identificando la naturaleza de estas dependencias. La Figura 3 muestra un mapa de contexto de este tipo para un sistema en el que he estado trabajando durante los últimos 5 años más o menos.

Ejemplo de un mapeo de contexto

Toda esta charla sobre mapas de contexto y BC a veces se denomina DDD estratégico y por una buena razón. Después de todo, averiguar la relación entre los BC es bastante político cuando lo piensas: ¿de qué sistemas ascendentes dependerá mi sistema, es fácil para mí integrarme con ellos, tengo influencia sobre ellos, confío en ellos? Y lo mismo es válido en sentido descendente: ¿Qué sistemas utilizarán mis servicios, cómo expongo mi funcionalidad como servicios, tendrán influencia sobre mí?

No entender esto y su aplicación fácilmente podría ser un fracaso.

Capas y hexágonos

Vayamos ahora hacia adentro y consideremos la arquitectura de nuestro propio BC (sistema). Básicamente, DDD solo está realmente preocupado por la capa de dominio y, en realidad, no tiene mucho que decir sobre las otras capas: presentación, aplicación o infraestructura (o capa de persistencia). Pero sí espera que existan. Este es el patrón de arquitectura en capas (Figura 4).

Arquitectura en capas

Hemos estado construyendo sistemas multicapa durante años, por supuesto, pero eso no significa que seamos necesariamente tan buenos en eso. De hecho, algunas de las tecnologías dominantes del pasado, sí, EJB 2, ¡te estoy mirando! - han sido positivamente perjudiciales para la idea de que un modelo de dominio puede existir como una capa significativa. 

Toda la lógica empresarial parece filtrarse en la capa de aplicación o (peor aún) en la capa de presentación, dejando un conjunto de clases de dominio anémicas [3] como una cáscara vacía de contenedores de datos. De esto no se trata DDD.

Entonces, para ser absolutamente claro, no debería haber ninguna lógica de dominio en la capa de aplicación. En cambio, la capa de aplicación asume la responsabilidad de aspectos como la gestión de transacciones y la seguridad. En algunas arquitecturas, también puede asumir la responsabilidad de garantizar que los objetos de dominio recuperados de la capa de infraestructura / persistencia se inicialicen correctamente antes de interactuar con ellos (aunque prefiero que la capa de infraestructura haga esto en su lugar).

Cuando la capa de presentación se ejecuta en un espacio de memoria separado, la capa de aplicación también actúa como mediador entre la capa de presentación y la capa de dominio. 

La capa de presentación generalmente se ocupa de representaciones serializables de un objeto de dominio o de objetos de dominio (objetos de transferencia de datos o DTO), generalmente uno por "vista". Si se modifican, la capa de presentación devuelve los cambios a la capa de aplicación, que a su vez determina los objetos de dominio que se han modificado, los carga desde la capa de persistencia y luego reenvía los cambios a esos objetos de dominio.

Una desventaja de la arquitectura en capas es que sugiere un apilamiento lineal de dependencias, desde la capa de presentación hasta la capa de infraestructura. Sin embargo, es posible que queramos admitir diferentes implementaciones tanto en la capa de presentación como en la de infraestructura. Ese es ciertamente el caso si (¡como supongo que sí!) Queremos probar nuestra aplicación:

• por ejemplo, herramientas como FitNesse [4] nos permiten verificar el comportamiento de nuestro sistema desde la perspectiva del usuario final. Pero estas herramientas generalmente no pasan por la capa de presentación, sino que van directamente a la siguiente capa, la capa de aplicación. Entonces, en cierto sentido, FitNesse actúa como un visor alternativo.
• de manera similar, es posible que tengamos más de una implementación de persistencia. Nuestra implementación de producción probablemente usa RDBMS o tecnología similar, pero para las pruebas y la creación de prototipos podemos tener una implementación liviana (quizás incluso en memoria) para que podamos simular la persistencia.

También podríamos querer distinguir entre las interacciones entre las capas que son "internas" y "externas", donde por interno me refiero a una interacción en la que ambas capas están completamente dentro de nuestro sistema (o BC), mientras que una interacción externa atraviesa los BC.

Entonces, en lugar de considerar nuestra aplicación como un conjunto de capas, una alternativa es verla como un hexágono [5], como se muestra en la Figura 5. Los visores utilizados por nuestros usuarios finales, así como las pruebas de FitNesse, utilizan un cliente interno API (o puerto), mientras que las llamadas procedentes de otros BC (por ejemplo, RESTful para una interacción de host abierta, o una invocación de un adaptador ESB para una interacción de lenguaje publicado) llegan a un puerto de cliente externo. Para la capa de infraestructura de back-end, podemos ver un puerto de persistencia para implementaciones de almacenamiento de objetos alternativos y, además, los objetos en nuestra capa de dominio pueden llamar a otros BC a través de un puerto de servicios externos.

DSN_XP y el nuevo juego de desarollo de nuevos productos

Hirotaka Takeuchi e Ikujiro Nonaka

DSN_XP tiene como referente a la escuela de pensamiento detrás del diseño de nuevos productos bajo un nuevo enfoque que juega con un pensar clásico e inflexible.

Harvard Business Review

En el acelerado y ferozmente competitivo mundo del desarrollo comercial de nuevos productos, la velocidad y la flexibilidad son esenciales. Las empresas se están dando cuenta cada vez más de que el antiguo enfoque secuencial para desarrollar nuevos productos simplemente no hará el trabajo. En cambio, las empresas de Japón y los Estados Unidos están utilizando un método holístico, como en rugby, la pelota pasa dentro del equipo a medida que se mueve una unidad en el campo.

Este enfoque holístico tiene seis características: se incorporan en la inestabilidad, son equipos de proyectos que se auto organizan, se emplean fases de desarrollo, se consigue un "aprendizaje múltiple", el control es sutil y la transferencia organizativa de aprendizaje. Las seis piezas encajan juntas como un rompecabezas, formando un proceso rápido y flexible para el desarrollo de nuevos productos. Igual de importante, el nuevo enfoque puede actuar como un agente de cambio: es un vehículo para presentar ideas y procesos creativos impulsados ​​por el mercado.es una organización vieja y rebelde.

El Sr. Takeuchi es profesor asociado y el Sr. Nonaka es profesor de la Universidad Hitotsubashi en Japón.  La investigación del Sr. Takeuchi se ha centrado en el marketing y la competencia global . El Sr. Nonaka ha publicado ampliamente en Japón sobre organizaciones, estrategia y marketing.

Nota de los autores: 

Agradecemos la contribución de Ken-ichi Imai en el desarrollo de este artículo. Un anterior versión de este artículo fue coautora de Ken-ichi Imai, Ikujiro Nonaka e Hirotaka Takeuchi. Estaba titulado "Gestión del proceso de desarrollo de nuevos productos: cómo Las empresas japonesas aprenden y desaprenden” y fue enviado en el septuagésimo quinto aniversario. Coloquio sobre productividad y tecnología, Harvard Business School, 28 y 29 de marzo de 1984.

El nuevo producto con el nuevo juego de desarrollo

Las reglas del juego en el desarrollo de nuevos productos están cambiando. Muchas empresas descubren que se necesita más que conceptos básicos aceptados de alta calidad, bajo costo y diferenciación para sobresalir en el mercado competitivo de hoy.  También requiere flexibilidad y velocidad.

 

Este cambio se refleja en el énfasis de las empresas que están colocando nuevos productos como fuente de nuevas ventas y ganancias. En 3M, por ejemplo, productos de menos de cinco años representan el 25% de las ventas. Una encuesta de 1981 de 700 empresas estadounidenses indicaron que los nuevos productos representarían un tercio de todas las ganancias en la década de 1980, un aumento de una quinta parte en la década de 1970. 

Enfoques de desarrollo

Este nuevo énfasis en la velocidad y la flexibilidad invoca un enfoque diferente para la gestión de desarrollo de nuevos productos. El tradicional enfoque secuencial o "carrera de relevos" para el desarrollo de productos - ejemplificado por la Administración Nacional de Aeronáutica y del Espacio y su sistema de planificación de programas por fases (PPP) - puede entrar en conflicto con los objetivos de velocidad máxima y flexibilidad. En cambio, un enfoque holístico o de "rugby": donde un equipo intenta recorrer la distancia como una unidad, pasando la pelota hacia adelante y hacia atrás, puede servir mejor para los requisitos competitivos de hoy.

Bajo el antiguo enfoque del desarrollo de un producto, el proceso se movió como una carrera de relevos, con un grupo de especialistas funcionales que pasan el testigo al siguiente grupo. El proyecto fue secuencialmente de fase a fase: desarrollo de conceptos, pruebas de viabilidad, producción diseño de producto, proceso de desarrollo, producción piloto y producción final. 

Bajo este método, las funciones estaban especializadas y segmentadas: el personal de marketing examinó las necesidades y percepciones de los clientes al desarrollar conceptos de productos; los ingenieros de I + D eligieron el diseño apropiado; la ingeniería de producción le dio forma y otras funciones especialistas llevaron el testigo en diferentes etapas de la carrera.

Bajo el enfoque de rugby, el proceso de desarrollo de productos surge de la interacción constante de un equipo multidisciplinario cuidadosamente seleccionado, los miembros trabajan juntos de principio a fin. En lugar de moverse en etapas definidas y altamente estructuradas, el proceso nace de la interacción de los miembros del equipo.(ver Anexo 1 ). 

Un grupo de ingenieros, por ejemplo, puede comenzar a diseñar el producto (fase tres) antes de que todos los resultados de las pruebas de viabilidad (fase dos) estén. O el equipo puede verse obligado a reconsiderar una decisión como resultado de información posterior. El equipo no se detiene entonces, pero se dedica a la experimentación iterativa. Esto ocurre incluso en las últimas fases del proceso de desarrollo.

El Cuadro 1 ilustra la diferencia entre los enfoques tradicional y lineal para el desarrollo de productos y el enfoque del rugby. El enfoque secuencial, etiquetado tipo A, está tipificado por el PPP tipo sistema NASA. El enfoque de superposición está representado por tipo B, donde la superposición ocurre solo en el borde de las fases adyacentes y tipo C, donde la superposición se extiende a través de varias fases. 

Observamos una superposición tipo B en Fuji-Xerox y una superposición de tipo C en Honda y Canon.

Este tipo de enfoque es esencial para las empresas que buscan desarrollar nuevos productos de forma rápida y flexible. El cambio de un enfoque lineal a uno integrado fomenta el ensayo y error y desafía el status quo. Estimula nuevos tipos de aprendizaje y pensamiento dentro de la organización en diferentes niveles y funciones. Tal como es importante, esta estrategia para el desarrollo de productos puede actuar como un agente de cambio para la organización en general.

La energía y la motivación que produce el esfuerzo pueden esparcirse por toda la gran empresa y empezar a romper algunas de las rigideces que se han establecido hasta ahora. En este artículo, destacamos empresas tanto en Japón y Estados Unidos que han adoptado un nuevo enfoque para gestionar el proceso de desarrollo de productos. Nuestra investigación examinó tales empresas multinacionales, empresas como Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard. Nosotros entonces analizamos el proceso de desarrollo de seis productos:

• Fotocopiadora de tamaño mediano D FX-3500 (presentada por Fuji-Xerox en 1978)
• Copiadora de uso personal PC-10 (Canon, 1982)
• Coche urbano D con motor de 1200 cc (Honda, 1981)
• Computadora personal D PC 8000 (NEC, 1979)
• Cámara réflex de objetivo único AE-1 (Canon, 1976)
• Auto Boy, conocido como Sure Shot in the United
• Estados, cámara con obturador de lente, (Canon, 1979)

Seleccionamos cada producto en función de su impacto, su visibilidad dentro de la empresa como parte de una "ruptura a través del proceso de desarrollo", la novedad de las características del producto en ese momento, el éxito en el mercado del producto y el acceso y disponibilidad de datos en cada producto.

Mover el SCRUM campo abajo

De entrevistas con miembros de la organización, desde el CEO hasta los ingenieros jóvenes, aprendimos que liderar las empresas muestran seis características en la gestión de sus procesos de desarrollo de nuevos productos:

1. Inestabilidad incorporada
2. Equipos de proyectos auto organizados
3. Fases de desarrollo superpuestas
4. "Aprendizaje múltiple"
5. Control sutil
6. Transferencia organizativa del aprendizaje

Estas características son como piezas de un rompecabezas. Cada elemento, por sí mismo, no produce velocidad y flexibilidad. Pero tomado en su conjunto, las características pueden producir un nuevo y poderoso conjunto de dinámicas que marcarán la diferencia.

Desarrollo en la inestabilidad

La alta dirección inicia el proceso de desarrollo señalando un objetivo amplio o una dirección estratégica general. Rara vez entrega un concepto claro o un plan de trabajo específico sobre un producto nuevo. Pero ofrece un equipo de proyecto con una amplia medida de libertad y también establece metas extremadamente desafiantes. Por ejemplo, La alta dirección de Fuji-Xerox pidió un cambio radicalmente diferente de copiadora y le dio al equipo del proyecto FX-3500 dos años para idear una máquina que pudiera producirse en la mitad del costo de su línea de gama alta y que aún funcionan bien.

La alta dirección crea un elemento de tensión en el equipo del proyecto dándole una gran libertad para llevar a cabo un proyecto de importancia estratégica para la empresa y estableciendo requisitos muy exigentes. Un ejecutivo a cargo del desarrollo de marcado Honda, "Es como poner a los miembros del equipo en el segundo piso, quitando la escalera y diciéndoles salta o si no. Creo que la creatividad nace empujando gente contra la pared y presionándolos casi en el extremo."

Equipos de proyecto auto organizados

Un equipo de proyecto adquiere un carácter auto organizado cuando es conducido a un estado de "información cero", donde no se aplica el conocimiento previo. Ambigüedad y abundante fluctuación en este estado. Dejando cocer, el proceso comienza a crear su propio orden dinámico. 2 

El equipo del proyecto comienza a operar como un emprendimiento: toma iniciativas y riesgos y desarrolla una agenda pendiente. En algún momento, el equipo comienza a crear su propio concepto. Un grupo posee una capacidad de auto organización cuando exhibe tres condiciones: autonomía, auto trascendencia y fertilización cruzada. 

En nuestro estudio de varios equipos de desarrollo de nuevos productos, encontramos las tres condiciones:

• Autonomía. La participación de la sede es limitada para proporcionar orientación, dinero y apoyo moral en el principio. En el día a día, la alta dirección rara vez interviene; el equipo es libre de establecer en dirección a lo suyo. En cierto modo, la alta dirección actúa como una empresa capitalista, o como dijo un ejecutivo: "Abrimos nuestra bolsa, pero mantenemos la boca cerrada".
  
  Este tipo de autonomía fue evidente cuando IBM desarrolló su computadora personal. Un pequeño grupo de ingenieros comenzaron a trabajar en la máquina en una cochera convvertida en la remota Boca Raton, Florida. A excepción de las revisiones corporativas trimestrales, la sede en Armonk, Nueva York permitió al grupo de Boca Raton para operar por su cuenta. El grupo obtuvo el visto bueno para tomar medidas poco convencionales, como seleccionar por fuera los proveedores para su microprocesador y el paquete de software.
  
  Observamos otros ejemplos de autonomía en nuestros estudios de caso:
  
  
• El equipo del proyecto Honda City, cuyos miembros oscilan en edad promedio de 27 años, tenían estas instrucciones administrativas: desarrollar “el tipo de automóvil que el segmento de jóvenes a los que les gustaría conducir". Un ingeniero dijo: “Es increíble cómo la empresa llamó a los jóvenes ingenieros como a nosotros para diseñar un coche con un nuevo concepto y nos dio la libertad de hacerlo a nuestra manera."
• Un pequeño grupo de ingenieros de ventas que originaron los microprocesadores vendidos finalmente construyeron el PC 8000 en NEC. El grupo comenzó sin conocimiento sobre computadoras personales. "Nos dieron el visto bueno de la alta dirección para continuar con el proyecto, provisto que desarrollaríamos el producto por nosotros mismos y también seríamos responsable de la fabricación, venta y repararlo por nuestra cuenta", comentó la cabeza del proyecto.
  
  
• Auto trascendencia. Los equipos del proyecto parecen estar absortos en una búsqueda interminable de "el límite". Iniciando con las pautas establecidas por la alta dirección, comienzan a establecer sus propias metas y seguir elevándolas a lo largo del proceso de desarrollo. Al perseguir lo que a primera vista parecen ser objetivos contradictorios, idean formas de anular el status quo y hacer el gran descubrimiento.
  
  Observamos muchos ejemplos de auto trascendencia en nuestro trabajo de campo. Llegó el equipo del proyecto Canon AE-1 con nuevas ideas para cumplir con los desafiantes parámetros establecidos por la alta dirección. La empresa pidió al equipo que desarrollara una cámara de exposición con sistema automático de alta calidad, tenía que ser compacta, ligera, fácil de usar y con un precio un 30% más bajo que el actual precio de las cámaras de un solo objetivo.
  
  Para alcanzar este ambicioso objetivo, el equipo del proyecto logró varias primicias en el diseño y producción de cámaras: un cerebro electrónico compuesto por circuitos integrados hechos a medida por Texas Instruments; producción modularizada que hizo posible la automatización y la producción en masa; y la reducción del número de piezas entre un 30% y un 40%." Eso fue una lucha porque tuvimos que negar nuestra tradicional forma de pensar”, recordó el responsable del equipo AE-1. “Pero lo hacemos todos los días en las partes en curso de nuestro negocio”, respondió otro ejecutivo de Canon. Toda la organización realiza mejoras incrementales diarias para fortalecer lo que el presidente llama "Los fundamentos": I + D, tecnología de producción, venta de destreza y cultura corporativa.
  
  El equipo del proyecto Honda City también logró una ruptura a través de trascender el status quo. Al equipo se le pidió que desarrollara un automóvil con dos características  de los competidores para el segmento juvenil: eficiencia en las fuentes y combustible y calidad sin concesiones a un precio bajo. El instinto natural del equipo fue desarrollar una versión reducida del Civic el modelo más vendido de Honda. Pero después de mucho debate, el equipo decidió desarrollar un coche con un concepto totalmente nuevo. Es desafiante el apoyó a la idea predominante de que un automóvil debe ser largo y bajo y diseñó un coche "bajo y alto". Estaba convencido de que una evolución hacia una "máquina mínima, máximo humano" era inevitable, el equipo estaba dispuesto a arriesgarse a ir contra la industria y sus normas.
  
  
• Fertilización cruzada. Un equipo de proyecto formado por miembros con diversas especializaciones funcionales, procesos de pensamiento y patrones de comportamiento llevan a cabo el desarrollo del nuevo producto. El equipo Honda, por ejemplo, consistió en miembros cuidadosamente seleccionados de producción y ventas I + D. La empresa dio un paso más colocando una amplia variedad de personalidades en el equipo. Tal diversidad fomentó nuevas ideas y conceptos. Si bien la selección de un equipo diverso es fundamental, no lo es hasta que los miembros comiencen a interactuar que la fertilización cruzada realmente tiene lugar.
  
  Fuji-Xerox localizó el equipo multifuncional que construye el FX-3500 —con integración de miembros desde los departamentos de planificación, diseño, producción, ventas, distribución y evaluación — en una gran sala. Un miembro del proyecto dio el siguiente razonamiento para este paso: "Cuando todos los los miembros del equipo están ubicados en una sala grande, la información de alguien se vuelve tuya, sin dificultad siquiera. Entonces empiezas a pensar en términos de lo que es mejor o el segundo mejor para el grupo en general y no solo acerca de dónde estás parado. Si todos entienden el posición de otra persona, entonces cada uno de nosotros es más voluntario tratando de ceder, o al menos de tratar de hablar entre ellos. Las iniciativas surgen como resultado ".

Fases de desarrollo superpuestas

El carácter auto organizado del equipo produce una dinámica o ritmo único. Aunque los miembros del equipo comienzan el proyecto con diferentes horizontes zonas de tiempo: las personas de I + D tienen el mayor tiempo que las personas de horizonte y producción son las más cortas: todas deben trabajar para sincronizar su ritmo para cumplir plazos. Además, mientras que el equipo del proyecto parte de "Información cero", cada miembro pronto comienza a compartir conocimientos sobre el mercado y la comunidad tecnológica. Como resultado, el equipo comienza a trabajar como una unidad. En algún momento, el individuo y el todo se vuelven inseparables. El ritmo del individuo y el ritmo del grupo comienzan a superponerse, creando un pulso completamente nuevo. Este pulso sirve como impulsor de fuerza y ​​mueve al equipo hacia adelante.

Pero la rapidez del pulso varía en diferentes fases de desarrollo. El ritmo parece ser el más vigoroso en las primeras fases y se reduce hacia el final. Miembros del equipo de desarrollo PC-10 de Canon describieron este ritmo de la siguiente manera: "Cuando estamos debatiendo sobre qué tipo de concepto crear, nuestras mentes van en diferentes direcciones y enumeran alternativas. Pero cuando estamos tratando de enfrentarnos logrando tanto un bajo costo como una alta confiabilidad, nuestro las mentes trabajan para integrar los distintos puntos de vista. El conflicto tiende a ocurrir cuando algunos intentan diferenciarse y otros intentan integrarse. La habilidad radica en crear este ritmo y saber cuándo pasar de un estado a otro ".

Bajo el enfoque secuencial o carrera de relevos, un proyecto pasa por varias fases en una forma de paso a paso, pasando de una fase a la siguiente sólo después de que todos los requisitos de la fase anterior se cumplen. Estos puntos de control controlan el riesgo. Pero al mismo tiempo, este enfoque deja poco espacio para la integración. Un cuello de botella en una fase puede ralentizar o incluso detener del todo el proceso de desarrollo.

Bajo el enfoque holístico o rugby, las fases se superponen considerablemente, lo que permite al grupo absorber la vibración o el "ruido" generado a lo largo del proceso de desarrollo. Cuando aparece un cuello de botella, obviamente, el nivel de ruido aumenta. Pero el proceso no se detiene repentinamente; el equipo logra empujarse hacia adelante.

Fuji-Xerox heredó el sistema PPP (consulte el tipo A en Anexo 1 ) de su empresa matriz, pero lo revisó en dos formas. Primero, redujo el número de fases de seis a cuatro redefiniendo algunas de las fases y agregándolos de manera diferente. En segundo lugar, cambió el sistema secuencial lineal en el llamado Sistema de “sashimi”. El sashimi son rodajas de pescado crudo alineados en un plato, una rebanada superpuesta a la otra (ver Anexo 2. )

El sistema de sashimi requiere una amplia interacción, no solo entre los miembros del proyecto, sino también con el apoyo de proveedores. El equipo FX-3500 los invitó a unirse al proyecto desde el principio (eventualmente produjeron 90% de las piezas del modelo). 

Cada lado regularmente visitó las plantas del otro y guardó la información en un canal abierto en todo momento. Este tipo de intercambio y apertura, tanto dentro del equipo del proyecto como con proveedores: aumenta la velocidad y la flexibilidad. Fuji-Xerox acortado el tiempo de desarrollo de 38 meses para un modelo anterior a 29 meses para el FX-3500. 

Si sashimi define el enfoque Fuji-Xerox, entonces el rugby describe la superposición en Honda. Como un equipo de rugby, los miembros principales del proyecto en Honda se quedan intactos de principio a fin y son responsables combinando todas las fases.

En el sistema PPP similar a un relé, los problemas cruciales tienden a ocurrir en los puntos por donde pasa un grupo el proyecto al siguiente. El enfoque del rugby se suaviza al resolver este problema manteniendo la continuidad a través etapas.

El proyecto Auto Boy procedió con mucho traslapando fases también. La ingeniería de diseño de Canon y los usuarios se mantuvieron alerta durante todo el proceso para hacer seguro que su diseño se estaba convirtiendo en lo que ellos tenían en mente. La gente de producción se entrometió en el césped de los ingenieros de diseño para asegurarse de que el diseño estaba de acuerdo con las economías de escala de producción.

El enfoque superpuesto tiene tanto méritos como deméritos. Mayor velocidad y mayor flexibilidad son las Méritos “duros”. Pero el enfoque también tiene un conjunto de Méritos “blandos” relacionados con la gestión de recursos humanos. El enfoque de superposición mejora la respuesta compartida dando visibilidad y cooperación, estimula la participación y compromiso, agudiza un enfoque en la resolución de problemas, fomenta la toma de iniciativas, desarrolla habilidades diversificadas y aumenta la sensibilidad hacia las condiciones del mercado. Los deméritos más obvios resultan de tener que gestionar un proceso intensivo. Los problemas incluyen comunicarse con todo el equipo del proyecto, mantener en estrecho contacto con los proveedores, preparando varios planes de contingencia y manejo de sorpresas. 

Este enfoque también crea más tensión y conflicto en el grupo. Como lo expresó acertadamente un miembro del proyecto, uno del desarrollo piensa que 1 de cada 100 es bien, esa es una clara señal de seguir adelante. Pero si alguien.., uno de producción piensa que 1 de cada 100 no está bien, tenemos que empezar de nuevo. Esta brecha en la percepción crea conflicto. La superposición de fases también elimina nociones tradicionales sobre la división del trabajo. División de mano de obra funciona bien en un sistema de tipo A, donde La gestión delinea claramente las tareas, espera todos los proyectos. miembros para conocer sus responsabilidades y evaluar ates cada uno de forma individual. Bajo un tipo B o C sistema, la empresa realiza las tareas a través de lo que llamamos "división compartida del trabajo", donde cada El miembro del equipo se siente responsable y es capaz de trabajar en cualquier aspecto del proyecto.

Multi aprendizaje

Porque los miembros del equipo del proyecto permanecen cerca en contacto con fuentes externas de información, es que pueden responder rápidamente a las condiciones cambiantes del mercado. Los miembros del equipo participan en un proceso continuo de prueba y error para reducir el número de alternativas que deben considerar. También adquieren amplios conocimientos y habilidades diversas, que les ayudan a crear un equipo versátil capaz de resolver una serie de problemas rápido.

Tal aprender haciendo se manifiesta a lo largo de dos dimensiones: en varios niveles (individual, grupal,

y corporativo) y en múltiples funciones. Nosotros referimos a estas dos dimensiones del aprendizaje como "multilearning".

Aprendizaje multinivel. Aprendiendo a nivel individual El nivel se lleva a cabo de varias formas. 3M, por ejemplo, anima a los ingenieros a dedicar el 15% de sus tiempo de la empresa para perseguir su "sueño". Canon utiliza la presión de los compañeros para fomentar el aprendizaje individual. Un ingeniero de diseño para el proyecto PC-10 explicó, "Mi gerentes senior y algunos de mis colegas realmente estudian mucho. No hay forma de que pueda competir con ellos en la cantidad de libros que leyeron. Así que siempre que tengo tiempo, voy a una tienda departamental y paso varias horas en el departamento de juguetes. Observo lo que se vende y echo un vistazo a los nuevos dispositivos que se utilizan en los juguetes. Es posible que me den una pista o dos más adelante ". 

El aprendizaje se persigue enfáticamente a nivel de grupo. también. Honda, por ejemplo, envió varios miembros del equipo del proyecto City a Europa durante tres semanas cuando el proyecto llegó a un callejón sin salida en la fase de desarrollo del concepto. Se les dijo simplemente para "mirar alrededor de lo que está sucediendo en Europa". Allí se encontraron con el Mini-Cooper, un pequeño automóvil desarrollado hace décadas en el Reino Unido que tuvo un gran impacto en su filosofía de diseño. Mientras desarrollaban la copiadora PC-10, Canon Los miembros del equipo dejaron las oficinas del proyecto para celebrar una número de reuniones en hoteles cercanos. En una de las reuniones tempranas, todo el equipo del proyecto se dividió en subgrupos, cada uno con un representante del equipo de diseño y el equipo de producción. A cada subgrupo se le dijo que calcule el costo de una pieza clave y averigüe formas de reducir ese costo en un tercio. "Dado que cada subgrupo enfrentó el mismo mandato y los mismos lineamientos, no teníamos otra opción”, recordó un miembro del proyecto. El aprendizaje tuvo lugar a toda prisa.

El aprendizaje a nivel corporativo se logra mejor mediante establecer un movimiento o programa en toda la empresa. Fuji-Xerox, por ejemplo, utilizó el concepto de control de calidad total (TQC) como base para cambiar la mentalidad corporativa. TQC fue diseñado para aumentar la sensibilidad de toda la organización hacia la simultaneidad mejora de la calidad y la productividad, orientación, reducción de costos y simplificación del trabajo. Para lograr estos objetivos, todos en la organización tuvieron que aprender los conceptos básicos de técnicas como control estadístico de calidad e ingeniería de valor.

Hewlett-Packard se embarcó en un tren de un programa de cuatro fases de entrenamiento en marketing como parte de la corporación aspiran a estar más orientados al mercado. La empresa ahora atrae a los mejores académicos y consultores de negocios para difundir el mensaje de marketing. También se aplican técnicas tomadas prestadas del consumidor empaquetadas en la industria de bienes, como entrevistas a grupos focales, investigación de mercado valiosa y marketing de prueba. Más, la empresa ha creado una división de marketing corporativo para acelerar lo que un conocedor llama "la transición de una empresa dirigida por ingenieros para ingenieros a uno con un enfoque de marketing más sólido".

Aprendizaje multifuncional. Se anima a los expertos a acumular experiencia en áreas distintas a la suya propia. Por ejemplo:

• Todos los miembros del proyecto que desarrollaron la primer Epson mini printer fueron ingenieros mecánicos que sabían poco sobre electrónica al principio. Entonces el líder del equipo del proyecto, también un ingeniero mecánico, regresó a su alma mater como investigador y estudió ingeniería eléctrica durante dos años. Él hizo esto mientras el proyecto estaba en marcha. Para el momento habían completado el proyecto de mini printer, todos los ingenieros tenían conocimientos sobre electrónica."Le dije a mi gente que esté bien versada en dos campos tecnológicos y en dos áreas funcionales, como el diseño y el marketing”, dijo el líder. “Incluso en una ingeniería de empresas orientada como la nuestra, no puede salir adelante con- la capacidad de prever desarrollos en el mercado."
• El equipo que trabajaba en el PC 8000 de NEC estaba formado por ingenieros de ventas de la División de Dispositivos Electrónicos. Adquirieron gran parte del know-how para desarrollar la primera computadora personal de la empresa juntos TK 80, un equipo de computadora, y presentando en el mercado dos años antes que el PC 8000; y al estacionarse durante aproximadamente un año, incluso los fines de semana, en BIT-IN, un centro de servicio de NEC en el medio de Akihabara, hablando con aficionados y aprendiendo el punto de vista del usuario.

Estos ejemplos muestran el importante papel que desempeña el multi aprendizaje y como juega en el programa de gestión de recursos humanos de la empresa. Fomenta la iniciativa y el aprendizaje haciendo parte de los empleados y ayudando a mantenerlos actualizados con los últimos desarrollos. También sirve como base para crear un clima que puede provocar la transición organizativa.

Resultados corporativos de rugby

Algunas empresas ya están avanzando en acelerar el desarrollo de nuevos productos:

• Una nueva fotocopiadora, la 9900, llevó a Xerox tres años desarrollar, mientras que la empresa gastó más de cinco años desarrollando un modelo anterior comparable.
• Se desarrolló una impresora Brother portátil, la EP-20, abierto en menos de dos años. Le tomó a la empresa más de cuatro años para desarrollar un modelo anterior.
• Una de las principales prioridades de John Sculley, cuando es nombrado presidente de Apple en 1984, iba a cortar la empresa tiempo de desarrollo del producto de 3,5 años a uno año.

Otras organizaciones están comenzando a agregar flexibilidad al desarrollo de productos:

• Black & Decker presentó recientemente 50 nuevas herramientas eléctricas productos en el National Hardware Show en Chicago para competir más eficazmente con la herramienta eléctrica japonesa fabricantes.
• Cuando Yamaha amenazó su posición de liderazgo en mercado japonés en 1982, Honda lanzó algunos 30 nuevos modelos de motocicletas en un período de seis meses.
• IBM rompió con su tradición de diseñar todo internamente y utilizó un microprocesador diseñado por Intel Corporación y un sistema operativo básico diseñado por Microsoft Corporation para desarrollar su competencia personal ordenador.

Control sutil

Aunque los equipos de proyecto están en gran parte por su cuenta, no están descontrolados. La gerencia establece suficientes puntos de control para evitar la inestabilidad, la ambigüedad y la tensión de convertirse en caos. Al mismo tiempo, la gerencia evita el tipo de control rígido que perjudica la creatividad y la espontaneidad. En cambio, el énfasis está en el "autocontrol", "el control a través de los pares de presión ”y“ control por amor ”, que colectivamente lo que llamamos "control sutil".

Se ejerce un control sutil en el nuevo producto. proceso de desarrollo de siete formas:

1. Seleccionar a las personas adecuadas para el equipo del proyecto mientras se monitorean los cambios en la dinámica del grupo y agregar o eliminar miembros cuando sea necesario. “Agregaríamos un mayor y más conservador miembro del equipo si el equilibrio cambia demasiado hacia el radicalismo", dijo un ejecutivo Honda, “elegimos cuidadosamente a los miembros del proyecto después de una larga deliberación. Analizamos las diferentes personalidades para ver si conseguirían a lo largo de. La mayoría de la gente se lleva bien, gracias a nuestro conjunto común de valores".
2. Crear un entorno de trabajo abierto, como en el caso de Fuji-Xerox.
3. Alentar a los ingenieros a salir al campo y escuchen lo que tienen que decir clientes y distribuidores. “Un ingeniero de diseño puede tener la tentación de tomar el camino más fácil a veces, pero puede reflejar sobre lo que el cliente tenía que decir y tratar de encontrar alguna forma de cumplir con ese requisito", señaló un ingeniero de Fuji-Xerox.
4. Establecimiento de un sistema de evaluación y recompensa basado en el desempeño del grupo. Canon, por ejemplo, solicitó patentes para productos del Proyecto PC-10 en grupo.
5. Manejar las diferencias de ritmo a lo largo del proceso de desarrollo. Como se mencionó anteriormente, el ritmo es más vigoroso en las primeras fases y se va reduciendo hacia el final.
6. Tolerar y anticipar errores. Ingenieros en Honda les gusta decir que “un 1% de la tasa de éxito está respaldada por errores cometidos el 99% de la hora." Un ejecutivo de Brother a cargo de I + D dijo: "Es natural que los ingenieros jóvenes cometan muchos errores. La clave está en encontrar el error temprano y tomar medidas para corregirlos inmediatamente. Hemos tomado medidas para acelerar el ciclo de producción de prueba por esa razón ". Un ejecutivo de 3M señaló: "Creo que aprendemos más de errores que de aciertos. Eso no quiere decir que debemos cometer errores fácilmente. Pero si lo hacemos, cometer errores, debemos cometerlos activamente".
7. Alentar a los proveedores a que se auto organicen e involucrarlos desde el principio durante el diseño es un paso en la dirección correcta. Pero el equipo del proyecto debe abstenerse de decirles a los proveedores qué hacer. Como descubrió Xerox, los proveedores producen mejores resultados cuando tienen el problema explicado a ellos y se les permite decidir cómo terminan las piezas.

Transferencia de aprendizaje

El impulso de acumular conocimientos en todos los niveles y funciones es solo un aspecto del aprendizaje. Nosotros observamos un impulso igualmente fuerte por parte de los miembros del proyecto para transferir su aprendizaje a otros fuera del grupo. 

La transferencia del aprendizaje hacia el subsecuente proyecto de desarrollo del nuevo producto u otras divisiones de la organización se lleva a cabo con regularidad. En varias de las empresas que estudiamos, la transferencia se llevó a cabo a través de "ósmosis”, asignando individuos clave a los siguientes proyectos. Un ejecutivo de Honda explicó: "Si la fábrica está en funcionamiento y las reclamaciones del período inicial están resueltas, desmantelamos el equipo del proyecto, dejando solo algunas personas para seguir adelante. Dado que solo tenemos un número limitado de personas inusualmente capaces, los convertimos parte de otro proyecto clave de inmediato".

El conocimiento también se transmite en la organización convirtiendo las actividades del proyecto en una práctica estándar.  En Canon, por ejemplo, el proyecto Auto Boy pre-elaboró ​​un formato para realizar revisiones que se utilizó en proyectos posteriores. Un miembro del equipo recordó: "Nosotros solíamos  reunirnos una vez al mes para intercambiar notas sobre subproyectos individuales en curso y una vez más o menos cada tres meses para discutir el proyecto desde una perspectiva más amplia. Este patrón más tarde se convirtió en institucional en las revisiones de progreso mensuales y trimestrales adoptado del proyecto de mini copiadoras PC-10 ".

Naturalmente, las empresas intentan institucionalizar las lecciones derivadas de sus éxitos. IBM está intentando emular el programa del proyecto de desarrollo de computadoras personales, que se completó en 13 meses sin ayuda lateral: en toda la empresa.

En Hewlett-Packard, el grupo de computadoras personales está reprogramando la forma en que toda la empresa desarrolla, opera y vende nuevos productos. En el pasado, la empresa era famosa por diseñar una máquina para un particular cliente y cobrando un precio superior. Pero su recientemente diseñó ingenieril de la ThinkJet, una impresora de inyección de tinta silenciosa para una producción en masa de bajo costo y con un precio bajo. Dentro de los seis meses de su introducción, la impresora capturó el 10% del mercado de gama baja.  Hewlett-Packard comenzó a aplicar lo que había aprendido desde el diseño y valoración en precio de la ThinkJet hasta su línea de mini computadoras. A los pocos meses de poner ThinkJet en el mercado, la empresa introdujo un sistema de mini computadora para una amplia audiencia corporativa a un modesto precio.

Pero la institucionalización, cuando se lleva demasiado lejos, puede crear su propio peligro. Transmitiendo palabras de sabiduría del pasado o el establecimiento de prácticas estándar basadas en las historias de éxito funciona bien cuando el ambiente es estable. Cambios en el medio ambiente, sin embargo, rápidamente pueden hacer que estas lecciones no sean prácticas.

Varias empresas han intentado desaprender viejas lecciones. Desaprender ayuda a mantener al equipo de desarrollo en sintonía con las realidades del entorno exterior. También actúa como un trampolín para hacer más mejoras incrementales. Gran parte del desaprendizaje se desencadena por cambios en el entorno. Pero algunas empresas conscientemente persiguen el desaprendizaje. Considere estos ejemplos:

• El objetivo de Epson es tener la próxima generación del modelo en etapas de desarrollo como un nuevo modelo está siendo introducido en el mercado. La empresa le dice a su equipos de proyecto que el modelo de próxima generación debe ser al menos un 40% mejor que el existente.
• Cuando Honda estaba construyendo la tercera generación de su modelo Civic, su equipo de proyecto optó por desechar todas las piezas viejas y empezar de nuevo. Cuando el coche hizo su debut ante el público, se exhibieron todas las piezas nuevas justo al lado del coche a petición de los miembros del proyecto. El coche ganó el premio al coche del año de 1984 en Japón.
• Fuji-Xerox ha refinado su enfoque de sashimi, primero adoptado para el FX-3500. Comparado con ese esfuerzo, un producto nuevo hoy requiere la mitad de la original mano de obra total. Fuji-Xerox también ha reducido el ciclo de desarrollo de producto de 4 años a 24 meses.

Algunas limitaciones

Algunas palabras de precaución están a la orden. El enfoque holístico para el desarrollo de productos puede no funcionar en todas las situaciones. Tiene algunas limitaciones integradas:

• Requiere un esfuerzo extraordinario por parte de todos los miembros del proyecto a lo largo del período del proceso de desarrollo. A veces, los miembros del equipo registran horas extraordinarias mensuales de 100 horas durante el pico y 60 horas durante el resto del proyecto.
• Puede que no se aplique a proyectos innovadores que requieren una innovación revolucionaria. Esta limitación puede ser particularmente cierto en intentos de biotecnología o química.
• Puede que no se aplique a proyectos gigantescos como en el negocio aeroespacial, donde el puro proyecto y su escalamiento limita las extensas discusiones cara a cara.
• Puede que no se aplique a organizaciones donde el producto del desarrollo está dirigido por un genio que hace la invención y sin duda un bien definido conjunto de especificaciones que deben seguir las personas siguientes.

Algunas limitaciones también se derivan del alcance de nuestra investigación. Nuestro tamaño de muestra se limitó a un puñado de empresas y nuestros hallazgos fueron extraídos, parte en la mayoría de los casos, de observar cómo el proceso de desarrollo se gestionó en Japón. Conclusiones generales, por lo tanto, deben hacerse con cierta precaución. Pero como los nuevos enfoques para el desarrollo de productos ganan aceptación en los Estados Unidos, la diferencia entre los países puede no ser tanto una diferencia de tipo como una diferencia de grado.

Implicaciones generales

Cambios en el medio ambiente - competencia intensificada, un mercado masivo fragmentado, una vida útil más corta en ciclos, tecnología avanzada y automatización — están obligando a las gerencias a reconsiderar el trámite de formas alternativas de crear productos. Un producto que llega unos meses tarde puede perder fácilmente varios meses de amortización. Un producto diseñado por un ingeniero nunca afligido con el síndrome del "próximo banco": el hábito de diseñar un producto preguntando al compañero de trabajo en el próximo banco, qué tipo de producto él o ella le gustaría — puede que no cumpla con los requisitos flexibles del mercado.

Para lograr velocidad y flexibilidad, las empresas deben gestionar el proceso de desarrollo de productos de forma diferente. Deben considerarse tres tipos de cambios. Primero, las empresas deben adoptar un estilo de gestión que puede promover el proceso. Los ejecutivos deben reconocer desde el principio que el desarrollo de productos se procede de manera lineal y estática. Esto implica un proceso iterativo y dinámico de prueba y error. Para gestionar dicho proceso, las empresas deben mantener un estilo altamente adaptable.  Porque los proyectos no proceden de un modo totalmente racional y de manera consistente, la adaptabilidad es particularmente importante. 

Considere, por ejemplo, situaciones en las que:

• La alta dirección fomenta la prueba y el error intencionalmente al mantener las metas amplias y tolerar la ambigüedad. Pero al mismo tiempo, establece metas desafiantes y crea tensión dentro del grupo y dentro de la organización.
• El proceso mediante el cual se amplifica la variedad (diferenciación) y reducida (integración) tiene lugar a lo largo de las fases superpuestas del ciclo de desarrollo. La diferenciación, sin embargo, tiende a dominar la fase de desarrollo del concepto del ciclo, y la integración comienza a hacerse cargo de las subsiguientes etapas.
• Las decisiones operativas se toman de forma incremental, pero las decisiones estratégicas importantes se retrasan tanto como sea posible para permitir una mayor flexibilidad de respuesta a la retroalimentación de último minuto del mercado.

Porque la gerencia ejerce formas sutiles de control durante todo el proceso de desarrollo, estas metas aparentemente contradictorias no crean una total confusión. El control sutil también es consistente con el carácter auto organizado de los equipos del proyecto. 

En segundo lugar, se requiere un tipo diferente de aprendizaje. bajo el enfoque tradicional, un grupo de especialistas altamente competente emprende el desarrollo de nuevos productos. Un grupo de élite de expertos técnicos hace más del aprendizaje. El conocimiento se acumula en una base individual, dentro de un área estrecha de enfoque, lo que llamamos aprendizaje en profundidad.

En contraste, bajo el nuevo enfoque (en su forma extrema) los no expertos emprenden el desarrollo de productos. Se les anima a adquirir los conocimientos necesarios para obtener ventaja y habilidades en el trabajo. A diferencia de los expertos, que no pueden tolerar errores ni siquiera el 1% de las veces, los no expertos están dispuestos a desafiar el statu quo. Pero para hacerlo, deben acumular conocimientos de en todas las áreas de gestión, en diferentes niveles de la organización, especializaciones funcionales e incluso los límites organizacionales. Tal aprendizaje en su amplitud sirve como condición necesaria para compartir la división del trabajo para funcionar con eficacia.

En tercer lugar, la gerencia debe asignar una diferente misión al desarrollo del nuevo producto. La mayoría de las empresas lo han tratado principalmente como un generador de flujos de ganancias futuras. Pero en algunas empresas, el desarrollo de un producto nuevo también actúa como catalizador para lograr un cambio en la organización. El proyecto de la computadora personal, por ejemplo, se dice que ha cambiado la forma en la que IBM piensa. Proyectos que salen del grupo de computadoras personales de Hewlett-Packard', incluido ThinkJet, cambió su cultura impulsada por la ingeniería.

Ninguna empresa encuentra fácil movilizarse para el cambio, especialmente en situaciones que no son de crisis. Pero la naturaleza auto trascendente de los equipos del proyecto y el ritmo frenético al que trabajan los miembros del equipo ayuda a desencadenar una sensación de crisis o urgencia en todo la organización. Un proyecto de desarrollo de importancia para la empresa, por lo tanto, puede crear un entorno de trabajo en tiempo de guerra incluso en tiempos de paz.

Los cambios que afectan a toda la organización también son difícil de llevar a cabo dentro de empresas altamente estructuradas, especialmente en las empresas basadas en la antigüedad como las que se encuentran comúnmente en Japón. Pero movimientos poco convencionales, que pueden ser difíciles de realizar en momentos de paz, puede legitimarse en tiempos de guerra. Por lo tanto, la gerencia puede desarraigar a un gerente competente o asignar un ingeniero muy joven al proyecto sin encontrar mucha resistencia.

Una vez que se forma el equipo del proyecto, comienza a crecer en estatura debido a su visibilidad ("hemos sido escogidos "), su poder legítimo (" tenemos incondicional apoyo técnico desde arriba para crear algo nuevo”), y su sentido de misión (“ estamos trabajando para resolver una crisis”). Sirve como motor para empresas cambiar como miembros del proyecto desde una variedad de funciones.

Las áreas regionales comienzan a tomar iniciativas estratégicas que a veces van más allá de lo convencional del dominio de la empresa y como su conocimiento se transfiere a proyectos posteriores.

El entorno en el que cualquier empresa multinacional —de los Estados Unidos o Japón— opera ha cambiado drásticamente en los últimos años. Las reglas del juego para competir eficazmente en el mercado mundial de hoy han cambiado en consecuencia. Las multinacionales deben lograr rapidez y flexibilidad en el desarrollo de productos; hacerlo requiere el uso de un proceso dinámico que involucre

confiar mucho en la prueba y el error y mediante el aprendizaje haciendo. Lo que necesitamos hoy es innovación constante en un mundo en constante cambio.

El deporte del rugby

Uno de los encantos del juego de Union Rugby es la infinidad de la variedad de sus posibles tácticas. Cualquiera que sea la táctica del equipo tiene como objetivo adoptar, el primer elemento esencial es un fuerte y hábil [ sic ] paquete de delanteros capaces de ganar la posesión inicial de las piezas a balón parado. Porque, con la pelota en su manos, un equipo esta en posición de dictar tácticas que hará el mejor uso de sus propios talentos particulares, al mismo tiempo investigando y exponiendo las debilidades en el equipo contrario. El equipo ideal tiene rápido y hábiles medios y tres cuartos que, con correr, pasar y patear astutamente, se asegurará de que la posesión ganada por los delanteros se emplea para la vergüenza máxima del equipo contrario.

Desde The Oxford Companion hasta World Sports and Games ed.

John Arlott (Londres: Oxford University Press) copyright © 1975 Reimpreso con permiso del editor.