Mostrando entradas con la etiqueta Gestión de proyectos. Mostrar todas las entradas
Mostrando entradas con la etiqueta Gestión de proyectos. Mostrar todas las entradas

miércoles, 17 de octubre de 2007

Motivación. ¿Tan dificil es motivar?

En contestación o continuación al post de Sergio "¿Qué pasa con nosotros?":

Aquí en tierras "ibéricas" yo creo que las cosas van cambiando, eso sí, a la velocidad de la luz que entra en un cuarto de revelado...

Obviamente yo sólo puedo hablar de los sectores que conozco personalmente, y aquellos en los que mis allegados me mantienen informado.

Se deba al estado del mercado de trabajo o al cambio de cultura empresarial, el caso es que se van viendo cambios en las políticas de motivación e incentivos de personal. No nos equivoquemos, motivación de un empleado no es darle dinero o subirle el sueldo (que también), son muchas otras cosas y detalles (pequeños en la mayoría de las ocasiones).

En mi propia empresa, antes del verano, y a petición personal del "dire", se organizó un grupo de trabajo representativo de todo el capital humano de la misma para estudiar "nosotros mismos" qué echamos en falta, qué haríamos, cómo mejoraríamos nuestro entorno laboral, etc.

Unos meses después, parece que se van viendo resultados. Enhorabuena.

Por desgracia, mi empresa es un tanto particular, y aun así, un hecho tan simple como "dar las gracias" por un trabajo bien hecho, por unos minutos de más (ya no hablamos de horas), etc. sigue siendo, para determinadas personas, la representación psicológica de "rebajarse" a alguien "por debajo en la escala".

No quiero ni hablar del hecho de pedir opinión, a pesar de que "el chavalito" te da mil vueltas sobre el tema que se discute.

También se de este tipo de reuniones en otras empresas (que yo recuerde ahora de memoria 3 diferentes) en tiempo y forma bastante parecidas.

Pero ojo, no disparemos tan alto. Sergio comenta en su post:


Hace poco mi jefe me preguntaba que podíamos hacer para mejorar el rendimiento del equipo de trabajo en España, me preguntó si no se les podía motivar regalándoles entradas para un partido del Real Madrid, un concierto, o para ir al cine. No fue fácil explicar por qué eso en España no se hace y me dio bastante vergüenza. Sentí como si viniera del tercer mundo, ese al que decimos no pertenecer.



A lo cual, lo único que cabe decir es: sí, somos así.
Probablemente, si regalas un par de entradas de cine en mi empresa, o entradas para el basket (para el Estudiantes, claro), o algo así... seguro que se oiría:

"Prefiero que me de el dinero y ya elegiré yo donde me lo gasto", ó "seguro que eran para él pero no puede ir y no sabe lo que hacer con las entradas" ó "se las habrán regalado".

Como alguno de vosotros sabe, ahora mismo estoy de "externo" en un cliente, el cual, hace unos días, mandó un correo a mis jefes y a mí, agradeciendo y felicitando mi trabajo. Unos días después, el "dire" de mi empresa me mandó un mail felicitándome de nuevo y haciendo sabedores de esta felicitación a los jefes de proyecto. ESTO ES MOTIVACIÓN. Tanto por parte del cliente como por parte de mi propia empresa.

Me llamó de forma inmediata un compañero y amigo por teléfono y me dijo "bueno, no es pasta, pero no está mal ¿no?". efectivamente, no está nada mal.

Sergio, de veras, creo que las cosas están cambiando, pero no vuelvas hasta dentro de unos 20 años o estarás corriendo el riesgo de sufrir un shock.

Un abrazo !!!!.

domingo, 1 de julio de 2007

Mi primera aplicación comercial

 
Sí, por fin DiveGestión ha visto la luz.... ha sido un embarazo largo (más de 2 años) y con un parto dificil (48 horas de tensión...)

Hoy dia 2 de Julio sale a la venta y ya tenemos casi agotado nuestro stock de licencias.

Esta ha sido realmente la causa de la baja frecuencia de contenidos en los últimos tiempos, pero os aseguro que intentaré remediarlo marcándome como objetivo un artículo semanal con lo más interesante que tenga. 

En estos más de dos años de trabajo he aprendido en carne propia lo que Aitor enumera perfectamente en PlanetaCódigo:

  Uno de los grandes problemas con mayúsculas cuando formas parte de una miniempresa-ISV-startup es la cantidad de trabajo brutal que es canalizado a través de cada uno de sus miembros. Sacar la primera version de cualquier aplicación como cita Rands: “no te va a matar, pero lo intentará”.

 

Evidentemente, no he estado sólo: Karlos Simón ha sido el precursor de la idea, el "beta tester" y documentador del proyecto, mientras que en la parte técnica, analítica y minera (por aquello de picar código), ha sido Ignacio Bello quien ha aportado su esfuerzo, tiempo y sabiduría.

Parece esto un "que guapos somos todos y que bien lo hemos hecho". Bueno, pues sí, que leches...   sin la capacidad de trabajar en equipo y a larga distancia, mezclada con grandes dosis de autodisciplina, organización y capacidad de trabajo individual y en solitario, nunca hubiera sido posible este proyecto, realmente monstruoso. Si en realidad quereis saber de que se trata, os diré que es una aplicación orientada a la gestión TOTAL de un centro de buceo.

Como casi todos sabeis, soy buzo (DiveMaster para aquel que le interese, con un blog sobre el tema y todo...), y fue a raiz de la mezcla de "mis dos mundos", el de la ingeniería de software y el del buceo deportivo, cómo surgió el nacimineto del grupo de trabajo.

Por supuesto, contamos con sitio web, aunque estamos aun agregando contenido, las bases de diseño y estructura ya están creadas, pero seguimos mejorándolo.  Está basado en Joomla y en diseño RedBridge de Wordpress.  Aun queda trabajo en este aspecto...

 

Realmente, un grupo pequeño puede hacer grandes obras.

El secreto es rodearse de personas con los suficientes conocimientos, motivación y ganas. El resto: marcarse pequeños hitos sin perder nunca de vista el gran objetivo, y tener la capacidad de variar el orden o posición de los hitos, crear nuevos puntos intermedios si es necesario o desechar aquellos que se transforman en escollos infranqueables que nos hacen perder de vista el objetivo.  Como siempre me ha dicho Ignacio a lo largo del proyecto:

Que lo urgente no te impida ver lo importante 

 

 

Desde el punto de vista de la ingeniería del software, he aprendido algunas cosas:

  • La visión global del proyecto es sumamente importante, porque te hace ver los pequeños desarrollos dentro de su entorno y anticipar posibles necesidades hacia y desde el "todo".
  • La capacidad de cambios continuos en la fase de desarrollo sólo es posible si el proyecto ha sido planificado para absorverlos. Unos requerimientos estancos o un análisis petreos harían imposible un desarrollo "agil".
  • Dejar que el "experto" te diga cómo deben ser y hacerse las cosas, incluso en tu propio desarrollo. Por algo es el experto.
  • y otras muchas que poco a poco ire desgranando en forma de posts, palabra.

Por desgracia, la absorción que hace de tí un proyecto de este calibre deja huella: o cuentas con un respaldo familiar infinito, o despídete (o de la familia o del proyecto), y por eso, desde aquí, públicamente, mis más sentidas disculpas y agradecimiento a mi familia: Isa Mary, mi mujer; Celia, mi hija; y mi mamá, quien siempre me ha dicho que trabajo demasiado...

Por supuesto, a todos aquellos que de una forma u otra me habeis apoyado tanto con cariño, ideas, soporte y aliento: Sergio Bonachella, Rebeca Astasio, Estrella, Luis (aka Luigi), Elba, Juanma Cortés y Rosa (sí, sí, la mamá de Anabel). A todos, muchas gracias.

