Christian A. Estay-Niculcar's research blog

Espacio de reflexión personal dedicado a la investigación aplicada cuando se vincula la ciencia proyectual con la disciplina informática, y se aplican al desarrollo de las personas y de la gestión empresarial.

El #software #process #improvement (#SPI) debe ser parte de un #proyecto de cambio de SPI (2012) -#softwareengineering

Durante el 2012 tuve en este blog un interés especial por el desarrollo de software bajo la óptica de la Ingeniería del Proyecto, lo cual permitía entrar de forma intensiva y profunda en un análisis conjunto de los proyectos de software y de los procesos de software. Esto ayudó a exponer temas “casi” epistemológicos de lo que sería un proyecto de tecnología bajo una óptica organizacional, pero por supuesto dentro y desde el plano de los proyectos de desarrollo de software.

Hablar de proyectos de software siempre es oportuno y pertinente especialmente cuando cada vez más el software ocupa un gran espacio del soporte tecnológico de internet y por supuesto de la nueva economía global basada en la información y las nuevas tecnologías. Por supuesto internet no el único soporte, pero es vital. Por ello esta epistemología no puede plantearse como un simple ejercicio teorizante, que igualmente ayuda a darle un rol más académico a la clara práctica profesional del desarrollo de software. Así que esta epistemología la pongo ordenada alrededor de la relación entre negocio, organización y tecnología. Y con esto se plantearon algunos post para pensar de esta manera o al menos inducir a pensar en que es importante pensar en esta relación.

Estos fueron estos post “epistemológicos”:

– “ICT & Business: ideas para cerrar el gap entre las TIC y las organizaciones (2011)” -Abril 22, 2012-. Aquí se busca consolidar la amalgama entre TIC y organizaciones, siguiendo la línea teórica del post señalado previamente, pero con un acercamiento más estructural o cercano a las estructuras organizacionales.

– “Gestión 2.0+: … y su relación con la “Information Systems Field” y la “Información Systems Philosophy” (2011)” -Abril 30, 2012-. Aquí se relaciona la nueva episteme de la gestión en el Siglo XXI (o Gestión 2.0+) con lo más teórico existente en el campo de estudio de los Sistemas de Información (o Informática como disciplina) con el fin de sostener la relación entre negocio, organización y tecnología, usando como elemento conector la gestión empresarial.

– “Ingeniería del proyecto: t=1 fundamentos para una ciencia proyectual” -Mayo 20, 2012-. Aquí se siguió pensando en consolidar y dar forma a ese boceto iniciado hace años de dar forma a una ciencia proyectual. Se quiera o no, son este post y su predecesor (indicado dentro de aquél anterior), los que muestran el pensamiento proyectual más emblemático del punto de vista de Ingeniería del Proyecto que yo uso.

– “ICT & Business: La multi-dimensionalidad de un proyecto informático desde la perspectiva de la Informática de Negocios: hacia una teoría general del proyecto informático de negocios” -Enero 24, 2012-. Aquí si se entra en terreno complejo al esbozar, proponer, soñar, o simplemente elucubrar la relación entre negocio, organización y tecnología, a través de los planos de los proyectos tecnológicos y de los proyectos de negocios, que no son ni más ni menos que dos proyectos vigentes, co-existentes, que los vemos relacionados gracias a los choques de intereses e intenciones que se dan entre gestores y administradores con tecnólogos, pero no por la íntima bi-direccionalidad de la relación organizacional que existe entre ellos.

– “Ingeniería del Proyecto: Hacia una más adecuada gestión de proyectos informáticos a través del reconocimiento de sus dimensiones” -Enero 25, 2012-. Aquí se analiza un proyecto informático desde varias dimensiones, todas las cuales le dan forma y le  definen.

– “El proyecto como una evolución … reflexiones desde una obra de Laia Estruch” -Julio 30, 2012-. Aquí abordo lo más obvio de los proyectos y lo menos tratado y menos deliberado en la literatura especializada, el proyecto como un evolutivo, aunque me tomo la libertad de hacerlo desde una experiencia artística.

– “Gestión del proyecto: problema, finalidad y salida … en imágenes … ” -Abril 29, 2012-. Aquí simplemente se discute sobre el sentido de hacer un proyecto.

– “Una nota sobre los proyectos y su constitución comunicativa” -Enero 26, 2012-. Aquí se discute cómo el proyecto, ya entendido como un proceso de empatizar intereses e intenciones, consolida este operar procesual a través de la comunicación.

– “Distribución de la riqueza y el rol de las TIC” -Agosto 7, 2012-. Aquí abordo algo poco usual en la literatura de ingeniería de software o más técnica, pero importante en una visión de proyectos: que un proyecto debe mejorar el desarrollo de las personas y la sociedad. Por esta razón hago un pequeño guiño hacia la relación entre distribución de riqueza y TIC.

– ” “Más importante que la pincelada es lo que yace entre ellas” … Estrategias y Diseño Proyectual” -Agosto 6, 2012-. Aquí abordo la relación la poco clara  aunque no inexistente relación entre estrategia y diseño proyectual que expongo recurriendo al uso de la metáfora poético-narrativa.

