Antes de contratar a un socio de desarrollo de software, averigüe exactamente quién escribirá el código, qué sistemas similares ha entregado, cómo se definen el alcance y la aceptación, y quién es el propietario del código desde el primer día. Las respuestas vagas a cualquiera de estas preguntas son una señal de alarma más seria que un precio alto.
Averigüe quién escribirá realmente el código
Las personas de la reunión comercial no suelen ser las que construyen su sistema. Pida los nombres, los roles y la experiencia de los ingenieros que trabajarán en el proyecto, y pida hablar con el responsable técnico antes de firmar.
Pregunte si alguna parte del trabajo se subcontrata o la hacen freelances. Ambas opciones pueden funcionar bien, pero usted debe saberlo, y el socio debe responder de todas las personas que incorpore. Pregunte también qué ocurre si un ingeniero clave se va a mitad de proyecto y quién paga el tiempo que necesita su sustituto para ponerse al día.
- ¿Quién es el responsable técnico y qué parte de su tiempo dedica a este proyecto?
- ¿Qué ingenieros son empleados y cuáles son subcontratistas o freelances?
- ¿Cómo selecciona y verifica a los especialistas que incorpora?
- ¿Cuál es el procedimiento si alguien se va o no encaja?
Pida una experiencia que se corresponda con su problema
Una larga lista de clientes demuestra poco si nada en ella se parece a su proyecto. Pida ejemplos con restricciones similares: el mismo tipo de sistema, un tráfico o una sensibilidad de los datos comparables y un contexto normativo parecido. Después, pregunte qué hizo ese equipo en cada caso, no lo que consiguió el programa completo del cliente.
Tenga claro de quién es la experiencia que está comprando. Algunas empresas presentan la trayectoria individual de sus ingenieros, algo legítimo si se dice con honestidad. Pregunte cuándo se fundó la empresa, qué trabajos se hicieron con sus propios contratos y si puede hablar con un cliente anterior.
Deje por escrito el alcance, los hitos y la aceptación
Muchos conflictos vienen de un alcance que nunca se puso por escrito con precisión. Una buena propuesta enumera los entregables, divide el trabajo en hitos y define cómo se acepta cada hito: por ejemplo, pruebas que pasan, una demostración en un entorno de preproducción o documentación entregada.
Pregunte cómo se gestionan y se valoran las solicitudes de cambio, y cuál es el modelo comercial. El precio cerrado encaja con un trabajo bien definido, mientras que el modelo de tiempo y materiales encaja con la fase de descubrimiento y con requisitos que evolucionan. En ambos casos, debería ver las hipótesis en las que se basa la estimación.
Resuelva la propiedad del código y el traspaso antes de empezar
El contrato debe indicar que el código y la propiedad intelectual asociada son suyos, y en qué momento se transfiere esa propiedad. Pida que los repositorios, las cuentas en la nube y los dominios se creen en su organización desde el primer día, con el socio invitado como colaborador, para no depender nunca de él para el acceso.
Planifique el traspaso al principio, no al final. Pregunte qué recibirá: documentación, registros de decisiones de arquitectura, manuales de operaciones y sesiones de trabajo con su propio equipo. Compruebe qué licencias de terceros y de código abierto usará el proyecto, porque conllevan obligaciones.
Acuerde cómo verá los avances
Nunca debería tener que preguntar si el proyecto va según lo previsto. Acuerde un ritmo fijo, como una demostración semanal de software que funciona y un breve informe escrito sobre los avances, los riesgos y las decisiones que se necesitan de usted.
Pida acceso directo al gestor de incidencias y al repositorio, y un interlocutor con nombre y apellidos que responda de la entrega. Aclare cómo se escalan los problemas y en cuánto tiempo puede esperar una respuesta.
Ponga a prueba sus prácticas de seguridad, no sus sellos
Pregunte cómo acceden los ingenieros a sus sistemas y datos, cómo se guardan los secretos, cómo se revisa el código antes de publicarlo y cómo se comprueban las dependencias frente a vulnerabilidades conocidas. Las respuestas concretas importan más que una diapositiva llena de logotipos.
Si el socio va a tratar datos personales por cuenta de usted, necesita un contrato de encargo del tratamiento que cumpla los requisitos del RGPD. Si un proveedor afirma tener una certificación, pida el certificado y su alcance, y confirme que cubre al equipo y los servicios que usted contrata.
Señales de alarma que deberían cortar la conversación
Una señal de alarma aislada puede tener explicación. Varias juntas suelen indicar que el proyecto será más difícil de lo necesario.
- No pueden nombrar a los ingenieros que harán el trabajo.
- Los casos de éxito muestran resultados, pero no lo que hizo realmente ese equipo.
- La estimación llega antes de que nadie haya hecho preguntas detalladas sobre su sistema.
- Los repositorios y las cuentas en la nube siguen bajo el control del socio.
- Los hitos no tienen criterios de aceptación por escrito.
- Las preguntas de seguridad reciben respuestas tranquilizadoras genéricas en lugar de prácticas concretas.
Puntos clave
- Conozca al responsable técnico y sepa quién escribirá el código antes de firmar.
- Valore la experiencia por su parecido con sus restricciones y por lo que hizo el propio equipo.
- Unos hitos por escrito con criterios de aceptación claros evitan muchos conflictos de alcance.
- Mantenga los repositorios y las cuentas en la nube en su propia organización desde el primer día.
- Pida prácticas de seguridad concretas y pruebas de cualquier certificación que afirme tener un proveedor.
Preguntas frecuentes
¿Con cuántos socios debería hablar antes de elegir uno?
Con los suficientes para comparar diferencias reales de enfoque, lo que en la mayoría de los proyectos significa unos pocos. Dé a cada uno el mismo brief y las mismas preguntas, para que las respuestas sean comparables.
¿Precio cerrado o tiempo y materiales: qué contrato elegir?
El precio cerrado encaja con un trabajo que se puede especificar en detalle antes de empezar. El modelo de tiempo y materiales encaja con la fase de descubrimiento, los requisitos cambiantes y el desarrollo continuo, siempre que reciba informes transparentes y demostraciones periódicas.
¿Qué debe tratarse en una primera llamada con un posible socio?
Su objetivo, sus restricciones, sus plazos y sus sistemas actuales, además de las preguntas que el socio le haga a usted. Un socio que hace preguntas detalladas sobre su sistema en la primera llamada suele ser uno que lo estimará con honestidad. En SDK Enterprises, esa primera llamada es una conversación de 30 minutos en francés o en inglés.