Puedes empezar por enseñar cómo utilizas esa hoja cuando llega un encargo, explicando qué buscas en la aplicación y para qué necesitas compararlo con la información que guardas aparte, de manera que quien estudie las alternativas comprenda la tarea antes de proponerte un ajuste o un desarrollo.
También merece atención cuánto se parece ese trabajo a otros que ya tienen soluciones disponibles y qué parte responde a una condición particular de tu actividad, porque quizá una aplicación cubra bien lo habitual y baste con resolver una conexión, mientras en otro caso haya una forma de trabajar que requiera estudiar algo más específico.
El coste de una solución continúa después de su primera entrega, porque alguien tendrá que mantenerla, atender incidencias y adaptarla cuando cambien las herramientas o las necesidades del negocio, por lo que al pedir una propuesta conviene conocer quién asumiría ese trabajo y cómo quedarían documentados los accesos y las decisiones necesarias para sostenerlo.
Antes de comprometer un desarrollo completo podéis preparar una representación sencilla con casos ficticios para que quienes vayan a utilizarla recorran una tarea y expliquen dónde encuentran dudas, mientras aún resulta fácil modificar la propuesta a partir de lo que descubráis juntos.
La propuesta técnica tendrá que concretar las condiciones de seguridad, la recuperación de la información y la posibilidad de cambiar de proveedor en el futuro, porque junto al presupuesto y los plazos, esos acuerdos ayudan a valorar qué dependencia asumiría la empresa y qué recursos necesitaría para hacerse cargo de la solución.
Al comparar una aplicación existente con un desarrollo propio, incluid el trabajo que necesitará el equipo para aprender a utilizar cada alternativa y elegid una primera tarea con la que podáis comprobar el resultado, antes de ampliar el proyecto a otras funciones.
La hoja puede serviros para recordar por qué habéis acabado trabajando de esa manera y preguntar qué sigue siendo necesario, porque tal vez conservéis una columna que respondía a una condición antigua o a un dato que ahora recibís por otra vía, algo que quienes la utilizan podrán aclarar al recorrerla con vosotros.
Al conversar con un equipo de desarrollo, podéis pedirle que os muestre cómo haríais una tarea con los datos ficticios que habéis preparado, para que las personas que se ocuparán de ella puedan probar el recorrido y explicar qué necesitan aclarar o qué echarían en falta al encontrarse con otros casos, dejando esas cuestiones recogidas en el encargo antes de decidir qué funciones vais a desarrollar.
Pensad también quién podrá mantener el contacto con el proveedor y reservar tiempo para reunir las dudas del equipo, de manera que las decisiones que surjan durante el proyecto lleguen a las personas que deban tomarlas y quienes vayan a utilizar la solución puedan explicar cómo afectaría cada cambio a su trabajo.
Al revisar una propuesta, pedid que os expliquen cómo recibiríais la primera entrega y qué oportunidad tendríais de probarla con el equipo, para conocer cuándo podréis plantear una duda y cómo se valorará si pertenece al alcance acordado o requiere estudiar una ampliación.
También merece preguntar qué información y apoyo recibiríais si más adelante otra persona tuviera que mantener la solución, para valorar esa continuidad antes de elegir y dejar recogidas las condiciones de acceso y documentación que correspondan.
Explica la necesidad antes de elegir la solución
Describe una tarea que hoy resolvéis con dificultad y prepara un ejemplo ficticio del resultado que necesitáis, para utilizarlo al comparar propuestas y preguntar cómo se pondría en marcha cada alternativa, quién atendería los cambios y cómo conservaríais vuestra información.