Dirección de proyectos de Gestión de Información Geoespacial

Tecnologías Geoespaciales & Gestión de Proyectos y Personas.

Archive for the ‘Dirección de proyectos’ Category

Reflexión sobre la ‘colaboración’.

with 2 comments

En las pasadas 4as JORNADAS INTERNACIONALES  gvSIG se celebró una mesa redonda con representantes de Adminstración Pública, Universidad y Empresa para debatir sobre los modelos de colaboración entre estos diferentes actores, en proyectos de software abierto. A pesar de que se celebró a última hora de un día bien intenso, desde luego que resultó interesante, hubo participación y se hizo un buen repaso a temas como: las razones para desarrollar software abierto como modelo de crecimiento en una industria, la evolución que van siguiendo empresas que están incrementando sus servicios en este tipo de proyectos, cómo determinadas empresas consiguen colaborar fomentando escenarios ‘win-win’, y puedendo así abordar proyectos que no podrían acometer solas, razonamientos de por qué la Universidad sólo debería utilizar y formar en herramientas abiertas, etc.

A partir de ese debate, he estado dándole vueltas al tema de la colaboración llevándolo al plano de nuestros propios equipos de trabajo. ¿Cómo vamos a abordar estrategias de colaboración con empresas en red, si nuestros propios equipos de trabajo no son colaborativos? ¿Cómo se puede fomentar la colaboración desde el seno de los equipos de trabajo?

A lo largo del debate se repetían dos palabras que siempre están en juego en la balanza de la colaboración: El ‘Miedo’ y la ‘Confianza’. El ‘Miedo’ suele ser, a perder un conocimiento supuestamente valioso y diferencial, pero que lo curioso es que en realidad, cuando no lo compartamos será cuando estará realmente perdido. Y la ‘confianza’, como el factor clave para crear entornos de colaboración.

Pues esto mismo ocurre a las personas en los equipos de trabajo. Debido a factores culturales de la formación, las personas dan demasiada importancia al ‘conocimiento explicito’, parece que valemos lo que sabemos, cuando en realidad corren tiempos en los que este conocimiento explícito cada vez tiene menos valor frente a otras capacidades, competencias o habilidades. Ahora bien, ¿Qué hace falta para que aflore esa confianza en los equipos?. Pues, seguridad. Las personas tienen que sentirse seguras en sus organizaciones y en el desarrollo de su actividad. Esta es la parte difícil que afrontan los managers de equipos cuando, contando de por sí con pocas herramientas para mantener la motivación de los mismos, tiene que sostener escenarios que reflejen seguridad, en situaciones inciertas de sostenibilidad de proyectos. Porque, no es verdad que ¿Cuándo hay tarta para todos es más fácil colaborar que cuando no? Pues creo que incluso eso tiene sus matices, pues a través de la colaboración se puede hacer la tarta más grande.

Aunque este último comentario suene a la retaila de la crisis, y la falta de inversión y de nuevos proyectos, estamos de suerte en general; las nuevas generaciones de trabajadores son bastante más colaborativas, el sector del GIS está viendo nacer proyectos Open Source diversos, se están formando comunidades colaborativas auto-organizadas, regidas por mecanismos de crecimiento basados en el consenso ( como el Capítulo Hispanohablante de OSGEO ), están naciendo plataformas para fomentar la compartición de proyectos a nivel Europeo (como OSOR), etc.

Un poquito de por favor, más confianza en la colaboración!.

Anuncios

Written by jsgisdev

diciembre 15, 2008 at 2:32 am

Publicado en Dirección de proyectos, Wikinomía

Tagged with

Wikinomics. Mi lectura favorita del 2007.

with 3 comments

wikinomics El año pasado, en algún blog ví una recomendación sobre este libro. La atracción especial que ejerce sobre mí todo aquello que contiene la palabra ‘wiki'[1] hizo que acabara adquiriendo un ejemplar. Durante la lectura he ido recomendándolo a colegas, como pocas veces con un libro. Para mí ha superado todas las espectativas, sobre todo, porque a través de su lectura, he adquirido mayor conciencia del verdadero calado de un fenómeno que tiene la talla de cambio de paradigma empresarial, de cambio profundo.

