La urgencia y algunas malas prácticas derivadas

Quería compartirles algunas reflexiones sobre la gestión del conocimiento en las pequeñas empresas que trabajamos con software libre. Reflexiones que surgen de observar desde una perspectiva crítica nuestro propio quehacer.

Un escenario típico en una pequeña empresa que presta servicios basados en Software Libre es recibir un requerimiento de un cliente (casi siempre urgente) que solicita poner en marcha un nuevo servicio A en un servidor que ya está en operaciones.

El requerimiento pasa a la cola de las “tareas a cumplir a corto plazo” y es asignada a uno/a de nuestros jóvenes profesionales.

Él o ella recurren a la documentación que se generó en la empresa para un caso anterior similar a partir del pedido de otro cliente. Rápidamente caen en la cuenta que la información no les sirve exactamente, puede ser porque está un tanto desactualizada, o porque la puesta en marcha se hizo para otra distribución y no la que ahora desea el cliente. Quizá peor, se dan cuenta de que quién documentó por última vez no puso mucho empeño en la tarea a juzgar por lo complicado o escaso o desordenado del texto.

Entonces, como la documentación propia no es el mejor recurso con el que cuentan, rápidamente recurren a Internet y encuentra un “How To” que les dice exactamente qué hacer para implementar A sobre la distribución que necesitamos. Siguen la receta, y para la tarde tienen el nuevo servicio A funcionando.

Si somos afortunados, el “How To” incluyó algunas pruebas de funcionamiento del servicio y configuraciones del mismo relacionadas con la seguridad, de manera que antes de comunicarnos que concluyeron la tarea, verifican estos últimos pasos.

Es escasamente probable que hayan realizado algunas pruebas sobre cómo el nuevo servicio implementado carga al servidor o hayan procurado entender con claridad los nuevos registros que aparecen en los archivos de log generados por el nuevo servicio. En cualquier caso, quedan convencidos/as de que saben realizar la tarea de poner en marcha un servicio A.

Si les solicitamos una explicación sobre lo realizado, nos inundan de detalles sobre comandos utilizados, pero en general nos cuesta mucho entender qué es lo que acaban de dejar funcionando y cómo lo han configurado. En general, nos cuesta entender también porque ellos tampoco tienen una clara idea conceptual de lo que han realizado.

Cuando un problema serio o un incidente se produce al cabo de un tiempo por una falla en el servicio A, y nos damos cuenta de las serias carencias que tenemos como empresa para responder al problema, volvemos a recordar lo mal que estamos gestionando el conocimiento en nuestra pequeña organización.

Es cierto, muchas veces nos auto-justificamos diciendo que lo hicimos de esa manera en ese momento porque no teníamos tiempo de aprender correctamente antes de implementar, debido a la urgencia solicitada. Puede ser cierto, como también es cierto que tampoco dedicamos tiempo a aprender una vez que dejamos las cosas funcionando porque una nueva urgencia cayó en nuestras manos. Luego, el incidente tuvo lugar.

Es más, muchas veces, siendo conscientes del problema que enfrentamos, buscamos un software que gestione nuestra documentación, como si ello fuera a constituir una solución mágica a nuestros problemas de gestión del conocimiento.

La pequeña empresa, como agente de formación de profesionales, creo que tiene una dinámica mucho más interesante que la dada en una gran empresa. Sin embargo, lograr ordenar, encausar o direccionar esa dinámica no es sencillo. Trabajar sobre las actitudes de los jóvenes profesionales para que se sientan desafiados a aprender realmente, a entender porqué llevan adelante tal o cual tarea, a comprender que la documentación que desarrollan no sólo sirve para futuros casos similares si está bien realizada, sino que les sirve como proceso interactivo para plasmar la experiencia que han desarrollado en la implementación, junto con los caminos conceptuales que justifican dicha experiencia.

Soy un convencido de que escribir documentación sigue siendo una excelente manera de contribuir a la comunidad de software libre. Pero debemos mejorar la calidad de esa documentación, salir de la mera receta, del copiar y pegar. No es sencillo, pero podemos realizar documentos aplicables a casos prácticos que ayuden a generar conocimiento y que no sólo nos digan que comandos utilizar.

Danilo Lujambio es consultor en el Máster de Software Libre dentro de la asignatura de Redes abiertas, trabaja brindando soluciones en Software Libre desde su empresa Latinux Sistemas y para el sector de organizaciones de la sociedad civil lo hace desde la ONG Nodo Tau.

2 Comments

  1. Malas prácticas hay en todos los campos, en la programación es más divertido cuando haces cosas simples y con las prisas haces lo que popularmente se conoce como “una ñapa” y la entierras en el olvido.. los muertos salen de sus tumbas.. con demasiada frecuencia.

    Reply
  2. Lamentablemente en estos tiempos los sistemas se orientan a solucionar lo urgente y no prestan atención a lo importante.
    Coincido plenamente en que la documentación es una parte importantísima no valorada por los desarrolladores actuales.
    Así mismo, el entender el fundamento de cada tarea que se realiza es vital para el éxito de un proyecto y de hecho puede servir de base para otros que vengan en el futuro.

    Reply

Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Leer entrada anterior
Vuelta al trabajo…

Volver al trabajo y retomar el contacto con el día a día. Abrir el cliente de correo y enfrentarse al...

Cerrar