viernes, diciembre 01, 2006

La metodología como caballo de troya

Uno de los problemas que nos podemos encontrar en las organizaciones es que no estén lo suficientemente maduras para la agilidad como ya comenté en ¿Cuando puedo aplicar una metodología ágil? y en 7 Paradigmas a romper para ser ágiles

Si a esto le unimos la semiestructuración de los procesos decisionales, nos encontramos que para aplicar una metodología ágil en un proyecto de Business Intelligence, tenemos que tener muy claro a que nos estamos enfrentando. Para ello el primer proyecto que se haga de estas características en la organización tiene que tener no solo el caracter de una metodología rigurosa y seria, sino también la característica de "evangelizar", de ser un caballo de Troya que infecte a todos los ambitos de desarrollo de la organización.

Un metodología (que desgraciadamente su autor no ha seguido desarrollando) es el Adaptative Software Development, esta metodología parte de la idea de que las necesidades del cliente son siempre cambiantes durante el desarrollo del proyecto (y posteriormente a su entrega). Cosa que nos viene que ni pintada para los sistemas decisionales

Su impulsor es Jim Highsmith, la novedad de esta metodología es que en realidad no es una metodología de desarrollo de software, sino un método (como un caballo de troya) a través del cual inculcar una cultura adaptativa a la empresa ya que su velocidad de adaptación a los cambios marcará la diferencia entre una empresa próspera y una en declive.

La incertidumbre y el cambio continuo son el estado natural de los sistemas de información, pero parece ser que muchas organizaciones aún no son conscientes de ellos. La idea de “finalizar” un proyecto carece de sentido porque debe seguir adaptándose y con mas razón si se trata de un sistema decisional. Siempre estamos cambiando nuestros puntos de vista.


Así pues tenemos una metodología (mas bien un metodito) con 4 objetivos claros (independientemente de que el proyecto sea un éxito)

  1. Concienciar a la organización de que debe esperar cambio e incertidumbre y no orden y estabilidad.
  2. Desarrollar procesos iterativos de gestión del cambio.
  3. Facilitar la colaboración y la interacción de las personas a nivel interpersonal, cultural y estructural.
  4. Marcar una estrategia de desarrollo rápido de aplicaciones pero con rigor y disciplina.El ciclo de vida que propone se basa en tres fases

El ciclo de vida que propone se basa en tres fases

Fase 1: Especulación. Se inicia el proyecto y se planifican las características del aplicativo a desarrollar.

Fase 2: Colaboración. en esta el equipo de desarrollo se encarga de implementar las características

Fase 3: Aprendizaje. En ella se revisa su calidad, se aprende de los errores y se vuelve a iniciar el ciclo de desarrollo y/o se entrega al cliente.

Pero lo importante no son las fases ni nada por el estilo, lo realmente importante es que cambia la semántica de la creación de sistemas de información:

En lugar de analizar, diseñar, implementar, etc.. que es el lenguaje habitual con una semántica de infalibilidad y definitud (creo que me he inventado esta palabra) algo jactante, pasamos a especular, colaborar y aprender juntos y eso creo que es una buena característica para una metodología, sea cual sea su ámbito de actuación.


Por favor no me pongais ningún comentario a esta entrada (estoy probando la psicología inversa a ver si consigo mas colaboración) :-D

9 comentarios:

Emilio Velardiez dijo...

re: Excelentes listas de comprobación para Scrum

Y bueno ya que me pongo estos articulos de otro excelente blog de Jorge Fernández González paisano de BCN.

La metodología como caballo de troya

http://sistemasdecisionales.blogspot.com/2006/12/la-metodologa-como-caballo-de-troya.html

¿Cuando puedo aplicar una metodología ágil?

http://sistemasdecisionales.blogspot.com/2006/10/cuando-puedo-aplicar-una-metodologa.html

7 Paradigmas a romper para ser ágiles

http://sistemasdecisionales.blogspot.com/2006/08/7-paradigmas-romper-para-ser-giles.html

A ver si se invita a algo por la publicidad... jejeje

Jorge Fernández González dijo...

Emilio

Seguro que algo se me escapa... ¡¡¡pero si me haces publicidad en mi blog!!! je je je

Dime lo que se me escapa, ¿¿es un link de otro blog??

Luego yo te invito a lo que sea :-D

Emilio Velardiez dijo...

Puedes eliminarlo... gracias.
Mi intención era comentar aqui:
http://geeks.ms/blogs/rcorral/archive/2006/11/30/excelente-lista-de-comprobaci-oacute-n-para-scrum.aspx?CommentPosted=true#commentmessage

Jorge Fernández González dijo...

si hombre, un comentario que tengo no lo pienso eliminar je je je

Muchas gracias por la publicidad Emilio
cuando quieras te invito a una cerveza.

Un saludo y gracias

Antonio Valle dijo...

mmm, Jorgete... esta frase me gusta! hay que darle unas cuantas vueltas, pero da para discutir largo y tendido!

La incertidumbre y el cambio continuo son el estado natural de los sistemas de información

No se si es el estado "natural", pero seguro que es el estado "real"... debemos adaptarnos a ese estado o debemos luchar para eliminar al menos el factor "incertidumbre" y potenciar el factor "cambio continuo" para convertirlo en "cambio continuo y controlado para asegurar la adaptabilidad" (toma palabro inventado!).

Al fin y al cabo, Darwin dijo que solo los que se sabian adaptar correctamente al medio son los que sobreviven, no? (eso dice el video promocional de tu empresa)

Jorge Fernández González dijo...

Tienes razón, si una empresa no cambia seguramente acabará desapareciendo, por lo tanto el Sistema de Información debe adaptarse plenamente a estos cambios continuos como tu has dicho. Pero la incertidumbre.... ¡oh amigo!, esa no te la quita nadie, puedes llevar a tener mas o menos controlada tu cadena de valor interna, en incluso a tus proveedores y a tus clientes, pero es muy dificil que puedas controlar como te va a afectar el mercado o un cambio en las leyes o un rayo que te caiga encima (no confundir con que te parta un rayo ;-D), son muchas las "fuerzas" que actuan sobre la organización que hacen que la incertidumbre esté siempre presente, Porter las clasificó en 5 .

Aunque eso si hay que minimizarla

Anónimo dijo...

Muy muy interesante el post. Los pasos que propones:

Fase 1: Especulación. Se inicia el proyecto y se planifican las características del aplicativo a desarrollar.

Fase 2: Colaboración. En esta el equipo de desarrollo se encarga de implementar las características

Fase 3: Aprendizaje. En ella se revisa su calidad, se aprende de los errores y se vuelve a iniciar el ciclo de desarrollo y/o se entrega al cliente.

Me parecen muy interesantes y mucho más próximos a la forma de trabajar de un proceso de cambio continuo que no, como apuntas, los métodos clásicos mucho más estáticos.


Este post me ha recordado mucho a un libro que leí ya hace tiempo del que os adjunto la referencia:

LA ORGANIZACIÓN EN LA ERA DE LA INFORMACIÓN.
Aprendizaje, innovación y cambio
Autores: Rafael Andreu, Joan E. Ricart y Josep Valor McGraw - Hill, 1997

Un libro muy interesante que habla de cómo organizar y aplicar cambios sobre una organización, reorganizando la información sobre los procesos de negocio. También expone casos, etc.

Saludos a todos,

Martí

Anónimo dijo...

Por cierto, veo que la psicología inversa funciona ;·)

Jorge Fernández González dijo...

Gracias por la referencia Marti, le pegaré un vistazo.

Como bien dices, el cambio continuo nos hace que necesitemos una metodología que nos sirva para adaptarnos facilmente, que esté concebida por y para el cambio, que no sea una molestia cambiar la especificación, sino que sea parte del ciclo natural de la misma.