search instagram arrow-down

Deja tu correo electrónico para avisarte de mis nuevos artículos

Entradas recientes

angel maría animales aprender aprendizaje blog cambio clientes competencia constancia consumo creatividad desarrollo e-commerce ecología educación empleo emprendedor emprender emprendiendo emprendimiento empresa empresas enseñanza equipo escribir estrés evento felicidad filosofía foco fracaso frustración gestión hablar información inversión Lean startup libro libros lujo madrid medios de comunicación miedo motivación negociación negocios objetivos película pensar personal personas presentación proyecto psicología simplificar social sociedad sociología socios talento tienda timidez tonterías razonables trabajar trabajo Unikuo valiente valor veganismo vergüenza viaje vida video Web éxito

Menos documentos y más prototipos

Menos documentos y más prototipos

Una de las cosas que he aprendido en mi paso del mundo corporativo al de las startups es a apreciar el valor del tiempo y el dinero, es decir, de la agilidad. En una gran empresa sueles tener presupuestos y recursos holgados, justo lo que te falta cuando creas tu propia empresa. Los que venimos del mundo corporativo empezamos en las startups con torpeza creyendo que las reglas son las mismas, pero no es así. Hasta que el emprendedor no lo asimila y comprende COMPLETAMENTE, seguirá cometiendo fallos que harán que su proyecto termine antes de tiempo.

Documenta solo lo imprescindible

Vamos a partir de la base de que la documentación es innecesaria, solo prepara aquella que tu proyecto te está pidiendo a gritos. ¿Toma de requisitos? La puedes hacer en un folio y no hace falta que la pases a limpio, como mucho, crea un sencillo documento de texto explicando la aplicación y cuáles son los requisitos clave.

Prototipos en papel

¿Análisis funcional?, ¿diseño técnico?, eso déjalo para las complejas aplicaciones corporativas, coge un lápiz y empieza a dibujar. Prepara los prototipos de las pantallas clave de la aplicación, haz las anotaciones que creas conveniente y no te preocupes por si queda bonito. Los prototipos son herramientas de trabajo, no cuadros al óleo. Enséñale a tu cliente el prototipo y repasa los requisitos con él delante. A buen seguro saldrán cambios, pero como no te habrá costado trabajo preparar los prototipos, tampoco te costará cambiarlos. El problema de los extensos documentos de análisis es que mantenerlos es un auténtico infierno, y no te engañes, el cliente nunca tendrá la misma claridad para decidir con un domento en Word de 20 páginas que con unos simples prototipos. Claro, que eso no lo sabrás hasta que la aplicación esté funcionando y te diga que eso no es lo que quería.

Pantallas en html

Una vez enseñados los prototipos y realizados los cambios (no olvides que este es un proceso iterativo y que puede requerir varias revisiones), ponte manos a la obra y pinta las pantallas en html o con la herramienta de desarrollo que vayas a utilizar. Todavía no programes, limítate a pasar tus prototipos revisados a algo más real pero que puedas realizar en poco tiempo. Este prototipo digital más elaborado ya le permitirá ver a tu cliente el resultado “final” de la aplicación. Piensa que a él el código le da igual, lo que va a utilizar es el interfaz y es lo que más le importa. No dudes de que cuando lo vea, surgirán más cambios que podrán realizarse con agilidad porque todavía no habrá programación.

Empieza a programar

Ya tenemos el esqueleto, ahora, vamos a darle vida. Lo bueno de empezar a programar en este instante es que tanto el programador como el cliente tienen una idea clara de cómo quieren que sea la aplicación, habrá cambios, pero te aseguro que no tendrá nada que ver con lo que ocurriría con el método clásico de 1º requisitos, 2º análisis, 3º diseño, 4º programación, 5º pruebas…

Cuidado con complicar las cosas

Llegados a este punto, la clave es ir revisando las funcionalidades más importantes con el cliente antes de que la aplicación vaya ganando en complejidad y los cambios sean más costosos. Es vital que el programador advierta al cliente de aquellas funcionalidades que vayan a complicar demasiado la aplicación para evitarlas o simplificarlas. Esto tiene como fin el conseguir un aplicativo sencillo, con poco código y pocas dependencias, vamos, el sueño de cualquier programador que tenga que tocar el código en un futuro :). En programación, a mayor código más errores, más coste de mantenimiento y más coste de aprendizaje para nuevos programadores. Además, más funcionalidad no es igual a mejor programa, y si no, probad BaseCamp de 37Signals, una de las aplicaciones Web de gestión de proyectos más exitosas y a la vez más sencillas que hay.

Recuerda, normalmente la solución más sencilla es la mejor solución.

One comment on “Menos documentos y más prototipos

Responder
Your email address will not be published. Required fields are marked *

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s