archivo

Archivos Mensuales: septiembre 2010

En muchas ocasiones el concepto de mantenimiento adaptativo se utiliza de forma incorrecta confundiéndose muy a menudo con el mantenimiento evolutivo, siendo dos tipos de mantenimiento que persiguen objetivos distintos.

Lo mejor es recordar las definiciones que Métrica V.3, hace de cada uno de estos mantenimientos:

– Mantenimiento evolutivo: “Incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambios en las necesidades del usuario.”

– Mantenimiento adaptativo: “Modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios en la configuración del hardware, software de base, gestores de bases de datos, comunicaciones, etc…”.

Con las definiciones por delante resulta bastante sencillo discernir un tipo de mantenimiento de otro, ya que el primero está centrado en un cambio en las necesidades del usuario o lo que es lo mismo, en una modificación de los requisitos funcionales de la aplicación (por muy pequeños o grandes que sean) y el segundo se basa en los cambios en cualquiera de los elementos que conforman el entorno sobre el que funciona el programa, a los ejemplos que indica Métrica V.3, yo añadiría los servidores de aplicaciones, servidores web e incluso las interfaces con terceros sistemas, es decir, si una aplicación se comunica con otra por servicios web y ésta modifica la interfaz el cambio a realizar en la aplicación es de carácter adaptativo ya que el requisito funcional (que es comunicarse con ese tercer sistema) no ha variado.

Lo fuí y mucho tiempo. Me hubiera gustado ganar lo que ahora mucho antes, me gustaría que cada mes mi nómina fuera mayor que la que tengo en estos momentos, en realidad y no es solo mi caso, es difícil determinar cuánto resulta suficiente.

Que quisiera cobrar más no quiere decir que no me sienta contento con lo que gano, probablemente en la facultad si me hubieran puesto un papel por delante indicándome que iba a tener el salario que tengo y sus condiciones laborales y lo hubiera firmado sin mirarlo. Estoy contento, si dijera lo contrario sería injusto, pero también mentiría si dijese que no aspiro a ganar más.

Como estoy contento no me planteo otras alternativas más allá de seguir desarrollando mi profesión en mi organización y realmente si termino por irme serán otras causas (y no precisamente económicas, salvo que la diferencia sea sensible), probablemente un proyecto, unas tareas que me resulten suficientemente motivantes.

Como sé lo que es ser mileurista, como lo he sido más tiempo del que hubiera deseado, como sentía que merecía ganar más de lo que ganaba y veía con frustración que no lo conseguía, sé de lo que hablo. De hecho para dejar de ser mileurista tuve que trabajar muchísimo porque tenía claro que el nivel de vida que quería tener estaba sostenido con alfileres con ese sueldo.

De hecho ahí está la clave de todo, en el nivel de vida que queramos tener, ya que ahí se sitúa el límite del gasto y por tanto de los ingresos que debemos tener. Cuánto más alto pongamos el listón más dinero necesitaremos ganar, de esta forma personas que cobran más dinero las pueden pasar canutas para llegar a fin de mes y personas que ganan menos pueden llegar más desahogadas.

No soy persona de grandes gastos o caprichos, quienes me conocen lo saben, tengo un coche pequeño y que ya tiene algunos años, no uso ropa cara, tengo una hipoteca acorde a mis posibilidades, etc…, por ese motivo mi sueldo actual me permite estar contento, ya que con él puedo mantener mi nivel de vida sin ningún tipo de presión, siendo mileurista la cosa estaría más apretada y tal vez algunos de mis hábitos tendrían que cambiar y esos autoregalos que me hago de vez en cuando (sobre todo por tener la capacidad de poder ahorrar) tendrían que diferirse en el tiempo.

No quiero ganar más dinero para elevar mi nivel de vida (por lo menos no es ese el motivo, aunque tampoco puedo asegurar que teniendo un colchón más amplio, casi sin querer adquiera algún hábito nuevo de gasto) sino porque siento que mi sueldo no está acorde con mi trabajo. Esto es un aspecto muy subjetivo, ya que como es lógico muchos no estarán de acuerdo con ello, pero en este caso, la única opinión que debe tener voz y voto es la de uno mismo.

Quiero dejar claro que respeto totalmente a aquellas personas que decidan llevar un nivel de vida superior o inferior al mío, ya que este tipo de decisiones son personales y yo no soy nadie para decir si mi decisión es más acertada o no en este sentido.

