Como organizar(me) los proyectos

01 de Enero del 2021

Es importante entender, que el Como de estos articulos, a veces no son los consejos de un experto, mas bien los planes de un aprendiz.

Crear proyectos, como desarrollador/a, es genial, creas un producto, y te aporta valor, aunque no lo termines, ya que te da las experiencias de los problemas solucionados y el conocimiento del código usado. Pero cuando queremos dar el siguiente paso, y convertir estos proyectos de experimentos de laboratorio a productos reales entran en juego otros aspectos que debemos atender para evitar perder el tiempo.

Soy muy fan del "learn by doing", pero en su justa medida y con el objetivo correcto.

Mi proceso

  1. Analizar la idea.
  2. Elegir las tecnologias.
  3. Definir las tareas minimas.

Tú dirás; "pero esto no es nada nuevo, así es como se crean proyectos de normal", y te sorprendería saber la cantidad de desarrolladores que pasan a la ejecución directamente, como pollos sin cabeza, antes de analizar la idea. El objetivo de escribir y definir este proceso es "obligarme" a seguir una disciplina, para invertir mejor mi tiempo.

Analizar la idea

Analizar significa entender, la idea que tienes, y ver si encaja con la necesidad que quieres solucionar, explorar sus posibilidades y de ahí seguir uniendo los hilos. Quizás te des cuenta de que no era tan fácil como pensabas, o que en realidad tienes muchas más opciones para mejorar tu futuro producto.

Esta parte es muy abstracta y a mí me sirve para pensar el producto ideal. Ojo, quizás tú no seas el target de tu producto y la estés liando, para eso siempre viene bien el feedback de gente que piensas que estaría interesada o tenga el problema que quieres solucionar.

En esta parte hay mucho de marketing, y es que a veces creemos saber lo que la gente necesita, pero la realidad no siempre es así. Actualmente me encuentro formándome en marketing enfocado a SaaS y productos de este estilo, así que quizás en el futuro expanda esta sección.

Elegir las tecnologías

A mí eso de hacer todo con el mismo lenguaje, con el mismo framework sin importar la necesidad, me huele a rancio. Como en todos los trabajos, las herramientas correctas ayudan enormemente a no sufrir trabajando. O prueba a trabajar de carpintero con un cenicero en vez de un martillo.

Definir las tareas mínimas

Quizás tu producto es brutal, con miles de implementaciones, pero para cuando lo tengas terminado quizás ya ha entrado alguien al mercado que te sustituye, o el tuyo es tan complejo que prefieren usar a "la competencia". O simplemente nadie va a usarlo, o se convierte en uno de esos proyectos de "ya lo terminaré".

En vez de crear todas las ramas de producto, elijo las que me permitan tener una versión funcional rápido, probarla, enseñarla, y me ayuda a encontrar la motivación de ir mejorando el producto, en vez de convertirlo en un proyecto "que nunca termina".

En cuanto al nivel de detalle de la tarea, yo apunto hasta el más mínimo, aunque me lleve una hora realizar este análisis de tareas. Porque esta hora de análisis, ahorrara 12 horas de cambiar código en el futuro porque no me di cuenta de cierto detalle minúsculo que cambiaba por completo la implementación.

La parte interesante es que para mí esto es un proceso iterativo. Menos por la parte de elegir las tecnologías (si no lo hice bien al principio ese era el problema), en cada iteración de este proceso analizo lo que quiero introducir y la forma más eficaz de introducirlo. Aparte, de que este acercamiento permite adaptarse a los problemas mientras surgen y poder solucionarlos, en vez de construir un monolito que luego hay que cambiar entero.

Perfección es enemigo de lo bueno

No quiero decir que haya que hacer basura rápida, quiero decir que debemos asegurarnos de conocer el equilibrio entre rapidez y calidad. Quedarse mirando el código después de cada línea para ver como puede ser más óptimo, lo unico que hace es multiplicar el tiempo de desarrollo por dos. Si queremos realizar este proceso, entonces debemos adoptar algo más conocido como code review, en el futuro hablaré de eso.

Código exquisito

El código limpio es lo mejor, y hay infinidad de artículos donde se explica que la calidad interna (como está hecho) de un producto ayuda en cuanto a mantenimiento y escalabilidad. Pero estamos en 2021, tenemos herramientas brutales (frameworks) que nos ofrecen la capacidad de no reinventar la rueda y nos ofrecen la capa justa de abstracción y funcionalidad para poder crear lo que al final importa, nuestro producto.

Reinventar la rueda

Si, aprender como está hecho algo, es esencial, pero para un proyecto personal a nivel formativo, no en algo que luego queremos entregar o en una empresa. Puede que pensemos "para qué voy a usar esta librería si lo puedo hacer a mano", pero los que mantienen esa librería ya han invertido una cantidad enorme de horas en contemplar casos de uso que ni sabes que existen, y que cuando te pasen, el tiempo que invertirás en arreglarlo no será rentable. Lo digo por experiencia.

Estimación de fechas

Nadie es capaz de conocer la fecha de fin de entrega exactamente porque deducir lo que se tarda en hacer un proyecto entra más en temas de astrología y adivinación que en el desarrollo de software en sí mismo. ¿Pero por qué, los propios desarrolladores, no saben lo que tardan? Sí que lo saben, lo que pasa es que somos optimistas y creemos que el desarrollo va a ser una carrera sin obstáculos, encontrando las soluciones a la primera, con respuestas perfectas en StackOverflow que poder copiar y pegar, etc.

Por eso en cuanto aparece el primer problema, esta fecha en la que el desarrollador terminaría ese desarrollo, ya no es real.

Como estimo yo las fechas

Si he realizado correctamente el análisis de tareas necesarias, bien desgranadas, le aplico lo que yo creo que tardaré y le añado un 30% del tiempo que he puesto, por si las moscas. De normal, no necesitaré ese tiempo, pero cuando lo necesite, o surja un problema, podre ocuparme del mismo sin tener la continua presión de "me estoy pasando de tiempo", ya que llevaré un buen ritmo. No es engañarse a uno mismo, de hecho, muchas veces, ese +30% es el tiempo real.

¿Estimar, en proyectos personales?

En freelancing es imperativo, en crear un producto propio, no sé yo, aunque depende si ya tienes usuarios/clientes que buscan actualizaciones futuras.

Este artículo me servirá para no perder el norte en futuros proyectos, o quizás lo actualice porque he encontrado un sistema mejor, pero de momento es lo que mejor me ha servido para adaptarme a los cambios, para aprender rápido, ser más eficiente y hacer mi tiempo más rentable.

Observación

Ojo, esto en productos para empresas, se involucran otros muchos aspectos, ya que entran en juego los dueños de producto, los diseñadores, los de QA, los clientes pidiendo cambios en mitad del desarrollo, etc.

Pero creo que el punto en común de los side-projects y los proyectos "principales" es que el producto saldrá antes y mejor si se prima el análisis, sobre las prisas para empezar.

Fuentes: