¡Necesito evitar la dependencia de las personas!

Dependencia de las personas… el gran terror de miles de responsables de proyecto, de gerentes, socios, directores, etc. Más aún si cuenta con personal externo ¿Qué hacer? ¿Cómo hacer para no depender de ciertas personas? ¿Y si Pepe se va de la empresa? ¿Y si no queremos seguir contando él?
Lo primero que a cualquiera le viene a la cabeza es que, para no depender de Pepe, hay que, valga la redundancia, sacarle a Pepe las cosas de la cabeza. ¡Que alguien escriba lo que Pepe hace en un documento! ¡Documentación! De echo, en parte, este motivo dio origen a la inconclusa era de la “sobre documentación”.
Todo en papel. No se da el siguiente paso en el ciclo de desarrollo… si antes alguien no escribe el paso previo en un papel.
Hasta este punto, mucha gente se cree segura, muchas veces viviendo en una falsa seguridad. Tengo documentado todo lo que se ha implementado y además cómo se ha llegado a ello, y todo ello en un papel.
Pero como comentábamos en la verdadera calidad software la tienes que ver en los fuentes, en el código, no te fíes de nada más… ¿De verdad crees que lo que hay en un papel vale para algo? ¿De verdad crees que lo que hay en un papel se parece en algo a lo que de verdad se ha programado? ¿De verdad?
Yo que tu… mmm no me fiaría. Yo hay veces que ni me fío ni de los fuentes que hay en control de versiones, porque muchas veces ni coinciden con el software que hay en producción.
La historia de la ingeniería del software está llena de “inventos” ingeniados para asegurar que los documentos reflejan la realidad del software implementado, desde las auditorías, pasando por las matrices de trazabilidad, el “round trip” (actualizar los UML cuando se toca el código), etc. Pero realmente… no han terminado de funcionar.
Mientras, ingentes cantidades de documentos se han ido generando. Horas. Meses. Personas y personas dedicadas a documentar. Desperdicio y desperdicio en terminología Lean.
¿Quieres un consejo? ¿Sabes cuál es la mayor garantía de no dependencia de personas? Cómo no depender de aquel que programó algo…. Tener buen código. Código limpio. Buenos diseños. Buenas Pruebas. Buen control de versiones. Métricas de calidad software en valores razonables. No tener exceso de líneas de código. No tener aberraciones en el diseño. Etc.
Ya, si lo sé. Que esto es mucho más difícil de entender y de explicar a muchos gerentes y responsables de proyecto. Es más fácil entender “lo importante de documentar” que entender lo que son “aberraciones en diseño y código”.
Pero nadie dijo que esto era fácil, el software, eso que revoluciona negocios, que cambia el mundo, no podía ser tan fácil. Y para entenderlo necesitas profesionales cualificados.
¿Qué? ¿qué pasa con los documentos? ¿qué si no hay entonces que documentar? Sí, claro. Yo no dije que no documentases, yo digo que hagas documentación inteligente, documentación útil. No documentación tan difícil de mantener que nadie la mantiene y nadie se fía de ella.
Documentación cuyo propósito no sea poner el código en un papel. Documentación que sirva de guía, al igual que un esbozo de un mapa no pretende representar todos los detalles de la realidad.
Pero por muy buena documentación que tengas, recuerda, no serás tan libre como teniendo buen código.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “¡Necesito evitar la dependencia de las personas!”

  1. Pingback: Bitacoras.com

  2. Hola Javier, aún estando de acuerdo contigo en que sólo hay que documentar lo necesario y que luego haya compromiso de mantener, me gustaría comentar dos situaciones en las que es necesario tener una buena documentación.
    * Yo, en mis 30 años de informático he sufrido (y cuando digo sufrido, quiero decir sufrido) 6 auditorias externas serias. En todas ellas me han pedido evidencias por escrito de proyectos finalizados/en curso. Éstas evidencias erán desgraciadamente documentación: planes de proyectos, análisis funcionales, catálogos de requisitos, documentación del diseño y ejecución de pruebas, etc. Y cuando no la tenías lo que tenías era un gran problema (Javier tu eres auditor y sabes de lo que hablo). Todavia me acuerdo de cuando nos ibamos a fusionar con otra empresa del mismo sector y los auditores debían decidir cuál de los dos sistemas informáticos debería ser el principal (con todo lo que eso supone respecto a la perdida de puestos de trabajo de los «perdedores»). Al final uno de los factores fundamentales fue el grado de documentación de los sistemas.
    * Cuando contratas una factoria de software (cosa cada vez más corriente) tanto para diseño y desarrollo como para pruebas, la empresa externa te pide un nivel de documentación tan completo que te puedo asegurar que sólo con las historias de usuario (HDU) no les vale. Concretamente la empresa que nos hace el diseño y ejecución de las pruebas funcionales no acepta los Acuerdos de Nivel de Servicio establecidos si la documentación funcional entregada para hacer sus pruebas no es completa y detallada, tampoco acepta las HDU como única documentación funcional.
    Desgraciadamnte, hay bastantes más casos en los que hay que hacer más documentación que la justamente necesaria y mantenible.
    Perdonad por la extensión de mi comentario y por las batallas del abuelo cebolleta (no conoces el abuelo cebolleta, entonces no necesitas un plan de pensiones ;)) ).

    1. Hola Vicente!!
      Lo que comentas, efectivamente, es una realidad, lo que no quita que a la vez… sea una pena ☹, y me estoy refiriendo principalmente al punto 1 que mencionas, al de las auditorías.
      Efectivamente, yo suelo hacer bastantes auditorías y lo primero que yo digo es:
      – “no quiero ver documentos que el equipo no nunca ha leído, yo quiero ver los proyectos y de documentación la que ahí se maneje”,
      – continuo con “las cosas importantes deben estar explicadas, que no implica necesariamente documentadas en un pdf o en un doc”
      – y también digo “las empresas no tienen que trabajar para el auditor”
      Y en muchas auditorías me encuentro situaciones terribles, heredadas de auditores que habían estado previamente y que sólo sabían ver documentos, no sabían leer una línea de código, y que la auditoría consistió en ver pdfs. Y eso ha derivado en que he visto a empresas pasar auditorías de software… ¡comprando los pdfs con metodología a otra empresa! pdfs que jamás usaron.
      Y he podido escuchar auditores que no consideran como una evidencia una explicación en una tarea de Jira, Trac o la que sea. Y que así hacen a las empresas contratar una persona exclusivamente para crear un universo paralelo de pdfs que ninguna persona del equipo conoce, etc. Y que por razones como estas han deteriorado la imagen de modelos como CMMI hasta niveles bajísimos.
      Como decía, estoy de acuerdo que la realidad, en su mayoría es así, afortunadamente creo que cada vez lo es menos, lo cual no quiere decir que sea una realidad que me guste.
      Gracias por el comentario!

  3. ¿Y me pregunto es tan grave que exista dependencia?
    ¿Por qué nos cuesta aceptar que efectivamente sí la hay? ¿y por qué nos cuesta tanto aceptarla?
    Creo que tenemos miedo y deberíamos tener Confianza.
    Y la Confianza hay que trabajarla, porque se puede dar de forma natural, pero para mantenerla hay que trabajarla.
    Para sentir confianza, esta ha de ser bidireccional, la empresa en el empleado y el empleado en la empresa.
    Para que el empleado confíe en la empresa, creo que ésta tiene que ofrecerle funciones que le permitan desarrollarse como profesional, y que contribuyen a un proyecto que le interesa en aspectos económicos y también sociales, tecnológicos…, y fundamental debe sentir que el interés de la empresa en la persona.
    Invito a pensar menos en evitar la dependencia y sí en generar Implicación.
    Las personas implicadas en un proyecto son las crean futuro para el proyecto.
    ¡Un saludo a todos!

    1. Si, tener dependencia con una persona o tecnología es terrible.
      Pueden existir dependencias pero no hasta el punto de que los cambios, de personas y tecnológicos, sean impracticables. Por que si hay algo seguro en la vida, y más en el software, son los cambios.
      Así que estoy contigo, la dependencia hay que aceptarla, pero se acepta y se gestiona para que no nos pueda amordazar.

  4. Hola Javier,
    Una pregunta que siempre me surge con el tema de la documentación.
    Cuando hablas de «documentación que sirva de guía» me vienen dudas de hasta donde es una buena guía y a partir de donde nos encontramos con el problema de que ande siempre desactualizada.
    ¿Existe un «estado del arte» en lo que a procesos de documentación se refiere? Practicas recomendables y desaconsejadas.
    Un saludo

    1. Hola Ignacio,
      Quien dio una buena explicación de este tema, para mí fue Fowler cuando escribió el UML distilled, que lo escribió para mostrar como UML podía ser útil sin necesidad de escribir centenares de páginas con diagramas UML.
      Para mí, documentación mantenible, que podamos asegurarnos que sin mega esfuerzo que lo que contiene es realista, no necesariamente mostrando todos los detalles, y que sirva de de guía. Esto lo cumplen, por ejemplo, los mapas de la arquitectura del sistema, y no lo cumplen tanto los diagramas UML que muestran todos los detalles del código.
      Saludos

Dejar un comentario

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