Las visitas de hoy a la página: 45
El otro día me aptecía postear, preguntar a la gente sobre las Fábricas de Software. Tenía y sigo teniendo, mucho interés en el tema. Lo que el otro día no tenía era mucho tiempo para postear y creo que, por los comentarios que he recibido, no he conseguido explicarme muy bien. A ver si hoy consigo explicarme un poco mejor...
Desde mi punto de vista, esto de las "Fábricas de Software" solamente se aplicaría al desarrollo de productos (es decir, aplicaciones no desarrolladas para un cliente concreto, mas bien para ser vendidas varias veces a cuantos mas clientes mejor).
Logicamente, cualquier equipo (o empresa, o lo que sea) que se dedique a hacer proyectos "ad-hoc" (o llave en mano) nunca va a tener el más minimo interés en montar semejante infraestructura. Así, de mano, se me ocurren varias razones:
- Los proyectos viven del corto plazo. Un proyecto con un horizonte temporal de mas de un año es un proyecto, como mínimo, grande. Para un producto un horizonte temporal de un año es una autentica ruina.
- Los proyectos se venden "a priori", antes de ser desarrollados. Una vez vendidos, lo mas importante es conseguir el mayor margen posible. Esto implica contratar personal barato (baja cualificación, poca experiencia, etc.). Además, como normalmente hay un "pliego de condiciones" (o similar), lo importante es tirarse a cubrir la funcionalidad especificada, sin centrarse en florituras, ni preocuparse por la estabilidad del desarrollo. Vamos, lo que llaman "sin perder el tiempo".
- El mantenimiento también es muy diferente. Al final, en un proyecto, los usuarios finales son casi siempre los mismos y usan el software siempre para las mismas tareas y siempre de igual forma. Las funcionalidades están muy acotadas y los fallos también. Y en el peor de los casos, siempre se pueden ir parcheando los fallos que vayan apareciendo sobre la marcha.
Bueno, entonces pongamos que nos centramos en el desarrollo de productos software. Vale, acepto que un desarrollo de software no es igual que el de otros productos como ruedas, botellas o televisores, pero ¿tanto?.
Las empresas que yo conozco aplican téncias de gestion de proyectos al desarrollo de productos. En el post del otro día, simplemente me preguntaba si habrá alguna empresa que aplique técnicas de gestion de productos (productos en general) al desarrollo de productos software.
Alguien me dejo un comentario hablandome sobre RUP. Me parece muy interesante, pero no me estaba refiriendo a una metodología de desarrollo. Por ejemplo Scrum es una metodología que últimamente pega mucho y proviene del desarrollo de otro tipo de productos tencológicos (no especificamente software) y ahí si que conozco sitios donde se usa.
Me refería mas bien a la gestión en general del centro, de la supuesta "factory". Por ejemplo, en la definición de requisitos. ¿Es realmente necesario el baile de requisitos tipico de un proyecto de desarrollo de software al construir un producto?. O también la organización y la burocracia, la gestión de tiempos, la definición de protocolos.
Por ejemplo, hace poco estuve en un curso sobre gestión del conocimiento en las empresas y el profesor del curso en un momento habló sobre "protocolos de contingencia" (o algo así). Son una especie de pasos a seguir para los momentos de crisis. El ejemplo que nos puso era la caída de la energía eléctrica en una central nuclear.
¿Por qué las Software Factories no tienen "procedimientos de contingencia"? ¿Por que no hacemos simulacros para saber como reaccionar si en un momento critico se cae un sistema importante?. Es solo un ejemplo.
Otro ejemplo es la definición de requisitos. En cualquier industria, cuando se plantea la posibilidad de introducir una mejora (una nueva tecnología de inyección, un nuevo sabor, un nuevo material, etc.) a un producto, siempre se hacen un monton de estudios, prototipos, pruebas, etc. ¿Se hace esto cuando se plantea una nueva funcionalidad en un producto software?. Pero es que este tipo de pruebas no son solamente tecnicas, tambien se estudia desde el punto de vista del mercado, de la usabilidad, de la aceptación por parte de los clientes, etc.
Un ejemplo mas, la "automatización del proceso productivo". Nosotros tenemos ANT, Maven, Makefiles, etc. Algunos incluso son capaces de empaquetar todo el producto en un solo paso pero, ¿también distribuirlo, almacenarlo, clasificarlo?. Si un producto software tiene personalizaciones para clientes ¿tenemos automatizada la gestión de nuestro "almacen"?.
¿Cuantas empresas de desarrollo de productos software tienen un CRM para atender a sus clientes? ¿De las que lo tienen, cuantas explotan la información capturada para mejorar sus productos?
¿Existen en alguna empresa de desarrollo de productos personas que trabajan como ingenieros de pruebas (como en la industria automovilistica, aeronautica, etc.), ingenieros de procesos (como en la siderurgia) que trabajan estudiando y afinando los procesos internos de la "factory"?
No pretendo comparar una cadena de montaje con el hecho de "picar codigo", está claro que no es ni parecido. Estoy muy de acuerdo con el comentario que decia que el desarrollo era mas parecido a la fase de diseño de un producto. Pero no estoy para nada de acuerdo en que el diseño industrial (desde mi ignorancia siempre) es caotico. Existen un monton de ISOs, y otras normas internacionales que debe respetar, ademas de estandares de empresa.
¿Las empresas de desarrollo de productos software tienen estrictas normas de estilo de cara al desarrollo y a los componentes, arquitecturas, etc. que se pueden usar?. Las partes funcionalmente similares deberían de ser similares en cuanto a su implementación. Por ejemplo, en una fabrica de botellas, si los tapones tienen dos vueltas de rosca, cuando se diseñan nuevos tapones, o llevan dos vueltas de rosca igual que los anteriores, o hay alguna buena razón para lo contrario. Nunca suele ser por comodidad, gusto, dejadez o manía del diseñador.
Bueno, la verdad es que no se muy bien como funciona una industria de cualquier otra cosa que no sea software, y me gustaría saber si el desarrollo "industrial" de software es parecido en algun sitio. Porque mi experiencia me dice que si esto no se hace es porque en este negocio pesa demasiado el trabajo de consultoría o de desarrollo de proyectos a medida.