Métodos prácticos para evaluar la capacidad técnica de un proveedor de desarrollo de software sin conocimientos de programación, basados en indicadores observables de proceso, comunicación y entregables.
Una de las situaciones más incómodas para quien contrata desarrollo de software es la sensación de estar tomando una decisión técnica sin tener conocimientos técnicos. ¿Cómo saber si el proveedor sabe lo que hace si yo no sé programar? ¿Cómo distinguir entre un equipo competente y uno que habla bien pero ejecuta mal?
La respuesta es que la competencia técnica de un equipo de desarrollo deja huellas observables en aspectos que no requieren conocimientos de programación para ser evaluados. La forma en que se comunican, la estructura de sus propuestas, el tipo de preguntas que hacen, cómo gestionan los problemas: todo eso es información sobre su nivel técnico, disponible para cualquiera que sepa qué mirar.
Este artículo propone cinco métodos para evaluar la solidez técnica de un proveedor sin necesidad de entender una línea de código.
En una reunión comercial, el cliente explica lo que necesita y el proveedor responde. Pero las preguntas que el proveedor hace durante esa conversación dicen más sobre su competencia técnica que sus respuestas.
Un proveedor técnicamente sólido hace preguntas que revelan que está pensando en cómo construir, no solo en qué construir:
Después de explicar el proyecto, preguntale al proveedor: "¿Qué es lo que más te preocupa de lo que te conté, técnicamente hablando?" Si no identifica ninguna preocupación, o no entendió la complejidad del proyecto o está evitando ser honesto. Si identifica dos o tres puntos concretos y explica por qué le preocupan, está demostrando criterio técnico sin que necesites entender los detalles.
Una propuesta técnica revela la madurez del proveedor en aspectos que van más allá del contenido:
¿La propuesta incluye una sección de decisiones técnicas y sus justificaciones?
Un proveedor maduro explica por qué eligió ciertas tecnologías — lenguaje de programación, base de datos, servicios cloud — y no otras. No necesitás entender los detalles: necesitás ver que hay un razonamiento detrás de las elecciones. "Usamos X porque es lo que conocemos" no es una justificación técnica, es una preferencia. "Usamos X porque el proyecto necesita Y — velocidad, escalabilidad, integración con Z — y X resuelve eso mejor que las alternativas A y B" es una justificación.
¿Describe la arquitectura en términos que se puedan entender?
Un proveedor técnicamente sólido puede explicar cómo funciona el sistema por dentro sin usar jerga. Si cada pregunta sobre cómo funciona algo recibe como respuesta un término técnico sin traducción, puede ser falta de habilidad para comunicar —lo cual es un problema en sí mismo, porque durante el proyecto vas a necesitar entender qué está pasando— o puede ser una cortina de humo para no mostrar que no hay una arquitectura pensada.
¿La propuesta distingue entre lo que es estándar y lo que es complejo?
Todo proyecto tiene partes rutinarias —un formulario de registro, un panel de administración— y partes que requieren decisiones no triviales —un algoritmo de matching, una integración con un sistema legacy, un procesamiento en tiempo real—. Un proveedor que trata todo como si tuviera la misma complejidad probablemente no entendió el proyecto. Uno que identifica los puntos de mayor riesgo técnico y propone abordarlos primero —con una prueba de concepto, un prototipo, una fase de investigación— está demostrando criterio.
No necesitás entender la decisión. Necesitás ver cómo la explican.
Pedile al proveedor que te cuente sobre un proyecto donde enfrentaron un desafío técnico y cómo lo resolvieron. No importa si usaron tecnología A o tecnología B: importa la estructura del relato.
Un proveedor sólido técnicamente va a contar una historia con esta estructura:
Un proveedor con debilidades técnicas va a contar una historia genérica —"optimizamos el código y mejoró"— sin detalles, sin alternativas consideradas, sin métricas. La diferencia es notoria incluso sin entender los términos técnicos que puedan aparecer.
Las pruebas de software son el indicador más confiable de madurez técnica, y se pueden evaluar sin saber programar.
Un proveedor técnicamente sólido, cuando le preguntás cómo prueba lo que construye, describe un proceso, no una actividad:
Un proveedor con debilidades en testing dice: "Probamos todo antes de entregar" o "nuestro equipo revisa el código". Probar "todo" sin un proceso definido significa probar lo que al desarrollador se le ocurrió probar —que suele ser lo que él mismo construyó y por lo tanto tiende a pasar por alto los mismos puntos ciegos—.
Las pruebas automáticas no son algo que el cliente vea. Son una inversión que el proveedor hace para su propio beneficio —porque detectar un error con pruebas automáticas cuesta menos que corregirlo cuando ya está en producción—. Un proveedor que no invierte en pruebas está ahorrando en el lugar equivocado, y ese ahorro lo termina pagando el cliente en bugs que aparecen después de la entrega.
La forma en que un proveedor gestiona el código fuente dice mucho sobre su nivel técnico sin necesidad de leer una línea:
¿Usan control de versiones?
Preguntá si usan Git —la herramienta estándar de la industria— y si el código está en un repositorio al que el cliente puede tener acceso. Un proveedor que no usa control de versiones o que lo usa de manera informal —"cada desarrollador tiene su copia y después las juntamos"— está operando con prácticas de hace veinte años.
¿Cómo organizan los cambios en el código?
Un equipo maduro no modifica el código directamente sobre la versión que está en producción. Usa ramas —copias de trabajo aisladas— donde desarrolla y prueba cada cambio antes de incorporarlo. Cada cambio está asociado a una funcionalidad o un error concreto, no es una bolsa de "arreglos varios". Esto permite rastrear quién hizo qué, cuándo y por qué —información vital si algo falla y hay que investigar.
¿Hacen revisiones de código?
Preguntá si otra persona del equipo revisa el código antes de que se incorpore al proyecto. La revisión de código —code review en la jerga— es una práctica que detecta errores temprano y distribuye el conocimiento dentro del equipo. Un proveedor donde cada desarrollador publica su código sin que nadie lo revise está operando con un punto único de falla: si ese desarrollador se va, se lleva el conocimiento de cómo funciona lo que construyó.
El objetivo no es asignar un puntaje ni descartar proveedores por una respuesta insatisfactoria. Es identificar fortalezas y debilidades para cada proveedor evaluado y decidir con qué perfil de riesgo se siente más cómodo el negocio.
Un proveedor que es débil en pruebas pero fuerte en comunicación y proceso puede ser adecuado para un proyecto chico y de bajo riesgo. Esa misma combinación puede ser inaceptable para un proyecto que procesa datos sensibles o del que depende la operación diaria del negocio.
La evaluación técnica sin conocimientos de programación es posible porque la competencia técnica no se manifiesta solo en el código: se manifiesta en el proceso, en la comunicación, en la estructura de las propuestas y en la forma de gestionar los problemas. Lo que hace falta no es saber programar, sino saber qué preguntar y qué buscar en las respuestas.
Para complementar esta evaluación con un checklist más amplio de preguntas, el artículo sobre qué preguntas hacer antes de contratar a un proveedor tecnológico cubre quince preguntas agrupadas en cinco áreas. Y si querés entender cómo se comparan dos propuestas una vez que ya evaluaste a los proveedores, revisá cómo comparar dos propuestas tecnológicas.
Más contenido sobre selección de proveedores en la categoría de proveedores tecnológicos.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →