Principios del modelado de negocios

Una vez que entiendes quién es "Dios", debes tener paciencia con Dios. Las personas que se especializan en ciencias e ingeniería generalmente son mejores en pensamiento lógico, pero para las partes interesadas, este no es necesariamente el caso. Una vez me encontré con una parte interesada que estaba haciendo trabajo de archivo. Al comprender los requisitos, divagaba y era vago. El método que fue claramente rechazado en un minuto se volvió a proponer al minuto siguiente. Pensé que tenía buen temperamento, pero al final casi pierdo los estribos. Afortunadamente, finalmente logré sobrevivir. Creo que después de experimentar este incidente, mi índice de paciencia mejorará enormemente.

Tengo un colega cuya paciencia admiro. En un proyecto de sitio web, era responsable del análisis del sistema. Pasó tres días completos conviviendo con el responsable del proyecto del sitio web. Después del análisis final del sistema, estaba de buen humor, pero el responsable estaba muriendo. Por supuesto, esto es sólo una broma, no para animar a todos a trabajar duro. El equilibrio entre trabajo y descanso sigue siendo muy importante. El cuerpo es la capital de la revolución. Pero esto nos dice que si falta paciencia, es difícil tener éxito en la demanda. Por ejemplo, en un seminario de modelado de negocios, aunque usted estipuló que en esta reunión se discutirán requisitos de alto nivel, los participantes siempre discutirán sobre asuntos triviales de vez en cuando. ¿Qué deberías hacer? Creo que esta situación es muy común.

Al final, la paciencia seguirá reflejándose en la comunicación. Sólo a través de la comunicación paciente podrás descubrir el velo de las necesidades. El comportamiento de las personas siempre estará guiado por sus pensamientos. Si no puedes desatar el nudo de la parte interesada, no podrás comprender lo que realmente necesita.

Una de las partes interesadas de mi proyecto se comporta de manera muy extraña. Siempre dice una cosa: quiere generar informes automáticamente. Sus necesidades parecían estar dentro de este rango, pero no escuché casi nada más de ella. En ese momento, decidí rendirme. Pensé que tal vez no hubiera más información de ella. Pero después de enterarme de que el procesamiento de informes consumía mucho de su tiempo en el trabajo, cambié de opinión. Después de pasar algún tiempo ayudándola a aclarar sus pensamientos sobre el procesamiento de informes, también me brindó mucha ayuda en otros aspectos. Una práctica importante del método XP es promover "clientes en el sitio". Es decir, el cliente debe estar con el desarrollador en todo momento para facilitarle información y tomar decisiones. Y este cliente también debe ser un experto en la materia y poder tomar decisiones con autoridad.

Los clientes locales creen que la mayoría de las organizaciones de software nacionales no pueden hacer esto. Pero debemos trabajar duro en este sentido. En mi opinión, hay dos tipos de clientes in situ: uno son las partes interesadas del proyecto y el otro son los expertos de la industria. De hecho, muchas empresas de software cuentan con algunos consultores de gestión que son expertos en la industria. Según las estadísticas, la proporción entre consultores y desarrolladores en las empresas de software de la provincia de Guangdong ha llegado a 3:1. Creo que esto es algo bueno. Las partes interesadas del proyecto suelen tener un conocimiento profundo de los aspectos transaccionales de su trabajo, pero es difícil elevarlo a un nivel teórico. En este momento, se necesita la ayuda de algunos expertos de la industria. Permitir que los expertos de la industria y las partes interesadas del proyecto discutan juntos también puede inspirar a las partes interesadas del proyecto a pensar en aspectos en los que nunca habían pensado. Este es el desarrollo de la "demanda latente". Por otro lado, la participación también significa que las partes interesadas del proyecto deben dedicarse de todo corazón al proceso de modelado empresarial y ser capaces de movilizar su entusiasmo. Por lo tanto, un proceso demasiado complejo obstaculizará la participación de las partes interesadas. Por lo tanto, es necesario utilizar algunos artefactos simples que los clientes puedan aceptar para el modelado de negocios. He dicho que los "protagonistas" y los "casos de uso" discutidos anteriormente son teorías y son para que los desarrolladores los vean, para que los desarrolladores puedan tener una idea clara. Si muestra esto a las partes interesadas, ¿lo entenderán? Para cuando comprendan este mecanismo, me temo que el lirio de día estará frío. Las tarjetas de historia de usuario, funciones y CRC son muy buenos artefactos, son simples y pueden satisfacer las necesidades. Punto de conocimiento: Tanto los materiales como las características expresan un requisito simple del usuario, que puede completarse en un corto período de tiempo. Los materiales son artefactos en el método XP y las características son artefactos en el método FDD. CRC es la abreviatura de clase, responsabilidad y colaborador. Es una tarjeta dividida en tres partes, que marcan respectivamente el nombre de la clase, la responsabilidad de la clase y la relación de cooperación entre clases. Está muy cerca de los clientes e incluso puedes completar la tarjeta durante el juego, lo que puede generar una fuerte participación de los clientes. Creo que esto será criticado unánimemente por los desarrolladores. Después de todo, cambiar los requisitos es una de las cosas que más odian los desarrolladores. Sí, yo también lo odio. Sin embargo, así como solemos decir “llorar no puede resolver el problema”, ¿puede el odio resolver el problema? Rechazar la solicitud de cambio del cliente y exigirle que firme la especificación de requisitos. Estas prácticas sólo pueden ser contraproducentes. No hay ningún significado positivo.

