8 errores costosos en el desarrollo de apps que las pymes siguen cometiendo

Esta es la verdad incómoda sobre los proyectos de apps que se tuercen: para cuando el código parece estar mal, el proyecto ya estaba perdido desde hacía semanas. Los errores caros en el desarrollo de apps de pequeñas empresas casi nunca ocurren ante el teclado. Ocurren en conversaciones informales: el briefing que nunca se puso por escrito, la función que alguien añadió 'ya que estamos', el desarrollador elegido porque lo recomendó un amigo. En el momento, nada de eso parece una decisión. Todo eso le cuesta después.

He visto a muchas pequeñas empresas encargar su primera app, y me han llamado para rescatar muchas después del hecho. Los dueños rara vez son personas descuidadas. Son perspicaces, cuidadosos, buenos dirigiendo un negocio. Pero el software tiene su propio conjunto de trampas que no existen en ninguna otra parte de su vida laboral, y nadie les advirtió. Así que caen de lleno en los mismos ocho escollos, más o menos en el mismo orden, cada vez.

Esta es la lista que desearía que cada dueño tuviera antes de gastar un solo céntimo. No es teoría: son los errores reales y repetibles, y las pequeñas correcciones de rumbo que habrían salvado cada proyecto. Si está a punto de crear una app, o ya va a mitad de camino y algo no le encaja, lea esto primero. La mayoría de estos errores aún tienen arreglo si los detecta a tiempo.

Error 1: Construir antes de haber demostrado que alguien la quiere

El error más caro es también el más común: comprometerse con un desarrollo completo antes de que haya pruebas reales de que la app resuelve un problema por el que la gente pagará o que usará. Al dueño la idea le parece obvia (por supuesto que los clientes la querrán), y esa certeza es precisamente lo peligroso. La certeza parece validación. No lo es.

Validar no significa preguntar a diez amigos si les gusta la idea; todos dicen que sí por amabilidad. Significa poner la versión más pequeña posible ante usuarios reales en una situación real y observar lo que de verdad hacen. Un prototipo en el que se pueda hacer clic, una página de aterrizaje que mida los registros, una versión manual de 'conserje' en la que falsifique la automatización a mano: cualquiera de estas le dice más que una app terminada construida sobre una corazonada. El orden importa: demuestre la demanda de forma barata y luego construya de forma cara. Inviértalo y puede gastar todo su presupuesto puliendo algo que nadie abre dos veces.

Error 2: La expansión del alcance disfrazada de ambición

Toda app empieza ligera y ordenada. Luego comienza el 'ya que estamos'. Ya que estamos construyendo la pantalla de reservas, ¿podría gestionar también vales regalo? ¿Y puntos de fidelidad? ¿Y un sistema de recomendaciones? Cada añadido suena razonable por sí solo. Juntos triplican en silencio el plazo y la factura, y posponen el lanzamiento tan lejos que el impulso original muere.

El remedio no es decir que no a las buenas ideas. Es aparcarlas. Mantenga una lista visible de 'versión dos' donde cada idea brillante espere su turno. Esto hace algo psicológico además de práctico: la gente deja de pelear por meter funciones en la primera versión en cuanto confía en que su idea tendrá un lugar real más adelante. Su primera versión debe hacer una cosa genuinamente bien, no diez cosas de forma aceptable. Una app que clava un único flujo de trabajo se usa. Una app que hace todo a medias se abandona.

Error 3: Sin briefing por escrito, solo una imagen mental compartida

Este error es invisible hasta que muerde. El dueño tiene una app clara en la cabeza. El desarrollador tiene una app clara en la cabeza. Todos asienten en la reunión de arranque. Nadie lo pone por escrito como es debido, y las dos imágenes, resulta, nunca fueron la misma imagen. Lo descubre a mitad de camino, cuando lo que se está construyendo no es lo que imaginaba, y ahora hay una discusión sobre quién dijo qué.

No necesita una especificación de cien páginas. Necesita unas pocas páginas que cualquier recién llegado pueda leer y entender: quién usa esta app, cuáles son las tres o cuatro cosas que necesitan hacer con ella, cómo es un resultado exitoso. Añada un boceto aproximado de las pantallas clave. Eso es todo. El propósito del briefing no es la burocracia: es una referencia compartida a la que ambos pueden señalar cuando la memoria y la realidad empiezan a separarse, cosa que siempre hacen.

Error 4: Elegir al desarrollador de la forma equivocada

La mayoría de los dueños eligen a su primer desarrollador por una de dos señales endebles: el presupuesto más bajo o una recomendación personal de alguien de otro sector. Ambas pueden funcionar por suerte. Ninguna es una forma fiable de elegir a quien confiará una parte considerable de su dinero y varios meses del futuro de su negocio.

El presupuesto más bajo es especialmente traicionero en el software, porque la brecha entre un presupuesto y el coste final es enorme e invisible. Un desarrollador barato que necesita tres rondas de retoques, desaparece dos semanas y le deja un código que nadie más puede mantener resulta mucho más caro que uno algo más costoso que lo hace bien. El precio es lo que ve; el coste total es lo que paga.

Qué comprobar de verdad

Pida ver cosas que hayan lanzado y que sigan funcionando y, si puede, hable con esos clientes sin el desarrollador en la sala. Pregunte cómo gestionan los cambios a mitad de proyecto, porque habrá cambios. Pregunte de quién son el código y las cuentas cuando esté terminado: la respuesta siempre debería ser suyos. Y fíjese en si le hacen buenas preguntas a su vez. Un desarrollador que solo recibe órdenes construirá exactamente lo equivocado con mucha eficiencia. Los buenos le rebaten, señalan vacíos en su razonamiento y tratan el briefing como punto de partida de una conversación, no como una lista de la compra cerrada.

Error 5: Presupuestar el desarrollo y olvidar el resto

Una app no es una compra única como un folleto impreso. Es algo vivo que necesita alimentarse. Los dueños presupuestan habitualmente el desarrollo y nada más, y luego les pillan por sorpresa los costes que llegan después: el alojamiento, las tarifas de las tiendas de apps, el mantenimiento para seguir el ritmo de las actualizaciones del sistema operativo del móvil, y la inevitable ronda de arreglos y pequeñas mejoras una vez que la gente real empieza a usarla.

Una regla práctica sensata: cueste lo que cueste el desarrollo, reserve de nuevo una parte considerable de eso para el primer año de funcionamiento. La cifra exacta varía, pero el error es universal: tratar el día del lanzamiento como la línea de meta cuando en realidad es la línea de salida. La app que se lanza y luego se abandona en silencio porque no hay presupuesto para mantenerla es uno de los desenlaces más tristes y comunes de todo este campo, y se puede evitar por completo con una planificación honesta de antemano.

Error 6: Diseñar para usted en lugar de para su usuario

Conoce su negocio al dedillo, lo que le convierte en el peor juez posible de si su app es fácil de usar. Las cosas que para usted son obvias (la jerga, el orden en que hace las tareas, los atajos que toma sin pensar) desconciertan a un usuario primerizo. Una app que tiene todo el sentido para el dueño y confunde a todos los demás ha fracasado, por muy ingeniosa que sea.

La cura es barata y un poco humillante: observe a personas reales usarla antes de lanzar. No a su equipo, que ya sabe cómo se supone que funciona, sino a clientes o empleados reales que nunca la han visto. Entrégueles la app, deles una tarea y no diga nada. Donde duden, toquen lo que no es o suspiren, ahí está su retroalimentación de diseño. Cinco personas bastan para sacar a la luz los peores problemas. Saltarse este paso es como las apps acaban lanzándose con un botón de 'enviar' que nadie encuentra y un flujo de registro que pierde a la mitad de quienes lo intentan.

• Dele a quien prueba una tarea real, no un recorrido guiado: 'reserva una cita para el próximo martes', y luego guarde silencio.
• Observe sus manos y su cara, no solo si al final lo consigue.
• Anote cada duda; una pausa es un problema de diseño que no puede ver desde dentro.
• Resista el impulso de explicar: si tiene que explicarlo, la app debería haberlo hecho.
• Pruebe con cinco personas, corrija los fallos evidentes y luego vuelva a probar.

