Proof of change: el secreto mejor guardado de los vendedores de tecnología

«¿En cuánto tiempo se puede realizar esta aplicación con tu herramienta low-code? porque mis programadores lo hacen en X horas«

He escuchado eso miles de veces.

No cientos, miles.

Siempre que voy a presentar GeneXus a una empresa que está vinculada al desarrollo de software tradicional piden hacer una prueba de concepto y probar la herramienta low-code contra su mejor programador.

Un proof of concept diría Shakespeare.

Como una pelea de street fighter pero mucho más aburrido.

El objetivo es comprobar si en realidad somos tan productivos como decimos que somos y además ver si la herramienta cumple su promesa de que se puede hacer lo que digo que se puede hacer.

Pero hay algo más...

Muchas veces se hace trampa.

Se hace esa comparación con el super programador manual vs un programador que acaba de aprender la herramienta low-code.

Ahí se da una linda pelea, experiencia vs apalancamiento.

Casi siempre gana GeneXus, por eso tengo trabajo.

Pero no quiero hablar de pruebas de concepto o proof of concept.

Construir software es fácil.

Lo difícil es mantenerlo.

Como dijo alguna vez Mariano Delarrobla: «Dios creó el mundo en 7 días porque no tenía base instalada»

En ese sentido es que existe el proof of change.

Consiste a partir de un software ya construido solicitar un cambio, cuánto más radical sea el mismo, mejor.

Esa es la hora de la verdad! Ahí es donde se define el partido!

Este escenario es el más parecido a la vida real.

Es lo que nos va a pasar el día de mañana en el ciclo de vida de nuestro proyecto.

Es difícil y por eso ningún vendedor de tecnología va a decir: «hacé una prueba de cambios», excepto uno que venda Genexus.

En fin, la próxima vez que estén evaluando una herramienta de desarrollo no se olviden de pedir su proof of change.

Se van a divertir!

2 pensamientos sobre “Proof of change: el secreto mejor guardado de los vendedores de tecnología”

  1. Totalmente de acuerdo. La gestion del cambio, la responsabilidad, el mantenimiento ya el soporte son costos que no se ven con claridad cuando uno implementa un cambio.
    Si el core de tu empresa no es desarrollar software, no deberías hacerlo. Menos aún si el único que va a usar ese software sos vos.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *