En una entrada anterior hablé de dónde pensaba yo que estaba el origen de la tirantez que siempre hay entre la parte comercial y la parte de IT. Yo creo que es por la diferencia de velocidad entre pensar qué hacer y hacerlo. Pero también comenté que hablaría más sobre esa reflexión.
Creo que la única solución buena es que IT gane velocidad. Eso parece complicado pero el beneficio es para toda la empresa por que si IT puede responder con más rapidez las peticiones que llegan desde la parte comercial, más proyectos se podrán ejecutar y al final más dinámica de venta podrá tener la empresa. Muy bien, hasta ahí supongo que muchos estáis de acuerdo, pero... ¿cómo?.
Desde mi punto de vista la única manera de conseguirlo es con un desarrollo orientado a la reutilización.
Casi siempre se entiende la metodología como una manera de gestionar un proyecto que resuelve un problema de ciertas características. Pero lo primero que hay que hacer es entender la metodología como una herramienta para sistematizar el conocimiento en toda la empresa.
A partir de aquí, IT debe esforzarse por modelar el negocio de la empresa en componentes de software. Componentes que después se reutilizarán y que algunos deberán modificarse o actualizarse pero que será reflejo de la evolución normal en la vida del negocio. Por decirlo de otra manera, un cliente es un cliente pero seguramente un cliente de un curso de inglés será distinto a un cliente de una fábrica de electrodomésticos.
Pero claro, modelar es todo un trabajo de análisis que necesita un tiempo y una calma que en la vida normal de una empresa normal cuesta encontrar.
Entonces, creo que la solución es intentar ir enriqueciendo la librería de componentes de la empresa con los proyectos que surjan, de manera que con el tiempo y los proyectos se vaya construyendo esta librería. Si por ejemplo en el proyecto que estoy analizando ahora de los clientes sólo vamos a tratar los aspectos contables por ejemplo, centraré mi análisis en estas características dejando las menos relacionadas para futuros proyectos.
Cuándo acabe el proyecto colocaré en mi librería de objetos lo obtenido hasta ese momento debidamente preparado para que en el próximo proyecto que deba tratar el mismo objeto me cueste lo mínimo posible el reemprender el tema. A su vez cuándo comience el siguiente proyecto deberé analizar mi librería para ver qué puedo aprovechar y cuánto me supone.
Si esto se realiza correctamente, los tiempos de desarrollo tienen que disminuir por fuerza con el tiempo y los proyectos. Pero a su vez es necesario una metodología de trabajo robusta, que realmente sea respetada por toda la companía y que esté orientada a 'hacer el próximo desarrollo más barato'.
Como resumen, creo que en cualquier proyecto existen dos etapas que muy poca veces se contemplan que son:
1) Análisis de la librería de objetos para ver qué tengo, qué puedo hacer con ello y qué necesito hacer para enriquecerlo
2) Una vez finalizado el proyecto hay que 'recoger', hay que reincorporar a la librería de objetos todo lo que se haya hecho en el proyecto.
Con el tiempo en los proyectos deberé contar: los tiempos de desarrollo de nuevos componentes, los tiempos de modificación de componentes existentes, y los tiempos ahorrados por anteriores desarrollos. Esas son tres buenas métricas para poder observar con el tiempo si vamos en la buena dirección o no.
Un saludo