Error 7: Crear apps nativas de iOS y Android cuando no hacía falta

Existe el reflejo de crear una app 'de verdad' para iPhone y Android desde el primer día, totalmente nativa, como hacen las grandes marcas. Para la mayoría de las pequeñas empresas, eso supone de dos a tres veces el coste y la complejidad a cambio de un beneficio que sus usuarios nunca notarán. Peor aún, ahora mantiene dos bases de código separadas para siempre, duplicando cada arreglo futuro.

A menudo, el primer paso correcto no es una app nativa en absoluto. Una app web bien construida que funcione en el navegador de cualquier móvil, o un enfoque multiplataforma que produzca ambas versiones para las tiendas a partir de una sola base de código, le lleva al mercado más rápido y más barato, y siempre puede pasar a algo totalmente nativo más adelante si el uso real demuestra que vale la pena. La pregunta nunca es 'nativa o web' en abstracto. Es: ¿cuál es la cosa más pequeña y barata que permite a usuarios reales hacer el trabajo esencial? Construya eso, aprenda de ello y luego gaste el dinero grande con pruebas en lugar de con suposiciones.

Error 8: Tratar el lanzamiento como el final del trabajo

El octavo error es creer que el proyecto está terminado cuando la app sale a producción. No lo está: ahí es cuando empieza el proyecto de verdad. Una app sin plan para llegar a manos de los usuarios, sin manera de escuchar lo que piensan y sin intención de mejorarla a partir de lo que aprende es una app que se desvanece en pocos meses. El desarrollo era la parte fácil. La adopción es la parte difícil, y casi nadie la planifica.

Antes de lanzar, conozca tres cosas: cómo se enterará la gente de que la app existe, cómo medirá si de verdad la están usando y cómo recogerá lo que le cuenten para que la siguiente ronda de trabajo se guíe por la realidad en lugar de por conjeturas. Nada de esto es caro. Es simplemente una mentalidad distinta: la app no es algo que termina y abandona, es una relación que mantiene. Los dueños que lo entienden consiguen apps que se vuelven más útiles con el tiempo. Los que no, consiguen un pico el día del lanzamiento y un declive largo y silencioso.

Cómo mantenerse al margen de los ocho a la vez

Leídos en conjunto, estos errores comparten una única raíz: avanzar rápido sobre suposiciones en lugar de despacio sobre pruebas. Cada uno de ellos es un punto en el que pareció más barato saltarse el paso cuidadoso. Y cada uno de ellos es mucho más barato de gestionar antes del desarrollo que después. Esta es la secuencia que esquiva en silencio los ocho.

1. 1
   Demuestre la demanda antes de construir

   Un prototipo, una página de aterrizaje o una versión manual. Consiga pruebas reales de que alguien la quiere antes de comprometer el presupuesto.
2. 2
   Escriba el briefing y la lista de versión dos

   Unas pocas páginas claras que cualquiera entienda, más un aparcamiento para cada idea de 'ya que estamos' para que no descarrile la v1.
3. 3
   Elija al desarrollador por su trayectoria, no por el precio

   Trabajo lanzado, llamadas a referencias, propiedad clara del código y las cuentas, y alguien que haga buenas preguntas a su vez.
4. 4
   Presupueste todo el primer año, no solo el desarrollo

   Alojamiento, mantenimiento, arreglos y soporte. El día del lanzamiento es la línea de salida, así que financie el funcionamiento de la cosa.
5. 5
   Elija la plataforma más pequeña que haga el trabajo

   Web o multiplataforma primero en la mayoría de los casos. Pase a algo totalmente nativo más adelante, con pruebas, solo si el uso lo exige.
6. 6
   Pruebe con usuarios reales y luego planifique el lanzamiento

   Observe a cinco desconocidos usarla, corrija los fallos evidentes y decida de antemano cómo la encontrará la gente y cómo medirá el uso.

Preguntas frecuentes