Cómo gestionar tu primer proyecto de desarrollo: first steps

Ser Project Manager de un proyecto de desarrollo es un lindo desafío. Las exigencias de conocimientos técnicos y terminologías son más altas, pero también es algo que nos enriquece como PMs. Por eso, junté algunas recomendaciones en este artículo que te pueden ayudar 🙌

Tener claros los roles  🎩

Hay distintos factores iniciales que van a afectar en nuestra gestión de un proyecto de desarrollo.

Si el equipo de devs es grande, debemos entender muy bien el rol de cada uno en el proyecto. Es decir: saber quién está a cargo del Frontend, quién está encargado de la arquitectura…y del Backend. ⚠️ Esto es aún más importante si es tu primer proyecto porque así vas a saber a quién consultarle cuando quieras saber algo o si algo no salió como lo esperábamos.

Para llegar a este lugar, está bueno juntarse con el equipo y el manager de los devs (si es que hay) y que la decisión sobre los roles se tome en conjunto según lo que cada persona desea a nivel profesional y lo que el proyecto necesita. 

Además, es ideal que el equipo esté conformado por personas con más y menos experiencia para buscar el aprendizaje continuo y el mentoreo entre sí. 

¿Y si también hay diseño? 🤔

Si el proyecto involucra diseño y desarrollo, como PMs debemos (siempre y cuando el tiempo lo permita) poner como tarea a los devs que revisen el diseño unas cuantas veces antes de entrar hands on con el código.

Incluso, lo ideal sería hacer uno o dos encuentros iniciales entre PM y devs (si es posible con diseño también) para que el handoff sea mucho más completo, revisar todos los diseños a trabajar y levantar dudas, inquietudes y mejoras. 

Muchas veces (y a veces diría que es parte cotidiana de los proyectos) se da mucho por sentado y en la transición de diseño a desarrollo, la comunicación entre equipos es importante y como PM debemos prestar atención (y pushear por eso a nuestros equipos) a los detalles, para evitar idas y vueltas.

Precisión en los tiempos  📅

Como PMs debemos pedir estimaciones lo más detalladas y precisas posibles. Sí, es la eterna lucha entre devs y PMs, pero vinculado a lo que ya hablamos: cuanto más completo y cerrado está el diseño, más precisa deberá ser la estimación de los devs para ayudarnos a tener el roadmap lo más fiel posible a cómo será el proyecto.

Ojo 👀, las estimaciones justamente son estimaciones, y es muy común que nos desviemos del roadmap inicial. Lo importante es que ese desvío no sea uno que nos perjudique y que los podamos contemplar con antelación.

Algunas recomendaciones generales 📌

• Ser PM de un equipo de desarrollo es la mejor oportunidad para aprender, ¡aprovechala! Si trabajás de forma presencial, sentarte al lado de los devs y preguntarle las veces que necesites las cosas, es el mejor camino: “¿Esto porqué es así?”, “¿Y acá por qué decidiste esto?”. Si trabajás de forma remota, es cuestión de ponerse de acuerdo para tener algunos encuentros y poder aprovechar el espacio. Mi consejo es: ¡no dudes en preguntar! 
  
• Nuestro rol es para especificar claramente el objetivo de la tarea y los plazos, y que la toma de decisiones tecnológicas queden a cargo del equipo de desarrolladores (siempre que sea posible, a veces no podemos decidir mucho). No se trata de decir “necesito esta feature hecha de esta forma con vue.js”. Es más motivador para el equipo y posiblemente ayude al rendimiento saber que tienen voz y voto en las herramientas y los lenguajes con los que van a trabajar 🙌
  
• ¡No tengas miedo a los cambios! Hay que intentar mantenerse flexible y siempre pedirle input y feedback a los devs sobre lo que está pasando. Aunque tener un plan es importante, tenemos que mantenernos flexibles para aceptar imprevistos. Y no solo debemos aceptarlos, sino esperar que pasen ✨. Nadie mejor que el equipo dev para ayudarte a encarar un plan con estos cambios.
  
• Pushear el testing y el peer review 🔎. Al ser PMs, no siempre tenemos tanto conocimiento técnico. Por eso, es importante confiar en el equipo para que sean ellos quienes hagan tests de lo que desarrollaron, previo a considerarlo listo. Lo mismo pasa con la corrección entre pares. 
  
• Evitemos reuniones que no tienen agenda o un objetivo concreto. Debemos dejar que el equipo tenga tiempo para concentrarse y trabajar en el proyecto.
  
• ¡Todo se puede hacer! 💡 Debemos pedirles a los devs soluciones o propuestas cuando algo no puede hacerse tal cual como se diseñó, pero siempre podemos darle la vuelta.
  
• Siempre contemplar un escenario ideal y un escenario pesimista. Nunca sabes todo lo que puede llegar a pasar en el transcurso del proyecto que hará que se retrasen los tiempos ideales. ¡Contemplalo! Y más importante aún: validalo con tu equipo 🙌
  
• Por último, no nos olvidemos del scope. Es un plus poder hablar con los devs y el equipo sobre cosas que después hacen que el scope inicial se vaya por las nubes ☁️: integraciones, analytics, performance, etc, etc, etc. 
  
  

En conclusión

Como PMs, debemos atrevernos a gestionar proyectos de desarrollo, no nos debe dar miedo. Aprenderemos mucho de nuestro equipo y el proceso 😉

Si son proyectos que aún te cuesta gestionar o sos dev y querés dejarme tus comentarios, escribime por LinkedIn.  Y para animarte, te dejo algunas frases para inspirarte:

“Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

— Samuel Beckett

"Talent wins games, but teamwork and intelligence wins championships”

— Michael Jordan

“If you're not embarrassed by the first version of your product, you've launched too late” 

— Reid Hoffman