Cómo elegir una empresa de desarrollo de software: preguntas que hacer y señales de alarma

La pregunta más importante de todas: ¿quién escribe realmente el código?

Si preguntas una sola cosa al decidir cómo elegir una empresa de desarrollo de software, pregunta quién escribirá personalmente tu código, por nombre, y si las personas en tu reunión de ventas son las personas que estarán en tu repositorio. Esta es la pregunta que expone el patrón más común y más caro de la industria: el engaño de demo-senior, entrega-junior. Un arquitecto curtido conduce el discurso, se gana tu confianza y cierra el trato. Luego la entrega se transfiere en silencio a un banco rotativo de desarrolladores junior, a menudo en el extranjero, mientras la persona senior pasa a la siguiente venta. Pagaste por criterio y obtuviste cabezas.

El daño de esto no es abstracto. Los equipos junior sin supervisión senior producen código que funciona en la demo y se desmorona en producción. Toman decisiones de arquitectura que no están preparados para tomar, acumulan deuda técnica por la que pagarás intereses durante años, y rotan tan a menudo que ninguna sola persona llega a sostener nunca el cuadro completo de tu sistema. Para cuando aparecen las grietas, el senior que te vendió hace tiempo que se fue y la conversación de garantía es incómoda.

Presiona por especificidad. Pregunta cuántas personas tocarán el código, cuál es su nivel de experiencia, dónde están ubicadas, y si la persona senior con la que hablas escribirá y revisará el trabajo real o simplemente supervisará a distancia. Las respuestas vagas aquí son la respuesta. Un modelo liderado por un senior con un único dueño elimina la mayor parte de este riesgo por construcción: cuando la persona que arquitecta el sistema es la persona que lo construye y la persona a la que llamas cuando se rompe, no hay traspaso que pueda salir mal ni brecha entre lo que se prometió y lo que se entrega.

¿Quién es dueño del código? La respuesta debe ser: tú

La propiedad de la propiedad intelectual es la segunda pregunta que nunca debería dejarse a la suposición. Cuando el encargo termina, deberías ser dueño del código fuente, la documentación, la configuración de despliegue y todo lo necesario para ejecutar y extender el software sin el permiso del proveedor. La respuesta correcta a quién es dueño del producto del trabajo es inequívoca: tú lo eres, desde el primer día, con acceso completo al repositorio a medida que se escribe, en lugar de como una entrega final.

Cuídate de los arreglos que retienen apalancamiento en silencio. Algunas firmas te otorgan una licencia para usar el software mientras conservan la propiedad del código subyacente. Otras guardan el fuente en sus propios repositorios y lo liberan solo al finalizar el proyecto, lo que les da un poder enorme en cualquier disputa. Algunas construyen sobre marcos propietarios o librerías internas que no puedes usar ni mantener sin seguir pagándoles. Cada uno de estos convierte un proyecto puntual en una dependencia permanente.

Lee el contrato específicamente buscando las palabras cesión de propiedad intelectual, acceso al código fuente, y qué ocurre con tu código si la relación termina. Si un proveedor titubea en cualquiera de estas, trátalo como una señal sobre toda la relación. Un socio confiado en el valor de su trabajo continuo no tiene razón para retener tu código como rehén.

¿Alcance fijo o tiempo y materiales? Ajusta el modelo al trabajo

La estructura de precios es donde las buenas intenciones chocan con la realidad, y ni el alcance fijo ni el tiempo y materiales son universalmente correctos. Los contratos de alcance fijo funcionan cuando los requisitos están genuinamente bien entendidos y es improbable que cambien. Dan certeza de presupuesto, pero castigan el descubrimiento: cada cambio se convierte en una orden de cambio, y el incentivo se desplaza hacia entregar exactamente lo especificado aun cuando todos pueden ver que es lo equivocado. Los proveedores que cotizan un precio fijo preciso para requisitos vagos o están acolchando fuertemente por el riesgo o planean hacer su margen con las órdenes de cambio.

