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:

Inestabilidad incorporada
Equipos de proyectos auto organizados
Fases de desarrollo superpuestas
"Aprendizaje múltiple"
Control sutil
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:

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".
Crear un entorno de trabajo abierto, como en el caso de Fuji-Xerox.
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.
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.
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.
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".
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.

DSN_XP y los métodos ágiles

¿Metodologías ágiles realmente diferentes?

Documento de posición para el taller OOPSLA 2003

Jens Coldewey

Consultoría Coldewey

correo electrónico: jens_coldewey@acm.org

http://www.coldewey.com

Enfoques de una metodología

Además de considerar los procesos que una metodología supone utilizar, otro tema de interés para estudios es el modelo que subyace a la metodología. Aunque esto está estrechamente relacionado con el valor del sistema, el modelo no soporta juicio ético, como lo hace un sistema de valores.

Hay dos modelos populares para proyectos: el modelo de control y el modelo sistémico. El modelo de control asume que hay roles de dirección centralizados en un proyecto, individuos capacitados que planifican y gestionan el proyecto. Estos roles incluyen el gerente de proyecto, el arquitecto, el jefe de programación, etc. Con este enfoque, el éxito y el fracaso del proyecto depende principalmente del desempeño de estos roles de control. Me referiré a estos roles como los "gerentes", aunque esto incluye todo tipo de gestión y control.

Metodologías que utilizan este enfoque usualmente se concentran en los elementos que apoyan esta estructura:

Mejorar la comunicación entre los gerentes y los miembros del equipo operativo, como programadores.
Proporcionar estructuras de control y presentación de informes para permitir que los gerentes obtengan una buena imagen del estado del proyecto.
Asegurar que el trabajo operativo se realice de la manera más uniforme posible para facilitar la planificación, la predicción y control. Se supone que los miembros del equipo desempeñan determinados roles y se intercambian "recursos" capaces.
Clara separación de responsabilidades.

El último extremo de esta apreciación es Frederick Taylors, Scientific Management que estableció el terreno para el impulso económico del siglo pasado. La mayoría de los procesos tradicionales siguen este modelo.

Un enfoque alternativo es ver un proyecto como un sistema complejo. Los sistemas complejos tienen algunas características que las estructuras de comando y control no tienen: Su comportamiento es difícil de predecir y son muy flexibles. Controlar un sistema complejo no significa predecir y controlar cada acción única en él. Más bien significa comprender la estructura y las interrelaciones del sistema y configurarlos para que el sistema se adapte a las necesidades.

El pensamiento sistémico proporciona el conjunto de herramientas apropiado para este tipo de enfoque.

Metodologías basadas en el pensamiento sistémico, ya sea de forma consciente o no, muestran algunas propiedades típicas:

Pocas reglas. La mayoría de las reglas establecen circuitos de retroalimentación y comunicación para asegurar que todas las partes del proyecto todavía se dirigen hacia el objetivo del proyecto.
La retroalimentación y la comunicación están diseñadas para ser lo más eficientes posible, en lugar de ser rastreable o controlable.
Pocos o ningún rol centralizado o jerárquico. Se asume que los miembros del equipo están bien capacitados, personas responsables que sean capaces de organizarse.

Comparación de los enfoques de las metodologías ágiles

La siguiente lista comprueba a qué enfoque pertenecen las diferentes metodologías ágiles:

Desarrollo de software adaptativo: ASD

Es la única metodología que se basa explícitamente en la teoría de los sistemas adaptativos complejos, se limita a establecer un circuito de retroalimentación. ("Especular, colaborar, aprender") y configurar el entorno para un trabajo de proyecto eficiente. Un representante clásico del enfoque sistémico.

Metodologías Crystal:

El principal punto en común de todas las metodologías Crystal es un taller de verificación de los procesos al menos dos veces por incremento. Además, Cockburn ofrece siete principios a observar en un proyecto. Los roles y las organizaciones solo se proporcionan como sugerencias. Otro ejemplo de enfoque de sistemas

Método de desarrollo de software dinámico: DSDM

Define roles y responsabilidades explícitos como núcleo de la metodología. Se provocan bucles de retroalimentación para la entrega (entrega frecuente, todos los cambios son reversibles) pero no a nivel de proceso. Por tanto, DSMD utiliza un sistema de enfoque para dejar crecer el software pero un modelo de control para gestionar el proyecto.

Programación extrema: XP

