archivo

Archivo de la etiqueta: gestión del conocimiento

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”.

En un artículo anterior hice referencia a la tiranía del cliente, cuando este aprovecha de forma abusiva la posición de dependencia de una proveedor respecto de los ingresos que le proporcionan sus contratos, ya que una buena parte de la facturación procede del mismo.

Esta tiranía también la podemos encontrar al revés, cuando un proveedor se encarga del desarrollo y mantenimiento de sistemas de información críticos para el negocio o para un aspecto concreto del mismo y el conocimiento necesario para poder cambiar de proveedor no está debidamente transferido al cliente y/o no está documentado (todo esto se ve agravado exponencialmente si en el caso de un desarrollo a medida no hay un control adecuado de versiones y del código fuente).

Como en el caso de la tiranía del cliente, el principal responsable no es quien ejerce la posición de poder sino quién ha propiciado las condiciones para que esa posición de poder exista. Es cómodo para un cliente depender de pocos clientes que te aseguren ingresos fijos y también lo es para un cliente trabajar con una serie de proveedores fijos que cumplen con su cometido y no te dan problemas.

Pero este ambiente idílico, funciona si todo va bien, pero ya sabemos de voluble es el mercado y nuestro negocio. Puede haber relaciones de años que se terminen degradando y se rompa el equilibrio en el que todo parece marchar, ahí es cuando empiezan los problemas, ahí es cuando pueden aparecer este tipo de situaciones.

Si un proveedor se siente fuerte, podrá empezar a exigir precios superiores a los que venía percibiendo, sin más justificación (real) que la de ganar más dinero, podrá empezar a reducir su nivel de calidad, a reducir su nivel de compromiso y lo peor de todo es que se termina tragando más y más porque te tienen bien agarrado por donde todos sabemos.

Llegado el momento tendrás que plantearte seriamente continuar con el proveedor. Lo mismo no lo puedes hacer de manera inmediata porque se puede resentir tu negocio, pero sí que se tienen que establecer los mecanismos para que el conocimiento no se encuentre exclusivamente en él.

Barry Boehm plantea una de las principales críticas que se realizan a las metodologías ágiles y que se basa en el hecho de que prime las personas (y su interacción) sobre los procesos y que el software funcione por encima de la documentación, de manera que el conocimiento se concentra en el equipo de proyecto (en el concepto general no refiriéndose exclusivamente al equipo de desarrollo) y que el mismo empieza y termina en él, sin tener en cuenta que en el futuro, otro equipo, parte de él de otra organización, puede participar en su evolución.

La reflexión que realiza Boehm es la siguiente (traducción libre): “Las metodologías ágiles obtienen buena parte de su agilidad, apoyándose en el conocimiento implícito que posee el equipo, en lugar de traspasar el conocimiento a documentos”.

Las metodologías ágiles no obvian ni los procesos ni la documentación, de hecho son medios e instrumentos de trabajo, pero no son el fin. En mi opinión tan malo es el extremo de no documentar como el hecho considerar a la documentación un fin más dentro del proyecto (esto último podría entenderse en ciertos tipos de proyectos, pero aplicados a la generalidad no resulta práctico).

¿Es bueno que el conocimiento se quede en el equipo de proyecto? La respuesta es que no, ¿es eso, entonces, compatible con las metodologías ágiles? La respuesta es que sí y es el resultado de la suma de varios factores: sí que se documenta (lo que el proyecto necesita acorde a su naturaleza, presupuesto y metodología utilizada), se busca la solución más simple (o al menos se debe) y la codificación pretende ser de gran calidad. Por tanto, las metodologías ágiles, bien aplicadas, permiten una transferencia del conocimiento eficaz (será más o menos complicada en función del tipo de proyecto, pero eso al fin y al cabo pasa también con metodologías no ágiles) y una reducción del tiempo de adaptación a la arquitectura y código.

Si los proyectos no varían de proveedor de servicios de desarrollo de software o de responsable del proyecto, la importancia de las métricas y de la documentación pueden pasar a un segundo plano, ya que de una u otra forma el sistema de información seguirá adelante. Es cierto que las métricas y la documentación pueden resultar también de gran utilidad en estos casos, sobre todo si se quiere ver cómo evoluciona la calidad de la herramienta y las incidencias que están teniendo los usuarios en el uso cotidiano de la aplicación.

En cualquier caso el problema está en que generalmente nos solemos acordar de la documentación y de conocer métricas cuando las necesitamos y precisamente por eso, cuando tenemos que echar mano de ellas no las tenemos.

Como es lógico, esa no son las únicas circunstancias que aconsejan que se documenten los proyectos y se obtengan métricas, ya que por encima de eso está la persistencia del conocimiento de la aplicación lo que permite que la adaptación a cambios en la gestión y en los proveedores resulte menos traumática. También permitirá tener un punto de referencia para evaluar la evolución del producto en las nuevas condiciones de explotación o mantenimiento.

Por ejemplo, si se fueran a externalizar en bloque el mantenimiento de una serie de aplicaciones de una organización probablemente lo primero que querrían conocer los posibles proveedores de ese servicio sería información general de las aplicaciones: tecnologías, arquitecturas, fecha de puesta en producción, etc… y métricas: número de incidencias de relacionadas con correctivos, frecuencia de mantenimientos evolutivos, volumen, calidad y formato de la documentación, etc… Si eso se adobara con informes Sonar que indiquen la evolución del análisis estático de código de las mismas, les permitiría todavía más ser más precisos en la estimación del esfuerzo que se requeriría para realizar el servicio en función del número de aplicaciones a mantener, las características del servicio y del acuerdo de nivel de servicio. Además de todo lo anterior, les sería interesante conocer las reglas de desarrollo y de calidad del software de la organización, el ecosistema de desarrollo, las características del entorno de producción, preproducción y desarrollo: sistemas físicos, software de base y servidores de aplicaciones, la estructura organizativa del departamento de informática, el proceso de paso a producción, etc…

Uno de los aspectos que considero fundamentales en una organización es el establecimiento de mecanismos para que el conocimiento permanezca ligado a la misma y no a las personas que componen la misma. Ya lo sabemos todos, las personas vienen y van, pero la organización sigue ahí.

Evidentemente, por mucho que se documente todo y se comparta el conocimiento con el resto de compañeros, es imposible recopilar toda la experiencia de una persona, ya que el conocimiento no es solo información y datos, sino la forma de interpretarlos y ponerlos en contexto con cada situación concreta. Por este motivo, no se debe olvidar que la marcha de una persona de la organización, conlleva, sin duda, la pérdida de conocimiento. Cualquier otra consideración es engañarse.

Una vez conocido que un objetivo debe ser que el conocimiento permanezca en la organización, pero que es imposible desligarlo de las personas, queda llegar a la situación de equilibrio y es que en la medida de lo posible persistan los procedimientos de la organización (eso no es conocimiento, pero si el entorno de actuación) y que los proyectos de desarrollo de software, técnica de sistemas, etc… queden lo mejor documentados posible. Esto es información y datos, la base para un posterior conocimiento.