Procedimientos
Demasiadas veces se confunde procedimientos con burocracia. La burocracia puede llegar por varios factores, procedimientos demasiado complejos o demasiado celo en el cumplimiento estricto del procedimiento (en este segundo caso el problema no es el procedimiento, sino las personas).
Cada vez soy más partidario de que existan procedimientos, creo que es la forma menos mala de que haya un orden y en consecuencia haya menos arbitrariedad, aunque para ello se debe renunciar a algo de flexibilidad.
Los procedimientos describen situaciones, delimitan competencias y generan obligaciones, lo cual en muchos casos evita problemas y reduce malos entendidos, ya que por lo menos establece un marco de referencia. Y además permiten medir, algo que me antoja fundamental si se quiere mejorar en la organización.
La flexibilidad: una clave
Ya he comentado en algún post que contra una hoja de cálculo, una base de datos tipo Access, un procesador de textos y una unidad de red o local, no puede competir ningún sistema de información corporativo, absolutamente ninguno, por muy bien que esté hecho.
La clave es la flexibilidad. Los usuarios pueden hacer lo que quieran.
Inconvenientes: muchísimos.
Es por eso por lo que los sistemas de información corporativos deben existir, pero no deben olvidar que uno de los fines que tiene es servir al usuario final para que pueda ejecutar eficientemente su trabajo. Un sistema de información poco usable y complejo tiene complicada su supervivencia.
Dentro de la compleja ecuación que se tiene que resolver para que un sistema de información sea de calidad y cumpla su propósito, una de las variables más importantes es que la solución que se ofrezca sea flexible y que no suponga una carrera de obstáculos su uso por parte del usuario final.
Estrategia conservadora
Hace poco, entre un compañero que hace las tareas de asesor técnico de mis proyectos y que además colabora en la dirección de unos cuantos y yo, tuvimos que decidir qué tipo de solución dábamos a un proyecto, si la teóricamente perfecta o si aplicábamos una estrategia más conservadora.
El proyecto tiene como objetivo que a través de una aplicación web se puedan realizar consultas alfanuméricas, cartográficas y documental, en base a la información que se ha generado en diferentes sistemas de información (más de diez), residente dichos datos en organizaciones, formatos y tecnologías distintas, los cuales además pese a tratar una temática similar se han implementado, en la mayoría de los casos, como departamentos estanco.
La mejor solución, en un entorno de desarrollo y explotación de software de software ideal, sería captar la información en línea mediante servicios web de las distintas aplicaciones origen, cada vez que se realice una consulta. Sin embargo en un entorno tan heterogéneo como el que comento, en el que la información a consultar en cada sistema, puede ser abundante en función de la consulta que se realice y según el sistema que se consulta, en el que además es complicado controlar y conocer las modificaciones que pueden producirse en los modelos de datos de los sistemas fuentes de la información y en el que la predicibilidad de la disponibilidad de los sistemas es complicada, así como el comportamiento de la red, pensamos que una solución basada en servicios web, podría ser bastante arriesgada y corríamos el riesgo de que una vez implementada la solución, tal vez la mejor conceptualmente, tuviéramos que volver atrás ya sea por un mal rendimiento del sistema, por no asegurar un mínimo de disponibilidad de la información o por la suma de dichos factores y otros más.
Por este motivo tomamos la decisión de buscar una estrategia conservadora, basada en crear un repositorio central de información que persista la información de los sistemas origen que nos interesa, siendo el proceso de carga de datos orientado a la transacción (la carga de datos se hace completamente o no se hace) y orientado a las características de actualización de la información que se carga, es decir, no todas las fuentes de información cargarán información en el repositorio central en el mismo proceso, sino que las cargas se adaptarán a sus características. De esta forma, la complejidad será la misma que en la solución conceptualmente más aceptable en cuanto a que hay que recopilar la información de los sistemas de información origen, pero la persistencia de la información en una base de datos, reducirá hasta tender a cero los errores por no poder acceder a los datos (en todo caso se accedería a información menos actualizada) y por supuesto el rendimiento mejoraría, ya que la información se almacena en la base de datos central debidamente tratada y dispuesta para su consulta a través de la aplicación.
Ahora toca el proceso de implementación de la solución elegida. Esperamos haber tomado la decisión correcta.
El usuario
Sí. Todo lo que hacemos tiene como objetivo ofrecer un servicio a un conjunto de usuarios, ya sean de tu organización, de otras o el conjunto de la ciudadanía.
Dar ese servicio es responsabilidad no solo de los departamentos de desarrollo de software de las organizaciones, sino también de los departamentos de sistemas y explotación, ya que al fin y al cabo lo que los usuarios reciben es la suma de la calidad del producto software, el rendimiento y disponibilidad del sistema y la calidad de la atención a usuarios (en el caso de que sea necesaria).
Cuando un usuario tiene un problema con un sistema de información, las culpas siempre van dirigidas al mismo, ya que al fin y al cabo ellos no tienen por qué entender que para que en su navegador (en el caso de una aplicación web) se vea la aplicación influyen muchos factores. Es por esto por lo que en ocasiones se vincula mucho a los usuarios con los departamentos de desarrollo, vinculación que sí que debe ser cierta en la fase de elaboración y puesta en marcha del producto, pero que no debe ser tan directa una vez que el producto se encuentra en producción y se ha realizado la correspondiente y necesaria gestión del cambio. Es decir, el usuario reportará dudas sobre el uso de la aplicación, incidencias de funcionamiento y en algunas ocasiones evolutivos, pero todo ello debe pasar (salvo en el caso de algunas peticiones de evolutivos) previamente por un punto único de acceso que no debe ser otro que el Centro de Atención a Usuarios.
En cualquier caso, algo que nunca se debe olvidar a un desarrollador de software es que el software se debe implementar pensando en que al final va a haber un usuario que lo va a utilizar.
Gestión del conocimiento
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.
8 de julio
Parece que fue ayer, pero hoy hace seis años que empecé a trabajar en mi organización. Han pasado muchísimas cosas, casi de todo me atrevería a decir, pero aqui sigo y probablemente siga siendo mi centro de trabajo a corto y medio plazo.
Lo mejor de estos seis años ha sido todo lo que he aprendido, mucho más de lo que me enseñó la Universidad. No reniego de mis años universitarios, antes al contrario, me divertí muchísimo y también me enseñaron muchas cosas, pero la organización en la que trabajo ha sido desde el primer día una dosis de realidad, de mundo real, de informática, de TICs, de todo eso junto, agitado en una coctelera a una velocidad de vértigo que no para nunca. Seis años en mi organización son muchos años, cualquiera que trabaja dentro de ella o con ella, lo sabe.
De becario en una gran empresa de desarrollo de software pasé a ser jefe de proyectos en mi organización, de manera accidental eso sí, no soy el típico tipo de personas que a la primera (ni a la segunda, ni a la tercera, ni a la cuarta… ni a la trillonésima) parece un genio, de hecho no lo soy. Si no se hubiesen dado las circunstancias adecuadas desconozco cual hubiera sido mi trayectoria profesional. La cosa es que prácticamente estos seis años me los he pasado dirigiendo proyectos. Me he saltado muchas etapas, lo que me ha provocado algunas deficiencias formativas (no poseo una gran capacidad técnica), pero me ha llevado a lo que realmente me gusta que es la gestión.
Me queda muchísimo por aprender, de hecho cada noche me acuesto siendo consciente de que sé menos que el día anterior, pero no porque no haya aprendido nada o haya desaprendido algo, sino porque me doy cuenta de que hay nuevas esquinas, nuevas aristas por explorar y que el mundo gira muy deprisa, mucho más rápido de lo que puedo avanzar yo.
¿Cuándo terminará mi ciclo en la organización? Lo dije hace mucho tiempo, creo que antes siquiera de cumplir dos años en la misma. Mi grado de satisfacción en mi organización va como una onda senoidal y cuando coincida una sima de la misma con una posibilidad de irme a un sitio y a un puesto de trabajo que me satisfaga lo haré. Hasta ahora cuando he sentido deseos de irme no había puertas abiertas y cuando han existido puertas abiertas no tenía deseos de irme (o no he podido). En cualquier caso es cuestión de tiempo que la coincidencia se produzca.
En cualquier caso, soy consciente de ser un afortunado por estar donde estoy y por tener el trabajo que tengo, y pese a que nadie me ha regalado nada, salvo mis padres que pagaron con su trabajo y sacrificio mi formación, no puedo dejar de agradecer la inmensa suerte que me ha llevado hasta aqui.
La fiebre del CMMI
De un tiempo a esta parte me estoy encontrando con que la mayoría de las empresas de desarrollo de software que conozco o bien se están certificando en CMMI (Capability Maturity Model Integration) o bien ya se han certificado en los niveles 2, 3 o 5 (y siguen haciendo los movimientos oportunos para llegar al máximo nivel que pueden llegar que es el 5).
De CMMI conozco más bien nada, más allá de que es un conjunto de modelos y prácticas cuyos objetivos finales que no son otros que la mejora de los procesos de ingeniería y desarrollo del software, ingeniería de sistemas y la adquisición de aplicaciones.
No tengo base para decir si la certificación en CMMI es una moda que ha provocado un movimiento en las empresas desarrolladoras de software para quedar empatadas con la competencia en este aspecto o si bien sí que produce resultados satisfactorios en las mismas y sí que consigue los objetivos que persigue.
Espero tener tiempo en los próximos meses para aprender un poquito sobre CMMI y en base a ello hablar con un poquito más de propiedad. En cualquier caso, no me extraña que la certificación masiva de empresas de desarrollo de software en CMMI, haya provocado un efecto llamada en las demás, para no quedarse atrás y por lo menos, como comenté antes, ponerlas en situación de empate con las demás.
No obstante, la certificación en CMMI podría provocar más que probables cambios en la gestión internas de las empresas de desarrollo de software, por lo que antes de ir a ciegas y conseguir cueste lo que cueste esta certificación, yo lo que haría sería formarme lo máximo posible en CMMI para estudiar cuáles serían las consecuencias en mi organización y si traería más beneficios que inconvenientes y también escrutar el mercado y conocer si las empresas y organizaciones que contratan desarrollos de software se están empezando a fijar en si una empresa está certificada en CMMI o no y en qué niveles.
Caminando sobre frágiles bases funcionales
Bien es cierto que muchas veces las circunstancias del proyecto: falta de tiempo, falta de implicación y/o de criterio por el usuarios, etc… impiden hacer un análisis funcional de calidad, pero independientemente de eso hay que intentar realizar el mejor trabajo posible, de ahí la importancia de la experiencia y habilidades que debe tener un buen analista funcional.
También es cierto que otras veces se le da menos importancia al análisis funcional dando más peso a la solución tecnológica o simplemente a intentar conseguir un resultado y esto en la mayor parte de las ocasiones es un problema, porque no hay nada más peligroso en un sistema de información que el hecho de que camine sobre frágiles bases funcionales ya que tarde o temprano, ya sea en el propio sistema o viéndolo globalmente con el resto de sistemas de la información de la organización, terminará mostrando sus carencias y/o sus deficiencias y todos sabemos lo que cuesta parchear una aplicación informática.
Todo el que desarrolla sabe que los errores detectados en etapas tempranas como por ejemplo la etapa de análisis funcional son más baratos de solucionar que los errores detectados en etapas sucesivas, por eso, hay que intentar conseguir el mejor análisis funcional posible, teniendo en cuenta lo comentado en el primer párrafo y es que muchas veces por mucho que se quiera la calidad del mismo se ve afectada por factores externos.
Infraestructura homogénea
En mi organización salvo los elementos de la infraestructura de desarrollo, que se encuentran administrados por un equipo específico de personal, toda la infraestructura de servidores de aplicaciones y de sistemas de gestión de base de datos se encuentran en máquinas con sistemas operativos de la familia UNIX (concretamente AIX) o en máquinas con sistemas operativos de la familia Linux.
Hace poco planteé la posibilidad de instalar un servidor de aplicaciones en una máquina con sistema operativo Windows ante la dificultad que presentaba una aplicación para conectarse con un motor de datos que requiere necesariamente su instalación en máquinas Windows. Los responsables de sistemas me recomendaron que hiciéramos los estudios correspondientes para evitar esto, ya que ellos querían tener todos los servidores de aplicaciones bajo una infraestructura común, también comentaron que si no solución sí que permitirían la instalación de un servidor de aplicaciones en una máquina Windows. Tras el estudio correspondiente y no pocas horas de esfuerzo se consiguió que la aplicación funcionase instalada sobre un servidor de aplicaciones sobre Linux atacando al motor de datos que necesaria e inevitablemente se encuentra en una máquina Windows.
Lo de la infraestructura homogénea creo que es una buena idea, ya que facilita, sin dudas, las tareas de mantenimiento, por este motivo me alegro de que se encontrase una solución que no rompiera con esa filosofía de funcionamiento.