No es fácil salir del mileurismo en términos generales, ya que depende muchísimo del tipo de profesión que tenga cada uno, la preparación, etc… Yo me voy a centrar en lo que conozco que es el desarrollo de software, en donde el mileurismo es un objetivo en demasiadas ocasiones incluso lejano a los que empiezan en esta profesión porque eso es otra, se ha instaurado en las empresas que todos los que empezamos en esto tenemos que ganar poco dinero, ¿por qué? pues porque sí (evidentemente detrás hay motivos económicos y a menor salario, más margen de beneficios por tu trabajo, esto es respetable, ya que las empresas están para ganar dinero, pero también sería respetable, porque nosotros también queremos ganar dinero, que las condiciones laborales medias de los que empiezan en esta profesión sean superiores a las actuales, no obstante veo bastante complicado que esto cambie).

Como la base de partida es pequeña, para empezar a ganar un dinero relativamente decente tenemos que dejar pasar bastante tiempo y comernos bastantes marrones (el tiempo puede ser mayor o menor en función de nuestras capacidades y de que alguien nos apoye, menciono la palabra apoyo porque no solo vale con hacer el trabajo bien, sino en conseguir que alguien lo aprecie de verdad y eso no siempre se va a encontrar).

En el desarrollo de software se sale del mileurismo con paciencia y con trabajo (no son ingredientes ni necesarios ni suficientes, pero son una buena base), si se quieren atajos habrá que ir a buscarlos, que consistirá básicamente en encontrar a alguna empresa que te pague uno o varios escalones más de lo que cobras en la actualidad (por regla general, incluso en etapas como la actual, se puede conseguir), ahora bien, cuando se tome esa decisión hay que hacerlo teniendo muy claras las consecuencias y si el motivo para irse a otro lado es meramente económico mi recomendación es que solo se haga si se tiene claro que realmente en tu trabajo actual tu progresión salarial es por debajo de la que deseas (o necesitas) y resulta complicado romper esa tendencia, esto es así porque si el motivo es solo el sueldo quiere decir que los otros aspectos de tu trabajo resultan satisfactorios (es difícil que exista siempre un solo motivo para algo, generalmente es la suma de ellos lo que nos hace tomar unas decisiones u otras, pero en este caso lo que quiero indicar es que la causa principal, la que tiene un peso que supera al de las demás sumadas entre sí, es el factor económico).

Un aspecto está claro, si uno no mira por uno mismo no debe esperar a que otros lo hagan por ti, por tanto el primer paso para salir del mileurismo lo tiene que dar uno y sobre todo se debe ser consciente de que se puede tardar tiempo en salir de ahí, de hecho incluso a veces es mejor esperar más y tener más base que buscar soluciones más rápidas ya que cuanto más desarrolladas estén nuestras habilidades y mayor sea nuestra experiencia, más valdremos en nuestra empresa y fuera de ella, de manera que tendremos un precio de mercado y ya será decisión de cada uno (del trabajador y de la empresa) determinar la solución a esta ecuación.

Como he dicho en otros artículos hay otros aspectos que sin tener una recompensa económica directa sí que la tiene de forma indirecta. La posibilidad de tener un mayor tiempo libre en el que podamos hacer lo que queramos vale dinero (incluso más que el material), el sentirse integrado, satisfecho y la capacidad de aprendizaje y desarrollar habilidades, también tienen su valor.

Es cierto que llega un momento en la vida de cada persona donde es necesario que el dinero sea el suficiente para colmar sus necesidades (o aspiraciones) y eso solo lo da el dinero físico, el que se refleja en la nómina. Por tanto, es en esta circunstancia o bien la recompensa no monetaria no termina de compensar cuando muchos se plantean buscar otras soluciones, generalmente si aprecian que si situación actual, sin cambios, resulta difícil de cambiar.

La documentación de los proyectos es un asunto muy controvertido y en el que en la comunidad de desarrolladores hay prácticamente tantas respuestas como personas a las siguientes preguntas:

¿Tiene utilidad la documentación de un proyecto?

¿Cuál debería ser la documentación mínima exigible?

En este artículo voy a dar mi opinión siendo consciente de que probablemente gran parte de los lectores no se sienta identificado con la misma, pero como he dicho muchas veces leer o escuchar opiniones diferentes nunca está de más.

Sobre si tiene utilidad documentar un proyecto no puedo dar una respuesta absoluta. Depende. Casi prefiero un proyecto sin documentar que un proyecto con documentación deficiente, ya que el resultado es el mismo y no se habrá gastado esfuerzo en balde. Por tanto para pueda servir la documentación de un proyecto ésta debe ser de calidad. Es importante señalar que no estoy hablando de cantidad, sino de calidad, es decir, la poca o mucha que haya, que sea buena.