La gestión del cambio de requisitos necesarios es importante. Porque los cambios interminables e incontrolados provocarán inevitablemente un enorme desperdicio de recursos. Pero, por otro lado, el criterio para aceptar los cambios en la demanda debe ser "si es razonable", y los cambios en la demanda requieren que nuestro trabajo de desarrollo se lleve a cabo de manera iterativa, incluidos los requisitos, el diseño, la implementación y otras etapas. De esta manera se puede minimizar el riesgo de cambio. Discutiremos esto más a fondo cuando analicemos el modelado de requisitos específicos.

El siguiente nivel para aceptar el cambio es anticipar los cambios con antelación. Desarrollar una lista de posibles cambios para documentar los posibles cambios. El ejemplo más simple es que después de que una empresa desarrolla un sistema de compras, ventas e inventario, espera desarrollar un sistema de contabilidad para conectarse a él. Si puede dejar algunos presagios por adelantado, creo que puede ahorrar mucho esfuerzo. Otra forma de estimar el cambio es mediante el uso de patrones. Pero recuerde, no abuse de los patrones. Estos son temas fuera de tema y me centraré en este aspecto en otros artículos si tengo la oportunidad. 7. Práctica del modelado de negocios (Práctica) Las reuniones son el medio más importante para el modelado de negocios. Aunque las reuniones siempre han sido estigmatizadas en China, siempre que estén bien organizadas, son un medio de comunicación muy eficaz. Una reunión de modelaje es una reunión a gran escala; en otras palabras, todas las personas relevantes deben participar en la reunión. Porque durante el período de modelado de negocios, el objetivo principal es establecer requisitos de alto nivel para el sistema, lo que requiere la participación conjunta de muchas partes interesadas del proyecto para garantizar la amplitud de los requisitos. Por tanto, la escala de la conferencia de modelaje es bastante grande. Financiadores, altos directivos, gerentes, usuarios directos, desarrolladores, todos deberían asistir o enviar representantes a la reunión de modelado.

Si alguna vez ha participado en una reunión grande, sabrá que cuanto más grande es la reunión, menor es la eficiencia en la toma de decisiones. Esto es normal. Porque cuando estás solo, no hay necesidad de comunicarse y la toma de decisiones es más eficaz. Cuando dos personas están juntas, necesitan tiempo para comunicarse y tomar decisiones. Cuando somos tres personas, tardaremos más en comunicarnos y llegar a un acuerdo. Si son cuatro, cinco o incluso diez o veinte personas, la mayor parte del tiempo se dedicará a la comunicación. Es más, todavía existen diferencias de ideas y conflictos de intereses entre las personas. Por lo tanto, para asegurar la eficiencia y eficacia de la reunión se deben seguir ciertas reglas:

· Esté preparado: Si va a tener una reunión y los participantes ni siquiera saben el contenido, ¿qué ¿lo harás? Primero tienes que dedicar mucho tiempo a explicar el propósito de tu reunión, ¿verdad? El tema y la agenda de la reunión, junto con el aviso de la reunión, deben enviarse a los asistentes con anticipación para que puedan estar preparados y llegar rápidamente al punto en el que comienza la reunión.

·Invita a tanta gente como sea posible: He dicho que una reunión de modelaje no es una reunión exitosa si no se escucha el mayor abanico de opiniones posible. Pero, en realidad, esto suele ser difícil de lograr. Debido a que la organización objetivo, como cliente, suele ser muy insistente, es simplemente imposible que todos estén presentes antes de comprender plenamente la importancia de la reunión. Objetivamente hablando, pueden existir motivos como viajes de negocios, vacaciones, asuntos importantes, etc. que hagan imposible realizarlo. Aquí, por un lado, es necesario aclarar los intereses y daños a los responsables de la toma de decisiones de la organización objetivo y dejar que les presten atención. Por otro lado, también es necesario invitar proactivamente a participar a las partes interesadas del proyecto. Como es imposible invitar a todos, intenta invitar a tantos como sea posible.

·Separar los niveles de asistentes: Me gustan mucho las salas de conferencias que tienen un círculo interior y un círculo exterior. Como me es imposible invitar a todos, primero tengo que asegurarme de que todo el personal central pueda estar presente y sentarse en el círculo interior, y luego el personal secundario se siente en el círculo exterior. Las personas clave son el tipo de personas que están estrechamente relacionadas con su proyecto. Por ejemplo, en el sistema financiero, el director financiero es el personal central. Es necesario asegurar que todo el personal central esté presente, y en cuanto al personal secundario, cuanto más completo mejor.

·Empezar desde abajo: los chinos tienen una mala costumbre, es decir, cuando el jefe dice uno, nunca dirá dos. Así que dejemos que el nivel inferior hable primero, luego el nivel medio y luego el nivel superior. Los desarrolladores no hablan, escuchan o guían a todos para que hablen. Si dejamos que los líderes nos sermoneen desde el principio, entonces la gente de abajo no tendrá que decir nada más.

·Enumere todas las opiniones de todas las partes interesadas: primero, permita que todos puedan hablar libremente sobre el nuevo sistema y luego enumere todas las opiniones en la pizarra. Puede que aquí haya algunas ideas que sean ridículas, pero está bien, simplemente escríbelas. Este es un proceso de lluvia de ideas y es fácil generar nuevas ideas. El trabajo principal del desarrollador de hosting es guiar y animar a todos a expresar más ideas y registrarlas. Digamos un poco aquí. Algunas personas dicen que la mayoría de los chinos son reacios a expresar sus opiniones en reuniones. No creo que deba preocuparse demasiado por esto en este tipo de reuniones de modelaje. ¿Por qué? Porque los interesados ​​en el proyecto no tienen por qué asumir ninguna responsabilidad por sus discursos. Si lo dices, será en vano. Quien no lo diga, será en vano.

·Ideas de categoría: las partes interesadas de tu proyecto deben estar un poco cansadas, sus ideas casi se han agotado y tu pizarra probablemente esté llena. Pero si miras las ideas en la pizarra, muchas se repiten y muchas son similares. Por tanto, es necesario utilizar conceptos lógicos para categorizar estas ideas. También puedes guiar a todos para que hagan este trabajo.

·Priorizar: Priorizar ideas también es muy importante. Puede ayudarle a identificar riesgos importantes y proporcionar orientación a la hora de desarrollar planes de iteración. Una vez más, este trabajo también debería ser determinado por las partes interesadas del proyecto.

·Investigando la lógica empresarial principal: ¿Cuál es la lógica empresarial principal? Incluye los principales procesos comerciales de la empresa, las principales reglas comerciales y los principales algoritmos. Toda esta es información que debe quedar clara desde el principio y debe entenderse en la sesión de modelado. Por supuesto, no puede decirles a las partes interesadas de su proyecto, esto, a continuación, hablemos de la lógica empresarial principal. Las partes interesadas que aparecen a continuación deben quedarse rascándose la cabeza.

Aún debes guiar a las partes interesadas y capturar la información que necesitas a partir de sus palabras.

·Presta atención al horario de reunión: las personas no son máquinas y se cansarán. Por eso, controlar la duración de las reuniones es fundamental. Generalmente, este tipo de reuniones duran cuatro o cinco horas. Según las estadísticas, las reuniones de dos horas no provocan fatiga. Por tanto, la reunión debería dividirse en segmentos cortos. Además, también puedes decidir el número de personas que participarán en cada reunión corta en función del progreso de la reunión. Porque, a medida que avanza la reunión, algunos asistentes pierden importancia.

