A lo largo de nuestra trayectoria como desarrolladores pasamos por todo tipo de proyectos, y creemos que los que más nos costó llevar fueron los que tuvieron problemas relacionados a la gestión. Hoy les traemos consejos basados en nuestros aprendizajes con proyectos de este tipo para que puedan reconocer y ayudar a solucionar problemas de gestión comunes.

¿Llega un requerimiento urgente? Plantear opciones, estimar y negociar 

Hay veces en las que el cliente pide funcionalidades o cambios y los quiere con la mayor de las urgencias. En ocasiones pueden ser cambios sencillos de realizar que no llevan más de unos minutos, sin embargo, otras veces la funcionalidad solicitada implica un desarrollo extenso.
Ante una situación así no debemos dejarnos llevar por la urgencia ni comprometernos a terminar desarrollos a las apuradas. Por una parte, hay probabilidades de que no lleguemos al plazo esperado por el cliente y su confianza se vea perjudicada o que el producto que entreguemos no tenga calidad y vuelva a futuro en forma de bugs.  
Antes de aceptar un cambio urgente, estimar qué es lo que hay que hacer, analizar los plazos que hay para entregarlo y tomar una decisión con el cliente, dejando siempre en claro cómo los cambios afectan a lo que ya estaba planificado. Si nuestra estimación nos indica que no vamos a llegar con lo que se está necesitando debemos plantear  alternativas y negociar. Por ejemplo, sólo entregar la parte más valiosa de los cambios, resolver la parte más compleja y que lo más simple se resuelva más adelante, etc. 

Horas extras no solucionan problemas de proyecto 

¿Cuántas veces terminamos saturados trabajando hasta tarde para terminar de cerrar una historia? O ¿Cuántas veces les pidieron por favor de terminar X tarea para hoy? 
Debemos evitar martirizarnos para terminar con una funcionalidad, ya que probablemente cometamos más errores, perdamos motivación y al sumarnos a la urgencia perdamos de vista el rumbo del proyecto. Antes de quedarnos haciendo horas extras, podemos replantearnos: ¿La estimación que realizamos fue la correcta? ¿Venimos midiendo correctamente el progreso del proyecto? ¿Nos comunicamos bien con el cliente? Si no queremos volver a quedarnos hasta tarde, debemos analizar estos problemas y corregirlos.

Sin feedback temprano del cliente, habrá doble trabajo

Si por ejemplo estuviéramos realizando el frontend de un sitio durante un mes, y el cliente recién ve el producto al final, posiblemente haya muchos cambios para hacer, y cuesten mucho más que si se lo mostráramos una vez por semana. Cuanto más tarde descubramos un cambio, tendrá impacto en más lugares de nuestra aplicación y habrá que hacer un retrabajo cada vez más extenso. Al final nuestro proyecto sólo será un éxito si es lo que el cliente quería, y debemos asegurarnos de eso. Scrum, por ejemplo, resuelve esto mediante las Sprint Reviews.

Consensuar estándares de calidad antes de empezar 

Es frustrante dar por terminado un desarrollo y que tiempo después cuando lo ve el cliente tengamos que rehacerlo porque no cumple sus expectativas. Por eso antes de comenzar a desarrollar debemos ponernos de acuerdo con el cliente para consensuar estándares de calidad. Tenerlos agiliza el desarrollo y garantiza una calidad de producto validada por el cliente, también establece claramente cuándo se da por terminado un desarrollo, y evita desacuerdos luego de terminada una funcionalidad. Scrum resuelve esto mediante la Definition of Done.

Establecer un canal de comunicación inmediata y horarios de disponibilidad 

Una mala comunicación puede hacer que tu proyecto fracase estrepitosamente, por lo que es fundamental tener definidos los lugares por los cuales nos vamos a comunicar y el horario en el que vamos a estar desde el inicio del proyecto. La comunicación por email tiene algunos problemas: a veces se acumulan muchos emails de asuntos distintos, a veces no tienen respuesta alguna, a veces se envían sólo a ciertas personas y las demás no se enteran, etc.  

En nuestro caso nos ha servido más la comunicación por grupo de chat (Discord, Whatsapp, etc) ya que sirve para resolver dudas rápidas que surgen en el momento y también para una comunicación más cercana e informal que mejora la confianza. 

Mantener la calma 

No caigamos en la tentación de estresarnos cuando las cosas no están yendo como nos gustaría o cuando nos piden cambios urgentes. Sumarnos al apuro de otros o generarlo es perjudicial para el equipo y para el proyecto. Las decisiones que podemos llegar a tomar bajo este estado van a ser poco prudentes y terminarán perjudicándonos. Estar tranquilos nos ayuda a ver mejor el panorama, poder barajar una mayor cantidad de opciones para resolver cada tema y conservar la paz en nuestras relaciones. 

Usar herramientas de trackeo de progreso 

Trabajar en un proyecto en el que no sabemos qué tan lejos estamos de terminar puede ser desesperante tanto para nosotros como para el cliente, y no tener esta información nos quita la posibilidad de actuar con previsión. Por suerte existen herramientas como los BurnDown chart y Trello que nos sirven para plasmar el estado actual del proyecto para que lo vea todo el equipo y, a la hora de realizar un cambio en la planificación, tener un marco de referencia común. 

Usá control de versiones 

Cuando hay muchas personas trabajando en el mismo código, pueden surgir muchos problemas. Puede que sobreescribamos cambios que hizo otro, o que hayamos cometido algún error o hecho algún experimento sobre el código y no podamos volver atrás. Una herramienta conocida para resolver esto es git, y creemos que es indispensable para comenzar un proyecto. 

Si hay varios equipos trabajando en lo mismo, que se hablen diariamente. 

Alguna vez nos ha pasado de trabajar con otro equipo y no hablar por varios días, sólo para al final enterarnos que terminamos resolviendo los mismos problemas que ellos pero de otra manera (tardando más y generando código redundante), o que tomamos tareas que ya no hacía falta hacer (trabajo que se perdió). Por eso es importante una comunicación fluida con los demás equipos para evitar estos problemas. Scrum resuelve esto mediante el Daily Scrum. 

Evitar las islas de conocimiento 

A veces en un proyecto hay una persona que sostiene todo, y el día que se vaya de vacaciones, sabemos que la empresa va a fundir. Esto es porque esa persona es una isla de conocimiento, y nadie más sabe hacer lo que esta persona sabe. Es importante que los miembros del equipo compartan todos sus conocimientos para que cualquiera pueda seguir con cualquier tarea y en caso de enfermedad, vacaciones o infortunios el proyecto siga tranquilamente. También servirá para dar lugar al desarrollo profesional de cada integrante de tu equipo y aumentará la confianza que se tienen entre sí. 

Estos consejos son en base a experiencias que tuvimos que nos han enseñado el valor de marcos de trabajo como Scrum y del conjunto de herramientas ágiles que existen a la hora de llevar proyectos y esperamos que los ayuden en los proyectos futuros que lleven a cabo.