Cuando hablo de calidad me refiero no solo a que los modelos e información que se reflejen en los documentos estén bien hechos sino que sean acordes a la realidad de lo que posteriormente se va a implementar. Muchas veces se tiene ejecutado un análisis y un diseño y después cuando se está construyendo se toman determinadas decisiones que no han tenido reflejo en la documentación.

Lo ideal es que además cuando se hablase de calidad lo estuviéramos haciendo en el sentido de que las decisiones reflejadas en la documentación sean adecuadas, es decir, que los requisitos que se hayan tomado sean buenos, que los modelos y arquitectura representados sean coherentes, etc…, sin embargo una documentación puede ser válida aunque se hayan cometido errores en los procesos de análisis y diseño (que, por otra parte, no es solo algo probable sino algo totalmente cierto), lo importante, es que lo que contega, tal y como he comentado en el párrafo anterior sea acorde con lo que se ha hecho y si en la construcción hay que hacer cambios respecto a lo planificado que dichos cambios estén recogidos en la documentación.

Si la documentación es buena sí que puede tener utilidad (no es condición suficiente). Todos (no soy una excepción) hemos renegado de la documentación de los proyectos de desarrollo de software, sin embargo, siempre nos acordamos de ella cuando la necesitamos y no disponemos de la misma (fundamentalmente cuando nos queremos integrar con un tercer sistema o cuando adoptamos un sistema de información que se encuentra en etapas tardías del desarrollo o en mantenimiento).

Otro característica que debe tener la documentación sea útil es que sea sostenible con el futuro mantenimiento del proyecto, si no es así, gran parte de la documentación quedará desactualizada en el proceso de mantenimiento (que recordemos, según Robert Glass supone entre el 40% y el 80% del montante total del proyecto, siendo un 60% mejoras). Por tanto, no debemos pedir en los proyectos, documentación que después no podamos mantener (quedará muy bonito como histórico del proyecto e incluso puede tener una cierta utilidad para comprender los objetivos del mismo, pero al final, si se quiere entrar en detalle habrá que pelearse con el programa). Como es lógico queda fuera de esto la documentación propia de la gestión ordinaria del proyecto como por ejemplo actas de reuniones, documentación de referencia, etc… que forman parte del día a día y que no requieren actualización. También es importante señalar que la estrategia de la gestión de la configuración de la documentación debe permitir que dada una determinada versión del programa, podamos rescatar la que le corresponde a la misma (no es tan fácil como parece).

Hay que tener en cuenta también que aunque se dispongan de los medios necesarios, lo mismo la naturaleza del proyecto no requiere una documentación extensa, eso es necesario valorarlo y no invertir más dinero y esfuerzo que el que realmente se requiere (hay que tener en cuenta que buena parte de los modelos se pueden obtener por ingeniería inversa).

Si la documentación es de calidad y acorde a los medios presentes (y que se estimen futuros) del proyecto ya se va por el buen camino, pero siguen sin ser suficientes para que la documentación cumpla todo lo que debería ser su propósito, ya que no solo debe dejar rastro de lo que se ha hecho y de cómo está en la actualidad el sistema de información sino que la misma debe formar parte del proceso de desarrollo, es decir, la construcción del sistema de información no debe ser una cosa y la documentación otra, sino que lo que se construya debe ser resultado de dicha documentación.

Utilizar la estrategia de integrar la documentación de los proyectos en el proceso de desarrollo no asegura nada, ya que la ejecución final puede ser deficiente, el análisis y el diseño pueden tener errores, etc… y además se pueden construir sistemas que funcionen de manera adecuado sin haber documentación de por medio. Pese a la no existencia de garantías, yo sí creo en que el proceso de desarrollo de software es un proceso de ingeniería y que cuanto más y mejor se aplique mejores resultados se obtendrán.

Por tanto y a grandes rasgos, para que una documentación pueda ser de utilidad debe integrarse en el proceso de desarrollo, ser de calidad y acorde a las posibilidades que se prevén tengamos en el futuro mantenimiento.

Estoy convencido de que la teoría de la evolución es perfectamente aplicable al desarrollo de software, ya que soy de la opinión de que el entorno en el que se trabaja y la especialización que exige moldea la forma de trabajar de quien habita en ese ecosistema.

Cuantas más variantes plantee el ecosistema o en más ecosistemas se haya habitado más características se añadirán a nuestras habilidades y más posibilidades tendremos de prosperar ante condiciones cambiantes.

