Jeff Sutherland. El conocimiento debe residir en el equipo y no acumularse en personas concretas

La gestión del conocimiento en una organización suele ser uno de sus puntos débiles. El día a día y la orientación exclusiva a la ejecución de los trabajos hace que queden en un segundo plano medidas orientadas a que el conocimiento no sea algo exclusivo de las personas sino un bien de la organización.

Además, muchas personas tienden a acumular conocimiento sobre determinadas materias y hacerlos estanco para los demás, creando de esta forma una parcela de poder (un cortijo) que lo haga fuerte tanto en su continuidad en la organización como en su promoción.

Es cierto que siempre habrá alguien que domine mejor una tecnología, un área de negocio o conozca mejor a un cliente, eso resulta lógico y razonable y además puede ser una ventaja importante personas tan especializadas. En estos casos lo que hay que intentar hacer es que su conocimiento llegue a más compañeros y en lo posible que lo más significativo quede registrado por escrito.

Si nos centramos en marcos de desarrollo fuertemente colaborativos como por ejemplo la programación extrema el conocimiento debería ser algo colectivo por la rotación existente de manera interna en un equipo donde una semana uno puede estar haciendo programación por pares de un módulo con una persona y la siguiente estar con una funcionalidad totalmente distinta en otro subsistema.

Jeff Sutherland en relación a la acumulación de conocimientos por parte de personas concretas opina lo siguiente: “No debe haber un tipo que acumule todo el conocimiento sobre un tema. Yo despediría a aquellas personas que tienen todo el conocimiento sobre un dominio concreto ya que no se debe tener un único punto de error”.

Anuncios
7 comentarios
  1. Ricardo dijo:

    ¿Tan difícil es escribir un documento de diseño para que cualquiera pueda leerlo cuando quiera sin molestar a nadie? Además de eso, la gente siempre rota, en mayor o menor medida, pero siempre hay rotación.
    Por cierto, estoy de acuerdo con la frase, si alguien se resiste, lo mejor es despedirle.

    • jummp dijo:

      No, no es tan difícil y en general no es tan complicado establecer mecanismos que permitan que el conocimiento esté al alcance del colectivo aunque antes, es necesario conciencias a las personas y a los equipos de trabajo del beneficio que trae consigo trabajar de esta forma.

  2. Joder con el Jeff, no sera tambien que a veces en las organizaciones funciona mucho eso de “a mi no me cuentes tus historias que eso es cosa tuya” y “para que escribir documentos si no los lee nadie y al final o me preguntan o acabo siempre haciendolo yo”.

    Si hablamos de codigo sin duda el mejor legado es un codigo bien hecho y razonablemente comentado, casi siempre los documentos sobre codigo salvo que se hagan despues suelen valer cero.

    • jummp dijo:

      Más que un tema de organizaciones (lo del “a mi no me cuentes tus historias que eso es cosa tuya”) es de personas y actitudes negativas a compartir el conocimiento lo tenemos tanto en personas que lo poseen y quieren conservar su parcela de poder como en aquellas personas que se desentienden de la posibilidad de adquirir ese conocimiento. En ambos casos son culpas de esas personas pero más de quien lo consiente.

      Es cierto que parte del conocimientos se tiene que documentar. La clave es encontrar el equilibrio entre lo que es útil y lo que empieza a dejar de serlo.

      • Yo tengo muy claro que un buen técnico tiene que posicionarse ante este dilema:

        “Si buscas hacer bien tu trabajo lo más probable es que te echen o te tengas que irte”

        Me explico.

        1) Si haces un buen software los costes disminuirán porque existirán menos incidencias, menos problemas técnicos, mejor punto de partida para evoluciones o mejoras etc, al disminuir el coste no se necesitarán más personas para mantenerlo, evolucionarlo etc por lo que paradójicamente el dueño del producto es posible que se de cuenta de que la proporción del coste de los buenos técnicos respecto al producto es cada vez más alto, y consecuencia de estar “tan mal acostumbrado” tendrá la tentación de substituirlos por otros técnicos de mucho menor coste en el mismo número, porque la mayoría piensa que el desarrollo software es una commodity y que da igual mientras el resultado siga siendo “igual de bonito” (yo lo llamo “la maldición de los colorines”). Se que es absurdo y se pagará caro pero es una realidad cotidiana.

        2) Si buscas en lo posible elevar el nivel de tu equipo, compartirás conocimientos, habilidades etc y al final prescindirán de ti, por una parte porque eleva tu “nivel de liderazgo en la compañía” dando lugar a las conocidas envidias, recelos y miedos de otros, pero por otro tus compañeros estarán a un nivel similar al tuyo (dejas de ser tan “imprescindible” y tan “necesario” para tu equipo) y por otra parte porque das lugar al punto 1).

        Yo personalmente asumo esos dos puntos como “inevitables” pero entiendo perfectamente que “el camino de la mediocridad” a veces suele dar mejores frutos.

    • Ricardo dijo:

      “casi siempre los documentos sobre codigo salvo que se hagan despues suelen valer cero.”
      Con esa frase has demostrado que de ingeniería del software no tienes la más remota idea, espero que seas mejor programando.
      Por cierto, cambiando de tema, en ciertas industrias el software se modela, no se programa, por ejemplo el software de control de un avión, por tanto en ese campo ni habría programación tal como tú piensas. Según tú, ¿esto no sería software, verdad?

  3. Por otra parte hay que ser muy prudente y saber gestionar “la disidencia” y no necesariamente a través de la habitual estrategia del miedo, a veces la disidencia puede ser extremadamente valiosa si es una “disidencia constructiva”, por ejemplo, RIM ha tenido que entrar en barrena para que alguien se haya atrevido dentro de RIM ha expresar su “disidencia” de una forma tan clara como:

    http://www.bgr.com/2011/06/30/open-letter-to-blackberry-bosses-senior-rim-exec-tells-all-as-company-crumbles-around-him/

    En esa carta el alto directivo de RIM deja claro que una de las causas del deterioro de la compañía en todos los aspectos (no sólo en en ventas) es debido a :

    “unfortunately the culture at RIM does not allow us to speak openly without having to worry about the career-limiting effects”

    Lo de “career-limiting effects” es una forma extremadamente fina y sutil de decir ciertas cosas 🙂

    Al igual que el empleado debe al final acatar las directrices de la compañía, una dirección que no los escucha es fácil que acabe llevando la compañía a la ruina, pista: son los empleados los que suelen estar MUY cerca de los problemas.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: