archivo

Archivo de la etiqueta: Crisis del software

Que los desarrolladores tenemos gran culpa de lo que sigue siendo la crisis del software no nos debe caber duda.

Sé que no es justo que englobe a todos en esto porque hay muchas personas y muchos equipos que tratan de luchar contra esto y están invirtiendo poco a poco la tendencia, no obstante la realidad de nuestro sector sigue siendo esa y por ese motivo, entre otros, no tenemos el reconocimiento que tienen otras profesiones.

Ahora bien, también tienen gran parte de culpa los responsables funcionales, por lo menos para repartirla casi de manera igualitaria, por haber dado malas especificaciones de lo que realmente necesitan y/o por no implicarse de la manera que deberían en los proyectos.

Da igual que tu desarrollo sea perfecto si la orientación que se le ha dado al mismo no ha sido la adecuada.

Una vez puestas las cartas sobre la mesa, tenemos el atenuante de que desarrollar un buen software es una tarea muy compleja y también lo es traducir pensamientos e intuiciones abstractas en especificaciones.

Partiendo de esa base, la elección de una buena estrategia adaptada a las necesidades del proyecto y su contexto, la aplicación de buenas prácticas, la intención de todas las partes por tratar de sacar el producto adelante y la existencia de un presupuesto acorde a las necesidades resultan fundamentales para incrementar las probabilidades de éxito.

Anuncios

Sin embargo, pese a todo, el problema de fondo se sitúa más allá del enfoque, sino en la importancia real que se le da al proceso de desarrollo sobre el producto software, que no es más, en esencia, que la importancia real que se le da a las personas en todo esto.

Cuando se mira más al procedimiento que a las personas no me extraña que se nos considere recursos porque da una idea de servicio a un fin distinto al que se pretende con el desarrollo de software (se sirve al proceso), que es conseguir un producto final que proporcione el mayor valor posible al usuario final (ahora hablo de valor, antes lo hice de calidad, al final de esta serie de artículos, los trataré de manera conjunta).

Independientemente de que haya determinados desarrollos, como por ejemplo, soluciones que se obtienen a través de configuración de productos base, donde el procedimiento puede tener gran interés (al fin y al cabo el producto ya existe), el desarrollo de software es una actividad intelectual que se lleva a cabo interactuando y colaborando con otras personas, tratando de eliminar fronteras entre ellas que creándolas de manera artificial.

Tenemos un producto que ha sido desarrollado con todos los entregables documentales que solicita el proceso, ¿debería ser un sistema fantástico? Sabemos que no es así o por lo menos que no es necesariamente así. Si todo fuera tan fácil como seguir una receta, no hubiera existido el concepto de crisis del software y la misma no hubiera llegado hasta nuestros días y no hubieran aparecido movimientos como el ágil que entienden que el desarrollo de software se basa en el producto y en las personas.

Los procesos dan un orden, armonizan actuaciones. Sobre esta base no podemos decir que, en esencia, sean perjudiciales. De hecho pese a que he pasado del amor al desamor con respecto a ellos siempre comento que siguen siendo necesarios pero como background en el que tengan un núcleo mínimo, que sean flexibles y admitan excepciones justificadas.

Cuando se cree que el éxito está tras los procesos es cuando se cae en el error. De ser cierto que aseguran el éxito bastaría con seguir su receta para conseguir desarrollar productos software que satisfagan las expectativas de los usuarios. ¿Alguien cree que si fuera así de fácil existiría hoy día la crisis del software?.

No niego que determinados procesos puedan ser efectivos en condiciones muy específicas pero no creo que en procesos que se consideran martillos de oro o solucionadores universales para todo tipo de desarrollos en todo tipo de contextos.

Cuando un proceso no funciona (en enfoques de desarrollo de software dirigidos por procesos) siempre se le suele echar la culpa al desarrollador: “el proyecto ha ido mal porque no has seguido bien el proceso o porque no se han ejecutado adecuadamente los hitos” o a que el proceso no está lo suficientemente desarrollado lo que da lugar a que se entre en un mayor nivel de detalle y se convierta en una solución más rígida que, por supuesto, funcionará igual de mal o peor (que es lo más posible) que la versión anterior.

La mayoría de los procesos son ad-hoc, lo cual en sí no es malo ni bueno (generalmente las implementaciones de metodologías ágiles suelen ser ad-hoc) pero sí que se debe ser prudente por parte de quien o quienes lo han hecho de considerarlo soluciones universales por mucho que sean el resultado (o se venda así) de años de feedback en proyectos reales.

¿Por qué lo digo? Pues porque la mayoría nos hemos encontrado con las siguientes situaciones: Proyectos que han salido adelante cuando no se ha seguido a rajatabla un proceso que provocaba bloqueos y resistencia y proyectos que han fracasado o que no han tenido el éxito esperado precisamente por seguir procesos rígidos que no se adaptaban a la realidad de los mismos.

Es cierto que no es justo echarle toda la culpa a los procesos cuando algo sale mal (no podemos escondernos tras ellos) pero sí que es verdad que si te exigen trabajar de una manera y no existe flexibilidad tu margen de maniobra queda reducido y se trabaja mucho peor que si tuvieras los pies y las manos liberados.

Cada vez más muchas organizaciones están dirigiendo sus miradas a la adquisición de productos software o a la adaptación de los mismos a sus necesidades, dejando de lado el desarrollo a medida.

Motivos:

– Coste. Será más barato hacerse con la licencia de un producto (o todavía más si es gratuito) o contratar servicios para adaptarlo a tus necesidades (es un desarrollo a medida pero partiendo de un producto, es decir, de una base sólida a partir de la cual realizar las adaptaciones y evoluciones que se necesiten) que desarrollar desde cero una solución que hace lo mismo o prácticamente lo mismo.

Existen muchas empresas que han ganado mucho dinero con el desarrollo a medida, en unos casos aplicando internamente políticas orientadas a productos (esto que hemos hecho allí, lo aplicamos aquí haciendo un par de retoques y lo vendemos como si lo hubiéramos desarrollado desde cero), en otros sobredimensionando costes (que después no se correspondían a la calidad de los resultados) y en otros rehaciendo lo que deberían haber hecho bien antes (mantenimientos perpetuos).

Sin embargo, la crisis del software pasa factura y los clientes de estos servicios están cansados de no obtener unos resultados acordes con el dinero que pagan. Si a esto le sumamos la crisis económica actual donde no se pueden (o no se deben) cometer los dispendios de antaño, el impacto sobre el desarrollo a medida resulta evidente.

– Riesgo. Embarcarse en un proyecto de desarrollo de software presenta riesgos, porque desde que se contratan los servicios hasta que se obtiene la versión definitiva del producto, pueden pasar muchas contingencias que supongan un incremento de los costes, un retraso en la planificación o incluso que finalmente el proyecto termine en un cajón.

Con la que está cayendo, tener certeza de que lo que necesito lo voy a tener prácticamente de inmediato y con un presupuesto controlado, es un argumento de mucho peso a la hora de elegir entre un producto o un desarrollo a medida.

Los desarrollos a medida seguirán existiendo, tanto en la vertiente de adaptación de productos como en la de desarrollos de soluciones desde cero, ya que existirán necesidades no cubiertas por soluciones ya existentes o se quiera tener un control total sobre el proceso de desarrollo del producto.

Algunos lectores del artículo “Desarrollo de software. ¿Qué es caro?, ¿qué es barato?” probablemente serán de la opinión que el mercado en la actualidad impone unas condiciones como consecuencia de la crisis y de la concepción que se tiene sobre nuestra profesión como consecuencia de la continuada crisis del software, en donde si quieres ser competitivo no tienes más remedio que aplicar una política de precios muy agresiva y que eso condiciona en gran medida el resultado de los proyectos.

Es una buena foto de la realidad, no lo puedo negar, pero también es la evidencia del triunfo de la mediocridad, que ha sumido nuestro sector en una espiral que entre todos tenemos que parar, antes de que nuestras condiciones laborales sean todavía más precarias.

