Game Over

Se acabaron las excusas, tiro la toalla en esta edición del reto blogger ya que me veo incapaz de completar mi reto antes de que acabe el año, que recuerdo era:

Crear un NUEVO producto (o negocio) y conseguir facturar un mínimo de 1000EUR con él, antes del 31 de Diciembre de 2012.

Sin embargo, que no cunda el pánico, con o sin reto blogger el proyecto Mazinger sigue adelante. De momento ha cogido nuevos bríos y estamos en plena fase de discusión sobre los requerimientos. Para el que no esté familiarizado con el ciclo del software comentar que esta fase (captura de requerimientos) es la más importante. En los requerimientos se debe detallar de forma clara, precisa y concisa que debe hacer el producto o aplicación que queremos implementar. Es muy importante invertir mucho tiempo en esta fase, antes siquiera de tirar una sola línea de código. Una vez empezado el desarrollo cualquier funcionalidad que se nos hubiese pasado por alto podría tener un coste altísimo, en comparación a si se hubiese tenido en cuenta desde el principio (estoy harto de ver esto en todos los proyectos, "las prisas son malas consejeras"). Los requerimientos los podemos clasificar en:

• MUST HAVE: este es un requerimiento que debe ser implementado forzosamente e.g. "los datos de las tarjetas de crédito deberán quedar encriptados en el sistema".


• COULD HAVE: este es un requerimiento que, si bien es importante considerar, no será obligado implementar en la primera versión "1.0" e.g. "el login inicial en el sistema deberá seguir un procedimiento de validación por email". Es importante considerar estos requerimientos en el diseño de la escalabilidad del sistema, de cara a futuras versiones con funcionalidades ampliadas (*).


• NICE TO HAVE: este es un requerimiento prescindible pero que sería una "cucada" implementarlo e.g. "posibilidad de que los usuarios utilicen la negrita y el subrayado en los comentarios" ;)

Entonces, junto con el documento de requerimientos (dónde, aparte de explicar en detalle que debe hacer el producto, incluiremos "use cases" ("casos de usos") describiendo todas los posibles procesos de flujo a los que se debe enfrentar nuestro producto/sistema) completaremos una matriz con la lista completa de requerimientos (cada requerimiento irá numerado unívocamente). Posteriormente, una vez los requerimientos estén claramente definidos, clasificados (requerimientos de seguridad, requerimientos de diseño de pantalla, requerimientos de funcionalidad...) y listados, crearemos sendos documentos de diseño y de pruebas que habrán de cubrir todos y cada uno de los requerimientos identificados, Para no aburrir, describiremos los siguientes pasos en otro post (o no), quedaros con la idea de que la creación de software más que un arte es una ciencia, aunque esto es la teoría... en la práctica acabamos todos con el sistema de "prueba y error" ;), no obstante cuanto mejor planifiquemos todo mucho mejor.

(*) Una cosa en la que incido al equipo una y otra vez es en seguir el principio KISS (Keep It Simple Stupid) para la v1.0 del producto. Steve Jobs era un fanático de este principio y estaba obsesionado con que los productos de Apple fuesen cerrados y sencillos (e.g. el iPad: una pantalla táctil, un botón y listo), y yo estoy absolutamente de acuerdo con él, todo debe ser lo máximo sencillo posible. Otro ejemplo: cada paso extra que tenga que dar un usuario en una web de e-commerce para comprar un producto más posibilidades hay de que abandone el proceso de compra. 

Aún recuerdo mi perplejidad la primera vez que vi el buscador de Google (acostumbrado a Altavista y Yahoo): una pantalla en blanco con el anagrama de Google y una casilla para buscar texto en la www siguiendo criterios objetivos y no comerciales, y ya está! mirad en lo que se ha convertido Google ahora... y es que Google es otro buen ejemplo de crear herramientas sencillas y potentes.

Esto es si cabe más importante en la primera versión del producto (a la cual informáticamente es común denominarla "1.0"). Machaconamente una y otra vez insisto al equipo en concentrarnos en la funcionalidad más básica: saquemos un producto sencillo, fiable, robusto y fácil de usar al mercado y ya luego implementaremos las miles de posibilidades que se nos ocurren! Por supuesto dotando al sistema de la máxima flexibilidad y escalabilidad, de cara a futuras mejoras... difícil compromiso.

En fin, terminaré como he empezado, jodido por no poder optar a ganar este reto ya que yo soy tremendamente competitivo :( y es que es condición sin equa non el haber cumplido el reto personal para que las votaciones se tengan en cuenta. Queda el consuelo de que mis rivales van también como el culo con sus retos, a excepción de Richarte que está haciendo unos vídeos muy divertidos y al final ganará el cabrón!!

De todas formas me queda un "run-run" y quién sabe... quizás mañana me ponga a vender coca-colas, cervezas y patatas con un carrito por la playa y haga los 1000EUR... o algo similar... humm...