Hola,

Desde nuestra experiencia, vamos a crear una serie de entradas en nuestro blog de cómo afrontar un proyecto de software, enfocado a startups, programadores freelance que realizan todo el desarrollo, etc..

La premisa en la que nos basaremos és, una salida al mercado del «producto», ya sea una web, software de gestión, APP, etc… que se pueda realizar de forma rápida y con garantías. Esto nos dará una ventaja sobre los competidores, nos permitirá reenfocar el producto sin llegar a tener el 100% del desarrollo deseado.

Nuestra experiencia a lo largo de los años, nos ha enseñado como muchas aplicaciones quedan en el camino, debido a algunos factores que hacen que esa aplicación se retrase, sufra cambios una vez todo el desarrollo está casi finalizado, etc.. .Evidentemente hay otros factores, una vez desarrollada, ha de comercializarse, ya sea mediante campañas online, comerciales, publicidad, etc…

En esta primera entrada, vamos a definir unos puntos críticos iniciales, en posteriores entradas, añadiremos algunos detalles y consideraciones en otras fases del desarrollo y aconsejaremos algunas opciones en función de nuestra experiencia, hay que destacar, que hay muchos factores, tipo de cliente, tipo de empresa, etc… que influyen o varían estas pautas, pero puede seguirse un guión general con algunos puntos que suelen coincidir bastante.
Vamos a definir algunos puntos iniciales.

1- Identificar muy bien los requisitos iniciales, hacer una pequeña lista de la funcionalidad que creemos básica, no hace falta entrar en detalle, puede ser una lista con la funcionalidad a grandes rasgos, por ejemplo en el apartado de usuarios (login / registro / recordar contraseña), luego ya veremos y definiremos si el registro, envía un email de validación, si ha de enviar copia a diferentes usuarios, si ha de generar registros adicionales en la BD, etc….), pero a grandes rasgos es lo que debe cumplir. Si se identifica una funcionalidad no esencial, la pondremos en una lista Version2.0, que veremos más adelante como afrontar

2. Definir el equipo y los roles, en equipos pequeños, lo ideal es que todos puedan aportar en todos los campos, pero siempre debería existir o bien un ‘manager’ o alguien que se especialice en alguno de los puntos, por EJ: back, front, BD, cuando decimos back, nos referimos a la estructura que deberá tener el BACK, si tiene una API, capa de servicios, etc… a nivel de FRONT, si se va a usar bootstrap, jQuery, etc, etc.. a nivel de BD, motor de la BD, config mínima para slowqueries por ej, etc… esto ha de ser puesto en común antes de dar un OK, para que todo el equipo sepa de donde se parte y hacia donde se va.

3. Planificación de las tareas y bloques, indicando quien la va a hacer y que tiempo cree que le puede llevar, lo ideal es hacer algunas fases (no muchas), pero por ejemplo, registro de usuarios, panel dashboard, alta de productos (fase 1), proceso de compra de productos y gestión de las ventas (fase 2), crm de clientes con promociones, ofertas, mailing, etc… (fase 3), de esta manera tenemos una idea de cuanto tiempo nos puede llevar, y así tener una previsión.

4.Tecnología, un error muy común que vemos, es que al iniciar un proyecto, nos ilusionamos y decidimos usar lo último de lo último.. hay que sentarse y valorar si realmente merece la pena, en este punto aconsejamos que depende del conocimiento de esa tecnología por parte de los miembros del equipo, de si tenemos código de otros proyectos que sepamos que funcionan en versiones anteriores y podamos reutilizar. Por ejemplo, imaginemos que tenemos una librería que sirve para exportar o importar archivos excel, decidimos, crear nuestro proyecto en Laravel 7, y php 8, muy nuevos en estos momentos, pero tenemos proyectos en laravel 5 y php 7, con sus librerías para esta tarea. El proyecto avanza registro de usuarios, login, panel, etc.. y en el momento de usar la librería o funciona diferente, o no está actualizada, etc, etc, etc.. .esto puede provocar un retraso importante, al igual son 4 o 5 librerías que no funcionan, que el código o la manera de usarla han cambiado, no digamos si por ej Laravel ha cambiado la estructura (middlewares, eloquent, caché, o lo que sea)… Lo ideal es usar tecnología que conozcamos, sacar el producto en v1.0, y una vez el producto sea vendible por los comerciales, alguien del equipo de desarrollo realice las pruebas pertinentes para migrar a las versiones marcadas. Esto va a ser una tónica que no hay que olvidar, cada X tiempo (6 meses), lo ideal es actualziar librerías, framework, etc…

Con esto tendríamos un esquema del proyecto, tareas a realizar, equipo, roles, fases, tecnología a usar (librerías), etc…. En el siguiente post veremos como avanzar en el proyecto y otras aspectos a tener en cuenta.

Saludos.