La respuesta corta
Para contratar una software house, empiece por el problema de la operación, haga a todas las candidatas las mismas preguntas sobre método, equipo, uso de IA, propiedad del código y soporte, y compare las propuestas por lo que cada una incluye, excluye y documenta. Firme solo un contrato que lo diga por escrito.
El portafolio muestra lo que la empresa ya hizo. Las respuestas muestran cómo va a trabajar en su caso. Quien trabaja bien explica su propio método con claridad, pregunta mucho sobre su operación y deja por escrito lo que queda fuera del alcance.
Qué llevar a la primera reunión con la software house
Llegue con el problema, no con la solución. No necesita un alcance terminado, pero ayuda saber qué genera trabajo, retrasos o errores hoy, quién usa la rutina, qué sistemas ya existen y qué pasa si nada cambia en los próximos meses. Una buena software house convierte eso en alcance; el artículo sobre cómo definir el alcance de un software muestra cómo suele hacerse ese trabajo.
Si tiene documentos, hojas de cálculo, informes o pantallas del proceso actual, llévelos. Muestran en minutos lo que tomaría una reunión entera explicar. Lleve también a quien va a usar el sistema en el día a día, o al menos sus dudas: esa persona suele ver problemas que la gerencia no ve.
Desconfíe de quien se salta esta etapa y llega con la tecnología elegida, el plazo cerrado y el precio en la primera conversación. Sin entender la operación, cualquier número es una apuesta.
Lista de preguntas para la primera reunión
Haga las mismas preguntas a todas las empresas que esté evaluando y anote las respuestas lado a lado. Junto a cada pregunta, lo que vale la pena esperar oír.
- ¿Cómo entienden el problema antes de proponer una solución? Espere oír sobre conversaciones con quienes operan, relevamiento de lo que ya existe, prototipo y validación de hipótesis antes del código.
- ¿Con qué frecuencia vamos a ver software funcionando? La buena respuesta es en cada ciclo corto, con una demostración para probar y aprobar, y no solo al final del proyecto.
- ¿Cómo definen cuándo una entrega está lista? El criterio de aceptación debe acordarse antes de que empiece cada ítem, para que "listo" signifique lo mismo para las dos partes.
- ¿Qué pasa cuando la prioridad cambia a mitad de camino? Un método serio acomoda el cambio en la planificación del ciclo siguiente y muestra el impacto en el plazo, sin esconderlo.
- ¿Quién va a trabajar en el proyecto y quién decide del lado de ustedes? Averigüe si producto, diseño, desarrollo, infraestructura, seguridad y soporte quedan con el mismo equipo o pasan por proveedores distintos. Cada traspaso es un punto donde se pierde información.
- ¿Ya trabajaron con operaciones parecidas a la nuestra? Pida ejemplos concretos: el problema, para quién se hizo, qué se entregó y qué costó trabajo.
- ¿Cómo usan la inteligencia artificial y quién revisa lo que produce? Casi toda software house usa IA hoy. La pregunta es si hay revisión humana antes de producción y en qué herramientas entran sus datos.
- ¿Cómo se tratan el control de acceso, la LGPD y la seguridad? Espere oír que eso entra desde el diseño, con verificación antes de cada publicación, y no como ajuste al final. (La LGPD es la ley brasileña de protección de datos.)
- ¿De quién es el código y qué queda documentado? La propiedad del código y la transferencia de conocimiento deben estar en el contrato, con decisiones, versiones y riesgos registrados.
- ¿Quién atiende después de que el sistema entra en producción? Averigüe el canal, los tiempos de atención y cómo el uso real se convierte en la próxima mejora antes de firmar.
Fíjese también en lo que la empresa pregunta de vuelta. Quien se interesa por su operación, por quién usa el sistema y por lo que ya existe está intentando entender el problema. Quien habla solo de tecnología y de plazo todavía no sabe qué va a construir. Si quiere ver cómo respondemos a estas preguntas, nuestro método está descrito en cómo trabajamos.
Señales buenas y señales de alerta en una propuesta de software
Después de las reuniones llegan las propuestas. Lea cada una buscando los puntos de abajo, que dicen más sobre el riesgo del proyecto que el valor final.
| Punto de la propuesta | Señal buena | Señal de alerta |
|---|---|---|
| Alcance | Enumera lo que entra, lo que queda fuera y las premisas asumidas | Describe el sistema con frases genéricas, sin exclusiones |
| Plazo | Surge de un estudio del alcance y muestra entregas intermedias | Fecha cerrada antes de cualquier conversación sobre la operación |
| Forma de entrega | Software funcionando en cada ciclo, con demostración y aceptación | Nada para ver o probar hasta el final del proyecto |
| Equipo | Dice quién hace cada parte y quién es el punto de contacto | No dice quién trabaja en el proyecto, o subcontrata partes sin avisar |
| Propiedad y documentación | Código, accesos y documentación quedan con el cliente, por escrito | Silencio sobre quién es dueño del código y de los datos |
| Uso de IA | Explica dónde entra la IA y garantiza revisión humana antes de producción | Promete que la IA lo resuelve todo sola y recorta el plazo por eso |
| Después de la entrega | Describe el soporte, el canal de atención y la evolución | Termina en la publicación, sin hablar de quién atiende las solicitudes |
Una propuesta más cara puede resultar la más barata si es la única que dice lo que queda fuera. Un alcance vago es el origen más común de discusiones a mitad del proyecto. Para entender por qué un plazo honesto depende del alcance, vea cuánto tiempo lleva desarrollar un sistema a medida.
Cómo comparar propuestas de distintas software houses
Comparar solo el valor total engaña, porque cada empresa incluye cosas distintas. Arme una hoja de cálculo simple con las mismas filas para todas: qué entra en el alcance, qué queda fuera, cómo se entrega y se acepta cada parte, quién compone el equipo, de quién es el código y qué pasa después de la publicación. Los huecos aparecen solos.
Cuando el problema todavía no está bien definido, tiene sentido contratar primero un estudio corto, que produce un alcance validado y prioridades, y solo después el desarrollo. Así empezamos los proyectos de desarrollo de software a medida: un estudio que define alcance, plazo e inversión antes de cualquier compromiso mayor. Con ese material en mano, también puede pedir propuestas comparables a otras empresas.
Si la duda es anterior, entre tercerizar o contratar personal propio, la comparación entre software house o equipo interno ayuda a decidir antes de abrir la convocatoria.
Qué debe incluir el contrato con la software house
El contrato es donde las buenas respuestas de la reunión se convierten en obligación. Antes de firmar, verifique que trate estos puntos:
- Alcance, premisas y exclusiones. Qué se entregará, qué no, y de qué información o accesos depende el proyecto del lado del cliente.
- Forma de entrega y de aceptación. Cómo se demuestra cada entrega, quién la aprueba y en cuánto tiempo, y qué pasa si no cumple el criterio acordado.
- Cambio de alcance. Cómo se evalúa, estima y aprueba un pedido nuevo antes de que entre, para que ninguna de las partes se lleve sorpresas.
- Propiedad del código y accesos. A quién pertenecen el código, los datos, los ambientes y las cuentas de servicio, y cómo se entrega todo al final. El artículo sobre de quién es el código del software a medida detalla el tema.
- Confidencialidad y tratamiento de datos. Quién puede acceder a los datos, para qué, y las responsabilidades de cada parte ante la LGPD cuando el sistema trata datos personales.
- Soporte y mantenimiento. Canales de atención, tiempos de respuesta, qué es corrección y qué es evolución, y cómo se presupuesta la evolución.
- Salida. Cómo funciona la transición si el contrato termina: entrega de código, documentación y accesos, y un período de apoyo para quien asuma.
Nada de esto necesita estar en lenguaje difícil. Necesita estar por escrito. Lo acordado solo de palabra suele ser recordado de forma distinta por cada parte seis meses después.
Cómo saber si la software house usa IA con responsabilidad
La inteligencia artificial acelera la investigación, el borrador de código, las pruebas y el análisis de logs, y es razonable que la empresa contratada la use. El riesgo está en código generado sin revisión que llega a producción, o en datos del cliente que entran en herramientas que nadie autorizó.
Pregunte quién revisa lo que produce la IA, en qué herramientas entran sus datos y si va a saber en qué etapas se usó. En nuestro caso, ningún código o contenido generado por IA va a producción sin la revisión de un profesional del equipo, que lo verifica, lo corrige y asume la autoría, y el cliente sabe dónde entró la IA.
Cómo contratar una software house siendo un organismo público
Las mismas preguntas valen, pero el camino es otro. En Brasil, los organismos públicos contratan mediante licitación o contratación directa en los casos que la ley permite, hoy regidas por la Ley 14.133/2021. Eso exige planificación antes de la compra: el problema, la solución pretendida y los criterios de aceptación deben estar descritos en los documentos de la contratación, y el contrato tiene fiscalización formal durante la ejecución.
Por eso la documentación pesa todavía más. Ritos, responsables y registros definidos desde el inicio apoyan al fiscal del contrato, y la accesibilidad, la LGPD y el registro de cada movimiento entran en el alcance desde el comienzo. El paso a paso está en la guía sobre cómo contratar software para un organismo público. Con ese cuidado desarrollamos y mantenemos Ágil Cidadão, nuestro sistema de atención al ciudadano.