Gestión del conocimiento en proyectos de software

29-07-2009 Luis Artola

Hay un concepto que, sorprendentemente y por más que pregunto a colegas que trabajan en diferentes empresas, se deja de lado en muchas empresas de desarrollo de software: la gestión del conocimiento. Y dado el sector en el que nos movemos, parece un punto clave. Me parece que cualquier empresa debería ser capaz de responder a:

  • ¿Quién utilizó, qué tecnología, cuándo?
  • ¿Quién ha desarrollado qué producto y, por tanto, conoce su Lógica de Negocio?
  • ¿Qué pasa si el programador X se marcha de la empresa? ¿se lleva todo su conocimiento? ¿Quién más lo tiene?
  • ¿Todo el mundo debe tener los mismos conocimientos? ¿Tenemos diferentes perfiles?
  • ¿Cuál va a ser la estrategia para que un recien salido de la facultad llegue a tener los mismos conocimiento que un Senior de su perfil?

Lo más triste es que pienso que la mayoría de estas cosas se podrían solucionar teniendo a una persona que se encargara de pensar un poco en ello. No sé si el problema es que la existencia o no de esa persona depende exclusivamente de que alguien, de manera proactiva, decida dedicarle algo de tiempo, o que algunas empresas tienen en la dirección cabezas que sólo piensan de manera financiera (beneficios = presupuesto – (coste del programador * número de programadores))…

Dejó aquí un artículo interesante y las técnicas básicas que propone:

  • Pair Programming: ayuda a revisar el código, tomar decisiones de diseño, y trasvasar conocimiento entre programadores.
    Wiki: es una manera ágil y rápida de compartir documentación, modificarla, y mantenerla totalmente actualizada (sabiendo quién hizo qué cambios).
    Coding Standards Document: si todo el mundo escribe código igual, el mantenimiento es mucho más sencillo y evita que un código solo sea mantenible por quien lo programó.
    Mailing List: o montarte “un twitter” para el proyecto (con Prologue o con lo que sea) ayuda a preguntar y responder dudas sobre el proyecto rápidamente.
    Hacer saber a la gente que has arreglado un problema: esto se refiere a que una persona pueda entra en el código programado por otra y modificarlo para solucionar un problema, comentádoselo luego a los demás, y depende de la manera en que gestiones el código.
Etiquetas:
, , ,

7 Comentarios

  • 1. patata  |  Julio 30th, 2009 at 8:28 am

    Hola, Luis

    Muchas veces, me he realizado la misma pregunta que tú. Sobre todo porque, si no hay inteligencia colectiva ¿qué más da si confiar un proyecto a una empresa con 1 año de antigüedad o 10 años, si las dos acumulan la misma experienca?

    Pero, en lugar de preguntar a empresas del sector, yo me he dedicado a observar a empresas de cualquier sector.

    Y mi apreciación (absolutamente personal, por supuesto) es que el motivo subyacente a esta falta no es la falta de herramientas ni metodologías, sino a la idiosincracia hispánica que considero incompatible -por lo general- con este tipo de prácticas.

    ¿A qué me refiero con “idiosincracia hispánica”? Puf, esto daría pie a TODO un blog…

    Ojo:

    - Mi objetivo no es criticar nuestra idiosincracia, sino intentar comprenderla lo máximo posible para poder gestionarla lo mejor posible.

    - Como toda generalización, es peligrosa. Afortunadamente, cada persona es un pequeño mundo.

    Felicidades por tu blog

  • 2. Luis Artola  |  Julio 30th, 2009 at 8:36 am

    hola “patata”,

    dios mío, me resisto a pensar que el “spanish trakatrá” sea la razón última de la inexistencia de la gestión del conocimiento.

    Me gusta pensar que se trata única y exclusivamente de inexperiencia, y de que la ingeniería del software es algo nuevo… porque sino los pobres programadores estamos habiados… :-D

  • 3. kapsule  |  Agosto 2nd, 2009 at 11:38 pm

    Muy buenas.

    Ante todo felicitarte por tú blog. Creo que tienes mucha pero que mucha razón en tus comentarios. Despues de 8 años en mi empresa por fin he podido crear un blog interno en el cual informamos a todo el personal sobre los desarrollos actuales e incidencias que se producen. Creo que es muy importante que la información sea fluida y clara. Como bien comentas, si este tipo de estructura la realizas correctamente nunca tendrás toda la información centralizada en una misma persona o departamento.

    Un saludo.

  • 4. Luis Artola  |  Agosto 3rd, 2009 at 8:55 am

    hola kapsule,

    es que un blog interno me parece ya un gran avance. Y si consigues desarrollar una cultura dentro de la empresa de usar ese blog (y que incluso la gente esté motivada a hacerlo para destacar, por ejemplo)… eso ya me parecería la repanocha!

    Un saludo y gracias por participar!

  • 5. Ki  |  Septiembre 9th, 2009 at 12:17 pm

    aprovechando mi periplo de becario en la empresa finalmente hemos ( he ) añadido una wiki con todo tipo de información detallada de los script empleados en servidores y programas de gestión/ administración como Nagios.

    Misteriosamente ahora la gente pregunta menos cosas sobre programación jejeje

  • 6. inyaka  |  Octubre 20th, 2009 at 3:37 am

    sobre el ultimo punto acabo de instalar a modo de prueba ProjectPier http://www.projectpier.org en mi servidor de pruebas y hace algunas de las cosas que propones, un sistema de tiquets y tambien de mensajes, etc… además es libre, gratuito y escrito en php

    sobre lo de que todos programen mas menos con el mismo estilo, para eso creo fundamental el uso de algún buen framework yo uso Codeigniter aunque veo que a ti te gusta Zend)

    y sobre Pair Programming: ¿eso con que se come? no habia escuchado sobre eso

    Es primera ves que posteo en tu blog, lo acabo de conocer y en verdad escribes artículos bien interesantes, ya te tengo agregado a mis RSS.

  • 7. fernando morales  |  Noviembre 20th, 2009 at 8:31 pm

    Nosotros trabajamos en un hospital desarrollando las aplicaciones tanto administrativas como medicas de la empresa. Y nos dimos cuenta de la importancia de que todos los miembors del equipo tengan un estandar de conocimientos generales y especificos de lo que pasa en la empresa y el departamento de desarrollo. Empezamos por aplicar metodologías ágiles para modificar el pensamiento e integrar al equipo. Pero lo mas importante es que implementamos una politica de enseñanza e investigación que se aplica a todos cada X tiempo, es decir, todo mundo tiene que investigar y exponer un tema en especifico que puede estar relacionado con el proyecto actual o con algun otro tema y que todos tienen que debatir (todos son maestros y alumnos al mismo tiempo). El resultado de la investigación y el conocimiento generado se guarda en un lugar especifico al que todos pueden accesar. De esta manera podemos tener a todos informados con conceptos básicos y avanzados de todo y sirve como motivación para superación individual y colectiva.

Comenta el articulo:

Requerido

Requerido,