·Evitar detalles: El objetivo principal de la sesión de modelado es establecer requisitos de alto nivel. Si se dedica demasiado tiempo a discutir asuntos triviales, será una pérdida de tiempo para todos. No tiene mucho sentido investigar los detalles de los requisitos en este momento. Porque todavía no entiendes muchas cosas y necesitas profundizar más. Los detalles en este punto no le serán de mucha ayuda.

·Evitar la tecnología: durante una reunión de modelado, conocí a un interesado responsable de la tecnología. Siempre preguntaba sobre la arquitectura técnica del sistema y promocionaba sus conceptos de diseño. Debo reiterar varias veces que encontraremos tiempo para discutir las cuestiones técnicas por separado. Creo que el técnico debería tener una mejor idea y esperar hacerlo bien. Esto es comprensible. Pero este no es el momento de hablar de tecnología. Los requisitos aún no se han aclarado. ¿No es hablar de implementación de tecnología poner el carro delante del caballo?

·Lleva registros: Como dice el refrán, una buena memoria es peor que una mala escritura. Por eso es muy importante tomar buenas notas durante la reunión. Debido a que el costo de tales reuniones es bastante alto, es imposible que las partes interesadas de su proyecto no trabajen todos los días y lo acompañen a las reuniones. Incluso si están dispuestos, sus jefes no lo harán. Por lo tanto, para aprovechar al máximo los resultados de la reunión, es absolutamente necesario un excelente taquígrafo. Además, las investigaciones muestran que el uso de una grabadora hará que los participantes se sientan reacios a hablar, así que no utilice una grabadora. Puede parecer extraño mencionar las pruebas en las etapas iniciales de los requisitos. Para cada proyecto, siempre existe un estándar para evaluar si tiene éxito. Las pruebas aquí se refieren a un objetivo de ejecución para evaluar el éxito de un proyecto de software.

Este objetivo será la condición final que debe cumplir el desarrollo de software, y el criterio para determinar si el software tiene éxito o no. Muchas empresas no tienen un objetivo relativamente claro al construir tecnología de la información. Por lo tanto, cuando se le pregunta sobre este tema, su respuesta a menudo son palabras vacías, como "Mi objetivo es construir el sistema ERP de la empresa y construir la plataforma de información de la empresa". ¿Cómo desarrollar dicho software? No existe un estándar para terminar. ¿Terminará cuando se agoten las tarifas o se detendrá cuando los responsables de la toma de decisiones digan que se detendrá? Las metas deben tener un estándar cuantificable. Por ejemplo, el propósito de desarrollar un sistema de logística es acortar el ciclo de rotación de productos y reducir el inventario; el propósito de desarrollar un sistema de cadena de suministro es fortalecer las conexiones con los proveedores y reducir el inventario. Estos indicadores relacionados con negocios específicos se pueden refinar y medir utilizando múltiples subindicadores, para poder lograrlos.

A este objetivo lo llamamos prueba para recordar a los desarrolladores que alcanzar este objetivo debe considerarse como la prueba final. No importa qué tan bueno sea su software, si no es lo que quieren las partes interesadas, ¿de qué sirve? Esta es una verdad muy simple, pero en la práctica, las partes interesadas y los desarrolladores a menudo no lo ven debido a algunos factores específicos. De hecho, también hablamos de este objetivo en el artículo anterior, lo llamamos visión y alcance. Es esencialmente lo mismo. Este "objetivo ejecutable" se puede medir utilizando varios factores: Las entidades comerciales son categorías en una empresa que desempeñan un papel clave. Clientes, proveedores, empleados, pedidos, vales, hay muchos ejemplos de este tipo de entidades comerciales. Las entidades comerciales a menudo se convierten en un factor muy crítico, porque en el sistema, el comportamiento de las funciones que operan las entidades comerciales a menudo se asigna a entidades comerciales. Por ejemplo, el "cálculo de precios basado en pedidos" lo completarán varias entidades comerciales en cooperación entre sí. . Por tanto, la calidad del diseño de la entidad empresarial tendrá un gran impacto en el sistema.

El trabajo principal del diseño de una entidad comercial incluye encontrar la entidad comercial y determinar los atributos y comportamientos de la entidad comercial.

