Cómo elegir una empresa de software: preguntas, contrato y código

Esta es la pregunta más importante. Si el contrato no establece con claridad que el código fuente pasa al cliente una vez completado el pago, el código puede quedarse en la agencia. Si más adelante usted quiere trabajar con otro equipo, o si usted y la agencia se separan, su acceso a su propio producto queda entonces en riesgo. Imagine a un fabricante de suelos que se enemista con la agencia que escribió su sistema de pedidos. Si el código está en el servidor de la agencia, puede que el fabricante ni siquiera pueda acceder a su propio flujo de trabajo.

Junto con la propiedad, importa el acceso. ¿A nombre de quién se abren el repositorio de código, el servidor, el nombre de dominio y las cuentas de terceros? Abrirlos a nombre del cliente resuelve desde el principio el punto que más problemas causa después. Para la redacción jurídica detallada conviene consultar a un abogado.

La entrega es más que salir en producción. Una buena entrega incluye la transferencia ordenada del código fuente, las notas de instalación, los datos del entorno y el acceso de administrador. Si otro desarrollador puede poner en marcha el producto a partir de esos documentos, la entrega está completa. Una forma práctica de comprobarlo es hacer que un desarrollador independiente lea las notas de instalación antes de la entrega.

Los criterios de aceptación y el proceso de pruebas deben ponerse por escrito de antemano. También debe hablarse de un periodo de garantía: corregir sin coste, durante un tiempo determinado, los fallos que aparezcan tras la entrega es una salvaguarda que ofrecen la mayoría de las empresas serias.

• El código fuente y su historial de versiones se transfieren al cliente.
• Las notas de instalación y de entorno se entregan por escrito.
• El acceso de administrador se crea bajo la propia cuenta del cliente.
• Los criterios de aceptación y el proceso de pruebas se redactan de antemano.
• Se define el periodo para corregir fallos tras la entrega.

El software no termina con la entrega. Necesita actualizaciones de seguridad, renovación de dependencias y pequeñas mejoras. El acuerdo de mantenimiento debe indicar con claridad qué cubre, cómo se notifica un fallo y cuál será el tiempo de respuesta. De lo contrario, cada petición pequeña se convierte en una negociación aparte, y ante un fallo urgente se discute quién es el responsable.

La empresa que mantiene el sistema no tiene por qué ser la que lo construyó, pero un código ordenado y documentado es lo que hace posible ese cambio. Una empresa que no habla de mantenimiento al inicio de un proyecto suele no hablar de él después tampoco. Preguntar por ello en la primera reunión es, por tanto, la forma más rápida de saber si una empresa respalda su producto.

Si el trabajo de una empresa pequeña depende de un único desarrollador, el proyecto puede quedarse parado cuando esa persona se va. Por eso hay que preguntar quién dirigirá el proyecto, si hay una persona de respaldo y cómo se comparte el conocimiento.

La documentación escrita, la revisión de código y una rutina de desarrollo compartida son los signos concretos de continuidad. Es igual de importante averiguar si la persona de la reunión comercial es la que hará el trabajo. Si puede, hable una vez directamente con el desarrollador que lo hará; saber explicar cuestiones técnicas con palabras sencillas es una buena señal.

El error más común es elegir solo por la cifra presupuestada. Un presupuesto bajo suele significar un alcance estrecho, una definición vaga o peticiones adicionales que llegan después. El segundo error es no comprobar las referencias. Hablar con clientes anteriores sobre lo que ocurrió tras la entrega resulta más instructivo que la mayoría de las presentaciones.

El tercer error es no cuestionar las decisiones técnicas. La tecnología con la que se construye el producto decide si otro equipo podrá continuarlo más adelante. Las tecnologías muy extendidas y bien documentadas suelen conllevar menos riesgo. Una estructura muy nueva, o que solo entiende esa empresa, puede hacer el mantenimiento costoso y difícil.

• Mirar solo el precio: deben compararse el alcance y los supuestos.
• No pedir referencias: hable con un cliente anterior.
• No leer el contrato: se saltan las cláusulas de propiedad y mantenimiento.
• Confundir al comercial con el desarrollador: pregunte quién hará el trabajo.

Una empresa que da un precio de inmediato, sin preguntar por el alcance, debe evaluarse con cuidado. Una empresa que propone soluciones sin escuchar, se niega a entregar el código fuente o insiste en mantener las credenciales de acceso en su propia cuenta puede dejarle dependiente más adelante. Ninguno de estos puntos es por sí solo prueba de mala fe, pero cada uno exige una explicación antes de que usted firme.

Una gran empresa de software es innecesaria para un trabajo pequeño y puntual, y un equipo de una sola persona es arriesgado para un sistema crítico y duradero. La elección correcta es aquella en la que el tamaño y la estructura de la empresa se corresponden con el tamaño y la vida útil del trabajo.