Nadie en su sano juicio le puede gustar la gestión de proyectos. Si lo haces es porque es la herramienta para conseguir algo, dudo que un humano quiera dedicar su vida a la parte aburrida del trabjo. Dicho esto, mis respetos a toda esa gente, como veis, yo no me dedico a esto profesionalmente, así que no tengo que hacer ningun amigo.

Como me ha tocado hacer esto durante toda mi vida laboral y veo todos los santos días a gente que no tiene la más remota idea de como gestionar un proyecto, por pequeño que sea, voy a soltarte un rollo importantísimo con algunas cosas básicas de como llevar proyectos.

Esta pequeña guía está pensada para startup tecnológica, pero los principios aplican a cualquier cosa. Y aplican porque el 99% de un proyecto es la gente y la gente siempre es igual (de pesada, es tontería no soltarlo en la intro directamente).

Por si acaso tu capacidad de concentración no te da para leerte 7 secciones de 3 párrafos cada una, te dejo el resumen en una frase: tu proyecto sale si la pones a la gente a funcionar. El resto da más o menos igual.

Los productos pasan por diferentes fases y no tiene sentido tener el mismo proceso. Por mucho que te empeñes en usar SCRUM/Kanban/la tontería de Spotify o la cosa de moda del momento tienes que adaptarla a tu empresa, tu presupuesto, el momento de tu producto y sobre todo, tu gente.

Por eso cuando lees que Google o similar tienen un sistema, seguramente no tiene sentido aplicarlo para tu empresa de 6 fulanos en Boadilla. La parte de leer, comprender lo leído, analizarlo y luego razonar sobre si tiene sentido en tu contexto se ve que la quitaron de la carrera de informática (o puede que de secundaria) en algún momento de este siglo.

Así que aplica el cuento para este texto, estos son procesos que a mi me han funcionado, pero puede que a ti no, así que como te digo, lee, analiza y usa lo que te sirva.

Al tema. Las dos fases que diferencio en el desarrollo de un producto en una startup son preproducción, que va desde que tiras la primera línea hasta que tienes clientes en producción y post-producción, que es cuando los clientes ya se empiezan a quejar y no sabes muy bien como organizar el trabajo.

El único objetivo es poner tu producto delante del cliente, así que es el único foco que tienes que tener.

La pregunta diaria es: hay algún cliente probando esto? si la respuesta es no, eso es lo único que tiene que importar, el resto es ornamento, fuegos de artificio, champán para desayunar.

Esto suena fácil, pero rápidamente te encuentras a dos desarrolladores discutiendo sobre qué framework de testing usar o si “tabs vs spaces”. En ese momento seguramente tienes que estar pensando en poner order (y pensar si has contratado bien) pero es la patada en la boca que necesitas para saber que tienes que tomar decisiones y poner a la gente a mirar al mismo sitio.

Bueno, mi receta para estos proyectos es la siguiente:

• Monta un equipo pequeño, 5-6 personas máximo y aislarlo
• Marca un objetivo de lo que quieres que el cliente use
• Pon una fecha agresiva
• Monta un plan semanal
• Trackea todos los santos días, empuja cada detalle, modifica el plan

Facilímismo. No hay mucho misterio, da igual que montes el equipo de cero o sea dentro de una empresa ya establecida.

La primera regla es que tienes que tener claro qué quieres hacer. Esto no quiere decir que tengas claro el producto que quieres tener, si no el problema que quieres solucionar. El producto coge forma por el camino.

Estás pensando ahora mismo “este es gilipollas, he venido a leer un artículo para que este me diga que tengo que saber qué hacer”. Bien, la mayoría de gente no tiene claro exactamente qué quiere hacer, tiene una idea de lo que cree que quiere hacer.

El otro tema es, puede que tengas tu idea clarísima, pero está en tu cabeza, ahora tienes que sacarla fuera. No eres ese genio que tienes ideas increíbles y necesitas dar un aire místico ocultando parte de ellas para darte el pisto. No seas ese gilipollas, pon encima de la mesa todo lo que tengas.

La segunda regla es que tienes que tener el mínimo número de cosas y quitar el máximo número de tonterías. Te tiene que sobrar todo, como cuando no quieres pagar los 40€ para llevar maleta en Ryanair.

Si no tienes clara la regla número 1, no pierdas el tiempo en montar un equipo vas a tirar tu dinero y el tiempo de mucha gente.

La gente es lo peor. Cualquier que haya gestionado personas en su vida lo sabe. Seguramente por eso es la clave de todo. Poner a la gente a funcionar juntos, entender las dinámicas, lo que les motiva y todo ese tinglado de las emociones es horrible porque no se puede medir, no se puede hacer un proceso y no son matemáticas.

La gente que esté en ese equipo tiene que ser poca y muy navajeros, les tiene que importar poco guarrear, no seguir las normas. Tienen que estar pensando en poner en producción todo el día. Que les queme. No importa si son rápidos o lentos, tienen que tener claro lo que hacer e ir allí.

Hay que saber elegir bien la combinación de gente que pones. No vale coger a los más rápidos o las más listas, tiene que haber un tejido entre esas personas. Es el grupo el que hace que el proyecto salga, así que hay que priorizar el conjunto y no la lista de individuos. Tampoco vayas a pensar que pones a un paquete en un equipazo y se va a convertir en el nuevo John Carmack. Así que si vas a contratar, busca a quien complemente, no una lista de “features”. Aquí la intuición, por mucho que duela a toda la industria del recruitment, es clave.

Tienes que desarrollar esa intuición, la gente no son matemáticas, ni tampoco son “frontend” y “backend”, la gente es tan buena como los dispuesta que esté a comerse el marrón de otro de buena gana.

Y cómo se desarrolla esa intuición? fácil, haciendo muchos proyectos con muchos equipos, llevándolos a producción, trabajando con mucha gente, hablando con ellos, al final identificas patrones con relativa facilidad. Al principio tendrás que cargarla y arreglarlo por el camino, luego también, nunca se hace bien esto.

Dicho esto, en general, cualquier cosa que hagas es menos importante que esto

“YOU CANNOT COMPETE WITH SOMEONE WHO IS HAVING FUN”

A menudo se nos olvida que la gente que mejor funciona es la motivada y la gente está motivada si está pasandoselo bien (que no tiene que ver con hacer una cosa u otra, he visto a gente hacer debugging de cosas horribles y estar pasándoselo bien)

Y no puedes fakear la motivación, es como el amor, se nota cuando pasa.

El día que se empieza el proyecto se sabe el día que se lanza. No digo que se termina, digo que se lanza, y esto implica que tienes que tener en mente que hay que lanzarlo, no solo programarlo

Se marca una fecha, lo que va a salir y de ahí hacia atrás, semanalmente, se colocan lo que se espera tener cada semana. OBVIAMENTE esto va a cambiar, pero tiene que haber buenas razones para hacerlo.

Cada semana el lider (ver “el lider”) se trabaja bien lo que hay que hacer la siguiente semana y se lo explica al equipo. Se discute, se cambia y se pone la gente manos a la obra. Lo que no se hace es llegar e improvisar, se prepara, se preve los problemas, se tira lo que claramente no funciona.

Se puede hacer más de una semana, pero me parece que es un buen compromiso de tiempo para no meterme muy en la mierda si la has liado

El proceso por el proceso no tiene sentido, el proceso en este caso es llevar a producción y para llevar a producción necesitas: descubrir, corregir, iterar, probar y vuelta a todo esto. Lo mismo que dicen todos los tratados agilistas pero esta vez no hablas más del proceso que del resultado.

El sistema que uso funciona así:

• Se habla todos los días. Se revisa lo que se ha hecho y lo que se va a hacer. Se eliminan dudas y bloqueos. Tu labor como gestor es salir de allí con la sensación de que a todo el mundo le parezca que tienes claro el qué y el cómo. La mayoría de veces tomas decisiones sin tener ni idea, pero da igual, lo importante es avanzar. Avanzas para descubrir. No significa que tengas al equipo engañado, significa que no hay más mínimo lugar a dudas que aquí no se para.
• Los canales de comunicación son constantes y en tiempo real. Es más importante resolver una duda que tener foco.
• Si hay posibilidad, estar en persona donde todo fluye mejor (que yo sé que eres muy fan del trabajo en remoto, pero es que venimos a trabajar)
• Solo hay un documento de trabajo. Más sobre esto abajo.
• Hay un líder, tiene que haber alguien empujando.

Tú eres el lider. Tú marcas el paso en cada reunión, decides que hacer cuando hay dudas, recuerdas todos los días donde vamos y donde estamos, eres el primero en entrar a la reunión diaria, el que prepara el documento, el que dice qué se va a hacer cada semana, el que aprieta o suelta en función de como va el equipo. Decide quien está y quien no está. Te va a tocar meter y sacar gente de ese equipo, así que tiene que tener cierta mano.

Pero tiene que haber alguien, no vale el juego de “confiar en el proceso”. El proceso son los raíles pero tiene que haber alguien tirando.Solo una persona y si puede ser que tenga el respeto del resto, no vayas a pensar en poner un engineering manager standard. Y tiene que tener cierto respeto porque cuando vengan relativamente mal dadas a la gente se la sopla que seas “loquesea manager”, recuerda que estás trabajando con gente con criterio propio.

La otra cosa que tienes que hacer como lider es explicar qué es lo que quieres hacer, poner lo que tienes en la cabeza fuera. Ya sabemos que eres el rey del mambo y que tus ideas son las mejores. En tu cabeza todo suena espectacular, así que más vale que saques todo eso día tras día.

Este documento es la biblia. No hay más sitios donde se trabaje, puede ser un google doc o lo que te de la real gana que sea colaborativo. Nada de issue trackers, no linear, no JIRA, no has venido a trackear, no has venido a jugar a ser una empresa que se puede permitir invertir tiempo en gestionar, has venido a poner en producción.

Tiene que tener

• Qué se va a hacer
• Que NO se va a hacer
• Cómo lo vamos a hacer
• Cómo medir que lo que hacemos está bien
• Timeline con un deadline y deadlines intermedios
• Logística: quién y cómo
• Un worklog donde todos los días todo el mundo pone qué ha hecho y que va a hacer. Suena a fiscalizar y efectivamente, mantener a la gente “accountable” requiere un esfuerzo y es una pesadilla, pero hasta los deportistas de élite, con la mejor fuerza de voluntad del mundo necesitan a alguien que les de la brasa.
• Principios a nivel técnicos/de producto/de como trabajar, esto es, cosas que valores por encima de otras cosas y que te ayudan a tomar decisiones. Por ejemplo, esto fueron los principios de uno de los proyectos

• Local experience first, UI second
• We leverage LLMs everywhere: suggest schema, suggest migrations, suggest SQL, cursor context, tests generation, generate fixtures, [re]generate tests, fix tests, add quality tests, generate everything
• Development speed is the priority. If there is a workaround, we take it.
• UI will work more like the CLI (we deploy stuff instead of changing it right away)
• Let's forget about git integrations for now. That does not mean we can't integrate deep (for example, pushing from the ui to the repo)

Otras cosas que puede tener:

• Decisiones técnicas
• Documentación
• Links a cosas importantes, contexto

Personalmente uso un google doc, tiene tabs para separar cosas, es tiempo real, permite comentarios, cumple bien.

Lo que estableces como fundamental y persigues cada día, se queda. Lo que quieres que pase pero no persigues, se queda en amor de verano y buenas intenciones.

Si tu dices que tu software tiene que ser rápido o que los bugs se resuelven el mismo día que aparecen, lo repites mil veces, lo persigues todo el rato. Si no se hace, te vas al equipo y dices “sois unos buenos lebreles, no me hacéis ni puto caso” o la fórmula que tú tengas para echar la peta sin parecer un cabrón.

Esto pasa a nivel de proyecto y a nivel de empresa, lo que persigues durante un tiempo, se queda para siempre, así que ten claro lo que valoras y síguelo.

Hay momentos de rozamiento, en todos los equipos los hay, pero en estos, especialmente. Has elegido a esta gente porque son decididos (high agency que se dice ahora) y es normal que pasen cosas.

Tú eres el que engrasa eso, los roces no pueden quedarse ahí, o bien eres tú quien toma la decisión y todo el mundo se pone a funcionar o tratas de quitar la parte del ego (que es lo que jode todo) y racionalizar.

La regla aquí es que no dejes que un conflicto no se solucione. A veces se tarda, tienes que dejarlo madurar y volver, pero vas y lo puto arreglas.

Si este proyecto que tienes pensado está dentro de una empresa relativamente grande, con cierta inercia, con su pasado, sus formas, tienes que aislar a la gente del proyecto. Si crees que el corporate es incapaz de lanzar proyectos interesantes porque son malos es que no has trabajado en uno nunca, no los sacan porque hay un montón de moscardones tocandolos huevos, un montón de políticas y procesos que "hay que seguir".

Tú has venido aquí a romper el cristal de "rómpase solo en caso de emergencia", coger el martillo y huir con el botín. Tienes a un equipo que va a salvar al rehen en medio de la selva, van a dejar algún herido seguro, va a doler.

Esto significa que puede que te juegues tu puesto, bien porque salga mal y termines en un sótano siendo SCRUM master o porque quemes todos los puentes. Pero, joder, tú has venido a este mundo a dejar huella, no a ser un rule follower, no vayas a coger el camino aburrido.

No busques un numerito, no hay una métrica que te diga si está bien o mal. Ni ahora, ni nunca (aunque parezca que sí). Los KPI se ponen para que los directivos cobren bonuses y puedas apretar a tus empleados, no porque sean útiles en esta fase.

Esta es la forma de medir: 1\) hay clientes? si la respuesta es “no” significa que vas mal. 2\) la gente que lo está usando te dice que les gusta? si es que si (y va a ser que si, nadie te dice que algo no le gusta), lo siguen usando? si la respuesta es no, te estaban mintiendo para quedar bien y tienes que entender como arreglarlo.

En el momento en que estés en producción, tengas clientes, hayas iterado y empezado a tener suficiente número de problemas para que el equipo esté sobrepasado, entonces es cuando tienes que pasar al otro modo

TBD