Ahora solo queda que se venda bien y el esfuerzo no sólo tenga recompensa personal si no también económica, que si no, a la siguiente, Isa me va a decir que sí... 

 

 

 

jueves, 8 de febrero de 2007

Entrevista a la presidente de Microsoft Ibérica

Me entero por navegápolis de una entrevista realizada en la TV3 a Rosa María García, presidente de Microsoft Ibérica, no sólo sobre Windows Vista, su lanzamiento y "virtudes".

La entrevista toca temas como el software libre, política de empresa de Microsoft, gestión de personal y de personas, cultura de empresa trabajo y vida privada... salvo lo tocante al software libre, en el que deja demasiadas frases lapidarias, injustas y en algunas ocasiones rozando la desinformación (por no decir mentiras), la entrevista es muy interesante.

domingo, 28 de enero de 2007

Requerimientos y especificaciones: gestión de expectativas.

Hace unos días Ángel publicaba en PresiónBlogosférica una entrada en la que me vi perfectamente dibujado, y de la que le he robado el título: La gestión de las expectativas.

Por resumirlo, nos cuenta su experiencia con un cliente al que le parecen pocos los beneficios y/o mejoras obtenidas con el proyecto terminado, aun superando este las expectativas iniciales de la fase inicial del mismo. O cómo cuando comentas las posibilidades de una tecnología determinada o un nuevo enfoque, el cliente multiplica sus expectativas exponencialmente para pasar de unas necesidades concretas, a montarse un universo paralelo donde el nuevo sistema será la solución a todos sus problemas presentes, pasados y futuros... la entrada es ideal, muy recomendable.

En el mundo de la consultoría y desarrollo informático, nos encontramos en estos casos con serios problemas: cuando estás en la fase de requerimientos junto al cliente (idealmente, claro), vas dibujando mentalmente pequeñas soluciones concretas. Cuando terminas esta primera fase y estudias el proyecto en su totalidad, planteas la posible solución global, cómo lo vas a hacer, con qué tecnología, etc... y es ahí donde hay que andar con pies de plomo...

Se puede dar el caso de que el cliente vea soluciones nuevas a viejos problemas que no entraban en los requerimientos iniciales... ¿qué haces? ¿Aumentas los requerimientos y por tanto la solución final y por tanto el precio del proyecto? ¿Haces encajar más requerimientos en los ya tomados al mismo precio? Uff... como diría un gallego... depende...

Depende de la venta, del cliente, de tus expectativas de futuro con el cliente, de las expectativas del cliente en torno al proyecto... son decisiones tan particulares y concretas de un momento dado con determinados actores, que no es posible dar una respuesta estándar; aunque sí hay que mantener una línea base:

Si los requerimientos iniciales han sido obtenidos siguiendo unas normas básicas (próximas entradas sobre requerimientos !! ), con la conformidad del cliente, son estos requerimientos los que deben marcar las expectativas y el marco del proyecto, y por tanto, todo aquello que se salga de estos requerimientos mutuamente acordados, deberán ser abordados en un nuevo proyecto o en una ampliación del mismo.

miércoles, 13 de diciembre de 2006

Formación interna en empresas de software

Ayer comenzó, para algunos compañeros en mi empresa, un curso básico de programación orientada a objetos.
Se que a estas alturas muchos de vosotros os preguntareis: "¿ De POO en el año 2006 (2007 casi...) ? ¡Pues a buenas horas!", o... "Je, je... una empresa de desarrollo de software... y un curso de esos a estas alturas, con el Web 2.0 por ahí, AJAX, etc, etc... díme que empresa es para no contar con ella..."


Pues bien, teneis razón, pero en el campo donde se mueve la empresa, realmente, no son necesarios esos conocimientos, ni siquiera hoy en día, en el 90% de los desarrollos; leí hace unos días en PresiónBlogosférica (gracias Angel por el link) titulado "Hacer bien una cosa".

La empresa para la que trabajo, es realmente, si no la mejor, casi, en lo que se refiere al conocimiento del negocio en el que se mueve, sus desarrolladores son especialistas o casi, en la materia, y los analistas no solo son reclamados por los clientes para desarrollos nuevos, si no como consultores que les ayuden en su propio negocio.



Con sólo un día de curso (presentación y esas cosas), ya hay alguno que se ha atrevido a cuestionar la validez del mismo, no solo poniendo en cuestión la calidad profesional de la persona que lo imparte, si no, y lo que me parece más llamativo, la utilidad de esos conocimientos que su empresa le pone al alcance de la mano.
Si bien es cierto que estas personas llevan "haciendo lo mismo" desde hace años, en el mismo entorno, con los mismos métodos, etc. etc., no es menos cierto, por tópico que sea, que el saber no ocupa lugar y más aun en este "mundillo". Frases tales como "si luego se me olvidará... total...", u otras del calibre de "si me valiera para algo...", no son la primera vez que las escucho en situaciones semejantes anteriores. Las mismas, no son más que la expresión hablada, a mi modo de ver, del cerrado entrecejo, limitado entendimiento del mundo informático y empresarial, de la persona que las dice.

La escasa amplitud de miras de estos compañeros, quiero pensar que se debe más a ganas de tocar las narices que a sus sentimientos reales, porque aun en el caso de ser ciertas dichas afirmaciones, ¿alguien les asegura que en un futuro (lejano o no) van a seguir "haciendo lo mismo"? ¿Tienen una bola de cristal en casa en la que han visto que su futuro profesional está asegurado, en puesto y funciones, en la empresa donde están ahora? ¿Realmente piensan que engordar su curriculum de conocimientos es una pérdida de tiempo?.
Si fuera yo, que evidentemente no es el caso, quien tubiera que financiar estos cursos, la siguiente vez me lo pensaría muy mucho, a pesar de poder encontrarme entonces en un círculo vicioso... "Mi empresa no me forma, haré siempre lo mismo, que aburrimiento"... lo que encima, aumentará la desilusión, la baja productividad, y mandará al garete cualquier intento de incentivación del personal.
Y lo peor de todo... es gente joven, muy joven, con una media de alrededor de 30/35 años de carrera profesional por delante... no quiero pensar que será de ellos dentro de 10 años...


Por favor, es un tema en el que necesito críticas y otros puntos de vista, porque se que lo miro con un filtro muy subjetivo. Deja tus comentarios. Gracias por servir de desahogo.

martes, 12 de diciembre de 2006

Reglas para el buen desarrollo de un producto

En el blog Product Musing, hubo una entrada el pasado 5 de Noviembre sobre 20 reglas para conseguir el lanzamiento de un producto software con éxito (en inglés). No es que esté de acuerdo al 100% con todos los puntos, pero realmente, dan en que pensar, o al menos, para echarse unas risas.

