Cómo elegir una empresa de desarrollo de software

Antes de contactar a una empresa de desarrollo de software

Elegir una empresa de desarrollo de software es tanto una decisión de negocio como técnica. Para un pequeño negocio, una clínica, un despacho de abogados o un gobierno local, en Denver o en cualquier otro lugar, la meta es un equipo que entienda el trabajo, explique las ventajas y desventajas, controle los riesgos y dé soporte al software después del lanzamiento.

Antes de la primera llamada, tenga claro qué problema debe resolver el software, quién lo usará, con qué sistemas debe conectarse y qué limitaciones importan. No necesita una especificación técnica completa, pero sí suficiente detalle para recibir una respuesta útil en lugar de una conversación de ventas general. Una descripción común también le permite comparar propuestas con la misma base.

Escriba primero un resumen corto del proyecto

Para una primera conversación bastan de una a tres páginas. Nuestra guía para preparar un proyecto lo explica paso a paso; lo esencial es:

El problema: qué es lento, manual, riesgoso o difícil de seguir hoy.
Los usuarios: personal, clientes, pacientes, residentes, administradores o socios.
Las tareas principales: enviar un formulario, subir un archivo, aprobar una solicitud, ver un estado, sacar un informe.
Las herramientas actuales: hojas de cálculo, programas, bases de datos o sitios web con los que debe conectarse.
Los datos: personales, de salud, legales, financieros o registros públicos.
Lo que fija la fecha: una subvención, un ciclo de presupuesto, una norma o una temporada.
El rango de presupuesto: un rango realista o, al menos, cómo se aprueba el gasto.

Describa resultados, no tecnología. "El personal revisa y aprueba en línea las solicitudes de permisos" dice más que "necesitamos un panel".

Equipo local o remoto: ¿importa que esté en Denver?

Un equipo local ayuda cuando importan los talleres presenciales, las reuniones con las partes interesadas o el conocimiento de los negocios y del sector público de Colorado. Un equipo remoto puede funcionar igual de bien si se comunica con claridad y tiene experiencia relevante. La ubicación importa menos que si la empresa entiende su tipo de organización y puede explicar su proceso.

Compare lo que de verdad afecta al proyecto: si su gente prefiere reunirse en persona, la experiencia con organizaciones parecidas, los horarios de trabajo compatibles, cómo se hacen los talleres, demostraciones, pruebas y capacitación, y si el contrato fija quién comunica qué y cuándo.

Preguntas para la primera llamada

¿Han trabajado con organizaciones como la nuestra? Pida flujos de trabajo comparables, no productos idénticos.
¿Cómo definen el alcance? Escuche si mencionan descubrimiento, funciones de usuario, mapeo de procesos y criterios de aceptación.
¿Quién forma el equipo? Gestión del proyecto, diseño, desarrollo, pruebas, seguridad y su contacto diario.
¿Cómo manejan los cambios? El trabajo a medida cambia a medida que se aclaran los detalles; pregunte cómo se documentan, se cotizan y se aprueban.
¿Cada cuánto veremos software que funcione? Las demostraciones frecuentes permiten a personas no técnicas comprobar el ajuste a tiempo.
¿Qué necesitan de nosotros? Las decisiones, comentarios, datos de prueba y aprobaciones también requieren su tiempo.
¿Qué pasa después del lanzamiento? Corrección de errores, alojamiento, monitoreo, actualizaciones, documentación y capacitación.

Si una empresa no puede explicar su proceso con claridad antes del contrato, es poco probable que la comunicación sea más fácil durante el proyecto.

Cómo revisar trabajos anteriores y referencias

Busque relevancia más que parecido superficial: complejidad similar, datos sensibles, flujos de trabajo, integraciones o acceso público. Un trabajo confidencial quizá no se pueda mostrar en vivo, pero la empresa debería poder describir el problema, los usuarios, las limitaciones y el resultado. Un organismo público también debe preguntar por experiencia en accesibilidad, compras públicas y registros.

Al llamar a las referencias, pregunte si el equipo entendió el negocio antes de construir, si se explicaron los presupuestos y plazos, cómo se manejaron los cambios de alcance, si hubo sorpresas de costo o calendario, si el software se podía usar al lanzarse y cómo ha ido el soporte desde entonces. Las respuestas más útiles describen cómo se resolvieron los problemas.

Quién es dueño del código y del repositorio

Defina la propiedad en el contrato antes de empezar. El repositorio es donde vive el código y su historial; sepa dónde estará, quién controla el acceso y qué pasa si cambia de proveedor. Pregunte por escrito:

¿Seremos dueños del código a medida después del pago?
¿Tendremos acceso al repositorio, idealmente en nuestra propia cuenta?
¿El proveedor conserva componentes reutilizables, y con qué licencia?
¿Qué marcos de trabajo, complementos o servicios requieren licencias o cuotas?
¿Qué documentación recibiremos para el mantenimiento futuro?
¿Podría otro programador calificado continuar el trabajo?

Precio fijo, tiempo y materiales o descubrimiento pagado

Precio fijo: un solo costo para un alcance definido. Sirve si los requisitos son estables y los criterios de aceptación son claros; cuidado con supuestos estrechos y costos de órdenes de cambio.
Tiempo y materiales: se cobra el trabajo realmente hecho. Sirve si el proyecto necesita descubrimiento o iteración; cuidado con un control débil del presupuesto y prioridades poco claras.
Descubrimiento pagado y después una construcción a precio fijo o con tope: funciona bien para quien contrata por primera vez, porque el equipo estudia los procesos, los datos, las integraciones y la seguridad antes de comprometerse con un plan.

Cómo leer un presupuesto

