Pida a tres desarrolladores que coticen "una aplicación para nuestro negocio" y recibirá tres cifras que no se pueden comparar, porque cada uno supuso algo distinto. Un brief de desarrollo de aplicaciones claro lo resuelve. No necesita ser técnico ni largo. Necesita decir quién usará el software, qué debe poder hacer, a qué sistemas se conecta y qué pasa después del lanzamiento. Así se redacta uno para una aplicación web, una aplicación móvil o ambas.
Qué debe cubrir un brief de desarrollo de aplicaciones
Piense en el brief como un mapa para la primera conversación, no como un contrato. De dos a cinco páginas bastan para la mayoría de los proyectos, y debe cubrir:
- El problema. ¿Qué es lento, propenso a errores o imposible hoy? "Las cotizaciones tardan dos días porque los precios están en tres hojas de cálculo" es más útil que "necesitamos una aplicación de cotizaciones".
- Las personas. Quién la usará, aproximadamente cuántas personas y en qué dispositivos.
- El objetivo. Qué será distinto cuando funcione: menos llamadas telefónicas, facturación más rápida, trabajos que ya no se pierden entre la oficina y el campo.
- Restricciones. Plazos que sean reales, un rango de presupuesto y sistemas que no pueden cambiar.
Ya sea que llame al resultado software a la medida o aplicaciones web y móviles personalizadas, el brief es el mismo documento, y es la mejor preparación para una primera reunión con cualquier desarrollador.
Roles de usuario y las tareas que importan
La mayoría del software empresarial tiene unos cuantos roles de usuario, y cada uno ve cosas distintas: un administrador que gestiona los ajustes, personal de oficina que maneja los registros, trabajadores de campo con un teléfono y quizá clientes que inician sesión en un portal. Para cada rol, enumere de cinco a diez tareas que realizará con más frecuencia, con sus propias palabras. "Un técnico marca un trabajo como terminado y agrega fotos" es una tarea; "módulo de gestión de trabajos" no lo es.
Anote quién no debe ver qué. Es mucho más fácil diseñar los permisos desde el principio que añadirlos después del lanzamiento.
Funciones imprescindibles, funciones posteriores y criterios de aceptación
Divida la lista de funciones en las funciones imprescindibles para el primer lanzamiento y todo lo demás. El primer lanzamiento, a menudo llamado producto mínimo viable, debe ser la versión más pequeña con la que los usuarios reales puedan trabajar todos los días. Las funciones posteriores son más fáciles de priorizar cuando la gente ya la usa y le dice qué echa de menos.
Para cada función imprescindible, agregue criterios de aceptación: una frase que diga cómo sabrá que funciona. "Cuando un cliente sube un documento, la oficina lo ve en el registro del trabajo y recibe una notificación" se puede probar; "carga fácil de documentos" no. Los criterios de aceptación también son la forma más justa de decidir si una función está terminada.
Datos, integraciones de sistemas y dispositivos
- Datos existentes. Qué debe importarse de hojas de cálculo o de un sistema anterior, y qué tan limpio está.
- Integraciones de sistemas. Contabilidad, CRM, pagos, correo electrónico, mapas o envíos. Nombre el software y la dirección en que fluyen los datos; muchas de estas conexiones se manejan como trabajo de integración de API junto con la propia aplicación.
- Dispositivos y condiciones. Computadoras de escritorio de oficina, teléfonos personales o dispositivos portátiles resistentes de la empresa; en interiores o en obras con poca señal. Si las personas deben trabajar sin conexión, dígalo, porque da forma a todo el diseño.
- Funciones del teléfono. La cámara, el escaneo de códigos de barras, la ubicación o las notificaciones push apuntan a una aplicación instalada en el dispositivo y no a una aplicación web.
Una aplicación web a la medida que se ejecuta en el navegador suele bastar para las tareas de oficina, mientras que una aplicación móvil a la medida se justifica cuando importan el hardware del teléfono o el trabajo sin conexión. El brief no tiene que decidir esto; tiene que aportar los datos que lo deciden.
Cuentas, propiedad y la vida después del lanzamiento
Las cuestiones de propiedad son más fáciles de resolver antes de que exista código alguno. El brief debe establecer que el repositorio del código, el hosting, el dominio y las cuentas de tiendas de aplicaciones pertenecen a su negocio. Publicar en la App Store con el nombre de su empresa implica inscribirse como organización, y Apple exige una entidad legal y un número D-U-N-S para verificarla; consulte los requisitos de inscripción de Apple. Google Play también verifica las cuentas de organizaciones, así que empiece pronto con ambas.
Planifique también los años posteriores al lanzamiento. Los sistemas operativos de los teléfonos reciben una actualización importante cada año, y las aplicaciones de las tiendas necesitan actualizaciones para mantenerse al día. Tanto las soluciones móviles personalizadas como las aplicaciones web necesitan hosting, actualizaciones de seguridad y alguien responsable de ellos, así que pregunte en el brief cómo funcionarán las actualizaciones y el soporte. En nuestros proyectos de aplicaciones personalizadas, la documentación, el acceso al repositorio del código y un plan de actualizaciones y hosting forman parte de la entrega.
Preguntas frecuentes: brief de desarrollo de aplicaciones
¿Qué tan detallado debe ser el brief?
Lo bastante detallado para que dos desarrolladores imaginen el mismo software. Describa tareas y resultados en lugar de pantallas y tecnologías; un buen desarrollador lo convertirá en un diseño y preguntará por los vacíos.
¿Debo poner un presupuesto en el brief?
Un rango ayuda. El mismo objetivo se puede lograr con una primera versión sencilla o con una completa, y un rango permite a los desarrolladores proponer un alcance adecuado en lugar de adivinar.
¿Necesito wireframes antes de contactar a un desarrollador?
No. Los bocetos o las capturas de pantalla de herramientas que le gustan son útiles, pero no necesita diseñar las pantallas usted mismo. En nuestros proyectos, las pantallas interactivas de las tareas principales vienen después del descubrimiento y se revisan con las personas que realmente usarán el software.
¿Tiene un proceso que ya se les quedó pequeño con las hojas de cálculo? Nuestro servicio de desarrollo de aplicaciones web y móviles personalizadas comienza con el descubrimiento y un prototipo interactivo, construye por etapas y entrega la documentación y el acceso al código, para empresas de Los Ángeles, Long Beach y más allá. Envíenos su brief, aunque sea preliminar, e indíquenos quién usará el software y con qué sistemas debe funcionar.