Paso a comentar las que me han parecido más acertadas:

  1. Asegúrate de saber qué estás desarrollando. Muchos de los retrasos en los proyectos se deben a que "el cliente", el/los analista/s, los programadores, etc. (inclúyete en el pack correspondiente), no saben realmente cuál es el objetivo final del proyecto. Reconoce, añade en una actualización del post, que lo que estás desarrollando ahora mismo, cambiará casi de forma irremediable en el futuro hasta completar el proyecto, así que asegúrate de que tus procesos, clases, sistemas o subsistemas, admitirán estos cambios preparándolos para ello desde el origen.
  2. Trabaja solo en los puntos necesarios para lanzar la versión 1.0
    • Sin olvidar lo mencionado en el punto anterior, claro...
  3. Asegúrate de mantener un prototipo siempre funcional
    • Si lo vas actualizando con las últimos desarrollos, y lo mantienes accesible a los usuarios finales, podrás ir corrigiendo o debatiendo con ellos desde la interfaz a posibles malentendidos en las funcionalidades de la aplicación, con lo que podrás, entonces, anticipar estos cambios en las partes que aun no has empezado o tienes entre manos...
  4. No hagas del proyecto un escaparate para mostrar lo "guay" que eres
    • Aquí... no es que discrepe, pero... si tu proyecto puedes aprovecharlo como escaparate del buen desarrollo y buen hacer de tu empresa o grupo de trabajo, es posible utilizarlo como un trampolín para futuros proyectos... o a la inversa, si la picias o el cliente no queda contento... una puerta abierta menos...
  5. Lo breve, si bueno, dos veces bueno... osea, mejor las cosas pequeñas
    • No seas mal pensado... estamos hablando de los métodos, ficheros, procesos, funciones....
  6. Si alguien no está en sintonía con el resto del grupo...
    • Habla con él/ella en privado
    • Reasígnalo o cambia sus tareas o funciones
    • Habla con él/ella en privado
    • Y si eres tu mismo... recuerda lo del escaparate...
  7. Diseña los módulos o clases construyendo interfaces, de forma que sea accesible facilmente por terceros módulos, reutilizable y facil de implementar cambios masivos.
    • Documenta estas interfaces a la perfección, pero no los módulos o clases que usa la interface, eso sí, mantén una escrupulosidad absoluta en la facilidad de lectura y mantenimiento del código de estos módulos.
  8. Cuando estés en el proceso de debug de un problema, nunca digas ¡¡¡ Pero si en mi equipo funciona !!!
    • ¿Quién no lo ha dicho alguna vez?
  9. Si hay algún fallo de funcionalidad o algún bug grabe en la parte ya desarrollada, no continues con partes de código nueva hasta haber resuelto estos problemas
  10. Si alguna parte del código es complicada de seguir el Lunes a primera hora, antes del primer café, rediséñalo.

Después de todos estos puntos, sería casi obligado hablar de algunos temas importantes, y debatir sobre ellos:

  • Tomas de especificaciones.
  • Reuniones de seguimiento con los clientes/usuarios y con el equipo de desarrollo.
  • Equipos multidisciplinares o equipos de especialistas
  • Prototipos, maquetas, beta releases...

Y prometo ir ocupándome poco a poco de estas cositas... por supuesto, necesito de tu colaboración, opiniones, críticas, experiencias... no te cortes...

lunes, 11 de diciembre de 2006

Brainstorming (II)

Posteado por Ángel en PresionBlogosferica el 11 de Diciembre de 2006


Tal como
prometí, la continuación del artículo sobre la realización de Brainstormings.

Nos quedamos al final de la fase de creación:



Las ideas han ido surgiendo y se han ido anotando… Es importante insistir en que, si bien debe establecerse un límite horario, es igualmente importante fijar un objetivo cuantitativo, y mi consejo es fijarlo en el orden de los cientos de ideas. A veces no será posible, sobre todo cuando el objetivo de la sesión esté muy delimitado o el campo sea muy específico, pero es bueno marcarse objetivos ambiciosos.


Otra cosa que se me olvidó comentar en el artículo anterior: Invitad a gente de fuera. Los miembros de un grupo, equipo o Departamento pueden estar muy retroalimentados entre ellos con la misma información. Traer a personas de fuera - incluso mejor si no tienen ningún conocimiento sobre la materia - estimulará el proceso creativo. Además, el cruce de experiencias y conocimientos durante la fase de destilación puede ser crucial si de lo que se trata es de innovar.


Pasemos pues a la destilación. Durante esta fase, procuraremos no solo identificar las buenas ideas, sino ver qué podemos aprovechar de las que se descarten e incluso generar nuevas ideas derivadas de las que ya existen.


Al igual que en la fase anterior, existen unas reglas de obligado cumplimiento:


ANOTAR LOS CRITERIOS DE VALORACIÓN: Usar frases comenzando con “Debería”, “Sería deseable”, “Es necesario que”. Esto nos servirá para evaluar las ideas de forma homogenea y no arbitraria.


IDENTIFICAR GRUPOS O CATEGORÍAS DE IDEAS: Para esto, los mapas mentales son fenomenales. Si además habéis seguido mi consejo de usar post-it, podréis ir moviendo las ideas hacia las zonas del mapa a las que pertenezcan.