Con este planteamiento teórico aparecieron varios post relacionados con el estudio más profundo del desarrollo de software. Pero advierto que no se hizo una revisión del desarrollo de software  como una experiencia de ingeniería de software (que de eso hay bastante escrito) sino como un proyecto que existe en función y por un fin, y ese fin es organizacional, el cual, por su lado, se consigue (es decir cómo llegar al fin organizacional) mediante una óptica clara de gestión de proyectos (a diferencia de la ingeniería de software centrada en que se construya un producto, mientras la gestión busca que ESE producto surja de la síntesis empática de diversos intereses e intenciones tanto tecnológicos como organizacionales y de negocios. En la lista de post se incluyó uno que relaciona los problemas del desarrollo de software con el estándar de gestión de proyectos PMBOK para así vincular la utilidad de la gestión de proyectos en la resolución de los problemas clásicos del desarrollo de software-

– “Ingeniería del proyecto: el problema del desarrollo de software (0/7): Hacia una ingeniería de software bajo la óptica de la gestión de proyectos” -Enero 26, 2012-.

– “Ingeniería del proyecto: el problema del desarrollo de software (1/7): la naturaleza del software” -Enero 28, 2012-.

– “Ingeniería del proyecto: el problema del desarrollo de software (2/7): problemas comunes” -Enero 28, 2012-.

– “Ingeniería del proyecto: el problema del desarrollo de software (3/7): consecuencias de los problemas comunes” -Enero 28, 2012-.

– “Ingeniería del proyecto: el problema del desarrollo de software (4/7): causas de los problemas comunes” -Enero 31, 2012-.

– “Ingeniería del proyecto: el problema del desarrollo de software (5/7): formas de evitar los problemas comunes” -Enero 31, 2012-.

– “Ingeniería del proyecto: el problema del desarrollo de software (6/7): estados de una mala gestión de proyectos” -Febrero 4, 2012-.

– “Ingeniería del proyecto: el problema del desarrollo de software (7/7): razón de ser de una gestión de proyectos en informática” -Febrero 4, 2012-.

– “Problemas informáticos y el PMBOK” -Enero 26, 2012-.

Se cerró el 2012 con un desarrollo teórico pero que emana de la propia práctica y praxis del desarrollo de software, orientado a mejorar el proceso de software. El proceso de software, ese difuso concepto que nos dice que el software se desarrolla a través de procesos maduros conseguidos en modelos de madurez, se analiza en algunos post como un proyecto de cambio. ¡¡¡Sí!!!, un proyecto de cambio. Cuando se habla y aplican procesos de software se trabaja literalmente en la aplicación y definición de procesos orientados a que las cosas se hagan mejor, con mejores herramientas y aprovechando la experiencia de proyectos pasados. Esto se conoce como la madurez del proceso, la cual, parte de un estado o nivel de inmadurez o madurez 0, hasta otros superiores que conducen hacia una madurez. A mayor madurez, dice la teoría, mayor calidad. Y esto cuando opera consecutivamente le llaman proceso de mejora de software o Software Process Improvement (SPI).  Todo esto está muy bien, PERO, se ha dejado bastante de lado, que el pasar de un estado de madurez a otro no es parte del proceso de madurez, sino que es parte de un proceso superior, el proyecto de cambio. Cuando una organización desarrolladora de software decide pasar de un estado de madurez a otro, DEBE asumir que entra en un fuerte proceso de cambio y cada decisión que tome para evolucionar hacia mayores niveles de madurez implican costes y nuevos commodities de calidad que deben sostenerse. Aquí es donde quienes entran en este proceso de cambio suelen fallar: uno, porque mayor madurez implica mayor calidad y por ende nuevos y mayores costes de calidad que deben asumirse y no olvidemos que el negocio del desarrollo de software no necesariamente sigue la regla de más-calidad–>incremento-de-beneficios ya que fenómenos como el plagio (muy frecuentes), mercados sensibles a cambios (usuarios poco fieles), etc., hacen de éste, el negocio del software, muy volatil. Y, dos, porque alcanzar un nivel mayor de madurez implica no volver atrás, o sea, implica cognitivamente no pensar la calidad como un elemento excepcional sino como un commodity de la organización, algo que DEBE estar presente sin necesidad de pensarlo, lo cual muchas veces no es algo tan común. El proceso de cambio, por tanto es crucial, pero ¿cómo se hace, quién lo hace, cuanto cuesta hacerlo y cuánto cuesta una decisión, cómo opera y donde encaja en la organización y en el proceso de software en el día-a-día, etc?  Todas estas preguntas demandan respuestas y por su propia forma de enunciarlas hace pensar en un enfoque de proyecto que debe ser gestionado, por eso este proceso de cambio se denomina proyecto de cambio del proceso de mejora de software, proyecto de cambio del SPI.

– “Una nota sobre el Incapability Maturity Model” -Enero 25, 2012-.

– “Ingeniería del Proyecto: Conformación de la Propuesta de Mejora al Proceso de Software” -Mayo 9, 2012-.

– “Ingeniería del proyecto: DEFINICIÓN DE LOS ESCENARIOS PARA PROYECTOS DE MEJORA AL PROCESO DE SOFTWARE: PERSPECTIVA ORGANIZACIONAL” -Julio 16, 2012-.

– “Ingeniería del Proyecto: Change Process: Formalisation and Valorisation with Cost-Efficiency Analysis on Initial Phase to Software Process Improvement” -Junio 13, 2012-.

– “Más allá del ROI en la Selección de Proyectos y cómo mejorar el proceso de desarrollo de software” -Marzo 21, 2012-.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

CEO & Co-Founder de EstayConsulting – Consultoría Estratégica

Miembro de Red

//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js (adsbygoogle = window.adsbygoogle || []).push({});

Categorías

A %d blogueros les gusta esto: