Piloto de una aplicación para equipos de campo: qué probar

Lanzar una app a todo tu equipo de golpe cuesta plata, reclamos y control. Un piloto de una aplicación para equipos de campo destapa las fallas antes.

Cuando un despliegue falla con todos a la vez, lo paga el dueño. El equipo vuelve a WhatsApp, el cliente sigue esperando el informe y la inversión queda como "la app que no funcionó". Un piloto pequeño y bien armado te deja ver esos problemas con 10 personas y no con toda la empresa molesta.

¿Qué es un piloto de una app de campo y en qué se diferencia de una demo?

Una demo ocurre en una sala con buen wifi, un teléfono nuevo y alguien que ya sabe dónde tocar. Un piloto ocurre en el patio del puerto a las seis de la mañana, en la finca donde el celular marca una sola raya, en la bodega con techo de zinc y en la carretera entre dos antenas.

Lo que te va a fallar con toda la empresa aparece primero con 10 personas, siempre que elijas bien a esas 10.

Un piloto bien armado tiene cuatro piezas: trabajo real, poco tiempo, un ambiente de prueba desechable y criterios de decisión escritos antes de empezar. Si falta alguna, lo que tienes es una demo larga.

Antes de arrancar, revisa tres cosas:

1. Que el proceso esté definido. No se prueba una app sobre un proceso que nadie ha acordado. Si cada supervisor llena "su" Excel, primero estandariza el proceso de tu equipo de campo. La transformación digital no es comprar software: es estandarizar el proceso y hacerlo auditable.
2. Que el ambiente sea barato y desechable. Debe estar separado del sistema final, funcionar con datos reales y poder borrarse sin pena. En un producto propio, el primer piloto lo hizo el propio fundador con sus vehículos, en un ambiente de prueba barato que se pausó cuando el proyecto se detuvo. Parar costó poco. Desplegar sin probar habría costado mucho más.
3. Que probar cueste una fracción del despliegue. Si trabajas con tarifa de arranque más mensualidad, pregunta qué incluye el arranque y si el ambiente de prueba forma parte de él. Nosotros construimos el software alrededor de tu proceso, lo dejamos listo en semanas y lo hacemos crecer con lo que enseña el campo. Revisa cómo trabajamos y cómo funciona el arranque más mensualidad.

Como referencia, dos a tres semanas suelen alcanzar:

1. Semana 1, uso acompañado. El grupo usa la app en trabajos reales y tiene a alguien disponible para resolver dudas. El registro doble (app y método anterior) se permite solo esta semana.
2. Semana 2, la app es el único canal. Para ese proceso, el papel y las fotos por WhatsApp dejan de aceptarse. Aquí aparece la resistencia real.
3. Semana 3, calibrar y decidir. Ajustas las reglas con los datos acumulados y aplicas el criterio escrito: desplegar, ajustar o parar.

¿A quiénes incluyes entre los 10?

Las guías genéricas recomiendan empezar con los más hábiles con la tecnología. En campo, eso te da un piloto que sale bonito y un despliegue que se cae a las pocas semanas.

Usa este checklist para elegir a los participantes:

1. Los dos o tres teléfonos más viejos de la empresa: poca memoria, Android atrasado, batería cansada.
2. Al menos un teléfono nuevo, para saber si la falla es del aparato o de la app.
3. Las rutas o sitios con peor señal: puerto, finca adentro, bodega cerrada, el tramo de carretera que todos conocen.
4. La persona más escéptica, la que dice "esto no va a funcionar".
5. Un líder de opinión, alguien a quien el resto escucha.
6. La coordinadora o la persona de backoffice que recibe la información y arma el informe.
7. Un supervisor que revise los registros todos los días.

No hay un número mágico. En uno de nuestros pilotos bastó un solo camión; en otro fueron unas 10 personas. Importa menos el número que tener el peor caso dentro del grupo.

Una prueba que puedes hacer: a la persona escéptica dale la capacitación más corta del grupo. Si así completa un trabajo real, el despliegue va a ser manejable.

¿Qué pruebas con teléfonos, señal y evidencia antes de desplegar?

Estas son las pruebas que más problemas han destapado en nuestros pilotos:

1. Arranque sin red. Apaga los datos, bloquea la pantalla y abre la app. En una app de voz para conductores, el viaje de regreso no arrancó solo. El teléfono estaba bloqueado y sin datos, y la app intentaba validar la sesión por internet. Además, Android congela los temporizadores con la pantalla bloqueada. La regla que quedó: lo que la app hace al arrancar no puede depender de la red.
2. Evidencia sin señal. En una zona sin cobertura, registra un sello y toma la foto. Cierra la app a la fuerza, reinicia el teléfono y vuelve a una zona con señal. Comprueba que la foto llegó, que lleva la hora en que se tomó y no la hora en que sincronizó, y que quedó ligada al punto correcto del checklist. Más detalle en qué separa una foto de una prueba.
3. Ubicación. En una app de marcación de asistencia con GPS (sistema de posicionamiento global), una persona marcó su salida desde un taxi a varios kilómetros de la oficina y el sistema la aceptó. El teléfono no consiguió GPS real y usó una ubicación aproximada con un margen de 92 metros, y el punto central caía dentro del radio permitido de 50. La solución fue rechazar toda lectura con margen mayor a 50 metros y pedir un reintento. El costo, aceptado a conciencia, es que cerca del 1% de las marcaciones legítimas piden un segundo intento.
4. Datos y batería. En el piloto de conductores, el teléfono midió un consumo de datos 40 veces mayor al que había calculado un documento técnico: 2,9 MB (megabytes) por hora de viaje. Sin chip de datos, la información llegaba entre 12 y 48 minutos tarde; con chip, en unos 5 segundos. El plan de datos se dimensiona con lo medido, no con lo calculado. Y como la app iba fija a pantalla completa, el conductor dejó de ver la batería, así que se agregó un aviso hablado al 20% y al 10%.
5. Tiempo por tarea. Cronometra el mismo trabajo con la app y con el método anterior. Si la app agrega minutos en campo, tiene que ahorrar bastante más en oficina, y el equipo tiene que entender por qué.

