Tecnología no fiable a largo plazo. Por: Jeremy Keith – CC BY 2.0
Invertir esfuerzo en un software clave para la actividad de una organización, para más tarde verse obligado a cambiarlo, puede ser un problema realmente traumático. Pero el software muchas veces no es un input cualquiera en un proceso de trabajo, sino que se adapta a él y a su vez adapta el proceso de trabajo a sí mismo: es decir, cuando un software va a permanecer en la organización a largo plazo, el proceso de trabajo puede ajustarse para aprovechar mejor sus ventajas y sortear sus limitaciones. Con esto quiero decir que el nivel de dependencia entre un trabajo y el software que se utiliza para realizarlo puede llegar a ser muy elevado, y cambiar el software un problema de primera magnitud.
No voy a hablar de cuando ese cambio de software se debe a un error de selección (cuando se descubre que la elección era insuficiente para las necesidades), sino un caso mucho más extremo: cuando el producto desaparece. El proveedor desaparece; cambia su negocio y elimina el producto; es adquirido por un competidor que elimina el producto. La pequeña empresita que ofrece el producto sufre un revés en sus resultados y pierde pie.
La cuestión, entonces, es de confianza: ¿cuándo es confiable, a largo plazo, un software? ¿Quién garantiza la continuidad y estabilidad de esta herramienta? ¿Quién garantiza la rentabilidad de la inversión de esfuerzo que haremos en aprenderla y alimentarla?
Esta semana recibí una invitación a probar software de pago, un CRM (software de gestión de clientes) en la nube ofrecido por una consultora española de tamaño mediano, que me hizo pensar y sacar algunas conclusiones provisionales sobre este tema.
Sólo encuentro dos casos en los que el software merece confianza a largo plazo:
- O es un producto asentadísimo en el mercado, uno de los líderes, casi estándar, con una empresa muy sólida que gana dinero con él (Google Reader, never forget).
- O es software libre y depende de la comunidad (opción que prefiero).
Y otros tres casos en los que podría no haber confianza, pero valer la pena de todos modos:
- El producto es muy innovador (en sentido muy amplio; incluyendo, por ejemplo, los casos de productos que sean la única opción seria de su nicho).
- El producto es muy barato (lo cual, compitiendo contra software libre, será difícil de conseguir).
- El producto tiene un lock-in muy bajo: esto requiere que los datos sean muy fáciles de trasladar a otro producto y que la curva de aprendizaje sea mínima.
El CRM en la nube cuya publicidad recibí no pertenecía a ninguno de estos casos. Era propietario, poco conocido, en la banda de precios habitual, aparentemente hace lo mismo que todos los CRMs (no presumen de ninguna función original en su web), y se me ocurren pocos tipos de software con un lock-in tan elevado como un CRM (complejo, más que curva de aprendizaje tiene una carretera de la muerte, y necesidad de conservar todo el trabajo antiguo para realizar el trabajo futuro).
Por eso no puedo evitar preguntarme: ¿para qué existe ese producto? ¿Qué ventaja tiene su oferta? ¿Dónde está el negocio? Y mi única conclusión es el poco conocimiento en temas tecnológicos, el miedo incluso, de los clientes potenciales (especialmente de las personas que toman las decisiones en esos clientes), los cuales no tienen definidos los criterios que he descrito más arriba. Ni siquiera son unos criterios universales: muchísimos clientes, aun hoy, confían más en un producto propietario que en uno libre.
Creo, en conclusión, que falta comprensión sobre la fiabilidad a largo plazo del software, que se suele percibir como un factor secundario frente a sus funciones, y a veces se da por descontada. Si quieres convencerme de que use tu software, ofréceme alguno de los cinco argumentos que he dicho; si no, ni siquiera entiendo por qué tu producto existe.
Nota: esta entrada es una ampliación de un comentario que dejé en el blog de Pablo Yglesias.
El artículo Cómo convencerme de que tu software merece confianza es original de David Mendaña en derrotero · net.