Para determinar la entidad comercial, primero debe determinar la función y descubrir la entidad comercial a partir del comportamiento de la función. El rol requiere que tengamos una discusión sobre la organización objetivo. En mi experiencia personal, generalmente es más fácil encontrar roles comerciales, pero recuerde que una persona puede desempeñar varios roles comerciales, lo que suele ser el caso. A partir del comportamiento del rol comercial, podemos descubrir qué maneja el rol comercial. Estas son las entidades comerciales que necesitamos. Vale la pena estudiar si la entidad comercial es una entidad comercial separada o un atributo de la entidad comercial. Si algo que se supone que es un atributo se juzga como una entidad comercial, solo traerá algunos gastos generales. Sin embargo, si una entidad comercial que debería enumerarse por separado se juzga simplemente como un atributo de otras entidades comerciales, puede resultar desastroso. consecuencias, la mayor posibilidad es que el sistema sea difícil de expandir.

En un sistema de gestión de recursos humanos, la clase de empleado puede ser una entidad comercial muy importante y puede tener muchos atributos. En otros sistemas, como los de compra, venta e inventario, la clase de empleado sólo desempeña un papel en la gestión de registros y autoridades. Por poner otro ejemplo, en algunos sistemas internos de procesamiento automatizado de empresas, los clientes pueden ser simplemente atributos de otras entidades. Sin embargo, en el siglo XXI, donde el diseño centrado en el cliente es popular, este diseño tiene sus defectos fatales.

Para determinar los atributos y comportamientos de las entidades comerciales, se trata principalmente de determinar qué hace cada clase (entidad comercial). Los atributos sirven para describir mejor la clase y lo que hace la clase. Usar tarjetas CRC es una buena idea. CRC es la abreviatura de "clase", "responsabilidad" y "colaborador". Esta información suele presentarse en una tarjeta. Nombre de clase Responsabilidad 1 Auxiliar 1 de Responsabilidad 1 Responsabilidad 2 Auxiliar 2 de Responsabilidad 2... Al hacer una tarjeta CRC de este tipo, es más fácil conocer el comportamiento (responsabilidad) y los atributos (auxiliares) de cada entidad comercial. Quizás se pregunte por qué no simplemente descubrir las propiedades y comportamientos en lugar de pasar por todos los problemas. Esta cuestión es la que hemos estado enfatizando. En la etapa de modelado, nos enfrentamos a partes interesadas que tal vez no comprendan la tecnología informática en absoluto. Por lo tanto, el uso de métodos que sean fáciles de aceptar para todos puede garantizar que los requisitos sean completos y correctos. En el desarrollo de software, existen dos conceptos erróneos extremos sobre la planificación. En algunas organizaciones de software, generalmente no se hacen planes, o se hacen algunos planes generales e inútiles. Algunos desarrolladores creen que la planificación es inútil y que es mejor hacer cosas prácticas. Para el director del proyecto, o no hay forma de abordar esta situación, o los desarrolladores del plan publicado trabajan en contra del plan, lo que convierte el plan en letra muerta. Hay una gran arbitrariedad en la ejecución de los proyectos y a menudo suceden cosas que se desvían de la dirección.

En otras organizaciones, la planificación se considera una prioridad absoluta, requiere mucho tiempo y mano de obra, y se puede decir que los planes elaborados son meticulosos y exhaustivos. Y los gerentes de proyectos que pueden redactar un plan de este tipo también se consideran talentos senior. El desarrollador suspiró y dijo: "Quienes escriben programas no son tan buenos como quienes escriben documentos". Sin embargo, durante la ejecución, el sofisticado plan original a menudo estaba lleno de lagunas y el progreso del proyecto se retrasaba una y otra vez. Todos conocemos el dicho obvio: en el desarrollo de software, dedique el 90% del tiempo a completar el 90% del proyecto y luego otro 90% del tiempo a completar el 10% restante del proyecto. ¿Por qué? El plan no es científico.

En gestión, la planificación, también llamada planificación, se define como “el proceso de determinar los objetivos de una organización y las estrategias, medios, pasos y procedimientos para alcanzarlos”. Por ejemplo, quiero empujar una caja a un lugar. Este lugar es mi objetivo. Para llegar allí, necesito estimar la ruta y la velocidad a la que debo empujarla. Luego comencé a presionar y compararlo con el plan original de vez en cuando para ver si necesitaba ajustar la ruta y la velocidad. Esta estimación es el plan.