Prueba siempre con datos reales. Una lectura automática de recibos que funcionaba con imágenes de ejemplo no es lo mismo que un recibo térmico fotografiado en una gasolinera ecuatoriana.

¿Cómo mides lo que el equipo hace y decides si despliegas, ajustas o paras?

Un piloto se mide por lo que el equipo hace, no por lo que dice. Si en la encuesta todos dicen que les gusta, pero las fotos siguen llegando al grupo de operación, el piloto no ha terminado. WhatsApp no es un sistema de control, y cuánto se sigue usando es tu mejor indicador de adopción.

Qué medir y qué señal de alerta buscar:

1. Registros frente a trabajos hechos. Cruza la app con la agenda o las órdenes del día. La alerta son trabajos realizados que no existen en el sistema.
2. Sincronización. Revisa los pendientes por teléfono. La alerta es una cola que no baja al volver a zona con señal.
3. Actividad por persona. Revisa los registros por usuario y por día. En un equipo, dos de cuatro usuarios dejaron de usar el sistema y nadie lo notó en semanas: entre los dos sumaban 3 registros en dos meses.
4. WhatsApp. Revisa el grupo de operación. La alerta son fotos o confirmaciones que deberían estar en la app.

Mira los registros del sistema antes que las opiniones. En el piloto de conductores, la función central nunca se ejecutó, aunque cada pieza pasaba sus pruebas: había 35 hechos marcados para preguntar al conductor y ninguna pregunta hecha. Tampoco confundas instalado con desplegado. Una empresa tenía su sistema comercial en tres ciudades, y en una de ellas, de 431 empresas asignadas, solo 3 tenían alguna gestión registrada.

Pide al grupo una bitácora diaria de fallas. Cada registro lleva fecha, persona, modelo de teléfono, lugar y estado de la señal, qué intentaba hacer, qué pasó y si volvió al papel o a WhatsApp. Antes de teorizar sobre una falla, lee también el registro del teléfono. El mensaje de error puede engañarte.

Escribe los criterios de decisión antes del piloto, con umbrales que defina tu empresa:

1. Desplegar si los trabajos del grupo están completos en la app, la sincronización se pone al día sola y WhatsApp dejó de recibir evidencia de ese proceso.
2. Ajustar si las fallas se concentran en un teléfono, una zona o una regla con arreglo barato. Una regla que bloqueaba coordenadas idénticas de un día a otro castigó a gente honesta en una oficina interior. A las dos semanas pasó de bloqueo a alerta para el supervisor. Las reglas de control se calibran con los datos del piloto, no en la reunión.
3. Parar si la función central no cumple el umbral. En un producto de control de combustible se fijó parar si la lectura automática acertaba menos del 70% con recibos térmicos reales, o si después de los arreglos baratos seguía habiendo más de 1 vehículo marcado en rojo por cada 10 honestos.

¿Hasta dónde llega un piloto y qué no resuelve?

Si tienes tres personas en campo y pocos trabajos a la semana, un formato en papel bien diseñado, con fotos ordenadas por número de orden, puede alcanzarte por un tiempo. Una plataforma conviene cuando te piden evidencia y tardas días en encontrarla, cuando la coordinadora se vuelve cuello de botella armando informes o cuando crecer significa contratar gente solo para perseguir información. Si no puedes encontrar evidencia rápido, no tienes control: tienes esperanza. Ese punto de quiebre lo ves en nuestros casos y en por qué las pymes están dejando el Excel.

Un piloto con 10 personas tampoco lo prueba todo. No demuestra cómo responde el sistema con toda la empresa ni valida integraciones que no se tocaron. Te da criterios, no estadísticas.

Y ningún software resuelve la adopción por ti. Si el dueño sigue aceptando fotos por WhatsApp "solo por esta vez", el equipo aprende que la app es opcional. El piloto funciona cuando la gerencia sostiene la regla de la semana 2.

Si quieres armar tu piloto con nosotros, agenda una llamada de 30 minutos, sin compromiso. Revisamos juntos el proceso de campo que quieres digitalizar, quiénes serían tus 10 participantes (incluidos los teléfonos más viejos y los lugares con peor señal), qué medir en las primeras dos semanas y qué resultado te haría desplegar, ajustar o parar. Sales con una lista de participantes, una tabla de pruebas y criterios de decisión escritos para tu operación.