El tiempo y materiales encaja en trabajos donde el camino es incierto y esperas aprender a medida que construyes, lo que describe a la mayoría del software genuinamente a medida. La contrapartida es que requiere confianza y visibilidad, porque estás pagando por esfuerzo en lugar de por un resultado definido. La forma de hacerlo seguro no es evitarlo sino exigir los controles que lo mantienen honesto: iteraciones cortas, software funcionando que puedes ver cada semana, y la capacidad de detener o cambiar de dirección en cualquier punto sin penalización.

La estructura importa menos que la cadencia. Un socio que te muestra software corriendo en un ritmo semanal te da la protección real, que es la capacidad de juzgar el progreso con tus propios ojos en lugar de confiar en un informe de estado. Esa cadencia funciona bajo cualquier modelo de precio y vale más que cualquier cláusula contractual.

Referencias, soporte y cómo se comporta la relación bajo presión

Pide referencias y de verdad llámalas, pero haz mejores preguntas que si quedaron contentos. Pregunta si las personas que vendieron el encargo fueron las personas que hicieron el trabajo. Pregunta qué ocurrió cuando algo se rompió, cuánto tardaron en responder, y si las estimaciones se sostuvieron. Pregunta si todavía son dueños de lo que se construyó y pueden mantenerlo. La señal útil no es el elogio; es cómo se comportó el proveedor cuando el proyecto se puso difícil.

Sé específico sobre el soporte y los niveles de servicio antes de firmar, porque aquí es donde muchos encargos fracasan en silencio. Establece qué ocurre después del lanzamiento, qué tiempos de respuesta puedes esperar para problemas críticos, a quién llegas realmente cuando llamas, y si el soporte es la misma persona senior que construyó el sistema o una cola de tickets separada que nunca ha visto tu código. Un entendimiento claro y por escrito del soporte posterior al lanzamiento te dice si el proveedor te ve como una relación o como una transacción.

Por último, pondera la comunicación directamente. Deberías saber quién es tu único punto de contacto, con qué frecuencia verás el progreso, y en qué zona horaria trabaja. Los equipos distribuidos en muchas zonas horarias pueden añadir días de latencia a cada decisión. Un socio con base en EE. UU. trabajando en tus horas de negocio, con una persona responsable que contesta el teléfono, elimina una categoría de fricción que los compradores subestiman constantemente hasta que la están viviendo.

• ▸Promesas de talento senior en el discurso, sin un compromiso nombrado de que esas personas escribirán tu código.
• ▸Renuencia a cederte la propiedad completa del código fuente y el acceso al repositorio desde el principio.
• ▸Un precio fijo preciso cotizado contra requisitos vagos o sin terminar.
• ▸Nada de software funcionando que mostrar hasta tarde en el proyecto, con el progreso reportado solo como actualizaciones de estado.
• ▸Equipos grandes con alta rotación, entrega en el extranjero y ningún dueño responsable único.
• ▸Respuestas vagas o evasivas sobre el soporte posterior al lanzamiento y los tiempos de respuesta.

Juntándolo todo

Elegir bien tiene que ver sobre todo con eliminar riesgo más que con perseguir la oferta más baja. La propuesta más barata a menudo carga el costo total más alto una vez que tienes en cuenta el retrabajo, las órdenes de cambio, el amarre y el costo de un sistema que nadie puede mantener. Las preguntas anteriores están diseñadas para sacar esos costos a la luz antes de que te lleguen.

El patrón que resuelve en silencio la mayoría de estos riesgos de una vez es la entrega liderada por un senior con un único dueño: la persona que arquitecta el sistema lo escribe, es dueña de la relación, lo soporta después del lanzamiento y te entrega el código a lo largo del camino en lugar de al final. Ese no es el único modelo válido, y los programas más grandes a veces genuinamente necesitan equipos más grandes. Pero para la mayoría del software a medida y del trabajo de integración empresarial, menos traspasos significan menos maneras de que el encargo salga mal. Cuando evalúes a cualquier proveedor, mídelo contra ese estándar: claridad sobre quién lo construye, certeza de que tú eres dueño, y una cadencia que te deja ver la verdad cada semana.