Jummp’s Blog

Hace unas semanas tuve una reunión con un proveedor de software en la cual, entre otros temas, hablamos de una serie de evolutivos que había que hacer sobre un producto software que se había puesto en producción dos meses atrás. El proveedor me comentaba que si dedicabamos presupuesto a realizar esos evolutivos, podríamos quedarnos sin presupuesto para el desarrollo de algunos de los sistemas de información que estaban programados y que formaban parte de ese contrato (la famosa teoría de la manta: que si te cubres los pies te dejas la cabeza al aire y si te tapas la cabeza lo que dejas al aire son los pies).

Mi respuesta fue que dada la buena acogida que había tenido la aplicación entre los usuarios, que lo que habían solicitado no era algo desproporcionado en esfuerzo y además iba a permitirles mejorar la eficiencia y experiencia en el uso de la aplicación, se desarrollasen los evolutivos.

El motivo es que la aplicación es una realidad, ha pasado el durísimo proceso de desarrollarse e implantarse y además los usuarios se están adaptando a la misma, las otras aplicaciones son importantes también que se hagan, pero hasta el momento son proyectos, llegado el momento, si hiciera falta, se reduciría el alcance de alguna de ellas para que entrase en presupuesto, pero que lo importante es dejar la aplicación que se ha puesto en producción perfectamente rematada.

Otro error muy común en el proceso de desarrollo de software (y en el que yo también he caído) es olvidar que el producto que se está implementando no es para nosotros sino para el usuario final e independientemente de que tengamos la sensación de que conozcamos perfectamente lo que quiere el usuario o que dominamos la materia, tenemos que buscar hasta donde sea posible la implicación del usuario, no solo durante el proceso de definición del sistema, sino durante el proceso de construcción.

Si los que nos dedicamos al desarrollo de software, que ya tenemos una cierta experiencia en abstraer problemas, nos encontramos con dificultades en numerosas ocasiones para llevar a un programa de ordenador un determinado proceso y nos damos cuenta muchas veces cuando se está construyendo que hay piezas que no encajan, ¿podemos pedir al usuario que tenga esa misma capacidad de abstracción?, algunos pensaréis: “era obligación del usuario leerse el análisis”, ¿de verdad pensáis que el usuario puede llegar mucho más allá del análisis de requisitos, de la descripción de casos de uso, de la revisión de las interfaces de usuario y su navegación?, salvo que el sistema no sea excesivamente grande, que los entregables que acabo de indicar se realicen de la forma más completa, exacta y clara posible, y que el usuario se esmere en repasarlos (y aún así), quedarán resquicios que cuanto más se tarden en corregir más costosos serán para el desarrollador.

Lo que acabo de comentar en el párrafo anterior no es un vale todo para el usuario, es decir, éste debe asumir su responsabilidad en el proyecto y de alguna u otra forma se lo tenemos que hacer ver. El desarrollo de software no se hace con una pizarra y una tiza, donde se puede borrar y volver a escribir libremente, es un proceso tan complejo en el que no vale la barra libre. Lo que vengo a comentar es que en el desarrollo de software se debe ser consciente de que cuanto más se tarde en detectar un error más vale corregirlo y que los usuarios en la mayoría de los casos no toman conciencia del programa y de los problemas hasta que se enfrentan a él. Como podéis ver se trata prácticamente de dos extremos, de hecho cuanto peor se hagan las cosas (por parte del desarrollador y del usuario (por no hacer frente, este último, a su responsabilidad)) se cumplirán ambos extremos, lo que provocará que el proyecto salga caro (lo cual puede repercutir sobre el usuario o sobre el desarrollador (más bien, sobre este último)) y que la calidad del mismo se vea muy perjudicada.

Por tanto, es importante que no olvidemos que las aplicaciones se desarrollan para los usuarios y que por tanto hay que buscar la mayor implicación posible por parte de los mismos en todo el proceso de desarrollo de software. ¿Qué el usuario no se implica? Hay que intentar que siempre quede patente este hecho (evidentemente hay que saber hacerlo con tacto), ya que más adelante si el proyecto no ha salido como debía y hay que empezar a parchear, que todo el gasto de ese parcheo no repercuta directamente sobre el desarrollador.

Hay un dicho muy utilizado que dice que si algo funciona no hay que tocarlo (muy usado en el mundo del desarrollo de software y con mucho acierto) y puede ser válido en la mayoría de los casos en el mundo de los negocios.

No obstante, el mercado tiene a no permanecer estático ya que su equilibrio depende de un gran número de variables y además ese movimiento puede realizarse a distintas velocidades. Esto implica que si una determinada forma de hacer negocio funciona en un momento concreto del mercado, no tiene por qué funcionar en otro, de manera que si se quiere seguir funcionando con un nivel de éxito similar es necesario adaptarse al mercado (y cuanto antes comience ese proceso de adaptación, por la detección temprana del cambio de marco, menor será el impacto que sufrirá la empresa).

Con el cambio de mercado (y/o de las reglas del juego del mismo) se produce una adaptación de su ecosistema al mismo, en el que los que hayan conseguido evolucionar antes y darse cuenta de las nuevas variables tendrán más posibilidades de tener éxito en este nuevo entorno, los que no evolucionen o evolucionando lo hagan más tarde también tendrán dificultades al existir otras empresas ocupando su hábitat y que se han convertido en tan fuertes o más fuertes que la suya y con las que tendrá que competir para conseguir alimento (negocio).

Un ejemplo de lo que acabo de comentar lo tenemos en Microsoft que no se llegó a subir a tiempo a lo que es Internet y la WWW y tras muchos años y muchísimo dinero invertido sigue sufriendo a día de hoy las consecuencias de su inmovilismo inicial ante el mercado y su ecosistema.

La evolución del mercado crea oportunidades y puede provocar problemas, todo depende de la capacidad de poder predecir sus movimientos, de detectar cuando comiencen a hacerse, de las decisiones que se tomen y de lo que se tarde en aplicarse.

En un mercado tan inestable (ante la continua evolución de la tecnología y la innovación) como es el TIC en general y el desarrollo de software en particular, la capacidad de adaptación resulta esencial para poder sobrevivir. Es cierto que las empresas fuertes, con una red de clientes sólida y solvencia técnica son más estables a estas oscilaciones que las pequeñas, pero nunca deben olvidar por un lado lo que le pasó a Microsoft y por otro de que la competencia con otras empresas fuertes desgastan y que la tendencia de este tipo de empresas es hacerse con todo el negocio posible y que evidentemente el mercado es finito y la parte de su pastel que se coma otro es una parte del pastel que no te comes tú.

Ya nos pasó a todos cuando estudiábamos. Cuando más conseguíamos rendir era en los días previos a los exámenes. Muchas veces ese sprint final permitía que llegásemos al aprobado o consiguiéramos mejores notas, pero si se dejaba todo en manos de ese último impulso podría ocurrir que no diera tiempo de estudiarnos todo el temario con la suficiente profundidad y suspender (o no sacar la nota que nos habíamos marcado como objetivo).

Los seres humanos somos así, la cercanía del momento decisivo hace que nos pongamos las pilas y empecemos a rendir con el nivel que hubiéramos deseado desde el principio.

En el proceso de desarrollo de software se repite, como no podría ser de otra forma, esta máxima, normalmente la proximidad de una fecha de entrega mejora el rendimiento y productividad del equipo (por regla general, también la cantidad de tiempo que se dedica al proyecto, empujado por la necesidad de querer cumplir los plazos). También es cierto que la mala evaluación de las fechas de entrega, siendo demasiado exigentes en muchos casos, obliga en gran cantidad de ocasiones a hacer este sprint final por mucho que se apriete o se mantenga un nivel alto de rendimiento en todo el proyecto.