Voy a tomarme como ejemplo, a lo largo de mi trayectoria profesional, como ya sabréis los seguidores habituales de mi blog he trabajado hasta ahora en dos organizaciones, en una casi seis meses como becario y en otra más de siete años realizando de tareas de bastante más responsabilidad. La primera en términos de tiempo y de características del trabajo podría pensarse que no es representativa, pero la verdad es que tuve la oportunidad aunque fuera poco tiempo de ver las cosas desde otra perspectiva y aunque sea poco, forma parte de mi ADN laboral.

Dado que la mayor parte de mi trabajo lo he desarrollado en la misma organización realizando tareas de gestión de proyectos, reconozco que estoy bastante especializado en mi entorno y en mis tareas, lo cual no asegura que en un entorno distinto yo pueda funcionar o rendir de la misma manera. Esto que es extensible a mi persona es extensible a cualquiera, es decir, uno puede destacar en un tipo de entorno laboral y ser un cero a la izquierda en otro (no es cuestión evidentemente de que se den extremos, pero lo he puesto de esa manera para que el mensaje tenga más fuerza). Dado que solo conozco (prácticamente) un ecosistema laboral solo puedo garantizar un comportamiento similar en un ecosistema que tenga unas condiciones semejantes, mi comportamiento en otro tipo de ecosistema no lo puedo predecir (sí que sé que pondría el máximo empeño, conocimientos, experiencia y profesionalidad y que eso siempre es una buena base, pero probablemente requeriría de un período de adaptación al nuevo medio).

Dentro de las limitaciones de cada ecosistema si se quiere seguir evolucionando dentro de él es necesario explorar la biodiversidad que se encuentra en él, es decir, podemos especializarnos todavía más o bien adquirir nuevas habilidades. En mi caso la diversidad viene dada por los diferentes proyectos de desarrollo de software en los que participo, en los cuales se abarcan temáticas y tecnologías diferentes y tengo la posibilidad de interactuar con especies de otros ecosistemas (los proveedores).

También es válida la interacción indirecta a través de la lectura, la reflexión y otras técnicas que permiten dirigir la mirada más allá de nuestro entorno.

No quiero que parezca este artículo un alegato contra la especialización, de hecho si eres muy bueno en algo concreto tal vez sea mejor que ser simplemente uno más en muchas cosas, lo que vengo a decir en él que nuestra evolución profesional depende mucho de dónde nos movamos y de que seamos capaces dentro o fuera de nuestro entorno laboral de asumir retos que nos permitan seguir creciendo.

Alan Jay Perlis fue catedrático en ciencias de la computación siendo su principal área de especialización los lenguajes de programación.

He escogido esta cita (Alan Perlis puede ser un desconocido para muchos de nosotros, pero en el año 1966 recibió el primer premio Turing de la historia por su contribución en las técnicas de programación y en la construcción de compiladores, por lo que su opinión resulta muy relevante) porque refleja un aspecto muy importante del desarrollo de software y que se ha mantenido constante desde los inicios de esta disciplina (hay que tener en cuenta que esta cita junto con otras muchas fueron publicadas en el año 1982, cuando contaba ya con 60 años y en ellas, en un tono desenfadado, Alan Perlis trata de exponer algunos aspectos que había aprendido en relación a lo largo de la programación a lo largo de su carrera) y es que resulta prácticamente imposible entregar una aplicación sin errores (podrán ser más graves, podrán ser más leves), pero siempre terminarán pasando a producción, la clave es que los más importantes se hayan detectado y corregido antes y que el software desarrollado sea lo más fácil de mantener posible.

Alan Perlis comentó que: “Hay dos formas de escribir programas sin errores; solo la tercera funciona”.

Como decía antes, tener conciencia de que es muy difícil que un producto llegue al usuario sin errores, no quiere decir que se deba descuidar su detección en el proceso de desarrollo (y cuanto antes mejor), sino de que hay que dedicar el esfuerzo necesario para filtrar todos los que sean posibles (y tener claro, que es necesario realizar esa tarea y a ser posible, una vez que el desarrollador le haya dado las revisiones oportunas, por personal distinto al que ha participado en el proyecto), hasta unos límites que se consideren adecuados, ya que más allá de eso, el esfuerzo no compensará, ya que para detectar y corregir pequeños errores habrá que dedicar mucho tiempo, sobre todo teniendo en cuenta que cuando el producto llegue a producción necesitará nuevos retoques hasta ajustarse realmente a lo que necesita el usuario.