Dado que las reglas del juego son esas, si queremos cambiar las cosas debemos aceptar la situación tal como es. Puedes ser una empresa de servicios de desarrollo de software excepcional pero para que te conozcan de verdad te tienen que contratar (o por lo menos que lo haga otra entidad muy allegada a aquella) y si la deriva actual ha llevado a una política de precios agresiva tendrás que convivir con ella.

Es conveniente analizar en primer lugar si es posible bajar precios minimizando el impacto sobre la masa laboral, ¿es posible reducir alguna de las partidas de gastos fijos?, ¿es posible mejorar la productividad?, ¿es posible enfocar parte de nuestro negocio a la instalación, soporte y adaptación de productos propios o libres?. Es más que probable que sea posible, en época de bonanza se cometen excesos que se institucionalizan.

Tal vez, si el cliente al que se quiere llegar es interesante, a lo anterior se pueda sumar una reducción de las expectativas de beneficio (siempre de manera sensata, teniendo en cuenta la naturaleza y complejidad del proyecto a realizar).

Otras estrategias interesantes puede ser ofrecer pilotos a precio de coste o a coste cero (sobre todo si nos basamos en la utilización de productos).

Ahora bien, una vez que llegamos al cliente, es nuestra oportunidad. Si queda satisfecho, es más que probable que en el futuro se acuerde de nosotros o que incluso quiera continuar la relación con otro tipo de proyectos. Es en este momento donde podemos empezar a ajustar la política de precios a unos términos más razonables, aunque sea poco a poco, proyecto a proyecto.

¿Estamos condicionados por el mercado? Sí, pero no hay que olvidar que somos en gran parte culpables que el mercado se haya vuelto así y que para darle la vuelta, tenemos que adaptarnos a las reglas del juego, para desde dentro y poco a poco, empezar a revertir la situación.

Caro es no cumplir las expectativas del usuario y barato todo lo contrario.

Es tanto el dinero gastado en sistema de información que no han producido resultados satisfactorios y tanto los problemas que esto ocasiona a un cliente (crisis del software), que realmente cualquier de ellos estaría dispuesto a pagar lo que fuese (dentro de unos límites razonables) con tal de que el producto que se obtenga tuviera éxito.

Precisamente, la no consecución de esos objetivos ha sido una de las causas del abaratamiento progresivo de los presupuestos en los proyectos, es decir, falta de confianza de los clientes = peores condiciones.

Esta situación la ha creado nuestro sector. Somos los principales culpables y en nuestra mano está dar la vuelta a esto. Sin embargo, no se termina de mirar de más allá y sigue sin importar lo que le pase al sector, solo importa conseguir negocio a corto plazo a costa de lo que sea.

Otros artículos relacionados:

El precio hora y el triunfo de la mediocridad: I y II.

Buena parte de los trucos de magos e ilusionistas, del pasado y del presente utilizaban como instrumentos el humo y los espejos, de ahí que este antipatrón reciba esta denominación.

Estamos ante otra de las situaciones que deja a nuestro negocio o a nuestra profesión en muy mal lugar y, por tanto, es otra de las variables que afecta a la crisis del software.

Nos encontramos ante este antipatrón cuando vendemos al cliente o a los usuarios falsas expectativas, es decir, a sabiendas de que no se va a poder conseguir o que existe un importante riesgo de que no se alcancen (y no se comunique ese riesgo) se indica que se el proyecto va a alcanzar tal objetivo, que se va a implementar tal funcionalidad, que el coste va a ser este, etc…

No todo vale para vender o conseguir un contrato. No todo termina con la firma de un papel. No es así, no debe ser así. Las palabras se deben corresponder con hechos y si no se corresponde que sea porque los hechos han superado a las palabras o lo que es lo mismo, que se superen las expectativas de usuarios y/o clientes.

La fidelización de clientes se consigue a través del cumplimiento de sus expectativas y de una relación de confianza y eso es lo que realmente importa. Si incumples las expectativas que has generado difícilmente van a seguir confiando en ti y te cerrarán las puertas a posibles buenos clientes, además de ir creándote una fama que te cerrará puertas a las que ni siquiera todavía has llamado.