Por tanto, el sprint final va a ser necesario en la mayoría de los proyectos de desarrollo de software (esos famosos picos de trabajo), que va a durar más cuanto peor esté estimado el proyecto en tiempo y/o recursos (picos de trabajo continuos (y que darán lugar además de tener quemado al equipo del proyecto a una merma en la calidad del producto y a un más que probable retraso en la entrega)) pero que en cualquier caso es necesario mantener un ritmo constante para terminar el proyecto en fecha, ya que si no se ha avanzado lo suficiente antes del sprint final será muy complicado que se puedan cumplir los plazos con un nivel de calidad aceptable.

Atacar directamente a un modelo de datos de otra aplicación incrementa el grado de acoplamiento entre sistemas y cuando este modelo se extiende a la mayoría de sistemas de información de una organización, se entiende que está implantado lo que se denomina modelo en spaghetti.

La teoría dice que hay que intentar reducir al mínimo el nivel de acoplamiento y que una de las posibilidades para reducirla se encuentra en el uso de APIs que utilizarán la tecnología que se elija en cada caso para suministrarle a una aplicación la información que necesita de otra.

Hasta ahí todo bien y estoy de acuerdo. La reducción del nivel de acoplamiento minimiza impactos en terceras aplicaciones que consumen o graban datos ya que si se conserva el API (los cambios son internos (principio de caja negra)) las aplicaciones que hacen uso del mismo no se enteran.

Me considero bastante ortodoxo (muy teórico) en el desempeño de mi labor profesional y en consecuencia eso se traduce en muchas de las decisiones que tomo, que como ya he dicho muchas veces en este blog, a veces son acertadas y otras equivocadas, ya que la teoría no vale para todos los casos o bien porque la teoría no se ha aplicado o interpretado correctamente. Lo que me enseñaron en la facultad era teoría (por muchas prácticas que tuvieran las asignaturas) y es lo que aplico, aunque afortunadamente la experiencia y tropezarse contra muchas piedras (alguna de ellas más de una vez) permite que donde han habido errores intente abordar el problema de otra manera.

En el asunto de las API podemos realizar la siguiente clasificación: las APIs que se utilizan porque no hay otra forma de obtener/grabar información en otro sistema (es decir, aquellas en las que no tenemos acceso al modelo de datos) y aquellas que se ponen por encima de un modelo de datos al que sí podemos acceder. En el primer caso, no hay más remedio que utilizar el API. En el segundo tenemos la posibilidad de elegir y si tenemos la posibilidad de elegir no hay que caer (yo he caído), en el error de aplicar la teoría a rajatabla y si el API no está bien construido o no es lo suficientemente eficiente, utilizar el API por narices. Si el API original está en nuestra manos mejorarlo y en un tiempo razonable sí que puede ser solución continuar con su uso, en caso contrario yo recomiendo una implementación alternativa o atacar directamente al modelo de datos, ya que lo primero es que las aplicaciones funcionen de forma eficiente y con usabilidad para el usuario, la ortodoxia viene después.

No es este un post en contra del uso de APIs, en absoluto, antes al contrario, ya he comentado que estoy totalmente de acuerdo con su uso (y que en ocasiones no hay otro medio para acceder/grabar la información) y en sus fundamentos teóricos, lo que quiero decir con este artículo esta expresado al final del párrafo anterior: lo primero, el usuario.

El concepto de Inshore, es un concepto que ha venido de la mano de los dos modelos de centros de desarrollo de software tradicionales: Nearshore y Offshore, los cuales como ya he comentado en diferentes posts, se diferencian por motivos geográficos (para unas personas son unos motivos, para otras otros, en mi caso, el criterio es la distancia).

El Inshore maneja también criterios geográficos para diferencias del Nearshore, ya que hace referencia al establecimiento del centro de desarrollo de software en la misma localización geográfica (mismo municipio o misma provincia) que el centro destinatario del producto resultante.

La regla general que se aplica a estos modelos (no siempre se cumple) es que la distancia reduce la calidad del producto final y también los costes de desarrollo. Supuestamente, atendiendo a esta regla, un centro Inshore produciría resultados de gran calidad, pero también a unos costes de producción altos (o por lo menos similares a la competencia).

