« agosto 2008
lunmarmiéjueviesábdom
    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
       
Hoy
XML

Blog::Navigation

Bookmarks::Blogroll

Bookmarks::Articulos

Blog::Referers

Las visitas de hoy a la página: 32

Powered by Roller Weblogger.
« Fabricas de Software | Main | Los salarios en el... »
20070707 sábado julio 07, 2007
Fabricas de Software (II)

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.

Comentarios:

En referencia a que el "diseño industrial sea caótico", mi comentario no iba en el sentido de que no haya normativas y estándares.

De lo que hablo es de que el proceso de investigación, desarrollo y diseño es, en el fondo, un proceso eminentemente creativo. Y en ese aspecto, vuelve a estar sujeto a circunstancias de la personalidad más que a normativas.

Por poner un ejemplo más claro, cuando en una empresa de componentes para la industria del automóvil, donde *hacen* cableados, limpiaparabrisas, asientos, mandos, salpicaderos, paneles, etc, surge la necesidad/oportunidad/deseo de crear un nuevo componente (por ejemplo, un nuevo tipo de limpiaparabrisas que limpie más superficie o lo que sea), en ese momento digo, entra en juego un proceso de creatividad e imaginación. También de investigación y de requerimientos que cumplir y, en última instancia, también de reglamentos y normativas.

Pero el proceso de creación y diseño no nace de unas normativas, nace de las ideas. Y ahí es donde entra en acción el proceso caótico. La investigación, las pruebas, las ocurrencias, las nuevas pruebas, los prototipos y más pruebas. Y sí, en todo eso hay una serie de procesos normativos que cumplir, por supuesto. Pero también hay un gran impulso puramente creativo.

La diferencia que yo quería señalar con los procesos de fabricación es que, en realidad, la mayor parte de normativas y procesos y regulaciones y planes que comentas se refieren casi siempre a los procesos de fabricación. Las optimizaciones, las contingencias, las planificaciones, estudios de logística, cálculos de tiempos y materiales... todo eso ocurre cuando realmente es una industria que fabrica algo tangible.

-----

Aún así, he recordado un sitio que quizá encaja un poco con algo cercano a lo que comentas. En una empresa en la que trabajé brevemente hace ya años, lo que me dieron el primer día fue la "guía de estilo". Y hay muchas empresas que tienen una guía de estilo, que define muchos detalles de los que señalas. Lo que ocurre es que en la realidad, en muy pocos sitios creen que tenga alguna ventaja obligar a cumplir una normativa estricta en lo que es un proceso intelectivo.

Enviado por Venkman en julio 08, 2007 a las 09:55 PM GMT-01:00 #

Esta bien que hayas vuelto a escribir algo..

Muchas veces lo hemos hablado y sabes que estoy contigo, las fabricas de software con procesos claramente definidos me parecen posibles.

Sin embargo a parte de los topicos "..nuestros jefes no tienen ni idea, son cortos de miras y son economistas.." existen otros factores:

1)Los procesos, es decir, lo que idealmente se querria modelar, definir e implantar no se conoce con exactitud y es, a dia de hoy, un trabajo en progreso que entre todos los del mundillo deberemos conseguir.

2)Las herramientas por las cuales podriamos automatizar e implantar estos procesos organizativos son relativamente nuevas, poco maduras y, lo que es peor, nos resultan parcialmente desconocidas requiriendo investigación (=1 tio= x horas=..=$$ pasta).

3)Ahora el topico, las organizaciones en sus puestos directivos no apuestan firmemente por un soft de calidad 10, prefieren un 7 en el bolsillo. Además, especialmente en España, en nuestro mercado nadie se ha hecho muchimillonario sobresaliendo en estos términos. El día que una empresa se haga de oro gracias a esta industrialización (y lo haría si existiese) el resto irá detrás.

En definitiva, la industrialización del desarrollo de software es posible, pero al igual que los primeros coches se hacian de forma manual las primeras factories son girigay de cojones donde la frase más escuchada es "quien coño ha subido esto que no compila??"

Enviado por ivo_es en julio 12, 2007 a las 12:55 PM GMT-01:00 #

Enviar un comentario:

Los comentarios han sido deshabilitados.
Copyright (C) 2003, Angel Retamar Arias