Prueba antes de desarrollar.
Antes de financiar la creación de un software más grande, pruebe la idea a pequeña escala. Una empresa establecida puede realizar esa prueba con los clientes y el personal que ya tiene. La primera pregunta no es qué funciones crear: es lo que más necesita aprender y la forma más barata y honesta de aprenderlo.
Pruebe un nuevo servicio o flujo de trabajo a pequeña escala antes de financiar una creación de software más grande. Una empresa establecida tiene una ventaja aquí: puede realizar pruebas con clientes o personal existente, que ya confían en ti lo suficiente como para intentar algo difícil.
El objetivo de un piloto es aprender, no enviar. Comience con la pregunta: ¿los clientes utilizarán esto? ¿Podemos entregárselo? ¿La información cambia una decisión? – y elija la prueba más barata que responda honestamente.
La prueba útil no es si puedes desarrollarlo completo. Se trata de si un ensayo pequeño y real proporciona suficiente evidencia para expandirse, cambiar de dirección o detenerse.
Cinco ideas, cinco pequeñas pruebas.
Estos son experimentos ilustrativos, no evidencia de que las ideas tendrán éxito.
En cada caso, la prueba es manual y limitada: suficiente para producir evidencia real, y lo suficientemente barata como para abandonarla.
Aprende a mano antes que tú. automatizar.
Para un distribuidor que evalúa un portal de pedidos, la progresión puede ser deliberadamente de baja tecnología.
El procesamiento manual de pedidos revela las excepciones (los precios impares, la entrega especial, la solicitud a medio terminar) antes de que se conviertan en costosos requisitos de software. Una regla de honestidad: tenga claro lo que realmente ofrece el piloto. No presente un servicio que esté confirmando manualmente como automatización instantánea.
Relaciona la evidencia con la decisión.
La mayoría de los proyectos de software fracasan debido a uno de tres riesgos: viabilidad técnica ¿Puedes desarrollarlo y alcanzar los datos y las integraciones que necesita? demanda del cliente — ¿Importa el problema lo suficiente como para que la gente realmente lo utilice? y viabilidad empresarial ¿Pagarán lo suficiente para cubrir el costo de entrega? Nombra el riesgo al que está más expuesta tu idea y pruébalo primero.
Diferentes preguntas necesitan diferentes pruebas. Busque el más ligero que responda al suyo:
- Entrevistas revelar el problema real y las soluciones que la gente utiliza hoy en día.
- Una página de destino prueba si existe algún interés inicial.
- Un vídeo conceptual muestra la idea en acción y prueba si la promesa por sí sola genera interés, antes de desarrollar algo.
- Un prototipo interactivo prueba si las personas entienden el flujo y pueden utilizarlo.
- Una prueba técnica prueba si un sistema existente realmente puede compartir los datos que necesita, antes de diseñar un flujo de trabajo en torno a él.
- Un piloto en vivo prueba el uso real, el esfuerzo de entrega y si se ajusta a su forma de operar.
- Pago y uso repetido son la evidencia más fuerte de que el valor continúa más allá de la novedad.
Nada de esto es nuevo o exótico. Dropbox probó la demanda con un video de demostración antes de desarrollar el producto, Airbnb comenzó alquilando el propio apartamento de los fundadores y Zappos dirigió un servicio de conserjería (cumpliendo sus primeros pedidos comprando zapatos a mano en tiendas locales) para ver si la gente realmente pagaría, no solo se registraría. Cada uno respondió una pregunta arriesgada de forma económica antes de que alguien se comprometiera con el desarrollo completo.
Antes de comenzar, establece un alcance limitado, un presupuesto, un punto de revisión y criterios de éxito. Para los servicios de cara al cliente, mida la finalización, el uso repetido, el esfuerzo de soporte y la disposición a pagar; para una herramienta interna, un menor esfuerzo y menos errores son más importantes que el entusiasmo: compare el tiempo, los errores y la adopción con el proceso actual.
Protéjase de la evidencia halagadora. Incluya a personas más allá de tus clientes más entusiastas y analice por qué otros rechazan o abandonan la prueba; ahí es donde suele esconderse la verdadera objeción. Un porcentaje de registro genérico no es una marca de aprobación universal; juzgue el resultado frente a la decisión que realmente tiene delante.
Financiar el aprendizaje, no todo el desarrollo.
Haz coincidir la financiación con lo que está probando. Un proyecto de eficiencia interna necesita un caso operativo: cuánto cuesta, qué mejora y cuándo aparece el beneficio. Un nuevo producto orientado al cliente necesita eso, además de evidencia de que los clientes realmente pagarán. Para convertir tu propio proceso en un producto para vender a otras empresas se necesita más: evidencia de que el problema y la voluntad de adoptar una solución existen más allá de la empresa que lo pensó. La inversión externa plantea una cuestión aparte sobre la propiedad y las expectativas de crecimiento, y una plataforma de financiación no puede establecer que vale la pena desarrollar un proyecto; no debería sustituir ninguna de estas pruebas, y una campaña exitosa aún deja que gestionar los costos de entrega y operación.
Si miramos hacia afuera, "una plataforma de financiación" significa varias cosas muy diferentes. El crowdfunding de recompensas te permite pre-vender un producto y mantener la propiedad total, pero te compromete a entregarlo. El crowdfunding de acciones atrae inversores que reciben acciones, con las reglas de divulgación, los límites de elegibilidad y la dilución que eso implica. Otras plataformas no son tanto un lugar para recaudar dinero como herramientas para encontrar, gestionar o informar a los inversores. Sus tarifas, obligaciones e implicaciones de propiedad difieren marcadamente, y el mercado cambia con frecuencia, así que compare los términos actuales directamente y recuerde que ninguno de ellos es evidencia de que la demanda sea real.
Así que financie el aprendizaje primero, en etapas:
- Establezca un límite de gasto para aprender. Incluya la configuración, el tiempo del personal, la migración, la capacitación y el soporte, no solo la herramienta.
- Gastarlo en la suposición más incierta. ¿Los clientes realizarán pedidos a través del portal? ¿El personal mantendrá actualizados los registros de producción?
- Utilice la solución viable más pequeña. Una herramienta configurada o un piloto manual a menudo proporciona evidencia suficiente antes de cualquier desarrollo personalizado.
- Liberar el próximo presupuesto contra resultados. Defina el éxito antes de que comience el piloto y compárelo con el proceso actual.
- Verifique el costo continuo. Las suscripciones, el mantenimiento, las integraciones y el trabajo que aún se realiza a mano duran más que el desarrollo y deciden si el beneficio los cubre.
Elige la prueba que responda a la incertidumbre
Una prueba de concepto comprueba si un enfoque técnico incierto puede funcionar. Un prototipo ayuda a las personas a responder a la experiencia propuesta. Un producto mínimo viable, o MVP, pone en uso real un producto limitado pero utilizable para probar su valor. Responden diferentes preguntas; cada proyecto no necesita los tres.
Para obtener una herramienta de reserva ilustrativa, primero pruebe una conexión de calendario incierta si esa conexión podría detener el proyecto. Utiliza un prototipo para comprobar si el personal comprende el flujo de aprobación. Una primera versión en vivo podría entonces manejar un tipo de reserva desde la solicitud hasta la confirmación.
“Mínimo” debería limitar el alcance, no excusar el manejo poco confiable de registros reales. Un piloto en vivo aún necesita acceso, recuperación, apoyo y una propiedad clara adecuados. Acuerda qué justificaría continuar, revisar la idea o detenerse antes de financiar la siguiente etapa. Cybercube puede definir un precio fijo para una prueba acordada o un primer lanzamiento, con la pregunta y la evidencia de aceptación explícitas.
Pequeño, pero todavía confiable.
Un programa piloto puede ser limitado, pero aun así maneja pedidos, registros y compromisos reales, así que reduzca el alcance sin recortar las piezas que los usuarios necesitan para completar la tarea o confiar en el resultado. "Aspero" debería describir los bordes, no el manejo del pedido real de alguien.
Trate la evidencia como temprana, no definitiva. Un pequeño piloto muestra lo que sucede con unos pocos usuarios; no establece cómo se comporta la solución en cada cliente, en un período de actividad o en un caso inusual. Dejemos que la expansión ponga a prueba esas incertidumbres restantes en lugar de asumir que el piloto ya las resolvió.
Para CYBERCUBE, el punto de partida útil es la pregunta que más necesita respuesta antes de comprometerse. Realice la prueba más pequeña y creíble, mida lo que le dice y utilícela para decidir si expandirse, cambiar de dirección o detenerse. Cuéntanos qué estás pensando desarrollar. Si el piloto lo demuestra, ver cómo determinar el alcance de una primera aplicación confiable; si todavía lo estás pesando, cuando el software a medida tiene sentido cubre la decisión.