Algunas veces el CEO de una de las empresas donde trabajaba me comentaba:
– Oye Juan, tenemos una Prueba de Concepto (PoC) para un nuevo cliente y necesitamos que el producto tenga implementada la funcionalidad X. Cuándo la podemos tener?
Yo me reunía con mi equipo para darme tener una estimación y se la pasaba a mi jefe:
– Para hacer la funcionalidad X necesitamos 3 semanas. Así que acabamos este Sprint y lo hacemos para el siguiente
Trabajabamos con Scrum, y los sprints eran de 4 semanas de desarrollo, que normalmente se alargaba un par de semanas por el testing. La fecha de entrega de la funcionalidad X iba de 3 a 7 semanas.
– Mira Juan -me decía el CEO- la Poc es para dentro de dos semanas y es un cliente importante. Esto tiene la mayor prioridad, haz lo que tengas que hacer. Tenemos que ser más flexibles

En estos casos para afrontar este problema lo que hacíamos era sacar del equipo de Scrum al desarrollador que iba a programar dicha funcionalidad. Sus ciclos de desarrollo y alcance dependía directamente de las necesidades de la PoC. Esto ocasionaba que parte del sprint perdía sentido; o bien la funcionalidad en la que estaba trabajando el desarrollador se postponía o bien se reajustaba el trabajo quedando fuera parte de la funcionalidad acordada.

El desarrollo para la PoC tenía ciertos problemas: normalmente, por las prisas no tenía la calidad suficiente, la interacción con el usuario estaba poco trabajada, se generaba una release especial para dicha PoC menos probada e integrada. Como problema adicional, muchas veces ese desarrollo se daba por bueno por lo que era incluído en el producto y disponible para otros clientes, sin tener la calidad suficiente lo que producía problemas posteriores (la famosa deuda técnica). Hay que tener en cuenta que para acortar los plazos o recortas el alcance (usabilidad, funcionalidad) o calidad.

Sin embargo entendemos que este tipo de prácticas, desde el punto de vista de negocio son necesarias: una pyme vive de sus clientes y cuando surge una posibilidad comercial tiene que ajustar sus equipos para transformarla en dinero entrante en caja, que es de lo que vivimos.

Desde un punto de vista de desarrollo de software el gran error que se cometía era que el trabajo hecho para la PoC se deba por bueno. Tendríamos que haber revisado desde cero todos esos desarrollos, revisar la calidad, y hacer el refactor que fuera necesario; sin embargo desde el punto de vista de negocio era invertir dos veces en lo mismo, les costaba ver que a veces valía más la pena empezar de cero que aprovechar el desarrollo realizado.