Dos Ideas. - Contribuciones del usuario [es]

The Core

2009-10-15T17:36:55Z

Gianu: /* Notas */

[[The Core]] es un conjunto de protocolos y prácticas para la [[Conformación de equipos]] efectivos.

Los protocolos de The Core son "mejores prácticas" para las personas, equipos de personas y organizaciones que quieren obtener grandes resultados - todo el tiempo. Son "Core" (núcleo) porque son fundacionales - pueden ser usados por todos los equipos, en todo lugar, incluso si ya tienen patrones organizaciones y mejores prácticas propias. Son "protocolos" porque nombran y prescriben formas de interacción entre las personas (comportamiento), que resultan predecibles, como los "protocolos" que se usan en la diplomacia.

Entonces, los protocolos de The Core:
* son tácticas que las personas pueden usar para obtener mejores resultados
* los pueden usar individuos, equipos y organizaciones
* son de "[[Software Libre]]" y "versionados" (se mejoran con el tiempo), al igual que el software

Suena interesante, ¿no?

A continuación dejamos una traducción de [http://www.mccarthyshow.com/LearnForFree/BestPracticesTheCoreProtocols/tabid/65/Default.aspx The Core Protocolos v 3.02].
Pueden leer más sobre [[The Core]] en el libro '''Software for your head''', de Jim y Michele McCarthy (ISBN 0-201-60456-6).

== Los protocolos de The Core v 3.02 ==

'''(The Core está distribuido bajo la [http://www.gnu.org/licenses/gpl.txt licencia GNU -PL]. The Core se considera como el código fuente bajo esa licencia. Son libres de usar, distribuir este trabajo o cualquier derivado que hagan, siempre y cuando también distribuyan este documento fuente en forma completa, incluyendo este párrafo).'''

=== Los compromisos de The Core ===
# Me comprometo a estar involucrado cuando estoy presente.
#* A conocer e informar
#** lo que quiero,
#** lo que pienso, y
#** lo que siento.
#* A siempre buscar ayuda efectiva.
#* A no ofrecer y negarme a aceptar transmiciones emocionales incoherentes.
#* Cuando tengo o escucho una mejor idea que la actual, inmediantamente voy a
#** proponerla para una aceptación decisiva o rechazo, y/o
#** explícitamente voy a buscar que se mejore
#* Personalmente voy a apoyar la mejor idea
#** sin importar de quien venga,
#** sin importar cuánto desee que aparezca otra mejor idea más tarde, y
#** cuando no tengo una idea alternativa superior.
# Voy a buscar percibir más de lo que busco ser percibido.
# Voy a usar los equipos, en especial cuando llevo adelante tareas difíciles.
# Voy a hablar siempre y sólo cuando creo que voy a mejorar el ratio general resultado/esfuerzo.
# Voy a ofrecer y aceptar sólo comportamiento y comunicación racional y orientada a resultados.
# Me voy a desinvolucrar de situaciones menos productivas
#* cuando no pueda mantener este compromiso
#* cuando es más importante que me involucre en otro lugar.
# Voy a hacer ahora lo que debe hacerse eventualmente y puede hacerse efectivamente ahora.
# Voy a buscar avanzar hacia un objetivo en particular, llevando mi comportamiento hacia la acción.
# Voy a usar los Protocolos de The Core (o mejores) cuando sea aplicable.
#* Voy a ofrecer y aceptar a tiempo y usar adecuadamente el Protocolo de [[Check-In]]
# No voy a lastimar -ni tolerar que lastimen- a nadie por su fidelidad a estos compromisos.
# No voy a hacer nada tonto a propósito.

=== Pasar (Despasar) ===
El protocolo [[Pasar]] es para declinar la participación en algo. Usalo cada vez que no quieras participar en una actividad.

==== Pasos ====
# Cuando decidís no participar, decí "Paso".
# Podés despasar en cualquier momento que quieras. Despasá ni bien sepas que querés participar otra vez, diciendo "Despaso".

==== Compromisos ====
* Mantener privados los motivos de pasar.
* Pasar en algo ni bien somos conscientes de que vamos a pasar.
* Respetar el decho de los demás a pasar sin explicación.
* No juzgar, avergonazar, molestar, interrogar ni castigar a alguien que pasa.

==== Notas ====
* En general, no vas a estar bien parado frente a los Compromisos de The Core si pasás la mayor parte del tiempo.
* Podés pasar de cualquier actividad; sin embargo, si adoptás los Compromisos de The Core, no podés pasar en un voto de [[Decisión]] y tenés que decir "Estoy presente" al hacer el [[Check-In]].
* Podés pasar aunque ya hayas empezado algo.

=== Check-In ===
Usá el [[Check-In]] para empezar reuniones o en cualquier momento que un Check-In individual o grupal agregue valor a las interacciones del equipo.

==== Pasos ====
# La persona dice "Me siento [uno o más de ENOJADO, TRISTE, CONTENTO, ASUSTADO]". La persona puede dar una breve explicación. O si otros ya hacieron su check-in, la persona puede decir "Paso". (ver el protocolo [[Pasar]]).
# La persona dice "Estoy presente". Esto significa que la persona se comportará de acuerdo a los Compromisos de The Core.
# El resto de las personas responden "Bienvenido".

==== Compromisos ====
* Decir los sentimientos sin adjetivos.
* Decir los sentimientos sólo sin nos pertenecen.
* Estar callados durante el Check-In de otra persona.
* No referirse al Check-In de otra persona sin su permiso explícito para hacerlo.

==== Notas ====
* En el contexto de los Protocolos de The Core, todas las emociones se expresan a través de una combinación de ENOJADO, TRISTE, CONTENTO o ASUSTADO. Por ejemplo, "ansioso" puede ser una combinación de CONTENTO y ASUSTADO.
* Hacer el Check-In lo más profundo posible. Lo normal es hacer el check-in con dos o más emociones. La profundidad del Check-In del grupo se traduce directamente en la calidad de los resultados del grupo.
* No hacer nada por disminuir el estado emocional. No describirnos como "un poquito" enojado, triste, contento o asustado, ni tampoco decir "Estoy enojado, PERO igual estoy contento".
* Excepto en los grupos muy grandes, si más de una persona hace el check-in, es recomendable que todos lo hagan.
* FELIZ puede ser un sustito de CONTENTO, y CON MIEDO puede ser un sustitio de ASUSTADO.

=== Check-Out ===
El [[Check-Out]] requiere que nuestra presencia física siempre signifique nuestro involucramiento. Debemos hacer un Check-Out cuando somos conscientes que no podemos mantener los Compromisos de The Core o cuando es mejor para nosotros estar en otro lugar.

==== Pasos ====
# Decir "Hago un Check-Out".
# Físicamente dejar al grupo hasta que estemos listos para hacer un nuevo Check-In.
# Opcionalmente, si lo sabemos y es relevante, podemos decir cuándo pensamos volver.
# Quienes están presentes al momento del Check-Out no deben seguir a la persona, preguntar o hablar sobre el Check-Out de la persona.

==== Compromisos ====
* Retornar ni bien podamos seguir los Compromisos de The Core.
* Retonar y hacer un Check-In sin llamar la atención por nuestro retorno.
* No juzgar, avergonzar, molestar, interrogar o castigar a nadie que hace un Check-out.

==== Notas ====
* Cuando hacemos un Check-Out hacerlo de la forma más calmada que sea posible, de manera de causar la menor interrupción posible a los demás.
* Hacer un Check-Out si nuestra estado emocional nos impide colaborar, si tenemos una recepción baja a nueva información, o si no sabemos lo que queremos.
* El Check-Out es admitir que no podemos contribuir en ese momento.

=== Pedir ayuda ===
El protocolo de [[Pedir ayuda]] nos permite hacer un uso eficiente de las habilidades y conocimientos de otros. Pedir ayuda es el acto que cataliza la [[Conexión]] y uan [[Visión compartida]]. Debemos usarlo continuamente, antes y durante la búsqueda de cualquier resultado.

==== Pasos ====
# Quien pide le pregunta a otro; "[Nombre de quien ayuda], ¿harías X?".
# Quien pide expresa todas las cosas específicas o restricciones de la petición.
# Quien ayuda responde diciendo "Si" o "No", u ofreciendo una forma alternativa de ayuda.

==== Compromisos ====
* Siempre empezar el Protocolo de Pedir ayuda con la frase "¿harías....?".
* Tener una comprensión clara de lo que queremos que haga quien nos ayuda, o si no tenemos en claro la ayuda que queremos, dejarlo en claro diciendo "No estoy seguro con qué necesito ayuda, ¿me ayudarías?".
* Asumir que todos quienes ayudan están siempre disponibles, y confiar que cada uno de quienes ayudan aceptan la responsabilidad de decir "No".
* Decir "No" cada vez que no querramos ayudar.
* Aceptar la respuesta "No" sin hacer preguntas ni un drama emocional.
* Ser receptivos de la ayuda ofrecida.
* Ofrecer nuestra mejor ayuda incluso aunque no sea lo que está esperando quien pide.
* Postponer el pedido de ayuda si no podemos estar completamente involucrados.
* Pedir más información si no tenemos en claro en qué consiste la ayuda que nos piden.
* No disculparse por pedir ayuda.

==== Notas ====
* Es "barato" pedir ayuda. El peor resultado es un "No", lo que nos deja ni más adelante ni más atrás de antes de pedir. En el mejor escenario, reducimos el tiempo para hacer una tarea y/o aprender.
* Quienes ayudan deben decir "No" si no están seguros de querer ayudar. No deben decir nada más después de negarse.
* No podemos "pedir demasiada ayuda" a una persona, a menos que explícitamente esa persona haya pedido que se respete un límite en particular.
* Si no comprendemos el valor de lo que se ofrece, o sentimos que no sería útil, o creemos que ya consideramos y rechazamos la idea anteriormente, usemos una postura curiosa en vez de rechazar automáticamente con un "pero..." (ver el protocolo [[Investigar]])
* Pedir cuando hay problemas quienes decir que esperamos demasiado tiempo para pedir ayuda. Debemos pedir ayuda cuando nos está yendo bien.
* El simple hecho de conectarnos con alguien, incluso cuando esta persona no sepa nada del tema, pueden ayudarnos a encontrar respuestas dentro de nosotros mismos, especialmente si le pedimos a esa persona que nos Investigue.

=== Comprobación de protocolo ===
Usar la Comprobación de protocolo cuando creemos que se está usando un protocolo de forma incorrecta, o cuando se está rompiendo uno de los Compromisos de The Core.

==== Pasos ====
# Decir "Comprobación de protocolo".
# Si sabemos el uso correcto del protocolo, decirlo. Sino, [[Pedir ayuda]].

==== Compromisos ====
* Decir "Comprobación de protocolo" ni bien seamos conscientes del uso incorrecto de un protocolo, o si se viola alguno de los Compromisos de The Core. Hacerlo sin importar la actividad que se esté llevando a cabo.
* Apoyar a cualquiera que use la Comprobación de protocolo.
* No avergonzar ni castigar a nadie que use la Comprobación de protocolo.
* [[Pedir ayuda]] ni bien nos demos cuenta que no sabemos el uso correcto de un protocolo.

=== Comprobación de intención ===
Usar la [[Comprobación de intención]] para clarificar el propósito de nuestro comportamiento, o el de otros. Usarlo cuando no estamos esperando un resultado positvo del comportamiento actual. La [[Comprobación de intención]] verifica la integridad de la intención propia y de otros en un caso dado.

==== Pasos ====
# Preguntar "¿Cuál es mi/tu intención con X?", donde X es algún tipo de comportamiento actual o pendiente de la persona cuya intención queremos conocer.
# Si resulta útil, preguntar "¿Qué respuesta o comportamiento querés de alguien como resultado de X?".

==== Compromisos ====
* Ser consciente de nuestra propia intención antes de comprobar la intención de otros.
* Investigar lo suficiente para descubrir la intención de la persona o de sus acciones.
* Asegurarse de tener la intención de resolver cualquier conflicto de manera pacífica antes de comprobar la intención de otra persona. Si no tenemos una intención pacífica, hacer un [[Check-Out]].
* No ser defensivos cuando alguien nos pregunta cuál es nuestra intención. Si no podemos, hacer un [[Check-Out]].

==== Notas ====
* Si aparece un conflicto que parece irresoluble, hacer un [[Check-Out]] o [[Pedir ayuda]].

=== Decisión ===
Usar [[Decisión]] cada vez que querramos avanzar al equipo de forna inmediata y unánime hacia resultados.

==== Pasos ====
# El proponente dice "Propongo [comportamiento consiso y accionable]".
# El proponente dice "1-2-3".
# Los votantes votan simultáneamente, usando un "Si" (pulgar arriba), "No" (pulgar abajo) o "Lo apoyo" (mano plana).
# Los votantes que no pueden aceptar la propuesta bajo ningún punto de vista deben expresarlo abiertamente diciendo "Mi voto es un no absoluto. No voy a apoyarlo". Si esto ocurre, se retira la propuesta.
# El proponente cuenta los votos.
# El proponente retira la propuesta si la combinación de votos "No" y votos "Lo apoyo" es demasiado grande, o si el proponente no espera concluir con éxito la [[Resolución]] (ver a continuación). Podemos aproximar este "demasiado grande" usando la siguiente heurística:
#* aproximadamente el 50% (o más) de los votos son "Lo apoyo", o
#* la ganancia esperada de la propuesta si fuera aprobada es menor que el costo por el esfuerzo de la [[Resolución]].
# El proponente usa el Protocolo de [[Resolución]] con cada votante "No" para acercarlo a la propuesta, preguntándole "¿Qué sería necesario para que aceptes?".
# El proponente declara aceptada a la propuesta si todos los votos "No" cambian a "Si" o "Lo apoyo".
# El equipo ahora está comprometido a la acción.

==== Compromisos ====
* Proponer no más de un elemento por propuesta.
* Mantenerse presente hasta que esté terminado el protocolo de [[Decisión]]; siempre estar conscientes de cómo nuestro comportamiento afecta al equipo, haciendolo avanzar o poniendo obstáculos.
* Dar nuestra máxima atención a la propuesta por sobre cualquier otra actividad.
* Hablar sólo cuando se es el proponente, o cuando el proponente nos pide hablar.
* Durante el protocolo, no expresar los motivos por los cuales votamos como lo hicimos.
* Revelar inmediatamente cuando somos un votante "No absoluto", y estar listos a proponer una mejor idea.
* Ser personalmente responsable por lograr los resultados del compromiso de la Decisión, incluso aunque haya sido hecha en nuestra ausencia.
* Mantenerse informados sobre los compromisos de una Decisión hechos en nuestra ausencia.
* No discutir con un votante "No absoluto". Siempre pedirle una idea mejor.
* Apoyar activamente las decisiones tomadas.
* Usar la capacidad de "parar el carro" al decir "no me van a convencer sin importar qué pase" con mucha discresión y lo más infrecuentemente posible.
* Insitir todo el tiempo que se sigan los protocolos de [[Decisión]] y [[Resolución]] tal cual están prescriptos, sin importar cuántas veces nos encontremos insistiendo en esto.
* No [[Pasar]] durante una [[Decisión]].
* Trabajar incesantemente para avanzar; estar enfocados a la acción.
* No mirar cómo votan los demás para elegir nuestro voto.
* Evitar usar el protocolo de [[Decisión]] en grupos grandes. Dividir al grupo grande en pequeños subgrupos para tomar decisiones, y usar el grupo grande para informar el estado.

==== Notas ====
* Votar "No" sólo cuando realmente creemos que nuestra contribución para hacer avanzar al equipo después de detenerlo con nuestro voto supera ampliamente el (en general alto) costo que agregamos por votar "No".
* Si no estamos seguros o confusos por la propuesta, apoyarla y buscar clarificación luego de que la propuesta esté resuelta. Si tenemos una propuesta alternativa después de recibir más información, podemos estar seguros que nuestro equipo apoyará la mejor idea (recordar los Compromisos de The Core).
* Votar "No" para hacer cambios menores a lo que de otra manera es una propuesta aceptable sólo detiene el avance del equipo y debería evitarse. En cambio, ofrecer una propuesta adicional después de aprobar la actual o, mejor aún, involucrarse en la implementación para asegurarnos que nuestra idea se lleva adelante.
* Retirar las propuestas débiles. Si una propuesta recibe menos del 70% (aproximado) de votos "Si", es una propuesta débiles y el proponente debería retirarla. Sin embargo, esta decisión queda a criterio del proponente.
* Cada vez que votemos "No" pensar como si fueramos el único votante no.
* Votar "No absoluto" sólo cuando estemos convencidos de tener una contribución importante para hacer a la dirección o liderazgo del equipo, o cuando la integridad lo requiere absolutamente.

=== Resolución ===
Cuando un voto por [[Decisión]] resulta en una pequeña minoria de disidentes, el proponente lleva rápidamente al equipo, de manera estructurada, a negociar con los disientes. El protocolo de [[Resolución]] promueve que el equipo avance al enfcarse en traer a los disidentes al menor costo.

==== Pasos ====
# El proponente pregunta al disidente "¿Qué sería necesario para que aceptes?"
# El disidente dice la modificación que él requiere, usando una oración única, corta y declarativa.
# El proponente ofrece adoptar los cambios del disidente o descarta la propuesta.

==== Notas ====
* Si los cambios del disidente son simples, basta con realizar un chequeo visual para determinar si todos siguen aceptando la propuesta.
* Si los cambios del disidente son complejos, el proponente debe retirar la propuesta actual y luego crear una nueva propuesta que incluya los cambios del disidente.
* Si el disidente comienza a explicar porqué votó "No" o a explicar cualquier otra cosa que no sea lo necesaria para que acepte, el proponente lo debe interrumpir con "¿Qué sería necesario para que aceptes?".

=== Juego de perfección ===
El protocolo del [[Juego de perfección]] nos apoyará en nuestro deseo de agregar las mejores ideas. Usarlo cada vez que deseamos mejorar algo que creamos.

==== Pasos ====
# El Perfeccionista realiza un acto o presenta un objeto para perfeccionar, opcionalmente diciendo "Empiezo" y "Terminó" para notificar al Perfeccionador el final de la actuación.
# El Perfeccionador califica el valor de la actuación o del objeto en un escala de 1 al 10, basándose en cuánto valor el Perfeccionador cree poder agregar.
# El Perfeccionador dice "Lo que me gusta de la actuación o del objeto X es..." y procede a listar las cualidades del objeto que el Perfeccionador cree que son de alto valor y que deberían amplificarse.
# El Perfeccionador ofrece las mejoras a las actuación o al objeto para obtener la calificación "10" diciendo "Para obtener un diez, deberías hacer X".

==== Compromisos ====
* Aceptar la perfección sin cuestionar.
* Dar sólo comentarios positivos: lo que nos gusta y lo que debería hacerse para "lograr el 10".
* Abstenerse de mencionar lo que no nos gusta, o ser negativo en cualquier otra forma.
* Quitar puntos sólo si podemos pensar en alguna mejora.
* Usar calificaciones que reflejen la escala de mejora en vez de una escala de cuánto nos gustó el objeto.
* Si no podés decir algo de lo que te gustó del objeto o no podés especificar cómo hacer mejor al objeto, tenés que calificar con un "10".

==== Notas ====
* La calificación de "10" significa que no podemos agregar valor, y una calificación de "5" significa que vamos a describir cómo hacer que el objeto sea el doble de bueno.
* La información importante para transmitir en el protocolo del [[Juego de perfección]] mejora a la actuación o al objeto. Por ejemplo, "El sonido idea de un chasquido de dedos para mi es claro, tiene suficiente volumen, y me sorprende. Para obtener un 10, deberías mejorar la claridad".
* Como Perfeccionista, sólo podemos hacer preguntas para clarificar o recolectar más información para mejorar. Si no estás de acuerdo con las ideas que te ofrecen, simplemente no las incluyas.

=== Alineamiento personal ===
El protocolo de [[Alineamiento personal]] ayuda a entrar con profunidad en los deseos y encontrar lo que nos bloquea en obtener lo que queremos. Usarlo para descubrir, articular, y lograr lo que queremos. La calidad del alineamiento será igual a la calidad de nuestros resultados.

==== Pasos ====
# Deseo. Responder a la pregunta: "¿Qué quiero específicamente?".
# Bloqueo. Preguntarnos, "¿Qué me está bloqueando en obtener lo que quiero?".
# Virtud. Averiguar qué podría quitar este bloqueo respondiendo la pregunta "¿Qué virtud -si la tuviera- podría destruir este bloqueo mio?".
# Cambio. Fingir que la virtud que identificamos es en realidad lo que queremos.
# Otra vez. Repetir los pasos 2-4 hasta que este proceso descubra una virtud que sea lo suficientemente poderosa como para destruir los bloqueos y nos obtenga lo que originalmente creíamos querer.
# Listo. Ahora escribí una oración de alineamiento personal de la forma "Quiero [virtud]". Por ejemplo, "Quiero coraje".
# Señal / Respuesta / Asignación. Crear una señal para que otros sepan que estás practicando tu alineamiento, y brindá una respuesta que los demás puedan darte para demostrar su apoyo. Por ejemplo, "Cuando digo/hago X, ¿ustedes podrían decir/hacer Y?". Opcionalmente, convertilo en una asignación al decir que haremos X una cierta cantidad de veces al día, donde X es una actividad que requiere que vivamos nuestro alineamiento.
# Evidencia. Escribí, en términos específicos y medibles, la evidencia a largo plazo de practicar este alineamiento.
# Ayuda. Pedile ayuda a cada miembro del equipo. Ellos ayudan al dar la respuesta que te gustaría cuando des la señal de estar practicando tu alineamiento.

==== Compromisos ====
* Identificar un alineamiento que resultarán en un cambio personal y que no requiere ningún cambio en otra personal.
* Identificar bloqueos y deseos que son específicos y personales.
* Identificar bloqueos que, si se resuelven, radicalmente van a incrementar tu efectividad en la vida, el trabajo y el ocio.
* Elegir una virtud que trata sobre vos y que sea, preferentemente, de una sola palabra. Por ejemplo: integridad, pasión, cuidado personal, paz, diversión.
* Pedir ayuda a las personas que te conozcan y/o conozcan tu alineamiento.
* Identificar evidencia que es medible por una tercera persona, objetiva.

==== Notas ====
* Los alineamientos personales más comunes son "Quiero (integridad, coraje, pasión, paz, cuidado personal, conocimiento personal).
* Si te cuesta averiguar lo que querés, adoptá el alineamiento "conocimiento personal". No hay ningún caso en el que aumentar el conocimiento personal no sea benéfico.
* Un bloqueo personal es algo que encontramos dentro nuestro. No se refiere a circunstancias ni a otras personas. Asumir que ya podríamos haber tenido lo que queremos, que nuestro bloqueo es un mito que de alguna manera nos está privando de nuestro potencial máximo.
* Idealmente, identificá evidencia inmediata y a largo plazo para tu alineamiento. Escribí los resultados que empiezan ahora (o muy pronto) y también los resultados que veremos en cinco o más años en el futuro.
* Como señal predeterminada, decile a tus compañeros u otras personas cercanas que estás trabajando en tu alineamiento cuando lo estás practicando. Si no conocen el protocolo, simplemente contales en qué virtud estás trabajando y pediles ayuda.
* Cuando los miembros del equipo están completando su alineamiento juntos (se piden ayuda entre ellos), el paso final del proceso es más poderoso si se hace como una ceremonia.

=== Investigar ===
[[Investigar]] permite aprender sobre cierto fenónemo que ocurre en alguien. Usalo cuando la idea o comportamiento que alguien presenta parece ser pobre, confuso o simplemente interesante.

==== Pasos ====
# Actuá como si fueras un investigador independiente, pero fascinado, haciendo preguntas hasta que tu curiosidad este satisfecha o hasta que no quieras hacer más preguntas.

==== Compromisos ====
* Realizar preguntas bien formadas.
* Realizar únicamente preguntas que aumentarán tu comprensión.
* Realizar preguntas sólo si el interrogado está comprometido y parece estar listo para responder más.
* Abstenerse de emitir opiniones.
* No realizar preguntas donde crees saber qué es lo que responderá.
* Si no puedes mantenerte como un investigador curioso e independiente, no siguas utilizando el protocolo hasta que puedas volver y mantener estos compromisos.

==== Notas ====
* No sacar teorias sobre el investigado ni dar diagnóstico alguno.
* Considerá utilizar los siguientes tipos de preguntas:
** ¿Que aspecto de X te generan Y Z?
** ¿Puedes darme un ejemplo específico?
** ¿Qué es lo que mas quieres de resolver X?
** ¿Cuál es el problema más grande que ves de X ahora?
** ¿Cuál es la cosa más importante que podés hacer ahora para ayudar con X?
* Las preguntas ineficientes incluyen las siguientes:
** Preguntas que lleven a una agenda de preguntas.
** Preguntas que intenten esconder una respuesta que tu crees verdadera.
** Preguntas que inviten a contar historias.
** Preguntas que comiencen con "Por qué".
* Mantenerse en la intención de obtener mas información.
* Si sientes que vas a explotar si no podés decir lo que tenés en mente, no deberías hablar. Considerá utilizar [[Comprobación de intención]] o [[Check-Out]].

==Ver también==
* [[Conformación de equipos]]
* [http://www.mccarthyshow.com/LearnForFree/BestPracticesTheCoreProtocols/tabid/65/Default.aspx Descargar The Core Protocols en PDF (inglés)]

[[Category: The Core]]

The Core

2009-10-14T18:43:53Z

Gianu: /* Investigar */

[[The Core]] es un conjunto de protocolos y prácticas para la [[Conformación de equipos]] efectivos.

== ¿Qué son los protocolos de The Core? ==
Los protocolos de The Core son "mejores prácticas" para las personas, equipos de personas y organizaciones que quieren obtener grandes resultados - todo el tiempo. Son "Core" (núcleo) porque son fundacionales - pueden ser usados por todos los equipos, en todo lugar, incluso si ya tienen patrones organizaciones y mejores prácticas propias. Son "protocolos" porque nombran y prescriben formas de interacción entre las personas (comportamiento), que resultan predecibles, como los "protocolos" que se usan en la diplomacia.

Entonces, los protocolos de The Core:
* son tácticas que las personas pueden usar para obtener mejores resultados
* los pueden usar individuos, equipos y organizaciones
* son de "[[Software Libre]]" y "versionados" (se mejoran con el tiempo), al igual que el software

Suena interesante, ¿no?

A continuación dejamos una traducción de [http://www.mccarthyshow.com/LearnForFree/BestPracticesTheCoreProtocols/tabid/65/Default.aspx The Core Protocolos v 3.02].
Pueden leer más sobre [[The Core]] en el libro '''Software for your head''', de Jim y Michele McCarthy (ISBN 0-201-60456-6).

== Los protocolos de The Core v 3.02 ==

'''(The Core está distribuido bajo la [http://www.gnu.org/licenses/gpl.txt licencia GNU -PL]. The Core se considera como el código fuente bajo esa licencia. Son libres de usar, distribuir este trabajo o cualquier derivado que hagan, siempre y cuando también distribuyan este documento fuente en forma completa, incluyendo este párrafo).'''

=== Los compromisos de The Core ===
# Me comprometo a estar involucrado cuando estoy presente.
#* A conocer e informar
#** lo que quiero,
#** lo que pienso, y
#** lo que siento.
#* A siempre buscar ayuda efectiva.
#* A no ofrecer y negarme a aceptar transmiciones emocionales incoherentes.
#* Cuando tengo o escucho una mejor idea que la actual, inmediantamente voy a
#** proponerla para una aceptación decisiva o rechazo, y/o
#** explícitamente voy a buscar que se mejore
#* Personalmente voy a apoyar la mejor idea
#** sin importar de quien venga,
#** sin importar cuánto desee que aparezca otra mejor idea más tarde, y
#** cuando no tengo una idea alternativa superior.
# Voy a buscar percibir más de lo que busco ser percibido.
# Voy a usar los equipos, en especial cuando llevo adelante tareas difíciles.
# Voy a hablar siempre y sólo cuando creo que voy a mejorar el ratio general resultado/esfuerzo.
# Voy a ofrecer y aceptar sólo comportamiento y comunicación racional y orientada a resultados.
# Me voy a desinvolucrar de situaciones menos productivas
#* cuando no pueda mantener este compromiso
#* cuando es más importante que me involucre en otro lugar.
# Voy a hacer ahora lo que debe hacerse eventualmente y puede hacerse efectivamente ahora.
# Voy a buscar avanzar hacia un objetivo en particular, llevando mi comportamiento hacia la acción.
# Voy a usar los Protocolos de The Core (o mejores) cuando sea aplicable.
#* Voy a ofrecer y aceptar a tiempo y usar adecuadamente el Protocolo de [[Check-In]]
# No voy a lastimar -ni tolerar que lastimen- a nadie por su fidelidad a estos compromisos.
# No voy a hacer nada tonto a propósito.

=== Pasar (Despasar) ===
El protocolo [[Pasar]] es para declinar la participación en algo. Usalo cada vez que no quieras participar en una actividad.

==== Pasos ====
# Cuando decidís no participar, decí "Paso".
# Podés despasar en cualquier momento que quieras. Despasá ni bien sepas que querés participar otra vez, diciendo "Despaso".

==== Compromisos ====
* Mantener privados los motivos de pasar.
* Pasar en algo ni bien somos conscientes de que vamos a pasar.
* Respetar el decho de los demás a pasar sin explicación.
* No juzgar, avergonazar, molestar, interrogar ni castigar a alguien que pasa.

==== Notas ====
* En general, no vas a estar bien parado frente a los Compromisos de The Core si pasás la mayor parte del tiempo.
* Podés pasar de cualquier actividad; sin embargo, si adoptás los Compromisos de The Core, no podés pasar en un voto de [[Decisión]] y tenés que decir "Estoy presente" al hacer el [[Check-In]].
* Podés pasar aunque ya hayas empezado algo.

=== Check-In ===
Usá el [[Check-In]] para empezar reuniones o en cualquier momento que un Check-In individual o grupal agregue valor a las interacciones del equipo.

==== Pasos ====
# La persona dice "Me siento [uno o más de ENOJADO, TRISTE, CONTENTO, ASUSTADO]". La persona puede dar una breve explicación. O si otros ya hacieron su check-in, la persona puede decir "Paso". (ver el protocolo [[Pasar]]).
# La persona dice "Estoy presente". Esto significa que la persona se comportará de acuerdo a los Compromisos de The Core.
# El resto de las personas responden "Bienvenido".

==== Compromisos ====
* Decir los sentimientos sin adjetivos.
* Decir los sentimientos sólo sin nos pertenecen.
* Estar callados durante el Check-In de otra persona.
* No referirse al Check-In de otra persona sin su permiso explícito para hacerlo.

==== Notas ====
* En el contexto de los Protocolos de The Core, todas las emociones se expresan a través de una combinación de ENOJADO, TRISTE, CONTENTO o ASUSTADO. Por ejemplo, "ansioso" puede ser una combinación de CONTENTO y ASUSTADO.
* Hacer el Check-In lo más profundo posible. Lo normal es hacer el check-in con dos o más emociones. La profundidad del Check-In del grupo se traduce directamente en la calidad de los resultados del grupo.
* No hacer nada por disminuir el estado emocional. No describirnos como "un poquito" enojado, triste, contento o asustado, ni tampoco decir "Estoy enojado, PERO igual estoy contento".
* Excepto en los grupos muy grandes, si más de una persona hace el check-in, es recomendable que todos lo hagan.
* FELIZ puede ser un sustito de CONTENTO, y CON MIEDO puede ser un sustitio de ASUSTADO.

=== Check-Out ===
El [[Check-Out]] requiere que nuestra presencia física siempre signifique nuestro involucramiento. Debemos hacer un Check-Out cuando somos conscientes que no podemos mantener los Compromisos de The Core o cuando es mejor para nosotros estar en otro lugar.

==== Pasos ====
# Decir "Hago un Check-Out".
# Físicamente dejar al grupo hasta que estemos listos para hacer un nuevo Check-In.
# Opcionalmente, si lo sabemos y es relevante, podemos decir cuándo pensamos volver.
# Quienes están presentes al momento del Check-Out no deben seguir a la persona, preguntar o hablar sobre el Check-Out de la persona.

==== Compromisos ====
* Retornar ni bien podamos seguir los Compromisos de The Core.
* Retonar y hacer un Check-In sin llamar la atención por nuestro retorno.
* No juzgar, avergonzar, molestar, interrogar o castigar a nadie que hace un Check-out.

==== Notas ====
* Cuando hacemos un Check-Out hacerlo de la forma más calmada que sea posible, de manera de causar la menor interrupción posible a los demás.
* Hacer un Check-Out si nuestra estado emocional nos impide colaborar, si tenemos una recepción baja a nueva información, o si no sabemos lo que queremos.
* El Check-Out es admitir que no podemos contribuir en ese momento.

=== Pedir ayuda ===
El protocolo de [[Pedir ayuda]] nos permite hacer un uso eficiente de las habilidades y conocimientos de otros. Pedir ayuda es el acto que cataliza la [[Conexión]] y uan [[Visión compartida]]. Debemos usarlo continuamente, antes y durante la búsqueda de cualquier resultado.

==== Pasos ====
# Quien pide le pregunta a otro; "[Nombre de quien ayuda], ¿harías X?".
# Quien pide expresa todas las cosas específicas o restricciones de la petición.
# Quien ayuda responde diciendo "Si" o "No", u ofreciendo una forma alternativa de ayuda.

==== Compromisos ====
* Siempre empezar el Protocolo de Pedir ayuda con la frase "¿harías....?".
* Tener una comprensión clara de lo que queremos que haga quien nos ayuda, o si no tenemos en claro la ayuda que queremos, dejarlo en claro diciendo "No estoy seguro con qué necesito ayuda, ¿me ayudarías?".
* Asumir que todos quienes ayudan están siempre disponibles, y confiar que cada uno de quienes ayudan aceptan la responsabilidad de decir "No".
* Decir "No" cada vez que no querramos ayudar.
* Aceptar la respuesta "No" sin hacer preguntas ni un drama emocional.
* Ser receptivos de la ayuda ofrecida.
* Ofrecer nuestra mejor ayuda incluso aunque no sea lo que está esperando quien pide.
* Postponer el pedido de ayuda si no podemos estar completamente involucrados.
* Pedir más información si no tenemos en claro en qué consiste la ayuda que nos piden.
* No disculparse por pedir ayuda.

==== Notas ====
* Es "barato" pedir ayuda. El peor resultado es un "No", lo que nos deja ni más adelante ni más atrás de antes de pedir. En el mejor escenario, reducimos el tiempo para hacer una tarea y/o aprender.
* Quienes ayudan deben decir "No" si no están seguros de querer ayudar. No deben decir nada más después de negarse.
* No podemos "pedir demasiada ayuda" a una persona, a menos que explícitamente esa persona haya pedido que se respete un límite en particular.
* Si no comprendemos el valor de lo que se ofrece, o sentimos que no sería útil, o creemos que ya consideramos y rechazamos la idea anteriormente, usemos una postura curiosa en vez de rechazar automáticamente con un "pero..." (ver el protocolo [[Investigar]])
* Pedir cuando hay problemas quienes decir que esperamos demasiado tiempo para pedir ayuda. Debemos pedir ayuda cuando nos está yendo bien.
* El simple hecho de conectarnos con alguien, incluso cuando esta persona no sepa nada del tema, pueden ayudarnos a encontrar respuestas dentro de nosotros mismos, especialmente si le pedimos a esa persona que nos Investigue.

=== Comprobación de protocolo ===
Usar la Comprobación de protocolo cuando creemos que se está usando un protocolo de forma incorrecta, o cuando se está rompiendo uno de los Compromisos de The Core.

==== Pasos ====
# Decir "Comprobación de protocolo".
# Si sabemos el uso correcto del protocolo, decirlo. Sino, [[Pedir ayuda]].

==== Compromisos ====
* Decir "Comprobación de protocolo" ni bien seamos conscientes del uso incorrecto de un protocolo, o si se viola alguno de los Compromisos de The Core. Hacerlo sin importar la actividad que se esté llevando a cabo.
* Apoyar a cualquiera que use la Comprobación de protocolo.
* No avergonzar ni castigar a nadie que use la Comprobación de protocolo.
* [[Pedir ayuda]] ni bien nos demos cuenta que no sabemos el uso correcto de un protocolo.

=== Comprobación de intención ===
Usar la [[Comprobación de intención]] para clarificar el propósito de nuestro comportamiento, o el de otros. Usarlo cuando no estamos esperando un resultado positvo del comportamiento actual. La [[Comprobación de intención]] verifica la integridad de la intención propia y de otros en un caso dado.

==== Pasos ====
# Preguntar "¿Cuál es mi/tu intención con X?", donde X es algún tipo de comportamiento actual o pendiente de la persona cuya intención queremos conocer.
# Si resulta útil, preguntar "¿Qué respuesta o comportamiento querés de alguien como resultado de X?".

==== Compromisos ====
* Ser consciente de nuestra propia intención antes de comprobar la intención de otros.
* Investigar lo suficiente para descubrir la intención de la persona o de sus acciones.
* Asegurarse de tener la intención de resolver cualquier conflicto de manera pacífica antes de comprobar la intención de otra persona. Si no tenemos una intención pacífica, hacer un [[Check-Out]].
* No ser defensivos cuando alguien nos pregunta cuál es nuestra intención. Si no podemos, hacer un [[Check-Out]].

==== Notas ====
* Si aparece un conflicto que parece irresoluble, hacer un [[Check-Out]] o [[Pedir ayuda]].

=== Decisión ===
Usar [[Decisión]] cada vez que querramos avanzar al equipo de forna inmediata y unánime hacia resultados.

==== Pasos ====
# El proponente dice "Propongo [comportamiento consiso y accionable]".
# El proponente dice "1-2-3".
# Los votantes votan simultáneamente, usando un "Si" (pulgar arriba), "No" (pulgar abajo) o "Lo apoyo" (mano plana).
# Los votantes que no pueden aceptar la propuesta bajo ningún punto de vista deben expresarlo abiertamente diciendo "Mi voto es un no absoluto. No voy a apoyarlo". Si esto ocurre, se retira la propuesta.
# El proponente cuenta los votos.
# El proponente retira la propuesta si la combinación de votos "No" y votos "Lo apoyo" es demasiado grande, o si el proponente no espera concluir con éxito la [[Resolución]] (ver a continuación). Podemos aproximar este "demasiado grande" usando la siguiente heurística:
#* aproximadamente el 50% (o más) de los votos son "Lo apoyo", o
#* la ganancia esperada de la propuesta si fuera aprobada es menor que el costo por el esfuerzo de la [[Resolución]].
# El proponente usa el Protocolo de [[Resolución]] con cada votante "No" para acercarlo a la propuesta, preguntándole "¿Qué sería necesario para que aceptes?".
# El proponente declara aceptada a la propuesta si todos los votos "No" cambian a "Si" o "Lo apoyo".
# El equipo ahora está comprometido a la acción.

==== Compromisos ====
* Proponer no más de un elemento por propuesta.
* Mantenerse presente hasta que esté terminado el protocolo de [[Decisión]]; siempre estar conscientes de cómo nuestro comportamiento afecta al equipo, haciendolo avanzar o poniendo obstáculos.
* Dar nuestra máxima atención a la propuesta por sobre cualquier otra actividad.
* Hablar sólo cuando se es el proponente, o cuando el proponente nos pide hablar.
* Durante el protocolo, no expresar los motivos por los cuales votamos como lo hicimos.
* Revelar inmediatamente cuando somos un votante "No absoluto", y estar listos a proponer una mejor idea.
* Ser personalmente responsable por lograr los resultados del compromiso de la Decisión, incluso aunque haya sido hecha en nuestra ausencia.
* Mantenerse informados sobre los compromisos de una Decisión hechos en nuestra ausencia.
* No discutir con un votante "No absoluto". Siempre pedirle una idea mejor.
* Apoyar activamente las decisiones tomadas.
* Usar la capacidad de "parar el carro" al decir "no me van a convencer sin importar qué pase" con mucha discresión y lo más infrecuentemente posible.
* Insitir todo el tiempo que se sigan los protocolos de [[Decisión]] y [[Resolución]] tal cual están prescriptos, sin importar cuántas veces nos encontremos insistiendo en esto.
* No [[Pasar]] durante una [[Decisión]].
* Trabajar incesantemente para avanzar; estar enfocados a la acción.
* No mirar cómo votan los demás para elegir nuestro voto.
* Evitar usar el protocolo de [[Decisión]] en grupos grandes. Dividir al grupo grande en pequeños subgrupos para tomar decisiones, y usar el grupo grande para informar el estado.

==== Notas ====
* Votar "No" sólo cuando realmente creemos que nuestra contribución para hacer avanzar al equipo después de detenerlo con nuestro voto supera ampliamente el (en general alto) costo que agregamos por votar "No".
* Si no estamos seguros o confusos por la propuesta, apoyarla y buscar clarificación luego de que la propuesta esté resuelta. Si tenemos una propuesta alternativa después de recibir más información, podemos estar seguros que nuestro equipo apoyará la mejor idea (recordar los Compromisos de The Core).
* Votar "No" para hacer cambios menores a lo que de otra manera es una propuesta aceptable sólo detiene el avance del equipo y debería evitarse. En cambio, ofrecer una propuesta adicional después de aprobar la actual o, mejor aún, involucrarse en la implementación para asegurarnos que nuestra idea se lleva adelante.
* Retirar las propuestas débiles. Si una propuesta recibe menos del 70% (aproximado) de votos "Si", es una propuesta débiles y el proponente debería retirarla. Sin embargo, esta decisión queda a criterio del proponente.
* Cada vez que votemos "No" pensar como si fueramos el único votante no.
* Votar "No absoluto" sólo cuando estemos convencidos de tener una contribución importante para hacer a la dirección o liderazgo del equipo, o cuando la integridad lo requiere absolutamente.

=== Investigar ===
Investigar permite aprender sobre cierto fenónemo que ocurre en alguien. Usalo cuando la idea o comportamiento que alguien presenta aparenta ser pobre, confusa o simplemente interesante.

==== Pasos ====
# Actua como si fueras un investigador independiente, pero fascinado, haciendo preguntas hasta que tu curiosidad este satisfecha o hasta que no quieras hacer mas preguntas.

==== Compromisos ====

* Realizar preguntas bien formadas.
* Realizar preguntas que unicamente aumentaran tu comprensión.
* Realizar preguntas solo si el interrogado esta comprometido y parece estar listo para responder mas.
* Abstenerse a emitir opiniones.
* No realizar preguntas donde crees que sabes que es lo que responderá.
* Si no puedes mantenerte como un investigador curioso e independiente, no siguas utilizando el protocolo hasta que puedas volver y mantener estos compromisos.

==== Notas ====

* No sacar teorias sobre el investigado ni dar diagnostico alguno.
* Considera utilizar los siguientes tipos de preguntas:
** ¿Que aspecto de X hace que Y Z?
** ¿Puedes darme un ejemplo especifico?
** ¿Que es lo que mas quieres de resolver X?
** ¿Cual es el problema mas grande que ves de X ahora?
** ¿Cual es la cosa mas importante que puedes hacer ahora para ayudar con X?
* Las preguntas ineficientes incluyen las siguientes:
** Preguntas que lleven a una agenda de preguntas.
** Preguntas que intenten esconder una respuesta que tu crees verdadera.
** Preguntas que inviten a contar historias.
** Preguntas que comiencen con "Por que".
* Mantenerse en la intención de obtener mas información
* Si sientes que vas a explotar si no puedes decir lo que tienes en mente, no debes hablar. Considera utilizar [[Comprobación de intención]] o [[Check-Out]].

==Ver también==
* [[Conformación de equipos]]
* [http://www.mccarthyshow.com/LearnForFree/BestPracticesTheCoreProtocols/tabid/65/Default.aspx Descargar The Core Protocols en PDF (inglés)]

[[Category: The Core]]

The Core

2009-10-14T18:43:07Z

Gianu: /* Comprobación de intención */

[[The Core]] es un conjunto de protocolos y prácticas para la [[Conformación de equipos]] efectivos.

== ¿Qué son los protocolos de The Core? ==
Los protocolos de The Core son "mejores prácticas" para las personas, equipos de personas y organizaciones que quieren obtener grandes resultados - todo el tiempo. Son "Core" (núcleo) porque son fundacionales - pueden ser usados por todos los equipos, en todo lugar, incluso si ya tienen patrones organizaciones y mejores prácticas propias. Son "protocolos" porque nombran y prescriben formas de interacción entre las personas (comportamiento), que resultan predecibles, como los "protocolos" que se usan en la diplomacia.

Entonces, los protocolos de The Core:
* son tácticas que las personas pueden usar para obtener mejores resultados
* los pueden usar individuos, equipos y organizaciones
* son de "[[Software Libre]]" y "versionados" (se mejoran con el tiempo), al igual que el software

Suena interesante, ¿no?

A continuación dejamos una traducción de [http://www.mccarthyshow.com/LearnForFree/BestPracticesTheCoreProtocols/tabid/65/Default.aspx The Core Protocolos v 3.02].
Pueden leer más sobre [[The Core]] en el libro '''Software for your head''', de Jim y Michele McCarthy (ISBN 0-201-60456-6).

== Los protocolos de The Core v 3.02 ==

'''(The Core está distribuido bajo la [http://www.gnu.org/licenses/gpl.txt licencia GNU -PL]. The Core se considera como el código fuente bajo esa licencia. Son libres de usar, distribuir este trabajo o cualquier derivado que hagan, siempre y cuando también distribuyan este documento fuente en forma completa, incluyendo este párrafo).'''

=== Los compromisos de The Core ===
# Me comprometo a estar involucrado cuando estoy presente.
#* A conocer e informar
#** lo que quiero,
#** lo que pienso, y
#** lo que siento.
#* A siempre buscar ayuda efectiva.
#* A no ofrecer y negarme a aceptar transmiciones emocionales incoherentes.
#* Cuando tengo o escucho una mejor idea que la actual, inmediantamente voy a
#** proponerla para una aceptación decisiva o rechazo, y/o
#** explícitamente voy a buscar que se mejore
#* Personalmente voy a apoyar la mejor idea
#** sin importar de quien venga,
#** sin importar cuánto desee que aparezca otra mejor idea más tarde, y
#** cuando no tengo una idea alternativa superior.
# Voy a buscar percibir más de lo que busco ser percibido.
# Voy a usar los equipos, en especial cuando llevo adelante tareas difíciles.
# Voy a hablar siempre y sólo cuando creo que voy a mejorar el ratio general resultado/esfuerzo.
# Voy a ofrecer y aceptar sólo comportamiento y comunicación racional y orientada a resultados.
# Me voy a desinvolucrar de situaciones menos productivas
#* cuando no pueda mantener este compromiso
#* cuando es más importante que me involucre en otro lugar.
# Voy a hacer ahora lo que debe hacerse eventualmente y puede hacerse efectivamente ahora.
# Voy a buscar avanzar hacia un objetivo en particular, llevando mi comportamiento hacia la acción.
# Voy a usar los Protocolos de The Core (o mejores) cuando sea aplicable.
#* Voy a ofrecer y aceptar a tiempo y usar adecuadamente el Protocolo de [[Check-In]]
# No voy a lastimar -ni tolerar que lastimen- a nadie por su fidelidad a estos compromisos.
# No voy a hacer nada tonto a propósito.

=== Pasar (Despasar) ===
El protocolo [[Pasar]] es para declinar la participación en algo. Usalo cada vez que no quieras participar en una actividad.

==== Pasos ====
# Cuando decidís no participar, decí "Paso".
# Podés despasar en cualquier momento que quieras. Despasá ni bien sepas que querés participar otra vez, diciendo "Despaso".

==== Compromisos ====
* Mantener privados los motivos de pasar.
* Pasar en algo ni bien somos conscientes de que vamos a pasar.
* Respetar el decho de los demás a pasar sin explicación.
* No juzgar, avergonazar, molestar, interrogar ni castigar a alguien que pasa.

==== Notas ====
* En general, no vas a estar bien parado frente a los Compromisos de The Core si pasás la mayor parte del tiempo.
* Podés pasar de cualquier actividad; sin embargo, si adoptás los Compromisos de The Core, no podés pasar en un voto de [[Decisión]] y tenés que decir "Estoy presente" al hacer el [[Check-In]].
* Podés pasar aunque ya hayas empezado algo.

=== Check-In ===
Usá el [[Check-In]] para empezar reuniones o en cualquier momento que un Check-In individual o grupal agregue valor a las interacciones del equipo.

==== Pasos ====
# La persona dice "Me siento [uno o más de ENOJADO, TRISTE, CONTENTO, ASUSTADO]". La persona puede dar una breve explicación. O si otros ya hacieron su check-in, la persona puede decir "Paso". (ver el protocolo [[Pasar]]).
# La persona dice "Estoy presente". Esto significa que la persona se comportará de acuerdo a los Compromisos de The Core.
# El resto de las personas responden "Bienvenido".

==== Compromisos ====
* Decir los sentimientos sin adjetivos.
* Decir los sentimientos sólo sin nos pertenecen.
* Estar callados durante el Check-In de otra persona.
* No referirse al Check-In de otra persona sin su permiso explícito para hacerlo.

==== Notas ====
* En el contexto de los Protocolos de The Core, todas las emociones se expresan a través de una combinación de ENOJADO, TRISTE, CONTENTO o ASUSTADO. Por ejemplo, "ansioso" puede ser una combinación de CONTENTO y ASUSTADO.
* Hacer el Check-In lo más profundo posible. Lo normal es hacer el check-in con dos o más emociones. La profundidad del Check-In del grupo se traduce directamente en la calidad de los resultados del grupo.
* No hacer nada por disminuir el estado emocional. No describirnos como "un poquito" enojado, triste, contento o asustado, ni tampoco decir "Estoy enojado, PERO igual estoy contento".
* Excepto en los grupos muy grandes, si más de una persona hace el check-in, es recomendable que todos lo hagan.
* FELIZ puede ser un sustito de CONTENTO, y CON MIEDO puede ser un sustitio de ASUSTADO.

=== Check-Out ===
El [[Check-Out]] requiere que nuestra presencia física siempre signifique nuestro involucramiento. Debemos hacer un Check-Out cuando somos conscientes que no podemos mantener los Compromisos de The Core o cuando es mejor para nosotros estar en otro lugar.

==== Pasos ====
# Decir "Hago un Check-Out".
# Físicamente dejar al grupo hasta que estemos listos para hacer un nuevo Check-In.
# Opcionalmente, si lo sabemos y es relevante, podemos decir cuándo pensamos volver.
# Quienes están presentes al momento del Check-Out no deben seguir a la persona, preguntar o hablar sobre el Check-Out de la persona.

==== Compromisos ====
* Retornar ni bien podamos seguir los Compromisos de The Core.
* Retonar y hacer un Check-In sin llamar la atención por nuestro retorno.
* No juzgar, avergonzar, molestar, interrogar o castigar a nadie que hace un Check-out.

==== Notas ====
* Cuando hacemos un Check-Out hacerlo de la forma más calmada que sea posible, de manera de causar la menor interrupción posible a los demás.
* Hacer un Check-Out si nuestra estado emocional nos impide colaborar, si tenemos una recepción baja a nueva información, o si no sabemos lo que queremos.
* El Check-Out es admitir que no podemos contribuir en ese momento.

=== Pedir ayuda ===
El protocolo de [[Pedir ayuda]] nos permite hacer un uso eficiente de las habilidades y conocimientos de otros. Pedir ayuda es el acto que cataliza la [[Conexión]] y uan [[Visión compartida]]. Debemos usarlo continuamente, antes y durante la búsqueda de cualquier resultado.

==== Pasos ====
# Quien pide le pregunta a otro; "[Nombre de quien ayuda], ¿harías X?".
# Quien pide expresa todas las cosas específicas o restricciones de la petición.
# Quien ayuda responde diciendo "Si" o "No", u ofreciendo una forma alternativa de ayuda.

==== Compromisos ====
* Siempre empezar el Protocolo de Pedir ayuda con la frase "¿harías....?".
* Tener una comprensión clara de lo que queremos que haga quien nos ayuda, o si no tenemos en claro la ayuda que queremos, dejarlo en claro diciendo "No estoy seguro con qué necesito ayuda, ¿me ayudarías?".
* Asumir que todos quienes ayudan están siempre disponibles, y confiar que cada uno de quienes ayudan aceptan la responsabilidad de decir "No".
* Decir "No" cada vez que no querramos ayudar.
* Aceptar la respuesta "No" sin hacer preguntas ni un drama emocional.
* Ser receptivos de la ayuda ofrecida.
* Ofrecer nuestra mejor ayuda incluso aunque no sea lo que está esperando quien pide.
* Postponer el pedido de ayuda si no podemos estar completamente involucrados.
* Pedir más información si no tenemos en claro en qué consiste la ayuda que nos piden.
* No disculparse por pedir ayuda.

==== Notas ====
* Es "barato" pedir ayuda. El peor resultado es un "No", lo que nos deja ni más adelante ni más atrás de antes de pedir. En el mejor escenario, reducimos el tiempo para hacer una tarea y/o aprender.
* Quienes ayudan deben decir "No" si no están seguros de querer ayudar. No deben decir nada más después de negarse.
* No podemos "pedir demasiada ayuda" a una persona, a menos que explícitamente esa persona haya pedido que se respete un límite en particular.
* Si no comprendemos el valor de lo que se ofrece, o sentimos que no sería útil, o creemos que ya consideramos y rechazamos la idea anteriormente, usemos una postura curiosa en vez de rechazar automáticamente con un "pero..." (ver el protocolo [[Investigar]])
* Pedir cuando hay problemas quienes decir que esperamos demasiado tiempo para pedir ayuda. Debemos pedir ayuda cuando nos está yendo bien.
* El simple hecho de conectarnos con alguien, incluso cuando esta persona no sepa nada del tema, pueden ayudarnos a encontrar respuestas dentro de nosotros mismos, especialmente si le pedimos a esa persona que nos Investigue.

=== Comprobación de protocolo ===
Usar la Comprobación de protocolo cuando creemos que se está usando un protocolo de forma incorrecta, o cuando se está rompiendo uno de los Compromisos de The Core.

==== Pasos ====
# Decir "Comprobación de protocolo".
# Si sabemos el uso correcto del protocolo, decirlo. Sino, [[Pedir ayuda]].

==== Compromisos ====
* Decir "Comprobación de protocolo" ni bien seamos conscientes del uso incorrecto de un protocolo, o si se viola alguno de los Compromisos de The Core. Hacerlo sin importar la actividad que se esté llevando a cabo.
* Apoyar a cualquiera que use la Comprobación de protocolo.
* No avergonzar ni castigar a nadie que use la Comprobación de protocolo.
* [[Pedir ayuda]] ni bien nos demos cuenta que no sabemos el uso correcto de un protocolo.

=== Comprobación de intención ===
Usar la [[Comprobación de intención]] para clarificar el propósito de nuestro comportamiento, o el de otros. Usarlo cuando no estamos esperando un resultado positvo del comportamiento actual. La [[Comprobación de intención]] verifica la integridad de la intención propia y de otros en un caso dado.

==== Pasos ====
# Preguntar "¿Cuál es mi/tu intención con X?", donde X es algún tipo de comportamiento actual o pendiente de la persona cuya intención queremos conocer.
# Si resulta útil, preguntar "¿Qué respuesta o comportamiento querés de alguien como resultado de X?".

==== Compromisos ====
* Ser consciente de nuestra propia intención antes de comprobar la intención de otros.
* Investigar lo suficiente para descubrir la intención de la persona o de sus acciones.
* Asegurarse de tener la intención de resolver cualquier conflicto de manera pacífica antes de comprobar la intención de otra persona. Si no tenemos una intención pacífica, hacer un [[Check-Out]].
* No ser defensivos cuando alguien nos pregunta cuál es nuestra intención. Si no podemos, hacer un [[Check-Out]].

==== Notas ====
* Si aparece un conflicto que parece irresoluble, hacer un [[Check-Out]] o [[Pedir ayuda]].

=== Decisión ===
Usar [[Decisión]] cada vez que querramos avanzar al equipo de forna inmediata y unánime hacia resultados.

==== Pasos ====
# El proponente dice "Propongo [comportamiento consiso y accionable]".
# El proponente dice "1-2-3".
# Los votantes votan simultáneamente, usando un "Si" (pulgar arriba), "No" (pulgar abajo) o "Lo apoyo" (mano plana).
# Los votantes que no pueden aceptar la propuesta bajo ningún punto de vista deben expresarlo abiertamente diciendo "Mi voto es un no absoluto. No voy a apoyarlo". Si esto ocurre, se retira la propuesta.
# El proponente cuenta los votos.
# El proponente retira la propuesta si la combinación de votos "No" y votos "Lo apoyo" es demasiado grande, o si el proponente no espera concluir con éxito la [[Resolución]] (ver a continuación). Podemos aproximar este "demasiado grande" usando la siguiente heurística:
#* aproximadamente el 50% (o más) de los votos son "Lo apoyo", o
#* la ganancia esperada de la propuesta si fuera aprobada es menor que el costo por el esfuerzo de la [[Resolución]].
# El proponente usa el Protocolo de [[Resolución]] con cada votante "No" para acercarlo a la propuesta, preguntándole "¿Qué sería necesario para que aceptes?".
# El proponente declara aceptada a la propuesta si todos los votos "No" cambian a "Si" o "Lo apoyo".
# El equipo ahora está comprometido a la acción.

==== Compromisos ====
* Proponer no más de un elemento por propuesta.
* Mantenerse presente hasta que esté terminado el protocolo de [[Decisión]]; siempre estar conscientes de cómo nuestro comportamiento afecta al equipo, haciendolo avanzar o poniendo obstáculos.
* Dar nuestra máxima atención a la propuesta por sobre cualquier otra actividad.
* Hablar sólo cuando se es el proponente, o cuando el proponente nos pide hablar.
* Durante el protocolo, no expresar los motivos por los cuales votamos como lo hicimos.
* Revelar inmediatamente cuando somos un votante "No absoluto", y estar listos a proponer una mejor idea.
* Ser personalmente responsable por lograr los resultados del compromiso de la Decisión, incluso aunque haya sido hecha en nuestra ausencia.
* Mantenerse informados sobre los compromisos de una Decisión hechos en nuestra ausencia.
* No discutir con un votante "No absoluto". Siempre pedirle una idea mejor.
* Apoyar activamente las decisiones tomadas.
* Usar la capacidad de "parar el carro" al decir "no me van a convencer sin importar qué pase" con mucha discresión y lo más infrecuentemente posible.
* Insitir todo el tiempo que se sigan los protocolos de [[Decisión]] y [[Resolución]] tal cual están prescriptos, sin importar cuántas veces nos encontremos insistiendo en esto.
* No [[Pasar]] durante una [[Decisión]].
* Trabajar incesantemente para avanzar; estar enfocados a la acción.
* No mirar cómo votan los demás para elegir nuestro voto.
* Evitar usar el protocolo de [[Decisión]] en grupos grandes. Dividir al grupo grande en pequeños subgrupos para tomar decisiones, y usar el grupo grande para informar el estado.

==== Notas ====
* Votar "No" sólo cuando realmente creemos que nuestra contribución para hacer avanzar al equipo después de detenerlo con nuestro voto supera ampliamente el (en general alto) costo que agregamos por votar "No".
* Si no estamos seguros o confusos por la propuesta, apoyarla y buscar clarificación luego de que la propuesta esté resuelta. Si tenemos una propuesta alternativa después de recibir más información, podemos estar seguros que nuestro equipo apoyará la mejor idea (recordar los Compromisos de The Core).
* Votar "No" para hacer cambios menores a lo que de otra manera es una propuesta aceptable sólo detiene el avance del equipo y debería evitarse. En cambio, ofrecer una propuesta adicional después de aprobar la actual o, mejor aún, involucrarse en la implementación para asegurarnos que nuestra idea se lleva adelante.
* Retirar las propuestas débiles. Si una propuesta recibe menos del 70% (aproximado) de votos "Si", es una propuesta débiles y el proponente debería retirarla. Sin embargo, esta decisión queda a criterio del proponente.
* Cada vez que votemos "No" pensar como si fueramos el único votante no.
* Votar "No absoluto" sólo cuando estemos convencidos de tener una contribución importante para hacer a la dirección o liderazgo del equipo, o cuando la integridad lo requiere absolutamente.

=== Investigar ===
Investigar permite aprender sobre cierto fenónemo que ocurre en alguien. Usalo cuando la idea o comportamiento que alguien presenta aparenta ser pobre, confusa o simplemente interesante.

==== Pasos ====
# Actua como si fueras un investigador independiente, pero fascinado, haciendo preguntas hasta que tu curiosidad este satisfecha o hasta que no quieras hacer mas preguntas.

==== COMPROMISOS ====

* Realizar preguntas bien formadas.
* Realizar preguntas que unicamente aumentaran tu comprensión.
* Realizar preguntas solo si el interrogado esta comprometido y parece estar listo para responder mas.
* Abstenerse a emitir opiniones.
* No realizar preguntas donde crees que sabes que es lo que responderá.
* Si no puedes mantenerte como un investigador curioso e independiente, no siguas utilizando el protocolo hasta que puedas volver y mantener estos compromisos.

==== NOTAS ====

* No sacar teorias sobre el investigado ni dar diagnostico alguno.
* Considera utilizar los siguientes tipos de preguntas:
** ¿Que aspecto de X hace que Y Z?
** ¿Puedes darme un ejemplo especifico?
** ¿Que es lo que mas quieres de resolver X?
** ¿Cual es el problema mas grande que ves de X ahora?
** ¿Cual es la cosa mas importante que puedes hacer ahora para ayudar con X?
* Las preguntas ineficientes incluyen las siguientes:
** Preguntas que lleven a una agenda de preguntas.
** Preguntas que intenten esconder una respuesta que tu crees verdadera.
** Preguntas que inviten a contar historias.
** Preguntas que comiencen con "Por que".
* Mantenerse en la intención de obtener mas información
* Si sientes que vas a explotar si no puedes decir lo que tienes en mente, no debes hablar. Considera chequear tus intenciones o utilizar [[Check-Out]].

==Ver también==
* [[Conformación de equipos]]
* [http://www.mccarthyshow.com/LearnForFree/BestPracticesTheCoreProtocols/tabid/65/Default.aspx Descargar The Core Protocols en PDF (inglés)]

[[Category: The Core]]

The Core

2009-10-14T18:42:37Z

Gianu: /* PASOS */

[[The Core]] es un conjunto de protocolos y prácticas para la [[Conformación de equipos]] efectivos.

== ¿Qué son los protocolos de The Core? ==
Los protocolos de The Core son "mejores prácticas" para las personas, equipos de personas y organizaciones que quieren obtener grandes resultados - todo el tiempo. Son "Core" (núcleo) porque son fundacionales - pueden ser usados por todos los equipos, en todo lugar, incluso si ya tienen patrones organizaciones y mejores prácticas propias. Son "protocolos" porque nombran y prescriben formas de interacción entre las personas (comportamiento), que resultan predecibles, como los "protocolos" que se usan en la diplomacia.

Entonces, los protocolos de The Core:
* son tácticas que las personas pueden usar para obtener mejores resultados
* los pueden usar individuos, equipos y organizaciones
* son de "[[Software Libre]]" y "versionados" (se mejoran con el tiempo), al igual que el software

Suena interesante, ¿no?

A continuación dejamos una traducción de [http://www.mccarthyshow.com/LearnForFree/BestPracticesTheCoreProtocols/tabid/65/Default.aspx The Core Protocolos v 3.02].
Pueden leer más sobre [[The Core]] en el libro '''Software for your head''', de Jim y Michele McCarthy (ISBN 0-201-60456-6).

== Los protocolos de The Core v 3.02 ==

'''(The Core está distribuido bajo la [http://www.gnu.org/licenses/gpl.txt licencia GNU -PL]. The Core se considera como el código fuente bajo esa licencia. Son libres de usar, distribuir este trabajo o cualquier derivado que hagan, siempre y cuando también distribuyan este documento fuente en forma completa, incluyendo este párrafo).'''

=== Los compromisos de The Core ===
# Me comprometo a estar involucrado cuando estoy presente.
#* A conocer e informar
#** lo que quiero,
#** lo que pienso, y
#** lo que siento.
#* A siempre buscar ayuda efectiva.
#* A no ofrecer y negarme a aceptar transmiciones emocionales incoherentes.
#* Cuando tengo o escucho una mejor idea que la actual, inmediantamente voy a
#** proponerla para una aceptación decisiva o rechazo, y/o
#** explícitamente voy a buscar que se mejore
#* Personalmente voy a apoyar la mejor idea
#** sin importar de quien venga,
#** sin importar cuánto desee que aparezca otra mejor idea más tarde, y
#** cuando no tengo una idea alternativa superior.
# Voy a buscar percibir más de lo que busco ser percibido.
# Voy a usar los equipos, en especial cuando llevo adelante tareas difíciles.
# Voy a hablar siempre y sólo cuando creo que voy a mejorar el ratio general resultado/esfuerzo.
# Voy a ofrecer y aceptar sólo comportamiento y comunicación racional y orientada a resultados.
# Me voy a desinvolucrar de situaciones menos productivas
#* cuando no pueda mantener este compromiso
#* cuando es más importante que me involucre en otro lugar.
# Voy a hacer ahora lo que debe hacerse eventualmente y puede hacerse efectivamente ahora.
# Voy a buscar avanzar hacia un objetivo en particular, llevando mi comportamiento hacia la acción.
# Voy a usar los Protocolos de The Core (o mejores) cuando sea aplicable.
#* Voy a ofrecer y aceptar a tiempo y usar adecuadamente el Protocolo de [[Check-In]]
# No voy a lastimar -ni tolerar que lastimen- a nadie por su fidelidad a estos compromisos.
# No voy a hacer nada tonto a propósito.

=== Pasar (Despasar) ===
El protocolo [[Pasar]] es para declinar la participación en algo. Usalo cada vez que no quieras participar en una actividad.

==== Pasos ====
# Cuando decidís no participar, decí "Paso".
# Podés despasar en cualquier momento que quieras. Despasá ni bien sepas que querés participar otra vez, diciendo "Despaso".

==== Compromisos ====
* Mantener privados los motivos de pasar.
* Pasar en algo ni bien somos conscientes de que vamos a pasar.
* Respetar el decho de los demás a pasar sin explicación.
* No juzgar, avergonazar, molestar, interrogar ni castigar a alguien que pasa.

==== Notas ====
* En general, no vas a estar bien parado frente a los Compromisos de The Core si pasás la mayor parte del tiempo.
* Podés pasar de cualquier actividad; sin embargo, si adoptás los Compromisos de The Core, no podés pasar en un voto de [[Decisión]] y tenés que decir "Estoy presente" al hacer el [[Check-In]].
* Podés pasar aunque ya hayas empezado algo.

=== Check-In ===
Usá el [[Check-In]] para empezar reuniones o en cualquier momento que un Check-In individual o grupal agregue valor a las interacciones del equipo.

==== Pasos ====
# La persona dice "Me siento [uno o más de ENOJADO, TRISTE, CONTENTO, ASUSTADO]". La persona puede dar una breve explicación. O si otros ya hacieron su check-in, la persona puede decir "Paso". (ver el protocolo [[Pasar]]).
# La persona dice "Estoy presente". Esto significa que la persona se comportará de acuerdo a los Compromisos de The Core.
# El resto de las personas responden "Bienvenido".

==== Compromisos ====
* Decir los sentimientos sin adjetivos.
* Decir los sentimientos sólo sin nos pertenecen.
* Estar callados durante el Check-In de otra persona.
* No referirse al Check-In de otra persona sin su permiso explícito para hacerlo.

==== Notas ====
* En el contexto de los Protocolos de The Core, todas las emociones se expresan a través de una combinación de ENOJADO, TRISTE, CONTENTO o ASUSTADO. Por ejemplo, "ansioso" puede ser una combinación de CONTENTO y ASUSTADO.
* Hacer el Check-In lo más profundo posible. Lo normal es hacer el check-in con dos o más emociones. La profundidad del Check-In del grupo se traduce directamente en la calidad de los resultados del grupo.
* No hacer nada por disminuir el estado emocional. No describirnos como "un poquito" enojado, triste, contento o asustado, ni tampoco decir "Estoy enojado, PERO igual estoy contento".
* Excepto en los grupos muy grandes, si más de una persona hace el check-in, es recomendable que todos lo hagan.
* FELIZ puede ser un sustito de CONTENTO, y CON MIEDO puede ser un sustitio de ASUSTADO.

=== Check-Out ===
El [[Check-Out]] requiere que nuestra presencia física siempre signifique nuestro involucramiento. Debemos hacer un Check-Out cuando somos conscientes que no podemos mantener los Compromisos de The Core o cuando es mejor para nosotros estar en otro lugar.

==== Pasos ====
# Decir "Hago un Check-Out".
# Físicamente dejar al grupo hasta que estemos listos para hacer un nuevo Check-In.
# Opcionalmente, si lo sabemos y es relevante, podemos decir cuándo pensamos volver.
# Quienes están presentes al momento del Check-Out no deben seguir a la persona, preguntar o hablar sobre el Check-Out de la persona.

==== Compromisos ====
* Retornar ni bien podamos seguir los Compromisos de The Core.
* Retonar y hacer un Check-In sin llamar la atención por nuestro retorno.
* No juzgar, avergonzar, molestar, interrogar o castigar a nadie que hace un Check-out.

==== Notas ====
* Cuando hacemos un Check-Out hacerlo de la forma más calmada que sea posible, de manera de causar la menor interrupción posible a los demás.
* Hacer un Check-Out si nuestra estado emocional nos impide colaborar, si tenemos una recepción baja a nueva información, o si no sabemos lo que queremos.
* El Check-Out es admitir que no podemos contribuir en ese momento.

=== Pedir ayuda ===
El protocolo de [[Pedir ayuda]] nos permite hacer un uso eficiente de las habilidades y conocimientos de otros. Pedir ayuda es el acto que cataliza la [[Conexión]] y uan [[Visión compartida]]. Debemos usarlo continuamente, antes y durante la búsqueda de cualquier resultado.

==== Pasos ====
# Quien pide le pregunta a otro; "[Nombre de quien ayuda], ¿harías X?".
# Quien pide expresa todas las cosas específicas o restricciones de la petición.
# Quien ayuda responde diciendo "Si" o "No", u ofreciendo una forma alternativa de ayuda.

==== Compromisos ====
* Siempre empezar el Protocolo de Pedir ayuda con la frase "¿harías....?".
* Tener una comprensión clara de lo que queremos que haga quien nos ayuda, o si no tenemos en claro la ayuda que queremos, dejarlo en claro diciendo "No estoy seguro con qué necesito ayuda, ¿me ayudarías?".
* Asumir que todos quienes ayudan están siempre disponibles, y confiar que cada uno de quienes ayudan aceptan la responsabilidad de decir "No".
* Decir "No" cada vez que no querramos ayudar.
* Aceptar la respuesta "No" sin hacer preguntas ni un drama emocional.
* Ser receptivos de la ayuda ofrecida.
* Ofrecer nuestra mejor ayuda incluso aunque no sea lo que está esperando quien pide.
* Postponer el pedido de ayuda si no podemos estar completamente involucrados.
* Pedir más información si no tenemos en claro en qué consiste la ayuda que nos piden.
* No disculparse por pedir ayuda.

==== Notas ====
* Es "barato" pedir ayuda. El peor resultado es un "No", lo que nos deja ni más adelante ni más atrás de antes de pedir. En el mejor escenario, reducimos el tiempo para hacer una tarea y/o aprender.
* Quienes ayudan deben decir "No" si no están seguros de querer ayudar. No deben decir nada más después de negarse.
* No podemos "pedir demasiada ayuda" a una persona, a menos que explícitamente esa persona haya pedido que se respete un límite en particular.
* Si no comprendemos el valor de lo que se ofrece, o sentimos que no sería útil, o creemos que ya consideramos y rechazamos la idea anteriormente, usemos una postura curiosa en vez de rechazar automáticamente con un "pero..." (ver el protocolo [[Investigar]])
* Pedir cuando hay problemas quienes decir que esperamos demasiado tiempo para pedir ayuda. Debemos pedir ayuda cuando nos está yendo bien.
* El simple hecho de conectarnos con alguien, incluso cuando esta persona no sepa nada del tema, pueden ayudarnos a encontrar respuestas dentro de nosotros mismos, especialmente si le pedimos a esa persona que nos Investigue.

=== Comprobación de protocolo ===
Usar la Comprobación de protocolo cuando creemos que se está usando un protocolo de forma incorrecta, o cuando se está rompiendo uno de los Compromisos de The Core.

==== Pasos ====
# Decir "Comprobación de protocolo".
# Si sabemos el uso correcto del protocolo, decirlo. Sino, [[Pedir ayuda]].

==== Compromisos ====
* Decir "Comprobación de protocolo" ni bien seamos conscientes del uso incorrecto de un protocolo, o si se viola alguno de los Compromisos de The Core. Hacerlo sin importar la actividad que se esté llevando a cabo.
* Apoyar a cualquiera que use la Comprobación de protocolo.
* No avergonzar ni castigar a nadie que use la Comprobación de protocolo.
* [[Pedir ayuda]] ni bien nos demos cuenta que no sabemos el uso correcto de un protocolo.

=== Comprobación de intención ===
Usar la [[Comprobación de intención]] para clarificar el propósito de nuestro comportamiento, o el de otros. Usarlo cuando no estamos esperando un resultado positvo del comportamiento actual. La [[Comprobación de intención]] verifica la integridad de la intención propia y de otros en un caso dado.

==== Pasos ====
# Preguntar "¿Cuál es mi/tu intención con X?", donde X es algún tipo de comportamiento actual o pendiente de la persona cuya intención queremos conocer.
# Si resulta útil, preguntar "¿Qué respuesta o comportamiento querés de alguien como resultado de X?".

==== Compromisos ====
* Ser consciente de nuestra propia intención antes de comprobar la intención de otros.
* Investigar lo suficiente para descubrir la intención de la persona o de sus acciones.
* Asegurarse de tener la intención de resolver cualquier conflicto de manera pacífica antes de comprobar la intención de otra persona. Si no tenemos una intención pacífica, hacer un [[Check-Out]].
* No ser defensivos cuando alguien nos pregunta cuál es nuestra intención. Si no podemos, hacer un [[Check-Out]].

==== Notas ====
* Si aparece un conflicto que parece irresoluble, hacer un [[Check-Out]] o [[Pedir ayuda]].

=== Decisión ===
Usar [[Decisión]] cada vez que querramos avanzar al equipo de forna inmediata y unánime hacia resultados.

==== Pasos ====
# El proponente dice "Propongo [comportamiento consiso y accionable]".
# El proponente dice "1-2-3".
# Los votantes votan simultáneamente, usando un "Si" (pulgar arriba), "No" (pulgar abajo) o "Lo apoyo" (mano plana).
# Los votantes que no pueden aceptar la propuesta bajo ningún punto de vista deben expresarlo abiertamente diciendo "Mi voto es un no absoluto. No voy a apoyarlo". Si esto ocurre, se retira la propuesta.
# El proponente cuenta los votos.
# El proponente retira la propuesta si la combinación de votos "No" y votos "Lo apoyo" es demasiado grande, o si el proponente no espera concluir con éxito la [[Resolución]] (ver a continuación). Podemos aproximar este "demasiado grande" usando la siguiente heurística:
#* aproximadamente el 50% (o más) de los votos son "Lo apoyo", o
#* la ganancia esperada de la propuesta si fuera aprobada es menor que el costo por el esfuerzo de la [[Resolución]].
# El proponente usa el Protocolo de [[Resolución]] con cada votante "No" para acercarlo a la propuesta, preguntándole "¿Qué sería necesario para que aceptes?".
# El proponente declara aceptada a la propuesta si todos los votos "No" cambian a "Si" o "Lo apoyo".
# El equipo ahora está comprometido a la acción.

==== Compromisos ====
* Proponer no más de un elemento por propuesta.
* Mantenerse presente hasta que esté terminado el protocolo de [[Decisión]]; siempre estar conscientes de cómo nuestro comportamiento afecta al equipo, haciendolo avanzar o poniendo obstáculos.
* Dar nuestra máxima atención a la propuesta por sobre cualquier otra actividad.
* Hablar sólo cuando se es el proponente, o cuando el proponente nos pide hablar.
* Durante el protocolo, no expresar los motivos por los cuales votamos como lo hicimos.
* Revelar inmediatamente cuando somos un votante "No absoluto", y estar listos a proponer una mejor idea.
* Ser personalmente responsable por lograr los resultados del compromiso de la Decisión, incluso aunque haya sido hecha en nuestra ausencia.
* Mantenerse informados sobre los compromisos de una Decisión hechos en nuestra ausencia.
* No discutir con un votante "No absoluto". Siempre pedirle una idea mejor.
* Apoyar activamente las decisiones tomadas.
* Usar la capacidad de "parar el carro" al decir "no me van a convencer sin importar qué pase" con mucha discresión y lo más infrecuentemente posible.
* Insitir todo el tiempo que se sigan los protocolos de [[Decisión]] y [[Resolución]] tal cual están prescriptos, sin importar cuántas veces nos encontremos insistiendo en esto.
* No [[Pasar]] durante una [[Decisión]].
* Trabajar incesantemente para avanzar; estar enfocados a la acción.
* No mirar cómo votan los demás para elegir nuestro voto.
* Evitar usar el protocolo de [[Decisión]] en grupos grandes. Dividir al grupo grande en pequeños subgrupos para tomar decisiones, y usar el grupo grande para informar el estado.

==== Notas ====
* Votar "No" sólo cuando realmente creemos que nuestra contribución para hacer avanzar al equipo después de detenerlo con nuestro voto supera ampliamente el (en general alto) costo que agregamos por votar "No".
* Si no estamos seguros o confusos por la propuesta, apoyarla y buscar clarificación luego de que la propuesta esté resuelta. Si tenemos una propuesta alternativa después de recibir más información, podemos estar seguros que nuestro equipo apoyará la mejor idea (recordar los Compromisos de The Core).
* Votar "No" para hacer cambios menores a lo que de otra manera es una propuesta aceptable sólo detiene el avance del equipo y debería evitarse. En cambio, ofrecer una propuesta adicional después de aprobar la actual o, mejor aún, involucrarse en la implementación para asegurarnos que nuestra idea se lleva adelante.
* Retirar las propuestas débiles. Si una propuesta recibe menos del 70% (aproximado) de votos "Si", es una propuesta débiles y el proponente debería retirarla. Sin embargo, esta decisión queda a criterio del proponente.
* Cada vez que votemos "No" pensar como si fueramos el único votante no.
* Votar "No absoluto" sólo cuando estemos convencidos de tener una contribución importante para hacer a la dirección o liderazgo del equipo, o cuando la integridad lo requiere absolutamente.

=== Investigar ===
Investigar permite aprender sobre cierto fenónemo que ocurre en alguien. Usalo cuando la idea o comportamiento que alguien presenta aparenta ser pobre, confusa o simplemente interesante.

==== Pasos ====
# Actua como si fueras un investigador independiente, pero fascinado, haciendo preguntas hasta que tu curiosidad este satisfecha o hasta que no quieras hacer mas preguntas.

==== COMPROMISOS ====

* Realizar preguntas bien formadas.
* Realizar preguntas que unicamente aumentaran tu comprensión.
* Realizar preguntas solo si el interrogado esta comprometido y parece estar listo para responder mas.
* Abstenerse a emitir opiniones.
* No realizar preguntas donde crees que sabes que es lo que responderá.
* Si no puedes mantenerte como un investigador curioso e independiente, no siguas utilizando el protocolo hasta que puedas volver y mantener estos compromisos.

==== NOTAS ====

* No sacar teorias sobre el investigado ni dar diagnostico alguno.
* Considera utilizar los siguientes tipos de preguntas:
** ¿Que aspecto de X hace que Y Z?
** ¿Puedes darme un ejemplo especifico?
** ¿Que es lo que mas quieres de resolver X?
** ¿Cual es el problema mas grande que ves de X ahora?
** ¿Cual es la cosa mas importante que puedes hacer ahora para ayudar con X?
* Las preguntas ineficientes incluyen las siguientes:
** Preguntas que lleven a una agenda de preguntas.
** Preguntas que intenten esconder una respuesta que tu crees verdadera.
** Preguntas que inviten a contar historias.
** Preguntas que comiencen con "Por que".
* Mantenerse en la intención de obtener mas información
* Si sientes que vas a explotar si no puedes decir lo que tienes en mente, no debes hablar. Considera chequear tus intenciones o utilizar [[Check-Out]].

==Ver también==
* [[Conformación de equipos]]
* [http://www.mccarthyshow.com/LearnForFree/BestPracticesTheCoreProtocols/tabid/65/Default.aspx Descargar The Core Protocols en PDF (inglés)]

[[Category: The Core]]

The Core

2009-10-14T18:41:48Z

Gianu: /* NOTAS */

[[The Core]] es un conjunto de protocolos y prácticas para la [[Conformación de equipos]] efectivos.

== ¿Qué son los protocolos de The Core? ==
Los protocolos de The Core son "mejores prácticas" para las personas, equipos de personas y organizaciones que quieren obtener grandes resultados - todo el tiempo. Son "Core" (núcleo) porque son fundacionales - pueden ser usados por todos los equipos, en todo lugar, incluso si ya tienen patrones organizaciones y mejores prácticas propias. Son "protocolos" porque nombran y prescriben formas de interacción entre las personas (comportamiento), que resultan predecibles, como los "protocolos" que se usan en la diplomacia.

Entonces, los protocolos de The Core:
* son tácticas que las personas pueden usar para obtener mejores resultados
* los pueden usar individuos, equipos y organizaciones
* son de "[[Software Libre]]" y "versionados" (se mejoran con el tiempo), al igual que el software

Suena interesante, ¿no?

A continuación dejamos una traducción de [http://www.mccarthyshow.com/LearnForFree/BestPracticesTheCoreProtocols/tabid/65/Default.aspx The Core Protocolos v 3.02].
Pueden leer más sobre [[The Core]] en el libro '''Software for your head''', de Jim y Michele McCarthy (ISBN 0-201-60456-6).

== Los protocolos de The Core v 3.02 ==

'''(The Core está distribuido bajo la [http://www.gnu.org/licenses/gpl.txt licencia GNU -PL]. The Core se considera como el código fuente bajo esa licencia. Son libres de usar, distribuir este trabajo o cualquier derivado que hagan, siempre y cuando también distribuyan este documento fuente en forma completa, incluyendo este párrafo).'''

=== Los compromisos de The Core ===
# Me comprometo a estar involucrado cuando estoy presente.
#* A conocer e informar
#** lo que quiero,
#** lo que pienso, y
#** lo que siento.
#* A siempre buscar ayuda efectiva.
#* A no ofrecer y negarme a aceptar transmiciones emocionales incoherentes.
#* Cuando tengo o escucho una mejor idea que la actual, inmediantamente voy a
#** proponerla para una aceptación decisiva o rechazo, y/o
#** explícitamente voy a buscar que se mejore
#* Personalmente voy a apoyar la mejor idea
#** sin importar de quien venga,
#** sin importar cuánto desee que aparezca otra mejor idea más tarde, y
#** cuando no tengo una idea alternativa superior.
# Voy a buscar percibir más de lo que busco ser percibido.
# Voy a usar los equipos, en especial cuando llevo adelante tareas difíciles.
# Voy a hablar siempre y sólo cuando creo que voy a mejorar el ratio general resultado/esfuerzo.
# Voy a ofrecer y aceptar sólo comportamiento y comunicación racional y orientada a resultados.
# Me voy a desinvolucrar de situaciones menos productivas
#* cuando no pueda mantener este compromiso
#* cuando es más importante que me involucre en otro lugar.
# Voy a hacer ahora lo que debe hacerse eventualmente y puede hacerse efectivamente ahora.
# Voy a buscar avanzar hacia un objetivo en particular, llevando mi comportamiento hacia la acción.
# Voy a usar los Protocolos de The Core (o mejores) cuando sea aplicable.
#* Voy a ofrecer y aceptar a tiempo y usar adecuadamente el Protocolo de [[Check-In]]
# No voy a lastimar -ni tolerar que lastimen- a nadie por su fidelidad a estos compromisos.
# No voy a hacer nada tonto a propósito.

=== Pasar (Despasar) ===
El protocolo [[Pasar]] es para declinar la participación en algo. Usalo cada vez que no quieras participar en una actividad.

==== Pasos ====
# Cuando decidís no participar, decí "Paso".
# Podés despasar en cualquier momento que quieras. Despasá ni bien sepas que querés participar otra vez, diciendo "Despaso".

==== Compromisos ====
* Mantener privados los motivos de pasar.
* Pasar en algo ni bien somos conscientes de que vamos a pasar.
* Respetar el decho de los demás a pasar sin explicación.
* No juzgar, avergonazar, molestar, interrogar ni castigar a alguien que pasa.

==== Notas ====
* En general, no vas a estar bien parado frente a los Compromisos de The Core si pasás la mayor parte del tiempo.
* Podés pasar de cualquier actividad; sin embargo, si adoptás los Compromisos de The Core, no podés pasar en un voto de [[Decisión]] y tenés que decir "Estoy presente" al hacer el [[Check-In]].
* Podés pasar aunque ya hayas empezado algo.

=== Check-In ===
Usá el [[Check-In]] para empezar reuniones o en cualquier momento que un Check-In individual o grupal agregue valor a las interacciones del equipo.

==== Pasos ====
# La persona dice "Me siento [uno o más de ENOJADO, TRISTE, CONTENTO, ASUSTADO]". La persona puede dar una breve explicación. O si otros ya hacieron su check-in, la persona puede decir "Paso". (ver el protocolo [[Pasar]]).
# La persona dice "Estoy presente". Esto significa que la persona se comportará de acuerdo a los Compromisos de The Core.
# El resto de las personas responden "Bienvenido".

==== Compromisos ====
* Decir los sentimientos sin adjetivos.
* Decir los sentimientos sólo sin nos pertenecen.
* Estar callados durante el Check-In de otra persona.
* No referirse al Check-In de otra persona sin su permiso explícito para hacerlo.

==== Notas ====
* En el contexto de los Protocolos de The Core, todas las emociones se expresan a través de una combinación de ENOJADO, TRISTE, CONTENTO o ASUSTADO. Por ejemplo, "ansioso" puede ser una combinación de CONTENTO y ASUSTADO.
* Hacer el Check-In lo más profundo posible. Lo normal es hacer el check-in con dos o más emociones. La profundidad del Check-In del grupo se traduce directamente en la calidad de los resultados del grupo.
* No hacer nada por disminuir el estado emocional. No describirnos como "un poquito" enojado, triste, contento o asustado, ni tampoco decir "Estoy enojado, PERO igual estoy contento".
* Excepto en los grupos muy grandes, si más de una persona hace el check-in, es recomendable que todos lo hagan.
* FELIZ puede ser un sustito de CONTENTO, y CON MIEDO puede ser un sustitio de ASUSTADO.

=== Check-Out ===
El [[Check-Out]] requiere que nuestra presencia física siempre signifique nuestro involucramiento. Debemos hacer un Check-Out cuando somos conscientes que no podemos mantener los Compromisos de The Core o cuando es mejor para nosotros estar en otro lugar.

==== Pasos ====
# Decir "Hago un Check-Out".
# Físicamente dejar al grupo hasta que estemos listos para hacer un nuevo Check-In.
# Opcionalmente, si lo sabemos y es relevante, podemos decir cuándo pensamos volver.
# Quienes están presentes al momento del Check-Out no deben seguir a la persona, preguntar o hablar sobre el Check-Out de la persona.

==== Compromisos ====
* Retornar ni bien podamos seguir los Compromisos de The Core.
* Retonar y hacer un Check-In sin llamar la atención por nuestro retorno.
* No juzgar, avergonzar, molestar, interrogar o castigar a nadie que hace un Check-out.

==== Notas ====
* Cuando hacemos un Check-Out hacerlo de la forma más calmada que sea posible, de manera de causar la menor interrupción posible a los demás.
* Hacer un Check-Out si nuestra estado emocional nos impide colaborar, si tenemos una recepción baja a nueva información, o si no sabemos lo que queremos.
* El Check-Out es admitir que no podemos contribuir en ese momento.

=== Pedir ayuda ===
El protocolo de [[Pedir ayuda]] nos permite hacer un uso eficiente de las habilidades y conocimientos de otros. Pedir ayuda es el acto que cataliza la [[Conexión]] y uan [[Visión compartida]]. Debemos usarlo continuamente, antes y durante la búsqueda de cualquier resultado.

==== Pasos ====
# Quien pide le pregunta a otro; "[Nombre de quien ayuda], ¿harías X?".
# Quien pide expresa todas las cosas específicas o restricciones de la petición.
# Quien ayuda responde diciendo "Si" o "No", u ofreciendo una forma alternativa de ayuda.

==== Compromisos ====
* Siempre empezar el Protocolo de Pedir ayuda con la frase "¿harías....?".
* Tener una comprensión clara de lo que queremos que haga quien nos ayuda, o si no tenemos en claro la ayuda que queremos, dejarlo en claro diciendo "No estoy seguro con qué necesito ayuda, ¿me ayudarías?".
* Asumir que todos quienes ayudan están siempre disponibles, y confiar que cada uno de quienes ayudan aceptan la responsabilidad de decir "No".
* Decir "No" cada vez que no querramos ayudar.
* Aceptar la respuesta "No" sin hacer preguntas ni un drama emocional.
* Ser receptivos de la ayuda ofrecida.
* Ofrecer nuestra mejor ayuda incluso aunque no sea lo que está esperando quien pide.
* Postponer el pedido de ayuda si no podemos estar completamente involucrados.
* Pedir más información si no tenemos en claro en qué consiste la ayuda que nos piden.
* No disculparse por pedir ayuda.

==== Notas ====
* Es "barato" pedir ayuda. El peor resultado es un "No", lo que nos deja ni más adelante ni más atrás de antes de pedir. En el mejor escenario, reducimos el tiempo para hacer una tarea y/o aprender.
* Quienes ayudan deben decir "No" si no están seguros de querer ayudar. No deben decir nada más después de negarse.
* No podemos "pedir demasiada ayuda" a una persona, a menos que explícitamente esa persona haya pedido que se respete un límite en particular.
* Si no comprendemos el valor de lo que se ofrece, o sentimos que no sería útil, o creemos que ya consideramos y rechazamos la idea anteriormente, usemos una postura curiosa en vez de rechazar automáticamente con un "pero..." (ver el protocolo [[Investigar]])
* Pedir cuando hay problemas quienes decir que esperamos demasiado tiempo para pedir ayuda. Debemos pedir ayuda cuando nos está yendo bien.
* El simple hecho de conectarnos con alguien, incluso cuando esta persona no sepa nada del tema, pueden ayudarnos a encontrar respuestas dentro de nosotros mismos, especialmente si le pedimos a esa persona que nos Investigue.

=== Comprobación de protocolo ===
Usar la Comprobación de protocolo cuando creemos que se está usando un protocolo de forma incorrecta, o cuando se está rompiendo uno de los Compromisos de The Core.

==== Pasos ====
# Decir "Comprobación de protocolo".
# Si sabemos el uso correcto del protocolo, decirlo. Sino, [[Pedir ayuda]].

==== Compromisos ====
* Decir "Comprobación de protocolo" ni bien seamos conscientes del uso incorrecto de un protocolo, o si se viola alguno de los Compromisos de The Core. Hacerlo sin importar la actividad que se esté llevando a cabo.
* Apoyar a cualquiera que use la Comprobación de protocolo.
* No avergonzar ni castigar a nadie que use la Comprobación de protocolo.
* [[Pedir ayuda]] ni bien nos demos cuenta que no sabemos el uso correcto de un protocolo.

=== Comprobación de intención ===
Usar la [[Comprobación de intención]] para clarificar el propósito de nuestro comportamiento, o el de otros. Usarlo cuando no estamos esperando un resultado positvo del comportamiento actual. La [[Comprobación de intención]] verifica la integridad de la intención propia y de otros en un caso dado.

==== Pasos ====
# Preguntar "¿Cuál es mi/tu intención con X?", donde X es algún tipo de comportamiento actual o pendiente de la persona cuya intención queremos conocer.
# Si resulta útil, preguntar "¿Qué respuesta o comportamiento querés de alguien como resultado de X?".

==== Compromisos ====
* Ser consciente de nuestra propia intención antes de comprobar la intención de otros.
* Investigar lo suficiente para descubrir la intención de la persona o de sus acciones.
* Asegurarse de tener la intención de resolver cualquier conflicto de manera pacífica antes de comprobar la intención de otra persona. Si no tenemos una intención pacífica, hacer un [[Check-Out]].
* No ser defensivos cuando alguien nos pregunta cuál es nuestra intención. Si no podemos, hacer un [[Check-Out]].

==== Notas ====
* Si aparece un conflicto que parece irresoluble, hacer un [[Check-Out]] o [[Pedir ayuda]].

=== Decisión ===
Usar [[Decisión]] cada vez que querramos avanzar al equipo de forna inmediata y unánime hacia resultados.

==== Pasos ====
# El proponente dice "Propongo [comportamiento consiso y accionable]".
# El proponente dice "1-2-3".
# Los votantes votan simultáneamente, usando un "Si" (pulgar arriba), "No" (pulgar abajo) o "Lo apoyo" (mano plana).
# Los votantes que no pueden aceptar la propuesta bajo ningún punto de vista deben expresarlo abiertamente diciendo "Mi voto es un no absoluto. No voy a apoyarlo". Si esto ocurre, se retira la propuesta.
# El proponente cuenta los votos.
# El proponente retira la propuesta si la combinación de votos "No" y votos "Lo apoyo" es demasiado grande, o si el proponente no espera concluir con éxito la [[Resolución]] (ver a continuación). Podemos aproximar este "demasiado grande" usando la siguiente heurística:
#* aproximadamente el 50% (o más) de los votos son "Lo apoyo", o
#* la ganancia esperada de la propuesta si fuera aprobada es menor que el costo por el esfuerzo de la [[Resolución]].
# El proponente usa el Protocolo de [[Resolución]] con cada votante "No" para acercarlo a la propuesta, preguntándole "¿Qué sería necesario para que aceptes?".
# El proponente declara aceptada a la propuesta si todos los votos "No" cambian a "Si" o "Lo apoyo".
# El equipo ahora está comprometido a la acción.

==== Compromisos ====
* Proponer no más de un elemento por propuesta.
* Mantenerse presente hasta que esté terminado el protocolo de [[Decisión]]; siempre estar conscientes de cómo nuestro comportamiento afecta al equipo, haciendolo avanzar o poniendo obstáculos.
* Dar nuestra máxima atención a la propuesta por sobre cualquier otra actividad.
* Hablar sólo cuando se es el proponente, o cuando el proponente nos pide hablar.
* Durante el protocolo, no expresar los motivos por los cuales votamos como lo hicimos.
* Revelar inmediatamente cuando somos un votante "No absoluto", y estar listos a proponer una mejor idea.
* Ser personalmente responsable por lograr los resultados del compromiso de la Decisión, incluso aunque haya sido hecha en nuestra ausencia.
* Mantenerse informados sobre los compromisos de una Decisión hechos en nuestra ausencia.
* No discutir con un votante "No absoluto". Siempre pedirle una idea mejor.
* Apoyar activamente las decisiones tomadas.
* Usar la capacidad de "parar el carro" al decir "no me van a convencer sin importar qué pase" con mucha discresión y lo más infrecuentemente posible.
* Insitir todo el tiempo que se sigan los protocolos de [[Decisión]] y [[Resolución]] tal cual están prescriptos, sin importar cuántas veces nos encontremos insistiendo en esto.
* No [[Pasar]] durante una [[Decisión]].
* Trabajar incesantemente para avanzar; estar enfocados a la acción.
* No mirar cómo votan los demás para elegir nuestro voto.
* Evitar usar el protocolo de [[Decisión]] en grupos grandes. Dividir al grupo grande en pequeños subgrupos para tomar decisiones, y usar el grupo grande para informar el estado.

==== Notas ====
* Votar "No" sólo cuando realmente creemos que nuestra contribución para hacer avanzar al equipo después de detenerlo con nuestro voto supera ampliamente el (en general alto) costo que agregamos por votar "No".
* Si no estamos seguros o confusos por la propuesta, apoyarla y buscar clarificación luego de que la propuesta esté resuelta. Si tenemos una propuesta alternativa después de recibir más información, podemos estar seguros que nuestro equipo apoyará la mejor idea (recordar los Compromisos de The Core).
* Votar "No" para hacer cambios menores a lo que de otra manera es una propuesta aceptable sólo detiene el avance del equipo y debería evitarse. En cambio, ofrecer una propuesta adicional después de aprobar la actual o, mejor aún, involucrarse en la implementación para asegurarnos que nuestra idea se lleva adelante.
* Retirar las propuestas débiles. Si una propuesta recibe menos del 70% (aproximado) de votos "Si", es una propuesta débiles y el proponente debería retirarla. Sin embargo, esta decisión queda a criterio del proponente.
* Cada vez que votemos "No" pensar como si fueramos el único votante no.
* Votar "No absoluto" sólo cuando estemos convencidos de tener una contribución importante para hacer a la dirección o liderazgo del equipo, o cuando la integridad lo requiere absolutamente.

=== Investigar ===
Investigar permite aprender sobre cierto fenónemo que ocurre en alguien. Usalo cuando la idea o comportamiento que alguien presenta aparenta ser pobre, confusa o simplemente interesante.

==== PASOS ====
# Actua como si fueras un investigador independiente, pero fascinado, haciendo preguntas hasta que tu curiosidad este satisfecha o hasta que no quieras hacer mas preguntas.

==== COMPROMISOS ====

* Realizar preguntas bien formadas.
* Realizar preguntas que unicamente aumentaran tu comprensión.
* Realizar preguntas solo si el interrogado esta comprometido y parece estar listo para responder mas.
* Abstenerse a emitir opiniones.
* No realizar preguntas donde crees que sabes que es lo que responderá.
* Si no puedes mantenerte como un investigador curioso e independiente, no siguas utilizando el protocolo hasta que puedas volver y mantener estos compromisos.

==== NOTAS ====

* No sacar teorias sobre el investigado ni dar diagnostico alguno.
* Considera utilizar los siguientes tipos de preguntas:
** ¿Que aspecto de X hace que Y Z?
** ¿Puedes darme un ejemplo especifico?
** ¿Que es lo que mas quieres de resolver X?
** ¿Cual es el problema mas grande que ves de X ahora?
** ¿Cual es la cosa mas importante que puedes hacer ahora para ayudar con X?
* Las preguntas ineficientes incluyen las siguientes:
** Preguntas que lleven a una agenda de preguntas.
** Preguntas que intenten esconder una respuesta que tu crees verdadera.
** Preguntas que inviten a contar historias.
** Preguntas que comiencen con "Por que".
* Mantenerse en la intención de obtener mas información
* Si sientes que vas a explotar si no puedes decir lo que tienes en mente, no debes hablar. Considera chequear tus intenciones o utilizar [[Check-Out]].

==Ver también==
* [[Conformación de equipos]]
* [http://www.mccarthyshow.com/LearnForFree/BestPracticesTheCoreProtocols/tabid/65/Default.aspx Descargar The Core Protocols en PDF (inglés)]

[[Category: The Core]]

Buenas Practicas De Configuracion De Spring

2009-02-25T13:03:46Z

Gianu:

Aqui hay una recopilacion de buenas practicas a la hora de configurar Spring, las mismas son traducciones de: [http://www.onjava.com/pub/a/onjava/2006/01/25/spring-xml-configuration-best-practices.html Twelve Best Practices for Spring XML]

== Evitar el uso de autowiring ==

Spring puede hacer autowiring de dependencias haciendo instropeccion de las clases, logrando de esta manera evitar que uno tenga que especificar las propiedades del bean o los argumentos de los constructores. Se puede hacer autowiring de las propiedades de los beans ya sea por nombre de propiedad o por tipo. En el caso de los constructores, solo se permite por tipo. Tambien se puede especificar el modo "autodetect autoriwiring", que deja que Spring elija el mecanismo mas apropiado. Miremos el siguiente código:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService"
autowire="byName"/>
</code>

Los nombres de las propiedades de la clase InvasorService son usadas para buscar instancias de beans en el contenedor. El uso de Autowiring nos salva de tipear mucho código. De todas formas, nunca deberiamos utilizar Autowiring en una aplicación real porque perjudicamos la legibilidad de nuestro archivo de configuración y la mantenibilidad del mismo. Parece una buena idea hacer que nuestros archivos XML de configuración sean pequeños, pero esto aumenta en gran medida la complejidad de comprensión de la solución.

Spring tambien nos permite mezclar las dos técnicas (Autowiring y no-autowiring), pero con esto solamente lograriamos hacer mucho mas confusa la configuración.

== Usar convenciones de nomenclatura ==

Esta es la misma filosofia que utilizamo con el código Java. Usar una nomenclatura clara, descriptiva y consistente en todo el proyecto es de gran ayuda para que los desarrolladores entiendan la configuración XML. Para el id de los Beans, por ejemplo, se puede seguir la convención de atributos de una clase Java. El Bean ID de una instancia de ''InvasorDAO'' podria ser ''InvasorDAO''. En proyectos grandes, se puede agregar el nombre del paquete como prefijo del Bean ID.

== Usar formas abreviadas de configuración ==

Las formas abreviadas son mas faciles de leer, dado que transforma el valor de los elementos hijos en atributos del elemento padre. Por ejemplo:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService">
<property name="nombreInvasor">
<value>Zim</value>
</property>
<constructor-arg>
<ref bean="invasorDAO">
</constructor-arg>
</bean>
</code>

puede ser reescrito de forma abreviada:

<code lang="xml">
<bean id="InvasorService"
class="com.dosideas.spring.InvasorService">
<property name="nombreInvasor" value="Zim"/>
<constructor-arg ref="invasorDAO"/>
</bean>
</code>

Este feature esta disponible desde la versión 1.2 de Spring. Vale aclarar que no existe abreviacion para el elemento <ref local="...">.

Esta forma de abreviar nuestra configuración no solo nos evita tipear, tambien deja al archivo XML mucho mas claro.

== Utilizar type en vez de index para los argumentos del constructor ==

Spring permite utilizar indices (que comienzan en cero) para resolver el problema de ambigüedad cuando un constructor tiene mas de un argumento del mismo tipo, o cuando se utiliza el atributo '''value''' para asignar el valor. Por ejemplo, en vez de:

<code lang="xml">
<bean id="InvasorService"
class="com.dosideas.spring.InvazorService">
<constructor-arg index="0" value="Zim"/>
<constructor-arg index="1" value="100"/>
</bean>
</code>

es mejor utilizar el atributo '''type''' de la siguiente manera:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService">
<constructor-arg type="java.lang.String" value="Zim"/>
<constructor-arg type="int" value="100"/>
</bean>
</code>

Utilizar '''index''' es mas sencillo, ya que tipeamos menos, pero es mas propenso a errores y mucho mas dificil de leer que si utilizamos '''type'''. Se deberia utilizar '''index''' solamente cuando se presenta una ambigüedad en los argumentos del constructor.

== En lo posible, reutilizar definiciones de Beans ==

Spring ofrece un mecanismo de pseudo-herencia que reduce la duplicacion de informacion en los archivos de configuracion. Una definición de un Bean hijo puede heredar la información de configuracion de sus padres, los cuales sirven como un "template" para los beans hijos. En grandes proyectos el uso de este feature deberia ser obligatorio. Todo lo que se necesita hacer es especificar '''abstract=true''' en el Bean padre y referenciar a dicho Bean desde los Beans hijos. Por ejemplo:

<code lang="xml">
<bean id="abstractInvasorService" abstract="true"
class="com.dosideas.spring.AbstractInvasorService">
<property name="nombreInvasor" value="Zim"/>
</bean>

<bean id="InvasorService"
parent="abstractInvasorService"
class="com.dosideas.spring.InvasorService">
<property name="robotAsignado" value="Gir"/>
</bean>
</code>

El bean ''InvasorService'' hereda el valor '''Zim''' para la propiedad '''nombreInvasor''' del bean ''abstractInvasorService''. Una aclaración: Si no se especifica el nombre de una clase un un factory method en la definición de un bean, este bean es implicitamente abstracto.

== Integrar archivos de configuración mediante ApplicationContext y no utilizando import ==

Al igual que el import en los scripts de Ant, el import en Spring es conveniente para unir archivos modularizados de comfiguración. Por ejemplo:

<code lang="xml">
<beans>
<import resource="InvasorServices.xml"/>
<import resource="RobotsServices.xml"/>

<bean id="PlanetaObjetivoService"
class="com.dosideas.spring.PlanetaObjetivoService"/>
<beans>
</code>

En vez de unirlos dentro del XML utilizando imports, es mucho mas flexible configurarlo a traves del ApplicationContext. Utilizando ApplicationContext tambien hace que nuestra configuración XML sea mas facil de manejar. Se le puede pasar como argumento al constructor de ApplicationContext una lista de archivos de configuración. Nuestro ejemplo anterior quedaria:

<code lang="java">
String[] serviceResources =
{"PlanetaServices.xml",
"InvasorServices.xml",
"RobotServices.xml"};
ApplicationContext orderServiceContext = new
ClassPathXmlApplicationContext(serviceResources);
</code>

== Usar ids como identificadores de beans ==

Se pueden especificar un name o un id como identificador de beans. Utilizar ids no incrementa la legibilidad, pero puede permitir que el parser XML valide las referencias de los beans. Si los ids no pueden ser utilizados debido a alguna restriccion XML IDREF, se pueden utilizar nombres como identificadores de beans. La restriccion XML IDREF dice que los ids deben comenzar con una letra (o alguno de los pocos caracteres de signo de puntuación permitidos en la especificación XML) seguido de letras, digitos, guiones, guiones bajos, dos puntos, o punto. Es muy raro que en algun proyecto tengamos un problema con algun nombre por no cumplir con estas restricciones.

== Usar dependency-check durante la fase de desarrollo ==

Se puede asignar al atributo dependency-check en la definicion de un bean un valor destinto del default '''none''', como ser: '''simple''', '''objects''', o '''all'''. Con esto el contenedor puede realizar valiadciones de dependencias. Esto es util cuando todas las propiedades (o cierto grupo de propiedades) de un bean deben ser asignadas explicitamente (o por autowiring...pero ya dijimos lo malo de usar autowiring).

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService"
dependency-check="objects">
<property name="nombreInvasor" value="Zim"/>
<constructor-arg ref="invasorDAO"/>
</bean>
</code>

En este ejemplo, el contendedor se asegurara que las propiedades de InvasorService que no sean primitivos o colecciones esten asignadas. Se puede configurar el chequeo de dependencias para que controle que todas las propiedades del bean esten asignadas, pero esto es necesario en raras ocasiones ya que puede que haya propiedades que no necesiten ser asignadas.

== Agregar un descripcion en el encabezado de cada archivo de configuración ==

Es preferible usar ids y nombres descriptivos en vez de utilizar comentarios en los archivos de configuración. Adicionalmente, es útil agregar un encabezado en los archivos de configuración, el cual englobe los beans definidos en el archivo. Por ejemplo:

<code lang="xml">
<beans>
<description>
Este archivo define los Invasores que
atacaran los disintos planetas. Depende
de RobotsServices.xml, el cual provee los
servicios de los robots que cada invasor tiene
asignado....
</description>
...
</beans>
</code>

== Comunicar los cambios al equipo ==

Cuando se esta refactorizando código Java, es necesario asegurarse de actualizar el archivo de configuración para que refleje los cambios realizados e informar estos cambios a los miembros del equipo. El archivo de configuración XML es parte del código y es una parte crítica de la aplicación. La mayoria de las veces es necesario leer tanto el archivo XML como el código java para comprender como funciona algun componente.

== Utilizar inyección de dependencias por Setter en vez de por Constructor ==

Spring provee tres tipos de inyección de dependencias: inyección por constructor, por setter y por método. Usualmente solamente utilizamos las dos primera.

<code lang="xml">
<bean id="invasorService" class="com.dosideas.spring.InvasorService">
<constructor-arg ref="invasorDAO"/>
</bean>

<bean id="robotService" class="com.dosideas.spring.RobotService">
<property name="robotDAO" ref="robotDAO">
</bean>
</code>

En este ejemplo, el bean '''invasorService''' usa inyección por constructor, mientras que el bean '''robotService''' usa inyección por setter. La inyección de dependencias por constructor garantiza que el bean no sera construido con un estado inválido, pero la inyección de dependencias por setters es mucho mas flexible, especialmente cuando la clase tiene muchas propiedades y la mayoria de ellas son opcionales.

== No abusar de la inyección de dependencias ==

El ApplicationContext de Spring puede crear los objetos java que sean necesarios, pero no todos los objetos deberian ser creados a travez del motor de inyección de dependencias. Como ejemplo, los objetos de dominio no deberian ser creados utilizando inyección de dependencia. Los archivos de configuración pueden sobrecargarse mucho si no se controla bien el crecimiento de los beans definidos. Sobreutilizar la inyección de dependencia puede hacer el archivo de configuración muy complicado y sobrecargado.

Buenas Practicas De Configuracion De Spring

2009-02-25T12:56:14Z

Gianu:

Buenas Practicas De Configuracion De Spring

2009-02-25T12:49:18Z

Gianu:

Buenas Practicas De Configuracion De Spring

2009-02-25T12:44:57Z

Gianu:

Buenas Practicas De Configuracion De Spring

2009-02-25T12:40:27Z

Gianu: /* Usar dependency-check durante la fase de desarrollo */

Buenas Practicas De Configuracion De Spring

2009-02-25T12:40:12Z

Gianu: /* Usar dependency-check durante la fase de desarrollo */

Aqui hay una recopilacion de buenas practicas a la hora de configurar Spring, las mismas son traducciones de: [http://www.onjava.com/pub/a/onjava/2006/01/25/spring-xml-configuration-best-practices.html Twelve Best Practices for Spring XML]

== Evitar el uso de autowiring ==

Spring puede hacer autowiring de dependencias haciendo instropeccion de las clases, logrando de esta manera evitar que uno tenga que especificar las propiedades del bean o los argumentos de los constructores. Se puede hacer autowiring de las propiedades de los beans ya sea por nombre de propiedad o por tipo. En el caso de los constructores, solo se permite por tipo. Tambien se puede especificar el modo "autodetect autoriwiring", que deja que Spring elija el mecanismo mas apropiado. Miremos el siguiente código:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService"
autowire="byName"/>
</code>

Los nombres de las propiedades de la clase InvasorService son usadas para buscar instancias de beans en el contenedor. El uso de Autowiring nos salva de tipear mucho código. De todas formas, nunca deberiamos utilizar Autowiring en una aplicación real porque perjudicamos la legibilidad de nuestro archivo de configuración y la mantenibilidad del mismo. Parece una buena idea hacer que nuestros archivos XML de configuración sean pequeños, pero esto aumenta en gran medida la complejidad de comprensión de la solución.

Spring tambien nos permite mezclar las dos técnicas (Autowiring y no-autowiring), pero con esto solamente lograriamos hacer mucho mas confusa la configuración.

== Usar convenciones de nomenclatura ==

Esta es la misma filosofia que utilizamo con el código Java. Usar una nomenclatura clara, descriptiva y consistente en todo el proyecto es de gran ayuda para que los desarrolladores entiendan la configuración XML. Para el id de los Beans, por ejemplo, se puede seguir la convención de atributos de una clase Java. El Bean ID de una instancia de ''InvasorDAO'' podria ser ''InvasorDAO''. En proyectos grandes, se puede agregar el nombre del paquete como prefijo del Bean ID.

== Usar formas abreviadas de configuración ==

Las formas abreviadas son mas faciles de leer, dado que transforma el valor de los elementos hijos en atributos del elemento padre. Por ejemplo:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService">
<property name="nombreInvasor">
<value>Zim</value>
</property>
<constructor-arg>
<ref bean="invasorDAO">
</constructor-arg>
</bean>
</code>

puede ser reescrito de forma abreviada:

<code lang="xml">
<bean id="InvasorService"
class="com.dosideas.spring.InvasorService">
<property name="nombreInvasor" value="Zim"/>
<constructor-arg ref="invasorDAO"/>
</bean>
</code>

Este feature esta disponible desde la versión 1.2 de Spring. Vale aclarar que no existe abreviacion para el elemento <ref local="...">.

Esta forma de abreviar nuestra configuración no solo nos evita tipear, tambien deja al archivo XML mucho mas claro.

== Utilizar type en vez de index para los argumentos del constructor ==

Spring permite utilizar indices (que comienzan en cero) para resolver el problema de ambigüedad cuando un constructor tiene mas de un argumento del mismo tipo, o cuando se utiliza el atributo '''value''' para asignar el valor. Por ejemplo, en vez de:

<code lang="xml">
<bean id="InvasorService"
class="com.dosideas.spring.InvazorService">
<constructor-arg index="0" value="Zim"/>
<constructor-arg index="1" value="100"/>
</bean>
</code>

es mejor utilizar el atributo '''type''' de la siguiente manera:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService">
<constructor-arg type="java.lang.String" value="Zim"/>
<constructor-arg type="int" value="100"/>
</bean>
</code>

Utilizar '''index''' es mas sencillo, ya que tipeamos menos, pero es mas propenso a errores y mucho mas dificil de leer que si utilizamos '''type'''. Se deberia utilizar '''index''' solamente cuando se presenta una ambigüedad en los argumentos del constructor.

== En lo posible, reutilizar definiciones de Beans ==

Spring ofrece un mecanismo de pseudo-herencia que reduce la duplicacion de informacion en los archivos de configuracion. Una definición de un Bean hijo puede heredar la información de configuracion de sus padres, los cuales sirven como un "template" para los beans hijos. En grandes proyectos el uso de este feature deberia ser obligatorio. Todo lo que se necesita hacer es especificar '''abstract=true''' en el Bean padre y referenciar a dicho Bean desde los Beans hijos. Por ejemplo:

<code lang="xml">
<bean id="abstractInvasorService" abstract="true"
class="com.dosideas.spring.AbstractInvasorService">
<property name="nombreInvasor" value="Zim"/>
</bean>

<bean id="InvasorService"
parent="abstractInvasorService"
class="com.dosideas.spring.InvasorService">
<property name="robotAsignado" value="Gir"/>
</bean>
</code>

El bean ''InvasorService'' hereda el valor '''Zim''' para la propiedad '''nombreInvasor''' del bean ''abstractInvasorService''. Una aclaración: Si no se especifica el nombre de una clase un un factory method en la definición de un bean, este bean es implicitamente abstracto.

== Integrar archivos de configuración mediante ApplicationContext y no utilizando import ==

Al igual que el import en los scripts de Ant, el import en Spring es conveniente para unir archivos modularizados de comfiguración. Por ejemplo:

<code lang="xml">
<beans>
<import resource="InvasorServices.xml"/>
<import resource="RobotsServices.xml"/>

<bean id="PlanetaObjetivoService"
class="com.dosideas.spring.PlanetaObjetivoService"/>
<beans>
</code>

En vez de unirlos dentro del XML utilizando imports, es mucho mas flexible configurarlo a traves del ApplicationContext. Utilizando ApplicationContext tambien hace que nuestra configuración XML sea mas facil de manejar. Se le puede pasar como argumento al constructor de ApplicationContext una lista de archivos de configuración. Nuestro ejemplo anterior quedaria:

<code lang="java">
String[] serviceResources =
{"PlanetaServices.xml",
"InvasorServices.xml",
"RobotServices.xml"};
ApplicationContext orderServiceContext = new
ClassPathXmlApplicationContext(serviceResources);
</code>

== Usar ids como identificadores de beans ==

Se pueden especificar un name o un id como identificador de beans. Utilizar ids no incrementa la legibilidad, pero puede permitir que el parser XML valide las referencias de los beans. Si los ids no pueden ser utilizados debido a alguna restriccion XML IDREF, se pueden utilizar nombres como identificadores de beans. La restriccion XML IDREF dice que los ids deben comenzar con una letra (o alguno de los pocos caracteres de signo de puntuación permitidos en la especificación XML) seguido de letras, digitos, guiones, guiones bajos, dos puntos, o punto. Es muy raro que en algun proyecto tengamos un problema con algun nombre por no cumplir con estas restricciones.

== Usar dependency-check durante la fase de desarrollo ==

Se puede asignar al atributo dependency-check en la definicion de un bean un valor destinto del default '''none''', como ser: '''simple''', '''objects''', o '''all'''. Con esto el contenedor puede realizar valiadciones de dependencias. Esto es util cuando todas las propiedades (o cierto grupo de propiedades) de un bean deben ser asignadas explicitamente (o por autowiring...pero ya dijimos lo malo de usar autowiring :) ).

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService"
dependency-check="objects">
<property name="nombreInvasor" value="Zim"/>
<constructor-arg ref="invasorDAO"/>
</bean>
</code>

En este ejemplo, el contendedor se asegurara que las propiedades de InvasorService que no sean primitivos o colecciones esten asignadas. Se puede configurar el chequeo de dependencias para que controle que todas las propiedades del bean esten asignadas, pero esto es necesario en raras ocasiones ya que puede que haya propiedades que no necesiten ser asignadas.

Buenas Practicas De Configuracion De Spring

2009-02-25T12:39:23Z

Gianu: /* Usar dependency-check durante la fase de desarrollo */

Aqui hay una recopilacion de buenas practicas a la hora de configurar Spring, las mismas son traducciones de: [http://www.onjava.com/pub/a/onjava/2006/01/25/spring-xml-configuration-best-practices.html Twelve Best Practices for Spring XML]

== Evitar el uso de autowiring ==

Spring puede hacer autowiring de dependencias haciendo instropeccion de las clases, logrando de esta manera evitar que uno tenga que especificar las propiedades del bean o los argumentos de los constructores. Se puede hacer autowiring de las propiedades de los beans ya sea por nombre de propiedad o por tipo. En el caso de los constructores, solo se permite por tipo. Tambien se puede especificar el modo "autodetect autoriwiring", que deja que Spring elija el mecanismo mas apropiado. Miremos el siguiente código:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService"
autowire="byName"/>
</code>

Los nombres de las propiedades de la clase InvasorService son usadas para buscar instancias de beans en el contenedor. El uso de Autowiring nos salva de tipear mucho código. De todas formas, nunca deberiamos utilizar Autowiring en una aplicación real porque perjudicamos la legibilidad de nuestro archivo de configuración y la mantenibilidad del mismo. Parece una buena idea hacer que nuestros archivos XML de configuración sean pequeños, pero esto aumenta en gran medida la complejidad de comprensión de la solución.

Spring tambien nos permite mezclar las dos técnicas (Autowiring y no-autowiring), pero con esto solamente lograriamos hacer mucho mas confusa la configuración.

== Usar convenciones de nomenclatura ==

Esta es la misma filosofia que utilizamo con el código Java. Usar una nomenclatura clara, descriptiva y consistente en todo el proyecto es de gran ayuda para que los desarrolladores entiendan la configuración XML. Para el id de los Beans, por ejemplo, se puede seguir la convención de atributos de una clase Java. El Bean ID de una instancia de ''InvasorDAO'' podria ser ''InvasorDAO''. En proyectos grandes, se puede agregar el nombre del paquete como prefijo del Bean ID.

== Usar formas abreviadas de configuración ==

Las formas abreviadas son mas faciles de leer, dado que transforma el valor de los elementos hijos en atributos del elemento padre. Por ejemplo:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService">
<property name="nombreInvasor">
<value>Zim</value>
</property>
<constructor-arg>
<ref bean="invasorDAO">
</constructor-arg>
</bean>
</code>

puede ser reescrito de forma abreviada:

<code lang="xml">
<bean id="InvasorService"
class="com.dosideas.spring.InvasorService">
<property name="nombreInvasor" value="Zim"/>
<constructor-arg ref="invasorDAO"/>
</bean>
</code>

Este feature esta disponible desde la versión 1.2 de Spring. Vale aclarar que no existe abreviacion para el elemento <ref local="...">.

Esta forma de abreviar nuestra configuración no solo nos evita tipear, tambien deja al archivo XML mucho mas claro.

== Utilizar type en vez de index para los argumentos del constructor ==

Spring permite utilizar indices (que comienzan en cero) para resolver el problema de ambigüedad cuando un constructor tiene mas de un argumento del mismo tipo, o cuando se utiliza el atributo '''value''' para asignar el valor. Por ejemplo, en vez de:

<code lang="xml">
<bean id="InvasorService"
class="com.dosideas.spring.InvazorService">
<constructor-arg index="0" value="Zim"/>
<constructor-arg index="1" value="100"/>
</bean>
</code>

es mejor utilizar el atributo '''type''' de la siguiente manera:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService">
<constructor-arg type="java.lang.String" value="Zim"/>
<constructor-arg type="int" value="100"/>
</bean>
</code>

Utilizar '''index''' es mas sencillo, ya que tipeamos menos, pero es mas propenso a errores y mucho mas dificil de leer que si utilizamos '''type'''. Se deberia utilizar '''index''' solamente cuando se presenta una ambigüedad en los argumentos del constructor.

== En lo posible, reutilizar definiciones de Beans ==

Spring ofrece un mecanismo de pseudo-herencia que reduce la duplicacion de informacion en los archivos de configuracion. Una definición de un Bean hijo puede heredar la información de configuracion de sus padres, los cuales sirven como un "template" para los beans hijos. En grandes proyectos el uso de este feature deberia ser obligatorio. Todo lo que se necesita hacer es especificar '''abstract=true''' en el Bean padre y referenciar a dicho Bean desde los Beans hijos. Por ejemplo:

<code lang="xml">
<bean id="abstractInvasorService" abstract="true"
class="com.dosideas.spring.AbstractInvasorService">
<property name="nombreInvasor" value="Zim"/>
</bean>

<bean id="InvasorService"
parent="abstractInvasorService"
class="com.dosideas.spring.InvasorService">
<property name="robotAsignado" value="Gir"/>
</bean>
</code>

El bean ''InvasorService'' hereda el valor '''Zim''' para la propiedad '''nombreInvasor''' del bean ''abstractInvasorService''. Una aclaración: Si no se especifica el nombre de una clase un un factory method en la definición de un bean, este bean es implicitamente abstracto.

== Integrar archivos de configuración mediante ApplicationContext y no utilizando import ==

Al igual que el import en los scripts de Ant, el import en Spring es conveniente para unir archivos modularizados de comfiguración. Por ejemplo:

<code lang="xml">
<beans>
<import resource="InvasorServices.xml"/>
<import resource="RobotsServices.xml"/>

<bean id="PlanetaObjetivoService"
class="com.dosideas.spring.PlanetaObjetivoService"/>
<beans>
</code>

En vez de unirlos dentro del XML utilizando imports, es mucho mas flexible configurarlo a traves del ApplicationContext. Utilizando ApplicationContext tambien hace que nuestra configuración XML sea mas facil de manejar. Se le puede pasar como argumento al constructor de ApplicationContext una lista de archivos de configuración. Nuestro ejemplo anterior quedaria:

<code lang="java">
String[] serviceResources =
{"PlanetaServices.xml",
"InvasorServices.xml",
"RobotServices.xml"};
ApplicationContext orderServiceContext = new
ClassPathXmlApplicationContext(serviceResources);
</code>

== Usar ids como identificadores de beans ==

Se pueden especificar un name o un id como identificador de beans. Utilizar ids no incrementa la legibilidad, pero puede permitir que el parser XML valide las referencias de los beans. Si los ids no pueden ser utilizados debido a alguna restriccion XML IDREF, se pueden utilizar nombres como identificadores de beans. La restriccion XML IDREF dice que los ids deben comenzar con una letra (o alguno de los pocos caracteres de signo de puntuación permitidos en la especificación XML) seguido de letras, digitos, guiones, guiones bajos, dos puntos, o punto. Es muy raro que en algun proyecto tengamos un problema con algun nombre por no cumplir con estas restricciones.

== Usar dependency-check durante la fase de desarrollo ==

Se puede asignar al atributo dependency-check en la definicion de un bean un valor destinto del default '''none''', como ser: '''simple''', '''objects''', o '''all'''. Con esto el contenedor puede realizar valiadciones de dependencias. Esto es util cuando todas las propiedades (o cierto grupo de propiedades) de un bean deben ser asignadas explicitamente.

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService"
dependency-check="objects">
<property name="nombreInvasor" value="Zim"/>
<constructor-arg ref="invasorDAO"/>
</bean>
</code>

En este ejemplo, el contendedor se asegurara que las propiedades de InvasorService que no sean primitivos o colecciones esten asignadas. Se puede configurar el chequeo de dependencias para que controle que todas las propiedades del bean esten asignadas, pero esto es necesario en raras ocasiones ya que puede que haya propiedades que no necesiten ser asignadas.

Buenas Practicas De Configuracion De Spring

2009-02-25T12:35:57Z

Gianu:

Aqui hay una recopilacion de buenas practicas a la hora de configurar Spring, las mismas son traducciones de: [http://www.onjava.com/pub/a/onjava/2006/01/25/spring-xml-configuration-best-practices.html Twelve Best Practices for Spring XML]

== Evitar el uso de autowiring ==

Spring puede hacer autowiring de dependencias haciendo instropeccion de las clases, logrando de esta manera evitar que uno tenga que especificar las propiedades del bean o los argumentos de los constructores. Se puede hacer autowiring de las propiedades de los beans ya sea por nombre de propiedad o por tipo. En el caso de los constructores, solo se permite por tipo. Tambien se puede especificar el modo "autodetect autoriwiring", que deja que Spring elija el mecanismo mas apropiado. Miremos el siguiente código:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService"
autowire="byName"/>
</code>

Los nombres de las propiedades de la clase InvasorService son usadas para buscar instancias de beans en el contenedor. El uso de Autowiring nos salva de tipear mucho código. De todas formas, nunca deberiamos utilizar Autowiring en una aplicación real porque perjudicamos la legibilidad de nuestro archivo de configuración y la mantenibilidad del mismo. Parece una buena idea hacer que nuestros archivos XML de configuración sean pequeños, pero esto aumenta en gran medida la complejidad de comprensión de la solución.

Spring tambien nos permite mezclar las dos técnicas (Autowiring y no-autowiring), pero con esto solamente lograriamos hacer mucho mas confusa la configuración.

== Usar convenciones de nomenclatura ==

Esta es la misma filosofia que utilizamo con el código Java. Usar una nomenclatura clara, descriptiva y consistente en todo el proyecto es de gran ayuda para que los desarrolladores entiendan la configuración XML. Para el id de los Beans, por ejemplo, se puede seguir la convención de atributos de una clase Java. El Bean ID de una instancia de ''InvasorDAO'' podria ser ''InvasorDAO''. En proyectos grandes, se puede agregar el nombre del paquete como prefijo del Bean ID.

== Usar formas abreviadas de configuración ==

Las formas abreviadas son mas faciles de leer, dado que transforma el valor de los elementos hijos en atributos del elemento padre. Por ejemplo:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService">
<property name="nombreInvasor">
<value>Zim</value>
</property>
<constructor-arg>
<ref bean="invasorDAO">
</constructor-arg>
</bean>
</code>

puede ser reescrito de forma abreviada:

<code lang="xml">
<bean id="InvasorService"
class="com.dosideas.spring.InvasorService">
<property name="nombreInvasor" value="Zim"/>
<constructor-arg ref="invasorDAO"/>
</bean>
</code>

Este feature esta disponible desde la versión 1.2 de Spring. Vale aclarar que no existe abreviacion para el elemento <ref local="...">.

Esta forma de abreviar nuestra configuración no solo nos evita tipear, tambien deja al archivo XML mucho mas claro.

== Utilizar type en vez de index para los argumentos del constructor ==

Spring permite utilizar indices (que comienzan en cero) para resolver el problema de ambigüedad cuando un constructor tiene mas de un argumento del mismo tipo, o cuando se utiliza el atributo '''value''' para asignar el valor. Por ejemplo, en vez de:

<code lang="xml">
<bean id="InvasorService"
class="com.dosideas.spring.InvazorService">
<constructor-arg index="0" value="Zim"/>
<constructor-arg index="1" value="100"/>
</bean>
</code>

es mejor utilizar el atributo '''type''' de la siguiente manera:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService">
<constructor-arg type="java.lang.String" value="Zim"/>
<constructor-arg type="int" value="100"/>
</bean>
</code>

Utilizar '''index''' es mas sencillo, ya que tipeamos menos, pero es mas propenso a errores y mucho mas dificil de leer que si utilizamos '''type'''. Se deberia utilizar '''index''' solamente cuando se presenta una ambigüedad en los argumentos del constructor.

== En lo posible, reutilizar definiciones de Beans ==

Spring ofrece un mecanismo de pseudo-herencia que reduce la duplicacion de informacion en los archivos de configuracion. Una definición de un Bean hijo puede heredar la información de configuracion de sus padres, los cuales sirven como un "template" para los beans hijos. En grandes proyectos el uso de este feature deberia ser obligatorio. Todo lo que se necesita hacer es especificar '''abstract=true''' en el Bean padre y referenciar a dicho Bean desde los Beans hijos. Por ejemplo:

<code lang="xml">
<bean id="abstractInvasorService" abstract="true"
class="com.dosideas.spring.AbstractInvasorService">
<property name="nombreInvasor" value="Zim"/>
</bean>

<bean id="InvasorService"
parent="abstractInvasorService"
class="com.dosideas.spring.InvasorService">
<property name="robotAsignado" value="Gir"/>
</bean>
</code>

El bean ''InvasorService'' hereda el valor '''Zim''' para la propiedad '''nombreInvasor''' del bean ''abstractInvasorService''. Una aclaración: Si no se especifica el nombre de una clase un un factory method en la definición de un bean, este bean es implicitamente abstracto.

== Integrar archivos de configuración mediante ApplicationContext y no utilizando import ==

Al igual que el import en los scripts de Ant, el import en Spring es conveniente para unir archivos modularizados de comfiguración. Por ejemplo:

<code lang="xml">
<beans>
<import resource="InvasorServices.xml"/>
<import resource="RobotsServices.xml"/>

<bean id="PlanetaObjetivoService"
class="com.dosideas.spring.PlanetaObjetivoService"/>
<beans>
</code>

En vez de unirlos dentro del XML utilizando imports, es mucho mas flexible configurarlo a traves del ApplicationContext. Utilizando ApplicationContext tambien hace que nuestra configuración XML sea mas facil de manejar. Se le puede pasar como argumento al constructor de ApplicationContext una lista de archivos de configuración. Nuestro ejemplo anterior quedaria:

<code lang="java">
String[] serviceResources =
{"PlanetaServices.xml",
"InvasorServices.xml",
"RobotServices.xml"};
ApplicationContext orderServiceContext = new
ClassPathXmlApplicationContext(serviceResources);
</code>

== Usar ids como identificadores de beans ==

Se pueden especificar un name o un id como identificador de beans. Utilizar ids no incrementa la legibilidad, pero puede permitir que el parser XML valide las referencias de los beans. Si los ids no pueden ser utilizados debido a alguna restriccion XML IDREF, se pueden utilizar nombres como identificadores de beans. La restriccion XML IDREF dice que los ids deben comenzar con una letra (o alguno de los pocos caracteres de signo de puntuación permitidos en la especificación XML) seguido de letras, digitos, guiones, guiones bajos, dos puntos, o punto. Es muy raro que en algun proyecto tengamos un problema con algun nombre por no cumplir con estas restricciones.

== Usar dependency-check durante la fase de desarrollo ==

Se puede asignar al atributo dependency-check en la definicion de un bean un valor destinto del default '''none'', como ser: '''simple''', '''objects''', o '''all'''. Con esto el contenedor puede realizar valiadciones de dependencias. Esto es util cuando todas las propiedades (o cierto grupo de propiedades) de un bean deben ser asignadas explicitamente.

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService"
dependency-check="objects">
<property name="nombreInvasor" value="Zim"/>
<constructor-arg ref="invasorDAO"/>
</bean>
</code>

En este ejemplo, el contendedor se asegurara que las propiedades de InvasorService que no sean primitivos o colecciones esten asignadas. Se puede configurar el chequeo de dependencias para que controle que todas las propiedades del bean esten asignadas, pero esto es necesario en raras ocasiones ya que puede que haya propiedades que no necesiten ser asignadas.

Buenas Practicas De Configuracion De Spring

2009-02-25T12:27:55Z

Gianu:

Buenas Practicas De Configuracion De Spring

2009-02-25T12:23:12Z

Gianu: /* Integrar archivos de configuración mediante ApplicationContext y no utilizando import */

Buenas Practicas De Configuracion De Spring

2009-02-25T12:23:01Z

Gianu: /* Integrar archivos de configuración mediante ApplicationContext y no utilizando import */

Buenas Practicas De Configuracion De Spring

2009-02-25T12:22:41Z

Gianu:

Buenas Practicas De Configuracion De Spring

2009-02-25T12:11:38Z

Gianu:

Buenas Practicas De Configuracion De Spring

2009-02-25T11:56:02Z

Gianu:

Buenas Practicas De Configuracion De Spring

2009-02-25T11:38:47Z

Gianu:

Buenas Practicas De Configuracion De Spring

2009-02-25T11:26:47Z

Gianu:

Buenas Practicas De Configuracion De Spring

2009-02-25T11:24:47Z

Gianu:

== Evitar el uso de autowiring ==

Spring puede hacer autowiring de dependencias haciendo instropeccion de las clases, logrando de esta manera evitar que uno tenga que especificar las propiedades del bean o los argumentos de los constructores. Se puede hacer autowiring de las propiedades de los beans ya sea por nombre de propiedad o por tipo. En el caso de los constructores, solo se permite por tipo. Tambien se puede especificar el modo "autodetect autoriwiring", que deja que Spring elija el mecanismo mas apropiado. Miremos el siguiente código:

<code lang="xml">
<bean id="invasorService"
class="com.dosideas.spring.InvasorService"
autowire="byName"/>
</code>

Los nombres de las propiedades de la clase InvasorService son usadas para buscar instancias de beans en el contenedor. El uso de Autowiring nos salva de tipear mucho código. De todas formas, nunca deberiamos utilizar Autowiring en una aplicación real porque perjudicamos la legibilidad de nuestro archivo de configuración y la mantenibilidad del mismo. Parece una buena idea hacer que nuestros archivos XML de configuración sean pequeños, pero esto aumenta en gran medida la complejidad de comprensión de la solución.

Spring tambien nos permite mezclar las dos técnicas (Autowiring y no-autowiring), pero con esto solamente lograriamos hacer mucho mas confusa la configuración.

== Usar convenciones de nomenclatura ==

Esta es la misma filosofia que utilizamo con el código Java. Usar una nomenclatura clara, descriptiva y consistente en todo el proyecto es de gran ayuda para que los desarrolladores entiendan la configuración XML. Para el id de los Beans, por ejemplo, se puede seguir la convención de atributos de una clase Java. El Bean ID de una instancia de ''InvasorDAO'' podria ser ''InvasorDAO''. En proyectos grandes, se puede agregar el nombre del paquete como prefijo del Bean ID.

Configuracion De Spring

2009-02-25T11:20:45Z

Gianu: /* Ver también */

Dependiendo el tipo de aplicación y entorno, la configuración del contexto de [[Spring Framework]] varia.

==Aplicaciones web==
En las aplicaciones web, Spring puede configurarse de manera muy simple a través de un Listener o un Servlet.

En el archivo ''web.xml'' se agrega la variable de contexto ''contextConfigLocation'', la cual apunta a los archivos de configuración. Luego, puede utilizarse el listener ''ContextLoaderListener'' o el servlet ''ContextLoaderServlet'' (ambos provistos por el framework) para que inicialicen el contexto de Spring.

===Configuración usando ContextLoaderListener===
<code xml>
<web-app>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:archivoDeSpring1.xml,
classpath:archivoDeSpring2.xml
</param-value>
</context-param>

<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
</web-app>
</code>

===Obtención del contexto===
Con el contexto configurado, se utiliza la clase ''WebApplicationContextUtils'' para acceder al contexto de Spring.
<code java>
ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext);
FooBean foo = (FooBean) context.getBean("fooBean");
</code>

==Ver también==
* [[Obtener Variables De Entorno Con Spring]]
* [http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/web/context/support/WebApplicationContextUtils.html Javadoc de WebApplicationContextUtils]
* [[Buenas Practicas De Configuracion De Spring]]

Configuracion De Spring

2009-02-25T11:20:32Z

Gianu: /* Ver también */

Dependiendo el tipo de aplicación y entorno, la configuración del contexto de [[Spring Framework]] varia.

==Aplicaciones web==
En las aplicaciones web, Spring puede configurarse de manera muy simple a través de un Listener o un Servlet.

En el archivo ''web.xml'' se agrega la variable de contexto ''contextConfigLocation'', la cual apunta a los archivos de configuración. Luego, puede utilizarse el listener ''ContextLoaderListener'' o el servlet ''ContextLoaderServlet'' (ambos provistos por el framework) para que inicialicen el contexto de Spring.

===Configuración usando ContextLoaderListener===
<code xml>
<web-app>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:archivoDeSpring1.xml,
classpath:archivoDeSpring2.xml
</param-value>
</context-param>

<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
</web-app>
</code>

===Obtención del contexto===
Con el contexto configurado, se utiliza la clase ''WebApplicationContextUtils'' para acceder al contexto de Spring.
<code java>
ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext);
FooBean foo = (FooBean) context.getBean("fooBean");
</code>

==Ver también==
* [[Obtener Variables De Entorno De Spring]]
* [http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/web/context/support/WebApplicationContextUtils.html Javadoc de WebApplicationContextUtils]
* [[Buenas Practicas De Configuracion Con Spring]]

Buenas Practicas De Configuracion De Spring

2009-02-25T11:20:08Z

Gianu: Buenas Practicas De Configuracion Con Spring trasladada a Buenas Practicas De Configuracion De Spring: Estoy dormido...Sorry

Buenas Practicas De Configuracion Con Spring

2009-02-25T11:20:08Z

Gianu: Buenas Practicas De Configuracion Con Spring trasladada a Buenas Practicas De Configuracion De Spring: Estoy dormido...Sorry

#REDIRECT [[Buenas Practicas De Configuracion De Spring]]

Configuracion De Spring

2009-02-25T11:19:23Z

Gianu: /* Ver también */

Spring Framework

2009-02-25T11:18:57Z

Gianu: /* Ver también */

Spring Framework (también conocido simplemente como Spring) es un framework [[Java]] de [[Software Libre]], liviano de aplicación (también existe actualmente una versión para .NET). Su principal característica es brindar un factory de objetos basado en la [[Inyeccion De Dependencia]].

Por su diseño el framework ofrece mucha libertad a los desarrolladores en Java y soluciones muy bien documentadas y fáciles de usar para las prácticas comunes en la industria.

Mientras que las características fundamentales de este framework pueden emplearse en cualquier aplicación hecha en Java, existen muchas extensiones y mejoras para construir aplicaciones basadas en web por encima de la plataforma [[Java EE]]

{{curso|url=http://www.dosideas.com/cursos/course/view.php?id=4|nombre=Introducción al desarrollo Java EE}}

==Descargar la librería==
Spring puede bajarse libremente de la [http://www.springframework.org web oficial de Spring].

Existen dos distribuciones básicas: la librería de Spring por si misma, y un paquete que contiene Spring junto con todas las dependencias ("with-dependencies"). Este último paquete es el recomendado para comenzar con Spring.

==Ver también==
* [[Configuracion De Spring]]
* [[Enviar Mails Con Spring]]
* [[Interceptores Con Spring]]
* [[Instanciacion De Objetos Con Spring]]
* [[Transacciones Con Spring]]
* [[Mensajeria Con Spring]]
* [[Hibernate Con Spring]]
* [[Web Service Con Spring]]
* [[Ejb Con Spring]]
* [[JSF Con Spring]]
* [[Groovy Con Spring]]
* [[Spring Batch]]

==Más información==
* [http://www.springframework.org Web oficial de Spring ]
* [http://es.wikipedia.org/wiki/Spring_Framework Spring en la Wikipedia ]
* [http://www.springframework.org/docs/Spring-MVC-step-by-step/ Developing a Spring Framework MVC application step-by-step ]
* [http://wiki.netbeans.org/SpringMVConNetBeansGlassFish Step-by-step: Spring MVC with NetBeans and GlassFish]

Spring Framework

2009-02-25T11:18:39Z

Gianu: /* Ver también */

Spring Framework (también conocido simplemente como Spring) es un framework [[Java]] de [[Software Libre]], liviano de aplicación (también existe actualmente una versión para .NET). Su principal característica es brindar un factory de objetos basado en la [[Inyeccion De Dependencia]].

Por su diseño el framework ofrece mucha libertad a los desarrolladores en Java y soluciones muy bien documentadas y fáciles de usar para las prácticas comunes en la industria.

Mientras que las características fundamentales de este framework pueden emplearse en cualquier aplicación hecha en Java, existen muchas extensiones y mejoras para construir aplicaciones basadas en web por encima de la plataforma [[Java EE]]

{{curso|url=http://www.dosideas.com/cursos/course/view.php?id=4|nombre=Introducción al desarrollo Java EE}}

==Descargar la librería==
Spring puede bajarse libremente de la [http://www.springframework.org web oficial de Spring].

Existen dos distribuciones básicas: la librería de Spring por si misma, y un paquete que contiene Spring junto con todas las dependencias ("with-dependencies"). Este último paquete es el recomendado para comenzar con Spring.

==Ver también==
* [[Configuracion De Spring]]
* [[Enviar Mails Con Spring]]
* [[Interceptores Con Spring]]
* [[Instanciacion De Objetos Con Spring]]
* [[Transacciones Con Spring]]
* [[Mensajeria Con Spring]]
* [[Hibernate Con Spring]]
* [[Web Service Con Spring]]
* [[Ejb Con Spring]]
* [[JSF Con Spring]]
* [[Groovy Con Spring]]
* [[Spring Batch]]
* [[Buenas Practicas De Configuracion Con Spring]]

==Más información==
* [http://www.springframework.org Web oficial de Spring ]
* [http://es.wikipedia.org/wiki/Spring_Framework Spring en la Wikipedia ]
* [http://www.springframework.org/docs/Spring-MVC-step-by-step/ Developing a Spring Framework MVC application step-by-step ]
* [http://wiki.netbeans.org/SpringMVConNetBeansGlassFish Step-by-step: Spring MVC with NetBeans and GlassFish]

Buenas Practicas De Configuracion De Spring

2009-02-25T11:18:07Z

Gianu: Buenas Practicas Con Spring trasladada a Buenas Practicas De Configuracion Con Spring: puse mal el nombre :P

Buenas Practicas Con Spring

2009-02-25T11:18:07Z

Gianu: Buenas Practicas Con Spring trasladada a Buenas Practicas De Configuracion Con Spring: puse mal el nombre :P

#REDIRECT [[Buenas Practicas De Configuracion Con Spring]]

Buenas Practicas De Configuracion De Spring

2009-02-25T11:16:48Z

Gianu: Página nueva: == Evitar el uso de autowiring == Spring puede hacer autowiring de dependencias haciendo instropeccion de las clases, logrando de esta manera evitar que uno tenga que especificar las...