Recuerdo una frase (tal vez os haya hablado ya de ella en algún otro artículo) que me comentó un compañero de la empresa en la que trabajé antes de incorporarme a mi organización, justo el día antes de irme (iba a pasar de compañero a cliente en 24 horas): “…dentro de un año, probablemente ni nos hablemos…”.

Se equivocó, de hecho participamos en algunos proyectos juntos y salvo los desacuerdos lógicos que se producen en estos casos, seguimos hablando y teniendo una buena relación. Más tarde él empezó a trabajar en proyectos de otros clientes, pero siete años después ambos podemos decir que no se cumplió lo que predijo. ¿Podría haberse dado? Es posible, pero los proyectos funcionaron de manera adecuada, lo que propició una relación cliente y proveedor en la que cada cual defendía sus intereses, pero en la que había respeto.

Las relaciones clientes/proveedor son complicadas y es muy difícil que no se tengan roces. De hecho si me pongo a pensar en estos siete años que llevo dirigiendo proyectos no recuerdo un proveedor (hablo en términos de empresa) con el que no haya tenido algún problema y eso es normal, yo defiendo y exijo lo que creo que debo defender y exigir, el mismo derecho tiene el proveedor, a veces ellos tienen razón, otras yo, a veces gano yo, a veces ganan ellos y a veces ninguno. Lo importante por encima de lo anterior es el respeto y de la misma manera que he dicho que probablemente haya tenido uno o más períodos de crisis con los distintos proveedores con los que he trabajado, es igual de cierto que en la mayoría de los casos se ha mantenido el respeto entre las partes.

Si se está en este negocio es prácticamente imposible pretender que las relaciones siempre vayan como la seda, eso no es realista, hay que estar dispuesto a asumir que habrá períodos de crisis y circunstancias poco agradables y que estas vendrán solas porque los proyectos de desarrollo de software son complejos y porque detrás siempre hay un trasfondo económico.

Habrá momentos buenos, normales y malos, como en la vida. Ahora bien, lo que desde mi punto de vista marca la diferencia en proveedores y en clientes es cómo afrontes cada uno de esos momentos y particularmente los períodos de crisis, ya que en circunstancias delicadas no hay que perder el control, unas palabras fuera de tono o unas decisiones erróneas pueden provocar la pérdida de confianza de un cliente o la pérdida de confianza entre ambas partes y si no hay confianza es complicado trabajar persiguiendo objetivos comunes.

Cuando se pone una aplicación en producción, no tiene acogida entre el grupo de usuarios y tampoco cuenta con el apoyo de la dirección, existen dos opciones principalmente, dejar que desaparezca por inanición o intentar que el producto se utilice.

Partiendo de la base de que la aplicación es para los usuarios y no para el departamento de informática (en el caso de que no sea una aplicación de uso interno), no tendríamos ningún tipo de obligación de promocionar el uso de la herramienta pero lo que pasa normalmente es que cuando participamos en un desarrollo lo sentimos como algo nuestro y por eso nos causa un cierto grado de satisfacción que el resultado de nuestro trabajo pueda ser útil a los demás.

Existen muchas causas por las cuales una aplicación no tiene buena acogida entre el grupo de usuarios, una de las principales suele ser un cambio en la forma de trabajar pero otra (totalmente compatible con la anterior) suele ser que el producto tiene muchos fallos o que no cumple las expectativas creadas.

Si un producto tiene muchas incidencias, se ha puesto en producción y no hay posibilidad de marcha atrás nos encontraremos con una situación que va a durar bastante en el tiempo, sobre todo si el sistema tiene una cierta entidad, por lo que vamos a tener los usuarios descontentos un largo período y muchos de ellos tendrán la tentación de abandonar el uso de la herramienta.

Ante esto podemos optar por consolidar el producto, es decir, dedicar los esfuerzos a la corrección de las incidencias o bien compaginar lo anterior con la inclusión de ampliaciones funcionales, cargas de datos, documentación, etc… que pueda hacer el sistema más atractivo y útil. La verdad es que la disyuntiva es complicada y habría que estudiar cada caso en particular antes de optar por una estrategia u otra. Yo he sido mucho de optar por estrategias orientadas a hacer la aplicación más útil, incluso dedicando un mayor esfuerzo o equivalente que la consolidación del producto, a día de hoy pienso que es mucho mejor dedicar más atención a consolidar el sistema que a incluir ampliaciones funcionales antes de tener una cierta base sólida ya que conforme se vayan reduciendo el número de fallos, se reducirá la presión y se tendrá el camino más despejado para ir incluyendo novedades poco a poco.