Casi todos los equipos de software lucen bien en una primera reunión. Las diapositivas están pulidas, los ejemplos impresionan y todos son amables. Lo que todavía no puedes ver es cómo se hace realmente el trabajo, y ahí es donde los proyectos salen bien o mal.
Estas ocho preguntas están pensadas para una llamada inicial. Para cada una, te decimos cómo suena una buena respuesta y qué debería hacerte dudar. Anota las respuestas y compáralas entre los equipos con los que hables.
#Quién hace el trabajo y con quién hablas
1. ¿Quién va a escribir realmente el software y dónde está?
Una buena respuesta nombra a las personas o los roles, dice si son empleados o contratistas y dice dónde trabajan y en qué husos horarios. Que sea remoto está bien, y también una mezcla de ubicaciones. Lo que importa es que sepas quiénes son y cuándo puedes localizarlos.
Una respuesta que preocupa es vaga (“nuestro equipo global”) o revela que quien vende el proyecto no será quien lo construya, y nadie te dice quién es.
2. ¿Con quién hablaré en el día a día?
Una buena respuesta es una sola persona, con nombre, que conoce tu proyecto y puede responder preguntas técnicas sin consultarlo con alguien más. Pregunta si esa persona seguirá en el proyecto dentro de tres meses.
Ten cuidado si cada pregunta pasa por un ejecutivo de cuenta que retransmite mensajes. Eso retrasa las decisiones y esconde los problemas hasta que ya son caros.
#Cómo se acuerdan el alcance y el precio
3. ¿Cómo se acuerdan por escrito el alcance y el precio?
Una buena respuesta describe un alcance por escrito: qué incluye, qué no, qué vas a recibir y cuánto cuesta. Pide ver un ejemplo de documento de alcance sin los datos del cliente. Debes poder leerlo y entender qué estás comprando.
Preocúpate si el precio sale de una conversación y una sola cifra, o si el alcance es “se definirá sobre la marcha”. Nuestra guía para definir el alcance de un desarrollo a medida enumera lo que debe cubrir un alcance por escrito.
4. ¿Cómo se manejan los cambios una vez iniciado el trabajo?
Habrá cambios. A mitad de camino vas a aprender cosas que no podías saber al principio. Una buena respuesta explica el proceso: describes el cambio, el equipo te dice qué afecta (costo, orden del trabajo, lo que se pospone) y tú lo apruebas antes de que empiece.
Una respuesta que preocupa es “somos flexibles, no te preocupes”. La flexibilidad sin proceso suele terminar en una discusión por la factura. Igualmente, “cualquier cambio requiere un contrato nuevo” sin término medio es señal de rigidez.
#Qué ves y qué viene después
5. ¿Qué voy a ver antes del lanzamiento?
Una buena respuesta es que usarás software funcionando mientras se construye, no solo una demo al final. Pregunta con qué frecuencia y en qué forma: un enlace en el que puedas hacer clic, un entorno de pruebas, un recorrido grabado. Pregunta qué se espera que revises y qué tan rápido se necesita tu respuesta.
Ten cuidado si la primera vez que ves algo real es el día del lanzamiento. Para entonces, un malentendido de la primera semana ya está metido en todo.
6. ¿Qué pasa después del lanzamiento?
El software necesita atención después de salir en vivo: aparecen errores, se actualizan dependencias y tu negocio cambia. Una buena respuesta dice quién monitorea el sistema, cómo reportas un problema, qué tan rápido responde alguien y qué cubre un acuerdo de soporte y qué se factura aparte. También debe decir qué documentación y capacitación recibes en la entrega.
Preocúpate si el soporte es “ya veremos cómo” o si la respuesta solo habla de la construcción.
#Datos y accesos
7. ¿Cómo manejan mis datos y el acceso a mis cuentas?
Una buena respuesta es específica. Las cuentas de hosting, dominios y servicios de terceros se registran a nombre de tu negocio, con el equipo agregado como usuarios. El acceso se limita a lo que el trabajo necesita, las contraseñas pasan por un gestor de contraseñas y no por correo, y el acceso se retira cuando termina el trabajo. Pregunta dónde se almacenarán tus datos y quién puede verlos.
Preocúpate si el equipo quiere configurar todo en sus propias cuentas “para facilitar las cosas”, o no puede explicar cómo maneja tus datos.
#Pedir una referencia
8. ¿Puedo hablar con un cliente anterior?
Una buena respuesta es sí, con un nombre y una presentación. Parte del trabajo está bajo confidencialidad, así que un equipo puede ofrecerte una conversación en lugar de un caso de estudio publicado. Pregúntale al cliente qué salió mal y cómo lo manejó el equipo, porque todo proyecto tiene un mal momento.
Si un equipo no puede ponerte en contacto con nadie, o solo ofrece testimonios que escribió él mismo, tómalo como información.
#Cómo usar las respuestas
Pon las respuestas lado a lado. Las respuestas claras, específicas y un poco aburridas valen más que las pulidas. El equipo que dice “así funciona exactamente una solicitud de cambio” suele ser más seguro que el que promete que nada saldrá mal.
Si quieres saber cómo responderíamos nosotros, agenda una llamada de 30 minutos. Es con un ingeniero, en español o en inglés, y puedes traer esta lista.
