Entrega un producto, no una base.
La mayoría de las primeras fases entregan andamiaje y lo llaman avance. La nuestra entrega un ciclo de producto completo de punta a punta que puedes poner frente a un usuario real.
El problema
La ingeniería de producto es lo más grande que hace un Pod: llevar un producto de una idea o un prototipo a algo corriendo en producción con usuarios reales encima. Web, móvil, o los dos, sobre el stack que el problema de verdad pida.
La parte que importa es la secuencia. Insistimos en que la fase 1 sea un ciclo completo, es decir que un usuario pueda entrar, hacer la cosa central por la que el producto existe, y obtener un resultado. No una pantalla de login, un sistema de diseño y una promesa.
Esa restricción es impopular en las reuniones de planeación, y es la razón más grande por la que aquí los proyectos no se mueren en silencio en el mes cuatro. Un ciclo se puede probar, demostrar y financiar. El andamiaje solo se puede describir.
- La fase 1 es un producto usable de punta a punta, nunca un esqueleto
- Móvil nativo y multiplataforma, decidido por el requisito y no por la preferencia
- Aplicaciones web, APIs, y la infraestructura para correrlas
- Estimado en story points y cotizado antes de empezar
Qué cubre esto
Productos móviles
iOS y Android nativos donde la experiencia lo exige, multiplataforma donde no.
Aplicaciones web
Sistemas de larga vida con usuarios reales, datos reales y expectativas reales de disponibilidad.
MVPs que sobreviven
Una primera versión dimensionada para comprobar la cosa, no para impresionar en una diapositiva.
Desempeño bajo carga
Construido para aguantar el volumen que esperas, verificado antes del lanzamiento.
Seguro por defecto
Autenticación, autorización y protección de datos como parte de la construcción.
Analítica desde el primer día
No puedes iterar sobre un producto que no puedes medir.
Nativo o multiplataforma. El requisito decide.
Esta es la primera bifurcación real en una construcción móvil, y normalmente se resuelve por preferencia y no por evidencia. Así la resolvemos nosotros.
| Dimension | Multiplataforma | Nativo |
|---|---|---|
| Escógelo cuando | El producto son formularios, listas, contenido y navegación estándar, y necesita existir en las dos plataformas al mismo tiempo | La experiencia es el producto, o dependes de hardware y de funciones del sistema operativo que se mueven rápido |
| Costo en puntos | Un solo código base, así que aproximadamente una construcción más el pulido por plataforma | Dos códigos base para el alcance compartido, cotizado en consecuencia |
| Acceso a hardware | Suficiente para cámara, ubicación, notificaciones y biometría | Necesario para Bluetooth, NFC, terminales de pago, comportamiento en segundo plano e integración profunda con el sistema operativo |
| Libertad de diseño | Buena, hasta que quieres trabajo de movimiento y gestos que pelea con el framework | Total |
| Dónde falla | Un equipo lo escoge por costo y después especifica un producto que se siente nativo | Un equipo paga dos veces por un producto en el que nadie habría notado la diferencia |
| Nuestro valor por defecto | Donde el requisito de verdad lo permita, porque el ahorro es real | Donde el requisito lo exija, y te lo decimos sin rodeos |
Qué mueve la estimación
No podemos cotizar un párrafo, pero sí podemos decirte exactamente qué mueve el número, porque un story point se dimensiona por superficie funcional, cantidad de integraciones, y la cobertura de pruebas necesaria para entregarlo con confianza.
Así que las cosas que hacen caro un producto rara vez son las que los clientes esperan. La cantidad de pantallas importa mucho menos que la cantidad de estados distintos que tiene cada pantalla. Un sistema de terceros más contra el cual reconciliar cuesta más que varias vistas de lista más. Y un modelo de roles con cuatro niveles de permiso es un producto distinto de las mismas funcionalidades con uno.
Preferimos mostrarte estas palancas durante el dimensionamiento que descubrirlas en el mes tres. También es la razón por la que la fase 1 se dimensiona como un ciclo completo: un ciclo es la cosa más pequeña cuyo costo real podemos comprobar.
- Estados distintos por superficie, no cantidad de pantallas: vacío, cargando, parcial, error, sin conexión, permiso denegado
- Cantidad de integraciones y qué tan mal se comporta cada sistema aliado cuando falla
- Roles y permisos, que multiplican la superficie de prueba más rápido que las funcionalidades
- Datos regulados dentro del alcance, que suben la barra de cobertura en vez de la cantidad de funcionalidades
- Requisitos de trabajo sin conexión o en tiempo real, que cambian la arquitectura en vez de sumarse a ella
Cómo se ve esto en tu industria
La ingeniería es la misma disciplina. Lo que cambia es cuál modo de falla es inaceptable, y eso cambia qué construimos primero.
- Servicios de Salud
Flujo clínico, manejo listo para HIPAA, y rastros de auditoría construidos sobre la marcha en vez de reconstruidos.
- Pagos y Crédito
Idempotencia y reconciliación desde el primer commit, porque un doble cargo no es un defecto que se parcha después.
- Industria y Servicio en Campo
Sin conexión como arquitectura, no como caché. Las cuadrillas trabajan donde la conectividad no llega.
- Retail y Comercio
Tiendas nativas y plataformas de comercio, incluyendo StorefrontOS como punto de partida.
- Tecnología y SaaS
Aislamiento multiinquilino y APIs de plataforma sobre las que otros construyen.
Preguntas que vale la pena hacer
¿Pueden trabajar sobre nuestro código actual en vez de empezar de cero?
¿Quién decide el stack?
¿Y si la fase 1 comprueba que la idea no funciona?
¿Recibimos el código sobre la marcha o al final?
¿Pueden retomar un proyecto que empezó otro aliado?
Productos en el mercado, con resultados publicados
Luna pasó de cero a una app nativa en el mercado en tres meses. FlightLogger le hace seguimiento a más de 1.500 aerolíneas con cobertura mundial de más de 30.000 aeropuertos.
Tráenos el backlog.
En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.