REVISAR TODAS LAS IDEAS: Por extrañas, pequeñas o absurdas que parezcan, ninguna idea debería quedar si evaluar. Dedicadle al menos un minuto a cada una.Si, ya lo se, cien ideas a un minuto cada una son cien minutos…Nadie dijo que la creación de buenas ideas, de esas que marcan la diferencia, fuese rápida. Si queréis ideas rápidas y baratas, buscad algo en google… (*)


CLARIFICAR LAS IDEAS Y LO QUE SIGNIFICAN: Durante la fase de creación dijimos que no valía criticar ni hacer preguntas. Ahora es el momento. ¿Que ha querido decir la persona que ha propuesta esa idea? ¿En qué funcionamiento estaba pensando exáctamente? ¿Cómo piensa que se imlementaría?


USAR FRASES CONSTRUCTIVAS, NO DESTRUCTIVAS: Si os dedicáis a reiros de los que han propuesto las ideas más absurdas, solo lograréis coartar el proceso creativo. Por otra parte, si no sois constructivos con una idea podríais dejar pasar algún aspecto de la misma que os de la clave de lo que andais buscando… Algunas frase de estimulo podrían ser:


  • ¿Qué se podría hacer con esto?

  • ¿Cómo podría modificar esto para aplicarlo a un nuevo uso?

  • ¿Qué pasaría si se cambiase esto de alguna manera?

  • ¿Qué cambios podríamos introducir para provocar mayor atención?

  • ¿Por qué no arriba en vez de abajo?

  • ¿Qué podríamos eliminar?

  • ¿Qué se conseguiría si alteramos el orden?

  • ¿Cuáles son las cosas opuestas?

  • ¿Por qué no podría tener menos partes?

  • ¿Y si dijésemos esto al revés?


CLASIFICAR O PUNTUAR: Usar un baremo, bien con calificativos (excelente, interesante, no aprovechable) o con puntos (cero a cinco, cero a diez)…



ELIMINAR CONSENSUADAMENTE LAS IDEAS QUE NO SEAN UTILIZABLES: Cuando una idea no vale, no vale. Hay que intentar exprimirlas y luego pasar a la siguiente. Pero si alguien piensa que la idea no es tan mala, quizás tenga razón. Preservadla hasta el final, cuando hagáis una segunda o tercera criba. Solo deberían eliminarse las ideas a las que todos penséis que no se le puede sacar más partido.



Con toda esta información, es recomendable que el coordinador de la sesión realice un pequeño memorandum en el que explique el objetivo, los participantes, las áreas de ideas exploradas y las mejores que se han obtenido. Este tipo de documentos ayudan a demostrar a las organizaciones la utilidad del Brainstorming como técnica productiva.



(*) Esta frase me recuerda a una similar aparecida en una tira cómica protagonizada por

Dogbert: “Puedo darle buenos consejos por una tarifa de 60.000$…También puedo darle malos consejos al precio reducido de 40.000$”

jueves, 7 de diciembre de 2006

Brainstorming (I)

Desde Presión Blogosférica por Ángel

Se abusa demasiado de este término. Cada vez que se juntan cuatro personas a discutir, pensar o darle vueltas a una idea, es que hemos estado de brainstorming. Pero si nos ponemos académicos, este término se refiere a una técnica concreta para estimular el proceso creativo y, como tal, tiene ciertas reglas y procedimientos. Voy a reflejar aquí las que a mi me constan y que he empleado, lamentablemente, en muy poquitas ocasiones (porque las empresas no suelen prestarse a estas frivolidades, fijate ellas que serias ) pero en todas ellas con resultados espectacularmente buenos - ya ves, lo que son las cosas .


Ante todo, es necesario que una persona dirija la sesión. Solo en grupos que ya están muy acostumbrados a la mecánica del brainstorming aconsejaría prescindir de esta figura. El siguiente principio básico de un brainstorming (tormenta de ideas, para los puristas del idioma) es dividir la sesión en dos partes. Tres si lo hacéis con calentamiento.


Un calentamiento consistiría en hacer unas cuantas listas de prueba que no tengan nada que ver con el objetivo de la sesión. Por ejemplo, empezar nombrando cincuenta marcas de comida. Luego seguir con cincuenta prendas de ropa, cincuenta marcas de coche…¿Os acordáis del un-dos-tres? . Da igual si se consigue llenar la lista o no, se trata solo de difuminar un poco la consciencia, comenzar a disociar las ideas y calentar un poco las neuronas.


A continuación hay que centrar el concepto de la sesión: ¿Por qué estamos aquí? ¿Qué queremos conseguir? Para no perder el foco, recomiendo reservar una pizarra o papelógrafo en el que ir realizando un

mapa mental de la sesión.

Pasaríamos entonces a la primera fase del brainstorming: La fase de creación. Durante esta fase, todo vale. La cantidad vale más que la calidad. Se trata de fijar un número determinado de ideas (100, 200, 300…) e ir nombrando todas las que se nos vayan ocurriendo, por absurdas o inconexas que nos parezcan. Hay una serie de reglas que es importante cumplir:


TODO VALE: Da igual lo absurdas que parezcan las ideas. Precisamente cuando se agotan las respuestas convencionales es cuando empieza el proceso creativo.


CANTIDAD ANTES QUE CALIDAD: Lo importante en esta fase es generar muchas ideas, agotar el saco de las preconcebidas, las lógicas y las evidentes


PROHIBIDO CRITICAR: Las ideas no se critican. Todas las ideas valen lo mismo. No se permiten comentarios negativos:

  • Eso no funcionaría
  • Seamos serios
  • Vaya tontería
  • Esto no sirve para nada
  • No tenemos personal / tiempo / recursos / presupuesto para eso


ESTIMULAR/VALORAR LO DIFERENTE Y EXTRAÑO: Frente al punto anterior (no criticar), el contrapunto es precisamente premiar e incentivar las ideas que más se salgan de la senda habitual de pensamiento


ROBAR IDEAS: No solo se permite, sino que se estimula y se premia el copiar las ideas de otros dándole otros matices


TRABAJO EN EQUIPO (NO HAY “PADRES”): El director de la sesión debe conducir la misma y procurar que todo se haga según las reglas, pero ahi acaba su autoridad. No es su labor reñir a los que se saltan las reglas oi los que menos participan. Es el equipo el que debe tomar esa labor.


ORGANIGRAMA PLANO (NO HAY “JEFES”): Si los integrantes del equipo están cohibidos porque hay Jefes en el mismo y no quieren discutir con ellos, contradecirles o temen parecer ridículos ante ellos, es preferible que los Jefes no participen. Lo ideal es que reine un clima de equipo y organigrama plano.


TODOS PARTICIPAN (100% ENERGÍA): El equipo debe procurar estimular a los que más les cueste arrancar. Típicamente, al principio habrá personas que contribuyan poco, pero si logran saltar la barrera mental, se convierten en colaboradores al cien por cien.


TRABAJO EN CÍRCULO: Si en un momento dado la sesión se atasca, repasar desde el principio las ideas generadas y tratar de generar nuevas ideas basadas en ellas o como combinación de varias.


TOMAR NOTA DE TODO: Es responsabilidad del director de la sesión ir tomando notas de todas las ideas. Tambien es recomendable ir identificando areas o grupos de afinidad, para lo cuál es muy util usar el mapa mental que mencionaba al principio. Una técnica muy buena para esto es lo que los americanos llaman COW: Cards On the Wall, o sea, usar post-its u otro tipo de medio para anotar las ideas e ir pegándolas en la pared, lo cuál permite ir moviéndolas de sitio para acercarlos a grupos o areas de similitud.


Seguimos en otro post con la siguiente fase: La destilación…


Technorati Tags: