Consejos para contratar una aplicación a medida
Tengo un compañero de profesión, programador, y compañero de empresa algunas veces, con el que me sigo encontrando puntualmente en determinados ámbitos laborales, que defiende una idea que me ha repetido varias veces: «Yo no hago los programas sencillos a propósito. No quiero que puedan llamar a cualquiera a modificarlos luego, y yo quedarme sin trabajo. Quiero ser imprescindible«
La verdad es que es algo que no comparto, pero es una verdad incómoda que varios compañeros de profesión siguen, aunque éste es de los pocos que, aunque en «petit commite», tiene los redaños de admitirlo.
No ignoro que en otras profesiones pueden darse casos similares, pero quizás la abstracción de los procesos automáticos hace más proclive esta «mala praxis» en el ámbito de la programación.
Pero no todo está perdido. Siguiendo una serie de consejos, los gestores de las empresas que deban contratar servicios informáticos pueden evitar la dependencia excesiva de un único profesional, que a la larga puede producir, y eso lo he visto, que por la falta de ese profesional, una empresa haya tenido que sustituir toda la aplicación informática porque nadie podía mantenerla o adaptar los cambios.
Propiedad.
Legalmente, una empresa es propietaria del código, si éste se ha desarrollado en su empresa usando sus sistemas, pero si no es el caso, el gestor o director de la empresa receptora del software debería en la medida de lo posible disponer y ser el propietario del código fuente del software. No es un tema baladí, ni mucho menos, y quizás es el más importante de los consejos aquí descritos. No fueron pocas, las empresas que debido a de la llegada del EURO, o el cambio al año 2000, y por no disponer del código fuente, tuvieron que abandonar sus aplicaciones a medida y comprar o desarrollar nuevo software.
Control.
Directores, gestores, o en empresas más grandes, los responsables, deben reunirse habitualmente y conocer el desarrollo del software. Para ello es necesario que dichos responsables dispongan de cierta alfabetización TIC. Los desarrolladores a menudo pecan, pecamos, de cierta falta de asertividad. El lenguaje usado es demasiado técnico sin darnos cuenta que al otro lado, la mayoría de las veces, no hay desarrolladores. Por eso el dominar un poco el lenguaje técnico es deseable en estos casos.
Documentación
Otra de las piedras angulares del control del software desarrollado para nuestra empresa es la documentación sobre el mismo. Y no me refiero a una explicación de que hace el programa. Eso lo puede redactar cualquier usuario avanzado del software. Me refiero a documentación técnica que posteriormente pueda ser entendida por otro desarrollador. Existen varios tipos de documentación técnica, todo dependerá de lo grande de nuestra solución y los lenguajes y sistemas implicados. Cualquier documento técnico que puedan darnos los desarrolladores o podamos exigirles es una inversión de futuro. No sólo por situaciones de «desaparición» del desarrollador o empresa desarrolladora, sino como soporte para analizar las implicaciones de futuras modificaciones o ampliaciones de nuestro software.
Conclusión
Hay que confiar en la profesionalidad de los desarrolladores de nuestro software, pero esta confianza no ha de ser ciega en ningún caso. Estos consejos nos pueden ahorrar sustos en el futuro y no incurrir en costes innecesarios en una aplicación en la que en su momento ya se hizo la inversión para implementarla.
Hace unas semanas IBM presentaba los nuevos iSeries dotados de Power8. Hace algunos años, cuando aparecieron las primeras máquinas con procesadores Power7 el salto evolutivo fue muy apreciable. Ahora después de que esos procesadores Power7 ya han pasado al mercado más doméstico (algunas consolas de última generación llevan Power7 en sus «tripas») de nuevo IBM nos sorprende con el Power8, demostrando porqué es uno de los fabricantes más importantes de procesadores.