En el libro se analiza en detalle cómo la nueva colaboración masiva está transformando la manera que tienen las empresas y la sociedad de aprovechar el conocimiento y la competencia, para innovar y crear valor, cómo funcionan las ‘comunidades de iguales’, constituyendo focos de innovación a través de procesos democratizados de auto-organización, y todo a través de descripciones de innumerables casos de éxito reales.

Anteriormente en el blog había tratado temas sobre la importancia de las plataformas de gestión conocimiento en los proyectos , las plataformas de participación, etc. Soy desde hace años usuario de listas de distribución técnicas, y he podido experimentar sus bondades; por mi forma de trabajar, suelo promover la implantación de herramientas colaborativas en los proyectos; mantengo en el tiempo este blog intentando contactar con otros profesionales de similares inquietudes a través de él, y concibiéndolo como una de las herramientas colaborativas más interesantes actualmente. Pero la dimensión del fenómeno que se describe en el libro va más allá de todo eso.

Hay muchas cosas del libro que me gustaría destacar, y que tendrían amplio debate. Pongo de momento una descripción de los puntos que establece como ‘los principios de la wikinomía’ y dejo otros temas para futuros posts. Para la descripción de cada principio de la wikinomía, destaco alguna cita o comentario relevante desde mi punto de vista e intento también destacar reflexiones finales que relativizan lo radicales que pueden parecer algunos de ellos.

PRINCIPIOS DE LA WIKINOMIA

* Apertura: “..Crece el número de compañías inteligentes que caen en la cuenta de que la apertura constituye una fuerza de crecimiento y competitividad..”. Se describe cómo algunas de las empresas más cerradas han encontrado nuevos caminos hacia la apertura, como por ejemplo P&G antes famosa por su ‘secretismo’ , o las que realiza Amazon, eBay, Google, flickr, etc. Me parece muy interesante que se destaca el hecho de que los trabajadores de las empresas abiertas desarrollan una mayor confianza entre ellos mismos y en la empresa, algo que propicia la reducción de costes y el incremento de la innovación y la lealtad.

Respecto a este punto también se destaca al final del libro que “Ni todas las empresas quieren convertirse en una plataforma abierta ni todas deberían serlo. Apple, por ejemplo, no quiere abrir el iPod”.

* Interacción entre iguales: Se menciona el software libre (y en concreto el caso de Linux) como ejemplo de desarrollo de productos a través de comunidades autoorganizadas y el hecho de que estos mecanismos de autoorganización a veces son más eficaces que las estrucutras jerárquicas empresariales para determinadas tareas. Se desarrolla el tema de que las ‘comunidades de iguales’, se dan ya no solo en el campo del software libre, sino en otros muchos sectores actualmente, como la comunidad que se creó en torno a los productos de Lego, dónde los propios usuarios colaboran para crear e innovar productos.

Respecto a cómo desarrollar empresarialmente la capacidad para trabajar eficazmente con comunidades de código abierto, se destaca al final del libro, que no es algo que se logre de un día para otro y que empresas como IBM han ido poniendo a punto sus habilidades en ese sentido durante más de una década de experiencia y de construcción de relaciones.

* Compartir: “Hoy en día, las empresas inteligentes comprenden que compartir es algo más que un requisito de buena conducta. Significa reducir costes, construir una comunidad, acelerar los descubrimientos y conseguir que todos los barcos se hagan a la mar”…”la disposición cada vez más favorable a compartir de innumerables individuos y organizaciones está dando lugar a la formación de nuevas y potentes economías del uso compartido.”

“… Lo que las empresas pueden elegir actualmente no es si implicarse y colaborar con las comunidades de producción entre iguales o no, sino cuándo y cómo hacerlo…”

