Volver al blog
metodologias

Metodologías Pico

Framework de desarrollo para solopreneurs: innovación, minimalismo y retroalimentación constante

Metodologias pico

son aquellas metodologias de software para solopreneurs

consisten en: Un Amplio conocimiento de las tecnologias disponibles en el mercado actual, sus alcances limitaciones pros y contras una eleccion equilibrada entre un stack eficiente de alto nivel pero con buen performance y escalable.

Innovacion estetica y funcional. Marketing genuino y de calidad

Enfoque minimalista.

Retroceso intencional a travez de una Revision y reflexion constante del objetivo:

El enfoque de esta metodologia requiere al menos algo de experiencia tanto desarrolando como tambien de las diferentes partes del desarrollo…

Seguridad Performance Construccion Eleccion Distribucion.

El primer paso es un plan teorico muy bien estructurado y producto de refinamiento tras encontrar baches en cualquier aspecto tecnico. (y un retroceso)

el segundo paso es otro plan pero de implementacion. (y un retroceso)

El tercero es recien la construccion divida en 2 partes intimamente ligadas que a su vez se subdividen en etapas

por un lado: La interfaz y el diseño y por el otro la funcionalidad y el backend.

Para empezar la tercer etapa es necesario un retroceso y repasar una vez mas todo el plan.

Se empieza por diseñar la estetica en forma de wireframe con flujos mientras se va pensando en el backend de fondo. y se van definiendo las funcionalidades

una vez que se tienen en cuenta todas las vistas de forma de borrador, se intenta pensar en el flujo de un usuario. mientras se va definiendo que es lo que pasa de fondo en el backend.

Esta es la etapa mas costosa, wireframe + backend + retroceso.

Una vez que todo cierra coherentemente se empieza la construccion del codigo..

mientras en paralelo se hace el diseño teniendo en cuenta los wireframe..

Primero se define muy bien la estetica de UNA sola de las vistas… esto es con el fin de no perder mucho tiempo en diseñar toda la UI porque esta VA A CAMBIAR si o si

una vez definida una estetica que tiene que ser linda esteticamente, y no funcionalmente . se intenta hilar esta estetica con la logica definida previamente en los pasos (wireframe + backend + retroceso.) Si la estetica de la UI responde a las necesidadse de los flujos pensados ahi, entonces significa que va a ser mas util de la mitad; es decir va a ser mas del 50% util… . si este punto no se alcanza se vuelve a rediseñar la UI , el objetivo es alcanzar UNA SOLA VISTA MUY BIEN PRESENTADA Y COHERENTE CON EL FLUJO

Cuando se alcanza esta vista se pasa a la sigueinte etapa: que es A PARTIR DE ESTA VISTA, EMPEZAR A PENSAR EL FLUJO EN TERMINOS DE LA UI Y EL BACKEND es decir los flujos previamente definidos ahora adaptarlos como wireframes sabiendo que van a correpondderse con al estetica de la vista generada

una vez logrado ese wireframe, se empieza a codear con puramente la funcionalidad. sin estetica una interfaz muy rapida y de mala calidad de UI pero con toda la funcionalidad necesaria. una vez que eta la funcinalida necsaria recien ahi se empieza a pulir la estructura de la UI en este orden:

primero las medidas y tamaños de cada elemento. Despues los fondos y espaciados Despues la informacion real que va en cada uno (si es encesario ajustar) despues los eventos, hover, clicks, efectos animcaiones etc…

Deployar y listo FIN

categorias