La calidad del resultado final depende de muchos factores, pero no necesariamente la distancia debería ser un factor decisivo, si se tiene un buen framework, una buena gestión y organización, una buena metodología y un buen equipo de técnicos. Como en todos los casos, no se puede decir qué una solución es óptima para todos los casos, ya que hay proyectos de desarrollo de software para los que puede resultar interesante el empleo de Offshore, otros Nearshore, otros Inshore y otros una combinación de los anteriores.

El Inshore sólo o combinado con el Nearshore o el Offshore, resulta muy adecuado para proyectos que requieren mucho contacto y feedback con el cliente, por lo que no resulta recomendable (entre otra cosa por los costes) estar desplazando continuamente técnicos y tampoco un umbral de latencia en la respuesta al cliente demasiado alto.

Hasta ahora sólo he trabajado con modelos Inshore puros o con el modelo combinado Inshore-Nearshore, con mejores resultados en los primeros casos que en los segundos, aunque también es cierto que se están mejorando las prestaciones en los últimos trabajos entregados utilizando el modelo Inshore-Nearshore.

No hace falta dar muchas vueltas para apreciar las consecuencias nefastas que provocaría estar sometidos a un entorno basado en patentes software. Si todas las ideas en el mundo del software fueran patentables, la innovación sufriría un tremendo varapalo, ya que gran parte de las empresas y grupos de desarrollo de software tendrían que hacer frente a un pago a los distintos propietarios de patentes para poder realizar su labor habitual. Independientemente del acuerdo al que se llegue habría que sumar a los costes normales de producción de software un importante complemento que se llevarían los propietarios de patentes. Esto sería tremendo en el mundo de las PYMES dedicadas al desarrollo de software que no podrían soportar esos costes y terminarían siendo extinguidas (la otra posibilidad es que ese sobrecoste terminase en el cliente, que tampoco podría soportarlo al menos en la misma proporción, es decir, los propietarios de patentes siempre se llevarían su parte, pero los desarrolladores de software verían mermado considerablemente su margen de maniobra).

Ante este panorama, ¿quién podría subsistir? Pues las empresas con suficiente nivel de negocio para poder afrontar el pago de multitud de patentes, las empresas que tengan un número de patentes que permita hacer un intercambio con las otras propietarias de patentes (ya sea un intercambio a pelo o por lo menos un intercambio que permita reducir el coste de uso de patentes) y las propias empresas de desarrollo de software propietarias de muchas patentes. Es decir, el mercado de proveedores se reduciría considerablemente, reduciendo el nivel de competencia, provocando un mayor nivel de cautividad en los proveedores y reduciendo el nivel de innovación, ya que cada paso que se de en este aspecto es como andar sobre arenas movedizas, ya que son tantas las patentes que existirían y algunas de ellas con una interpretación tan ambigua que difícilmente se sabría si en todo el proceso innovador se está utilizando una idea ya patentada o no. También dificulta el proceso innovador la existencia de empresas que son meras cobradoras, es decir, propietarias de patentes que lo único que tienen es un equipo de abogados y técnicos dispuestos a descubrir dónde se está utilizando una patente de su propiedad sin haber obtenido un ingreso a cambio. En resumidas cuentas, pura especulación, la innovación ya no consistiría en mejorar los productos software existentes o crear otros nuevos sino que se basaría en la búsqueda de nuevos métodos para sacar dinero a los demás.

Ni que decir tiene de las nefastas repercusiones que tendría sobre el software libre, ya que éste también se vería afectado por las patentes y al verse afectado por ellas el software sería menos libre, el problema no sería principalmente de dinero (que también) sino de libertad, las patentes sobre software restringen esa posibilidad de elegir, esa posibilidad de poder modificar el software con el fin que se considere pertinente.

