El grupo al cual envías entradas es un grupo Usenet. Si envías mensajes a este grupo, cualquier usuario de Internet podrá ver tu dirección de correo electrónico
Interesante tu articulo, esto me hace acordar a la practica de XP llamada "Metafora" que si bien no es muy utilizada realmente lo que busca es encontrar un mecanismo para intercambiar conocimiento de una manera en que todos los participantes lo entiendan.
Quizas el problema con la Metafora sea que es muy generica y por ende no se le ha dado la importancia debida en XP, mientras que en Scrum a traves de las reuniones es que se ha "aterrizado" un poco mas la creacion y el compartir los conocimientos.
Scrum ayuda mucho en la *generacion* del Conocimiento, pero me parece que quizás falta definir alguna practica que permita *gestionar* ese conocimiento, pues al haber reuniones hay mucho conocimiento, pero este se encuentra normalmente en la mente de los participantes.
No hablo de documentar el producto o el proceso (pues eso va dentro de la documentacion regular que debe tener todo proyecto), sino del conocimiento que se va generando en el dia a dia en cada miembro del equipo. Ese conocimiento forma parte del know-how de las personas pero que seria muy util para la empresa al quedar en un repositorio simple pero organizado donde cada quien pueda, de manera natural, compartirlo con los demas de manera tangible para que cualquier persona que lo necesite tengan acceso a esa fuente de informacion, mas aun en caso la persona que registro ese conocimiento ya no se encuentra en la empresa. Esto complementaria el factor social que tiene que existir en todo manejo del conocimiento.
Se que una Wiki ayudaria, pero habra alguna otra forma? Alguien en la comunidad realiza algo parecido en su dia a dia?
Dejo las preguntas abiertas...
Atte,
Deusdit Correa Cornejo (@neodacc) MBA Student / IT Director / Certified ScrumMaster / Agile Coach
> -- > Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de > Grupos de Google. > Si quieres publicar en este grupo, envía un mensaje de correo > electrónico a agileperu@googlegroups.com > Para anular la suscripción a este grupo, envía un mensaje a > agileperu-unsubscribe@googlegroups.com > Para obtener más opciones, visita este grupo en > http://groups.google.com.pe/group/agileperu?hl=es.
Especificamente a que tipo de conocimiento en cada miembro del equipo te refieres? conocimiento del producto que se pretende construir, conocimiento de la metodologia agile en si o conocimiento en otras áreas del proyecto (ej. reuso de software, buenas practicas, etc)?
En agile, en el primero estamos de acuerdo que se genera con el solo objetivo de lograr un producto potencialmente entregable al final de cada iteración. Va de la mano con el hecho de que la comunicación verbal entre clientes y desarrolladores es mas importante que la escrita. Esto permite la existencia de un feedback constante que da oportunidad de aprendizaje y entendimiento mutuo. Hasta alli el conocimiento está en la mente del equipo y eso está bien.
Ahora el conocimiento de la metodologia, eso ya depende del Coach que asegure que las buenas prácticas se ejecuten, alguna vez como Coach he documentado escenarios tipicos negativos que conociamos como "agile flu" para compartirlo con otros coaches en la organizacion.
Aqui un ejemplo: My testers don't always understand stories the same way as the developers Are you running cross-functional teams? i.e. Dev + test on the same team, with other dev + other test on a separate team? Are you including your testers in the 'Conversation' part of your user stories? Are you recording all acceptance criteria? Is this criteria modified if you agree something new in a Conversation?
Otros aspectos tales como project setup, riesgos, buenas practicas, componentes a reusar, etc. he visto que se evaluan al final del proyecto en PIRs ( Post Implementation Reviews) que incuyen encuestas a los miembros del equipo para recopilar metricas. Los PIRs los veras en organizaciones agile que son también CMMi por encima del nivel III
En agile finalmente lo que tienes que tomar en cuenta es el conocimiento que genera el equipo como un todo y no los individuos.
> Interesante tu articulo, esto me hace acordar a la practica de XP llamada > "Metafora" que si bien no es muy utilizada realmente lo que busca es > encontrar un mecanismo para intercambiar conocimiento de una manera en que > todos los participantes lo entiendan.
> Quizas el problema con la Metafora sea que es muy generica y por ende no se > le ha dado la importancia debida en XP, mientras que en Scrum a traves de > las reuniones es que se ha "aterrizado" un poco mas la creacion y el > compartir los conocimientos.
> Scrum ayuda mucho en la *generacion* del Conocimiento, pero me parece > que quizás falta definir alguna practica que permita *gestionar* ese > conocimiento, pues al haber reuniones hay mucho conocimiento, pero este se > encuentra normalmente en la mente de los participantes.
> No hablo de documentar el producto o el proceso (pues eso va dentro de la > documentacion regular que debe tener todo proyecto), sino del conocimiento > que se va generando en el dia a dia en cada miembro del equipo. Ese > conocimiento forma parte del know-how de las personas pero que seria muy > util para la empresa al quedar en un repositorio simple pero organizado > donde cada quien pueda, de manera natural, compartirlo con los demas de > manera tangible para que cualquier persona que lo necesite tengan acceso a > esa fuente de informacion, mas aun en caso la persona que registro ese > conocimiento ya no se encuentra en la empresa. Esto complementaria el factor > social que tiene que existir en todo manejo del conocimiento.
> Se que una Wiki ayudaria, pero habra alguna otra forma? Alguien en la > comunidad realiza algo parecido en su dia a dia?
> Dejo las preguntas abiertas...
> Atte,
> Deusdit Correa Cornejo (@neodacc) > MBA Student / IT Director / Certified ScrumMaster / Agile Coach
>> -- >> Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de >> Grupos de Google. >> Si quieres publicar en este grupo, envía un mensaje de correo >> electrónico a agileperu@googlegroups.com >> Para anular la suscripción a este grupo, envía un mensaje a >> agileperu-unsubscribe@googlegroups.com >> Para obtener más opciones, visita este grupo en >> http://groups.google.com.pe/group/agileperu?hl=es.
> -- > Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de > Grupos de Google. > Si quieres publicar en este grupo, envía un mensaje de correo > electrónico a agileperu@googlegroups.com > Para anular la suscripción a este grupo, envía un mensaje a > agileperu-unsubscribe@googlegroups.com > Para obtener más opciones, visita este grupo en > http://groups.google.com.pe/group/agileperu?hl=es.
De repente me estoy saliendo un poco del tema de la lista (las disculpas del caso para quienes corresponda), actualmente estoy empezando un nuevo proyecto de mejora en la empresa donde estoy y es sobre gestión del conocimiento, de lo que he visto hasta ahora y de lo actualmente tenemos implementado en donde laboro te puedo contar que estamos implementando un Blog para temas novedosos o de investigación, además de un wiki donde guardamos instructivos, bitácoras de lo que hacemos, lecciones aprendidas y buenas prácticas, y utilizamos micro-blogging con un Twitter corporativo llamado yammer (http://www.yammer.com) para lo del día a día y generar discusiones (a partir de reuniones o de lo que investigamos o descubrimos a diario), esta herramienta es muy ágil ya que si tenemos un Twitter podemos postear desde ahí, usa hashtags y reconoce usuarios para incluirlos en el mensaje (el cual es de más de 150 caracteres), yo te aconsejaría usar no sólo una herramienta sino varias para generar communities of practice.
Te envió algunas referencias al respecto y una captura de cómo es nuestro yammer J por si te animas a usarlo.
De: agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] En nombre de Manuel Mazan Enviado el: Lunes, 01 de Febrero de 2010 03:00 p.m. Para: agileperu@googlegroups.com Asunto: Re: [agileperu] La creacion de conocimiento en Scrum
Hola Deusdit
Especificamente a que tipo de conocimiento en cada miembro del equipo te refieres? conocimiento del producto que se pretende construir, conocimiento de la metodologia agile en si o conocimiento en otras áreas del proyecto (ej. reuso de software, buenas practicas, etc)?
En agile, en el primero estamos de acuerdo que se genera con el solo objetivo de lograr un producto potencialmente entregable al final de cada iteración. Va de la mano con el hecho de que la comunicación verbal entre clientes y desarrolladores es mas importante que la escrita. Esto permite la existencia de un feedback constante que da oportunidad de aprendizaje y entendimiento mutuo. Hasta alli el conocimiento está en la mente del equipo y eso está bien.
Ahora el conocimiento de la metodologia, eso ya depende del Coach que asegure que las buenas prácticas se ejecuten, alguna vez como Coach he documentado escenarios tipicos negativos que conociamos como "agile flu" para compartirlo con otros coaches en la organizacion.
Aqui un ejemplo:
My testers don't always understand stories the same way as the developers Are you running cross-functional teams? i.e. Dev + test on the same team, with other dev + other test on a separate team? Are you including your testers in the 'Conversation' part of your user stories? Are you recording all acceptance criteria? Is this criteria modified if you agree something new in a Conversation?
Otros aspectos tales como project setup, riesgos, buenas practicas, componentes a reusar, etc. he visto que se evaluan al final del proyecto en PIRs ( Post Implementation Reviews) que incuyen encuestas a los miembros del equipo para recopilar metricas. Los PIRs los veras en organizaciones agile que son también CMMi por encima del nivel III
En agile finalmente lo que tienes que tomar en cuenta es el conocimiento que genera el equipo como un todo y no los individuos.
Interesante tu articulo, esto me hace acordar a la practica de XP llamada "Metafora" que si bien no es muy utilizada realmente lo que busca es encontrar un mecanismo para intercambiar conocimiento de una manera en que todos los participantes lo entiendan.
Quizas el problema con la Metafora sea que es muy generica y por ende no se le ha dado la importancia debida en XP, mientras que en Scrum a traves de las reuniones es que se ha "aterrizado" un poco mas la creacion y el compartir los conocimientos.
Scrum ayuda mucho en la generacion del Conocimiento, pero me parece que quizás falta definir alguna practica que permita gestionar ese conocimiento, pues al haber reuniones hay mucho conocimiento, pero este se encuentra normalmente en la mente de los participantes.
No hablo de documentar el producto o el proceso (pues eso va dentro de la documentacion regular que debe tener todo proyecto), sino del conocimiento que se va generando en el dia a dia en cada miembro del equipo. Ese conocimiento forma parte del know-how de las personas pero que seria muy util para la empresa al quedar en un repositorio simple pero organizado donde cada quien pueda, de manera natural, compartirlo con los demas de manera tangible para que cualquier persona que lo necesite tengan acceso a esa fuente de informacion, mas aun en caso la persona que registro ese conocimiento ya no se encuentra en la empresa. Esto complementaria el factor social que tiene que existir en todo manejo del conocimiento.
Se que una Wiki ayudaria, pero habra alguna otra forma? Alguien en la comunidad realiza algo parecido en su dia a dia?
Dejo las preguntas abiertas...
Atte,
Deusdit Correa Cornejo (@neodacc) MBA Student / IT Director / Certified ScrumMaster / Agile Coach
-- Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a agileperu@googlegroups.com Para anular la suscripción a este grupo, envía un mensaje a agileperu-unsubscribe@googlegroups.com Para obtener más opciones, visita este grupo en http://groups.google.com.pe/group/agileperu?hl=es.
-- Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a agileperu@googlegroups.com Para anular la suscripción a este grupo, envía un mensaje a agileperu-unsubscribe@googlegroups.com Para obtener más opciones, visita este grupo en http://groups.google.com.pe/group/agileperu?hl=es.
-- Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a agileperu@googlegroups.com Para anular la suscripción a este grupo, envía un mensaje a agileperu-unsubscribe@googlegroups.com Para obtener más opciones, visita este grupo en http://groups.google.com.pe/group/agileperu?hl=es. -- Este mensaje ha sido analizado por <http://www.mailscanner.info/> MailScanner en busca de virus y otros contenidos peligrosos, y se considera que está limpio.
__________ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 4824 (20100201) __________
Hola Manuel, gracias por los comentarios, yo estoy completamente de acuerdo que en Agile se promueve el conocimiento de todo el equipo pero eso no es excluyente con la gestion del conocimiento.
El conocimiento claro que puede ser tipificado, como el del producto (que normalmente debe tener documentacion (user stories, use cases, etc.)), de la metodologia (de acuerdo una vez mas, el Coach es el que debe ayudar a la gente a entenderla y asimilarla). Pero el hecho de tener un equipo multi-funcional permite que se genere otro tipo de conocimiento entre todos los miembros (cada uno aprende del otro) y ese conocimiento deberia ser tambien ser gestionado (en la fase de Combinacion segun el modelo de SECI).
Acerca de que las reuniones post implementacion ayuden a gestionar el conocimiento dependera del proposito de la reunion, normalmente en Scrum los Retrospective Meeting (que es un tipo de PRI) estan mas orientados a mejorar el el proceso utilizado durante el ultimo sprint (por eso tienen una duracion corta). Esto implicaria que se si lo que se busca es tener una reunion donde se mejore el conocimiento, por ejemplo de las buenas practicas, entonces se tendria que tener una reunion mas larga o programar otra reunion... y justamente por alli iba mi pregunta, cual seria una forma adecuada para poder mejorar la gestion del conocimiento.
Eddy envio links interesantes sobre herramientas y presentaciones que ayudarían en este propósito (gracias Eddy), y estoy de acuerdo en el beneficio de las herramientas excepto aquellas que se usan para comunicar cosas que podria ser comunicadas de manera mas personal (las herramientas como twitter son perfectas en caso el equipo no esta co-locado). Una vez que se tiene esto, hay que generar "audiencia" para ese conocimiento que alguien se dio el trabajo de compartir de manera escrita (en un blog, wiki, etc.), sino se terminan aburriendo y nadie comparte nada (aqui hay un tema de feedback positivo que se debe promover).
Bueno voy a seguir investigando este tema porque parece ser muy interesante, pero el tema sigue abierto para quien quiera compartir algo mas.
Atte,
Deusdit Correa Cornejo (@neodacc) MBA Student / IT Director / Certified ScrumMaster / Agile Coach
> De repente me estoy saliendo un poco del tema de la lista (las disculpas > del caso para quienes corresponda), actualmente estoy empezando un nuevo > proyecto de mejora en la empresa donde estoy y es sobre gestión del > conocimiento, de lo que he visto hasta ahora y de lo actualmente tenemos > implementado en donde laboro te puedo contar que estamos implementando un > Blog para temas novedosos o de investigación, además de un wiki donde > guardamos instructivos, bitácoras de lo que hacemos, lecciones aprendidas y > buenas prácticas, y utilizamos micro-blogging con un Twitter corporativo > llamado yammer (http://www.yammer.com) para lo del día a día y generar > discusiones (a partir de reuniones o de lo que investigamos o descubrimos a > diario), esta herramienta es muy ágil ya que si tenemos un Twitter podemos > postear desde ahí, usa hashtags y reconoce usuarios para incluirlos en el > mensaje (el cual es de más de 150 caracteres), yo te aconsejaría usar no > sólo una herramienta sino varias para generar communities of practice.
> Te envió algunas referencias al respecto y una captura de cómo es nuestro > yammer J por si te animas a usarlo.
> *De:* agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] *En > nombre de *Manuel Mazan > *Enviado el:* Lunes, 01 de Febrero de 2010 03:00 p.m. > *Para:* agileperu@googlegroups.com > *Asunto:* Re: [agileperu] La creacion de conocimiento en Scrum
> Hola Deusdit
> Especificamente a que tipo de conocimiento en cada miembro del equipo te > refieres? conocimiento del producto que se pretende construir, conocimiento > de la metodologia agile en si o conocimiento en otras áreas del proyecto > (ej. reuso de software, buenas practicas, etc)?
> En agile, en el primero estamos de acuerdo que se genera con el solo > objetivo de lograr un producto potencialmente entregable al final de cada > iteración. Va de la mano con el hecho de que la comunicación verbal entre > clientes y desarrolladores es mas importante que la escrita. Esto permite la > existencia de un feedback constante que da oportunidad de aprendizaje y > entendimiento mutuo. Hasta alli el conocimiento está en la mente del > equipo y eso está bien.
> Ahora el conocimiento de la metodologia, eso ya depende del Coach que > asegure que las buenas prácticas se ejecuten, alguna vez como Coach he > documentado escenarios tipicos negativos que conociamos como "agile flu" > para compartirlo con otros coaches en la organizacion.
> Aqui un ejemplo:
> My testers don't always understand stories the same way as the developers > Are you running cross-functional teams? i.e. Dev + test on the same team, > with other dev + other test on a separate team? Are you including your > testers in the 'Conversation' part of your user stories? Are you > recording all acceptance criteria? Is this criteria modified if you agree > something new in a Conversation?
> Otros aspectos tales como project setup, riesgos, buenas practicas, > componentes a reusar, etc. he visto que se evaluan al final del proyecto en > PIRs ( Post Implementation Reviews) que incuyen encuestas a los miembros del > equipo para recopilar metricas. Los PIRs los veras en organizaciones agile > que son también CMMi por encima del nivel III
> En agile finalmente lo que tienes que tomar en cuenta es el conocimiento > que genera el equipo como un todo y no los individuos.
> Interesante tu articulo, esto me hace acordar a la practica de XP llamada > "Metafora" que si bien no es muy utilizada realmente lo que busca es > encontrar un mecanismo para intercambiar conocimiento de una manera en que > todos los participantes lo entiendan.
> Quizas el problema con la Metafora sea que es muy generica y por ende no se > le ha dado la importancia debida en XP, mientras que en Scrum a traves de > las reuniones es que se ha "aterrizado" un poco mas la creacion y el > compartir los conocimientos.
> Scrum ayuda mucho en la *generacion* del Conocimiento, pero me parece > que quizás falta definir alguna practica que permita *gestionar* ese > conocimiento, pues al haber reuniones hay mucho conocimiento, pero este se > encuentra normalmente en la mente de los participantes.
> No hablo de documentar el producto o el proceso (pues eso va dentro de la > documentacion regular que debe tener todo proyecto), sino del conocimiento > que se va generando en el dia a dia en cada miembro del equipo. Ese > conocimiento forma parte del know-how de las personas pero que seria muy > util para la empresa al quedar en un repositorio simple pero organizado > donde cada quien pueda, de manera natural, compartirlo con los demas de > manera tangible para que cualquier persona que lo necesite tengan acceso a > esa fuente de informacion, mas aun en caso la persona que registro ese > conocimiento ya no se encuentra en la empresa. Esto complementaria el factor > social que tiene que existir en todo manejo del conocimiento.
> Se que una Wiki ayudaria, pero habra alguna otra forma? Alguien en la > comunidad realiza algo parecido en su dia a dia?
> Dejo las preguntas abiertas...
> Atte,
> Deusdit Correa Cornejo (@neodacc) > MBA Student / IT Director / Certified ScrumMaster / Agile Coach
> -- > Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de > Grupos de Google. > Si quieres publicar en este grupo, envía un mensaje de correo > electrónico a agileperu@googlegroups.com > Para anular la suscripción a este grupo, envía un mensaje a > agileperu-unsubscribe@googlegroups.com > Para obtener más opciones, visita este grupo en > http://groups.google.com.pe/group/agileperu?hl=es.
> -- > Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de > Grupos de Google. > Si quieres publicar en este grupo, envía un mensaje de correo > electrónico a agileperu@googlegroups.com > Para anular la suscripción a este grupo, envía un mensaje a > agileperu-unsubscribe@googlegroups.com > Para obtener más opciones, visita este grupo en > http://groups.google.com.pe/group/agileperu?hl=es.
> -- > Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de > Grupos de Google. > Si quieres publicar en este grupo, envía un mensaje de correo > electrónico a agileperu@googlegroups.com > Para anular la suscripción a este grupo, envía un mensaje a > agileperu-unsubscribe@googlegroups.com > Para obtener más opciones, visita este grupo en > http://groups.google.com.pe/group/agileperu?hl=es. > -- > Este mensaje ha sido analizado por
Los sistemas de Gestion del Conocimiento tienen dos orientaciones principalmente, aquellos que te permiten compartir (portales dinamicos, gestors de contenidos, etc) y aquellos que te permiten generar conocimiento basado en reglas previamente establecidas (en base a una maquina de inferencia que emula el razonamiento humano).
El año pasado inicie con este tema en un primer proyecto para Gestionar Conocimiento relacionado a la gobernabilidad de codigo fuente para un banco italiano y la segunda mitad del año para una financiera peruana con un motor de dinamicas contables.
Te podria comentar que para aprovechar verdaderamente un Sistema de Gestion de Conocimiento no basta con crear un repositorio de informacion y los buscadores especializados anexos, es importante construir reglas que mantengan esta informacion relacionada. Estas relaciones las conoce un experto en el tema que se esta explotando y el Ingeniero de Conocimiento es el encargado de modelar la *experiencia* en *conocimiento explicito. *
Actualmente estamos desarrollando la segunda fase del proyecto para la financiera. En caso haya interes para alguna consultoria no dudes en contactarme.
Saludos,
*Randiel J. Melgarejo Díaz* *Gerente General**BlackPrince Consulting* ------------------------------
> Hola Manuel, gracias por los comentarios, yo estoy completamente de acuerdo > que en Agile se promueve el conocimiento de todo el equipo pero eso no es > excluyente con la gestion del conocimiento.
> El conocimiento claro que puede ser tipificado, como el del producto (que > normalmente debe tener documentacion (user stories, use cases, etc.)), de la > metodologia (de acuerdo una vez mas, el Coach es el que debe ayudar a la > gente a entenderla y asimilarla). Pero el hecho de tener un equipo > multi-funcional permite que se genere otro tipo de conocimiento entre todos > los miembros (cada uno aprende del otro) y ese conocimiento deberia ser > tambien ser gestionado (en la fase de Combinacion segun el modelo de SECI).
> Acerca de que las reuniones post implementacion ayuden a gestionar el > conocimiento dependera del proposito de la reunion, normalmente en Scrum los > Retrospective Meeting (que es un tipo de PRI) estan mas orientados a mejorar > el el proceso utilizado durante el ultimo sprint (por eso tienen una > duracion corta). Esto implicaria que se si lo que se busca es tener una > reunion donde se mejore el conocimiento, por ejemplo de las buenas > practicas, entonces se tendria que tener una reunion mas larga o programar > otra reunion... y justamente por alli iba mi pregunta, cual seria una forma > adecuada para poder mejorar la gestion del conocimiento.
> Eddy envio links interesantes sobre herramientas y presentaciones > que ayudarían en este propósito (gracias Eddy), y estoy de acuerdo en el > beneficio de las herramientas excepto aquellas que se usan para comunicar > cosas que podria ser comunicadas de manera mas personal (las herramientas > como twitter son perfectas en caso el equipo no esta co-locado). Una vez que > se tiene esto, hay que generar "audiencia" para ese conocimiento que alguien > se dio el trabajo de compartir de manera escrita (en un blog, wiki, etc.), > sino se terminan aburriendo y nadie comparte nada (aqui hay un tema de > feedback positivo que se debe promover).
> Bueno voy a seguir investigando este tema porque parece ser muy > interesante, pero el tema sigue abierto para quien quiera compartir algo > mas.
> Atte,
> Deusdit Correa Cornejo (@neodacc) > MBA Student / IT Director / Certified ScrumMaster / Agile Coach
>> De repente me estoy saliendo un poco del tema de la lista (las disculpas >> del caso para quienes corresponda), actualmente estoy empezando un nuevo >> proyecto de mejora en la empresa donde estoy y es sobre gestión del >> conocimiento, de lo que he visto hasta ahora y de lo actualmente tenemos >> implementado en donde laboro te puedo contar que estamos implementando un >> Blog para temas novedosos o de investigación, además de un wiki donde >> guardamos instructivos, bitácoras de lo que hacemos, lecciones aprendidas y >> buenas prácticas, y utilizamos micro-blogging con un Twitter corporativo >> llamado yammer (http://www.yammer.com) para lo del día a día y generar >> discusiones (a partir de reuniones o de lo que investigamos o descubrimos a >> diario), esta herramienta es muy ágil ya que si tenemos un Twitter podemos >> postear desde ahí, usa hashtags y reconoce usuarios para incluirlos en el >> mensaje (el cual es de más de 150 caracteres), yo te aconsejaría usar no >> sólo una herramienta sino varias para generar communities of practice.
>> Te envió algunas referencias al respecto y una captura de cómo es nuestro >> yammer J por si te animas a usarlo.
>> *De:* agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] *En >> nombre de *Manuel Mazan >> *Enviado el:* Lunes, 01 de Febrero de 2010 03:00 p.m. >> *Para:* agileperu@googlegroups.com >> *Asunto:* Re: [agileperu] La creacion de conocimiento en Scrum
>> Hola Deusdit
>> Especificamente a que tipo de conocimiento en cada miembro del equipo te >> refieres? conocimiento del producto que se pretende construir, conocimiento >> de la metodologia agile en si o conocimiento en otras áreas del proyecto >> (ej. reuso de software, buenas practicas, etc)?
>> En agile, en el primero estamos de acuerdo que se genera con el solo >> objetivo de lograr un producto potencialmente entregable al final de cada >> iteración. Va de la mano con el hecho de que la comunicación verbal entre >> clientes y desarrolladores es mas importante que la escrita. Esto permite la >> existencia de un feedback constante que da oportunidad de aprendizaje y >> entendimiento mutuo. Hasta alli el conocimiento está en la mente del >> equipo y eso está bien.
>> Ahora el conocimiento de la metodologia, eso ya depende del Coach que >> asegure que las buenas prácticas se ejecuten, alguna vez como Coach he >> documentado escenarios tipicos negativos que conociamos como "agile flu" >> para compartirlo con otros coaches en la organizacion.
>> Aqui un ejemplo:
>> My testers don't always understand stories the same way as the developers >> Are you running cross-functional teams? i.e. Dev + test on the same team, >> with other dev + other test on a separate team? Are you including your >> testers in the 'Conversation' part of your user stories? Are you >> recording all acceptance criteria? Is this criteria modified if you agree >> something new in a Conversation?
>> Otros aspectos tales como project setup, riesgos, buenas practicas, >> componentes a reusar, etc. he visto que se evaluan al final del proyecto en >> PIRs ( Post Implementation Reviews) que incuyen encuestas a los miembros del >> equipo para recopilar metricas. Los PIRs los veras en organizaciones agile >> que son también CMMi por encima del nivel III
>> En agile finalmente lo que tienes que tomar en cuenta es el conocimiento >> que genera el equipo como un todo y no los individuos.
>> Interesante tu articulo, esto me hace acordar a la practica de XP llamada >> "Metafora" que si bien no es muy utilizada realmente lo que busca es >> encontrar un mecanismo para intercambiar conocimiento de una manera en que >> todos los participantes lo entiendan.
>> Quizas el problema con la Metafora sea que es muy generica y por ende no >> se le ha dado la importancia debida en XP, mientras que en Scrum a traves de >> las reuniones es que se ha "aterrizado" un poco mas la creacion y el >> compartir los conocimientos.
>> Scrum ayuda mucho en la *generacion* del Conocimiento, pero me parece >> que quizás falta definir alguna practica que permita *gestionar* ese >> conocimiento, pues al haber reuniones hay mucho conocimiento, pero este se >> encuentra normalmente en la mente de los participantes.
>> No hablo de documentar el producto o el proceso (pues eso va dentro de la >> documentacion regular que debe tener todo proyecto), sino del conocimiento >> que se va generando en el dia a dia en cada miembro del equipo. Ese >> conocimiento forma parte del know-how de las personas pero que seria muy >> util para la empresa al quedar en un repositorio simple pero organizado >> donde cada quien pueda, de manera natural, compartirlo con los demas de >> manera tangible para que cualquier persona que lo necesite tengan acceso a >> esa fuente de informacion, mas aun en caso la persona que registro ese >> conocimiento ya no se encuentra en la empresa. Esto complementaria el factor >> social que tiene que existir en todo manejo del conocimiento.
>> Se que una Wiki ayudaria, pero habra alguna otra forma? Alguien en la >> comunidad realiza algo parecido en su dia a dia?
> Los sistemas de Gestion del Conocimiento tienen dos orientaciones > principalmente, aquellos que te permiten compartir (portales dinamicos, > gestors de contenidos, etc) y aquellos que te permiten generar conocimiento > basado en reglas previamente establecidas (en base a una maquina de > inferencia que emula el razonamiento humano).
> El año pasado inicie con este tema en un primer proyecto para Gestionar > Conocimiento relacionado a la gobernabilidad de codigo fuente para un banco > italiano y la segunda mitad del año para una financiera peruana con un motor > de dinamicas contables.
> Te podria comentar que para aprovechar verdaderamente un Sistema de Gestion > de Conocimiento no basta con crear un repositorio de informacion y los > buscadores especializados anexos, es importante construir reglas que > mantengan esta informacion relacionada. Estas relaciones las conoce un > experto en el tema que se esta explotando y el Ingeniero de Conocimiento es > el encargado de modelar la *experiencia* en *conocimiento explicito. *
> Actualmente estamos desarrollando la segunda fase del proyecto para la > financiera. En caso haya interes para alguna consultoria no dudes en > contactarme.
> El 2 de febrero de 2010 14:52, Deusdit Correa Cornejo <neod...@gmail.com>escribió:
> Hola Manuel, gracias por los comentarios, yo estoy completamente de acuerdo >> que en Agile se promueve el conocimiento de todo el equipo pero eso no es >> excluyente con la gestion del conocimiento.
>> El conocimiento claro que puede ser tipificado, como el del producto (que >> normalmente debe tener documentacion (user stories, use cases, etc.)), de la >> metodologia (de acuerdo una vez mas, el Coach es el que debe ayudar a la >> gente a entenderla y asimilarla). Pero el hecho de tener un equipo >> multi-funcional permite que se genere otro tipo de conocimiento entre todos >> los miembros (cada uno aprende del otro) y ese conocimiento deberia ser >> tambien ser gestionado (en la fase de Combinacion segun el modelo de SECI).
>> Acerca de que las reuniones post implementacion ayuden a gestionar el >> conocimiento dependera del proposito de la reunion, normalmente en Scrum los >> Retrospective Meeting (que es un tipo de PRI) estan mas orientados a mejorar >> el el proceso utilizado durante el ultimo sprint (por eso tienen una >> duracion corta). Esto implicaria que se si lo que se busca es tener una >> reunion donde se mejore el conocimiento, por ejemplo de las buenas >> practicas, entonces se tendria que tener una reunion mas larga o programar >> otra reunion... y justamente por alli iba mi pregunta, cual seria una forma >> adecuada para poder mejorar la gestion del conocimiento.
>> Eddy envio links interesantes sobre herramientas y presentaciones >> que ayudarían en este propósito (gracias Eddy), y estoy de acuerdo en el >> beneficio de las herramientas excepto aquellas que se usan para comunicar >> cosas que podria ser comunicadas de manera mas personal (las herramientas >> como twitter son perfectas en caso el equipo no esta co-locado). Una vez que >> se tiene esto, hay que generar "audiencia" para ese conocimiento que alguien >> se dio el trabajo de compartir de manera escrita (en un blog, wiki, etc.), >> sino se terminan aburriendo y nadie comparte nada (aqui hay un tema de >> feedback positivo que se debe promover).
>> Bueno voy a seguir investigando este tema porque parece ser muy >> interesante, pero el tema sigue abierto para quien quiera compartir algo >> mas.
>> Atte,
>> Deusdit Correa Cornejo (@neodacc) >> MBA Student / IT Director / Certified ScrumMaster / Agile Coach
>>> De repente me estoy saliendo un poco del tema de la lista (las disculpas >>> del caso para quienes corresponda), actualmente estoy empezando un nuevo >>> proyecto de mejora en la empresa donde estoy y es sobre gestión del >>> conocimiento, de lo que he visto hasta ahora y de lo actualmente tenemos >>> implementado en donde laboro te puedo contar que estamos implementando un >>> Blog para temas novedosos o de investigación, además de un wiki donde >>> guardamos instructivos, bitácoras de lo que hacemos, lecciones aprendidas y >>> buenas prácticas, y utilizamos micro-blogging con un Twitter corporativo >>> llamado yammer (http://www.yammer.com) para lo del día a día y generar >>> discusiones (a partir de reuniones o de lo que investigamos o descubrimos a >>> diario), esta herramienta es muy ágil ya que si tenemos un Twitter podemos >>> postear desde ahí, usa hashtags y reconoce usuarios para incluirlos en el >>> mensaje (el cual es de más de 150 caracteres), yo te aconsejaría usar no >>> sólo una herramienta sino varias para generar communities of practice.
>>> Te envió algunas referencias al respecto y una captura de cómo es nuestro >>> yammer J por si te animas a usarlo.
>>> *De:* agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] *En >>> nombre de *Manuel Mazan >>> *Enviado el:* Lunes, 01 de Febrero de 2010 03:00 p.m. >>> *Para:* agileperu@googlegroups.com >>> *Asunto:* Re: [agileperu] La creacion de conocimiento en Scrum
>>> Hola Deusdit
>>> Especificamente a que tipo de conocimiento en cada miembro del equipo te >>> refieres? conocimiento del producto que se pretende construir, conocimiento >>> de la metodologia agile en si o conocimiento en otras áreas del proyecto >>> (ej. reuso de software, buenas practicas, etc)?
>>> En agile, en el primero estamos de acuerdo que se genera con el solo >>> objetivo de lograr un producto potencialmente entregable al final de cada >>> iteración. Va de la mano con el hecho de que la comunicación verbal >>> entre clientes y desarrolladores es mas importante que la escrita. Esto >>> permite la existencia de un feedback constante que da oportunidad de >>> aprendizaje y entendimiento mutuo. Hasta alli el conocimiento está en >>> la mente del equipo y eso está bien.
>>> Ahora el conocimiento de la metodologia, eso ya depende del Coach que >>> asegure que las buenas prácticas se ejecuten, alguna vez como Coach he >>> documentado escenarios tipicos negativos que conociamos como "agile flu" >>> para compartirlo con otros coaches en la organizacion.
>>> Aqui un ejemplo:
>>> My testers don't always understand stories the same way as the developers >>> Are you running cross-functional teams? i.e. Dev + test on the same team, >>> with other dev + other test on a separate team? Are you including your >>> testers in the 'Conversation' part of your user stories? Are you >>> recording all acceptance criteria? Is this criteria modified if you agree >>> something new in a Conversation?
>>> Otros aspectos tales como project setup, riesgos, buenas practicas, >>> componentes a reusar, etc. he visto que se evaluan al final del proyecto en >>> PIRs ( Post Implementation Reviews) que incuyen encuestas a los miembros del >>> equipo para recopilar metricas. Los PIRs los veras en organizaciones agile >>> que son también CMMi por encima del nivel III
>>> En agile finalmente lo que tienes que tomar en cuenta es el conocimiento >>> que genera el equipo como un todo y no los individuos.
>>> Interesante tu articulo, esto me hace acordar a la practica de XP llamada >>> "Metafora" que si bien no es muy utilizada realmente lo que busca es >>> encontrar un mecanismo para intercambiar conocimiento de una manera en que >>> todos los participantes lo entiendan.
>>> Quizas el problema con la Metafora sea que es muy generica y por ende no >>> se le ha dado la importancia debida en XP, mientras que en Scrum a traves de >>> las reuniones es que se ha "aterrizado" un poco mas la creacion y el >>> compartir los conocimientos.
>>> Scrum ayuda mucho en la *generacion* del Conocimiento, pero me parece >>> que quizás falta definir alguna practica que permita *gestionar* ese >>> conocimiento, pues al haber reuniones hay mucho conocimiento, pero este se >>> encuentra normalmente en la mente de los participantes.
>>> No hablo de documentar el producto o el proceso (pues eso va dentro de la >>> documentacion regular que debe tener todo proyecto), sino del conocimiento >>> que se va generando en el dia a dia en cada miembro del equipo. Ese >>> conocimiento forma parte del know-how de las personas pero que seria muy >>> util para la empresa al quedar en un repositorio simple pero organizado >>> donde cada quien pueda, de manera natural, compartirlo
> Hola Heitor, > Interesante tu articulo, esto me hace acordar a la practica de XP llamada > "Metafora" que si bien no es muy utilizada realmente lo que busca es > encontrar un mecanismo para intercambiar conocimiento de una manera en que > todos los participantes lo entiendan.
El interes es crear el BA necesario para compartir y generar conocimiento, no importa como la escrita de funcionalidads.
> Quizas el problema con la Metafora sea que es muy generica y por ende no se > le ha dado la importancia debida en XP, mientras que en Scrum a traves de > las reuniones es que se ha "aterrizado" un poco mas la creacion y el > compartir los conocimientos.
Las metaforas tienen un poder muy grande. Si bien utilizado el concepto tenes una herramienta de se va facilitar la creacion y compartir del conocimiento, por hacer que las personas involucradas tengan una tendencia a expresarsen mas facilmente.
> Scrum ayuda mucho en la generacion del Conocimiento, pero me parece > que quizás falta definir alguna practica que permita gestionar ese > conocimiento, pues al haber reuniones hay mucho conocimiento, pero este se > encuentra normalmente en la mente de los participantes.
La gestion esta con el equipo. Self-managed teams son premisas de Scrum Teams. Para alcanzar las metas de un proyecto o sprint no es necesario tener lo conocimiento explicitado. Pero si hablamo solo de KM (Knowledge Management) entonces tenemos un problema.
> No hablo de documentar el producto o el proceso (pues eso va dentro de la > documentacion regular que debe tener todo proyecto), sino del conocimiento > que se va generando en el dia a dia en cada miembro del equipo. Ese > conocimiento forma parte del know-how de las personas pero que seria muy > util para la empresa al quedar en un repositorio simple pero organizado > donde cada quien pueda, de manera natural, compartirlo con los demas de > manera tangible para que cualquier persona que lo necesite tengan acceso a > esa fuente de informacion, mas aun en caso la persona que registro ese
Una pregunta: porque esto es util y importante para una empresa?
> conocimiento ya no se encuentra en la empresa. Esto complementaria el factor > social que tiene que existir en todo manejo del conocimiento. > Se que una Wiki ayudaria, pero habra alguna otra forma? Alguien en la > comunidad realiza algo parecido en su dia a dia?
He trabajado con wikis y la utilizacion continua destos es algo muy dependiente del equipo. Hay que tener maturidad para usarlos. Conozco equipo de investigacion que trabajan hasta con reconocimiento de voz, pero tenemos que trabajar mucho aunque para alcanzar el objetivo mayor de KM en Agile.
> Dejo las preguntas abiertas... > Atte, > Deusdit Correa Cornejo (@neodacc) > MBA Student / IT Director / Certified ScrumMaster / Agile Coach
>> -- >> Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de >> Grupos de Google. >> Si quieres publicar en este grupo, envía un mensaje de correo >> electrónico a agileperu@googlegroups.com >> Para anular la suscripción a este grupo, envía un mensaje a >> agileperu-unsubscribe@googlegroups.com >> Para obtener más opciones, visita este grupo en >> http://groups.google.com.pe/group/agileperu?hl=es.
> -- > Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de > Grupos de Google. > Si quieres publicar en este grupo, envía un mensaje de correo > electrónico a agileperu@googlegroups.com > Para anular la suscripción a este grupo, envía un mensaje a > agileperu-unsubscribe@googlegroups.com > Para obtener más opciones, visita este grupo en > http://groups.google.com.pe/group/agileperu?hl=es.
Para serles sincero, luego de leer y releer sobre este tema, con esas ganas iniciales que tenía de realmente llegar a "gestionar el conocimiento" cuando supe de la existencia de este tema...he llegado a la conclusión que realmente "gestionamos" conocimiento?
Al final, en casi todo lo que he visto, se trata de (como bien dice Eddy)
1.Crear un repositorio con información coherentemente relacionada que permita la explotación y la recuperación de "conocimiento" (no es información?) de este repositorio. Y para esto nos valemos de herramientas colaborativas basadas generalmente en portales web, etc, etc.
2. Generar vías, dinámicas, reglas, políticas que ayuden a la "generación" de conocimiento en base a la experiencia de un equipo o una empresa, y con esto elevar la rapidez, eficiencia y calidad del conocimiento adquirido por la empresa.
Pero hago la consulta, no es algo "rimbombante" el decir: gestionamos conocimiento? , yo veo que estamos *guardando *información para luego utilizarla (en el punto 1) y estamos generando lineamientos para que las personas *generen* mas conocimiento para ellas mismas (en el punto 2)
Y por favor, ya eliminemos ese mito de que se puede extraer, sonsacar, quitar el conocimiento de las cabezas de las personas y hacerlo un patrimonio de la empresa. Podemos hacer un pequeño intento de dejar registrado lo que sucedió, lo que se hizo y como se encontró que era la mejor forma de hacerlo, pero eso es centralizar conocimiento?
Para mi, la clave (como siempre) está en el paradigma que se encuentra sobre la base de todo esto. Nos cuesta aceptar que la empresa son las personas, y que el conocimiento de la empresa es el conocimiento que está en las personas.
Lógicamente que existen una serie de limitantes en el mundo real para mantener al personal, etc, etc, etc...pero ese no es el tema aquí. Aquí el tema es como se vende esta gestión del conocimiento y el objetivo que pretende alcanzar.
> 2010/2/1 Deusdit Correa Cornejo <neod...@gmail.com>: > > Hola Heitor, > > Interesante tu articulo, esto me hace acordar a la practica de XP llamada > > "Metafora" que si bien no es muy utilizada realmente lo que busca es > > encontrar un mecanismo para intercambiar conocimiento de una manera en > que > > todos los participantes lo entiendan.
> El interes es crear el BA necesario para compartir y generar > conocimiento, no importa como la escrita de funcionalidads.
> > Quizas el problema con la Metafora sea que es muy generica y por ende no > se > > le ha dado la importancia debida en XP, mientras que en Scrum a traves de > > las reuniones es que se ha "aterrizado" un poco mas la creacion y el > > compartir los conocimientos.
> Las metaforas tienen un poder muy grande. Si bien utilizado el > concepto tenes una herramienta de se va facilitar la creacion y > compartir del conocimiento, por hacer que las personas involucradas > tengan una tendencia a expresarsen mas facilmente.
> > Scrum ayuda mucho en la generacion del Conocimiento, pero me parece > > que quizás falta definir alguna practica que permita gestionar ese > > conocimiento, pues al haber reuniones hay mucho conocimiento, pero este > se > > encuentra normalmente en la mente de los participantes.
> La gestion esta con el equipo. Self-managed teams son premisas de > Scrum Teams. Para alcanzar las metas de un proyecto o sprint no es > necesario tener lo conocimiento explicitado. Pero si hablamo solo de > KM (Knowledge Management) entonces tenemos un problema.
> > No hablo de documentar el producto o el proceso (pues eso va dentro de la > > documentacion regular que debe tener todo proyecto), sino del > conocimiento > > que se va generando en el dia a dia en cada miembro del equipo. Ese > > conocimiento forma parte del know-how de las personas pero que seria muy > > util para la empresa al quedar en un repositorio simple pero organizado > > donde cada quien pueda, de manera natural, compartirlo con los demas de > > manera tangible para que cualquier persona que lo necesite tengan acceso > a > > esa fuente de informacion, mas aun en caso la persona que registro ese
> Una pregunta: porque esto es util y importante para una empresa?
> > conocimiento ya no se encuentra en la empresa. Esto complementaria el > factor > > social que tiene que existir en todo manejo del conocimiento. > > Se que una Wiki ayudaria, pero habra alguna otra forma? Alguien en la > > comunidad realiza algo parecido en su dia a dia?
> He trabajado con wikis y la utilizacion continua destos es algo muy > dependiente del equipo. Hay que tener maturidad para usarlos. Conozco > equipo de investigacion que trabajan hasta con reconocimiento de voz, > pero tenemos que trabajar mucho aunque para alcanzar el objetivo mayor > de KM en Agile.
> > Dejo las preguntas abiertas... > > Atte, > > Deusdit Correa Cornejo (@neodacc) > > MBA Student / IT Director / Certified ScrumMaster / Agile Coach
> Saludos,
> Heitor
> > 2010/1/30 Heitor Roriz Filho <hro...@gmail.com>
> >> El modelo SECI de Takeuchi y Nonaka describe como el conocimineto es > >> creado y transformado. Como se pasa eso en Scrum?
> >> -- > >> Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de > >> Grupos de Google. > >> Si quieres publicar en este grupo, envía un mensaje de correo > >> electrónico a agileperu@googlegroups.com > >> Para anular la suscripción a este grupo, envía un mensaje a > >> agileperu-unsubscribe@googlegroups.com > >> Para obtener más opciones, visita este grupo en > >> http://groups.google.com.pe/group/agileperu?hl=es.
> > -- > > Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de > > Grupos de Google. > > Si quieres publicar en este grupo, envía un mensaje de correo > > electrónico a agileperu@googlegroups.com > > Para anular la suscripción a este grupo, envía un mensaje a > > agileperu-unsubscribe@googlegroups.com > > Para obtener más opciones, visita este grupo en > > http://groups.google.com.pe/group/agileperu?hl=es.
> -- > Has recibido este mensaje porque estás suscrito a Grupo "Agile Perú" de > Grupos de Google. > Si quieres publicar en este grupo, envía un mensaje de correo > electrónico a agileperu@googlegroups.com > Para anular la suscripción a este grupo, envía un mensaje a > agileperu-unsubscribe@googlegroups.com > Para obtener más opciones, visita este grupo en > http://groups.google.com.pe/group/agileperu?hl=es.
Quienes han trabajado bastante con el tema de gestionar conocimiento, entre otros, son las empresas japonesas.
No hay duda que el conocimiento lo tienen sólo las personas! No hay otra forma!
Tampoco hay duda que el conocimiento se comparte de manera eventual e informal, en blogs como este, en conferencias, cuando conversamos en el pasillo o tomamos un café con un colega, o cuando un colega o amigo nos pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto antes? Y le respondemos.
El asunto es (i) cómo hacer que el conocimiento se comparta de manera no sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
Este asunto puede resultas de poca importancia desde el punto de vista profesional individual o como consultores independientes o free lance. No estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora mientras más comparto y sirvo de conexión soy más valioso)
Les animo a que se pongan en los zapatos del accionista o dueño de una empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
La preocupación del gerente o dueño de empresa es ¿Cómo hago que el conocimiento importante para la empresa, se comparta con el resto de colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una empresa adquirimos experiencia gracias a que trabajamos para una empresa, es nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que ese conocimiento se comparta?
Las conclusiones, entre otras, de las empresas japonesas, es pasar el conocimiento implícito (en la cabeza de las personas) a explícito.
Esto se puede hacer de muchas formas y tener un repositorio no es la única ni las más efectiva, pero la que puede tener mayor alcance cuando la empresa tiene muchos colaboradores y/o están en varias ciudades. Hay empresas que tienen 130 mil colaboradores y oficinas en más de 120 países. Hay empresas en Perú con 50 personas en 3 ciudades. Hay empresas que tienen 25 colaboradores y están en 20 países.
En cuanto a la alternativa de tener un repositorio, está claro que no es suficiente guardar información en algún lugar para convertirlo en conocimiento explícito.
Para convertirlo en conocimiento explícito, se requiere:
. Que alguien (puede ser la misma persona) evalúe si ese conocimiento será de valor en otros casos
. Identificar el contenido a compartir
. Agregar al contenido a compartir, ideas que no están escritas y están en nuestra cabeza. Por ejemplo, en cuál contexto se usó ese conocimiento.
. Que alguien le de forma, es decir agregar datos que permitan accesar, clasificar a esa información (por ejemplo, por dominio, por profesión, entre otras formas)
. Publicar esa información
. Difundir que esa información está publicada y asegurar que llega a los posibles usuarios que le van a ver valor
. Mantener actualizada dicha información
. Dar de baja a información obsoleta o que ya no es correcta
. Hacer que las personas que tienen conocimiento o experiencia compartan su información, como parte del proceso, como parte de la retrospectiva de cualquier iteración, proyecto, tarea, servicio u operación.
El medio para esto es cualquier herramienta de manejo de contenidos, inclusive directorios compartidos!
Tener un repositorio no es la única forma de pasar conocimiento implícito a explícito en una organización. Pero es importante en muchos contextos.
He tenido la oportunidad de trabajar en empresas grandes y pequeñas que tenían dicho repositorio o base de datos de conocimiento. No tengo duda que eso es patrimonio de la empresa.
Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, proponer una solución y realizar una implementación exitosa usando la información en dicho repositorio, información que fue almacenada por dos proyectos ejecutados en Italia, jamás hablé con las personas de dichos proyectos en Italia, no sé hablar italiano, la información que almacenaron estaba en inglés y cuando hice la búsqueda pude ubicar la información que necesitaba. La información estaba guardada cumpliendo los requisitos anteriores: pude ubicarla, había información de contexto, habías recomendaciones, etc. además del contenido. No tengo duda que usé conocimiento generado por otras personas. Es decir cómo hacer algo, la técnica, el método. Yo necesitaba una solución relativamente similar.
"This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message."
"Este correo electrónico es para uso exclusivo del receptor(es) a quien(es) se envió y puede contener información confidencial o privilegiada. Cualquier revisión, uso, difusión o distribución no autorizada está prohibido. Si usted no es el receptor a quien se envió este correo electrónico y su contenido, por favor, adviértalo a quien le envío el correo electrónico contestando el correo y destruyendo todas las copias del mensaje original."
_____
De: agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] En nombre de Raul Uribe Enviado el: Wednesday, 03 February, 2010 8:29 AM Para: agileperu@googlegroups.com Asunto: Re: [agileperu] La creacion de conocimiento en Scrum
Para serles sincero, luego de leer y releer sobre este tema, con esas ganas iniciales que tenía de realmente llegar a "gestionar el conocimiento" cuando supe de la existencia de este tema...he llegado a la conclusión que realmente "gestionamos" conocimiento?
Al final, en casi todo lo que he visto, se trata de (como bien dice Eddy)
1.Crear un repositorio con información coherentemente relacionada que permita la explotación y la recuperación de "conocimiento" (no es información?) de este repositorio. Y para esto nos valemos de herramientas colaborativas basadas generalmente en portales web, etc, etc.
2. Generar vías, dinámicas, reglas, políticas que ayuden a la "generación" de conocimiento en base a la experiencia de un equipo o una empresa, y con esto elevar la rapidez, eficiencia y calidad del conocimiento adquirido por la empresa.
Pero hago la consulta, no es algo "rimbombante" el decir: gestionamos conocimiento? , yo veo que estamos guardando información para luego utilizarla (en el punto 1) y estamos generando lineamientos para que las personas generen mas conocimiento para ellas mismas (en el punto 2)
Y por favor, ya eliminemos ese mito de que se puede extraer, sonsacar, quitar el conocimiento de las cabezas de las personas y hacerlo un patrimonio de la empresa. Podemos hacer un pequeño intento de dejar registrado lo que sucedió, lo que se hizo y como se encontró que era la mejor forma de hacerlo, pero eso es centralizar conocimiento?
Para mi, la clave (como siempre) está en el paradigma que se encuentra sobre la base de todo esto. Nos cuesta aceptar que la empresa son las personas, y que el conocimiento de la empresa es el conocimiento que está en las personas.
Lógicamente que existen una serie de limitantes en el mundo real para mantener al personal, etc, etc, etc...pero ese no es el tema aquí. Aquí el tema es como se vende esta gestión del conocimiento y el objetivo que pretende alcanzar.
Se puso bonito el debate =)
Un abrazo,
Raúl
2010/2/3 Heitor Roriz Filho < <mailto:hro...@gmail.com> hro...@gmail.com>
> Hola Heitor, > Interesante tu articulo, esto me hace acordar a la practica de XP llamada > "Metafora" que si bien no es muy utilizada realmente lo que busca es > encontrar un mecanismo para intercambiar conocimiento de una manera en que > todos los participantes lo entiendan.
El interes es crear el BA necesario para compartir y generar conocimiento, no importa como la escrita de funcionalidads.
> Quizas el problema con la Metafora sea que es muy generica y por ende no se > le ha dado la importancia debida en XP, mientras que en Scrum a traves de > las reuniones es que se ha "aterrizado" un poco mas la creacion y el > compartir los conocimientos.
Las metaforas tienen un poder muy grande. Si bien utilizado el concepto tenes una herramienta de se va facilitar la creacion y compartir del conocimiento, por hacer que las personas involucradas tengan una tendencia a expresarsen mas facilmente.
> Scrum ayuda mucho en la generacion del Conocimiento, pero me parece > que quizás falta definir alguna practica que permita gestionar ese > conocimiento, pues al haber reuniones hay mucho conocimiento, pero este se > encuentra normalmente en la mente de los participantes.
La gestion esta con el equipo. Self-managed teams son premisas de Scrum Teams. Para alcanzar las metas de un proyecto o sprint no es necesario tener lo conocimiento explicitado. Pero si hablamo solo de KM (Knowledge Management) entonces tenemos un problema.
> No hablo de documentar el producto o el proceso (pues eso va dentro de la > documentacion regular que debe tener todo proyecto), sino del conocimiento > que se va generando en el dia a dia en cada miembro del equipo. Ese > conocimiento forma parte del
Aqui algunos comentarios para incrementar el debate :)
Yo estoy de acuerdo con David en el sentido de que a veces nos preocupamos mucho del tema de equipo y nos olvidamos que una empresa es un conjunto de equipos trabajando de manera integrada y hay una relacion bidireccional entre equipos y empresa.
Lo que si no comparto es la idea de Raul, pues justamente el hecho de que las personas que trabajan en los equipos no van a estar toda la vida en la empresa (lo cual es muy comun en nuestros dias) es que las empresas estan viendo la forma de gestionar el conocimiento, pues nos guste o no, el conocimiento es un activo intagible muy valioso para las personas y para las empresa. (Premisa bajo la que creo Wikipedia)
Ahora, por gestionar, no me estoy refiriendo a manejar, administrar el conocimiento, me estoy refiriendo al hecho de crear un ambiente, proporcionar herramientas, ayudar a la gente para que el conocimiento implicito se convierta en explicito para bien del resto de personas de los equipos y por consecuencia de la empresa.
Una de las formas de gestionar el conocimiento es a traves del mentoring e incluso del coaching de equipos las cuales pueden ser complementadas con algunas herramientas para poner el conocimiento explicito (tal como David lo indico en su ejemplo), pero como todo en la vida, hay un costo de oportunidad pues el mantener ese conocimiento implicara que la empresa dedique ciertos recursos a ello, ni modo.
Randiel indico que deben haber reglas y asociaciones entre el conocimiento, es cierto, imagino que con el tiempo saldran herramientas mas especializadas para esto, pero creo que el uso, no exagerado, de las herramientas Web 2.0 es un buen punto de partida (Wikis, enlaces, tags, twitter, RSS, etc.). Seria interesante que Randiel nos explicara un poco mas, si es posible claro, sobre las reglas de inferencia con las que ha trabajado :)
Heitor tambien menciono algo muy interesante... como el mundo Agile esta tratando el conocimiento explicito, quizas el hecho de que la mayoria de actividades sean verbales esta impidiendo que el conocimiento explicito florezca en estos ambientes. Por ello ni demasiada ni muy poca (o ninguna) documentacion es buena. Ademas, "documentar" el conocimiento explicito no me parece que sea algo sin importancia.... Creo que por aqui hay un tema de investigacion interesante.
Aun me falta leer el articulo que envio Manuel, se ve interesante, gracias por el link!
Deus
2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
> Quienes han trabajado bastante con el tema de gestionar conocimiento, entre > otros, son las empresas japonesas.
> No hay duda que el conocimiento lo tienen sólo las personas! No hay otra > forma!
> Tampoco hay duda que el conocimiento se comparte de manera eventual e > informal, en blogs como este, en conferencias, cuando conversamos en el > pasillo o tomamos un café con un colega, o cuando un colega o amigo nos > pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto > antes? Y le respondemos.
> El asunto es (i) cómo hacer que el conocimiento se comparta de manera no > sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
> Este asunto puede resultas de poca importancia desde el punto de vista > profesional individual o como consultores independientes o free lance. No > estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana > (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de > mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora > mientras más comparto y sirvo de conexión soy más valioso)
> Les animo a que se pongan en los zapatos del accionista o dueño de una > empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
> La preocupación del gerente o dueño de empresa es ¿Cómo hago que el > conocimiento *importante* para la empresa, se comparta con el resto de > colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, > etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una > empresa adquirimos experiencia gracias a que trabajamos para una empresa, es > nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que > ese conocimiento se comparta?
> Las conclusiones, entre otras, de las empresas japonesas, es pasar el > conocimiento implícito (en la cabeza de las personas) a explícito.
> Esto se puede hacer de muchas formas y tener un repositorio no es la única > ni las más efectiva, pero la que puede tener mayor alcance cuando la empresa > tiene muchos colaboradores y/o están en varias ciudades. Hay empresas que > tienen 130 mil colaboradores y oficinas en más de 120 países. Hay empresas > en Perú con 50 personas en 3 ciudades. Hay empresas que tienen 25 > colaboradores y están en 20 países.
> En cuanto a la alternativa de tener un repositorio, está claro que no es > suficiente guardar información en algún lugar para convertirlo en > conocimiento explícito.
> Para convertirlo en conocimiento explícito, se requiere:
> . Que alguien (puede ser la misma persona) evalúe si ese conocimiento será > de valor en otros casos
> . Identificar el contenido a compartir
> . Agregar al contenido a compartir, ideas que no están escritas y están en > nuestra cabeza. Por ejemplo, en cuál contexto se usó ese conocimiento.
> . Que alguien le de forma, es decir agregar datos que permitan accesar, > clasificar a esa información (por ejemplo, por dominio, por profesión, entre > otras formas)
> . Publicar esa información
> . Difundir que esa información está publicada y asegurar que llega a los > posibles usuarios que le van a ver valor
> . Mantener actualizada dicha información
> . Dar de baja a información obsoleta o que ya no es correcta
> . Hacer que las personas que tienen conocimiento o experiencia compartan su > información, como parte del proceso, como parte de la retrospectiva de > cualquier iteración, proyecto, tarea, servicio u operación.
> El medio para esto es cualquier herramienta de manejo de contenidos, > inclusive directorios compartidos!
> Tener un repositorio no es la única forma de pasar conocimiento implícito a > explícito en una organización. Pero es importante en muchos contextos.
> He tenido la oportunidad de trabajar en empresas grandes y pequeñas que > tenían dicho repositorio o base de datos de conocimiento. No tengo duda que > eso es patrimonio de la empresa.
> Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, proponer > una solución y realizar una implementación exitosa usando la información en > dicho repositorio, información que fue almacenada por dos proyectos > ejecutados en Italia, jamás hablé con las personas de dichos proyectos en > Italia, no sé hablar italiano, la información que almacenaron estaba en > inglés y cuando hice la búsqueda pude ubicar la información que necesitaba. > La información estaba guardada cumpliendo los requisitos anteriores: pude > ubicarla, había información de contexto, habías recomendaciones, etc. además > del contenido. No tengo duda que usé conocimiento generado por otras > personas. Es decir cómo hacer algo, la técnica, el método. Yo necesitaba una > solución relativamente similar.
> "This e-mail message is for the sole use of the intended recipient(s) and > may contain confidential and/or privileged information. Any unauthorized > review, use, disclosure or distribution is prohibited. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies of the original message."
> "Este correo electrónico es para uso exclusivo del receptor(es) a quien(es) > se envió y puede contener información confidencial o privilegiada. Cualquier > revisión, uso, difusión o distribución no autorizada está prohibido. Si > usted no es el receptor a quien se envió este correo electrónico y su > contenido, por favor, adviértalo a quien le envío el correo electrónico > contestando el correo y destruyendo todas las copias del mensaje original." > ------------------------------
> *De:* agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] *En > nombre de *Raul Uribe > *Enviado el:* Wednesday, 03 February, 2010 8:29 AM
> *Para:* agileperu@googlegroups.com > *Asunto:* Re: [agileperu] La creacion de conocimiento en Scrum
> Para serles sincero, luego de leer y releer sobre este tema, con esas ganas > iniciales que tenía de realmente llegar a "gestionar el conocimiento" cuando > supe de la existencia de este tema...he llegado a la conclusión que > realmente "gestionamos" conocimiento?
> Al final, en casi todo lo que he visto, se trata de (como bien dice Eddy)
> 1.Crear un repositorio con información coherentemente relacionada que > permita la explotación y la recuperación de "conocimiento" (no es > información?) de este repositorio. Y para esto nos valemos de herramientas > colaborativas basadas generalmente en portales web, etc, etc.
> 2. Generar vías, dinámicas, reglas, políticas que ayuden a la "generación" > de conocimiento en base a la experiencia de un equipo o una empresa, y con > esto elevar la rapidez, eficiencia y calidad del conocimiento adquirido por > la empresa.
> Pero hago la consulta, no es algo "rimbombante" el decir: gestionamos > conocimiento? , yo veo que estamos *guardando *información para luego > utilizarla (en el punto 1) y estamos generando lineamientos para que las > personas *generen* mas conocimiento para ellas mismas (en el punto
En mi experiencia profesional es verdad que los repositorios bien organizados e* integrados* con el resto de sistemas de la empresa (eg sistema de tickets, bugs, documentos, directorioa de personal, etc) ayudan bastante a compartir conocimientos.
Sin embargo también hay otras maneras más sencillas de mejorar el flujo de conocimiento en la empresa y que deben ser exploradas antes de pasar a implementar un sistema de conocimiento electronicos, ya que quizas basten para los requisitos de la empresa basten otras formas mas sencillas y economicas.
Por ejemplo yo conozco el caso de una empresa grande donde trabaje, done nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran de vidrio. Es más en muchos casos aprendía partes importantes cuando mis colegas y/o jefe hablaban con otros y yo escuchaba las conversacoines del costado. Este diseño de la oficina fomentar los encuentros casuales y el conocimiento compartido entre colegas puede ser muy útil, si es que el modelo del negocio lo permite.Funcionaba bastante bien y no requería mayor inversión en TI.
Saludos, Rafael
2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
> Quienes han trabajado bastante con el tema de gestionar conocimiento, entre > otros, son las empresas japonesas.
> No hay duda que el conocimiento lo tienen sólo las personas! No hay otra > forma!
> Tampoco hay duda que el conocimiento se comparte de manera eventual e > informal, en blogs como este, en conferencias, cuando conversamos en el > pasillo o tomamos un café con un colega, o cuando un colega o amigo nos > pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto > antes? Y le respondemos.
> El asunto es (i) cómo hacer que el conocimiento se comparta de manera no > sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
> Este asunto puede resultas de poca importancia desde el punto de vista > profesional individual o como consultores independientes o free lance. No > estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana > (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de > mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora > mientras más comparto y sirvo de conexión soy más valioso)
> Les animo a que se pongan en los zapatos del accionista o dueño de una > empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
> La preocupación del gerente o dueño de empresa es ¿Cómo hago que el > conocimiento *importante* para la empresa, se comparta con el resto de > colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, > etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una > empresa adquirimos experiencia gracias a que trabajamos para una empresa, es > nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que > ese conocimiento se comparta?
> Las conclusiones, entre otras, de las empresas japonesas, es pasar el > conocimiento implícito (en la cabeza de las personas) a explícito.
> Esto se puede hacer de muchas formas y tener un repositorio no es la única > ni las más efectiva, pero la que puede tener mayor alcance cuando la empresa > tiene muchos colaboradores y/o están en varias ciudades. Hay empresas que > tienen 130 mil colaboradores y oficinas en más de 120 países. Hay empresas > en Perú con 50 personas en 3 ciudades. Hay empresas que tienen 25 > colaboradores y están en 20 países.
> En cuanto a la alternativa de tener un repositorio, está claro que no es > suficiente guardar información en algún lugar para convertirlo en > conocimiento explícito.
> Para convertirlo en conocimiento explícito, se requiere:
> . Que alguien (puede ser la misma persona) evalúe si ese conocimiento será > de valor en otros casos
> . Identificar el contenido a compartir
> . Agregar al contenido a compartir, ideas que no están escritas y están en > nuestra cabeza. Por ejemplo, en cuál contexto se usó ese conocimiento.
> . Que alguien le de forma, es decir agregar datos que permitan accesar, > clasificar a esa información (por ejemplo, por dominio, por profesión, entre > otras formas)
> . Publicar esa información
> . Difundir que esa información está publicada y asegurar que llega a los > posibles usuarios que le van a ver valor
> . Mantener actualizada dicha información
> . Dar de baja a información obsoleta o que ya no es correcta
> . Hacer que las personas que tienen conocimiento o experiencia compartan su > información, como parte del proceso, como parte de la retrospectiva de > cualquier iteración, proyecto, tarea, servicio u operación.
> El medio para esto es cualquier herramienta de manejo de contenidos, > inclusive directorios compartidos!
> Tener un repositorio no es la única forma de pasar conocimiento implícito a > explícito en una organización. Pero es importante en muchos contextos.
> He tenido la oportunidad de trabajar en empresas grandes y pequeñas que > tenían dicho repositorio o base de datos de conocimiento. No tengo duda que > eso es patrimonio de la empresa.
> Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, proponer > una solución y realizar una implementación exitosa usando la información en > dicho repositorio, información que fue almacenada por dos proyectos > ejecutados en Italia, jamás hablé con las personas de dichos proyectos en > Italia, no sé hablar italiano, la información que almacenaron estaba en > inglés y cuando hice la búsqueda pude ubicar la información que necesitaba. > La información estaba guardada cumpliendo los requisitos anteriores: pude > ubicarla, había información de contexto, habías recomendaciones, etc. además > del contenido. No tengo duda que usé conocimiento generado por otras > personas. Es decir cómo hacer algo, la técnica, el método. Yo necesitaba una > solución relativamente similar.
> "This e-mail message is for the sole use of the intended recipient(s) and > may contain confidential and/or privileged information. Any unauthorized > review, use, disclosure or distribution is prohibited. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies of the original message."
> "Este correo electrónico es para uso exclusivo del receptor(es) a quien(es) > se envió y puede contener información confidencial o privilegiada. Cualquier > revisión, uso, difusión o distribución no autorizada está prohibido. Si > usted no es el receptor a quien se envió este correo electrónico y su > contenido, por favor, adviértalo a quien le envío el correo electrónico > contestando el correo y destruyendo todas las copias del mensaje original." > ------------------------------
> *De:* agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] *En > nombre de *Raul Uribe > *Enviado el:* Wednesday, 03 February, 2010 8:29 AM
> *Para:* agileperu@googlegroups.com > *Asunto:* Re: [agileperu] La creacion de conocimiento en Scrum
> Para serles sincero, luego de leer y releer sobre este tema, con esas ganas > iniciales que tenía de realmente llegar a "gestionar el conocimiento" cuando > supe de la existencia de este tema...he llegado a la conclusión que > realmente "gestionamos" conocimiento?
> Al final, en casi todo lo que he visto, se trata de (como bien dice Eddy)
> 1.Crear un repositorio con información coherentemente relacionada que > permita la explotación y la recuperación de "conocimiento" (no es > información?) de este repositorio. Y para esto nos valemos de herramientas > colaborativas basadas generalmente en portales web, etc, etc.
> 2. Generar vías, dinámicas, reglas, políticas que ayuden a la "generación" > de conocimiento en base a la experiencia de un equipo o una empresa, y con > esto elevar la rapidez, eficiencia y calidad del conocimiento adquirido por > la empresa.
> Pero hago la consulta, no es algo "rimbombante" el decir: gestionamos > conocimiento? , yo veo que estamos *guardando *información para luego > utilizarla (en el punto 1) y estamos generando lineamientos para que las > personas *generen* mas conocimiento para ellas mismas (en el punto 2)
> Y por favor, ya eliminemos ese mito de que se puede extraer, sonsacar, > quitar el conocimiento de las cabezas de las personas y hacerlo un > patrimonio de la empresa. Podemos hacer un pequeño intento de dejar > registrado lo que sucedió, lo que se hizo y como se encontró que era la > mejor forma de hacerlo, pero eso es centralizar conocimiento?
> Para mi, la clave (como siempre) está en el paradigma que se encuentra > sobre la base de todo esto. Nos cuesta aceptar que la empresa son las > personas, y que el conocimiento de la empresa es el conocimiento que está en > las personas.
> Lógicamente que existen una serie de limitantes en el mundo real para > mantener al personal, etc, etc, etc...pero ese no es el tema aquí. Aquí el > tema es como se vende esta gestión del conocimiento y el objetivo que > pretende alcanzar.
> > Hola Heitor, > > Interesante tu articulo, esto me hace acordar a la practica de XP llamada > > "Metafora" que si bien no es muy utilizada realmente lo que busca es > > encontrar un mecanismo para intercambiar conocimiento de una manera en > que > > todos los
Claro que sí! Claro que es bueno tener un repositorio, claro que las personas no estarán toda la vida en sus empresas (dímelo a mi que llevo un mes en una empresa nueva ;D ), es imposible predicar que "no hace falta", "no es bueno", gestionar el conocimiento. Esto no quize decir en ningún caso.
Por otro lado, David, en mi caso no hace falta abstraerme para imaginarme ser dueño de una empresa y que necesidades se pueden generar. Hace unos años tuve una con con mi padre, y vivíamos (entre otras mil preocupaciones) eso de que la gente se iba sin dejar nada. Claro que sí entiendo tu punto.
El problema está señores...
Cuando viene alguien que dice saber "gestionar el conocimiento" y quiere vender la idea a ese dueño de empresa, que con implementar un repositorio, prácticas de generación de conocimiento, etc, etc, etc...le promete..."Yo llevaré todo lo implícito a explícito!" y tu empresa ya no dependerá más de las personas, serán reemplazables sin problemas...
Creo que el desconocimiento respecto a esta rama es lo que hace tanto daño...se siente cierta contradicción en decir:* "Gestionemos el conocimiento y...dependamos de las personas!"* , la gente que siente que esto es contradictorio, es la que le hace daño al tema, y al final, a esa empresa.
Así que quede claro mi punto por favor, la gestión del conocimiento es importante, con la sabiduría de que realmente lo implícito...nunca será explicito al 100%.
> En mi experiencia profesional es verdad que los repositorios bien > organizados e* integrados* con el resto de sistemas de la empresa (eg > sistema de tickets, bugs, documentos, directorioa de personal, etc) ayudan > bastante a compartir conocimientos.
> Sin embargo también hay otras maneras más sencillas de mejorar el flujo de > conocimiento en la empresa y que deben ser exploradas antes de pasar a > implementar un sistema de conocimiento electronicos, ya que quizas basten > para los requisitos de la empresa basten otras formas mas sencillas y > economicas.
> Por ejemplo yo conozco el caso de una empresa grande donde trabaje, done > nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran de > vidrio. Es más en muchos casos aprendía partes importantes cuando mis > colegas y/o jefe hablaban con otros y yo escuchaba las conversacoines del > costado. Este diseño de la oficina fomentar los encuentros casuales y el > conocimiento compartido entre colegas puede ser muy útil, si es que el > modelo del negocio lo permite.Funcionaba bastante bien y no requería mayor > inversión en TI.
> Saludos, > Rafael
> 2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
>> Holas!
>> Añado más ideas para el debate.
>> Quienes han trabajado bastante con el tema de gestionar conocimiento, >> entre otros, son las empresas japonesas.
>> No hay duda que el conocimiento lo tienen sólo las personas! No hay otra >> forma!
>> Tampoco hay duda que el conocimiento se comparte de manera eventual e >> informal, en blogs como este, en conferencias, cuando conversamos en el >> pasillo o tomamos un café con un colega, o cuando un colega o amigo nos >> pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto >> antes? Y le respondemos.
>> El asunto es (i) cómo hacer que el conocimiento se comparta de manera no >> sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
>> Este asunto puede resultas de poca importancia desde el punto de vista >> profesional individual o como consultores independientes o free lance. No >> estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana >> (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de >> mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora >> mientras más comparto y sirvo de conexión soy más valioso)
>> Les animo a que se pongan en los zapatos del accionista o dueño de una >> empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
>> La preocupación del gerente o dueño de empresa es ¿Cómo hago que el >> conocimiento *importante* para la empresa, se comparta con el resto de >> colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, >> etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una >> empresa adquirimos experiencia gracias a que trabajamos para una empresa, es >> nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que >> ese conocimiento se comparta?
>> Las conclusiones, entre otras, de las empresas japonesas, es pasar el >> conocimiento implícito (en la cabeza de las personas) a explícito.
>> Esto se puede hacer de muchas formas y tener un repositorio no es la única >> ni las más efectiva, pero la que puede tener mayor alcance cuando la empresa >> tiene muchos colaboradores y/o están en varias ciudades. Hay empresas que >> tienen 130 mil colaboradores y oficinas en más de 120 países. Hay empresas >> en Perú con 50 personas en 3 ciudades. Hay empresas que tienen 25 >> colaboradores y están en 20 países.
>> En cuanto a la alternativa de tener un repositorio, está claro que no es >> suficiente guardar información en algún lugar para convertirlo en >> conocimiento explícito.
>> Para convertirlo en conocimiento explícito, se requiere:
>> . Que alguien (puede ser la misma persona) evalúe si ese conocimiento será >> de valor en otros casos
>> . Identificar el contenido a compartir
>> . Agregar al contenido a compartir, ideas que no están escritas y están en >> nuestra cabeza. Por ejemplo, en cuál contexto se usó ese conocimiento.
>> . Que alguien le de forma, es decir agregar datos que permitan accesar, >> clasificar a esa información (por ejemplo, por dominio, por profesión, entre >> otras formas)
>> . Publicar esa información
>> . Difundir que esa información está publicada y asegurar que llega a los >> posibles usuarios que le van a ver valor
>> . Mantener actualizada dicha información
>> . Dar de baja a información obsoleta o que ya no es correcta
>> . Hacer que las personas que tienen conocimiento o experiencia compartan >> su información, como parte del proceso, como parte de la retrospectiva de >> cualquier iteración, proyecto, tarea, servicio u operación.
>> El medio para esto es cualquier herramienta de manejo de contenidos, >> inclusive directorios compartidos!
>> Tener un repositorio no es la única forma de pasar conocimiento implícito >> a explícito en una organización. Pero es importante en muchos contextos.
>> He tenido la oportunidad de trabajar en empresas grandes y pequeñas que >> tenían dicho repositorio o base de datos de conocimiento. No tengo duda que >> eso es patrimonio de la empresa.
>> Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, proponer >> una solución y realizar una implementación exitosa usando la información en >> dicho repositorio, información que fue almacenada por dos proyectos >> ejecutados en Italia, jamás hablé con las personas de dichos proyectos en >> Italia, no sé hablar italiano, la información que almacenaron estaba en >> inglés y cuando hice la búsqueda pude ubicar la información que necesitaba. >> La información estaba guardada cumpliendo los requisitos anteriores: pude >> ubicarla, había información de contexto, habías recomendaciones, etc. además >> del contenido. No tengo duda que usé conocimiento generado por otras >> personas. Es decir cómo hacer algo, la técnica, el método. Yo necesitaba una >> solución relativamente similar.
>> "This e-mail message is for the sole use of the intended recipient(s) and >> may contain confidential and/or privileged information. Any unauthorized >> review, use, disclosure or distribution is prohibited. If you are not the >> intended recipient, please contact the sender by reply e-mail and destroy >> all copies of the original message."
>> "Este correo electrónico es para uso exclusivo del receptor(es) a >> quien(es) se envió y puede contener información confidencial o privilegiada. >> Cualquier revisión, uso, difusión o distribución no autorizada está >> prohibido. Si usted no es el receptor a quien se envió este correo >> electrónico y su contenido, por favor, adviértalo a quien le envío el correo >> electrónico contestando el correo y destruyendo todas las copias del mensaje >> original." >> ------------------------------
>> *De:* agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] *En >> nombre de *Raul Uribe >> *Enviado el:* Wednesday, 03 February, 2010 8:29 AM
>> *Para:* agileperu@googlegroups.com >> *Asunto:* Re: [agileperu] La creacion de conocimiento en Scrum
>> Para serles sincero, luego de leer y releer sobre este tema, con esas >> ganas iniciales que tenía de realmente llegar a "gestionar el conocimiento" >> cuando supe de la existencia de este tema...he llegado a la conclusión que >> realmente "gestionamos" conocimiento?
>> Al final, en casi todo lo que he visto, se trata de (como bien dice Eddy)
>> 1.Crear un repositorio con información coherentemente relacionada que >> permita la explotación y la recuperación de "conocimiento" (no es >> información?) de este repositorio. Y para esto nos valemos de herramientas >> colaborativas basadas generalmente en portales web, etc, etc.
>> 2. Generar vías, dinámicas, reglas, políticas que ayuden a la
> Claro que sí! Claro que es bueno tener un repositorio, claro que las > personas no estarán toda la vida en sus empresas (dímelo a mi que llevo un > mes en una empresa nueva ;D ), es imposible predicar que "no hace falta", > "no es bueno", gestionar el conocimiento. Esto no quize decir en ningún > caso.
> Por otro lado, David, en mi caso no hace falta abstraerme para imaginarme > ser dueño de una empresa y que necesidades se pueden generar. Hace unos años > tuve una con con mi padre, y vivíamos (entre otras mil preocupaciones) eso > de que la gente se iba sin dejar nada. Claro que sí entiendo tu punto.
> El problema está señores...
> Cuando viene alguien que dice saber "gestionar el conocimiento" y quiere > vender la idea a ese dueño de empresa, que con implementar un repositorio, > prácticas de generación de conocimiento, etc, etc, etc...le promete..."Yo > llevaré todo lo implícito a explícito!" y tu empresa ya no dependerá más de > las personas, serán reemplazables sin problemas...
> Creo que el desconocimiento respecto a esta rama es lo que hace tanto > daño...se siente cierta contradicción en decir:* "Gestionemos el > conocimiento y...dependamos de las personas!"* , la gente que siente que > esto es contradictorio, es la que le hace daño al tema, y al final, a esa > empresa.
> Así que quede claro mi punto por favor, la gestión del conocimiento es > importante, con la sabiduría de que realmente lo implícito...nunca será > explicito al 100%.
> En mi experiencia profesional es verdad que los repositorios bien >> organizados e* integrados* con el resto de sistemas de la empresa (eg >> sistema de tickets, bugs, documentos, directorioa de personal, etc) ayudan >> bastante a compartir conocimientos.
>> Sin embargo también hay otras maneras más sencillas de mejorar el flujo de >> conocimiento en la empresa y que deben ser exploradas antes de pasar a >> implementar un sistema de conocimiento electronicos, ya que quizas basten >> para los requisitos de la empresa basten otras formas mas sencillas y >> economicas.
>> Por ejemplo yo conozco el caso de una empresa grande donde trabaje, done >> nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran de >> vidrio. Es más en muchos casos aprendía partes importantes cuando mis >> colegas y/o jefe hablaban con otros y yo escuchaba las conversacoines del >> costado. Este diseño de la oficina fomentar los encuentros casuales y el >> conocimiento compartido entre colegas puede ser muy útil, si es que el >> modelo del negocio lo permite.Funcionaba bastante bien y no requería mayor >> inversión en TI.
>> Saludos, >> Rafael
>> 2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
>>> Holas!
>>> Añado más ideas para el debate.
>>> Quienes han trabajado bastante con el tema de gestionar conocimiento, >>> entre otros, son las empresas japonesas.
>>> No hay duda que el conocimiento lo tienen sólo las personas! No hay otra >>> forma!
>>> Tampoco hay duda que el conocimiento se comparte de manera eventual e >>> informal, en blogs como este, en conferencias, cuando conversamos en el >>> pasillo o tomamos un café con un colega, o cuando un colega o amigo nos >>> pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto >>> antes? Y le respondemos.
>>> El asunto es (i) cómo hacer que el conocimiento se comparta de manera no >>> sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
>>> Este asunto puede resultas de poca importancia desde el punto de vista >>> profesional individual o como consultores independientes o free lance. No >>> estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana >>> (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de >>> mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora >>> mientras más comparto y sirvo de conexión soy más valioso)
>>> Les animo a que se pongan en los zapatos del accionista o dueño de una >>> empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
>>> La preocupación del gerente o dueño de empresa es ¿Cómo hago que el >>> conocimiento *importante* para la empresa, se comparta con el resto de >>> colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, >>> etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una >>> empresa adquirimos experiencia gracias a que trabajamos para una empresa, es >>> nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que >>> ese conocimiento se comparta?
>>> Las conclusiones, entre otras, de las empresas japonesas, es pasar el >>> conocimiento implícito (en la cabeza de las personas) a explícito.
>>> Esto se puede hacer de muchas formas y tener un repositorio no es la >>> única ni las más efectiva, pero la que puede tener mayor alcance cuando la >>> empresa tiene muchos colaboradores y/o están en varias ciudades. Hay >>> empresas que tienen 130 mil colaboradores y oficinas en más de 120 países. >>> Hay empresas en Perú con 50 personas en 3 ciudades. Hay empresas que tienen >>> 25 colaboradores y están en 20 países.
>>> En cuanto a la alternativa de tener un repositorio, está claro que no es >>> suficiente guardar información en algún lugar para convertirlo en >>> conocimiento explícito.
>>> Para convertirlo en conocimiento explícito, se requiere:
>>> . Que alguien (puede ser la misma persona) evalúe si ese conocimiento >>> será de valor en otros casos
>>> . Identificar el contenido a compartir
>>> . Agregar al contenido a compartir, ideas que no están escritas y están >>> en nuestra cabeza. Por ejemplo, en cuál contexto se usó ese conocimiento.
>>> . Que alguien le de forma, es decir agregar datos que permitan accesar, >>> clasificar a esa información (por ejemplo, por dominio, por profesión, entre >>> otras formas)
>>> . Publicar esa información
>>> . Difundir que esa información está publicada y asegurar que llega a los >>> posibles usuarios que le van a ver valor
>>> . Mantener actualizada dicha información
>>> . Dar de baja a información obsoleta o que ya no es correcta
>>> . Hacer que las personas que tienen conocimiento o experiencia compartan >>> su información, como parte del proceso, como parte de la retrospectiva de >>> cualquier iteración, proyecto, tarea, servicio u operación.
>>> El medio para esto es cualquier herramienta de manejo de contenidos, >>> inclusive directorios compartidos!
>>> Tener un repositorio no es la única forma de pasar conocimiento implícito >>> a explícito en una organización. Pero es importante en muchos contextos.
>>> He tenido la oportunidad de trabajar en empresas grandes y pequeñas que >>> tenían dicho repositorio o base de datos de conocimiento. No tengo duda que >>> eso es patrimonio de la empresa.
>>> Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, proponer >>> una solución y realizar una implementación exitosa usando la información en >>> dicho repositorio, información que fue almacenada por dos proyectos >>> ejecutados en Italia, jamás hablé con las personas de dichos proyectos en >>> Italia, no sé hablar italiano, la información que almacenaron estaba en >>> inglés y cuando hice la búsqueda pude ubicar la información que necesitaba. >>> La información estaba guardada cumpliendo los requisitos anteriores: pude >>> ubicarla, había información de contexto, habías recomendaciones, etc. además >>> del contenido. No tengo duda que usé conocimiento generado por otras >>> personas. Es decir cómo hacer algo, la técnica, el método. Yo necesitaba una >>> solución relativamente similar.
>>> "This e-mail message is for the sole use of the intended recipient(s) and >>> may contain confidential and/or privileged information. Any unauthorized >>> review, use, disclosure or distribution is prohibited. If you are not the >>> intended recipient, please contact the sender by reply e-mail and destroy >>> all copies of the original message."
>>> "Este correo electrónico es para uso exclusivo del receptor(es) a >>> quien(es) se envió y puede contener información confidencial o privilegiada. >>> Cualquier revisión, uso, difusión o distribución no autorizada está >>> prohibido. Si usted no es el receptor a quien se envió este correo >>> electrónico y su contenido, por favor, adviértalo a quien le envío el correo >>> electrónico contestando el correo y destruyendo todas las copias del mensaje >>> original." >>> ------------------------------
>>> *De:* agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] *En >>> nombre de *Raul Uribe >>> *Enviado el:* Wednesday, 03 February, 2010 8:29 AM
>>> *Para:* agileperu@googlegroups.com >>> *Asunto:* Re: [agileperu] La creacion de conocimiento en Scrum
>>> Para serles sincero, luego de leer y releer sobre este tema, con esas >>> ganas iniciales que tenía de realmente llegar a "gestionar el conocimiento" >>> cuando supe de la existencia de este tema...he llegado a la conclusión que >>> realmente "gestionamos" conocimiento?
Exacto Raúl, eso es lo que trataba de mostrar con la lectura que mande, en realidad gestionar conocimiento implica una serie de tareas y recursos como menciona David, el problema con este enfoque es que por lo general se tiende a perder el objetivo (por naturaleza humana) y se destinan más recursos las actividades de gestión del conocimiento y menos a las de generación de nuevos conocimientos en especial en un entorno donde aparece mucho conocimiento nuevo fuera de la empresa. Entonces lo que se necesita (sin dejar de lado las otras tareas) es mejorar la interacción de las personas en la creación de nuevo conocimiento valioso fuera de los límites de la empresa pero para beneficio de la empresa.
Por eso herramientas colaborativas como blogs, Twitter, del.icius, wikis, entre otras generadoras de espacios, permiten que el conocimiento trascienda fuera de la empresa y se enriquezca. El objetivo de este enfoque no es que use tal o cual herramienta en desprecio de otras, sino que no se pierda el enfoque de porque gestiono el conocimiento y supeditado al enfoque principal: todas las actividades clásicas de una gestión de conocimiento.
MagiaDigital y aurix Software Solutions son marcas registradas de Magia Comunicaciones S.A.
De: agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] En nombre de Manuel Mazan Enviado el: Miércoles, 03 de Febrero de 2010 05:31 p.m. Para: agileperu@googlegroups.com Asunto: Re: [agileperu] La creacion de conocimiento en Scrum
Amigos
Ya que el tema agarro "viada" les alcanzo una presentacion de una conferencia en KM a la cual asisti en el 2006
Claro que sí! Claro que es bueno tener un repositorio, claro que las personas no estarán toda la vida en sus empresas (dímelo a mi que llevo un mes en una empresa nueva ;D ), es imposible predicar que "no hace falta", "no es bueno", gestionar el conocimiento. Esto no quize decir en ningún caso.
Por otro lado, David, en mi caso no hace falta abstraerme para imaginarme ser dueño de una empresa y que necesidades se pueden generar. Hace unos años tuve una con con mi padre, y vivíamos (entre otras mil preocupaciones) eso de que la gente se iba sin dejar nada. Claro que sí entiendo tu punto.
El problema está señores...
Cuando viene alguien que dice saber "gestionar el conocimiento" y quiere vender la idea a ese dueño de empresa, que con implementar un repositorio, prácticas de generación de conocimiento, etc, etc, etc...le promete..."Yo llevaré todo lo implícito a explícito!" y tu empresa ya no dependerá más de las personas, serán reemplazables sin problemas...
Creo que el desconocimiento respecto a esta rama es lo que hace tanto daño...se siente cierta contradicción en decir: "Gestionemos el conocimiento y...dependamos de las personas!" , la gente que siente que esto es contradictorio, es la que le hace daño al tema, y al final, a esa empresa.
Así que quede claro mi punto por favor, la gestión del conocimiento es importante, con la sabiduría de que realmente lo implícito...nunca será explicito al 100%.
En mi experiencia profesional es verdad que los repositorios bien organizados e integrados con el resto de sistemas de la empresa (eg sistema de tickets, bugs, documentos, directorioa de personal, etc) ayudan bastante a compartir conocimientos.
Sin embargo también hay otras maneras más sencillas de mejorar el flujo de conocimiento en la empresa y que deben ser exploradas antes de pasar a implementar un sistema de conocimiento electronicos, ya que quizas basten para los requisitos de la empresa basten otras formas mas sencillas y economicas.
Por ejemplo yo conozco el caso de una empresa grande donde trabaje, done nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran de vidrio. Es más en muchos casos aprendía partes importantes cuando mis colegas y/o jefe hablaban con otros y yo escuchaba las conversacoines del costado. Este diseño de la oficina fomentar los encuentros casuales y el conocimiento compartido entre colegas puede ser muy útil, si es que el modelo del negocio lo permite.Funcionaba bastante bien y no requería mayor inversión en TI.
Saludos, Rafael
2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
Holas!
Añado más ideas para el debate.
Quienes han trabajado bastante con el tema de gestionar conocimiento, entre otros, son las empresas japonesas.
No hay duda que el conocimiento lo tienen sólo las personas! No hay otra forma!
Tampoco hay duda que el conocimiento se comparte de manera eventual e informal, en blogs como este, en conferencias, cuando conversamos en el pasillo o tomamos un café con un colega, o cuando un colega o amigo nos pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto antes? Y le respondemos.
El asunto es (i) cómo hacer que el conocimiento se comparta de manera no sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
Este asunto puede resultas de poca importancia desde el punto de vista profesional individual o como consultores independientes o free lance. No estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora mientras más comparto y sirvo de conexión soy más valioso)
Les animo a que se pongan en los zapatos del accionista o dueño de una empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
La preocupación del gerente o dueño de empresa es ¿Cómo hago que el conocimiento importante para la empresa, se comparta con el resto de colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una empresa adquirimos experiencia gracias a que trabajamos para una empresa, es nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que ese conocimiento se comparta?
Las conclusiones, entre otras, de las empresas japonesas, es pasar el conocimiento implícito (en la cabeza de las personas) a explícito.
Esto se puede hacer de muchas formas y tener un repositorio no es la única ni las más efectiva, pero la que puede tener mayor alcance cuando la empresa tiene muchos colaboradores y/o están en varias ciudades. Hay empresas que tienen 130 mil colaboradores y oficinas en más de 120 países. Hay empresas en Perú con 50 personas en 3 ciudades. Hay empresas que tienen 25 colaboradores y están en 20 países.
En cuanto a la alternativa de tener un repositorio, está claro que no es suficiente guardar información en algún lugar para convertirlo en conocimiento explícito.
Para convertirlo en conocimiento explícito, se requiere:
. Que alguien (puede ser la misma persona) evalúe si ese conocimiento será de valor en otros casos
. Identificar el contenido a compartir
. Agregar al contenido a compartir, ideas que no están escritas y están en nuestra cabeza. Por ejemplo, en cuál contexto se usó ese conocimiento.
. Que alguien le de forma, es decir agregar datos que permitan accesar, clasificar a esa información (por ejemplo, por dominio, por profesión, entre otras formas)
. Publicar esa información
. Difundir que esa información está publicada y asegurar que llega a los posibles usuarios que le van a ver valor
. Mantener actualizada dicha información
. Dar de baja a información obsoleta o que ya no es correcta
. Hacer que las personas que tienen conocimiento o experiencia compartan su información, como parte del proceso, como parte de la retrospectiva de cualquier iteración, proyecto, tarea, servicio u operación.
El medio para esto es cualquier herramienta de manejo de contenidos, inclusive directorios compartidos!
Tener un repositorio no es la única forma de pasar conocimiento implícito a explícito en una organización. Pero es importante en muchos contextos.
He tenido la oportunidad de trabajar en empresas grandes y pequeñas que tenían dicho repositorio o base de datos de conocimiento. No tengo duda que eso es patrimonio de la empresa.
Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, proponer una solución y realizar una implementación exitosa usando la información en dicho repositorio, información que fue almacenada por dos proyectos ejecutados en Italia, jamás hablé con las personas de dichos proyectos en Italia, no sé hablar italiano, la información que almacenaron estaba en inglés y cuando hice la búsqueda pude ubicar la información que necesitaba. La información estaba guardada cumpliendo los requisitos anteriores: pude ubicarla, había información de contexto, habías recomendaciones, etc. además del contenido. No tengo duda que usé conocimiento generado por otras personas. Es decir cómo hacer algo, la técnica, el método. Yo necesitaba una solución relativamente similar.
Ese tema es interesante no lo metí por el tema que creo que va mas allá de Agile y no hay espacio para eso al menos aquí en Perú. Si se puede, pues seria bueno como tema de la siguiente reunion Agile. Hasta me presto para moderarla esos temas son bastante emocionantes y mejor en persona.
Under the Dilbert Principle, an incompetent computer programmer would be "promoted" out of his or her department in order to allow other competent programmers an opportunity to work in peace ---The Dilbert Principle
>> Claro que sí! Claro que es bueno tener un repositorio, claro que las >> personas no estarán toda la vida en sus empresas (dímelo a mi que llevo un >> mes en una empresa nueva ;D ), es imposible predicar que "no hace falta", >> "no es bueno", gestionar el conocimiento. Esto no quize decir en ningún >> caso.
>> Por otro lado, David, en mi caso no hace falta abstraerme para imaginarme >> ser dueño de una empresa y que necesidades se pueden generar. Hace unos años >> tuve una con con mi padre, y vivíamos (entre otras mil preocupaciones) eso >> de que la gente se iba sin dejar nada. Claro que sí entiendo tu punto.
>> El problema está señores...
>> Cuando viene alguien que dice saber "gestionar el conocimiento" y quiere >> vender la idea a ese dueño de empresa, que con implementar un repositorio, >> prácticas de generación de conocimiento, etc, etc, etc...le promete..."Yo >> llevaré todo lo implícito a explícito!" y tu empresa ya no dependerá más de >> las personas, serán reemplazables sin problemas...
>> Creo que el desconocimiento respecto a esta rama es lo que hace tanto >> daño...se siente cierta contradicción en decir:* "Gestionemos el >> conocimiento y...dependamos de las personas!"* , la gente que siente que >> esto es contradictorio, es la que le hace daño al tema, y al final, a esa >> empresa.
>> Así que quede claro mi punto por favor, la gestión del conocimiento es >> importante, con la sabiduría de que realmente lo implícito...nunca será >> explicito al 100%.
>> En mi experiencia profesional es verdad que los repositorios bien >>> organizados e* integrados* con el resto de sistemas de la empresa (eg >>> sistema de tickets, bugs, documentos, directorioa de personal, etc) ayudan >>> bastante a compartir conocimientos.
>>> Sin embargo también hay otras maneras más sencillas de mejorar el flujo >>> de conocimiento en la empresa y que deben ser exploradas antes de pasar a >>> implementar un sistema de conocimiento electronicos, ya que quizas basten >>> para los requisitos de la empresa basten otras formas mas sencillas y >>> economicas.
>>> Por ejemplo yo conozco el caso de una empresa grande donde trabaje, done >>> nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran de >>> vidrio. Es más en muchos casos aprendía partes importantes cuando mis >>> colegas y/o jefe hablaban con otros y yo escuchaba las conversacoines del >>> costado. Este diseño de la oficina fomentar los encuentros casuales y el >>> conocimiento compartido entre colegas puede ser muy útil, si es que el >>> modelo del negocio lo permite.Funcionaba bastante bien y no requería mayor >>> inversión en TI.
>>> Saludos, >>> Rafael
>>> 2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
>>>> Holas!
>>>> Añado más ideas para el debate.
>>>> Quienes han trabajado bastante con el tema de gestionar conocimiento, >>>> entre otros, son las empresas japonesas.
>>>> No hay duda que el conocimiento lo tienen sólo las personas! No hay otra >>>> forma!
>>>> Tampoco hay duda que el conocimiento se comparte de manera eventual e >>>> informal, en blogs como este, en conferencias, cuando conversamos en el >>>> pasillo o tomamos un café con un colega, o cuando un colega o amigo nos >>>> pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto >>>> antes? Y le respondemos.
>>>> El asunto es (i) cómo hacer que el conocimiento se comparta de manera no >>>> sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
>>>> Este asunto puede resultas de poca importancia desde el punto de vista >>>> profesional individual o como consultores independientes o free lance. No >>>> estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana >>>> (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de >>>> mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora >>>> mientras más comparto y sirvo de conexión soy más valioso)
>>>> Les animo a que se pongan en los zapatos del accionista o dueño de una >>>> empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
>>>> La preocupación del gerente o dueño de empresa es ¿Cómo hago que el >>>> conocimiento *importante* para la empresa, se comparta con el resto de >>>> colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, >>>> etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una >>>> empresa adquirimos experiencia gracias a que trabajamos para una empresa, es >>>> nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que >>>> ese conocimiento se comparta?
>>>> Las conclusiones, entre otras, de las empresas japonesas, es pasar el >>>> conocimiento implícito (en la cabeza de las personas) a explícito.
>>>> Esto se puede hacer de muchas formas y tener un repositorio no es la >>>> única ni las más efectiva, pero la que puede tener mayor alcance cuando la >>>> empresa tiene muchos colaboradores y/o están en varias ciudades. Hay >>>> empresas que tienen 130 mil colaboradores y oficinas en más de 120 países. >>>> Hay empresas en Perú con 50 personas en 3 ciudades. Hay empresas que tienen >>>> 25 colaboradores y están en 20 países.
>>>> En cuanto a la alternativa de tener un repositorio, está claro que no es >>>> suficiente guardar información en algún lugar para convertirlo en >>>> conocimiento explícito.
>>>> Para convertirlo en conocimiento explícito, se requiere:
>>>> . Que alguien (puede ser la misma persona) evalúe si ese conocimiento >>>> será de valor en otros casos
>>>> . Identificar el contenido a compartir
>>>> . Agregar al contenido a compartir, ideas que no están escritas y están >>>> en nuestra cabeza. Por ejemplo, en cuál contexto se usó ese conocimiento.
>>>> . Que alguien le de forma, es decir agregar datos que permitan accesar, >>>> clasificar a esa información (por ejemplo, por dominio, por profesión, entre >>>> otras formas)
>>>> . Publicar esa información
>>>> . Difundir que esa información está publicada y asegurar que llega a los >>>> posibles usuarios que le van a ver valor
>>>> . Mantener actualizada dicha información
>>>> . Dar de baja a información obsoleta o que ya no es correcta
>>>> . Hacer que las personas que tienen conocimiento o experiencia compartan >>>> su información, como parte del proceso, como parte de la retrospectiva de >>>> cualquier iteración, proyecto, tarea, servicio u operación.
>>>> El medio para esto es cualquier herramienta de manejo de contenidos, >>>> inclusive directorios compartidos!
>>>> Tener un repositorio no es la única forma de pasar conocimiento >>>> implícito a explícito en una organización. Pero es importante en muchos >>>> contextos.
>>>> He tenido la oportunidad de trabajar en empresas grandes y pequeñas que >>>> tenían dicho repositorio o base de datos de conocimiento. No tengo duda que >>>> eso es patrimonio de la empresa.
>>>> Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, >>>> proponer una solución y realizar una implementación exitosa usando la >>>> información en dicho repositorio, información que fue almacenada por dos >>>> proyectos ejecutados en Italia, jamás hablé con las personas de dichos >>>> proyectos en Italia, no sé hablar italiano, la información que almacenaron >>>> estaba en inglés y cuando hice la búsqueda pude ubicar la información que >>>> necesitaba. La información estaba guardada cumpliendo los requisitos >>>> anteriores: pude ubicarla, había información de contexto, habías >>>> recomendaciones, etc. además del contenido. No tengo duda que usé >>>> conocimiento generado por otras personas. Es decir cómo hacer algo, la >>>> técnica, el método. Yo necesitaba una solución relativamente similar.
>>>> "This e-mail message is for the sole use of the intended recipient(s) >>>> and may contain confidential and/or privileged information. Any unauthorized >>>> review, use, disclosure or distribution is prohibited. If you are not the >>>> intended recipient, please contact the sender by reply e-mail and destroy >>>> all copies of the original message."
>>>> "Este correo electrónico es para uso exclusivo del receptor(es) a >>>> quien(es) se envió y puede contener información confidencial o privilegiada. >>>> Cualquier revisión, uso,
Hola Gustavo, a los tiempos!... bueno la idea es ver como Agile ayudan a la *gestion *del conocimiento (creo que ya esta claro que Scrum, y cualquier otra metodologias agile, ayuda, y mucho, a la *creacion *del conocimiento) pues parece que es un tema un poco "flojo" en los ambientes agiles.
Atte,
Deusdit Correa Cornejo (@neodacc) MBA Student / IT Director / Certified ScrumMaster / Agile Coach
> Ese tema es interesante no lo metí por el tema que creo que va mas allá de > Agile y no hay espacio para eso al menos aquí en Perú. Si se puede, pues > seria bueno como tema de la siguiente reunion Agile. Hasta me presto para > moderarla esos temas son bastante emocionantes y mejor en persona.
> Under the Dilbert Principle, an incompetent computer programmer would be > "promoted" out of his or her department in order to allow other competent > programmers an opportunity to work in peace > ---The Dilbert Principle
>>> Claro que sí! Claro que es bueno tener un repositorio, claro que las >>> personas no estarán toda la vida en sus empresas (dímelo a mi que llevo un >>> mes en una empresa nueva ;D ), es imposible predicar que "no hace falta", >>> "no es bueno", gestionar el conocimiento. Esto no quize decir en ningún >>> caso.
>>> Por otro lado, David, en mi caso no hace falta abstraerme para imaginarme >>> ser dueño de una empresa y que necesidades se pueden generar. Hace unos años >>> tuve una con con mi padre, y vivíamos (entre otras mil preocupaciones) eso >>> de que la gente se iba sin dejar nada. Claro que sí entiendo tu punto.
>>> El problema está señores...
>>> Cuando viene alguien que dice saber "gestionar el conocimiento" y quiere >>> vender la idea a ese dueño de empresa, que con implementar un repositorio, >>> prácticas de generación de conocimiento, etc, etc, etc...le promete..."Yo >>> llevaré todo lo implícito a explícito!" y tu empresa ya no dependerá más de >>> las personas, serán reemplazables sin problemas...
>>> Creo que el desconocimiento respecto a esta rama es lo que hace tanto >>> daño...se siente cierta contradicción en decir:* "Gestionemos el >>> conocimiento y...dependamos de las personas!"* , la gente que siente que >>> esto es contradictorio, es la que le hace daño al tema, y al final, a esa >>> empresa.
>>> Así que quede claro mi punto por favor, la gestión del conocimiento es >>> importante, con la sabiduría de que realmente lo implícito...nunca será >>> explicito al 100%.
>>> En mi experiencia profesional es verdad que los repositorios bien >>>> organizados e* integrados* con el resto de sistemas de la empresa (eg >>>> sistema de tickets, bugs, documentos, directorioa de personal, etc) ayudan >>>> bastante a compartir conocimientos.
>>>> Sin embargo también hay otras maneras más sencillas de mejorar el flujo >>>> de conocimiento en la empresa y que deben ser exploradas antes de pasar a >>>> implementar un sistema de conocimiento electronicos, ya que quizas basten >>>> para los requisitos de la empresa basten otras formas mas sencillas y >>>> economicas.
>>>> Por ejemplo yo conozco el caso de una empresa grande donde trabaje, done >>>> nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran de >>>> vidrio. Es más en muchos casos aprendía partes importantes cuando mis >>>> colegas y/o jefe hablaban con otros y yo escuchaba las conversacoines del >>>> costado. Este diseño de la oficina fomentar los encuentros casuales y el >>>> conocimiento compartido entre colegas puede ser muy útil, si es que el >>>> modelo del negocio lo permite.Funcionaba bastante bien y no requería mayor >>>> inversión en TI.
>>>> Saludos, >>>> Rafael
>>>> 2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
>>>>> Holas!
>>>>> Añado más ideas para el debate.
>>>>> Quienes han trabajado bastante con el tema de gestionar conocimiento, >>>>> entre otros, son las empresas japonesas.
>>>>> No hay duda que el conocimiento lo tienen sólo las personas! No hay >>>>> otra forma!
>>>>> Tampoco hay duda que el conocimiento se comparte de manera eventual e >>>>> informal, en blogs como este, en conferencias, cuando conversamos en el >>>>> pasillo o tomamos un café con un colega, o cuando un colega o amigo nos >>>>> pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto >>>>> antes? Y le respondemos.
>>>>> El asunto es (i) cómo hacer que el conocimiento se comparta de manera >>>>> no sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
>>>>> Este asunto puede resultas de poca importancia desde el punto de vista >>>>> profesional individual o como consultores independientes o free lance. No >>>>> estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana >>>>> (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de >>>>> mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora >>>>> mientras más comparto y sirvo de conexión soy más valioso)
>>>>> Les animo a que se pongan en los zapatos del accionista o dueño de una >>>>> empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
>>>>> La preocupación del gerente o dueño de empresa es ¿Cómo hago que el >>>>> conocimiento *importante* para la empresa, se comparta con el resto de >>>>> colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, >>>>> etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una >>>>> empresa adquirimos experiencia gracias a que trabajamos para una empresa, es >>>>> nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que >>>>> ese conocimiento se comparta?
>>>>> Las conclusiones, entre otras, de las empresas japonesas, es pasar el >>>>> conocimiento implícito (en la cabeza de las personas) a explícito.
>>>>> Esto se puede hacer de muchas formas y tener un repositorio no es la >>>>> única ni las más efectiva, pero la que puede tener mayor alcance cuando la >>>>> empresa tiene muchos colaboradores y/o están en varias ciudades. Hay >>>>> empresas que tienen 130 mil colaboradores y oficinas en más de 120 países. >>>>> Hay empresas en Perú con 50 personas en 3 ciudades. Hay empresas que tienen >>>>> 25 colaboradores y están en 20 países.
>>>>> En cuanto a la alternativa de tener un repositorio, está claro que no >>>>> es suficiente guardar información en algún lugar para convertirlo en >>>>> conocimiento explícito.
>>>>> Para convertirlo en conocimiento explícito, se requiere:
>>>>> . Que alguien (puede ser la misma persona) evalúe si ese conocimiento >>>>> será de valor en otros casos
>>>>> . Identificar el contenido a compartir
>>>>> . Agregar al contenido a compartir, ideas que no están escritas y están >>>>> en nuestra cabeza. Por ejemplo, en cuál contexto se usó ese conocimiento.
>>>>> . Que alguien le de forma, es decir agregar datos que permitan accesar, >>>>> clasificar a esa información (por ejemplo, por dominio, por profesión, entre >>>>> otras formas)
>>>>> . Publicar esa información
>>>>> . Difundir que esa información está publicada y asegurar que llega a >>>>> los posibles usuarios que le van a ver valor
>>>>> . Mantener actualizada dicha información
>>>>> . Dar de baja a información obsoleta o que ya no es correcta
>>>>> . Hacer que las personas que tienen conocimiento o experiencia >>>>> compartan su información, como parte del proceso, como parte de la >>>>> retrospectiva de cualquier iteración, proyecto, tarea, servicio u operación.
>>>>> El medio para esto es cualquier herramienta de manejo de contenidos, >>>>> inclusive directorios compartidos!
>>>>> Tener un repositorio no es la única forma de pasar conocimiento >>>>> implícito a explícito en una organización. Pero es importante en muchos >>>>> contextos.
>>>>> He tenido la oportunidad de trabajar en empresas grandes y pequeñas que >>>>> tenían dicho repositorio o base de datos de conocimiento. No tengo duda que >>>>> eso es patrimonio de la empresa.
>>>>> Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, >>>>> proponer una solución y realizar una implementación exitosa usando la >>>>> información en dicho repositorio, información que fue almacenada por dos >>>>> proyectos ejecutados en Italia, jamás hablé con las personas de dichos >>>>> proyectos en Italia, no sé hablar italiano, la información que almacenaron >>>>> estaba en inglés y cuando hice la búsqueda pude ubicar la información que >>>>> necesitaba. La información estaba guardada cumpliendo los requisitos >>>>> anteriores: pude ubicarla, había información de contexto, habías >>>>> recomendaciones, etc. además del contenido. No tengo duda que usé >>>>> conocimiento generado por otras personas. Es decir cómo hacer algo, la >>>>> técnica, el método. Yo necesitaba una solución relativamente similar.
De: agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] En nombre de Gustavo Adolfo Veliz Bernaola Enviado el: Miércoles, 03 de Febrero de 2010 05:50 p.m. Para: agileperu@googlegroups.com Asunto: Re: [agileperu] La creacion de conocimiento en Scrum
Ese tema es interesante no lo metí por el tema que creo que va mas allá de Agile y no hay espacio para eso al menos aquí en Perú. Si se puede, pues seria bueno como tema de la siguiente reunion Agile. Hasta me presto para moderarla esos temas son bastante emocionantes y mejor en persona.
Under the Dilbert Principle, an incompetent computer programmer would be "promoted" out of his or her department in order to allow other competent programmers an opportunity to work in peace ---The Dilbert Principle
Claro que sí! Claro que es bueno tener un repositorio, claro que las personas no estarán toda la vida en sus empresas (dímelo a mi que llevo un mes en una empresa nueva ;D ), es imposible predicar que "no hace falta", "no es bueno", gestionar el conocimiento. Esto no quize decir en ningún caso.
Por otro lado, David, en mi caso no hace falta abstraerme para imaginarme ser dueño de una empresa y que necesidades se pueden generar. Hace unos años tuve una con con mi padre, y vivíamos (entre otras mil preocupaciones) eso de que la gente se iba sin dejar nada. Claro que sí entiendo tu punto.
El problema está señores...
Cuando viene alguien que dice saber "gestionar el conocimiento" y quiere vender la idea a ese dueño de empresa, que con implementar un repositorio, prácticas de generación de conocimiento, etc, etc, etc...le promete..."Yo llevaré todo lo implícito a explícito!" y tu empresa ya no dependerá más de las personas, serán reemplazables sin problemas...
Creo que el desconocimiento respecto a esta rama es lo que hace tanto daño...se siente cierta contradicción en decir: "Gestionemos el conocimiento y...dependamos de las personas!" , la gente que siente que esto es contradictorio, es la que le hace daño al tema, y al final, a esa empresa.
Así que quede claro mi punto por favor, la gestión del conocimiento es importante, con la sabiduría de que realmente lo implícito...nunca será explicito al 100%.
En mi experiencia profesional es verdad que los repositorios bien organizados e integrados con el resto de sistemas de la empresa (eg sistema de tickets, bugs, documentos, directorioa de personal, etc) ayudan bastante a compartir conocimientos.
Sin embargo también hay otras maneras más sencillas de mejorar el flujo de conocimiento en la empresa y que deben ser exploradas antes de pasar a implementar un sistema de conocimiento electronicos, ya que quizas basten para los requisitos de la empresa basten otras formas mas sencillas y economicas.
Por ejemplo yo conozco el caso de una empresa grande donde trabaje, done nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran de vidrio. Es más en muchos casos aprendía partes importantes cuando mis colegas y/o jefe hablaban con otros y yo escuchaba las conversacoines del costado. Este diseño de la oficina fomentar los encuentros casuales y el conocimiento compartido entre colegas puede ser muy útil, si es que el modelo del negocio lo permite.Funcionaba bastante bien y no requería mayor inversión en TI.
Saludos, Rafael
2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
Holas!
Añado más ideas para el debate.
Quienes han trabajado bastante con el tema de gestionar conocimiento, entre otros, son las empresas japonesas.
No hay duda que el conocimiento lo tienen sólo las personas! No hay otra forma!
Tampoco hay duda que el conocimiento se comparte de manera eventual e informal, en blogs como este, en conferencias, cuando conversamos en el pasillo o tomamos un café con un colega, o cuando un colega o amigo nos pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto antes? Y le respondemos.
El asunto es (i) cómo hacer que el conocimiento se comparta de manera no sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
Este asunto puede resultas de poca importancia desde el punto de vista profesional individual o como consultores independientes o free lance. No estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora mientras más comparto y sirvo de conexión soy más valioso)
Les animo a que se pongan en los zapatos del accionista o dueño de una empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
La preocupación del gerente o dueño de empresa es ¿Cómo hago que el conocimiento importante para la empresa, se comparta con el resto de colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una empresa adquirimos experiencia gracias a que trabajamos para una empresa, es nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que ese conocimiento se comparta?
Las conclusiones, entre otras, de las empresas japonesas, es pasar el conocimiento implícito (en la cabeza de las personas) a explícito.
Esto se puede hacer de muchas formas y tener un repositorio no es la única ni las más efectiva, pero la que puede tener mayor alcance cuando la empresa tiene muchos colaboradores y/o están en varias ciudades. Hay empresas que tienen 130 mil colaboradores y oficinas en más de 120 países. Hay empresas en Perú con 50 personas en 3 ciudades. Hay empresas que tienen 25 colaboradores y están en 20 países.
En cuanto a la alternativa de tener un repositorio, está claro que no es suficiente guardar información en algún lugar para convertirlo en conocimiento explícito.
Para convertirlo en conocimiento explícito, se requiere:
. Que alguien (puede ser la misma persona) evalúe si ese conocimiento será de valor en otros casos
. Identificar el contenido a compartir
. Agregar al contenido a compartir, ideas que no están escritas y están en nuestra cabeza. Por ejemplo, en cuál contexto se usó ese conocimiento.
. Que alguien le de forma, es decir agregar datos que permitan accesar, clasificar a esa información (por ejemplo, por dominio, por profesión, entre otras formas)
. Publicar esa información
. Difundir que esa información está publicada y asegurar que llega a los posibles usuarios que le van a ver valor
. Mantener actualizada dicha información
. Dar de baja a información obsoleta o que ya no es correcta
. Hacer que las personas que tienen conocimiento o experiencia compartan su información, como parte del proceso, como parte de la retrospectiva de cualquier iteración, proyecto, tarea, servicio u operación.
El medio para esto es cualquier herramienta de manejo de contenidos, inclusive directorios compartidos!
Tener un repositorio no es la única forma de pasar conocimiento implícito a explícito en una organización. Pero es importante en muchos contextos.
He tenido la oportunidad de trabajar en empresas grandes y pequeñas que tenían dicho repositorio o base de datos de conocimiento. No tengo duda que eso es patrimonio de la empresa.
Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, proponer una solución y realizar una implementación exitosa usando la información en dicho repositorio, información que fue almacenada por dos proyectos ejecutados en Italia, jamás hablé con las personas de dichos proyectos en Italia, no sé hablar italiano, la información que almacenaron estaba en inglés y cuando hice la búsqueda pude ubicar la información que necesitaba. La información estaba guardada cumpliendo los requisitos anteriores: pude ubicarla, había información de contexto, habías recomendaciones, etc. además del contenido. No tengo duda que usé conocimiento generado por otras personas. Es decir cómo hacer algo, la técnica, el método. Yo necesitaba una solución relativamente similar.
"This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message."
"Este correo electrónico es para uso exclusivo del receptor(es) a quien(es) se envió y puede contener información confidencial o privilegiada. Cualquier revisión, uso, difusión o distribución no autorizada está prohibido. Si usted no es el receptor a quien se envió este correo electrónico y su contenido, por favor, adviértalo a quien le envío el correo electrónico contestando el correo y destruyendo todas las copias del mensaje original."
_____
De: agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] En nombre de Raul Uribe Enviado el: Wednesday, 03
...
> *De:* agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] *En > nombre de *Gustavo Adolfo Veliz Bernaola > *Enviado el:* Miércoles, 03 de Febrero de 2010 05:50 p.m.
> *Para:* agileperu@googlegroups.com > *Asunto:* Re: [agileperu] La creacion de conocimiento en Scrum
> Ese tema es interesante no lo metí por el tema que creo que va mas allá de > Agile y no hay espacio para eso al menos aquí en Perú. Si se puede, pues > seria bueno como tema de la siguiente reunion Agile. Hasta me presto para > moderarla esos temas son bastante emocionantes y mejor en persona.
> Under the Dilbert Principle, an incompetent computer programmer would be > "promoted" out of his or her department in order to allow other competent > programmers an opportunity to work in peace > ---The Dilbert Principle
> Claro que sí! Claro que es bueno tener un repositorio, claro que las > personas no estarán toda la vida en sus empresas (dímelo a mi que llevo un > mes en una empresa nueva ;D ), es imposible predicar que "no hace falta", > "no es bueno", gestionar el conocimiento. Esto no quize decir en ningún > caso.
> Por otro lado, David, en mi caso no hace falta abstraerme para imaginarme > ser dueño de una empresa y que necesidades se pueden generar. Hace unos años > tuve una con con mi padre, y vivíamos (entre otras mil preocupaciones) eso > de que la gente se iba sin dejar nada. Claro que sí entiendo tu punto.
> El problema está señores...
> Cuando viene alguien que dice saber "gestionar el conocimiento" y quiere > vender la idea a ese dueño de empresa, que con implementar un repositorio, > prácticas de generación de conocimiento, etc, etc, etc...le promete..."Yo > llevaré todo lo implícito a explícito!" y tu empresa ya no dependerá más de > las personas, serán reemplazables sin problemas...
> Creo que el desconocimiento respecto a esta rama es lo que hace tanto > daño...se siente cierta contradicción en decir:* "Gestionemos el > conocimiento y...dependamos de las personas!"* , la gente que siente que > esto es contradictorio, es la que le hace daño al tema, y al final, a esa > empresa.
> Así que quede claro mi punto por favor, la gestión del conocimiento es > importante, con la sabiduría de que realmente lo implícito...nunca será > explicito al 100%.
> En mi experiencia profesional es verdad que los repositorios bien > organizados e* integrados* con el resto de sistemas de la empresa (eg > sistema de tickets, bugs, documentos, directorioa de personal, etc) ayudan > bastante a compartir conocimientos.
> Sin embargo también hay otras maneras más sencillas de mejorar el flujo de > conocimiento en la empresa y que deben ser exploradas antes de pasar a > implementar un sistema de conocimiento electronicos, ya que quizas basten > para los requisitos de la empresa basten otras formas mas sencillas y > economicas.
> Por ejemplo yo conozco el caso de una empresa grande donde trabaje, done > nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran de > vidrio. Es más en muchos casos aprendía partes importantes cuando mis > colegas y/o jefe hablaban con otros y yo escuchaba las conversacoines del > costado. Este diseño de la oficina fomentar los encuentros casuales y el > conocimiento compartido entre colegas puede ser muy útil, si es que el > modelo del negocio lo permite.Funcionaba bastante bien y no requería mayor > inversión en TI.
> Saludos, > Rafael
> 2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
> Holas!
> Añado más ideas para el debate.
> Quienes han trabajado bastante con el tema de gestionar conocimiento, entre > otros, son las empresas japonesas.
> No hay duda que el conocimiento lo tienen sólo las personas! No hay otra > forma!
> Tampoco hay duda que el conocimiento se comparte de manera eventual e > informal, en blogs como este, en conferencias, cuando conversamos en el > pasillo o tomamos un café con un colega, o cuando un colega o amigo nos > pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto > antes? Y le respondemos.
> El asunto es (i) cómo hacer que el conocimiento se comparta de manera no > sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
> Este asunto puede resultas de poca importancia desde el punto de vista > profesional individual o como consultores independientes o free lance. No > estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana > (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de > mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora > mientras más comparto y sirvo de conexión soy más valioso)
> Les animo a que se pongan en los zapatos del accionista o dueño de una > empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
> La preocupación del gerente o dueño de empresa es ¿Cómo hago que el > conocimiento *importante* para la empresa, se comparta con el resto de > colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, > etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una > empresa adquirimos experiencia gracias a que trabajamos para una empresa, es > nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que > ese conocimiento se comparta?
> Las conclusiones, entre otras, de las empresas japonesas, es pasar el > conocimiento implícito (en la cabeza de las personas) a explícito.
> Esto se puede hacer de muchas formas y tener un repositorio no es la única > ni las más efectiva, pero la que puede tener mayor alcance cuando la empresa > tiene muchos colaboradores y/o están en varias ciudades. Hay empresas que > tienen 130 mil colaboradores y oficinas en más de 120 países. Hay empresas > en Perú con 50 personas en 3 ciudades. Hay empresas que tienen 25 > colaboradores y están en 20 países.
> En cuanto a la alternativa de tener un repositorio, está claro que no es > suficiente guardar información en algún lugar para convertirlo en > conocimiento explícito.
> Para convertirlo en conocimiento explícito, se requiere:
> . Que alguien (puede ser la misma persona) evalúe si ese conocimiento será > de valor en otros casos
> . Identificar el contenido a compartir
> . Agregar al contenido a compartir, ideas que no están escritas y están en > nuestra cabeza. Por ejemplo, en cuál contexto se usó ese conocimiento.
> . Que alguien le de forma, es decir agregar datos que permitan accesar, > clasificar a esa información (por ejemplo, por dominio, por profesión, entre > otras formas)
> . Publicar esa información
> . Difundir que esa información está publicada y asegurar que llega a los > posibles usuarios que le van a ver valor
> . Mantener actualizada dicha información
> . Dar de baja a información obsoleta o que ya no es correcta
> . Hacer que las personas que tienen conocimiento o experiencia compartan su > información, como parte del proceso, como parte de la retrospectiva de > cualquier iteración, proyecto, tarea, servicio u operación.
> El medio para esto es cualquier herramienta de manejo de contenidos, > inclusive directorios compartidos!
> Tener un repositorio no es la única forma de pasar conocimiento implícito a > explícito en una organización. Pero es importante en muchos contextos.
> He tenido la oportunidad de trabajar en empresas grandes y pequeñas que > tenían dicho repositorio o base de datos de conocimiento. No tengo duda que > eso es patrimonio de la empresa.
> Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, proponer > una solución y realizar una implementación exitosa usando la información en > dicho repositorio, información que fue almacenada por dos proyectos > ejecutados en Italia, jamás hablé con las personas de dichos proyectos en > Italia, no sé hablar italiano, la información que almacenaron estaba en > inglés y cuando hice la búsqueda pude ubicar la información que necesitaba. > La información estaba guardada cumpliendo los requisitos anteriores: pude > ubicarla, había información de contexto, habías recomendaciones, etc. además > del contenido. No tengo duda que usé conocimiento generado por otras > personas. Es decir cómo hacer algo, la técnica, el método. Yo necesitaba una > solución relativamente similar.
> "This e-mail message is for the sole use of the intended recipient(s) and > may contain confidential and/or privileged information. Any unauthorized > review, use, disclosure or distribution is
jjejeje gracias muchachos Estoy en las ultimas semanas de un proyecto personal espero esta semana se termine. apuntando a tener mas tiempo y reactivar algunas cosas.
Esta interesante el tema seria bueno apuntar al tercer miércoles de cada mes como era usual. O en el caso que alguien, no pueda pues tomar un fin de semana, debido a que seria bueno tenerlos presente.
El problema es el de siempre el local :(. Como ando desconectado tiempo del mundo agile no se quien nos pueda apoyar con ese tema.
En ese caso prepararía una sesión y sacamos algo sintetizado de esa reunión.
Pero mientras podemos seguir por aquí que no se apague la conversa.
Personalmente concuerdo como mencionan lineas arriba que no se gestiona el conocimiento. Puesto que es una capacidad de adquisición. Es decir desde el nombre ya estamos mal :P. Pero creo que todos sabemos de que hablamos aunque el nombre tal vez no sea el correcto.
Como si puedes administrar información es que la linea tiende mas a las TI porque ayudan a gestionar la información y a tenerla disponible cuando, donde y como se quiere.
También se menciona sobre la generación del conocimiento. Este se genera en base a ensayo y error, vivencias, etc ahi es donde se le encuentra un pedazo de scrum al crear el espacio para la interaccion(vivencias). Me interesa mucho de que tipos de conocimiento que han visto espero se pueda en la reunión.
Ahora por algo surgió el termino no?. David algo como
Les animo a que se pongan en los zapatos del accionista o dueño de una empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
La preocupación del gerente o dueño de empresa es ¿Cómo hago que el conocimiento *importante* para la empresa, se comparta con el resto de colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una empresa adquirimos experiencia gracias a que trabajamos para una empresa, es nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que ese conocimiento se comparta?
Así que si le encontramos una solución a ese problema o nos ponemos en esos zapatos en la reunión podremos tal ves encontrar algo diferente o empezar a usar "gestión de información"
Saludos y exitos!
Deus personamente creo que Agile debe aprender mas gestion de conocimiento de otras areas.
Under the Dilbert Principle, an incompetent computer programmer would be "promoted" out of his or her department in order to allow other competent programmers an opportunity to work in peace ---The Dilbert Principle
>> *De:* agileperu@googlegroups.com [mailto:agileperu@googlegroups.com] *En >> nombre de *Gustavo Adolfo Veliz Bernaola >> *Enviado el:* Miércoles, 03 de Febrero de 2010 05:50 p.m.
>> *Para:* agileperu@googlegroups.com >> *Asunto:* Re: [agileperu] La creacion de conocimiento en Scrum
>> Ese tema es interesante no lo metí por el tema que creo que va mas allá de >> Agile y no hay espacio para eso al menos aquí en Perú. Si se puede, pues >> seria bueno como tema de la siguiente reunion Agile. Hasta me presto para >> moderarla esos temas son bastante emocionantes y mejor en persona.
>> Under the Dilbert Principle, an incompetent computer programmer would be >> "promoted" out of his or her department in order to allow other competent >> programmers an opportunity to work in peace >> ---The Dilbert Principle
>> Claro que sí! Claro que es bueno tener un repositorio, claro que las >> personas no estarán toda la vida en sus empresas (dímelo a mi que llevo un >> mes en una empresa nueva ;D ), es imposible predicar que "no hace falta", >> "no es bueno", gestionar el conocimiento. Esto no quize decir en ningún >> caso.
>> Por otro lado, David, en mi caso no hace falta abstraerme para imaginarme >> ser dueño de una empresa y que necesidades se pueden generar. Hace unos años >> tuve una con con mi padre, y vivíamos (entre otras mil preocupaciones) eso >> de que la gente se iba sin dejar nada. Claro que sí entiendo tu punto.
>> El problema está señores...
>> Cuando viene alguien que dice saber "gestionar el conocimiento" y quiere >> vender la idea a ese dueño de empresa, que con implementar un repositorio, >> prácticas de generación de conocimiento, etc, etc, etc...le promete..."Yo >> llevaré todo lo implícito a explícito!" y tu empresa ya no dependerá más de >> las personas, serán reemplazables sin problemas...
>> Creo que el desconocimiento respecto a esta rama es lo que hace tanto >> daño...se siente cierta contradicción en decir:* "Gestionemos el >> conocimiento y...dependamos de las personas!"* , la gente que siente que >> esto es contradictorio, es la que le hace daño al tema, y al final, a esa >> empresa.
>> Así que quede claro mi punto por favor, la gestión del conocimiento es >> importante, con la sabiduría de que realmente lo implícito...nunca será >> explicito al 100%.
>> En mi experiencia profesional es verdad que los repositorios bien >> organizados e* integrados* con el resto de sistemas de la empresa (eg >> sistema de tickets, bugs, documentos, directorioa de personal, etc) ayudan >> bastante a compartir conocimientos.
>> Sin embargo también hay otras maneras más sencillas de mejorar el flujo de >> conocimiento en la empresa y que deben ser exploradas antes de pasar a >> implementar un sistema de conocimiento electronicos, ya que quizas basten >> para los requisitos de la empresa basten otras formas mas sencillas y >> economicas.
>> Por ejemplo yo conozco el caso de una empresa grande donde trabaje, done >> nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran de >> vidrio. Es más en muchos casos aprendía partes importantes cuando mis >> colegas y/o jefe hablaban con otros y yo escuchaba las conversacoines del >> costado. Este diseño de la oficina fomentar los encuentros casuales y el >> conocimiento compartido entre colegas puede ser muy útil, si es que el >> modelo del negocio lo permite.Funcionaba bastante bien y no requería mayor >> inversión en TI.
>> Saludos, >> Rafael
>> 2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
>> Holas!
>> Añado más ideas para el debate.
>> Quienes han trabajado bastante con el tema de gestionar conocimiento, >> entre otros, son las empresas japonesas.
>> No hay duda que el conocimiento lo tienen sólo las personas! No hay otra >> forma!
>> Tampoco hay duda que el conocimiento se comparte de manera eventual e >> informal, en blogs como este, en conferencias, cuando conversamos en el >> pasillo o tomamos un café con un colega, o cuando un colega o amigo nos >> pregunta de manera directa y explícita sabes cómo hacer esto? Has hecho esto >> antes? Y le respondemos.
>> El asunto es (i) cómo hacer que el conocimiento se comparta de manera no >> sólo informal y (ii) cómo hacer que se comparta en las organizaciones.
>> Este asunto puede resultas de poca importancia desde el punto de vista >> profesional individual o como consultores independientes o free lance. No >> estamos obligados, quizás no tenemos interés, o lo hacemos de buena gana >> (Este es otro tema muy interesante, en mi opinión el paradigma obsoleto de >> mientras más conocimiento tengo soy más valioso, ya no es vigente, ahora >> mientras más comparto y sirvo de conexión soy más valioso)
>> Les animo a que se pongan en los zapatos del accionista o dueño de una >> empresa. Si ustedes con dueños de una empresa, donde tienen n colaboradores.
>> La preocupación del gerente o dueño de empresa es ¿Cómo hago que el >> conocimiento *importante* para la empresa, se comparta con el resto de >> colegas? Y así disminuyamos frustraciones, errores, re-trabajo negativo, >> etc. Es bueno evitar errores innecesarios! Cuando como colaboradores de una >> empresa adquirimos experiencia gracias a que trabajamos para una empresa, es >> nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para que >> ese conocimiento se comparta?
>> Las conclusiones, entre otras, de las empresas japonesas, es pasar el >> conocimiento implícito (en la cabeza de las personas) a explícito.
>> Esto se puede hacer de muchas formas y tener un repositorio no es la única >> ni las más efectiva, pero la que puede tener mayor alcance cuando la empresa >> tiene muchos colaboradores y/o están en varias ciudades. Hay empresas que >> tienen 130 mil colaboradores y oficinas en más de 120 países. Hay empresas >> en Perú con 50 personas en 3
On 2/3/10, Deusdit Correa Cornejo <neod...@gmail.com> wrote:
> Hola Gustavo, a los tiempos!... bueno la idea es ver como Agile ayudan a la > *gestion *del conocimiento (creo que ya esta claro que Scrum, y cualquier > otra metodologias agile, ayuda, y mucho, a la *creacion *del conocimiento) > pues parece que es un tema un poco "flojo" en los ambientes agiles.
Muy buen, creo que ahora has dicho todo lo que es mas concreto acerca de KM y Agile.
>> Ese tema es interesante no lo metí por el tema que creo que va mas allá de >> Agile y no hay espacio para eso al menos aquí en Perú. Si se puede, pues >> seria bueno como tema de la siguiente reunion Agile. Hasta me presto para >> moderarla esos temas son bastante emocionantes y mejor en persona.
>> Under the Dilbert Principle, an incompetent computer programmer would be >> "promoted" out of his or her department in order to allow other competent >> programmers an opportunity to work in peace >> ---The Dilbert Principle
>>>> Claro que sí! Claro que es bueno tener un repositorio, claro que las >>>> personas no estarán toda la vida en sus empresas (dímelo a mi que llevo >>>> un >>>> mes en una empresa nueva ;D ), es imposible predicar que "no hace >>>> falta", >>>> "no es bueno", gestionar el conocimiento. Esto no quize decir en ningún >>>> caso.
>>>> Por otro lado, David, en mi caso no hace falta abstraerme para >>>> imaginarme >>>> ser dueño de una empresa y que necesidades se pueden generar. Hace unos >>>> años >>>> tuve una con con mi padre, y vivíamos (entre otras mil preocupaciones) >>>> eso >>>> de que la gente se iba sin dejar nada. Claro que sí entiendo tu punto.
>>>> El problema está señores...
>>>> Cuando viene alguien que dice saber "gestionar el conocimiento" y quiere >>>> vender la idea a ese dueño de empresa, que con implementar un >>>> repositorio, >>>> prácticas de generación de conocimiento, etc, etc, etc...le >>>> promete..."Yo >>>> llevaré todo lo implícito a explícito!" y tu empresa ya no dependerá más >>>> de >>>> las personas, serán reemplazables sin problemas...
>>>> Creo que el desconocimiento respecto a esta rama es lo que hace tanto >>>> daño...se siente cierta contradicción en decir:* "Gestionemos el >>>> conocimiento y...dependamos de las personas!"* , la gente que siente que >>>> esto es contradictorio, es la que le hace daño al tema, y al final, a >>>> esa >>>> empresa.
>>>> Así que quede claro mi punto por favor, la gestión del conocimiento es >>>> importante, con la sabiduría de que realmente lo implícito...nunca será >>>> explicito al 100%.
>>>> En mi experiencia profesional es verdad que los repositorios bien >>>>> organizados e* integrados* con el resto de sistemas de la empresa (eg >>>>> sistema de tickets, bugs, documentos, directorioa de personal, etc) >>>>> ayudan >>>>> bastante a compartir conocimientos.
>>>>> Sin embargo también hay otras maneras más sencillas de mejorar el flujo >>>>> de conocimiento en la empresa y que deben ser exploradas antes de pasar >>>>> a >>>>> implementar un sistema de conocimiento electronicos, ya que quizas >>>>> basten >>>>> para los requisitos de la empresa basten otras formas mas sencillas y >>>>> economicas.
>>>>> Por ejemplo yo conozco el caso de una empresa grande donde trabaje, >>>>> done >>>>> nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran de >>>>> vidrio. Es más en muchos casos aprendía partes importantes cuando mis >>>>> colegas y/o jefe hablaban con otros y yo escuchaba las conversacoines >>>>> del >>>>> costado. Este diseño de la oficina fomentar los encuentros casuales y >>>>> el >>>>> conocimiento compartido entre colegas puede ser muy útil, si es que el >>>>> modelo del negocio lo permite.Funcionaba bastante bien y no requería >>>>> mayor >>>>> inversión en TI.
>>>>> Saludos, >>>>> Rafael
>>>>> 2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
>>>>>> Holas!
>>>>>> Añado más ideas para el debate.
>>>>>> Quienes han trabajado bastante con el tema de gestionar conocimiento, >>>>>> entre otros, son las empresas japonesas.
>>>>>> No hay duda que el conocimiento lo tienen sólo las personas! No hay >>>>>> otra forma!
>>>>>> Tampoco hay duda que el conocimiento se comparte de manera eventual e >>>>>> informal, en blogs como este, en conferencias, cuando conversamos en >>>>>> el >>>>>> pasillo o tomamos un café con un colega, o cuando un colega o amigo >>>>>> nos >>>>>> pregunta de manera directa y explícita sabes cómo hacer esto? Has >>>>>> hecho esto >>>>>> antes? Y le respondemos.
>>>>>> El asunto es (i) cómo hacer que el conocimiento se comparta de manera >>>>>> no sólo informal y (ii) cómo hacer que se comparta en las >>>>>> organizaciones.
>>>>>> Este asunto puede resultas de poca importancia desde el punto de vista >>>>>> profesional individual o como consultores independientes o free lance. >>>>>> No >>>>>> estamos obligados, quizás no tenemos interés, o lo hacemos de buena >>>>>> gana >>>>>> (Este es otro tema muy interesante, en mi opinión el paradigma >>>>>> obsoleto de >>>>>> mientras más conocimiento tengo soy más valioso, ya no es vigente, >>>>>> ahora >>>>>> mientras más comparto y sirvo de conexión soy más valioso)
>>>>>> Les animo a que se pongan en los zapatos del accionista o dueño de una >>>>>> empresa. Si ustedes con dueños de una empresa, donde tienen n >>>>>> colaboradores.
>>>>>> La preocupación del gerente o dueño de empresa es ¿Cómo hago que el >>>>>> conocimiento *importante* para la empresa, se comparta con el resto de >>>>>> colegas? Y así disminuyamos frustraciones, errores, re-trabajo >>>>>> negativo, >>>>>> etc. Es bueno evitar errores innecesarios! Cuando como colaboradores >>>>>> de una >>>>>> empresa adquirimos experiencia gracias a que trabajamos para una >>>>>> empresa, es >>>>>> nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer para >>>>>> que >>>>>> ese conocimiento se comparta?
>>>>>> Las conclusiones, entre otras, de las empresas japonesas, es pasar el >>>>>> conocimiento implícito (en la cabeza de las personas) a explícito.
>>>>>> Esto se puede hacer de muchas formas y tener un repositorio no es la >>>>>> única ni las más efectiva, pero la que puede tener mayor alcance >>>>>> cuando la >>>>>> empresa tiene muchos colaboradores y/o están en varias ciudades. Hay >>>>>> empresas que tienen 130 mil colaboradores y oficinas en más de 120 >>>>>> países. >>>>>> Hay empresas en Perú con 50 personas en 3 ciudades. Hay empresas que >>>>>> tienen >>>>>> 25 colaboradores y están en 20 países.
>>>>>> En cuanto a la alternativa de tener un repositorio, está claro que no >>>>>> es suficiente guardar información en algún lugar para convertirlo en >>>>>> conocimiento explícito.
>>>>>> Para convertirlo en conocimiento explícito, se requiere:
>>>>>> . Que alguien (puede ser la misma persona) evalúe si ese conocimiento >>>>>> será de valor en otros casos
>>>>>> . Identificar el contenido a compartir
>>>>>> . Agregar al contenido a compartir, ideas que no están escritas y >>>>>> están >>>>>> en nuestra cabeza. Por ejemplo, en cuál contexto se usó ese >>>>>> conocimiento.
>>>>>> . Que alguien le de forma, es decir agregar datos que permitan >>>>>> accesar, >>>>>> clasificar a esa información (por ejemplo, por dominio, por profesión, >>>>>> entre >>>>>> otras formas)
>>>>>> . Publicar esa información
>>>>>> . Difundir que esa información está publicada y asegurar que llega a >>>>>> los posibles usuarios que le van a ver valor
>>>>>> . Mantener actualizada dicha información
>>>>>> . Dar de baja a información obsoleta o que ya no es correcta
>>>>>> . Hacer que las personas que tienen conocimiento o experiencia >>>>>> compartan su información, como parte del proceso, como parte de la >>>>>> retrospectiva de cualquier iteración, proyecto, tarea, servicio u >>>>>> operación.
>>>>>> El medio para esto es cualquier herramienta de manejo de contenidos, >>>>>> inclusive directorios compartidos!
>>>>>> Tener un repositorio no es la única forma de pasar conocimiento >>>>>> implícito a explícito en una organización. Pero es importante en >>>>>> muchos >>>>>> contextos.
>>>>>> He tenido la oportunidad de trabajar en empresas grandes y pequeñas >>>>>> que >>>>>> tenían dicho repositorio o base de datos de conocimiento. No tengo >>>>>> duda que >>>>>> eso es patrimonio de la empresa.
>>>>>> Por ejemplo, en un caso, pude atender a un cliente aquí en Perú, >>>>>> proponer una solución y realizar una implementación exitosa usando la >>>>>> información en dicho repositorio, información que fue almacenada por >>>>>> dos >>>>>> proyectos ejecutados en Italia, jamás hablé con las personas de dichos >>>>>> proyectos en
Hola a todos. Ciertamente se armó un intercambio de opiniones muy productivo. Aunque llego bastante tarde al mismo, les alcanzo algunas conclusiones personales a las que llegué tras leer el hilo completo.
1. En las empresas que desarrollan software, se genera conocimiento implícito constantemente y por lo tanto es imposible pretender que todo el conocimiento implícito vaya a volverse explícito. 2. Hay casos en los que la tasa de generación de conocimiento implícito es muy alta, por lo que se debe evaluar el ROI de transformarlo en explícito. 3. Puesto que evaluar el ROI de esta transformación no es una tarea sencilla, opino que la medida más efectiva para mantener el conocimiento dentro de la empresa debería ser disminuir drásticamente la tasa de rotacion del personal (turnover). 4. Un modelo sencillo de evaluación de ROI para tranformar conocimento implícito en explícito (asumiendo un turnover bajo) es utilizar un enfoque PULL. Por ejemplo, transmitir o registrar el conocimiento cuando se detecta que es requerido por más de una persona. 5. Una excepción a la regla anterior es el trabajo en pares, el cual opino que es la manera más efectiva de transmitir conocimiento (asumiendo el punto 3 y la co-localización del personal). 6. La empresa debe brindar la cultura, las oportunidades y los medios adecuados para que la transformación de conocimiento se pueda realizar de manera exitosa.
Espero podamos continuar la conversación durante la reunión de la comunidad.
> On 2/3/10, Deusdit Correa Cornejo <neod...@gmail.com> wrote: > > Hola Gustavo, a los tiempos!... bueno la idea es ver como Agile ayudan a > la > > *gestion *del conocimiento (creo que ya esta claro que Scrum, y cualquier > > otra metodologias agile, ayuda, y mucho, a la *creacion *del > conocimiento) > > pues parece que es un tema un poco "flojo" en los ambientes agiles.
> Muy buen, creo que ahora has dicho todo lo que es mas concreto acerca > de KM y Agile.
> Saludos,
> Heitor
> > Atte,
> > Deusdit Correa Cornejo (@neodacc) > > MBA Student / IT Director / Certified ScrumMaster / Agile Coach
> >> Ese tema es interesante no lo metí por el tema que creo que va mas allá > de > >> Agile y no hay espacio para eso al menos aquí en Perú. Si se puede, pues > >> seria bueno como tema de la siguiente reunion Agile. Hasta me presto > para > >> moderarla esos temas son bastante emocionantes y mejor en persona.
> >> Under the Dilbert Principle, an incompetent computer programmer would be > >> "promoted" out of his or her department in order to allow other > competent > >> programmers an opportunity to work in peace > >> ---The Dilbert Principle
> >>>> Deus! veo que no me dejé entender bien... =(
> >>>> Claro que sí! Claro que es bueno tener un repositorio, claro que las > >>>> personas no estarán toda la vida en sus empresas (dímelo a mi que > llevo > >>>> un > >>>> mes en una empresa nueva ;D ), es imposible predicar que "no hace > >>>> falta", > >>>> "no es bueno", gestionar el conocimiento. Esto no quize decir en > ningún > >>>> caso.
> >>>> Por otro lado, David, en mi caso no hace falta abstraerme para > >>>> imaginarme > >>>> ser dueño de una empresa y que necesidades se pueden generar. Hace > unos > >>>> años > >>>> tuve una con con mi padre, y vivíamos (entre otras mil preocupaciones) > >>>> eso > >>>> de que la gente se iba sin dejar nada. Claro que sí entiendo tu punto.
> >>>> El problema está señores...
> >>>> Cuando viene alguien que dice saber "gestionar el conocimiento" y > quiere > >>>> vender la idea a ese dueño de empresa, que con implementar un > >>>> repositorio, > >>>> prácticas de generación de conocimiento, etc, etc, etc...le > >>>> promete..."Yo > >>>> llevaré todo lo implícito a explícito!" y tu empresa ya no dependerá > más > >>>> de > >>>> las personas, serán reemplazables sin problemas...
> >>>> Creo que el desconocimiento respecto a esta rama es lo que hace tanto > >>>> daño...se siente cierta contradicción en decir:* "Gestionemos el > >>>> conocimiento y...dependamos de las personas!"* , la gente que siente > que > >>>> esto es contradictorio, es la que le hace daño al tema, y al final, a > >>>> esa > >>>> empresa.
> >>>> Así que quede claro mi punto por favor, la gestión del conocimiento es > >>>> importante, con la sabiduría de que realmente lo implícito...nunca > será > >>>> explicito al 100%.
> >>>> Saludos,
> >>>> Raúl
> >>>> 2010/2/3 Rafael Olaechea <peru...@gmail.com>
> >>>> En mi experiencia profesional es verdad que los repositorios bien > >>>>> organizados e* integrados* con el resto de sistemas de la empresa (eg > >>>>> sistema de tickets, bugs, documentos, directorioa de personal, etc) > >>>>> ayudan > >>>>> bastante a compartir conocimientos.
> >>>>> Sin embargo también hay otras maneras más sencillas de mejorar el > flujo > >>>>> de conocimiento en la empresa y que deben ser exploradas antes de > pasar > >>>>> a > >>>>> implementar un sistema de conocimiento electronicos, ya que quizas > >>>>> basten > >>>>> para los requisitos de la empresa basten otras formas mas sencillas y > >>>>> economicas.
> >>>>> Por ejemplo yo conozco el caso de una empresa grande donde trabaje, > >>>>> done > >>>>> nadie tenía oficina ni siquiera el dueño. Y todos las paredes eran > de > >>>>> vidrio. Es más en muchos casos aprendía partes importantes cuando > mis > >>>>> colegas y/o jefe hablaban con otros y yo escuchaba las > conversacoines > >>>>> del > >>>>> costado. Este diseño de la oficina fomentar los encuentros casuales > y > >>>>> el > >>>>> conocimiento compartido entre colegas puede ser muy útil, si es que > el > >>>>> modelo del negocio lo permite.Funcionaba bastante bien y no requería > >>>>> mayor > >>>>> inversión en TI.
> >>>>> Saludos, > >>>>> Rafael
> >>>>> 2010/2/3 David Arteaga Process <david.arte...@processconsulting.net>
> >>>>>> Holas!
> >>>>>> Añado más ideas para el debate.
> >>>>>> Quienes han trabajado bastante con el tema de gestionar > conocimiento, > >>>>>> entre otros, son las empresas japonesas.
> >>>>>> No hay duda que el conocimiento lo tienen sólo las personas! No hay > >>>>>> otra forma!
> >>>>>> Tampoco hay duda que el conocimiento se comparte de manera eventual > e > >>>>>> informal, en blogs como este, en conferencias, cuando conversamos en > >>>>>> el > >>>>>> pasillo o tomamos un café con un colega, o cuando un colega o amigo > >>>>>> nos > >>>>>> pregunta de manera directa y explícita sabes cómo hacer esto? Has > >>>>>> hecho esto > >>>>>> antes? Y le respondemos.
> >>>>>> El asunto es (i) cómo hacer que el conocimiento se comparta de > manera > >>>>>> no sólo informal y (ii) cómo hacer que se comparta en las > >>>>>> organizaciones.
> >>>>>> Este asunto puede resultas de poca importancia desde el punto de > vista > >>>>>> profesional individual o como consultores independientes o free > lance. > >>>>>> No > >>>>>> estamos obligados, quizás no tenemos interés, o lo hacemos de buena > >>>>>> gana > >>>>>> (Este es otro tema muy interesante, en mi opinión el paradigma > >>>>>> obsoleto de > >>>>>> mientras más conocimiento tengo soy más valioso, ya no es vigente, > >>>>>> ahora > >>>>>> mientras más comparto y sirvo de conexión soy más valioso)
> >>>>>> Les animo a que se pongan en los zapatos del accionista o dueño de > una > >>>>>> empresa. Si ustedes con dueños de una empresa, donde tienen n > >>>>>> colaboradores.
> >>>>>> La preocupación del gerente o dueño de empresa es ¿Cómo hago que el > >>>>>> conocimiento *importante* para la empresa, se comparta con el resto > de > >>>>>> colegas? Y así disminuyamos frustraciones, errores, re-trabajo > >>>>>> negativo, > >>>>>> etc. Es bueno evitar errores innecesarios! Cuando como colaboradores > >>>>>> de una > >>>>>> empresa adquirimos experiencia gracias a que trabajamos para una > >>>>>> empresa, es > >>>>>> nuestro deber que lo que aprendemos se comparta. ¿Peró cómo hacer > para > >>>>>> que > >>>>>> ese conocimiento se comparta?
> >>>>>> Las conclusiones, entre otras, de las empresas japonesas, es pasar > el > >>>>>> conocimiento implícito (en la cabeza de las personas) a explícito.
> >>>>>> Esto se puede hacer de muchas formas y tener un repositorio no es la > >>>>>> única ni las más efectiva, pero la que puede tener mayor alcance > >>>>>> cuando la > >>>>>> empresa tiene muchos colaboradores y/o están en varias ciudades. Hay > >>>>>> empresas que tienen 130 mil colaboradores y oficinas en más de 120 > >>>>>> países. > >>>>>> Hay empresas en Perú con 50 personas en 3 ciudades. Hay empresas que > >>>>>> tienen > >>>>>> 25 colaboradores y están en 20 países.
> >>>>>> En cuanto a la alternativa de tener un repositorio, está claro que > no > >>>>>> es suficiente guardar información en algún lugar para convertirlo en
|