Usa solo unas pocas reglas para configurar un entorno en el que el software puede crecer. Por tanto, la parte técnica utiliza claramente un enfoque de sistemas. En cuanto a la metodología XP mostró un desarrollo interesante en los últimos años. Aunque la metáfora de Kent Beck de "Aprender a conducir" apuntaba hacia un modelo de sistemas, declaraciones iniciales como "O haces todo como está escrito o no haces XP" a menudo se interpretaba como una señal para un modelo de control. Al darse cuenta de que estas declaraciones llevaron a XP en una dirección no deseada, la comunidad ahora acuerda la adaptación regular del proceso. Por lo tanto, XP puede ser considerada una metodología de sistemas en la actualidad.

Desarrollo impulsado por Funcionalidades: FDD

Instala el rol de programador jefe y utiliza diseños basados en actualizaciones de frente al usario. Por lo tanto, FDD en mi percepción claramente utiliza un enfoque de control en lugar de utilizar una visión sistémica, aunque definitivamente es un proceso ligero.

Desarrollo Lean:

La mayoría de las prácticas técnicas de LD son similares a lo que XP encontró útil, así que técnicamente LD también se basa en un modelo de sistemas. La gestión está muy centrada en auto organización y retroalimentación: indicadores para un modelo de sistema también.

Scrum:

Define un ciclo de retroalimentación central como instrumento de control principal que identifica a Scrum como metodología sistémica. Esto se suma al hecho de que scrum define pocos roles con el papel central del "Scrum Master" quien tiene la responsabilidad principalmente de facilitar el proceso en lugar del entregable.

Una conclusión sugerente

Sugiero definir el desarrollo ágil como una metodología basada en una visión sistémica del desarrollo de software. Esta visión conduce a los principios ágiles, así como a muchas metodologías ágiles.

Usar esta definición significaría reevaluar la comprensión actual de qué las metodologías son ágiles y las que no lo son. Según la lista anterior, esto reduciría el "completamente ágil" a metodologías como ASD, Crystal, XP en su forma actual, Lean Development y Scrum. DSDM se considerarían una metodología "técnicamente ágil" y la FDD se consideraría un proceso tradicional pesado.

DSN_XP y el BUSINESS VIEW

La perspectiva del negocio

La perspectiva para estudio del negocio DSN_XP

Una de las tres perspectivas resultantes de aplicar el método de investigación DSN_XP fue aquella que se encarga de estudiar todos los aspectos que se requieren para la administración de un negocio.

Business View

En primer lugar es necesario destacar la necesidad de utilizar perspectivas como método para poder unificar los diversos criterios existentes desde la naturaleza del negocio.

Estudiamos al negocio porque estudiamos el desarrollo de soluciones a necesidades de la organización en base al software y su técnica de generación de aplicaciones.

Cuando aplicas un modelo de desarrollo de software, por concepto de modelo de desarrollo, requieres capturar por abstracción el entorno de una realidad del negocio, para ello se supone que existe el prototipado como escuela de diseño y junto al prototipado existe la denominada captura de requerimientos previos al desarrollo del software y su límite de acción.

Business Analyst

Según el BABOK, un Business Analyst es una persona que realiza análisis de negocios, sin importar su cargo o rol organizacional.

Estos son algunos ejemplos:

Analista de sistemas,
Analista de requisitos,
Analista de procesos,
Analista de productos,
Gerente de productos,
Propietario del producto.

Pero, en última instancia, alguien que realiza las tareas descritas en el BABOK, incluidos Project Manager, Software Developer, Tester , etc., también realiza análisis comerciales.

Business Discovery

DSN_XP aplica por concepto, la ingeniería inversa al estudio de los negocios basándose en el modelado, ya que, para modelar, se requiere adoptar una o varias perspectivas y para juntar varias de ellas en un modelo, se requiere el pensar primero en la audiencia que leerá el modelo para delimitar y definir sus elementos y terminar en la conceptualización de una propuesta.

Usualmente se piensa primero en los requerimientos y luego se define la propuesta, la sutil diferencia entre los 2 conceptos radica en la explicación del secreto de la ilustración :o)

Dependiendo del movimiento de los elementos del modelo se puede obtener un cambio cuantitativo en la perspectiva.
En esta ilustración originalmente son 13 personajes, pero un cambio de perspectiva obtiene 12 personajes :o)

DSN_XP toma en cuenta este factor y concluye que: dentro de la perspectiva del negocio, es necesario utilizar la orientación a objetos para relacionar un objeto con actividades, eventos, procesamiento y sobre todo tipo de unidad de negocio.

