Modelos de Software Factory. (primera parte)


Durante una serie de artículos voy a reflexionar sobre los tipos de "Fábrica de Software" que podemos encontrar así como sus modelos de trabajo.

El primer objetivo de una Software Factory es saber a que se dedica. La respuesta sencilla, es la inmediata, a desarrollar SW pero evidentemente no es tan simple.

En función del tipo de SW, las Tecnologías y las Metodologías elegidas debemos generar el modelo de negocio. El modelo de negocio debe responder a tres "sencillas" preguntas:

  • ¿Que vendemos?
  • ¿A quien se lo vendemos?
  • ¿A cuento lo vendemos para ganar dinero?

¿ Que vendemos?


A este pregunta suele contestar cualquier MBA llegado a un "Fábrica de Software", está muy claro vendemos Horas, no vendemos productos. Estoy de acuerdo, siempre y cuando no vendamos productos SW, que queremos vender n veces. En ese caso no podemos cobrar a un cliente el número de horas totales sino marcar un número de ventas para amortizar los costes. Pero esa es otra historia.

En este articulo vamos a a hablar del modelo "Fábrica de Software" como aquel que proporciona un servicio relacionado con el SW que se tarifica en horas con un precio hora asociado.

El primer error a cometer, es intentar vender el modelo como un Bodyshopping, sobre el cual no queremos tener ninguna responsabilidad. Bien, se puede dar el caso pero entonces que vengan los JP del cliente ha dirigirlo, porque lo que va a pasar es que no van a estar satisfechos con lo que hacen, y al final se acaba aportando al JP, los Sistemas, y personas no dimensionadas y todo gratis. El Bodyshopping es lo que es, si lo hacemos hagamoslo bien.

Vamos a ver los modelos de "Fábrica de Software" que podemos tener, evidentemente son compatibles entre si, pero debemos diferenciarlos, para saber cual es nuestro objetivo de venta y nuestro precio de salida.


A. Desarrollo de Proyectos.

En este modelo la "Fábrica de Software" es la encargada de realizar un desarrollo concreto, normalmente independiente de otras aplicaciones pudiendo basarse en arquitecturas del cliente o las propias.

En el modelo clásico de Desarrollo de Proyectos, el cliente realiza la especificación funcional (Análisis) y la "Fábrica de Software" todo el desarrollo tecnológico del proyecto, trabajando conjuntamente con el cliente en la fase de validación.

Puntos a cerrar en el proceso de lanzamiento/transición con el cliente a nivel operativo:

  • Política de precios / hora.
  • Acuerdos por volumen, continuidad.
  • Acuerdos respecto a picos y valles.
  • Garantía.
  • Productividad.
  • Política de Facturación
  • Acuerdos de nivel de Servicio y penalizaciones.
  • Condiciones de salida y cierre.
  • Gestión de riesgos (a nivel interno).

Puntos a clave cerrar en el proceso de lanzamiento/transición con el cliente a nivel de ingeniería:
  • Estimadores del proyecto.
  • Formación del equipo en arquitectura cliente.
  • Modelo de Análisis.
  • Modelo de Validación.
  • Modelo de Gestión del Cambio.
  • Plan de Gestión de la Configuración.

El buen cierre o acuerdo en los puntos anteriores minimiza los riesgos y encauza hacia el éxito, la indefinición acerca al beneficio 0 o perdidas.

Evidentemente existen el resto de tareas habituales (Planificación, Riesgos, Dotación de personal, etc) pero ya las enmarcamos dentro del proyecto y las anteriores son previas.

En función de los puntos anteriores o de las previsiones que tengamos de los mismos junto al estudio previo debemos calcular las previsiones de costes, en cuanto a recursos humanos (numero y perfiles necesarios), recursos HW y costes adicionales (desplazamientos, coste de lanzamiento, formación) etc. Tras este cálculo debemos aplicar el % de beneficio que queremos conseguir para el proyecto.

Consideraciones:

- Un proyecto de esta tipología puede estar enmarcado dentro de otros modelos de relación más amplios que se hayan adquirido por un determinado cliente.

- Las tecnologías típicas en que nos encontramos este modelo son, Java y MS .net.

- Son proyectos con más riesgo por lo general que un mantenimiento y se debe marcar % de beneficio más alto o con una previsión de sobrecostes más alta.

- Cada proyecto es diferente al anterior, no hay aumentos de productividad significativos en los grupos de recursos asignados a los mismos.

- El % de Seniors es más alto que en proyectos de mantenimiento. Por tanto son proyectos con mayor coste.

En próximos articulos hablaremos de Mantenimientos (AM), BPO's, Bodyshoping, Test Factory`s y alguno más..