Llamarme inocente, lo admito, he pasado la mayoría de mi carrera profesional creyendo que aquellos grupos y organizaciones que hacían software malamente y, por consiguiente, software malo, no tanto en el sentido funcional sino más en el sentido de cómo internamente está desarrollado y testeado, lo hacían por motivos de incompetencia.
Pero, con los años, he acabado creyendo que, aparte de la incompetencia, hay otra razón mayor para hacerlo mal y que algunos son conscientes de la misma: el negocio económico y los beneficios que genera el software rematadamente mal hecho y por consiguiente el software malo. Por mal hecho, sin perdernos en detalles, hablo, por ejemplo, de un 2 o menos en el Test Garzás.
De hecho, analizando los beneficios que tiene hacer el software mal, y analizándolo solo desde el punto de vista económico, que no ético y profesional, realmente hasta me empiezan a aparecer dudas sobre qué beneficio obtienen los que lo hacen bien.
Así que de los creadores de la serie de Por qué hay empresas que no hacen buen software y Cómo lograr que tus clientes nunca puedan sustituirte y tenerlos atados para la eternidad llega una nueva entrega: El negocio oculto de hacer mal software y software malo.
Veamos las enormes ventajas competitivas y económicas de hacerlo mal, y luego me dices….
1 – Ahorro de costes en personal.
Frente a una empresa profesional que tiene un correcto proceso de desarrollo software, si haces software malo, con un proceso malo, lo lógico es que tengas gente poco cualificada, poco experta o con poco conocimiento, lo que es ostensiblemente más económico.
Te ahorrarás en formación, en que te pidan aumentos de sueldo, bajas la rotación de la empresa, etc.
No es todo tan fácil, porque normalmente los que hacen mal software se caracterizan por intentar suplir sus carencias metiendo mucha gente. Pero eso suele aparecer cuando ya las cosas van muy mal, al principio «esto con 4 becarios sale».
2 – Fidelización de clientes.
Hacer software rematadamente malo genera que pocos, más allá de quienes lo programaron (y a veces ni eso), sean capaces de mantenerlo, tocarlo, evolucionarlo, etc. Es por ello que muchos clientes que compraron un desarrollo software mal hecho ya no pueden prescindir del proveedor… Sólo él puede mantener tal monstruo… y ahí se queda por años.
3 – Aumento de las tarifas.
Créeme, no cuento nada que no haya visto yo, y varias veces. Por motivos como el anterior, llega un momento que el proveedor de desarrollo toma consciencia de que ningún otro proveedor, nadie de la competencia, se atreverá a intentar quitarle el proyecto… nadie quiere ese problemón y el que quiera entrar cobrará más para poder hacerse con ello.
Entonces… le sube las tarifas al cliente. Así, podrás ver gente y empresas rematadamente malas cobrando tarifas que te producirían escalofríos, diciendo, además, que “ellos son los únicos que saben de ese software” y por ello cobran tanto (te repito, lo he escuchado, y muchas veces).
4 – Las ofertas más competitivas del mercado
Hacerlo mal genera la paradoja de prometer hacerlo en menos tiempo… pero en la realidad tardar el doble, o más, de tiempo de lo que alguien que se sabe diría que lo haría.
Y lo anterior es una gran ventaja competitiva. Es lo que todo cliente quiere escuchar… el menor tiempo. Y si al menor tiempo le unes que, debido al apunto 1 de esta lista, eres el proveedor que tiene personal menos cualificado y por ello menos costoso… además de ser el que lo hace en menos tiempo… eres el que lo hace en menor precio. Así no falla, te llevas el proyecto.
Pero es más, por si fuera poco, este punto te hará ganar más dinero porque lograrás un….
5 – Aumento, casi indefinido, vitalicio, del tiempo de proyecto (por consiguiente alargar los meses de facturación).
A raíz del punto anterior, aquello de prometer menos tiempo de proyecto del posible y necesario, crea otra gran ventaja competitiva (además de ganar el proyecto).
Lo normal es que la presión del inocente cliente engañado, para que que el mal proveedor cumpla las fechas, que ya sabemos son imposibles, provocará que el proveedor, para quitarse problemas y líos, diga… “ah, que quieres que entregue ya lo que llevo, que sino me penalizas, pues ahí lo tienes…”.
Puedes adivinar que el desarrollador entregará algo que medio funciona y con miles de bugs (obvio decirte que el testing nunca se hará, no hay tiempo).
Una vez entregado, más que en procesos tan caóticos, esos en los que nadie tiene claro exactamente “qué era lo que había que entregar”, se dará por buena la entrega y empezará la mal llamada fase de mantenimiento (realmente, fase de terminar lo que no dio tiempo).
Fase de mantenimiento en la que, sí querido lector, el mal proveedor de software comenzará un nuevo proyecto que, sí, sí, facturara al inocente cliente.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Interesante reflexión la de hoy. Y por sus similitudes me recuerda a un tema más común y más conocido por todos como el el tema de la corrupción política,que todos estamos de acuerdo en que es mala pero existe y nos inunda por todos lados porque:
Hay una serie de personas que se ven muy beneficiadas por ella.
Va entrampando a todoo el mundo al que toca.
Mal que bien si «todo lo demás va funcionando» podemos «ir tirando»
El problema viene cuando la tercera premisa deja de ser cierta y nos damos cuenta de que estamos metidos en un enorme y profundo agujero del que es difícil salir.
PD: La cultura de la no calidad del software no deja de ser una forma de corrupción.
Me encantó la PD.
Una de las mejores explicaciones de la situación en la que nos encontramos en nuestro Hospital.
Mas claro no se de puede decir.
Absolutamente de acuerdo, Javier. Hace poco, en una jornada que asistí, yo indicaba:
«Durante casi 20 años estuve sospechando que me engañaban las software factories y ahora estoy seguro que durante 20 años me estuvieron engañando…»
Todos los asistentes a la jornada, pertenecientes a este tipo de negocio, se pillaron un mosqueo bastante importante. Pero es que es así.
Cuando comenzamos a andar como empresa, todos los fabricantes de software que intenté «seducir» con los argumentos del aseguramiento y gestión de la calidad del software me contestaban que (de media) un 30% de sus ingresos (directos, sin tener en cuenta muchas cosas que indica Javier más arriba) venían de hacer el software como lo hacían… MAL… ahí queda eso…
Lo has clavado, es lo que te comentábamos en ¿Para qué voy a hacer las cosas con calidad si ningún cliente me va a pagar esa calidad?.
En la mayoría de los casos el criterio de selección de un proyecto es única y exclusivamente el precio, eso lleva a tirar a la baja y luego recuperar posteriormente de la forma que sea. Y tenerlos cautivos es una muy buena forma de conseguirlo.
100% de acuerdo.
Recordemos que muchas veces los clientes que deciden sobre los contratos son personas que no tienen idea de software, se limitan a aprobar presupuestos, y casi siempre gana el más barato.
Al cabo de unos años, los usuarios finales tendrán que aguantar las consecuencias, o comenzar otro proyecto de modificación.
Además, como los contratos fijos no contemplan cambios de requerimientos (o muy pocos) se aseguran al cliente a largo plazo, con más pagos.
Sigamos apostando por un mundo del software ágil.
Gracias!
Bien, por fin alguien se ha dado cuenta de porque los Windows 9x eran tan malos. No les hacía falta que fueran mejores ya que estaban pensados para entornos corporativos y por tanto, controlados en cuanto a software —más o menos, ya sabemos que a la larga no era así, pero el responsable era el administrador de la red, no Microsotf— y en definitva, les resutlaba rentable.
Mira que está agarrada de los pelos la similitud 😉
(Ojo, no quiero en ningún momento agregarles calidad a los Windows 9X, demasiado hicieron por el mundo PC en su época)
Pingback: El negocio oculto de hacer mal software (y software malo) - Javier Garzás
Bueno, es algo que más o menos se intuye, estoy de acuerdo contigo. El mercado informático es una burbuja, con sus propios matices, similar a la inmobiliaria: altos precios y calidades mediocres o malas con problemas que a la larga son imposibles de solucionar sopena de tirar todo el edificio y volver a construirlo.
Es lo que pasa cuando en vez de profesionales con cierta ética y amor por el trabajo bien hecho se meten gestores de medio pelo que solo quieren beneficio a toda costa sin contar con ninguna otra variable. Y, al final de la historia, siempre pasa que para sobrevivir, el que es éticamente integro, si ha de vivir de ésto, no le queda otra que aparcar la ética y subirse al carro de las malas prácticas
Los escenarios descritos de parte del proveedor son correctos. Sin embargo, el problema del desarrollo de software no son solo los proveedores sino tambien los que lo compran. No solo no tienen una adecuada Gestion de Proveedores de Software que incluya la calificacion del proveedor asi como un costo razonable del software solicitado incluyendo los niveles de calidad necesarios, no hay tarifas de mercado estandar. Adicionalmente las politicas de pago, por ejemplo a 60 dias, hacen que quien se atreva a realizar el software deba tener una buena espalda financiera algo que no todos los proveedores tienen y finalmente termina tambien influyendo en la calidad del servicio.
Fundamental el aporte de Guino respecto del que compra, en nuestro caso, por salvar un puesto de dirección técnica ejercido por alquien que no tiene idea del software ni del proceso de desarrollo, se compra un producto sin consultar al departamento de software que había desarrollado el programa anterior, que funcionaba desde 1997 hasta 2013. Por esa falta de proyecto y pensar que alguien de fuera puede tener un producto de mejor calidad, hipoteca un departamento estratégico de conocimiento. Si nos hubiesen consultado, y en lugar de ver la demo pedíamos la estructura de la base de datos y codigo, habríamos ahorrado seguramente 2 millones y medio de euros.
Javier; Felicidades sin lugar a dudas el mejor Post que te he leído. Hay que tener valor para identificar el «destrozo» que muchas empresas (la mayoría multinacionales) están haciendo y el negocio mal entendido llamado » mantenimiento» que han creado frente al software de calidad.