Que una empresa de software escriba una guía para elegir empresa de software supone un conflicto de intereses evidente, así que empecemos por la credencial que importa: una parte considerable de nuestro trabajo consiste en heredar proyectos que salieron mal en otro sitio. Rescates, reconstrucciones, modernización de sistemas que tienen tres años y ya son sistemas heredados. Vemos desde dentro qué aspecto tiene la elección equivocada, dieciocho meses después de firmar el contrato - y el patrón es notablemente constante. Casi nunca el cliente eligió mal por descuido. Eligió mal porque el proceso de evaluación habitual mide las cosas equivocadas.
Desde fuera, las empresas de desarrollo son casi indistinguibles. Las webs enseñan los mismos casos, los mismos logotipos, las mismas afirmaciones sobre ingenieros senior y entrega ágil. La nuestra incluida. Y las herramientas a las que recurre el comprador para deshacer el empate - porfolios, referencias, tarifas - son exactamente las que toda empresa lleva años puliendo. Esto es una lista de comprobación para mirar más allá de ellas.
Por qué las referencias y los porfolios inducen a error
Un porfolio es un resumen de los mejores momentos. Toda empresa enseña sus tres mejores proyectos, y esa selección no dice nada del encargo mediano: un porfolio es sesgo de supervivencia por construcción. Los proyectos que se alargaron un año, los que se entregaron y se abandonaron en silencio y los que acabaron en disputa no están en la web, y la confidencialidad regala a cualquier empresa una razón respetable para los huecos. Leer un porfolio le dice cuál es el techo de la empresa. Usted va a vivir en su mediana.
Las referencias tienen el mismo defecto con una cara más amable: las elige la empresa. Le darán los tres clientes más satisfechos de los últimos cinco años, y nunca le darán el teléfono de aquel cuyo proyecto se abandonó. Incluso una referencia sinceramente entusiasta es una prueba débil, porque el resultado dependió del equipo concreto asignado aquel año - y las personas que construyeron el caso estrella pueden haber cambiado de empresa dos veces desde entonces.
Aun así merece la pena llamar a las referencias - solo hay que hacer otras preguntas. No «¿quedó satisfecho?», que invita a un sí ensayado, sino «cuénteme el peor mes del proyecto y qué hicieron al respecto». Todo encargo de cierto tamaño tiene un mes malo. Que la empresa sacara el problema a la mesa pronto, repreciara con honestidad y lo resolviera - o que enmudeciera y siguiera facturando - es lo más informativo que una referencia puede contarle.
Qué hace bueno a un socio de ingeniería de software: cuatro señales
La primera es cómo estiman. Una empresa que le da una cifra antes de entender su operación le está contando cómo trabaja. Una estimación real viene después de preguntas reales: sobre sus flujos de trabajo, sus datos, los sistemas que ya tiene en marcha, las excepciones que hacen que su negocio sea suyo. Si el precio llega antes que esas preguntas, no se dedujo de su proyecto; se fijó para ganarlo, y la diferencia entre esas dos cifras aparecerá más tarde, disfrazada de peticiones de cambio. Si quiere un punto de referencia antes de la primera llamada, aquí tiene lo que de verdad determina el coste del software a medida.
Cómo se estima predice cómo se entrega. Una empresa que adivina el precio también adivinará la construcción.
La segunda es a qué dicen que no. Pregunte directamente: ¿qué proyectos han rechazado y por qué? Una empresa que no sabe nombrar ninguno o acepta todo lo que paga - con lo que su proyecto lo hará quien esté libre, no quien encaje - o nunca ha pensado en serio dónde es realmente buena. La forma de los rechazos de una empresa es el mapa más honesto de su competencia que va a obtener en un proceso comercial.
La tercera es quién escribe el código. Las personas de sus tres primeras reuniones no suelen ser las que construirán su sistema. Pida conocer al responsable técnico que se haría cargo de su proyecto - el ingeniero de verdad, no el director de entrega - y hágale preguntas técnicas sobre su problema. Una empresa que confía en sus ingenieros se los pone delante sin dudar. Una empresa que le mantiene en la capa comercial está administrando una impresión.
La cuarta es cómo es el traspaso. El final de un encargo es donde más divergen los incentivos: en todo lo anterior al proveedor le conviene hacerlo bien; la documentación, el traspaso y su independencia son las partes que solo le cuestan. Así que pida pruebas: un registro de arquitectura anonimizado, un runbook o un paquete de traspaso de un proyecto terminado. Una empresa capaz de enseñarle uno ya lo ha hecho antes y espera que usted pueda funcionar sin ella. Una empresa que habla de asociación en lugar de enseñar un documento está describiendo con educación una dependencia forzada.
Esas cuatro señales son lo que separa a un socio de ingeniería de software de un proveedor que vende horas: uno responde del resultado; el otro, del parte de horas.
Señales de alarma por las que conviene marcharse
La suplantación de perfiles senior es la más común. Los ingenieros senior llevan la presentación y el descubrimiento; el historial de commits cuenta otra historia a partir del segundo mes. Protéjase de forma estructural, no confiando: personas nombradas en el contrato, derecho a conocer a cualquier sustituto antes de que se incorpore y un vistazo a quién aparece de verdad en las reuniones diarias.
Facturación por horas sin disciplina de alcance. Facturar por horas no es malo en sí - pero por horas sin hitos, sin alcance escrito y sin definición de terminado significa que el proveedor gana más cuanto más dure su proyecto, y nada en la estructura empuja en sentido contrario. La pregunta no es «¿por horas o cerrado?», sino «¿dónde reside la responsabilidad de la estimación?». Si la respuesta es que en usted, entonces la disciplina de alcance es usted. (Explicamos la alternativa en por qué falla el software a precio cerrado y cómo lo arregla la facturación por hitos.)
«Podemos empezar el lunes.» Una empresa cuyo equipo entero está disponible mañana le está diciendo algo sobre la demanda de su trabajo. Los huecos genuinos existen - un proyecto termina, una fecha de inicio se retrasa -, pero un equipo senior completo esperando en el banquillo es raro en cualquier empresa que merezca la pena contratar. Trate la disponibilidad inmediata a gran escala como trataría a un cirujano sin lista de espera.
Ninguna opinión sobre las partes aburridas de su sector. Todo dominio tiene su maquinaria poco vistosa - conciliaciones, casos límite regulatorios, excepciones de precio, reglas de planificación - y es ahí donde los proyectos se hunden de verdad. Un socio no necesita experiencia previa en su sector, pero sí necesita que se le enciendan los ojos con las partes aburridas, porque es lo que pasará construyendo la mayor parte del proyecto. Si la conversación vuelve una y otra vez a la superficie emocionante del producto, las nueve décimas partes tediosas se aprenderán a su costa.
Ocho preguntas para la primera llamada
Las señales se leen mejor cuando se piden directamente. Merece la pena hacer estas preguntas literalmente, más o menos en este orden.
- «¿Qué necesitarían saber sobre nuestra operación antes de poner una cifra a esto?»
- «¿Qué proyectos han rechazado en el último año y por qué?»
- «¿Quién escribiría exactamente el código? ¿Podemos conocerlos antes de firmar?»
- «Cuéntennos un proyecto que salió mal. ¿Qué cambiaron después?»
- «¿Cómo es el traspaso? ¿Podemos ver un ejemplo anonimizado de un proyecto real?»
- «¿Qué recortarían de nuestro briefing para tener antes una primera versión en producción?»
- «¿Qué pasa si queremos parar a los tres meses?»
- «¿Cómo sabríamos, a los seis meses, si esto está funcionando?»
Escuche la concreción y una ligera incomodidad. Las buenas respuestas nombran proyectos reales, errores reales y restricciones reales; las malas son suaves, genéricas y complacientes al instante. La pregunta seis pone a prueba el criterio sobre el alcance: el socio adecuado defenderá una primera versión enfocada en 2-3 meses frente a una plataforma en un año, y le dirá qué partes de su briefing pueden esperar. La pregunta siete es la prueba de la dependencia: un socio que planea ganarse la renovación abarata la salida - sus repositorios, su infraestructura, la documentación como entregable -, mientras que un proveedor que planea retenerle se pondrá vago.
Cuándo cambiar de socio de desarrollo de software
Muchos lectores de esta lista no están eligiendo su primer socio: están decidiendo si sustituyen al actual. Las señales de alarma rara vez son un único desastre. Son una deriva: fechas incumplidas que dejan de venir con explicaciones, un sistema que solo el proveedor sabe desplegar, peticiones de cambio que cuestan más cada trimestre y un equipo que rota más deprisa de lo que documenta. Si se cumplen dos de ellas, aplique la lista anterior a su socio actual como si lo conociera por primera vez.
Si decide cambiar, el orden importa más que el nuevo proveedor. Asegure primero los repositorios, las cuentas de infraestructura y las credenciales; consiga la documentación que exista, por escasa que sea, y haga el traspaso por etapas en lugar de en un único corte. Heredar sistemas de esta forma es una parte importante de lo que hacemos - lea cómo cambiar de socio de desarrollo de software sin perder el proyecto y modernización de sistemas heredados sin la gran reescritura.
Reduzca el riesgo: empiece más pequeño que el contrato
El problema más profundo de la elección de socio no es ninguna señal concreta; es que el proceso habitual le pide decidirlo todo de golpe: dos llamadas, una propuesta, un compromiso de seis cifras. No hay entrevista que dé certeza sobre cómo se comporta una empresa en condiciones reales, pero sí puede comprar una pequeña muestra de ese comportamiento. En lugar de firmar el contrato grande, empiece con un encargo corto de diagnóstico: una o dos semanas dentro de un solo flujo de trabajo, que terminan en una estimación, un esquema de arquitectura y un caso de amortización que son suyos pase lo que pase después.
Un diagnóstico convierte cada señal de este artículo de afirmación en observación. Usted ve cómo estiman en lugar de preguntarlo. Conoce a los ingenieros que construirían de verdad, porque un diagnóstico es trabajo técnico que el equipo comercial no puede hacer. Y acaba con un artefacto en la mano que puede llevarse a otra empresa - esa es la prueba definitiva. Si el resultado solo sirve si los contrata, era un documento de venta disfrazado de entregable. Algunas empresas cobran por esto y otras hacen una versión gratuita - nosotros la hacemos, y es así como empieza cada uno de nuestros encargos - pero que sea de pago o gratuito importa menos que la forma: pequeño, acotado y con un resultado que sobrevive a la relación.
Es además la forma más barata de descubrir que una empresa no le conviene - la nuestra incluida. Aplique bien esta lista y puede que concluya que otro socio encaja mejor con su proyecto que nosotros. Eso no es un fallo de la lista; es la lista funcionando. El sentido de empezar pequeño es que la conclusión, caiga del lado que caiga, le cuesta dos semanas en lugar de dos trimestres.
La versión comprimida: ignore el resumen de mejores momentos y lea a la empresa por su comportamiento. El socio que quiere pone precio solo después de entender, sabe decirle qué rechaza, le pone ingenieros delante, le enseña un documento de traspaso real y estructura el encargo de modo que marcharse sea fácil. Porque cómo se comporta una empresa antes del contrato - mientras todavía intenta ganarle - es el techo de cómo se comportará después.
Preguntas frecuentes
¿Cómo elijo el socio de desarrollo de software adecuado?
Juzgue a la empresa por su comportamiento, no por su porfolio: cómo estima, qué trabajos rechaza, si puede conocer a los ingenieros que construirían su sistema y si es capaz de enseñarle un documento de traspaso real. Después, empiece con un encargo pequeño y acotado antes de firmar el contrato grande.
¿Qué hace bueno a un socio de ingeniería de software?
Un buen socio pone precio solo después de entender su operación, nombra a los ingenieros que harán el trabajo, saca los problemas a la luz pronto en lugar de seguir facturando y estructura el encargo de modo que marcharse sea barato: sus repositorios, su infraestructura y la documentación como entregable.
¿Cuáles son las señales de alarma al contratar una empresa de desarrollo de software?
Perfiles senior en la presentación y junior en los commits, facturación por horas sin hitos ni alcance escrito, un equipo entero disponible para empezar el lunes y ningún interés por las partes poco vistosas de su negocio, que es donde de verdad se hunden los proyectos.
¿Me conviene un socio de software a precio cerrado o por horas?
Ningún modelo es seguro por sí solo. Pregunte dónde reside la responsabilidad de la estimación. La facturación por hitos - un precio cerrado por cada entregable aceptado - mantiene al proveedor responsable de su estimación sin obligarle a usted a especificarlo todo de antemano.
¿Cuándo debería cambiar de socio de desarrollo de software?
Cuando las fechas incumplidas dejan de venir acompañadas de explicaciones, cuando solo el proveedor sabe desplegar o entender el sistema, o cuando cada petición de cambio cuesta más que la anterior. Asegure primero el acceso al código, la infraestructura y la documentación, y después haga el traspaso por etapas en lugar de en un único corte.