En resumen, en el "proceso" de desarrollo de software lo que se ha de hacer es gestionar a las personas, justamente lo que predica el XP y otros mtodos giles.

SoftInSpain

Totalmente de acuerdo, los procesos no sirven en el desarrollo de soft para garantizar la realización de buenos productos, sencillamente porque el proceso de construcción del software no es un proceso sistematico y predecible sino que es una actividad con un altisimo componente creativo. El buen software lo hacen los buenos desarrolladores y las buenas empresas son las que conscientes de esto son capaces de atraer y mantener buenos desarrolladores.

El problema de usar metaforas de otros procesos industriales en el software es que no sirven porque sencillamente son cosas diferentes, como decia Martin Fowler en su famoso articulo the new methodology, la metafora de diseño/construcción que desde hace tiempo se viene aplicando al desarrollo de software es un completo error.

De todos modos, tampoco creo que la idea de los procesos sea del todo desdeñable y se tenga que trabajar en un entorno caotico. Para que se pueda producir buen software el ingrediente indespensable esta claro que es el talento, pero esto es condición necesaria pero no suficiente, también hace falta tener un entorno de trabajo donde se apliquen una serie de buenas practicas y se sigan unos determinados procesos (sobretodo en cuanto a SCM y QA). La dificultad creo yo esta en definir estos procesos de modo que sirvan para canalizar el talento pero sin llegar ha ahogarlo.

De nuevo, muchas gracias Juan por este contenido. La gestión de procesos basados en el conocimiento es un tema que me interesa muchísimo.

Yo creo que el problema principal es un problema de continuidad. Los procesos industriales (homogéneos, repetitivos, etc...) se pueden describir de forma prescriptiva hasta un nivel de detalle que incluya instrucciones de trabajo muy concretas. El problema surge cuando se intentan describir procesos basados en el conocimiento de esa forma.

Me permito incluir un enlace a un artículo (en inglés) en el que hago unas reflexiones sobre este tipo de procesos.

Me gusta mucho la idea de añadir el elemento Entorno a la ecuación tradicional procesos-tecnología-personas.

Lucas Rodríguez Cervera

Gracias por vuestros comentarios.
Coincido contigo, Lucas, en el interés por los procesos basados en el conocimiento, y sin falta voy a leer tu artículo, que no conocía.
Como apuntas, hay diferencias con los procesos industriales. Al igual que considero que el 4º elemento (entorno) hay que incluirlo en la ecuación cuando se trata de proceosos del conocimiento, también creo que hay un concepto que no se tiene en cuenta y que no se explicar muy bien así de pronto... algo así como un "coeficiente de permeabilidad del proceso". Permeabilidad a la absorción de conocimiento. Creo que los procesos y la tecnología son "contenedores" de conocimiento, de "Know How". Esponjas capaces de absorber conocimiento.
Esto se entroncaría en la línea de conocimiento tácito y explícito de Nonaka... y buf! bla bla...

Es una línea detrás de la que llevo ya algún tiempo, y que creo va tomando forma. Si Cronos es benévolo :-) un día intento postear algo con más coherencia.

Un saludo.
Juan Palacio.

Muy buenas reflexiones que hacen pensar.

Ahora bien, el problema de hoy día en la producción de software de calidad es que hay que separar todo el proceso tecnologico y de abstracción asociados de los clientes finales, escondiendo la complejidad para poder vender las ideas finales de forma simple. Es decir no digas ni una sola sigla o tu cliente se dormira sin comprender de que le estás hablando.

Esto hace que el cliente final no entienda la dificultad y complejidad asociada y por tanto los precios asociados a un producto , proyecto o desarrollo. Lo que lleva a tener que ir siempre con prisar y corriendo y sin poder realizar un software de calidad.

No se si esto será así en el resto de paises pero lo que si que está claro es que "Spain is different".

A mi me parece una farza, una completa cagada