Un solo número no es un presupuesto. Pida qué incluye, qué excluye y qué supone la cifra: descubrimiento, diseño, desarrollo, integraciones, migración de datos, pruebas, gestión del proyecto, puesta en marcha, capacitación y soporte. Luego pregunte qué funciones entran en la primera versión, cuáles se dejan para después, cuántas rondas de revisión incluye, si el alojamiento, las licencias y las cuotas de terceros van aparte y qué haría cambiar el presupuesto. Un presupuesto claro le permite comparar alcance, no solo precio.

Preguntas sobre seguridad, datos y accesibilidad

Espere respuestas concretas siempre que el software maneje datos personales, de salud, legales, financieros o del gobierno:

¿Quién puede acceder a nuestros datos durante el desarrollo y el soporte, y se usan datos reales en las pruebas?
¿Dónde se alojarán la aplicación y la base de datos, y cómo se hacen y se prueban las copias de seguridad?
¿Cómo se manejan y registran el inicio de sesión, los permisos y las acciones de los administradores?
¿Cómo se aplican las actualizaciones de seguridad después del lanzamiento y qué pasa ante una posible exposición de datos?
Para un organismo público: ¿cómo funcionarán los formularios, documentos, mapas y pasos de pago con lectores de pantalla, teclado y otras tecnologías de apoyo? Es mucho más fácil incluir la accesibilidad desde el principio que agregarla después.

Soporte y mantenimiento después del lanzamiento

El lanzamiento no es el final. Antes de empezar, acuerden la corrección de errores durante un periodo fijo, cómo se piden las solicitudes de soporte, el alojamiento y el monitoreo, las actualizaciones de seguridad y de dependencias, las copias de seguridad y las pruebas de recuperación, las mejoras pequeñas y la capacitación. Deje por escrito los tiempos de respuesta, los costos mensuales y lo que se cobra aparte, sobre todo si tiene poco personal técnico.

Señales de alerta

Un precio sin alcance ni supuestos.
No hay un proceso claro de descubrimiento, diseño, pruebas y aprobación.
Resistencia a hablar de la propiedad del código o del acceso al repositorio.
Respuestas vagas sobre seguridad, datos o alojamiento.
No hay un responsable del proyecto ni un plan de comunicación.
Afirmar que un software a medida complejo casi no necesita participación de su equipo.
No hay plan de soporte después del lanzamiento.
Presión para firmar antes de que entienda el contrato.
No hay referencias ni ejemplos relevantes.

Una señal de alerta no siempre significa que la empresa no esté calificada, pero debería llevarle a hacer más preguntas antes de seguir.

Una lista de puntuación para comparar propuestas

Califique cada punto de 1 (débil o poco claro) a 5 (claro y adecuado) y anote el motivo:

Entiende nuestro flujo de trabajo y a nuestros usuarios.
Tiene experiencia con organizaciones como la nuestra.
Proceso de descubrimiento y requisitos claro.
Alcance, supuestos y exclusiones por escrito.
Presupuesto detallado y comprensible.
El tipo de contrato se ajusta a la incertidumbre del proyecto.
Atiende la seguridad y el manejo de datos.
Atiende la accesibilidad, si es para el público.
Define la propiedad del código y el acceso al repositorio.
Define las pruebas, el lanzamiento y la capacitación.
Incluye un plan de soporte y mantenimiento.
Las referencias son relevantes y responden.

Dé más peso a lo que más le importa: un gobierno local quizá priorice la accesibilidad, los registros y el soporte; una clínica, el manejo de datos y los permisos; un pequeño negocio, el ajuste al flujo de trabajo, la claridad del presupuesto y lo fácil que será mantener el software.

Dónde encaja ASL

ASL ofrece desarrollo de software a medida para organizaciones de Denver y Colorado, desde una integración concreta hasta una aplicación interna o la ampliación de una herramienta existente. El trabajo empieza con una primera versión acotada, con pruebas de aceptación que usted puede observar, revisada con datos representativos y aprobados.

La propiedad del código, las licencias, el acceso, la documentación de operación, el alojamiento y el soporte quedan por escrito en el acuerdo del proyecto, y el plan indica quién atiende incidentes, actualizaciones y cambios futuros. Para un software existente, el primer paso es revisar el código actual, cómo funciona y su permiso para cambiarlo.

Preguntas frecuentes

¿Cómo elijo una empresa de desarrollo de software?

Escriba un resumen corto, hable con tres a cinco empresas con las mismas preguntas, compare alcance y supuestos en vez de totales, revise referencias y la propiedad del código, y califique cada propuesta con la misma lista antes de firmar.

¿Conviene contratar una empresa local en Denver?

Un equipo local ayuda con los talleres y con el contexto de Colorado, pero un equipo remoto puede funcionar igual de bien. Elija por experiencia relevante, comunicación clara y responsabilidad, no solo por la ubicación.

¿Quién debe ser dueño del código?

Por lo general, su organización, después del pago, con el repositorio en su propia cuenta y documentación que permita a otro programador continuar. Defínalo en el contrato antes de empezar.

¿Qué es mejor, precio fijo o tiempo y materiales?

El precio fijo sirve para un alcance estable y bien definido; tiempo y materiales sirve cuando hace falta descubrimiento. Muchos primeros proyectos empiezan con un descubrimiento pagado y luego pasan a una construcción a precio fijo o con tope.

¿Qué debe incluir un presupuesto de software?

Qué incluye y qué excluye, los supuestos de la cifra, qué funciones entran en la primera versión, las rondas de revisión, las pruebas, la gestión del proyecto, la puesta en marcha, la capacitación, el soporte y cualquier cuota aparte de alojamiento o licencias.

Guías relacionadas

Conozca el producto completo

Consulte funciones, acceso actual y límites

Cómo elegir una empresa de desarrollo de software: lista para pequeños negocios