Cómo elige una software house un CEO sin perfil técnico
Marco práctico para evaluar una software house sin formación técnica, con preguntas sobre alcance, equipo, seguridad, coste y entrega.
Por Η ομάδα της Argonstack, TechIns Group
Un CEO no necesita evaluar líneas de código. Necesita evaluar si el proveedor entiende el problema empresarial, puede convertir la ambigüedad en un alcance claro y dispone de un sistema de entrega que reduce el riesgo.
El error más frecuente es elegir por una presentación impresionante o por el precio más bajo. La calidad real se ve en cómo la software house hace preguntas, define entregables, gestiona los cambios y demuestra que el sistema funciona.
Empiece por el resultado empresarial
Antes de pedir una propuesta, describa qué debe cambiar en la operativa. Por ejemplo, reducir el tiempo de emisión de una oferta, que no se pierdan solicitudes, conectar la cartera de clientes con el ERP o crear un nuevo canal digital de ingresos.
Evite empezar con una gran lista de funciones. Las funciones son posibles soluciones. El resultado es la razón por la que invierte. Un buen socio le ayudará a vincular cada función crítica con un usuario, un problema y un objetivo medible. Si la duda es específicamente sobre CRM, vea primero si le conviene un CRM estándar o a medida.
Compruebe cómo se realiza el descubrimiento
Pregunte qué ocurre antes de empezar el desarrollo. ¿Quién participa? ¿Cómo se registran los flujos? ¿Cómo se confirman los requisitos? ¿Cuál es el entregable del descubrimiento?
Si la empresa puede dar un precio y una fecha finales para un proyecto complejo tras una breve conversación general, probablemente subestime el alcance o incorpore un gran margen de incertidumbre. La precisión de la propuesta depende de la precisión de la comprensión.
Pida conocer al equipo real
La presentación comercial puede hacerla personal senior, pero el proyecto puede asignarse a otro equipo. Pida conocer al responsable del proyecto y al responsable técnico. Pregunte quiénes participarán, cuánta disponibilidad tienen y quién decide cuando surge un obstáculo técnico.
No hace falta juzgar el currículum de cada desarrollador. Hay que asegurarse de que existe un responsable con visión de conjunto del proyecto y de que el conocimiento no reside en una sola persona.
Evalúe proyectos similares de la forma correcta
Un portafolio extenso no demuestra por sí solo idoneidad. Pida dos o tres proyectos con complejidad, integraciones o entorno regulatorio similares. Pregunte cuál era el problema, qué se entregó, qué cambió durante la implantación y qué resultado se midió.
Las imágenes de una aplicación demuestran diseño. No demuestran estabilidad, adopción, rendimiento ni resultado empresarial.
Pida un alcance claro y criterios de aceptación
Cada función básica debe tener un criterio de aceptación. Si el sistema «se conecta con el ERP», debe definirse qué datos se transfieren, en qué dirección, con qué frecuencia, qué ocurre en caso de error y quién es responsable de la API.
La propuesta debe distinguir qué se incluye, qué no se incluye, qué hipótesis se han asumido y qué parte depende de terceros.
Entienda el modelo de coste
En el precio cerrado, el proveedor asume mayor riesgo de alcance y suele añadir un margen de seguridad. En el modelo por tiempo y materiales, el cliente paga el tiempo real pero asume mayor incertidumbre sobre el coste total. En el modelo por fases, cada etapa se aprueba antes de empezar la siguiente.
No existe un modelo que sea siempre mejor. Lo correcto depende de cuán maduros sean los requisitos y de cuánto cambio se espere.
Compruebe la seguridad y la continuidad
Pregunte dónde se aloja el sistema, cómo se hacen las copias de seguridad, cómo se gestionan los accesos, cómo se registran los incidentes y qué subencargados se utilizan. Pida saber quién posee las cuentas críticas y cómo continuará el proyecto si cambia la colaboración.
La respuesta «cumplimos el RGPD» no es suficiente. Se necesitan medidas concretas, roles y documentos contractuales.
Evalúe la forma de comunicación
La colaboración en un proyecto de software incluye incertidumbre. Lo que importa es con qué rapidez el equipo señala un problema y qué información aporta para tomar una decisión. Busque un ritmo estable, decisiones por escrito, demostraciones de material funcional y un backlog visible.
El exceso de seguridad es una señal de alerta. Un socio maduro distingue lo que sabe, lo que supone y lo que debe probarse.
Diez preguntas antes de contratar
- ¿Qué problema cree que resolvemos y cómo mediremos el éxito?
- ¿Cuál es el primer entregable y cuándo lo veremos funcionando?
- ¿Quién es responsable del alcance, las decisiones técnicas y la comunicación?
- ¿Qué hipótesis incluye la propuesta?
- ¿Cómo se aprueban los cambios y cómo afectan al coste y al tiempo?
- ¿Qué datos e integraciones dependen de nosotros o de terceros?
- ¿Cuáles son los criterios de aceptación?
- ¿Cómo se gestionan la seguridad, las copias de seguridad, la monitorización y la respuesta a incidentes?
- ¿Qué se entrega si se interrumpe la colaboración?
- ¿Cuál es el coste total de funcionamiento tras el lanzamiento?
Argonstack inicia los proyectos a medida con análisis empresarial y diseño técnico. El objetivo es que la propuesta describa un sistema que pueda entregarse, comprobarse y funcionar, no simplemente una lista atractiva de posibilidades.
Siguiente paso
Evalúe el proyecto, el riesgo y el resultado esperado antes de comprometer presupuesto.
Preguntas frecuentes
¿Debo elegir la propuesta más barata?
No, antes de confirmar que las propuestas cubren el mismo alcance. El precio más bajo puede deberse a menos entregables, hipótesis distintas o a la ausencia de tareas críticas.
¿Necesito mi propio CTO?
No siempre. Pero para un proyecto importante necesita supervisión técnica independiente o al menos un asesor experimentado que revise la arquitectura, la seguridad y los entregables.
¿Cuál es la señal de alerta más importante?
La incapacidad del proveedor de describir con claridad qué es lo que aún no sabe y cómo lo va a confirmar.
