El cliente que llega con la solución ya decidida
Es el escenario más frecuente en la primera reunión con un cliente nuevo: el cliente llega con una solución técnica en mente. Migrar todo a la nube. Implementar alta disponibilidad. Automatizar un proceso específico con una herramienta que investigaron. En algunos casos, ya tienen un presupuesto aprobado para esa solución.
La solución que traen no siempre es incorrecta. Con frecuencia es razonable y refleja investigación real. El problema es que llega antes del diagnóstico. Y cuando la solución llega antes del diagnóstico, hay preguntas que no se hicieron.
Esas preguntas son las que Aleph Server hace en la primera reunión, antes de cualquier propuesta técnica.
Las preguntas que siempre hacemos
La primera pregunta no es técnica. Es operacional: ¿qué problema está generando esta situación en la operación del negocio? No el síntoma técnico —el servidor lento, el proceso que falla, el sistema que no escala— sino el impacto concreto en la operación. ¿Cuánto tiempo tarda en detectarse un problema? ¿Quién lo detecta y cómo? ¿Cuánto tiempo tarda en resolverse? ¿Qué queda sin hacer mientras el problema persiste?
Esa pregunta incomoda a veces. El cliente llegó con una solución, no a un diagnóstico de su operación. Pero la respuesta define si la solución que traen resuelve el problema real o el síntoma visible.
La segunda pregunta es sobre el equipo: ¿quién va a operar lo que se implemente? ¿Tiene la capacidad técnica para hacerlo de forma autónoma? Si no la tiene hoy, ¿cómo se desarrolla esa capacidad y en qué plazo? ¿O el acuerdo con Aleph Server incluye soporte continuo que cubra esa operación?
Esta pregunta cambia el alcance de muchos proyectos. Una solución técnicamente óptima que el equipo del cliente no puede operar de forma autónoma tiene un costo de soporte continuo que no siempre está presupuestado y una dependencia que no siempre es la que el cliente quiere.
La tercera pregunta es sobre el después: ¿qué pasa con este sistema en doce meses? ¿El volumen de uso va a crecer? ¿El equipo técnico va a cambiar? ¿Hay otros proyectos en el roadmap que van a depender de lo que se implemente ahora? La arquitectura que tiene sentido hoy puede bloquear opciones dentro de un año si no se diseña con esa perspectiva.
Lo que cambia cuando el diagnóstico precede a la propuesta
En la mayoría de los casos, el diagnóstico no cambia radicalmente la solución que el cliente traía. Pero cambia los detalles que hacen la diferencia entre una implementación que funciona y una que genera fricciones a mediano plazo.
En algunos casos sí cambia la solución. El cliente que quería alta disponibilidad y lo que realmente necesitaba era reducir el tiempo de recuperación con un backup verificado y un procedimiento documentado. El cliente que quería migrar todo a AWS y para quien la respuesta correcta era una arquitectura híbrida con las cargas estables on-premise. El cliente que quería automatizar un proceso con Apache Airflow y cuyo proceso no estaba suficientemente documentado para automatizarlo de forma confiable.
En esos casos, la conversación inicial que parece ralentizar el proceso es la que evita un proyecto mal dimensionado, un costo mayor al proyectado, o una implementación que el cliente no puede sostener.
La conversación que diferencia un partner de un proveedor
Hay una tensión en esta forma de trabajar. El cliente llegó con una decisión tomada y con un presupuesto aprobado para esa decisión. Hacer preguntas que cuestionan esa decisión no es la postura más cómoda para iniciar una relación comercial. Es más fácil tomar el proyecto tal como llega, ejecutarlo, y cobrar.
El problema es que el cliente que implementa algo que no necesitaba, o que no puede operar lo que implementó, asocia ese resultado con la empresa que se lo recomendó. Y esa asociación dura más que el proyecto.
La conversación honesta al inicio —incluso cuando incomoda, incluso cuando lleva a recomendar algo diferente de lo que el cliente quería— es la que construye una relación donde el cliente vuelve con el siguiente problema. No porque Aleph Server ejecutó lo que se le pidió, sino porque diagnosticó lo que se necesitaba.
Esa es la diferencia entre actuar como proveedor y actuar como partner. Y es la diferencia que Aleph Server busca establecer desde la primera reunión, antes de cualquier propuesta técnica.