Una unidad del negocio es un proceso que cumple una funcionalidad

La perspectiva del negocio, en los inicios de la informática, estaba destinada a resolver tareas o automatizarlas, esta forma de ver al negocio y su relación con el software o con cualquier otra estructura mental, obligó a la academia a pensar en la descomposición de tareas como la alternativa más viable para ejecutar un proyecto.

DSN_XP no critica a este método, pues sabemos que como método funciona, un ejemplo de ello es la robótica con la automatización de la industria y por ello del negocio. Ahora bien, una vez que se introduce más la tecnología computacional, comienzan a aparecer nuevos actores que influyen en la concepción de proyectos

BusinessView

Esta sección contiene los criterios fundamentales para entender los aspectos relacionados con el diseño y estudio de las organizaciones tanto como estructura administrativa, así como en aspectos relacionados con su cultura organizativa y la madurez organizacional junto al enfoque de arquitectura empresarial.

Para lograr comprender una organización desde el concepto de perspectiva fue necesario desarrollar un estudio de todos aquellos aspectos que directa o indirectamente impactan en la industria, en los negocios y por defecto en las organizaciones.

DSN_XP originalmente fue diseñada como metodología para el estudio del software, sin embargo, al profundizar los artefactos para capturar los requerimientos del software, fue necesario desarrollar nuevas competencias que están relacionadas con la transferencia de conocimientos sobre los procesos de la organización, desde el cliente hacia el equipo de desarrollo.

DSN_XP aplica por concepto, la ingeniería inversa al estudio de los negocios basándose en el modelado; para modelar, se requiere adoptar una o varias perspectivas, comprendiendo que una perspectiva implica una forma de mirar el fenómeno observado y que por lo tanto se debe modelar una vista y que, para juntar varias perspectivas que definen el modelo, se requiere el pensar primero en la audiencia que leerá el modelo para con ello definir los elementos del modelo y terminar en la definición de una propuesta. Usualmente se piensa primero en los requerimientos y luego se define la propuesta, la sutil diferencia entre las dos formas de observar un evento radica en la explicación del secreto de la siguiente ilustración :o)

DSN_XP toma en cuenta este factor y concluye que, dentro de la perspectiva del negocio, es necesario utilizar la orientación a objetos para relacionar un objeto con actividades, eventos, procesamiento y sobre todo tipo de unidad de negocio.

DSN_XP no critica a este método, pues sabemos que como método funciona, un ejemplo de ello es la robótica con la automatización de la industria y por ello del negocio. Sin embargo, el método descendente no es suficiente para desarrollar software debido al concepto de acoplamiento.

El concepto de acoplamiento hace referencia en la ingeniería del software, al diseño estructural del sistema basado en las interrelaciones y por ende en una dependencia funcional (matemáticamente hablando) de sus componentes para responder a un flujo de acciones conocidas como algoritmo y a un conjunto de eventos que cambian como resultante de aplicar la función lógica del sistema. Este es un concepto de la ingeniería mecánica que determina que un acople permite adaptar funcionalmente dos elementos que sin dicho acople no podrían funcionar.

Para lograr mediante un diseño adecuado optimizar una organización, se requiere entender a la organización y sus procesos y esta es justamente la razón por la cual como DSN_XP creamos la perspectiva del negocio o Business View.

Ahora bien, una vez que se introduce más la tecnología computacional, comienzan a aparecer nuevos actores que influyen en la concepción de proyectos.

Las investigaciones que hemos realizado bajo esta perspectiva están respaldas en investigaciones continuas en libros y demandas como elementos del diseño holístico basado en perspectiva como:

La administración del conocimiento en la organización.
La madurez administrativa y el modelo CMMI
La madurez administrativa y el modelo COBIT
La madurez administrativa y la normativa ISO
La madurez administrativa y el modelo ITIL
La madurez administrativa y el modelo OPM
La administración de negocios y la gestión del cambio
La administración de negocios y el control
El diseño de negocios
El descubrimiento del negocio
La organización del negocio
La cultura organizacional
La administración de procesos de negocio
Herramientas de modelado de negocio
El lenguaje de procesos de negocio bpel
La unificación de modelos BPM/SOA
BPMN 20
Estándares de negocios
La ingeniería de procesos
La OMG
Los patrones de diseño
Las tools
Los talleres
Los proyectos de negocios
Los requerimientos de negocios
Los riesgos en los negocios
La seguridad en los negocios
Emprendimiento y negocios
Los valores de negociación