Cómo elegir una empresa de desarrollo de software

Somos una de las empresas que quizá esté evaluando, lo que hace este artículo interesado por construcción. La mitigación consiste en incluir las preguntas que nos incomodan y ser explícitos sobre dónde le serviría mejor una firma mayor o un autónomo. Juzgue el artículo por si se sostiene al aplicárnoslo.

Qué comprueban la mayoría de los procesos de selección, y por qué falla

El proceso habitual compara trabajos anteriores, tamaño del equipo, listas de tecnologías y precio. Nada de eso predice gran cosa.

Los trabajos anteriores muestran qué se entregó, no si fue a tiempo, ni si el cliente volvería a comprar, ni si sigue funcionando. Las capturas de pantalla son la parte más fácil de producir de un proyecto y la menos correlacionada con el éxito.

El tamaño del equipo predice capacidad, no calidad, y pasado cierto punto predice coste de coordinación. Las listas de tecnologías son casi carentes de sentido: toda agencia lista todas las tecnologías, y lo que importa es si las personas concretas de su proyecto conocen bien la pila concreta.

El precio lo hemos tratado en otro sitio. En resumen, el presupuesto más bajo suele ser el menos completo.

Las preguntas que sí predicen el resultado

1. ¿Puede describirnos nuestro negocio con sus palabras?Haga esta pregunta al final de la primera conversación. Un proveedor que ha entendido el problema puede reformularlo con sus propias palabras, incluida la parte que lo hace incómodo. Quien no pueda construirá lo que usted dijo literalmente, que nunca es exactamente lo que quería decir.
2. ¿Qué le haría rechazar este proyecto?Todo el que se ha quemado alguna vez tiene una respuesta: ningún responsable interno, un plazo fijado antes que el alcance, un cliente que no toma decisiones. Un proveedor sin criterios para rechazar trabajo o ha tenido suerte o no está siendo sincero con usted.
3. ¿Quién escribirá esto exactamente, y en qué más está trabajando?Las personas de la presentación a menudo no son las del proyecto. Pida nombres y compromisos actuales. Esta sola pregunta elimina toda una categoría de decepciones.
4. Muéstrenos algo en lo que se equivocaron y qué cambiaron.Todo proyecto real tiene una. Una respuesta concreta, técnica y ligeramente incómoda indica que reflexionan sobre su trabajo. Una respuesta pulida sobre «la comunicación» indica que se han preparado para esta pregunta y nada más.
5. ¿Qué pasa con el código y las cuentas si nos separamos?La respuesta debería ser estructural: el repositorio es suyo, el despliegue está documentado, la pila es convencional, sus cuentas de nube y de tiendas están a su nombre. Si algo de eso lo tiene el proveedor, está comprando una dependencia y no software.
6. ¿Cómo sabremos que va mal, y cuándo?Los buenos proveedores tienen un mecanismo: software funcionando a un ritmo fijo, una demostración a la que usted asiste, un gráfico de avance que puede leer. Si la primera visibilidad real llega con la entrega, el riesgo es enteramente suyo y se enterará demasiado tarde.

Señales de alarma que justifican retirarse

• Un presupuesto que llega sin una sola pregunta sobre sus datos. El coste vive en el modelo de datos; una cifra producida sin preguntar por él se produjo sin pensar en él.
• Estar de acuerdo con todo. Un proveedor que nunca discrepa o no está escuchando o piensa facturar el retrabajo.
• Ninguna mención a migración, pruebas o funcionamiento en paralelo. Ese trabajo existe se presupueste o no, y si falta en el presupuesto llegará después como una modificación.
• Una demostración en la que no se puede hacer clic. Si la única prueba son capturas y un vídeo, pida acceso a algo real. Si no se lo ofrecen, hay una razón.
• Presión para firmar antes del análisis inicial. En esa fase es donde ambas partes descubren si el proyecto es lo que creen que es. Saltársela no beneficia a nadie salvo a un proveedor que sospecha la respuesta.
• Reticencia a nombrar a las personas que harán el trabajo, o a dejar que hable con ellas.

Cuándo un estudio es la elección equivocada

Somos un estudio pequeño. Eso encaja con proyectos en los que el valor está en entender bien el dominio, en los que quiere que quienes lo diseñaron lo construyan, y en los que el acceso directo a los ingenieros importa más que el peso del proceso. Es la forma equivocada para varias situaciones, y decirlo sale más barato para todos que descubrirlo en el mes cuatro.

Si necesita cien personas sobre el terreno para un programa de dos años, necesita un integrador de sistemas, y lo que hace bueno a un estudio pequeño es irrelevante a esa escala.

Si el trabajo es una tarea corta, bien definida y autónoma —un tema de WordPress, un sitio de una página, un script pequeño—, un autónomo competente lo hará más rápido y más barato, y no debería pagar los gastos generales de un estudio por ello.

Si su organización exige un servicio de soporte identificado 24/7 con tiempos de respuesta contractuales y una vía formal de escalado, pregunte directamente qué se ofrece de verdad en lugar de aceptar una promesa tranquilizadora. Es un requisito real y los equipos pequeños a menudo no pueden cumplirlo con honestidad.

Comprobar bien las referencias

Las llamadas a referencias suelen desperdiciarse, porque las preguntas invitan a una respuesta positiva. «¿Quedó satisfecho?» recibe un «sí» de casi todos, incluidos quienes no volverían a comprar.

Pregunte en su lugar: cuál fue el mayor desacuerdo y cómo se resolvió; cuánto costó el proyecto frente a la primera estimación, y por qué; qué tuvo que hacer que no esperaba; y si volvería a contar con ellos para algo más grande. Esa última pregunta es aquella en la que la vacilación es la información.

Pida una referencia de su sector si el proveedor afirma tener experiencia sectorial, y pregunte a un cliente cuyo proyecto terminase hace al menos un año. Los clientes recientes siguen en la euforia. Un año después saben si el software sigue funcionando y si los cambios siguen siendo posibles.

Lo que más predice el éxito

No el proveedor. Sino si en su lado hay una persona con autoridad para decidir y tiempo para implicarse. Los proyectos con un responsable real salen bien con proveedores mediocres; los que no lo tienen fracasan con proveedores excelentes, porque cada decisión se convierte en un comité y cada ambigüedad en un retraso.

Si no puede nombrar a esa persona y proteger su tiempo, resuelva eso antes de seleccionar a nadie. Cambiará el resultado más que cualquier otra elección de esta lista.