¿Te has visto en algún proyecto con un deadline muy ajustado? ¿Te has visto obligado a dejar el testing de lado con tal de cumplir los plazos de entrega? No hablemos ya de la calidad del código…
En algún momento u otro, todos los que trabajamos en el sector consultoría nos hemos visto en alguna de las situaciones anteriores, pero… ¿qué nos lleva a esas situaciones?
En los siguientes apartados voy a exponer un caso práctico de lo que sería un proyecto en el que se dan los factores anteriormente expuestos, que aun no siendo un ejemplo real que me haya pasado a mi, sí que lo he experimentado en parte, por lo que me siempre me pondré en el peor escenario posible. Pero seguro que más de uno podrá sentirse identificado….
CONTEXTO
Acabas de aterrizar en un proyecto, y ya sea nuevo o lleve un tiempo en desarrollo, tu responsable te explica brevemente en qué consiste, para posteriormente detallar el estado actual: cuánto desarrollo se ha hecho, cuánto queda por hacer, los plazos a cumplir… Te sientas junto a tus compañeros, hablas con ellos, te cuentan de forma más personal y subjetiva el estado del proyecto y antes de que acabe el día es posible que estés ciertamente desanimado. Esto se debe a que al evaluar el trabajo realizado durante el tiempo de vida del proyecto, y viendo lo que queda, no te salen las cuentas.
CAUSAS
Hay muchos factores que pueden llevar a esta situación, voy a comentar alguno:
- El comercial de turno, con tal de conseguir el proyecto frente a sus competidores, ha reducido tiempo y costes, lo cual deriva en una reducción considerable de la calidad (seguro que conocéis el famoso triángulo del proyecto, o “triángulo de hierro”).
- El equipo, por falta de guía, o bien porque este guía no ha hecho del todo bien su trabajo, se pone a desarrollar como loco.
- El comercial he hecho un buen trabajo, el equipo va a dedicar un tiempo al análisis del proyecto, pero algún jefe mete prisa para, por ejemplo, intentar acabar el proyecto antes de fecha y posicionarse mejor de cara a futuros proyectos con ese cliente.
¿SOLUCIONES?
Desgraciadamente no voy a daros una mágica solución con la que se acaben todos estos problemas. De hecho, tan solo voy a entrar a valorar posibles soluciones respecto a lo que puede hacer el equipo.
Antiguamente los proyectos se regían mediante metodologías pesadas, como la cascada, en las que se invertía gran cantidad de tiempo en el análisis del proyecto, de forma que a la hora de desarrollar, todo estaba bien especificado y acotado. En mi no muy larga carrera no he participado en ningún proyecto así (afortunadamente), en los que te pasas mucho tiempo sin desarrollar, que al final es lo que nos gusta, y no adquieres una visión global del proyecto, ya que tus tareas siempre han estado perfectamente acotadas.
Nacieron las tecnologías ágiles, como SCRUM, en las que se vive más al día, entregando producto con valor al final de cada sprint, y permitiendo a los desarrolladores poder picar código en los primeros días.
Ahora bien… ¡No hay que volverse loco!
Como he comentado antes, bien por falta de un guía o por falta de consenso en el equipo, se ha empezado el desarrollo demasiado deprisa. Por tanto, mi “solución” es algo tan simple como «equipo, vamos a dedicar un poco de tiempo a pensar cómo vamos a hacer las cosas». Puede parecer una tontería, pero a veces lo único necesario es plantearlo y que todos lo tengamos en la cabeza. A veces somos nosotros mismos los que nos agobiamos y nos auto imponemos las prisas con tal de justificar el trabajo diario, o el de sprint, ya que muchas veces pensamos que “hacer algo” es “entregar algo de valor, visible, tangible, etc.” y no asumimos que el cierre de sprint pueda ser algo del estilo «no hemos entregado nada, pero hemos asentado unas buenas bases con las que empezar a trabajar».
Esto evita que en un futuro tengas que decir al cierre de sprint, con la cabeza gacha, que el trabajo realizado ha sido de refactoring, lo que algún cliente pueda traducir como «habéis trabajado para que el producto sea exactamente el mismo». (¡OJO! no estoy diciendo que el refactor no sea una herramienta útil con la que encauzar las buenas prácticas cuando nos hemos salido del buen camino, pero en su justa medida).
Ahora bien (otra vez)… ¡No hay que volverse loco con sobre analizar todo! Si el equipo entero dedica su tiempo a sentarse a analizar y debatir cada micro tarea, nunca avanzamos.
CONCLUSIÓN
Las prisas no son buenas, todos lo sabemos y aún así seguimos cayendo en las mismas trampas, por lo que es tarea de todos, incluidos el Product Owner, responsable técnico, etc., el tratar de generar un ambiente muy comunicativo, donde poder sentar bien las bases de nuestro proyecto y, finalmente, estar orgullosos del trabajo realizado.