En ocasiones, durante el desarrollo de un proyecto de software, nos encontramos frente a la situación en la que para cumplir con un requisito debemos realizar trabajo adicional, que no estaba previsto inicialmente. En esta situación, el responsable del proyecto se ve frente a dos opciones: la primera es realizar el trabajo adicional, con la consecuente carga extra e impacto en la fecha de entrega; y la segunda simplemente descartar dicha funcionalidad y seguir adelante, conforme lo definido al inicio. Estas dos salidas, por supuesto, tienen un impacto frente al cliente.

Para las empresas, lo importante es generar rentabilidad y cumplir los compromisos con el cliente. El uso adecuado del tiempo es esencial para el logro de estos objetivos. Por esto, cuando un proyecto sufre alteraciones en el tiempo, por algún factor como el señalado, se impacta directamente en estos. El jefe de proyecto, frente a esta situación, debe tener estos aspectos en cuenta, de manera que pueda tomar la decisión más acertada que beneficie a la empresa.

En las últimas semanas, mientras trabajabamos para un proyecto, me vi frente a esta situación. El tema radicaba en que, bajo el tratamiento usual a este tipo de situaciones, debíamos modificar parte del código base de un proyecto de software libre para cumplir con el requerimiento del cliente. Luego de evaluar el problema, determinamos que esto implicaría destinar varias horas adicionales de desarrollo, no contempladas en el presupuesto de este proyecto.

La solución del problema salio de un enfoque que pasaba lejos de lo técnico. Determine que si el proceso, que implicaba registro y aprobación, se realizaba de manera distinta a la que el software propone, solo sería necesario modificar una parte del código, trabajo que no tomaría más de una hora. Este enfoque permitiría resolver el requerimiento del cliente y cumplir con los objetivos de la empresa. En lugar de pasar horas “hackeando” el software, “hackeamos” el proceso.