Cada vez que escribo un plan, siempre pongo los siguientes capítulos.
Introducción
No olvides esto. Las personas que leen su plan quieren saber: quién es usted, qué hace aquí, quién soy, de qué se trata el proyecto y por qué estoy leyendo esto. Puede sonar tonto, pero su argumento de venta (si tiene que “vender” el proyecto) comienza en la introducción y le permite preparar el escenario.
Resumen
Resuma la introducción, los requisitos, la funcionalidad básica, la planificación, el costo y las posibles acciones futuras para cualquier persona demasiado floja como para leer el informe completo.
- ¿Cuánto cuesta construir un sitio web de citas y una aplicación móvil?
- ¿Es posible crear una aplicación de emoji para iOS con símbolos originales y alternativos?
- ¿Cuál es el rango de costo promedio para lanzar una beta privada para una aplicación para aproximadamente 100 personas?
- ¿Cuál es la principal diferencia entre Cordova y la plataforma móvil nativa?
- Cómo hacer una aplicación para iPhone
Funcionalidad
Para una aplicación móvil, siempre trabajo con una maqueta aproximada. Cada interfaz tiene su propia maqueta, y escribo lo que hace la interfaz en inglés básico. No asumas demasiado, tus lectores podrían no saber qué es “arrastrar y soltar”. Además, tampoco especifique demasiado. Respete los elementos de interfaz estándar y no tenga un discurso de diseño elegante Si su interfaz es demasiado complicada de explicar (con animaciones, esto puede ser), considere usar una maqueta de video de un diseñador de movimiento. Tenga en cuenta que este capítulo necesita un flujo lógico, por lo que desde el inicio de la aplicación hasta cada una de las subfunciones. Todavía tiene que ser una historia que el lector pueda seguir.
Lo que no va a hacer
Esto es importante: ¡señala lo que la aplicación no hará! Con demasiada frecuencia, un cliente me dice: Oh, pensé que estaba incluido, parecía lógico. Pues no lo es. Señale que no hay nada que asumir en este capítulo.
Requisitos
Señale en términos de bala lo que la aplicación debería ser capaz, en términos mensurables. Señale también lo que espera de su cliente: ¿deberían tener una cuenta de App Store? ¿Pagan por el diseño o tienen un diseñador en la nómina? ¿Qué archivos y con qué calidad entrega?
Pruebas
Como dice Steve Krug: comience a probar desde el principio. Elabore un plan para la prueba: ¿cuándo va a hacer la prueba, con qué frecuencia y cómo? Las aplicaciones se pueden automatizar fácilmente para las pruebas de interfaz de usuario y tratar de no molestarse con las pruebas unitarias. Tenga en cuenta que tener un flujo de trabajo de prueba deficiente influirá en gran medida en su tiempo de entrega y flexibilidad con las actualizaciones de la aplicación.
Gente clave
Señale quiénes son las personas clave en el proceso y asígneles un título y una responsabilidad. Nada peor que enviar CC a todos en el proyecto o reenviar constantemente correos electrónicos, o hacer que alguien diga al final del proyecto: No, ese no era mi trabajo.
Planificación
Sí, incluye una planificación. No, no lo hagas demasiado estricto. Intente trabajar con una planificación que dependa de la entrega, de modo que no haya fechas precisas sino un cuadro que diga “cuando haya terminado, comenzaremos con esto”. No olvide que firmar un proyecto lleva tiempo: ¡deje que la planificación comience después de ese tiempo!
Costo
Proporcione una descripción detallada del costo, pero no lo convierta en un menú. No me estoy sumergiendo demasiado en esto, si estás en este negocio ya deberías saber cómo hacer una estimación. Lo mismo se aplica para fundir los requisitos en hierro y firmarlo con sangre: cuando su cliente no cumple, tiene problemas. ¡Ten eso en cuenta!
Archivos adjuntos
Cosas como maquetas, términos y acuerdos generales, licencias, etc.
¡Buena suerte!
Descargo de responsabilidad: he trabajado como desarrollador de aplicaciones (contratación de trabajos) durante los últimos 6 años, por lo que he hecho lo anterior más de cien veces. Además, entreno a los editores de aplicaciones en sus habilidades comerciales.