La industria del desarrollo de software está siendo afectada, como casi prácticamente todas las áreas de negocio, por la época de crisis en la que nos encontramos en la actualidad. Y probablemente esta crisis en la industria dure algún tiempo más, debido a que se está derivando más presupuesto por parte de las Administraciones para políticas de carácter social que para inversiones y que para investigación y desarrollo y no hay que olvidar que una buena parte de la industria del desarrollo de software en nuestro país depende de las inversiones por parte de las Administraciones Públicas. No entraré en este artículo a valorar si esa política me parece correcta o no, ya que no quiero tratar en mi blog asuntos relacionados con la política.

Esta situación hace que un gran número de empresas de desarrollo de software vean complicado su futuro a corto y medio plazo, ya que si los gastos son superiores a los ingresos, la situación no se puede mantener de la misma manera durante mucho tiempo, lo que obligará a las empresas a reducir los gastos y entre esas partidas de gastos a reducir se encuentran los gastos relacionados con el personal. Esta reducción se centrará por un lado en disminuir la plantilla y por otra en mantener en la mayoría de los casos los salarios.

Por tanto, en el mercado del desarrollo de software nos encontraremos con una mayor oferta de personal que demanda y dentro de ese personal que ha perdido su puesto de trabajo o que bien no se encuentra satisfecho en su empresa, porque sus condiciones laborales han podido empeorar (más horas) y porque su sueldo no ha mejorado o no ha mejorado lo que cree que merecía, seguro que hay muchos mirlos blancos, mucho personal muy interesante y de gran calidad que podría venir estupendamente a las diferentes organizaciones que tengan a bien contratarlos.

Pero claro, en una época como en la que nos encontramos, salvo que la empresa tenga una buena perspectica de contratos y cobros asegurados a medio plazo o tenga unas necesidades concretas para determinados proyectos, no es sencillo plantearse el reclutamiento de más personal, porque si ya es complicado mantenerse con lo que hay, todavía lo será más si los gastos se incrementan. Por tanto, llegado a este punto, son las empresas las que tienen que plantearse si asumir riesgos y contratar esos mirlos blancos que en otras condiciones del mercado pueden ser más complicados fichar o simplemente que su camino se cruce con el de tu organización. Mi opinión es que si se encuentra una persona o un conjunto de personas que encajan perfectamente en la organización y tienen mucho que aportar, siempre es positivo y a la larga será muy rentable, pero claro, eso es una opinión de alguien que no se está jugando su dinero en una empresa.

Los lectores habituales de mi blog, me habrán visto siempre muy crítico con la postura y comportamiento de los usuarios, pero también habrán tenido la oportunidad de apreciar como defiendo que el resultado final de un producto debe ser siempre satisfacer al usuario y no solo funcionalmente.

Los usuarios son unos de los mejores maestros que pueden tener los profesionales de las TIC en general y los que se dedican al desarrollo de software en general y no me refiero a los directores usuarios o usuarios que actúan de enlace para capturar los requisitos o participar en diversas fases del proceso de desarrollo de software, sino el usuario de paisano, el que no ha tenido nada que ver en el desarrollo y se encuentra delante de un programa que generalmente siempre le causa más problemas que soluciones.

Es muy enriquecedor (aunque quema bastante) trabajar con los usuarios sin filtros (Centros de atención a usuario de por medio) e incluso con filtros de por medio si de alguna manera puedes leer lo que solicitan o incluso tienes que ponerte en contacto con ellos (otra forma muy interesante de conocer a los usuarios es a través de los cursos de formación). Hasta que uno no trata con usuarios, no se tiene una percepción real de lo que es el desarrollo de software. Se puede ser un técnico excelente, extraordinario, fuera de lo común, pero sin el trato con los usuarios se pierde una pizca de realidad que considero muy importante.

Yo noto muchísimo cuando un profesional de la informática ha trabajado con usuarios y cuando no. Cada uno da importancia a cosas distintas en el proceso de desarrollo de software (la diferencia en algunos casos es inapreciable y en otros bastante significativa).