El riesgo de convertirse en una factoría de software sin serlo

Esto que voy a comentar es muy subjetivo, ya que depende del sector de mercado en el que se mueva una empresa y del tipo de producto que venda o desarrolle.

Lo ideal en una empresa que vende un producto, o varios productos, es que pueda tener los recursos y el tiempo para poder implementar metodologías ágiles para la producción de los mismos y establecer de forma extricta lo que tiene que hacer cada uno de los departamentos.

Con "establecer de forma extricta lo que tiene que hacer cada uno de los departamentos" me refiero a que debe existir interoperabilidad entre ellos, pero cada uno debe centrarse en su trabajo y no crear interferencias en el trabajo del otro.

Si existen interferencias no se puede aplicar ningún tipo de metodología para el desarrollo ya que los equipos de cada uno de los departamentos nunca podrán estar centrados en su proyecto o en su producto.

La estructura departamental debe estar enfocada a cada sección de producto y establecer sus límites, por ejemplo, tres básicos:

HelpDesk
Mantenimiento
Desarrollo

HelpDesk interactua con Mantenimiento (forzosamente), Mantenimiento podría interactúar con Desarrollo, pero de forma puntual (mejoras, sugerencias... etc) ya que si Mantenimiento interfiere con Desarrollo, el ser de Mantenimiento deja de tener sentido y por supuesto, el de Desarrollo también.

En segundo lugar, los equipos de desarrollo deberían abordar los proyectos planificados según importancia y las fechas de inicio y final de los mismos se deberían establecer teniendo en cuenta la carga de proyectos de cada uno de los equipos.

Un equipo de desarrollo no puede abordar mas de un proyecto simultáneamente ya que la lógica me dice que es contraproducente con la implementación de metodologías ágiles. Se debería gestionar la pila de proyectos con el modelo FIFO (First In, First Out) y dejar que el equipo de desarrollo esté centrado y pueda dedicar el tiempo necesario para cada punto durante el trabajo en el proyecto asignado.

Si se pretendiese abordar mas de un proyecto simultáneamente, se tendrían que crear varios equipos para los distintos proyectos y poder así desarrollar proyectos en paralelo, obviamente, cada uno de los recursos de los distintos equipos debería pertenecer a un solo equipo, ninguno de los recursos de cada equipo podría interferir en un recurso de otro. ¿Qué implica éste modelo?, respuesta, duplicar todos los recursos.

Si abordas muchos proyectos con tan solo un equipo de desarrolloy no amplias recursos, que sepas que has adoptado un modelo de desarrollo aproximado a lo que debería ser el de una factoría de software, sin serlo, por tanto perderás tiempo, dinero y calidad en tu producto y se darán dos situaciones comunes con lo que comentaba Sergio Montoro en su artículo "El milagro de los recursos":

a) Tu recurso se pasará todo el día más quemado que la pipa de un indio diciendo que no le da tiempo de hacer todo lo que le han mandado (lo que de deduce en menor calidad de producto).

b) Los plazos se alargarán y el proyecto se torcerá.

Es el problema recurrente del tratamiento de los recursos, desafortundamente el modelo ideal nunca o casi nunca se ajusta con el modelo ideal real.