El objetivo de la planificación no es eliminar errores, sino convertir todos los errores en un montón de pequeños errores cuidadosamente planificados. Después de estudiar cuatro métodos de diseño, finalmente nos dimos por vencidos con tres, como máximo, fueron solo tres pequeños errores. Sin embargo, reescribir el programa tres veces debido a un mal diseño puede causar tres grandes errores.

Pero ¿por qué aparecen los dos extremos mencionados anteriormente? La primera situación es en realidad la forma más temprana de la industria del software: no hay ningún plan, la asignación de recursos es caótica y el proceso de desarrollo de software se encuentra en un estado caótico, desordenado y espontáneo. El éxito del proyecto depende enteramente de la suerte y de las habilidades individuales de los miembros del proyecto. La segunda situación es en realidad una forma avanzada, cuyo representante más típico es el modelo en cascada que mencionamos antes. Entonces, ¿por qué un plan tan bien pensado fracasa tan fácilmente? Es simple. Crees que lo has pensado bien, pero en realidad es posible que no sea así. He visto personas que se anuncian como planes bien pensados ​​con un horario de siete días a la semana. Parece que, en primer lugar, no tenía intención de darles un respiro a los desarrolladores. Un plan es una estimación del futuro. Nadie puede decir con precisión cómo será la situación dentro de seis meses. Antes del 11 de septiembre, ¿cuántas personas podrían haber predicho que algo tan grande sucedería ese día? Entonces, ¿por qué predices lo que sucederá medio año o incluso un año después? Además, ¿realmente conoce a sus desarrolladores lo suficiente como para sentirse seguro al hacer planes en su nombre?

Algunas personas dicen que los planes no cambian rápidamente. Esta frase es muy correcta. Nos recuerda que es imposible no tener un plan y no es posible tener un plan ejecutable. Los planes no son para lucirse, sino para ejecutarlos. Cuando hacemos planes, no necesitamos palabras elegantes ni ideas hermosas. Pero no podemos vivir sin algunos elementos:

·Qué (QUÉ): enumera en orden el trabajo necesario para lograr el objetivo;

·Cuándo (CUÁNDO): Qué se necesita para completar el tiempo de trabajo;

·QUÉ BIEN: el estándar por el cual se mide el trabajo a completar;

·RECURSOS: las personas necesarias para completar el trabajo/Fondos, etc. ;

·Quién (OMS): Quién es responsable de completar la tarea.

Pero todavía no podemos escapar del problema de la desviación entre la realidad y los planes. Aunque no tenemos mucha certeza sobre lo que esperamos que suceda dentro de un año, no tenemos mucha certeza sobre lo que piensan los desarrolladores. Pero si piensas en lo que te sucederá dentro de dos semanas, aún deberías poder adivinar bastante bien. Esto nos lleva al concepto de iteración. Un proyecto consta de varios o incluso docenas de ciclos de iteración, y cada ciclo de iteración es relativamente fácil de estimar y planificar. Esta es la idea de iteración y un gran salto en la tecnología de ingeniería de software. Dicho esto, quiero volver a abrir el apetito a todos. Dejaremos la discusión del desarrollo específico de planes de iteración para el próximo capítulo cuando analicemos el modelado de requisitos detallado.

Me cuesta imaginar cómo funcionaría un proyecto sin formación. Hay un dicho en el libro militar: "Los tres ejércitos no se han movido, pero la comida y el pasto van primero". Podemos entender que debemos estar completamente preparados con anticipación. Lo mismo ocurre con los proyectos. Se debe especificar un plan de formación al principio y reservar tiempo para la formación. Creo que a menos que sea un equipo perfecto, sus miembros aún deben tener algo que no entienden. Si no hay un plan de capacitación y la tarea de aprendizaje recae en individuos, los riesgos del proyecto serán difíciles de controlar. Hablando de formación, puedes pensar que todos están sentados allí escuchando a un profesor. Este no es el caso. La formación mencionada aquí es una formación de amplio alcance. Puede ser un conjunto de cursos, una reunión, tan pequeña como una discusión o un intercambio. El objetivo es dotar a los miembros del equipo de conocimientos y habilidades suficientes para completar el proyecto.