Cómo saber si un proveedor de software realmente puede construirlo

El sitio de todo proveedor se ve igual. Casos de éxito con porcentajes impresionantes, una página de equipo, una lista de tecnologías, un diagrama de proceso con cuatro o cinco fases. Nada de eso distingue a un equipo que ha operado sistemas en producción de uno que no, porque nada de eso es falsable.

Lo que sí los distingue es cómo responden preguntas sobre el fracaso. El éxito tiene muchos narradores plausibles. El fracaso solo tiene a quienes estuvieron ahí.

Seis preguntas

Hazlas a cualquiera que estés considerando en serio. El valor no está en la respuesta concreta, está en si la respuesta tiene textura.

1. Cuéntame un proyecto que salió mal, y qué harías distinto.

La respuesta que buscas es concreta y se autoimplica: una decisión que tomaron, por qué parecía correcta, qué costó y qué cambió después. La respuesta que debe preocuparte culpa al cliente, culpa a un proveedor o describe una dificultad que no fue culpa de nadie.

Todo el mundo ha tenido un proyecto malo. Un equipo que no puede nombrar ninguno o es inexperto o no está siendo franco, y ninguna de las dos es lo que quieres.

2. ¿Cómo es su rotación de guardias, y quién está en ella?

Los equipos que construyen sistemas y los entregan no tienen una. Los equipos que operan lo que construyen sí, y te cuentan cómo funciona sin preparación, porque lo viven.

3. Cuéntame su último incidente de producción.

Tiempo de detección, a quién avisaron, cuál fue el arreglo, qué cambió después. Un equipo que opera software tiene esa historia lista. Uno que no, va a describir un proceso y no un evento.

4. ¿Cómo manejan un requisito que resulta estar mal a mitad del proyecto?

Todo proyecto los tiene. La respuesta revela el modelo de contrato y la honestidad. "Lo levantamos, cotizamos el cambio y tú decides" es viable. "Eso no pasa, nuestro discovery es exhaustivo" es una afirmación que se pondrá a prueba y fallará.

5. ¿Qué se negarían a construir?

Un proveedor sin respuesta construirá lo que le pidan, incluida la cosa que no debería existir. La negativa concreta importa menos que tener una.

6. ¿Quién exactamente va a trabajar en esto, y en qué más está?

La distancia entre quienes aparecen en la presentación y quienes entran al proyecto es el problema más viejo de esta industria. Pide nombres, pregunta qué porcentaje de su tiempo recibes, y ponlo en el contrato. Si quieres hacernos estas preguntas directamente, para eso está hablar con un ingeniero.

Qué pedir en lugar de un portafolio

Los portafolios están curados. Estos son más difíciles de montar.

Pide	Qué revela
Una muestra de código real, depurada	Si el código tiene pruebas, comentarios que explican el porqué y estructura legible
Una referencia que terminó la relación	Cómo se comportan cuando el proyecto acaba, que es cuando más importa
Un post-mortem que hayan escrito	Si los fallos se analizan o se absorben
Su proceso de despliegue, de punta a punta	Si publicar es rutina o es un evento
Un discovery pagado antes del compromiso completo	Si su pensamiento vale lo que cobran, con riesgo bajo
Su respuesta sobre acceso a datos de producción	Si el acceso es controlado o es ambiental

Esa última fila merece énfasis. Pregunta quién dentro del proveedor puede leer tus datos de producción, cómo se concede ese acceso y si queda registrado. Un proveedor cuyos ingenieros tienen todos acceso permanente a producción te está diciendo que sus controles son informales, diga lo que diga su página de seguridad. Los nuestros están descritos en nuestras prácticas de seguridad.

Señales que deberían cerrar la conversación

Algunas respuestas descalifican por sí solas:

• Precio cerrado por un sistema que no han examinado. O el precio está inflado o el alcance se va a renegociar. Ambas te cuestan.
• Ningún ingeniero con nombre, solo roles. Estás comprando capacidad de un pool, lo cual está bien si eso es lo que quieres y es un problema si te dijeron otra cosa.
• Ninguna opinión sobre tu arquitectura. Un proveedor sin postura todavía no ha pensado en tu problema.
• Cumplimiento descrito como "eso lo manejamos". Para datos regulados, o lo han hecho bajo un acuerdo firmado o no. Mira qué obliga realmente un BAA.
• Resistencia a poner los supuestos por escrito. Los supuestos escritos son cómo un alcance cerrado sobrevive al contacto con la realidad.

Empieza más pequeño que la cosa entera

La evaluación más fiable no es una evaluación. Es un proyecto pagado pequeño, con un entregable real, hecho antes del compromiso grande.

Dos semanas de discovery producen un artefacto que puedes juzgar por su mérito: ¿muestra que entendieron el sistema, encontró cosas que no sabías, el plan es algo que seguirías? Y si la respuesta es no, lo averiguaste gastando una fracción del presupuesto. Qué debe producir ese proyecto está en qué debe entregar un discovery de dos semanas.

La cuestión geográfica es aparte y suele confundirse con esta. Está en nearshore, offshore o EE. UU..