Lamento que no compartamos la misma forma de ver el desarrollo de software; pero sobre todo lamento no conocer tu punto de vista para poder considerar y charlar de las diferencias.
Sin duda las crticas y discrepancias son tan de agradecer o ms que las felicitaciones. Cuestionan y enriquecen y son base para di�logo y discusin; pero por favor que sean constructivas, no simples exabruptos, motivados a saber por qu.

Un saludo.

Juan Palacio.

Interesante lo del "coeficiente de permeabilidad" del proceso. Lo que pasa es que en los procesos basados en el conocimiento, gran parte del conocimiento que se aplica en su ejecucin es de tipo prctico no articulabe (cogiendo prestado este concepto del mundo de la econom㡭a, Jess Huerta de Soto lo explica muy bien).

Sera como intentar describir el proceso de montar en bicicleta. Se podr꭭an definir los pasos del proceso (monta en la bicicleta, apoya un pie en el suelo y otro en un pedal, carga tu peso en el pie del pedal, etc...) pero al final del da no puedes esperar que lguien sin experiencia, sin ese conocimiento pr�ctico no articulable pueda montar en bicicleta.

As el concepto de permeabilidad del proceso estara en relaci�n con las posibilidades de articular dicho conocimiento en la medida de lo posible.

Efectivamente "permeeabilidad" indicaría la cantidad de conocimiento que se puede articular, que es explicitable o que se puede depositar en el proceso (y la tecnología).

De forma esquemática, las bases sobre las que intento armar algo con sentido (no se si un castillo de naipes) son:

1.- Para realizar un trabajo el conocimiento necesario y suficiente debe estar, en la forma que sea, en las variables Personas - Proceso - Tecnología.
2.- El conocimiento residente en el proceso y la tecnología (conocimiento explítico) es valor, Know-How, asentado en bienes tangibles de la empresa.
3.- El conocimiento residente en las personas (conocimiento tácito) es valor, Know-how asentado en la plantilla de la empresa.

El "coeficiente de permeabilidad" para un trabajo dado, (con unos parámetros de calidad necesarios) sería un indicador de un sistema específico de Personas-Proceso-Tecnología; e indicaría qué porcentaje de conocimiento puede ponerse en el Proceso y la Tecnología.

Creo que dependería tanto:
1.- Del tipo de trabajo. Como apuntas, algunos como el necesario para montar en bicicleta, o para catar vinos lo ponen muy difícil si se les quiere explicitar (o imposible).
2.- Del proceso y la tecnología empleados. Ej: para el trabajo "hacer crema catalana" el coeficiente de permeabilidad al conocimiento del sistema será muy bajo, si Proceso-Tecnología es una espumadera. Será mayor si contamos con una batidora, y si estuviera formado por una Thermomix y su manual de recetas, hasta yo sería capaz de hacer la crema catalana con parámetros de calidad muy altos.

En fin, lo dicho, este tema me tira mucho.

Juan Palacio.

Muy gráfico el ejemplo el de la crema catalana, la espumadera y la termomix.

El tema de la permeabilidad me lleva de nuevo al cuarto elemento que comentabas que hay que tener en cuenta además de proceso-tecnología-personas: el entorno. El entorno es un factor fundamental (en especial la cultura de la organización en particular en la forma de gestionar el conocimiento), ya que el mismo tiene un papel fundamental en el traspaso de ese conocimiento de las personas a los procesos y tecnología.

Lucas Rodríguez Cervera

PD: El comentario anterior era mio, se me había olvidado firmarlo

Más de un manager y gerente de empresas de software necesitaría leer esto!
Mientras no se acepte que el desarrollo de software no es una ingeniería más, seguiremos metidos en la crisis de software de mala calidad, entregado tarde y con baja satisfacción de todo el mundo (tanto de los clientes como de los propios desarrolladores)

Enhorabuena por el artículo

Saludos

JM