En este punto, se destaca al final del libro que “Compartir sólo tiene sentido si se dan las condiciones correctas para ello”, y se enumera unas cuantas reglas generales y ejemplos, extraídos de capítulos anteriores:

  • Si su oferta de productos de carácter “propietario” está fracasando y el hecho de abrir su código fuente podría inyectarle la creatividad y el personal necesarios para que tenga éxito en el mercado (véase iniciativa OpenSPARC de Sun).
  • Si abriendo sus derechos de propiedad intelectual en uno de los ámbitos de su negocio puede potenciar la demanda de ofertas complementarias de productos y servicios (véase el producto WebSphere de IBM).
  • Si las ventajas de compartir competencias en un fondo común y de reducir costes de I+D sobrepasan a los beneficios de quedarse con los derechos exclusivos sobre el conocimiento producido (véase consorcio SNP)
  • Si está buscando una mente excepcionalmente cualificada para aumentar el depósito de talento del que dispone para abordar un problema concreto (véase Goldcorp)
  • Si con un plataforma abierta favorecerá la innovación, la eficiencia y la interoperabilidad con los socios de su ecosistema (véase Amazon).
  • Si compartir es necesario para establecer unas credenciales y para desarrollar relaciones con otros contribuidores de la comunidad (véase SpikeSource).
  • Si impidiendo que sus competidores puedan reclamar derechos de propiedad sobre algo que ya es compartido consigue desplazar el momento y el escenario de la competencia o mejorar su libertad de actuación (véase el Índice Genético de Merck).
  • Si con la apertura eliminará fricciones innecesarias en los proyectos colaborativos y allanará el camino para que los participantes se concentren en la ciencia en sí (véase el acuerdo universidad-empresa de Intel)

* Actuación a escala global: “…La nueva globalización es causante de y, al mismo tiempo, está causada por cambios en la colaboración y en la manera que tienen las empresas de organizar la capacidad de innovar y producir cosas. Mantener la competitividad a escala mundial implica seguir las novedades empresariales en el ámbito internacional y explotar un vivero de talentos global, mucho más amplio. La alianzas mundiales, los mercados de capital humano y las comunidades de producción entre iguales proporcionarán acceso a nuevos mercados, ideas y tecnologías. Será preciso gestionar los activos personales e intelectuales trascendiendo culturas, disciplinas y fronteras de organizaciones…”

Ya he dado de alta como categoría del blog el término WIKINOMIA, con la intuición de que postearé contenidos relacionado con este tema.

 

 

[1] Nota del libro a modo de definición de ‘wiki’: “… el software web wiki (rápido’ en hawaiano) , permite que múltiples usuarios creen y editen la misma página web. Se basa en la premisa de que la colaboración entre usuarios irá mejorando el contenido con el tiempo, igual que la comunidad de software libre fue mejorando paulatinamente la primera versión de Linux que ofreció Linus Torvalds…”

Written by jsgisdev

enero 4, 2008 at 2:34 am

Blogs sobre Dirección de proyectos en español.

leave a comment »

Hoy vuelvo de vacaciones y pensando en cómo enfocar nuevos posts para el Blog, he vuelto a tener la reflexión de que debería escribir más sobre temas de Dirección de Proyectos en general, como me había planteado inicialmente. Me encuentro precisamente que Angel Águeda ha posteado una interesante lista de Blogs de Dirección de Proyectos e Ingeniería del Software. Gracias por incluirme en la lista Angel, aunque habrá que trabajar duro para estar a la altura del resto de interesantres blogs que has incluido en esa lista ;-)…

Written by jsgisdev

agosto 21, 2007 at 8:24 pm

El lenguaje corporal en las presentaciones.

leave a comment »

body_languaje3.jpg

Leo este reciente artículo sobre el lenguaje corporal como factor clave de éxito. Muy interesante para tener conciencia en qué porcentaje entra en juego este factor de la comunicación en las presentaciones. Algo que no solemos tener en cuenta, pero que cuando damos o recibimos una conferencia, efectivamente ‘notamos’ la importancia que tiene:

 1.- A small percentage of communication involves actual words: 7%

 2.- 55% of communication is visual (body language, eye contact)

 3.- 38% is vocal (pitch, speed, volume, tone of voice).

Desarrolla también recomendaciones sobre el contacto visual, los gestos, etc. y lo más importante sobre el hecho de que todo esto se puede aprender.

En los últimos meses he tenido que hacer varias presentaciones tanto en cliente como internas. De la mayoría estoy bastante satisfecho excepto de una, no voy a especificar cuál claro, para mantener la intriga de algún lector/colega…

El caso es que todas estas recomendaciones están fenomenal para ir ‘puliendo la técnica’, pero pensando en cuáles son las recomendaciones que haría yo, considerando por qué en alguna he fallado y que hablamos de recomendaciones para ‘no’ expertos en este arte (como los que cita el artículo) , me salen las siguientes 4:

Confianza, Preparación, Preparación y Preparación

Creo que respetando esas 4 básicas, emerge la naturalidad del conferenciante, y después de encontrar tu propio estilo y llevarte bien con él, se podrá ir mejorando con esas líneas de aprendizaje que analiza el artículo y otras muchas (hay mucha bibliografía al respecto).

making_announcements.jpg

~ * ~

Written by jsgisdev

junio 16, 2007 at 10:22 pm

Gestionar conocimiento de proyecto a través de wikis. Managing Wikis on project knowledge management

with 4 comments

-SP- 

Quizá una de las cosas que empieza a ocupa gran parte del esfuerzo de planificación inicial de un proyecto es la conveniencia o no de preparar un sitio ‘wiki’ dónde los participantes puedan contribuir de forma colaborativa en el mantenimiento dinámico del conocimiento que se va acumulando durante la ejecución del mismo.

Los beneficios que puede reportar en cuanto a la eficiencia de la gestión de la información asociada a la evolución del proyecto, considerando los bajos costes de implantación y la facilidad de uso, son enormes.

Pero una vez considerada la conveniencia de iniciar uno, resulta difícil elegir cuál puede ser el más idóneo entre el enorme abanico de posibilidades disponibles ( Ver ‘List of Wiki Software‘ )

Personalmente he probado TikiWiki y Tiddlywiki. TikiWiki es uno de los que lleva más tiempo en desarrollo, un sistema de gestión de contenidos como tal, y cada vez con más módulos ( Cómo no citar que ya incorpora gestión de contenidos Geoespaciales: objetos geográficos y capacidad de renderizado de mapas. Ver OSGeo Journal – Volume 1 | Integration Studies | Tikiwiki)

Normalmente con solo algunos de los módulos básicos de TikiWiki se puede empezar a utilizar para cualquier proyecto. Con los módulos de FAQ, la simple funcionalidad de poder editar páginas, Directory (para añadir links de interés), Forums (para gestionar líneas de discusión), File Galleries (como repositorio de los principales documentos de proyecto), etc. ya se puede hacer mucho.

Para una explicación facilita de las bondades de las wikis (que cada vez son más), consultar ‘5 uses for a wiki at work‘ o el divertidísimo video de Chris Brogan ( ‘Explaining Wikis‘), es genial!!

Estoy intentando averiguar cuál de estas herramientas ‘wiki’ Open Source puede ser más apropiada para gestionar un proceso de resolución de incidencias (asignar incidencias o tareas a programadores, gestionar información asociada a las misma, consultar estado, gestionar tiempos de resolución, etc). Me encanta JIRA, que los están en proyectos como uDig, pero claro, es de pago.

¿Me recomiendas alguna?

****

-EN-

An important task that is becoming more and more demanding in first steps project planning  is implementing a ‘wiki’ site where contribute, in a collaborative and dinamic way, the information generated during project execution  time.

Benefits of using a ‘tiki’, from the efficiency of managing project-related information point of view are enormous, considering the low cost and how easy to use they are.

Once you´ve decided to use one for your project, it´s difficult to choose the most proper one for your goals, as there too many products available (Take a look at ‘List of Wiki Software‘ )

I´ve allready partially tested ‘TikiWiki’ and ‘TiddlyWiki’. Tikiwiki is one of the more developed nowdays, is a Content Managemente System, and is currently adding more and more modules ( Already!! Geospatial content management: graphic objects and maps rendering capabilities. ( Explained in  OSGeo Journal – Volume 1 | Integration Studies | Tikiwiki)

Normally whith just the basic modules of TikiWiki a lot can be done to start managing project  related content: With modules like FAQ, simply editing new pages and content, Directory (for adding web links), Forums module, File Galleries (to store and manage project documents), and so on.

An easy explanation about benefits of using wikis can be found in  ‘5 uses for a wiki at work‘ or in a funny video by Chris Brogan ( ‘Explaining Wikis‘), which is great!!

Lately, I´m trying to figure out which of this ‘wiki’ tools can be used in order to manage project requirements/bugs resolutiom (assign requirements to developers, manage evolution information, query related info, manage resolution time, etc). I love ‘JIRA‘, which is being used by uDig project, but, is not free or Open Source (as far as I know), so…

¿Would you recommend me any?

****

Written by jsgisdev

junio 9, 2007 at 8:14 pm

Arquitecturas de participación

with one comment

He tenido ‘suerte’ descubriendo el blog de cholmes ( http://cholmes.wordpress.com/ ), o mi intencionalidad consultando la Web me ha llevado a él ;-)…

He leído la mayoría de sus posts sobre temas de GIS. Me ha resultado muy interesante su post sobre ‘Arquitecturas de participación’ http://cholmes.wordpress.com/2006/01/24/architectures-of-participation-yktm/. Es un concepto acuñado desde la observación de los procesos de producción de código abierto en un intento de servir incluso para procesos que no estén ligados al software libre en sí.

Estas arquitecturas tienen dos componentes estrechamente ligadas e interdependientes: una técnica y otra social.  En su descripción hace referencia a otras fuentes que describen el término que no voy a repetir aquí. Lo que sí que voy a repetir es la enumeración del pre-requisisto y los aspectos que debe cumplir una arquitectura de participación:

PREREQUISITO

El resultado del proceso de producción deberá estar disponible para todos los contribuidores de la solución. Todos los contribuidores esperan obtener algo a cambio y seguirán contribuyendo en la medida que sigan percibiendo que obtienen más de lo que aportan; y ésto suele suceder independientemente de que otros obtengan a su vez un beneficio económico con su contribución.

ASPECTOS

  1. El trabajo se hace sobre algo que resulte ser útil y se obtenga con inmediatez.
  2. Minimizar al máximo las barreras para que emerjan nuevas contribuciones.
  3. Los usuarios se perciben como partners del producto desarrollado directamente: Este me encanta! porque supone la delegación rápida de responsabilidad a los participantes. La clave aquí según cholmes es que dando responsabilidad a aquellos que nunca la han tenido a menudo los convierte en los que trabajan más duro y con más ‘pasión’ de los participantes del proyecto.

Me parece que repasando el prerequisito y los aspectos, constituyen unas buenas prácticas en cuanto a la forma de gestionar nuestros propios proyectos, aunque se trate de equipos pequeños y no de enormes comunidades de desarrolladores, ¿no?

Lo que también es extrapolable para fomentar la colaboración en las ‘contribuciones’ de los miembros del proyecto es la utilización de herramientas de gestión de contenidos que suelen utilizar las comunidades Open Source, tipo ‘wiki’, de las que parece que cada vez hay más opciones libres a disposición. Actualmente estamos utilizando ‘Tiki-Wiki’ http://tikiwiki.org/ y estamos analizando algunas que me gustaría resumir en un próximo ‘post’, sobre todo, por si alguién quiere ‘contribuir’ al ánalisis de las más adecuadas actualmente para soportar Arquitecturas de Participación…

Written by jsgisdev

abril 24, 2007 at 12:34 pm